CN101217403B - 一种基于简单网络管理协议的告警实现方法 - Google Patents
一种基于简单网络管理协议的告警实现方法 Download PDFInfo
- Publication number
- CN101217403B CN101217403B CN2008100011301A CN200810001130A CN101217403B CN 101217403 B CN101217403 B CN 101217403B CN 2008100011301 A CN2008100011301 A CN 2008100011301A CN 200810001130 A CN200810001130 A CN 200810001130A CN 101217403 B CN101217403 B CN 101217403B
- Authority
- CN
- China
- Prior art keywords
- snmp
- message
- alarm information
- nms
- value
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
一种基于简单网络管理协议SNMP的告警实现方法,包括以下步骤:当被管设备发生告警事件或产生故障时,网管代理SNMP Agent产生一告警消息,并根据告警消息组成一SNMP告警消息报文后将其发送给网络管理工作站NMS,报文中携带一表示告警消息为紧急或非紧急的紧急程度标识;NMS解析SNMP告警消息报文,如其中携带的紧急程度标识表示告警消息为紧急时,则NMS向SNMP Agent回复确认报文SNMP Response;否则,NMS按照标准SNMP Trap的机制处理告警消息后,结束。本发明既保留了SNMP Trap机制的简便高效性,又加入了实现可靠性保障的对象元素,具有很高的通用性。
Description
技术领域
本发明涉及通信领域,尤其涉及一种基于简单网络管理协议SNMP的告警实现方法。
背景技术
目前几乎所有网络通信设备都具备了简单网络管理协议SNMP(SimpleNetwork Management Protocol)网络管理功能,SNMP网络管理系统由网络管理工作站NMS(Network Management Station)和运行在被管设备上的网管代理SNMP Agent组成,SNMP Agent与NMS之间通过标准的SNMP协议来进行通信。SNMP网管系统可以完成对被管设备的配置管理、性能管理和故障管理等功能。
图1为SNMP网络管理系统的结构示意图。在图1中,NMS和被管网元之间是基于SNMP进行网络管理的。其中,NMS包括NMS应用层和NMS通讯层。一般的,在NMS和被管网元之间进行通信网络管理的过程包括以下步骤:
NMS应用层发送查询/配置请求给NMS通讯层,NMS通讯层相应地将这些请求转化为SNMP Get/Set请求后,与被管设备进行交互;同时,如果被管设备发生故障或异常,SNMP Agent也会主动向NMS发送告警消息。
其中,故障管理是网络管理中最基本的功能之一,也是运维人员最为关心的问题。当前技术中,基于SNMP的故障管理方式,主要包括以下两种:
A,通过网管系统定时轮询被管设备的方式来获取被管设备的各项性能指标及状态等。若采集到的性能数据超过某一限定值或采集到的状态异常,则认为发生了告警事件,由网管系统发出告警,通知运维人员干预处理;
B,在被管设备发生告警或故障时,SNMP Agent会自动产生告警消息并以通知的形式实时地向NMS报告被管设备发生的这些重要事件。
目前,被管设备向网管系统发送告警消息的机制主要有两种:SNMPTrap(陷阱消息)和SNMP Inform(通知消息)。
SNMP Trap是SNMP代理向一个或多个预配置的NMS发送的一种非请求性通知消息,其用于向管理者报告被管理对象的状态变化,其机制如图2所示。而SNMP Inform是一种需要NMS确认接收的通知消息,其机制如图3所示。从图3中可以看出,与SNMP Inform相比较,SNMP Trap为一种不可靠的传输方式,因为NMS在收到一条SNMP Trap后无需回复任何确认信息,发送者无法知道SNMP Trap是否已经被正确接收。与此相对应,当NMS收到一条SNMP Inform后,它需要使用SNMP应答数据包向发送者回复一条确认信息,并将这条SNMP Inform转发给另一个NMS。如果NMS没有接收到SNMP Inform,它将不会转发及发送应答,所以当发送者无法接收到期望的应答时,它将再次发送一条SNMP Inform给NMS。这种SNMP Inform方式保证了SNMP Agent可以无一遗漏地把告警消息发送到期望的目的地。
然而在多数情况下,SNMP Trap方式仍然较多地被采用,因为采用SNMP Inform方式会耗费更多的网络和设备资源。与SNMP Trap方式不同的是,采用SNMP Inform方式后,被管设备不能在发送后立即把一条SNMPInform丢弃,它需要把该条信息保存在系统内存中直到收到相应的确认应答或设备规定的计时器超时。由此可见,一条SNMP Trap只会被发送一次,而SNMP Inform可能会被重复发送多次。这种重复发送又会增加网络流量,造成网络额外开销的上升。
根据以上分析可以看出,在目前基于SNMP协议管理的通信网络,特别是网元层管理中,寻找能同时兼顾可靠性和高效性的告警通知方法仍是一个亟待解决的重要问题。
发明内容
本发明要解决的技术问题是提供一种基于SNMP的告警实现方法,以同时兼顾告警通知的可靠性和高效性。
为解决上述问题,本发明提供了一种基于简单网络管理协议SNMP的告警实现方法,应用于包含一网络管理工作站NMS和一运行在被管设备上的网管代理SNMP Agent的网管系统中,包括以下步骤:
a、当所述被管设备发生告警事件或产生故障时,所述SNMP Agent产生一告警消息,并根据所述告警消息组成一SNMP告警消息报文后将其发送给所述NMS,所述报文中携带一表示所述告警消息为紧急告警消息或非紧急告警消息的紧急程度标识;
b、所述NMS解析其收到的所述SNMP告警消息报文,如其中携带的紧急程度标识表示所述告警消息为紧急告警消息,则所述NMS向所述SNMP Agent回复确认报文SNMP Response;否则,所述NMS按照标准SNMPTrap的机制处理所述告警消息后,结束。
进一步地,上述方法还可具有以下特征:
所述紧急程度标识用一EmergentType标签来表示,其有两个取值,分别代表所述告警消息为紧急告警消息和非紧急告警消息。
进一步地,上述方法还可具有以下特征:
步骤a中,所述告警消息报文中还携带一TrapID标签并由所述SNMPAgent为其赋值;所述TrapID的值代表所述告警消息的编号,非紧急告警消息的TrapID值为0,而紧急告警消息的TrapID值为所述SNMP Agent为其分配的一个与前一告警消息的编号相连续的非零编号。
进一步地,上述方法还可具有以下特征:
所述紧急程度标识用一TrapID标签来表示,如所述告警消息为一非紧急告警消息,则其TrapID的值为0;如所述告警消息为一紧急告警消息,则其TrapID的值为所述SNMP Agent为其分配的一个与前一告警消息的编号相连续的非零编号。
进一步地,上述方法还可具有以下特征:
如果所述告警消息为紧急告警消息,则在步骤a中,还包括以下步骤:所述SNMP Agent将所述紧急告警消息数据结构缓存起来。
进一步地,上述方法还可具有以下特征:
所述步骤b中,所述SNMP Response报文中携带所述告警消息的TrapID值;所述步骤b之后,还包括以下步骤:所述SNMP Agent接收到所述NMS向其发送的SNMP Response报文后,对该报文进行解析,若其中携带的TrapID的值与缓存中保存的一条紧急告警消息数据结构的TrapID值相同,则所述SNMP Agent将缓存的该条告警消息数据结构释放。
进一步地,上述方法还可具有以下特征:
步骤b中,在构造所述SNMP Response报文时,将所述TrapID值填入所述SNMP Response报文结构的请求ID位置处,该报文结构的差错状态及差错索引的位置都填入0,请求对象的OBJECT IDENTIFIER位置填入所述SNMP告警消息报文中携带的表示产生告警的网元对象标识符Trap oid,与这个oid绑定的value的位置填入NULL。
进一步地,上述方法还可具有以下特征:
所述步骤b中,所述NMS对其接收到的所述SNMP告警消息报文进行解析后,将解析出的告警消息数据结构保存起来。
进一步地,上述方法还可具有以下特征:
所述步骤b中还包括以下步骤:如所述告警消息为紧急告警消息,则所述NMS判断其从所述SNMP告警消息报文中解析出的TrapID的值Id1与其上记录的上一条告警消息数据结构的TrapID的值Id2是否连续;如不连续,还包括以下步骤:
A、设一变量Id,其值等于Id1-1;
B、判断Id的值是否等于Id2的值;如果不等,则将Id的值作为所要请求的紧急告警消息的TrapID值,组成标准SNMP Get-Request报文后,将其发送至所述SNMP Agent;
C、所述SNMP Agent解析接收到的所述SNMP Get-Request报文,并在缓存数据区中查找与该报文具有相同TrapID值的告警消息数据结构;
D、所述SNMP Agent将查找到的告警消息数据结构组成SNMPResponse报文发送至所述NMS,并释放缓存的本条告警消息数据结构;
E、所述NMS解析收到的SNMP Response报文,并将解析后的告警消息数据结构保存起来后,令Id=Id-1,执行步骤B。
进一步地,上述方法还可具有以下特征:
步骤B中,在构造所述SNMP Get-Request报文时,所述NMS将所述TrapID的值填入所述SNMP Get-Request报文的请求对象的OID标签中。
进一步地,上述方法还可具有以下特征:
步骤a中,当所述SNMP Agent向所述NMS发送一条紧急告警消息报文时,启动一定时器;若直到所述定时器超时时仍未收到所述NMS向其返回的与所述紧急告警消息报文对应的SNMP Response报文,则所述SNMPAgent将其缓存的该条SNMP告警消息数据结构组成SNMP告警消息报文后重新发送给所述NMS。
进一步地,上述方法还可具有以下特征:
当所述SNMP Agent重发所述紧急告警消息报文的次数达到设定的次数后仍未收到所述NMS返回的SNMP Response报文时,所述SNMP Agent将不再尝试发送,而是将本条紧急告警消息数据结构中的关键信息字段重新缓存在另一处后,将本条紧急告警消息数据结构释放。
进一步地,上述方法还可具有以下特征:
所述紧急告警消息数据结构中的关键信息字段包括:告警发生时间、告警码及TrapID的值。
进一步地,上述方法还可具有以下特征:
所述EmergentType的值为0时表示所述告警消息为非紧急告警消息;所述EmergentType的值为1时表示该告警消息为紧急告警消息。
在本发明中设计了一种增强型的SNMP Trap报文,该报文在原有SNMPTrap报文结构的基础上进行了改进,既保留了SNMP Trap机制的简便高效性,又加入了实现可靠性保障的对象元素,在当前已实现了SNMP协议的网元设备上就可轻易实现,提高了本发明的通用性。此外,本发明并不拘泥于某一种固定的告警消息发送方式,可以根据具体的告警内容及性质在报文中动态填入,在保证可靠性的同时讲求高效,尽量少占用设备和网络资源,提高了网络性能。
附图说明
图1为现有技术中基于SNMP的网络管理系统的结构示意图;
图2为现有技术中SNMP Trap处理机制示意图;
图3为现有技术中SNMP Inform处理机制示意图;
图4为本发明实施例中基于SNMP的告警实现方法的流程图;
图5为本发明实施例中紧急告警消息“补漏”处理的流程图。
具体实施方式
下面将结合附图及实施例对本发明的技术方案进行更详细的说明。
本发明的基本构思是:通过在告警消息中添加一与告警的紧急程度有关的指示信息,以实现对任意重要的、必须收到的紧急告警以“告警—确认”的方式传递,对不十分重要的通知或Debug消息等非紧急告警消息则出于对流量及网络资源等因素的考虑以“告警”方式直接发送。
图4是本实施例中处理机制的流程图,描述了改进后的告警消息的传递流程,尤其是对重要告警类消息的处理过程,具体包括以下步骤:
401,网元层中的SNMP Agent在设备发生告警事件或产生故障时,自动产生一告警消息,并根据该告警消息组成一个告警消息报文,并将其发送给NMS通讯层(即NMS中的SNMP协议进程);
报文以增强型的SNMP Trap(以下简称SNMP ExTrap)报文格式组报,其格式如表1所示,其中携带TrapID及EmergentType标签(表1中虚线所示)或仅携带TrapID标签,除此之外,其格式与SNMP Trap报文的格式相同。这两个标签在SNMP MIB(管理信息库)库中的类型定义如下,其中,TrapID是一个INTEGER32类型的对象:
TrapID::=
INTEGER32;
EmergentType::=
INTEGER{
Non-Emergent(0),
Emergent(1),
};
表1 SNMP ExTrap告警消息报文的结构表
版本号(Version) |
共同体名(Community) |
PDU类型(PDU Type)(Trap) |
产生trap的系统的OBJECT IDENTIFIER(Trap oid) |
系统的IP地址(Agent IP) |
普通类型(genType) |
特定类型(specType) |
时间戳(sysuptime) |
告警ID编号(TrapID) |
告警紧急类型(EmergentType) |
变量对偶表(VarBind) |
对于紧急告警消息,SNMP Agent将TrapID的值从1开始顺序编号,而将非紧急告警消息的TrapID值置为0;如果报文中存在EmergentType标签,则其值将根据告警消息的紧急程度填入(在此实施例中,0表示非紧急,1表示紧急,反之亦可)。告警消息的紧急程度通常是由系统内部自己定义的,一般情况下默认进程挂起等影响系统正常功能的故障都为紧急告警。组好报文后,对于紧急告警消息报文,SNMP Agent还需将该条告警消息的数据结构缓存起来;而对于非紧急告警消息报文,SNMP Agent在将其发送给NMS通讯层后立即释放;
402,网管NMS中的NMS通讯层在接收到SNMP Agent发来的告警消息报文后,将按照标准SNMP编码规则进行解码,并将解析后的告警消息数据结构按照内部消息传输方式发送到NMS应用层(即SNMP Manager中的SNMP应用进程);
403,NMS应用层接收到告警消息数据结构,执行告警数据存储,并对其中的紧急程度标识进行判断。如告警消息报文携带TrapID标签及EmergentType标签,则EmergentType为紧急程度标识;如告警消息报文中仅携带TrapID标签,则TrapID为紧急程度标识;
404,若紧急程度标识EmergentType的值为1或TrapID的值非0,则将告警确认消息数据结构以内部消息形式发送到NMS通讯层;否则,NMS将仍按照现有的标准SNMP Trap的机制来处理上述告警消息,结束;
405,NMS通讯层在接收告警确认消息数据结构后,按照标准SNMPResponse的报文格式进行编码,将组好的SNMP Response(确认)报文经网络发送至SNMP Agent。组SNMP Response报文的过程如下:
如表2所示,告警确认消息使用的SNMP Response报文格式就是标准的SNMP Response的报文格式。无论SNMP ExTrap告警消息报文中携带TrapID与EmergentType标签还是仅携带TrapID标签,TrapID这个表示紧急告警消息唯一标识的标签,都可用来关联SNMP ExTrap告警消息报文和SNMP Response报文。NMS通讯层在接收到携带非零TrapID值的SNMPExTrap告警消息报文时,会将该条报文中的TrapID值取出;在组SNMPResponse报文的时候,将这个值填入其报文结构中的“请求ID”位置处,而“差错状态”及“差错索引”处都填入0,“请求对象的OBJECTIDENTIFIER”位置填入与其对应的SNMP ExTrap告警消息报文中携带的表示产生告警的网元对象标识符Trap oid,与这个oid绑定的“value”的位置填入NULL。这样,用于实现“告警—确认”这一机制的交互报文实体就完成了。
表2响应报文SNMP Response的结构表
版本号(Version) |
共同体名(Community) |
PDU类型(PDU Type)(Trap Response) |
请求ID(Trap ID) |
差错状态(Error Status) |
差错索引(Error Index) |
请求对象的OBJECT IDENTIFIER(Trap oid) |
请求对象的绑定值(value) |
406,SNMP Agent解析收到的SNMP Response报文,若报文中携带的TrapID与缓存中的一条告警消息数据结构中的TrapID值相同,则SNMPAgent将这条缓存的告警消息数据结构释放。
此外,在步骤401中,当SNMP Agent向NMS通讯层发送一条SNMPExTrap紧急告警消息报文后,还可以启动一定时器。若在该定时器超时时,SNMP Agent仍未收到NMS发来的表示已接收到该条SNMP ExTrap告警消息报文的SNMP Response报文,即为该条SNMP ExTrap紧急告警消息报文没有成功地被发送到NMS侧。则SNMP Agent将重新向NMS发送该SNMPExTrap紧急告警消息报文,且重新启动该定时器。当SNMP Agent重发此条SNMP ExTrap紧急告警消息报文的次数达到设定的次数(如3次)后仍未收到NMS的回应时,SNMP Agent将不再尝试发送,而是将本条告警消息中的关键信息字段,例如告警发生时间、告警码、TrapID等,重新缓存在另一处后,将该告警消息数据结构释放。如此,可以减少不断重发所占用的带宽资源和完整的告警报文占用的设备资源。
步骤403中,当NMS应用层收到一条紧急告警消息的数据结构后,将其中携带的TrapID的值(Id1)与其上存储的最后一条紧急告警消息数据结构的TrapID的值(Id2)进行比较。若Id1≠Id2+1,则认为存在紧急告警消息的丢失,由NMS发起SNMP Get-Request请求,SNMP Agent接收到后将以SNMP Response报文的形式将缓存数据区中的此条告警消息报文发送给NMS。这个过程称之为紧急告警消息的“补漏”处理。如图5所示,NMS主动获取因异常原因而丢失的紧急告警消息的实现过程包括以下步骤:
501,SNMP Agent向NMS通讯层发送SNMP ExTrap告警消息报文,其中携带TrapID与EmergentType或仅携带TrapID;
502,NMS通讯层解析接收到的SNMP ExTrap告警消息报文,并将解析后的告警消息数据结构按照内部消息传输方式发送到NMS应用层;
503,NMS应用层接收告警消息数据结构后,执行告警数据存储并对消息中的紧急程度标识进行判断;
504,若该条告警消息为紧急告警消息,且Id1≠Id2+1,则设一变量值Id,且Id=Id1-1;
505,判断Id的值是否等于Id2;如果是,结束;否则,将Id的值作为所要请求的告警消息的TrapID值,将请求消息数据结构以内部消息的形式发送到NMS通讯层;
506,NMS通讯层接收到请求消息数据结构后,按照标准SNMPGet-Request的报文格式进行编码,将上述TrapID的值填入SNMPGet-Request报文中的“请求对象的OID”标签中,组成SNMP Get-Request报文后经网络发送至SNMP Agent;
507,SNMP Agent解析接收到的SNMP Get-Request报文,并在缓存数据区中查找与该报文具有相同TrapID值的告警消息数据结构;
508,SNMP Agent将查找到的告警消息数据结构组成SNMP Response报文,经网络发送至NMS,并将缓存的本条告警消息释放;
509,NMS通讯层解析收到的SNMP Response报文,并将解析后的告警消息数据结构按照内部消息传输方式,发送到NMS应用层;
510,NMS应用层接收告警消息数据结构后,对其进行存储后,令Id=Id-1,执行步骤505。
由于NMS向SNMP Agent请求遗漏告警消息后,SNMP Agent向其发送响应消息的过程实际是一个GET-RESPONSE报文交互的过程。按照一般的处理方法,若NMS没有收到SNMP Agent向其发送的RESPONSE报文的话,其会再次向SNMP Agent发送SNMP Get-Request报文,去再次请求这些遗漏的紧急告警消息的。
在现有技术中,无论是以Trap还是以Inform机制实现告警传递都有其自身比较明显的优缺点,无法实现折中;而在本实施例中,实际是实现了一种中和两者优点、兼顾了可靠性和高效性的告警消息传递方法,并在此基础上进一步增强了对重要告警可靠性保证的实现。
综上所述,采用本发明所述方法,应用于基于SNMP的网管系统中,告警消息在网元层和NMS层之间的传递过程,由在告警报文中自主设定紧急类型的方式,达到了对重要的告警以一种可靠方式传递;而对不十分重要的告警则仍沿用非可靠的方式传递。做到了在保证可靠性的同时讲求高效,尽量少占用设备和网络资源,提高了网络性能。
当然,本发明还可有其他多种实施例,在不背离本发明精神及其实质的情况下,熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形,但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。
Claims (14)
1.一种基于简单网络管理协议SNMP的告警实现方法,应用于包含一网络管理工作站NMS和一运行在被管设备上的网管代理SNMP Agent的网管系统中,其特征在于,包括以下步骤:
a、当所述被管设备发生告警事件或产生故障时,所述SNMP Agent产生一告警消息,并根据所述告警消息组成一SNMP告警消息报文后将其发送给所述NMS,所述报文中携带一表示所述告警消息为紧急告警消息或非紧急告警消息的紧急程度标识;
b、所述NMS解析其收到的所述SNMP告警消息报文,如其中携带的紧急程度标识表示所述告警消息为紧急告警消息,则所述NMS向所述SNMP Agent回复确认报文SNMP Response;否则,所述NMS按照标准SNMPTrap的机制处理所述告警消息后,结束。
2.如权利要求1所述的方法,其特征在于,
所述紧急程度标识用一EmergentType标签来表示,其有两个取值,分别代表所述告警消息为紧急告警消息和非紧急告警消息。
3.如权利要求2所述的方法,其特征在于,
步骤a中,所述告警消息报文中还携带一TrapID标签并由所述SNMPAgent为其赋值;所述TrapID的值代表所述告警消息的编号,非紧急告警消息的TrapID值为0,而紧急告警消息的TrapID值为所述SNMP Agent为其分配的一个与前一告警消息的编号相连续的非零编号。
4.如权利要求1所述的方法,其特征在于,
所述紧急程度标识用一TrapID标签来表示,如所述告警消息为一非紧急告警消息,则其TrapID的值为0;如所述告警消息为一紧急告警消息,则其TrapID的值为所述SNMP Agent为其分配的一个与前一告警消息的编号相连续的非零编号。
5.如权利要求1所述的方法,其特征在于,
如果所述告警消息为紧急告警消息,则在步骤a中,还包括以下步骤:所述SNMP Agent将所述紧急告警消息数据结构存入缓存。
6.如权利要求3、4或5所述的方法,其特征在于,
所述步骤b中,所述SNMP Response报文中携带所述告警消息的TrapID值;所述步骤b之后,还包括以下步骤:所述SNMP Agent接收到所述NMS向其发送的SNMP Response报文后,对该报文进行解析,若其中携带的TrapID的值与缓存中保存的一条紧急告警消息数据结构的TrapID值相同,则所述SNMP Agent将缓存中的该条告警消息数据结构释放。
7.如权利要求6所述的方法,其特征在于,
步骤b中,在构造所述SNMP Response报文时,将所述TrapID值填入所述SNMP Response报文结构的请求ID位置处,该报文结构的差错状态及差错索引的位置都填入0,请求对象的OBJECT IDENTIFIER位置填入所述SNMP告警消息报文中携带的表示产生告警的网元对象标识符Trap oid,与这个oid绑定的value的位置填入NULL。
8.如权利要求1所述的方法,其特征在于,
所述步骤b中,所述NMS对其接收到的所述SNMP告警消息报文进行解析后,将解析出的告警消息数据结构保存起来。
9.如权利要求3、4、5或8所述的方法,其特征在于,
所述步骤b中还包括以下步骤:如所述告警消息为紧急告警消息,则所述NMS判断其从所述SNMP告警消息报文中解析出的TrapID的值Id1与其上记录的上一条告警消息数据结构的TrapID的值Id2是否连续;如不连续,还包括以下步骤:
A、设一变量Id,其值等于Id1-1;
B、判断Id的值是否等于Id2的值;如果不等,则将Id的值作为所要请求的紧急告警消息的TrapID值,组成标准SNMP Get-Request报文后,将其发送至所述SNMP Agent;
C、所述SNMP Agent解析接收到的所述SNMP Get-Request报文,并在缓存数据区中查找与该报文具有相同TrapID值的告警消息数据结构;
D、所述SNMP Agent将查找到的告警消息数据结构组成SNMPResponse报文发送至所述NMS,并释放缓存的本条告警消息数据结构;
E、所述NMS解析收到的SNMP Response报文,并将解析后的告警消息数据结构保存起来后,令Id=Id-1,执行步骤B。
10.如权利要求9所述的方法,其特征在于,
步骤B中,在构造所述SNMP Get-Request报文时,所述NMS将所述TrapID的值填入所述SNMP Get-Request报文的请求对象的OID标签中。
11.如权利要求5所述的方法,其特征在于,
步骤a中,当所述SNMP Agent向所述NMS发送一条紧急告警消息报文时,启动一定时器;若直到所述定时器超时时仍未收到所述NMS向其返回的与所述紧急告警消息报文对应的SNMP Response报文,则所述SNMPAgent将其缓存的该条SNMP告警消息数据结构组成SNMP告警消息报文后重新发送给所述NMS。
12.如权利要求11所述的方法,其特征在于,
当所述SNMP Agent重发所述紧急告警消息报文的次数达到设定的次数后仍未收到所述NMS返回的SNMP Response报文时,所述SNMP Agent将不再尝试发送,而是将本条紧急告警消息数据结构中的关键信息字段重新缓存在另一处后,将本条紧急告警消息数据结构释放。
13.如权利要求12所述的方法,其特征在于,
所述紧急告警消息数据结构中的关键信息字段包括:告警发生时间、告警码及TrapID的值。
14.如权利要求2所述的方法,其特征在于,
所述EmergentType的值为0时表示所述告警消息为非紧急告警消息;所述EmergentType的值为1时表示该告警消息为紧急告警消息。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2008100011301A CN101217403B (zh) | 2008-01-16 | 2008-01-16 | 一种基于简单网络管理协议的告警实现方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2008100011301A CN101217403B (zh) | 2008-01-16 | 2008-01-16 | 一种基于简单网络管理协议的告警实现方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101217403A CN101217403A (zh) | 2008-07-09 |
CN101217403B true CN101217403B (zh) | 2010-09-29 |
Family
ID=39623769
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2008100011301A Expired - Fee Related CN101217403B (zh) | 2008-01-16 | 2008-01-16 | 一种基于简单网络管理协议的告警实现方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101217403B (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103812690A (zh) * | 2013-08-06 | 2014-05-21 | 国家电网公司 | 一种设备归一化管理接口的故障诊断信息传送及处理方法 |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102014427B (zh) * | 2010-11-30 | 2015-07-22 | 中兴通讯股份有限公司 | 网络设备上报状态信息的方法和装置 |
CN102158363A (zh) * | 2011-04-26 | 2011-08-17 | 中兴通讯股份有限公司 | 简单网络管理协议的安全保护方法及装置 |
CN103618624B (zh) * | 2013-11-29 | 2017-04-12 | 武汉烽火网络有限责任公司 | 利用snmp告警实现设备自动发现的方法 |
CN104735474A (zh) * | 2013-12-20 | 2015-06-24 | 乐视网信息技术(北京)股份有限公司 | 一种消息推送方法和装置 |
CN104468206B (zh) * | 2014-11-28 | 2019-04-05 | 华为技术服务有限公司 | 性能告警的方法和装置 |
CN107290986B (zh) * | 2016-04-11 | 2019-09-03 | 趣之科技(深圳)有限公司 | 一种基于互联网云服务的远程机器人实时消息推送方法、系统和装置 |
CN107222356A (zh) * | 2017-07-28 | 2017-09-29 | 郑州云海信息技术有限公司 | 一种云监控系统告警方法和系统 |
CN111769973A (zh) * | 2020-06-05 | 2020-10-13 | 苏州浪潮智能科技有限公司 | 一种改进的双向snmp告警方法及装置 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1741461A (zh) * | 2004-08-23 | 2006-03-01 | 华为技术有限公司 | 在网管系统中处理设备信息的方法及系统 |
CN1893424A (zh) * | 2005-07-08 | 2007-01-10 | 中兴通讯股份有限公司 | 一种snmp协议下采用确认机制实现告警管理的方法 |
CN101076028A (zh) * | 2007-06-21 | 2007-11-21 | 中兴通讯股份有限公司 | 采用snmp协议的通信系统和消息交互方法 |
-
2008
- 2008-01-16 CN CN2008100011301A patent/CN101217403B/zh not_active Expired - Fee Related
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1741461A (zh) * | 2004-08-23 | 2006-03-01 | 华为技术有限公司 | 在网管系统中处理设备信息的方法及系统 |
CN1893424A (zh) * | 2005-07-08 | 2007-01-10 | 中兴通讯股份有限公司 | 一种snmp协议下采用确认机制实现告警管理的方法 |
CN101076028A (zh) * | 2007-06-21 | 2007-11-21 | 中兴通讯股份有限公司 | 采用snmp协议的通信系统和消息交互方法 |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103812690A (zh) * | 2013-08-06 | 2014-05-21 | 国家电网公司 | 一种设备归一化管理接口的故障诊断信息传送及处理方法 |
CN103812690B (zh) * | 2013-08-06 | 2017-02-22 | 国家电网公司 | 一种设备归一化管理接口的故障诊断信息传送及处理方法 |
Also Published As
Publication number | Publication date |
---|---|
CN101217403A (zh) | 2008-07-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101217403B (zh) | 一种基于简单网络管理协议的告警实现方法 | |
EP2166699B1 (en) | A method and system for sending the event notices based on netconf | |
Case et al. | Management information base for version 2 of the simple network management protocol (snmpv2) | |
KR100748701B1 (ko) | Snmp를 사용하는 네트워크 장비 관리 시스템 및 그방법 | |
Levi et al. | Simple network management protocol (SNMP) applications | |
US20060168263A1 (en) | Monitoring telecommunication network elements | |
CN110311799B (zh) | 一种通信方法及装置 | |
US8392548B1 (en) | Method and apparatus for generating diagnostic information for errors detected in a network management protocol | |
Levi et al. | SNMPv3 Applications | |
CN101076028B (zh) | 采用snmp协议的通信系统和消息交互方法 | |
Levi et al. | SNMP applications | |
CN101668014B (zh) | 制造网格服务中心与资源节点的通信方法 | |
CN101267335B (zh) | 一种保证简单网络管理协议告警成功收发的方法 | |
US8051155B2 (en) | Method and apparatus for persisting SNMP variable values | |
CN100512305C (zh) | 一种进程发送方法 | |
US8055746B2 (en) | Method and system for improved management of a communication network by extending the simple network management protocol | |
CN100502308C (zh) | 一种网管接口的文件准备通知重发的方法 | |
WO2016191180A1 (en) | Local object instance discovery for metric collection on network elements | |
WO2016202025A1 (zh) | 陷阱Trap报文处理方法及装置 | |
WO2015194931A1 (en) | A system and method for detecting and recovering lost simple network management protocol traps | |
CN105721213A (zh) | 一种网络管理告警同步实现的方法及系统 | |
Chisholm et al. | Alarm Management Information Base (MIB) | |
Case et al. | RFC1905: Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) | |
Aitken et al. | Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol | |
Chisholm et al. | RFC 3877: Alarm Management Information Base (MIB) |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20100929 Termination date: 20180116 |
|
CF01 | Termination of patent right due to non-payment of annual fee |