CN103595569A - 一种网络管理系统中的告警信息入库的处理方法 - Google Patents
一种网络管理系统中的告警信息入库的处理方法 Download PDFInfo
- Publication number
- CN103595569A CN103595569A CN201310578377.0A CN201310578377A CN103595569A CN 103595569 A CN103595569 A CN 103595569A CN 201310578377 A CN201310578377 A CN 201310578377A CN 103595569 A CN103595569 A CN 103595569A
- Authority
- CN
- China
- Prior art keywords
- bloomfilter
- warning information
- network management
- alarm
- managed object
- 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.)
- Pending
Links
Images
Abstract
本发明公开了一种网络管理系统中的告警信息入库的处理方法,包括如下步骤:S1、将被管理对象的当前告警信息通过hash方式映射到Bloomfilter数据结构;S2、网络管理服务器收到一条Trap报文后,对报文进行解析,并对Bloomfilter进行存在性判定,如果判定该报文携带的告警信息为新告警,则将此告警信息通过hash算法映射到对应的Bloomfilter中进行记录,并将该告警信息存入当前告警数据库;如果判定该报文携带的告警信息已经存在,更新当前告警数据库中的对应记录。本发明对网管系统中告警信息入库流程做出优化,减少了对数据库的操作,提高了系统的运行速度。
Description
技术领域
本发明涉及一种网络管理系统中的告警信息入库的处理方法,更具体涉及,一种基于Bloomfilter算法的网络管理系统中的告警信息入库的处理方法,属于计算机数据处理技术领域。
背景技术
随着社会信息化程度的增加,人们对于网络运行安全可靠的要求越来越高,网络管理系统作为保障网络高效正常运行的应用系统,越来越受到人们的重视。网络管理系统一般采用管理者-代理模型,如图1所示,该模型主要包括数据库1、管理者2、管理者代理3和被管理对象4,他们之间使用SNMP协议交换信息。
SNMP管理的实质是对管理信息进行相应的读写操作,SNMP协议定义了五种操作命令,分别是GetRequest、GetNextRequest、SetRequest、GetResponse和Trap,而操作的对象是管理信息。为了实现统一管理,将管理信息的集合定义为管理信息库,比如IETF定义的管理信息库MIB-Ⅱ,以及各种私有MIB库。MIB库是一个树形结构的信息库,每个管理信息都是管理信息树的一个节点,用唯一的对象标识码(OID)来代表。
故障管理负责采集、分析和响应Trap报文中所携带的告警信息,是网络管理最重要的功能。被管理对象会周期地检查自身状态,如果发现故障或异常,就通过Trap报文向网管服务器上报告警信息。如果该故障或异常长时间未恢复,就会造成告警信息的重复上报,被称为重复告警。收到告警信息后,服务器会将告警信息存入当前告警数据库中;当故障或异常恢复后,被管理对象会上报告警清除信息,服务器会将之前的告警信息由当前告警数据库移动到历史告警数据库中,用于日后对告警历史数据的查看以及被管理对象历史性能的分析。在这个过程中,服务器收到告警信息后,需要查询当前告警数据库,判断告警信息是新生成的还是重复告警。对于新生成的告警信息,服务器会将其存入当前告警数据库;对于重复告警,服务器会对当前告警数据库中的对应告警信息记录进行更新,将其告警次数加1,并将其最近告警时间变更为最近一条告警信息的告警时间。
现有技术中,告警信息的入库流程图如图2所示,上述流程中,服务器每收到一条告警信息,都需要查询当前告警数据库,确认这条告警信息是不是重复告警,以此确定要对数据库进行插入操作还是更新操作。随着网管系统中被管理对象数量增多,以及每个被管理对象管理信息的增多,这种处理方式给系统数据库带来很大存取压力,成为系统响应时间的瓶颈,此问题亟待解决。
发明内容
本发明所要解决的技术问题是,克服现有技术的缺点,提供一种网络管理系统中的告警信息入库的处理方法,缓解系统数据库存取压力,加快响应时间。
为了解决以上技术问题,本发明提供一种网络管理系统中的告警信息入库的处理方法,包括网络管理服务器和与网络管理服务器双向通信连接的被管理对象和当前告警数据库,包括如下步骤:
S1、将被管理对象的当前告警信息通过hash方式映射到Bloomfilter数据结构,将被管理对象对应的标识ID和Bloomfilter配对后组成Map结构存储到网络管理服务器的内存中;
S2、网络管理服务器收到一条Trap报文后,对报文进行解析,提取报文中携带的被管理对象ID和告警信息,通过被管理对象ID在内存中提取对应的记录该被管理对象当前告警信息的Bloomfilter,对Bloomfilter进行存在性判定,如果判定该报文携带的告警信息为新告警,则将此告警信息通过hash算法映射到对应的Bloomfilter中进行记录,并将该告警信息存入当前告警数据库;如果判定该报文携带的告警信息已经存在,更新当前告警数据库中的对应记录。
本发明技术方案的进一步限定为,步骤S1中所述的Bloomfilter数据结构采用相同的长度和哈希函数的数量,确定长度和哈希函数数量的方法为:确定网络管理系统中具有最多告警信息种类的被管理对象A,其告警信息种类的数量为n,网络管理系统可容忍的判错率为ε,则Bloomfilter数据结构的长度m≥nlog2(1/ε),Bloomfilter数据结构的哈希函数数量k=ln2·(m/n)。
进一步地,步骤S1中将被管理对象的告警信息存储到内存中的方法为:系统启动时,从数据库中读取所有被管理对象的ID,根据被管理对象的ID在当前告警数据库中查询其所有当前告警信息,并通过hash算法将告警信息映射到此ID对应的Bloomfilter中;遍历所有读取出的被管理对象,得到每个被管理对象ID和其Bloomfilter的对应关系列表,将此列表存储到内存中。
进一步地,步骤S2中,对Bloomfilter进行存在性判定的方法为:通过hash方式对Trap报文中携带的告警信息进行处理,并将处理后的结果与此被管理对象对应的Bloomfilter中存储的信息进行对比,如果存在,则此告警信息为重复告警,如果不存在,则此告警信息为新告警。
进一步地,所述网络管理系统还包括历史告警数据库,当网络管理服务器接收到告警清除报文或者接收到告警清除指令后,会将对应告警信息从当前告警数据库移动到历史告警数据库,同时,删除此被管理对象对应的Bloomfilter中的此条信息。
进一步地,步骤S2中,如果判定该报文携带的告警信息已经存在,更新当前告警数据库中的对应记录后,如果网络管理服务器接收到当前告警数据库返回结果显示“更新记录条数为0”,则网络管理服务器修正对Bloomfilter进行存在性判定的结果,判定该报文携带的告警信息为新告警,则将该告警信息存入当前告警数据库,并将此告警信息通过hash算法映射到对应的Bloomfilter中进行记录。
进一步地,步骤S1及S2中所述的Bloomfilter为计数型Bloomfilter。
本发明的有益效果是:本发明公开的一种网络管理系统中的告警信息入库的处理方法,对网管系统中告警信息入库流程做出优化,将系统中被管理对象ID和记录其当前告警数据的Bloomfilter数据结构存储到内存中,减少了对数据库的操作,提高了系统的运行速度;本发明方法告警信息入库处理流程所需时间基本呈线性增长趋势,模拟在当前告警数据库中查询50条记录,此时需要的时间是53ms,而在系统内存中通过Bloomfilter状态判定50条告警信息是否存在所需时间为8ms,因此,针对一条告警信息,改进的处理流程比原始处理流程用时少0.9ms。
附图说明
图1为现有技术中网络管理系统采用的管理者-代理模型;
图2为现有技术中告警信息的入库的流程图;
图3为本发明提供的网络管理系统中的告警信息入库的处理方法的流程图;
图4为实施例1提供的被管理对象的当前告警信息以Bloomfilter数据结构存储的结构图;
图5为实施例1模拟的告警信息每分钟到达1个~200个的情况两种处理流程所需处理时间的曲线图。
具体实施方式
实施例1
本实施例提供的一种网络管理系统中的告警信息入库的处理方法,其流程图如图3所示,包括网络管理服务器和与网络管理服务器双向通信连接的被管理对象和当前告警数据库,包括如下步骤:
S1、将被管理对象的当前告警信息通过hash方式映射到Bloomfilter数据结构,将被管理对象对应的标识ID和Bloomfilter配对后组成Map结构存储到网络管理服务器的内存中。
Bloomfilter是用于判定有限集合中某些元素是否存在的一种数据结构。对于网络管理系统中的某个被管理对象,其所能上报的告警信息种类是有限的,由所使用的MIB库决定。因此,可以设计Bloomfilter数据结构记录此被管理对象已经发生的告警信息。通过这种方式,可以将系统中所有被管理对象的当前告警信息以Bloomfilter数据结构存储。
在Bloomfilter类型选择上,由于网管系统当前告警数据库中的记录是动态增删的,为了保证Bloomfilter中所记录的当前告警信息与当前告警数据库中的信息一致,需要选择具有增删功能的Bloomfilter,本专利选取计数型Bloomfilter(Counting Bloomfilter)记录系统中的当前告警信息。
Bloomfilter的最小长度以及所需哈希函数的最佳数量,依赖于有限集合的大小以及所能接收的判错率。在Bloomfilter长度和哈希函数数量的选择上,有两种可行方案:一种是对系统中所有被管理对象设定相同的Bloomfilter长度和相同数量的哈希函数,另一种是针对不同的被管理对象,根据其可能产生告警种类数量的不同,设定不同的Bloomfilter长度和不同数量的哈希函数。前一种方式实现简单,只需要找出系统中具有最多告警种类的被管理对象,并以其告警种类作为标准,决定Bloomfilter长度和哈希函数的数量,但是这种方式的信息冗余度较高;第二种方式针对每一个被管理对象告警信息种类数量不同,设定不同的Bloomfilter长度和不同数量的哈希函数,这种方式可以最大限度地压缩告警信息,但是需要对每一个被管理对象进行计算,过程繁琐,且不利于Bloomfilter的统一存储。基于以上考虑,本实施例采用第一种方式,对所有被管理对象的Bloomfilter采用相同长度及相同数量的哈希函数。
所述的Bloomfilter数据结构采用相同的长度和哈希函数的数量,确定长度和哈希函数数量的方法为:确定网络管理系统中具有最多告警信息种类的被管理对象A,其告警信息种类的数量为n,网络管理系统可容忍的判错率为ε,则Bloomfilter数据结构的长度m≥nlog2(1/ε),Bloomfilter数据结构的哈希函数数量k=ln2·(m/n)。
本实施例中的操作方法为:假设在一个网络管理系统中,被管理对象A具有最多的告警种类,其告警信息种类数量为n,系统可容忍的判错率为ε,则Bloomfilter长度m必须满足m≥nlog2(1/ε),之后可以据此计算出最佳的哈希函数数量为k=ln2·(m/n),这样就确定了Bloomfilter结构。将每个被管理对象的所有当前告警信息通过hash方式映射到Bloomfilter之后,将此被管理对象的(ID,Bloomfilter)对组成Map结构存储到内存中,示意图如图4所示。
S2、网络管理服务器收到一条Trap报文后,对报文进行解析,提取报文中携带的被管理对象ID和告警信息,通过被管理对象ID在内存中提取对应的记录该被管理对象当前告警信息的Bloomfilter,对Bloomfilter进行存在性判定,如果判定该报文携带的告警信息为新告警,则将此告警信息通过hash算法映射到对应的Bloomfilter中进行记录,并将该告警信息存入当前告警数据库;如果判定该报文携带的告警信息已经存在,更新当前告警数据库中的对应记录。
上述步骤的具体实现方式为:
(1)网管系统初始化时同步当前告警信息到Bloomfilter中
系统启动时,从数据库中读取所有被管理对象的ID,根据被管理对象的ID在当前告警数据库中查询其所有当前告警信息OID,并通过hash算法将告警信息映射到此ID对应的Bloomfilter中;遍历所有读取出的被管理对象,得到每个被管理对象ID和其Bloomfilter的对应关系列表,将此列表存储到内存中。
例如,本实施例中选取Bloomfilter长度为11,哈希函数数量为2,某个被管理对象A在数据库中的ID为’01’,其所对应的当前告警信息有三条,告警OID分别为.1.3.6.1.2.1.1.5.1、.1.3.6.1.2.1.1.6.1、.1.3.6.1.2.1.1.7.1,经过hash算法,第一条告警信息映射为[10000010000],第二条告警信息映射为[10001010000],第三条告警信息映射为[10001010010],由于其中第1位、第5位、第7位被多次映射为1,因此三个hash结果叠加后,最后得到此被管理对象对应的计数型Bloomfilter结果为[10001010010][30002030010],其中前一个数组代表Bloomfilter映射之后的结果,后一个数组代表某个位被置1几次。这样就得到被管理对象A对应的Bloomfilter,如表1所示。
表1:被管理对象A对应的Bloomfilter
被管理对象ID | Counting Bloomfilter |
01 | [10001010010][30002030010] |
重复对每个被管理对象进行上述操作,就可以得到如表2所示的被管理对象ID-Bloomfilter对应关系。
表2:被管理对象ID-Bloomfilter对应关系列表
被管理对象ID | Counting Bloomfilter |
01 | [10001010010][30002030010] |
02 | [00000000010][00000000010] |
03 | [00000000000][00000000000] |
…… | …… |
本实施例中,将这种对应关系用Map数据结构来存储,并将所得到的Map存储到内存中。
(2)对Bloomfilter进行存在性判定
对Bloomfilter进行存在性判定的方法为:通过hash方式对Trap报文中携带的告警信息进行处理,并将处理后的结果与此被管理对象对应的Bloomfilter中存储的信息进行对比,如果存在,则此告警信息为重复告警,如果不存在,则此告警信息为新告警。
系统收到一条Trap报文后,会根据报文中携带的被管理对象ID信息,在内存中找到对应的(ID,Bloomfilter)对,从而找到记录该被管理对象所有当前告警信息的Bloomfilter。若此时通过Bloomfilter的存在性判定,判定该报文携带的告警信息为新告警,则将该告警信息存入当前告警数据库,并将此告警OID通过hash算法映射到对应Bloomfilter中进行记录。
表3:Trap报文示例表
被管理对象ID | 告警OID | 告警时间 |
01 | .1.3.6.1.2.1.1.8.1 | 2013.6.2712:00:00 |
例如,当前系统内存中ID-Bloomfilter对应关系如表2所示,收到Trap报文如表3所示,其中,被管理对象的ID为’01’,据此在ID-Bloomfilter对应关系表中可以查找到该被管理对象对应的Bloomfilter为[10001010010][30002030010]。报文中告警OID为.3.0.1.1.0.2.5.1.0.2.1,通过hash算法,该OID对应的hash结果为[10000010011],通过Bloomfilter的存在性判定规则,原有Bloomfilter中最后一位并不为1,可以判定该告警不在当前告警数据库中,即此告警为新告警信息。
(3)对新告警信息的处理
如果判定该报文携带的告警信息为新告警,则将此告警信息通过hash算法映射到对应的Bloomfilter中进行记录,并将该告警信息存入当前告警数据库。
针对上述的例子,判定为新告警信息后,系统会将此告警信息存入当前告警数据库中,同时将此告警信息的hash结果[10000010011]叠加到原来的Bloomfilter中,得到新的Bloomfilter:[10001010011][40002040021],如表4所示。
表4:加入新告警后的被管理对象ID-Bloomfilter对应关系列表
被管理对象ID | Counting Bloomfilter |
01 | [10001010011][40002040021] |
02 | [00000000010][00000000010] |
03 | [00000000000][00000000000] |
…… | …… |
(4)对重复告警的处理
如果判定该报文携带的告警信息已经存在,更新当前告警数据库中的对应记录。
当系统收到的告警信息经过Bloomfilter的存在性判定,判定该告警信息已经存在于Bloomfilter之中时,证明该告警为重复告警。对于此类告警,系统不会对Bloomfilter做任何操作,但是会更新当前告警数据库中的对应记录。
例如,上述ID为’01’的被管理对象,若其上报的Trap报文如表5所示,其中的告警OID通过hash算法得到的结果为[10001010010],通过Bloomfilter的存在性判定规则,此结果中每个为1的位在原有Bloomfilter中都为1,可以判定此Trap报文中携带的告警信息存在于当前告警数据库中,即为重复告警。此时,系统会根据被管理对象ID及告警信息OID,找到当前告警数据库中的对应记录,将记录中的告警次数字段加1,并将最后告警时间字段设置为2013.6.2712:00:00。
表5:Trap报文示例表
被管理对象ID | 告警OID | 告警时间 |
01 | .1.3.6.1.2.1.1.7.1 | 2013.6.2712:00:00 |
(5)告警信息的删除
所述网络管理系统还包括历史告警数据库,当网络管理服务器接收到告警清除报文或者接收到告警清除指令后,会将对应告警信息从当前告警数据库移动到历史告警数据库,同时,删除此被管理对象对应的Bloomfilter中的此条信息。
服务器收到告警清除报文或者网管系统页面操作中的告警清除指令后,会将对应告警信息从当前告警数据库移动到历史告警数据库,同时会在此被管理对象对应的Bloomfilter中删除这条告警信息记录。
比如,当前系统内存中ID-Bloomfilter对应关系如表2所示,收到告警清除报文如表6所示,根据报文中的被管理对象ID信息,可以找到其对应的Bloomfilter为[10001010010][30002030010]。将其告警OID经过hash算法映射,得到结果为[10001010010],将原有Bloomfilter中第1、5、7、10位的计数器减1,就实现了将该告警记录从Bloomfilter中移出的目的。此时内存中的ID-Bloomfilter对应关系列表更新为如表7所示。
表6:告警清除报文示例表
被管理对象ID | 告警OID | 告警清除时间 |
01 | .1.3.6.1.2.1.1.7.1 | 2013.6.2712:01:00 |
表7:删除一条告警后的ID-Bloomfilter对应关系列表
被管理对象ID | Counting Bloomfilter |
01 | [10001010000][20002030000] |
02 | [00000000010][00000000010] |
03 | [00000000000][00000000000] |
(6)针对Bloomfilter误判的处理
如果判定该报文携带的告警信息已经存在,更新当前告警数据库中的对应记录后,如果网络管理服务器接收到当前告警数据库返回结果显示“更新记录条数为0”,则网络管理服务器修正对Bloomfilter进行存在性判定的结果,判定该报文携带的告警信息为新告警,则将该告警信息存入当前告警数据库,并将此告警信息通过hash算法映射到对应的Bloomfilter中进行记录。
由于哈希算法的特点,当通过Bloomfilter存在性判定,判断某个告警不存在于当前告警数据库中时,这种判断的准确性为100%;但是如果判断某个告警存在于当前告警数据库中,这种判断却存在一定的误判率。假设Bloomfilter数据结构中,所需要表示的集合为S={x1,x2,……,xn},共包括n个元素,Bloomfilter长度为m,所采用的哈希函数有k个,分别为{h1,h2,……,hk},每一个都能把集合S中的元素映射为1~m中的任意数。此时,该Bloomfilter的判错率为(1-e-kn/m)k。
Bloomfilter发生误判时,会将原本不在Bloomfilter中的元素判定为存在于Bloomfilter中,即将新告警信息误判为重复告警信息,从而对数据库进行错误的操作。为了应对Bloomfilter误判带来的影响,首先,在Bloomfilter长度和哈希函数数量选择上,选择较长的Bloomfilter长度(m≥nlog2(1/ε))及适当数量的哈希函数(k=m·ln(2/n)),会降低判错率。另外,在发生误判时,本专利提出了对应的处理对策,可以保证在发生误判的情况下,仍然可以正确保存告警信息。
本实施例中误判处理策略为:当系统将新告警误判为重复告警时,会向数据库中更新记录,但数据库返回结果会显示“更新记录条数为0”,发生这种情况时,系统可以判定Bloomfilter发生了误判的情况,进而可以将此告警信息作为新告警进行对应操作。
值得注意的是,为了使上述策略简便有效,在告警信息入库流程中,Bloomfilter存在性判定之后,应首先进行数据库操作,再进行对Bloomfilter的操作,二者顺序不可互换。
本实施例通过Bloomfilter记录系统中的当前告警信息,当服务器收到被管理对象发送的告警信息后,会根据Bloomfilter的状态判断这条告警是否已经存在,从而决定进行数据库更新操作还是进行数据库插入操作。这种方式用增加内存和hash计算开销的方式,减少了对数据库的查询操作,从而提升了系统的运行速度。下面对这种方式所节省的时间开销进行分析。
对于告警信息处理来说,两种处理流程的差别仅在于:原始流程通过查询数据库判断告警是否重复告警;改进流程通过查询Bloomfilter判断告警是否重复告警。因此,只需要比较两种流程在这两个环节所需要的时间即可。编写程序模拟在当前告警数据库中查询50条记录,为了减少随机性对结果的影响,本仿真实验共测得5组对比数据,并将其中最大最小值去掉,取其余3个的平均值作为所用时间的估计值,5组对比数据如表8所示。
表8:两种查询方式所用时间对比表
经过处理得到第一种方式平均用时是53ms,第二种方式平均用时是8ms。因此,针对一条告警信息,改进的处理流程比原始处理流程用时少0.9ms。
当系统中出现严重告警时,会引发很多相关联告警同时上报(即告警风暴),此时告警信息数量势必会大大增加,若采用原始处理流程,势必会给系统数据库带来很大的访问压力,不利于迅速处理上报的告警信息。测试程序模拟了告警信息每分钟到达1个~200个的情况,两种处理流程平均所需处理时间结果如图5所示,曲线1为现有技术处理流程中的曲线图,曲线2为本发明技术处理流程中的曲线图。从图中可以看出,改进的告警信息入库处理流程所需时间基本呈线性增长趋势,而原始处理流程在告警信息以每分钟100个的速度到达时,所需处理时间开始急剧增长,证明此时数据库存取速度已经成为系统瓶颈,限制了对于告警信息的处理速度。
通过以上分析得到结论,使用此专利中基于Bloomfilter的告警信息入库处理流程,可以很大程度上提高告警信息入库速度,避免了网管系统中告警信息集中上报时出现的告警信息处理缓慢以及告警堆栈溢出的问题,优化了网络管理系统的系统性能。
除上述实施例外,本发明还可以有其他实施方式。凡采用等同替换或等效变换形成的技术方案,均落在本发明要求的保护范围。
Claims (7)
1.一种网络管理系统中的告警信息入库的处理方法,包括网络管理服务器和与网络管理服务器双向通信连接的被管理对象和当前告警数据库,其特征在于,包括如下步骤:
S1、将被管理对象的当前告警信息通过hash方式映射到Bloomfilter数据结构,将被管理对象对应的标识ID和Bloomfilter配对后组成Map结构存储到网络管理服务器的内存中;
S2、网络管理服务器收到一条Trap报文后,对报文进行解析,提取报文中携带的被管理对象ID和告警信息,通过被管理对象ID在内存中提取对应的记录该被管理对象当前告警信息的Bloomfilter,对Bloomfilter进行存在性判定,如果判定该报文携带的告警信息为新告警,则将此告警信息通过hash算法映射到对应的Bloomfilter中进行记录,并将该告警信息存入当前告警数据库;如果判定该报文携带的告警信息已经存在,更新当前告警数据库中的对应记录。
2.根据权利要求1所述的一种网络管理系统中的告警信息入库的处理方法,其特征在于,步骤S1中所述的Bloomfilter数据结构采用相同的长度和哈希函数的数量,确定长度和哈希函数数量的方法为:确定网络管理系统中具有最多告警信息种类的被管理对象A,其告警信息种类的数量为n,网络管理系统可容忍的判错率为ε,则Bloomfilter数据结构的长度m≥nlog2(1/ε),Bloomfilter数据结构的哈希函数数量k=ln2·(m/n)。
3.根据权利要求1所述的一种网络管理系统中的告警信息入库的处理方法,其特征在于,步骤S1中将被管理对象的告警信息存储到内存中的方法为:系统启动时,从数据库中读取所有被管理对象的ID,根据被管理对象的ID在当前告警数据库中查询其所有当前告警信息,并通过hash算法将告警信息映射到此ID对应的Bloomfilter中;遍历所有读取出的被管理对象,得到每个被管理对象ID和其Bloomfilter的对应关系列表,将此列表存储到内存中。
4.根据权利要求1所述的一种网络管理系统中的告警信息入库的处理方法,其特征在于,步骤S2中,对Bloomfilter进行存在性判定的方法为:通过hash方式对Trap报文中携带的告警信息进行处理,并将处理后的结果与此被管理对象对应的Bloomfilter中存储的信息进行对比,如果存在,则此告警信息为重复告警,如果不存在,则此告警信息为新告警。
5.根据权利要求1所述的一种网络管理系统中的告警信息入库的处理方法,其特征在于,所述网络管理系统还包括历史告警数据库,当网络管理服务器接收到告警清除报文或者接收到告警清除指令后,会将对应告警信息从当前告警数据库移动到历史告警数据库,同时,删除此被管理对象对应的Bloomfilter中的此条信息。
6.根据权利要求1所述的一种网络管理系统中的告警信息入库的处理方法,其特征在于,步骤S2中,如果判定该报文携带的告警信息已经存在,更新当前告警数据库中的对应记录后,如果网络管理服务器接收到当前告警数据库返回结果显示“更新记录条数为0”,则网络管理服务器修正对Bloomfilter进行存在性判定的结果,判定该报文携带的告警信息为新告警,则将该告警信息存入当前告警数据库,并将此告警信息通过hash算法映射到对应的Bloomfilter中进行记录。
7.根据权利要求1所述的一种网络管理系统中的告警信息入库的处理方法,其特征在于,步骤S1及S2中所述的Bloomfilter为计数型Bloomfilter。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310578377.0A CN103595569A (zh) | 2013-11-15 | 2013-11-15 | 一种网络管理系统中的告警信息入库的处理方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310578377.0A CN103595569A (zh) | 2013-11-15 | 2013-11-15 | 一种网络管理系统中的告警信息入库的处理方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN103595569A true CN103595569A (zh) | 2014-02-19 |
Family
ID=50085560
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201310578377.0A Pending CN103595569A (zh) | 2013-11-15 | 2013-11-15 | 一种网络管理系统中的告警信息入库的处理方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN103595569A (zh) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104580523A (zh) * | 2015-01-30 | 2015-04-29 | 广州广电运通金融电子股份有限公司 | 自助终端监控数据存储方法和自助终端监控服务器 |
CN105302703A (zh) * | 2015-09-21 | 2016-02-03 | 上海斐讯数据通信技术有限公司 | 一种olt设备的告警数据管理的方法 |
CN106959903A (zh) * | 2016-01-08 | 2017-07-18 | 中兴通讯股份有限公司 | 陷阱指令Trap的处理方法及装置 |
CN107222356A (zh) * | 2017-07-28 | 2017-09-29 | 郑州云海信息技术有限公司 | 一种云监控系统告警方法和系统 |
CN111221818A (zh) * | 2019-12-27 | 2020-06-02 | 特瓦特能源科技有限公司 | 一种告警信息解析方法及装置 |
CN111917565A (zh) * | 2019-05-10 | 2020-11-10 | 南京南瑞继保电气有限公司 | 一种实时告警统计方法及系统 |
CN112685277A (zh) * | 2020-12-31 | 2021-04-20 | 海光信息技术股份有限公司 | 警告信息检查方法、装置、电子设备和可读存储介质 |
CN113839912A (zh) * | 2020-06-24 | 2021-12-24 | 极客信安(北京)科技有限公司 | 主被动结合进行异常主机分析的方法、装置、介质和设备 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1925421A (zh) * | 2005-09-02 | 2007-03-07 | 中兴通讯股份有限公司 | 一种前后台告警同步的方法 |
US20100281541A1 (en) * | 2004-05-11 | 2010-11-04 | The Trustees Of Columbia University In The City Of New York | Systems and Methods for Correlating and Distributing Intrusion Alert Information Among Collaborating Computer Systems |
CN102064974A (zh) * | 2009-11-11 | 2011-05-18 | 杭州华三通信技术有限公司 | 一种告警信息的处理方法、系统和设备 |
US8032529B2 (en) * | 2007-04-12 | 2011-10-04 | Cisco Technology, Inc. | Enhanced bloom filters |
CN103078754A (zh) * | 2012-12-29 | 2013-05-01 | 大连环宇移动科技有限公司 | 一种基于计数型bloom filter的网络数据流统计方法 |
-
2013
- 2013-11-15 CN CN201310578377.0A patent/CN103595569A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100281541A1 (en) * | 2004-05-11 | 2010-11-04 | The Trustees Of Columbia University In The City Of New York | Systems and Methods for Correlating and Distributing Intrusion Alert Information Among Collaborating Computer Systems |
CN1925421A (zh) * | 2005-09-02 | 2007-03-07 | 中兴通讯股份有限公司 | 一种前后台告警同步的方法 |
US8032529B2 (en) * | 2007-04-12 | 2011-10-04 | Cisco Technology, Inc. | Enhanced bloom filters |
CN102064974A (zh) * | 2009-11-11 | 2011-05-18 | 杭州华三通信技术有限公司 | 一种告警信息的处理方法、系统和设备 |
CN103078754A (zh) * | 2012-12-29 | 2013-05-01 | 大连环宇移动科技有限公司 | 一种基于计数型bloom filter的网络数据流统计方法 |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104580523A (zh) * | 2015-01-30 | 2015-04-29 | 广州广电运通金融电子股份有限公司 | 自助终端监控数据存储方法和自助终端监控服务器 |
CN104580523B (zh) * | 2015-01-30 | 2019-04-16 | 广州广电运通金融电子股份有限公司 | 自助终端监控数据存储方法和自助终端监控服务器 |
CN105302703A (zh) * | 2015-09-21 | 2016-02-03 | 上海斐讯数据通信技术有限公司 | 一种olt设备的告警数据管理的方法 |
CN105302703B (zh) * | 2015-09-21 | 2018-01-30 | 上海斐讯数据通信技术有限公司 | 一种olt设备的告警数据管理的方法 |
CN106959903A (zh) * | 2016-01-08 | 2017-07-18 | 中兴通讯股份有限公司 | 陷阱指令Trap的处理方法及装置 |
CN107222356A (zh) * | 2017-07-28 | 2017-09-29 | 郑州云海信息技术有限公司 | 一种云监控系统告警方法和系统 |
CN111917565A (zh) * | 2019-05-10 | 2020-11-10 | 南京南瑞继保电气有限公司 | 一种实时告警统计方法及系统 |
CN111221818A (zh) * | 2019-12-27 | 2020-06-02 | 特瓦特能源科技有限公司 | 一种告警信息解析方法及装置 |
CN113839912A (zh) * | 2020-06-24 | 2021-12-24 | 极客信安(北京)科技有限公司 | 主被动结合进行异常主机分析的方法、装置、介质和设备 |
CN113839912B (zh) * | 2020-06-24 | 2023-08-22 | 极客信安(北京)科技有限公司 | 主被动结合进行异常主机分析的方法、装置、介质和设备 |
CN112685277A (zh) * | 2020-12-31 | 2021-04-20 | 海光信息技术股份有限公司 | 警告信息检查方法、装置、电子设备和可读存储介质 |
CN112685277B (zh) * | 2020-12-31 | 2023-01-24 | 海光信息技术股份有限公司 | 警告信息检查方法、装置、电子设备和可读存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103595569A (zh) | 一种网络管理系统中的告警信息入库的处理方法 | |
US11087329B2 (en) | Method and apparatus of identifying a transaction risk | |
US8826032B1 (en) | Systems and methods for network change discovery and host name resolution in storage network environments | |
CN111885040A (zh) | 分布式网络态势感知方法、系统、服务器及节点设备 | |
CN104301413B (zh) | 面向云数据库的一种Oracle分布式实时监控方法 | |
CN102340415B (zh) | 一种服务器集群系统的监控方法和一种服务器集群系统 | |
CN110535713B (zh) | 监控管理系统以及监控管理方法 | |
CN110149223B (zh) | 故障定位方法和设备 | |
WO2013029968A1 (en) | Method and system for detecting anomaly of user behavior in a network | |
WO2011017955A1 (zh) | 一种告警数据分析的方法及其系统 | |
CN103490937A (zh) | 监控数据过滤方法及装置 | |
CN109218080A (zh) | 一种自动绘制网络拓扑架构的方法、监控系统及终端设备 | |
CN106878038B (zh) | 一种通信网络中故障定位方法及装置 | |
CN112769605B (zh) | 一种异构多云的运维管理方法及混合云平台 | |
CN111258798A (zh) | 监控数据的故障定位方法、装置、计算机设备及存储介质 | |
CN108075913B (zh) | 一种播发系统服务质量的监控方法及其系统 | |
CN105491078A (zh) | Soa系统中的数据处理方法及装置、soa系统 | |
CN112199394A (zh) | 告警信息推送方法、系统、智能终端及存储介质 | |
CN109474470A (zh) | 一种自监控方法和装置 | |
CN116418653A (zh) | 基于多指标根因定位算法的故障定位方法及装置 | |
CN117376092A (zh) | 故障根因定位方法、装置、设备及存储介质 | |
CN110851758A (zh) | 一种网页访客数量统计方法及装置 | |
CN103812719B (zh) | 集群系统的失效预测方法及装置 | |
CN110196787B (zh) | 一种数据备份恢复系统及其数据备份恢复方法 | |
CN110389875A (zh) | 用于监控计算机系统运行状态的方法、装置和存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20140219 |