CN114244682A

CN114244682A - 一种设备告警丢失补漏方法及装置

Info

Publication number: CN114244682A
Application number: CN202111385519.2A
Authority: CN
Inventors: 薛竹
Original assignee: Unihub China Information Technology Co Ltd
Current assignee: Unihub China Information Technology Co Ltd
Priority date: 2021-11-22
Filing date: 2021-11-22
Publication date: 2022-03-25
Anticipated expiration: 2041-11-22
Also published as: CN114244682B

Abstract

本发明公开一种设备告警丢失补漏方法及装置，其中，该方法包括：设定关键告警类型，主动对设备进行检查并筛查告警；定时主动到网络设备上轮询历史告警信息；打通设备专业网管，与北向TL1接口获取的告警信息进行比对。本发明提出的设备告警丢失补漏方法及装置，能彻底规避告警信息传送协议的先天劣势，使告警可靠性成为可能；本发明变被动为主动，多种手段完成告警补漏，最大限度保证告警的完整性；一次比对，多点数据补全，效率高；补漏机制可重复多次进行，容错性好。

Description

一种设备告警丢失补漏方法及装置

技术领域

本发明涉及网络故障领域，尤其是一种设备告警丢失补漏方法及装置。

背景技术

告警处理及时率，是对网络运维人员考核的主要KPI。正常情况，当网络设备产生故障时，设备会以SYSLOG、TRAP方式发出告警，网络运维人员根据告警信息进行故障处理，当故障处理完毕后，进行告警恢复确认，形成故障处理闭环。但实际情况，由于SYSLOG、TRAP消息是以UDP协议来发送的，UDP是不可靠传输，进行数据传递时，会有数据包丢失的情况发生。即会产生告警丢失的情况，设备发出SYSLOG、TRAP告警，传送过程中丢失了，***没有收到。告警平台自然无法对告警进行呈现和推送。运维人员没有看到告警信息也不会处理告警故障，告警故障问题长时间得不到解决，影响客户满意度，同时告警处理及时率也会大幅降低，对运维人员考核有失公允。而且，设备发过告警后，相同告警不会再进行重发，告警一旦丢失，就彻底丢掉了，这一问题对网络运维人员造成较大困扰。

网络设备出现故障时，设备会主动发出告警，只支持SYSLOG和TRAP两种协议，但这两种协议都是不可靠传输，有丢失的可能，导致运维人员无法收到，故障也无法得到处理，对客户造成影响，直接造成经济损失，对网络运维人员来说，故障处理及时率低，也会影响考核。所以告警补漏是一个非常迫切的需求。

发明内容

为解决现有技术存在的上述问题，本发明提供一种设备告警丢失补漏方法及装置，主动对丢失告警进行补漏，找到丢失的告警，生成正式的告警信息，从而对告警故障进行处理。

为实现上述目的，本发明采用下述技术方案：

在本发明一实施例中，提出了一种设备告警丢失补漏方法，该方法包括：

S01、设定关键告警类型，主动对设备进行检查并筛查告警；

S02、定时主动到网络设备上轮询历史告警信息；

S03、打通设备专业网管，与北向TL1接口获取的告警信息进行比对。

进一步地，所述S01中的告警类型包括但不限于：设备脱网告警、端口DOWN告警、链路中断告警。

进一步地，所述S01包括：

S011、主动对设备进行检查，并筛查告警；

S012、与告警平台已获取到的告警信息进行比对；

S013、告警平台未收到新检查出的告警信息，将检查出的告警信息生成syslog消息并发送。

进一步地，所述S02包括：

S021、针对S01设定的告警类型判断是否存在这些告警；

S022、与告警平台已获取到的告警信息进行比对；

S023、告警平台未收到新检查出的告警信息，则将检查出的告警信息生成syslog消息并发送。

进一步地，所述S03包括：

S031、结合专业网管北向TL1接口收集告警信息，与北向TL1接口获取的告警进行比对；

S032、告警平台与北向TL1接口获取的告警信息不一致，查缺补漏，将比对出的遗漏告警信息生成syslog消息并发送。

进一步地，所述S03中告警信息通过TL1接口订阅专业网管告警信息。

进一步地，所述S03中告警信息通过TL1接口，获取设备实时告警信息。

在本发明一实施例中，还提出了一种设备告警丢失补漏装置，该装置包括：

设定与筛查模块、设定关键告警类型，主动对设备进行检查并筛查告警；

主动轮询模块、定时主动到网络设备上轮询历史告警信息；

对比模块、打通设备专业网管，与北向TL1接口获取的告警信息进行比对。

在本发明一实施例中，还提出了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现前述设备告警丢失补漏方法。

在本发明一实施例中，还提出了一种计算机可读存储介质，计算机可读存储介质存储有执行设备告警丢失补漏方法的计算机程序。

有益效果：

本发明彻底规避告警信息传送协议的先天劣势，使告警可靠性成为可能；本发明变被动为主动，多种手段完成告警补漏，最大限度保证告警的完整性；一次比对，多点数据补全，效率高；补漏机制可重复多次进行，容错性好。

附图说明

图1是本发明的设备告警丢失补漏方法流程示意图；

图2是实施例一设备脱网告警的示意图；

图3是告警信息传送给告警平台的示意图；

图4是本发明一实施例的设备告警丢失补漏装置结构示意图；

图5是本发明一实施例的计算机设备结构示意图。

具体实施方式

下面将参考若干示例性实施方式来描述本发明的原理和精神，应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本发明，而并非以任何方式限制本发明的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本发明的实施方式可以实现为一种***、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

本发明涉及的名词及其解释：

KPI：Key Performance Indicator关键绩效指标；

Trap：一种Linux命令，可以查看shell环境信号和设置信号的处理方式；

shell：计算机壳层；

UDP：User Datagram Protocol，Internet协议集支持一个无连接的传输协议，该协议称为用户数据包协议，UDP为应用程序提供了一种无需建立连接就可以发送封装的IP数据包的方法；

TL1：Transaction Language-1，交互语言-1，它是一个基于字符的管理协议，TL1作为网络设备和网络管理程序间的基本接口。

根据本发明的实施方式，提出了一种设备告警丢失补漏方法及装置，主动对丢失告警进行补漏，找到丢失的告警，生成正式的告警信息，从而对告警故障进行处理。

下面参考本发明的若干代表性实施方式，详细阐释本发明的原理和精神。

图1是本发明一实施例的设备告警丢失补漏方法流程示意图。如图1所示，该方法包括：

S01、设定关键告警类型，主动对设备进行检查并筛查告警；

S02、定时主动到网络设备上轮询历史告警信息；

所述S01中的告警类型包括但不限于：设备脱网告警、端口DOWN告警、链路中断告警。

所述S01包括：

S011、主动对设备进行检查，并筛查告警；

S012、与告警平台已获取到的告警信息进行比对；

所述S02包括：

S021、针对S01设定的告警类型判断是否存在这些告警；

S022、与告警平台已获取到的告警信息进行比对；

所述S03包括：

所述S03中告警信息通过TL1接口订阅专业网管告警信息。

所述S03中告警信息通过TL1接口，获取设备实时告警信息。

需要说明的是，尽管在上述实施例及附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

为了对上述设备告警丢失补漏方法进行更为清楚的解释，下面结合具体的实施例来进行说明，然而值得注意的是该实施例仅是为了更好地说明本发明，并不构成对本发明不当的限定。

实施例一：

如图2所示，以设备脱网告警为例，包括：

将检测的设备IP地址存成文件。解析每个设备IP，作为入参循环调用。根据传入的IP地址创建进程。

加载配置的Ping不通尝试次数配置信息(若Ping不通，尝试再进行几次Ping测)

对设备IP分别进行Ping测，若Ping不通，根据配置的Ping不通尝试次数进行再测试。将测试结果写入PingResult文件。Ping通记录up，Ping不通记录down，若原Ping不通，现可以Ping通，记录变化状态。

Ping测试方法：

Ping通：

$ping 4.122.110.254

PING 4.122.110.254(4.122.110.254)56(84)bytes of data.

64 bytes from 4.122.110.254:icmp_seq＝1 ttl＝55 time＝6.95 ms

64 bytes from 4.122.110.254:icmp_seq＝2 ttl＝55 time＝6.89 ms

64 bytes from 4.122.110.254:icmp_seq＝3 ttl＝55 time＝6.43 ms

64 bytes from 4.122.110.254:icmp_seq＝4 ttl＝55 time＝6.75 ms

64 bytes from 4.122.110.254:icmp_seq＝5 ttl＝55 time＝7.02 ms

64 bytes from 4.122.110.254:icmp_seq＝6 ttl＝55 time＝7.50 ms

---4.122.110.254 ping statistics---

6 packets transmitted,6 received,0％packet loss,time 5427ms

rtt min/avg/max/mdev＝6.431/6.926/7.506/0.339 ms

Ping不通：

$ping 4.123.110.254

PING 4.123.110.254(4.123.110.254)56(84)bytes of data.

---4.123.110.254ping statistics---

3 packets transmitted,0 received,100％packet loss,time 2586ms

读取PingResult文件，与告警平台已获取到的告警信息进行比对，若告警平台没收到新检查出的告警信息，则将检查出的告警信息生成syslog消息并发送。

不通:

ITE-DevMoni DevConnectFailed:设备名称(设备IP)ping failed with ping次数packets each ping大小KB at当前时间

不通到通(告警恢复):

ITE-DevMoni DevConnectSucceed:设备名称(设备IP)ping succeed with ping次数packets each ping大小KB at当前时间。

实施例二：

以端口Down告警为例

每个进程对分配的设备，进行端口流入流量、流出流量、管理状态和协议状态采集，对端口IP及其对端IP进行ping操作。

根据断点状态判断，只处理管理状态为up的物理端口

如果内存数据库中没有设备端口对应记录，将当前端口协议状态采集结果保存到内存数据库中，portDescr＝端口名称，preValue＝当前协议状态采集结果，preTime＝当前采集时间

当前协议状态采集结果为up，如果流量不为0，则端口状态为1；如果流量为0，则查看双端IP的ping测试结果，通则端口状态为1，不通端口状态为0，更新内存数据库表portstatus，preValue＝当前协议状态采集结果，preTime＝当前采集时间，preStatus＝1，与前次端口状态为不同时，changeTime＝当前采集时间，相同时，changeTime不变。

如果前次协议状态是up，本次采集为down，更新内存数据库，preValue＝当前采集结果，preTime＝当前采集时间

如果前次协议状态和本次采集结果都为down，则记录该端口到M中。M就是一个标识位，Mark，做个标记。前次协议状态和本次采集结果都为down，打个标记M。

全部物理端口状态判断完毕。对M中的物理端口判断，先判断相应逻辑端口的协议状态，如果有一个逻辑端口为up的情况，则物理端口状态为1，如果没有up的逻辑端口，则与前次采集的流入流出流量作差，任一方向流量大于0，说明采集正常，端口状态为1，否则端口状态为0。将当前采集结果和端口状态保存到内存数据库表中。

同时将本次采集的流量计数器数值保存到端口对应的内存数据库中。

如果状态发生变化，生成syslog，并发送。

syslog格式：

PortStatusAlarm:DeviceID＝设备ID；；PortIndex＝端口索引；；PortName＝端口名称；；PortStatusPre＝端口状态

(up|down)；；PortStatusCur＝端口状态

(up|down)；；StartTime＝yyyymmddhh24miss；；Detail＝端口状态发生变化

实施例三：

S02、定时主动到网络设备上进行轮询历史告警信息，针对设定的告警类型判断是否存在这些告警。

历史告警检查

<～>dis alarm history

A/B/C/D/E/F/G/H/I/J

A＝Sequence,

B＝RootKindFlag(Independent|RootCause|nonRootCause)

C＝Generating time,D＝Clearing time

E＝ID,F＝Name,G＝Level,H＝State

I＝Description information for locating(Para info,Reason info)

J＝RootCause alarm sequence(Only for nonRootCause alarm)

39/Independent/2021-09-1400:17:39+08:00/2021-09-14 08:45:19+08:00/0xff15204e/hwPortDown/Major/End/OID 1.3.6.1.4.1.2011.5.25.219.2.12.1 Thephysical status of the port changed to Down.(EntityPhysicalIndex＝16777729,

EntityPhysicalIndex＝16777729,

EntPhysicalName＝"GigabitEthernet0/1/0",

EntityTrapFaultID＝144384,hwPortDownReason＝"LOS")

38/Independent/2021-09-14 00:17:36+08:00/2021-09-14 08:45:27+08:00/0x70172000/ospfIfStateChange/Major/End/OID 1.3.6.1.2.1.14.16.2.16:The statusof the non-virtual interface changes.(IfIpAddress＝0.0.0.0,AddressLessIf＝26,ProcessId＝65534,AreaId＝0.0.0.0,IfnetIndex＝26,ProcessId＝65534,RouterId＝4.123.132.23,IfState＝1,IfName＝DCN-Serial0/1/0:0,InstanceName＝__dcn_vpn__,IfChgReason＝2)

......

hwPortDown：端口Down

ospfIfStateChange:OSPF非虚连接接口状态发生变化

与告警平台已获取到的告警信息进行比对，若告警平台没收到新检查出的告警信息，则将检查出的告警信息生成syslog消息并发送。

syslog格式：

(up|down)；；PortStatusCur＝端口状态

S03：打通设备专业网管，结合专业网管北向TL1接口收集告警信息，与北向TL1接口获取的告警进行比对，若告警平台与北向TL1接口获取的告警信息不一致，查缺补漏，将比对出的遗漏告警信息生成syslog消息并发送。

如图3所示，设备通过专业网管TL1接口将告警信息传送给告警平台，由于不是设备直接对接告警平台，而是设备->专业网管->告警平台，中间要透过专业网管，所以告警上报有延时问题，即告警上报的及时性不高，所以一般不采用这种方式进行告警上报。但是告警准确性比较高，所以可以拿它作为查缺补漏的手段。

方式1：通过TL1接口订阅专业网管告警信息，若出现告警号不连续情况，即存在丢失情况，进行重采。告警平台与专业网管告警信息进行比对，若不一致，查缺补漏，将比对出的遗漏告警信息生成syslog消息并发送。

方式2：通过TL1接口，获取设备实时告警信息。

将检测的设备IP地址存成文件。解析每个设备IP，作为入参循环调用TL1接口。

根据设备IP找到对应设备厂商，根据设备厂商找到对应设备厂商的TL1接口。

获取实时告警。

实施例四：

以设备厂商A为例：

输入LST-ALARM::OLTID＝设备IP:CTAG::；

查找IP为“设备IP”的告警信息进行返回，内容如下：

LYTBN_192.168.120.222 2021-10-14 11:27:34

M CTAG COMPLD

EN＝0 ENDESC＝No Error

total_blocks＝1

block_number＝1

block_records＝2

list of Device Alarm info

SERIALID ALARMNAME DIP DNAME POSITION SEVERITY FaultFlag HAPPENTIMERECOVERTIME ALARMTYPE

--盖子开关 10.68.37.112

LTRAN-TBF1000(10.68.37.112)分组 Fault 2021/10/14 10:50:25--EquipmentAlarm

--+10V 10.68.37.112

LTRAN-TBF1000(10.68.37.112)分组 Fault 2021/10/14 10:50:25--EquipmentAlarm

其中ALARMNAME代表告警内容，DNAME代表设备别名，POSITION代表设备所属分组，HAPPENTIME代表发生时间。

如果该IP对应设备没有告警，则会返回如下信息：

LST-ALARM::OLTID＝1.1.1.1:CTAG::；

LYTBN_192.168.120.222 2021-10-14 11:31:26

M CTAG COMPLD

EN＝O ENDESC＝No Error

total_b1ocks＝1

b1ock_number＝1

b1ock_records＝O

list of Device Alarm info

告警平台与专业网管告警信息进行比对，若不一致，查缺补漏，将比对出的遗漏告警信息生成syslog消息并发送。

基于同一发明构思，本发明还提出一种设备告警丢失补漏装置。该装置的实施可以参见上述方法的实施，重复之处不再赘述。以下所使用的术语“模块”，可以是实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图4是本发明一实施例的设备告警丢失补漏装置结构示意图。如图4所示，该装置包括：

设定与筛查模块101、设定关键告警类型，主动对设备进行检查并筛查告警；

主动轮询模块102、定时主动到网络设备上轮询历史告警信息；

对比模块103、打通设备专业网管，与北向TL1接口获取的告警信息进行比对。

应当注意，尽管在上文详细描述中提及了设备告警丢失补漏装置的若干模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多模块的特征和功能可以在一个模块中具体化。反之，上文描述的一个模块的特征和功能可以进一步划分为由多个模块来具体化。

基于前述发明构思，如图5所示，本发明还提出一种计算机设备200，包括存储器210、处理器220及存储在存储器210上并可在处理器220上运行的计算机程序230，处理器220执行计算机程序230时实现前述设备告警丢失补漏方法。

基于前述发明构思，本发明还提出一种计算机可读存储介质，计算机可读存储介质存储有执行前述设备告警丢失补漏方法的计算机程序。

本发明提出的设备告警丢失补漏方法及装置，能彻底规避告警信息传送协议的先天劣势，使告警可靠性成为可能；本发明变被动为主动，多种手段完成告警补漏，最大限度保证告警的完整性；一次比对，多点数据补全，效率高；补漏机制可重复多次进行，容错性好。

虽然已经参考若干具体实施方式描述了本发明的精神和原理，但是应该理解，本发明并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本发明旨在涵盖所附权利要求的精神和范围内所包含的各种修改和等同布置。

对本发明保护范围的限制，所属领域技术人员应该明白，在本发明的技术方案的基础上，本领域技术人员不需要付出创造性劳动即可做出的各种修改或变形仍在本发明的保护范围以内。

Claims

1.一种设备告警丢失补漏方法，其特征在于，该方法包括：

S01、设定关键告警类型，主动对设备进行检查并筛查告警；

S02、定时主动到网络设备上轮询历史告警信息；

2.根据权利要求1所述的设备告警丢失补漏方法，其特征在于，所述S01中的告警类型包括但不限于：设备脱网告警、端口DOWN告警、链路中断告警。

3.根据权利要求1所述的设备告警丢失补漏方法，其特征在于，所述S01包括：

S011、主动对设备进行检查，并筛查告警；

S012、与告警平台已获取到的告警信息进行比对；

4.根据权利要求1所述的设备告警丢失补漏方法，其特征在于，所述S02包括：

S021、针对S01设定的告警类型判断是否存在这些告警；

S022、与告警平台已获取到的告警信息进行比对；

5.根据权利要求1所述的设备告警丢失补漏方法，其特征在于，所述S03包括：

6.根据权利要求1所述的设备告警丢失补漏方法，其特征在于，所述S03中告警信息通过TL1接口订阅专业网管告警信息。

7.根据权利要求1所述的设备告警丢失补漏方法，其特征在于，所述S03中告警信息通过TL1接口，获取设备实时告警信息。

8.一种设备告警丢失补漏装置，其特征在于，该装置包括：

主动轮询模块、定时主动到网络设备上轮询历史告警信息；

9.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1-7所述方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有执行权利要求1-7所述方法的计算机程序。