一种告警数据处理方法和装置与流程

本发明涉及网络管理技术领域，具体涉及一种告警数据处理方法和装置。

背景技术：

随着计算机和通信技术的发展，对计算机网络的依赖与日俱增，使得网络管理的作用和地位也更加突出，而告警管理是网络管理的基础。在网络管理系统中，存在着大量的告警数据，网管系统需要对告警数据进行分析、计算、以及保存到数据库等一系列处理。目前，常见的告警类型有：硬件问题告警、端口告警、传输问题告警、配置问题告警和时钟问题告警等。现有技术，在对告警进行处理时，受限于网管系统的处理器、输入输出设备的性能以及软硬件环境等的限制，处理速度和效率较低，并且，现有技术中不对告警数据产生的故障根源进行分析，不能满足应用需求。

技术实现要素：

本发明提供了一种告警数据处理方法和装置，以解决现有技术中告警数据处理效率低以及不对告警数据产生的故障根源进行分析，不能满足应用需求的问题。

根据本发明一个实施例的一种告警数据处理方法，方法包括：

监听网络管理系统中的告警数据；

判断监听到的告警数据是否满足预设分析规则，并为满足预设分析规则的告警数据对应分配一个分析线程，对告警数据进行故障根源分析处理，得到告警数据的分析结果；

将所述分析结果保存到告警分析数据库中。

根据本发明的另一个方面，提供了一种告警数据处理装置，告警数据处理装置包括：

告警监听单元，用于监听网络管理系统中的告警数据；

告警处理单元，用于判断监听到的告警数据是否满足预设分析规则，并为满足预设分析规则的告警数据对应分配一个分析线程，对告警数据进行故障根源分析处理，得到告警数据的分析结果；

存储单元，用于保存所述分析结果到告警分析数据库中。

本发明实施例的有益效果是：本发明的告警数据处理方法和装置，通过监听网络管理系统中的告警数据，为监听到的满足预设分析规则的告警数据对应启动一个分析线程，以对告警数据进行故障根源分析处理，得到告警数据的分析结果，将分析结果保存到告警分析数据库中，从而能够对满足预设分析规则的告警数据分配独立的线程，实现了多线程处理告警数据的有益效果，与现有技术相比，提高了告警数据处理的速度和效率。此外，对满足预设分析规则的告警数据，本实施例会进一步分析这类告警数据的故障根源，从而为告警数据的处理提供更多的参考信息，避免重复处理由同一故障根源产生的告警数据，降低了告警管理的工作量，提高了网管系统中告警管理的有效性和价值。

附图说明

图1是本发明一个实施例的一种告警数据处理方法的流程图；

图2是本发明另一个实施例的一种告警数据处理方法的整体流程图；

图3是本发明又一个实施例的一种告警数据处理方法的流程示意图；

图4是本发明一个实施例的一种告警数据处理装置的框图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本发明的设计构思在于：利用Java语言的多线程特性为每个符合预设分析规则的告警启动独立的分析线程，从而实现在网络监控中当物理端口宕告警发生时，过滤其衍生出来的逻辑子端口宕告警，以避免对同一故障根源引起的多条告警数据进行处理导致的重复劳动，减轻日常告警工作的压力的有益效果。

Java语言支持多线程，多线程的目的是为了最大限度的利用CPU资源，提高数据处理的效率。线程：同一类线程共享代码和数据空间，每个线程有独立的运行栈和程序计数器，线程切换开销小。多线程是指在同一程序中有多个顺序流在执行。Java程序运行在Java虚拟机(Java Virtual Machine,简称JVM)中，在JVM的内部，程序的多任务是通过线程来实现的。对于一个进程中的多个线程来说，多个线程共享进程的内存块，当有新的线程产生的时候，操作系统不分配新的内存，而是让新线程共享原有的进程块的内存。因此，线程间的通信很容易，速度也很快。

在网络管理系统中，告警有多种类型，例如，根据告警产生的故障根源，告警可分为：物理端口故障引起的告警，以及物理端口绑定的逻辑子端口故障引起的告警。

物理端口：物理端口又称为接口，是可见端口，例如，计算机背板的RJ45网口，交换机、路由器、集线器等网络设备的RJ45端口。

逻辑子端口：逻辑接口指能够实现数据交换功能但物理上不存在，需要通过配置建立的接口，包括Dialer(拨号)接口、子接品、LoopBack接口、NULL接口、备份中心逻辑通道以及虚拟模板接口等。

在实际的网络监控中，由于逻辑子端口从属于物理端口，所以当一个物理端口宕掉、产生告警时，其下所有逻辑子端口也会产生接口宕告警。这种情况下，如果不将逻辑子端口告警过滤掉，那么后续再对告警数据进行处理时，势必导致对于同一个故障(即物理端口故障)引起的多条告警的重复处理，增加告警处理的压力和工作量。

为了解决这一问题，本实施例提出一种对告警进行故障根源分析的技术方案，判断每个逻辑子端口宕告警是否由于物理端口宕掉而产生，如果是，则将逻辑子端口宕告警过滤掉，以减少日常告警处理的数量，提高告警监控的有效性。

实施例一

图1是本发明一个实施例的一种告警数据处理方法的流程图，参见图1，本实施例的这种告警数据处理方法包括如下步骤：

步骤S101，监听网络管理系统中的告警数据；

步骤S102，判断监听到的告警数据是否满足预设分析规则，并为满足预设分析规则的告警数据对应分配一个分析线程，对告警数据进行故障根源分析处理，得到告警数据的分析结果；

步骤S103，将所述分析结果保存到告警分析数据库中。

由图1所示的方法可知，本实施例中通过对网管系统中的告警数据进行监控，当收到告警数据时为判断监听到的告警数据是否满足预设分析规则，并为满足预设分析规则的告警数据对应分配独立的线程，进行故障根源分析，从而能够提供告警故障根源信息供运维人员参考，方便后续过滤由同一个故障根源产生的告警(即不对过滤掉的告警进行处理)，减少告警处理的数量，提高告警监控的有效性。此外，由于为满足预设分析规则的告警数据对应分配一个分析线程，也保证了告警处理的效率。

实施例二

需要说明的是，本实施例的告警数据的处理方法的应用环境为网络管理系统，具体的，是应用在配置了物理端口和逻辑子端口之间绑定关系的网络管理系统中。在网络管理系统中建立分析策略，策略中配置分析规则和告警压制时间阈值，而后，在网络管理系统中启动分析服务(即，本实施例的告警数据的处理方法)，当分析服务收到一条符合预设分析规则的接口宕告警时，启动一个分析线程，对接口故障进行根源分析；最后，将分析结果上传到告警分析数据库，供界面、通知和派单使用。

图2是本发明另一个实施例的一种告警数据处理方法的整体流程图，参见图2，本实施例的告警数据处理方法的整体流程如下：

步骤S201，启动分析服务；

具体的，在网络管理系统启动时，可将本实施例的告警数据处理分析服务启动。分析服务为一个独立的线程服务，该线程服务的生命周期可与网络管理系统的生命周期相同，网管系统的生命周期，即该网管系统从启动到停止的整个周期，当网管系统停止时，分析服务也停止工作。

另外，在分析服务启动过程中，网管系统将用户通过界面配置的用于告警故障根源分析的分析策略(包括预设分析规则和压制时间)加载到内存，并将告警分析数据库中已经存在的根源故障分析结果加载到内存中，当预设分析规则和已有分析结果加载完成后，启动告警监听。

步骤S202，告警数据的故障根源分析；

分析服务启动后，开始监控告警，当有告警发生时，启动一个分析线程进行根源故障分析。

步骤S203，上传分析结果。

这里的，上传的分析结果，是上传对告警进行故障根源分析后得到的分析结果，例如，对物理端口宕告警进行故障根源分析后，确定出是由物理端口宕这一故障引起的，则在步骤S203可上传物理端口宕告警具体内容以及故障原因(即，物理端口宕)。而对于逻辑子端口宕告警，进行故障根源分析后，确定出是由逻辑子端口宕(而非物理端口宕)这一故障引起的，则在步骤S203可上传逻辑子端口宕告警具体内容以及故障原因(即，逻辑子端口宕)上传到数据库。

当告警数据对应的分析线程执行结束后，将告警数据的分析结果上传到数据库中保存，供界面、通知、派单使用。

实施例三

图3是本发明又一个实施例的一种告警数据处理方法的流程示意图，参见图3，本实施例的告警数据处理方法包括如下步骤：

流程开始。

执行步骤S301，监听告警数据；

本实施例的告警数据处理方法在监听到一条告警时，读取内存缓存中的分析策略，分析策略中配置有预设分析规则。

步骤S302，判断是否符合预设分析规则；是则，执行步骤S303，否则结束流程；

由于网络管理系统不只存在监控接口宕告警，还有很多其它类型的告警，本实施例中只对物理端口宕告警以及从属于物理端口的逻辑子端口宕告警进行处理，因此，需要对网管系统中的告警进行过滤，判断当前告警数据是否为物理端口宕或逻辑子端口宕，如果不是这两类告警，直接结束。

本实施例中，判断告警数据是否满足预设分析规则包括：获取告警数据的中指示告警类型的告警类型标识信息，判断告警类型标识信息指示的告警类型是否与预设分析规则中的告警类型匹配，是则，确定告警数据满足预设分析规则，否则，确定告警数据不满足预设分析规则。预设分析规则中的告警类型包括：物理端口宕告警，或者，与物理端口绑定的逻辑子端口宕告警。

一般的，每条告警数据基本包括如下信息：告警标题、告警级别、告警状态，告警序列号和告警通知方式等。其中每条告警数据的告警标题通常指示该条告警数据的类型，因此，本实施例中，当收到一条告警数据时，提取告警标题，可将告警标题指示的告警类型和预设分析规则中的告警类型(两类)：物理端口宕告警，或者，逻辑子端口宕告警进行匹配。当匹配到其中之一时，进行后续处理步骤，当与预设分析规则中的两种告警类型均不匹配时，直接结束。

步骤S303，启动分析线程，判断是否符合存在分析结果；否则，执行步骤S304，是则结束流程；

本步骤中，为每个物理端口宕告警以及该物理端口绑定的所有逻辑子端口的逻辑子端口宕告警分配同一个分析线程。

具体的，当收到一条满足分析规则的告警数据时，即收到一条物理端口宕告警或者逻辑子端口宕告警时，先判断是否存在相关的已有分析线程，如果存在已有分析线程，则将该条告警数据归入到已有分析线程中进行分析，如果不存在相关的已有分析线程，则为该条告警数据分配一个新分析线程，进行故障根源分析。

举例而言，物理端口A绑定有两个逻辑子端口，分别为：逻辑子端口a和逻辑子端口b，当本实施例的方法在先监听到物理端口A的物理端口宕告警时，判断不存在已有分析线程，则为物理端口A的该条物理端口宕告警分配一个新的分析线程Process01。然后，在3秒之后监听到了物理端口A的逻辑子端口a的逻辑子端口宕告警，进行线程判断，则会发现存在相关的已有分析线程Process01，则不再为逻辑子端口a的逻辑子端口宕告警分配新的分析线程，而是将逻辑子端口a的逻辑子端口宕告警归入到已有分析线程Process01中进行故障根源分析。

另外，本实施例中对物理端口A的物理端口宕告警和逻辑a的逻辑子端口以及逻辑子端口b的逻辑子端口宕告警的顺序不作限制，即，上述举例说明中，也可能先监听到逻辑子端口a的逻辑子端口宕告警，此时处理流程相同，即，同样先进行是否存在相关的已有分析线程的判断，存在，则归入已有分析线程，不存在，则分配新的分析线程。

由此可见，本实施例中通过为每个物理端口及其绑定的逻辑子端口分配同一个分析线程，实现了网络管理系统中告警数据故障根源分析的并行处理，与单线程的处理方式相比，提高了告警分析的速度和效率。

另外，实际网络管理系统中，告警监控具有连续性，对于按照预定时间间隔进行轮循的告警，只要故障未被清除，这类告警会每隔一定时间发生一次。

所以，当收到一条符合预设分析条件的告警后，先判断告警是否已经分析过，如果已经分析过，不再进行分析，结束线程。如果没有分析过，再进行后续故障根源分析。

即，本实施例中先通过在告警分析数据库中查找是否存在该告警的分析结果对告警进行去重判断，具体的，获取唯一标识每条告警数据的告警序列号(Alarm_id)，利用告警序列号在告警分析数据库中保存的分析结果中查找，当分析结果中存在该条告警数据时，结束分析；当分析结果中不存在该条告警数据时，根据告警数据的告警类型进行相应的操作。

如此，对于那些已经分析过的告警，可以直接结束流程，不再进行后续分析，从而提高了告警数据处理的效率。

步骤S304，判断是否为物理端口宕告警；是则，执行步骤S305，上传分析结果；否则，执行步骤S306；

在前述步骤S302中对告警进行是否符合预设分析规则的判断时，可确定出当前告警的类型(即为物理端口宕告警或逻辑子端口宕告警)，在本步骤，即步骤S304中，具体判断当前告警是否为物理端口宕告警，当告警数据的告警类型为物理端口宕告警时，将告警数据上传至告警分析数据库中保存。

注：由于物理端口的故障通常影响力较大，所以对于由物理端口故障引起的物理端口宕告警需要进行重点监控，收到这类告警时，可将该类告警数据直接上传到告警分析数据库中，方便对这类告警数据进行后续处理。

而对于从属于物理端口的逻辑子端口而言，其告警的发生有两种情况：第一种告警是由于物理端口故障引起的，即，逻辑子端口宕的故障根源为物理端口，第二种告警是由于逻辑子端口本身的故障引起的，即逻辑子端口宕的故障根源为逻辑子端口。

本实施例中，对于逻辑子端口的第一种告警，即故障根源为物理端口的这类告警需要进行过滤，以避免对同一故障引起的多条告警进行重复分析处理，增加告警处理的工作量。

步骤S306，将告警数据进行压制；

当告警数据的告警类型为逻辑子端口宕告警时，将告警数据发送至逻辑子端口绑定的物理端口对应的告警压制队列进行压制。

注：本实施例中之所以对逻辑子端口宕告警进行压制，是因为物理端口宕告警不一定在逻辑子端口宕告警之前发生，也有可能在逻辑子端口宕告警之后发生。例如：物理端口宕告警在逻辑子端口宕告警之后的5秒后发生。

由此，当逻辑子端口宕告警发生时，需要在系统内暂时缓存一段时间，如果不进行压制的话，逻辑子端口宕告警就会被上传到数据库，这条告警就没有被过滤掉，会造成告警重复。

步骤S307，判断是否收到相应的物理端口宕告警；是则，执行步骤S308，否则，执行步骤S305；

在逻辑子端口宕告警数据被压制期间，本实施例判断是否监听到该逻辑子端口绑定的物理端口的物理端口宕告警数据，否则，在逻辑子端口宕告警数据的压制时间超出预设压制时间阈值时，将逻辑子端口宕告警数据从告警压制队列中取出并上传至告警分析数据库中保存。

注：如果在逻辑子端口宕告警数据被压制期间没有收到该逻辑子端口绑定的物理端口的物理端口宕告警数据代表该条告警数据的故障根源不是物理端口，所以需要进行告警上报供后续处理。

另外，本实施例中还周期性地对告警压制队列中的逻辑子端口宕告警数据进行检查判断逻辑子端口宕告警的数据的压制时间是否超出预设压制时间阈值。

例如，每隔1秒钟轮询一次告警压制队列，检查逻辑子端口宕告警的压制时间是否超过预设的压制时间阈值(阈值可以设为5秒钟)。如果超过压制时间且没有收到该逻辑子端口绑定的物理端口的物理端口宕告警则可将逻辑子端口宕告警上传到数据库并结束分析线程。

步骤S308，过滤掉告警数据；

如果在逻辑子端口宕告警数据被压制期间，监听到该逻辑子端口绑定的物理端口的物理端口宕告警数据，则将逻辑子端口宕告警数据从告警压制队列中取出，并过滤掉该逻辑子端口宕告警数据。

注：如果在逻辑子端口宕告警数据被压制期间收到了该逻辑子端口绑定的物理端口的物理端口宕告警数据代表该条告警数据的故障根源是物理端口，所以不需要进行告警上报。

至此，流程结束。

由图3所示可知，本实施例的告警数据的处理方法利用Java语言的多线程特性，实现了网络管理中常见的物理端口宕告警与逻辑子端口宕告警之间的故障根源定位，减少日常告警处理的数量。并在具体故障根源分析过程中，为每个物理端口及其绑定的逻辑子端口建立并启动一个分析线程，提高了告警数据分析的效率和告警监控的有效性。

实施例四

图4是本发明一个实施例的一种告警数据处理装置的框图，参见图4，告警数据处理装置40包括：

告警监听单元401，用于监听网络管理系统中的告警数据；

告警处理单元402，用于判断监听到的告警数据是否满足预设分析规则，并为满足预设分析规则的告警数据对应分配一个分析线程，对告警数据进行故障根源分析处理，得到告警数据的分析结果；

存储单元403，用于保存分析结果到告警分析数据库中。

在本发明的一个实施例中，告警处理单元402包括：类型判断子单元，

类型判断子单元，用于获取告警数据的中指示告警类型的告警类型标识信息，判断告警类型标识信息指示的告警类型是否与预设分析规则中的告警类型匹配，是则，确定告警数据满足预设分析规则，否则，确定告警数据不满足预设分析规则，

预设分析规则中的告警类型包括：物理端口宕告警，或者，与物理端口绑定的逻辑子端口宕告警。

在本发明的一个实施例中，告警处理单元402还包括：线程分配子单元，用于为每个物理端口宕告警以及该物理端口绑定的所有逻辑子端口的逻辑子端口宕告警分配同一个分析线程；

去重子单元，用于获取唯一标识每条告警数据的告警序列号，利用告警序列号在告警分析数据库中保存的分析结果中查找，当分析结果中存在该条告警数据时，结束分析；当分析结果中不存在该条告警数据时，根据告警数据的告警类型进行相应的操作。

在本发明的一个实施例中，告警处理单元402，具体用于当告警数据的告警类型为物理端口宕告警时，将告警数据上传至告警分析数据库中保存，当告警数据的告警类型为逻辑子端口宕告警时，将告警数据发送至逻辑子端口绑定的物理端口对应的告警压制队列进行压制。

在本发明的一个实施例中，告警处理单元402还用于，在逻辑子端口宕告警数据被压制期间，判断是否监听到该逻辑子端口绑定的物理端口的物理端口宕告警数据，是则，将逻辑子端口宕告警数据从告警压制队列中取出，并过滤掉该逻辑子端口宕告警数据；否则，在逻辑子端口宕告警数据的压制时间超出预设压制时间阈值时，将逻辑子端口宕告警数据从告警压制队列中取出并上传至告警分析数据库中保存。

在本发明的一个实施例中，告警处理单元402还用于，周期性地对告警压制队列中的逻辑子端口宕告警数据进行检查判断逻辑子端口宕告警的数据的压制时间是否超出预设压制时间阈值。

需要说明的是，本实施例的这种告警数据处理装置是和前述告警数据处理方法中的相应步骤对应的，因而，本实施例的告警数据处理装置更详细的工作过程可以参见前述告警数据处理方法实施例中的说明，这里不再赘述。

综上可知，本发明实施例的告警数据的处理方法和装置，利用Java开发语言的多线程特性，解决了现有技术中不对告警进行故障根源分析导致的告警重复处理，告警工作量和压力大的问题，通过在监听到网络管理系统发生物理端口宕告警时，过滤该物理端口故障衍生出来的逻辑子端口宕告警，避免了对同一根源故障引起的多条告警数据进行重复分析处理，从而减轻了日常告警处理的数量和压力，提高了告警处理的效率，满足了企业的应用需求。

以上所述，仅为本发明的具体实施方式，在本发明的上述教导下，本领域技术人员可以在上述实施例的基础上进行其他的改进或变形。本领域技术人员应该明白，上述的具体描述只是更好的解释本发明的目的，本发明的保护范围以权利要求的保护范围为准。