一种基于SNMP的告警同步方法
技术领域
本发明涉及网络通信技术领域,尤其涉及一种基于SNMP协议的网络管理系统中的一种告警同步方法。
背景技术
简单网络管理协议(SNMP,simple Network Management Protocol)是基于TCP/IP的互联网网络管理的标准协议。利用SNMP,可以收集远程设备上的管理数据和配置远程设备,实现对远程设备的综合统一管理。由于其实现简单、管理方式简洁高效,目前已经得到了众多网络设备制造商的支持和极为广泛的应用。SNMP的管理模型如图1所示,网管站(NMS)101对被管设备102发送各种查询(Request)报文,并接收来自被管设备102的响应(Response)及告警(Trap)报文,将结果显示出来。代理(AGENT)是驻留在被管设备102上的一个进程,负责接收、处理来自网管站101的请求报文,然后从设备上其他协议模块中取得管理变量的数值,形成响应报文,反送给网管站101。当被管设备发生特殊事件时,如接口状态发生改变,设备断电等,代理会主动通知网管站101(发送告警报文)。
告警报文(Trap PDU)的格式随着SNMP协议的扩展而不断的发展。如图2所示为SNMP V1-Trap PDU,其中第一个部分十六进制值0xA4指示该SNMPPDU是一个Trap,第二部分ent是生成该Trap的设备sysObjectID,第三部分addr是生成该Trap的设备IP地址,第四、第五部分分别存放通用告警(generic-trap)和企业私有告警(specific-trap),第六部分ts是该trap生成时设备的运行时间(sysUpTime),最后一部分变量绑定提供了该Trap的附加信息。SNMP协议发展到V2版本后,SNMP V2-Trap PDU的格式如图3所示,0xA4指示该SNMP PDU是一个SNMP V2 Trap,reqid为请求标识符,其他信息均被嵌入变量绑定中,第一个变量提供了设备的运行时间(sysUpTime),第二个变量提供了该Trap的类型,其他的变量在此基础上添加。
SNMP Trap虽然可以用来通知可能的灾难性事件,但是其基于不可靠传输协议UDP的本质决定了SNMP Trap本身也是不可靠的,因此SNMP V2扩展了一种报文InformRequest,其实质为一个需要得到响应的SNMP V2 Trap,有了InformRequest,代理可以在没有收到响应时尝试重复发送消息,在一定程度上提高了Trap传输的可靠性。但是尽管如此,使用InformRequest需要付出一定代价,即额外的网络负载以及发送设备更多的资源消耗,当由于网络拥塞而导致消息丢失时,重新发送只会导致网络拥塞的问题更加恶化。
发明内容
本发明要解决的技术问题是一种基于SNMP的告警同步方法,在节省网络带宽及设备资源的前提下,弥补告警传输不可靠的缺点,使网管站和被管设备上的告警达到同步,提高网络设备管理的可靠性。
为了解决上述技术问题,本发明提供了一种基于SNMP的告警同步方法,包括:
在网管站和被管设备上分别记录被管设备已产生的告警数量;
达到触发条件后,所述网管站接收被管设备上记录的告警数量,并与本地记录的告警数量比较,如果被管设备上记录的告警数量大于网管站记录的告警数量,所述网管站从所述被管设备上接收所述网管站未接收过的告警。
进一步地,所述触发条件为:
设置一个定时器,并预设一个同步周期,所述定时器到达预设同步周期时,达到触发条件。
进一步地,同步过程完成后,重置所述定时器。
进一步地,所述触发条件为:
设定一个延迟时间,所述网管站收到告警时,经过所述延迟时间未收到新告警,达到触发条件。
进一步地,在所述网管站和被管设备上记录产生的告警数量的方法是:
在被管设备上设置第一变量,并赋值为0,当被管设备产生告警时,被管设备保存告警报文信息,并为所述告警报文以递增的顺序编号,并将所述第一变量值加1;
在所述网管站上设置第二变量,并赋值为0,所述网管站每接收到所述被管设备的一条告警,网管站保存该告警报文信息,并将所述第二变量的值加1。
进一步地,在所述被管设备上设置第一时间变量,用于记录被管设备从最近一次开机算起的运行时间;
在所述网管站上设置第二时间变量和第三时间变量,分别用于记录某一时刻网管站的本地绝对时间及被管设备运行时间;
在所述网管站上设置第四时间变量和第五时间变量,分别用于保存上一次成功同步的最后一条告警报文中的时间信息和所述网管站收到的最后一条告警报文中的时间信息;
在所述网管站上设置第三变量,用于记录所述被管设备上保存的告警报文中时间信息大于第四时间变量记录的时间信息的最早一条告警的记录编号;
所述网管站从所述被管设备上接收所述网管站未接收过的告警的方法为:
所述网管站向所述被管设备取回告警报文中时间信息等于第四时间变量记录的时间信息的最后一条告警的记录编号存入第三变量;
所述网管站判断第三变量是否为空,如果第三变量不为空,所述网管站向被管设备取回记录编号为第三变量加1的历史告警报文;
所述网管站在保存的未同步告警中通过比较告警报文参数查找与所述取回告警报文匹配的告警信息,如果未找到匹配的告警信息,网管站加入该告警。
进一步地,当发生下列条件之一时,所述网管站向被管设备取回被管设备上第一时间变量的值存入第三时间变量,同时将此时的绝对时间记入第二时间变量:
新加入被管设备;
已管理的被管设备由断开变为连通状态;
被管设备告警报文中的运行时间被重置;
设备轮询时。
进一步地,所述网管站收到新告警时,将收到告警报文中的时间信息存入第三时间变量,同时将此时的绝对时间记入第二时间变量。
进一步地,所述网管站判断第三变量为空时,更新第二时间变量及第三时间变量,然后向被管设备取回被管设备上最早的历史告警报文的记录编号减1存入第三变量,再次判断第三变量是否为空,如果否,执行所述取回历史告警报文的步骤,否则结束同步过程。
进一步地,如果所述网管站查找到与取回告警报文匹配的告警信息,则将所述第三变量的值加1,再次执行所述取回历史告警报文的步骤。
本发明的基于SNMP的告警同步方法,通过找到在被管设备端记录中存在而网管站记录中不存在的告警信息而实现同步,不依赖设备时钟,被管设备的负担小且易于实现;同步时机灵活、对网络带宽要求不高;网管站被动收告警与主动查询比较相结合,保证了所有告警的同步,同步准确率高。
附图说明
图1是一种基于SNMP的网络管理的模型图;
图2是SNMP V1-Trap PDU格式的构成图;
图3是SNMP V2-Trap PDU格式的构成图;
图4是本发明的告警同步的方法流程图;
图5是一个典型的基于SNMP的网络管理系统框图。
具体实施方式
下面结合附图和具体实施例对本发明作进一步说明,以使本领域的技术人员可以更好的理解本发明并能予以实施,但所举实施例不作为对本发明的限定。
本发明的核心在于找到AGENT端(被管设备)的历史记录中存在而NMS端(网管站)记录中不存在的告警信息,技术方案包括AGENT端和NMS端的变量设置及NMS端告警同步过程。
其中,AGENT端变量设置:
设置第一变量remoteTrapCount,用于记录设备已产生Trap的数量。设备产生Trap的同时,在设备上保存该Trap完整的报文信息,并以递增的记录编号加以标识,并将remoteTrapCount加1。
设置第一时间变量sysRunTime,用于记录被管设备从最近一次开机算起的运行时间。
NMS端变量设置:
设置第二时间变量localTime和第三时间变量remoteTime,分别用于记录某一时刻NMS的本地绝对时间及AGENT设备的运行时间,作为推算NMS漏收告警发生绝对时间的依据。当新加入被管设备或已管理的被管设备由断开变为连通状态或者AGENT告警报文中的sysUpTime被重置或者设备轮询时,NMS向AGENT取sysRunTime的值存入remoteTime,同时将此时的本地绝对时间记入localTime。当收到新告警时,将收到告警报文中的sysUpTime值存入remoteTime,同时将此时的本地绝对时间记入localTime。
设置第二变量localTrapCount,用于记录NMS端收到告警的数量,每收到一条告警localTrapCount加1。
设置第四时间变量lastSynSysUpTime和第五时间变量localLatestSysUpTime,分别用于保存上一次成功同步的最后一条告警的sysUpTime和NMS端收到的最后一条告警的sysUpTime。
设置第三变量index,用于记录AGENT上sysUpTime>lastSynSysUpTime的最早一条告警的记录编号;
设置定时器,用于定时执行同步过程。
在NMS端保存所有收到告警的完整报文信息及收到告警时的本地绝对时间。
告警同步过程在NMS端执行,包括:收到告警同步和定时同步。
收到告警同步:在NMS端,当收到设备告警后一段时间内无新告警,则开始同步过程,流程图如图4所示,其步骤为:
步骤401:NMS向AGENT取remoteTrapCount的值;
步骤402:比较remoteTrapCount与localTrapCount的值,若rcmoteTrapCount>localTrapCount则说明NMS端有告警没有收到,执行步骤403;否则结束同步过程;
步骤403:NMS向AGENT取回sysUpTime=lastSynSysUpTime的最后一条告警的记录编号存入index;
步骤404:判断index是否为空,如果index为空,则说明由于设备重启或其他原因,AGENT端告警报文的sysUpTime被重置,此时执行步骤405;否则执行步骤407;
步骤405:更新localTime及remoteTime,然后向AGENT取回最早的历史告警报文的记录编号减1存入index;
步骤406:再次判断index是否为空,如果否,执行步骤407;否则结束同步过程;
步骤407:依据index向AGENT发送SNMPGetNext请求,取回记录编号为index+1的历史告警报文;
步骤408:判断是否成功取回告警报文,如果是,执行步骤409;否则同步过程结束;
步骤409:在本地保存的未同步告警中通过比较sysUpTime、告警类型和变量绑定查找匹配的告警信息;
步骤410:判断是否找到匹配的告警,如果找到,执行步骤411;如果未找到,执行步骤412;
步骤411:将index加1后返回步骤407;
步骤412:依据从AGENT取回的报文信息在NMS本地加入该告警,该告警发生的本地绝对时间则根据localTime+该告警的sysUpTime-remoteTime得到,将lastSynSysUpTime的值存入localLatestSysUpTime,同时将定时同步的时间推迟一段时间。
定时同步:在NMS端设定一个固定的时间周期,每个周期同步一次,同步过程同收到告警同步。定时同步结束后,将定时器重置。
本发明以将AGENT端的所有告警均同步到NMS端为目的,基于标准的传输协议(适用于SNMP V1,SNMP V2,SNMP V3),不依赖设备时钟(采用标准协议中的sysUpTime推算设备绝对时钟,设备时钟不必准确),AGENT负担小且易于实现,同步时机灵活、对网络带宽要求不高(对不同的管理设备执行同步的时间分散,即使对同一台设备也是收到告警时同步和定时同步相结合,不会造成网络拥塞),同步准确率高(NMS被动收告警与主动查询比较相结合,保证了所有告警的同步)。
如图5所示,是一个典型的基于SNMP的网络管理系统,在这个系统中,各被管理设备上的告警服务器地址(TrapServer)均指向网管服务器,所有设备上发生的告警均会发送到网管服务器并在设备上留下历史记录,其中包括历史记录编号、告警类型、sysUpTime、变量绑定。网管服务器会存储收到的每一条告警,其中包括告警设备、告警发生本地绝对时间、告警类型、sysUpTime,变量绑定。通过比较每个设备上存储告警和网管服务器上存储告警的告警类型、sysUpTime、变量绑定即可找到网管服务器漏收的告警,从而达到告警同步的目的。那么比较的时机和比较的具体方法就显的尤为重要,因为时机不当会增加网络负担,比较方法不当会增加设备负担。
当服务器S收到设备1的告警后,如果1分钟内再未收到设备1的告警,则开始同步过程,即服务器S向设备1发出SNMPGet请求,取回设备当前已产生告警数量,与本地记录的设备1的告警数量进行比较,如果本地数量小于取回数量,则向设备1发出SNMPGetNext请求,逐条取回所有sysUpTime不小于本地最早未同步的设备1的告警sysUpTime的告警信息,并逐一与本地记录的设备1的未同步告警比较告警类型、sysUpTime及变量绑定,找出漏收告警,从而保证在每次收到告警时所有告警均已同步。
为了保证在未收到告警时所有告警也是同步的,在每次设备轮询的时候也执行上述同步过程。如果在上一次设备轮询后收到过设备1的告警,则此次轮询将不对设备1执行同步过程。这样进一步保证了同步的准确性、及时性和科学性。
服务器S收到其他设备告警后的处理与此相同,对不同设备告警的同步互不干扰,异步进行。
以上所述实施例仅是为充分说明本发明而所举的较佳的实施例,本发明的保护范围不限于此。本技术领域的技术人员在本发明基础上所作的等同替代或变换,均在本发明的保护范围之内。本发明的保护范围以权利要求书为准。