CN112104480B - 提高告警质量的方法及其系统 - Google Patents

Abstract

本发明提高告警质量的方法及其系统，方法包括：S1：当实例出现异常时，生成对应的异常日志；异常日志包括异常错误类、异常明细信息、异常接口类型、实例标识以及集群标识；异常错误类包括基础服务类和业务服务类；S2：获取异常日志，依据集群标识获取对应集群下各个实例在预设时间段内与所述异常日志的异常接口类型相同的所有异常日志；S3：若所有异常日志的异常错误类均为业务服务类，且异常原因均为非基础服务异常，则判断告警消息表中对应预设时间段是否存在与集群标识、异常接口类型以及异常错误类均相同的告警消息；若不存在，则发送告警消息；若存在，则不处理。本发明能够减少告警消息数量，提高告警质量，以提高问题解决效率。

Description

提高告警质量的方法及其系统

技术领域

本发明涉及互联网领域，具体涉及提高告警质量的方法及其系统。

背景技术

移动互联网蓬勃发展的今天，发展出来了各种各样的系统应用，而每一个客户端或者前端应用都会对应着后端一个或者多个的服务器应用；同时，随着现在应用用户的大量增长，服务端应用也需要支持大量用户和大量请求量，所以服务端应用一般都需要具备支持高并发和高可用性等能力。而随着用户量的逐渐增大，系统的请求量也会逐渐的增大，为了支撑大量的请求数量，后端服务应用一般都会使用分布式部署，通过NGINX等反向代理服务器进行请求分流，后端部署多台的tomcat实例应用等提供服务。

可是如果后端服务器集群的多个应用实例(即服务器)中的某一个或者几个存在问题时，该问题指的是非宕机，或者非网络无法访问这种反向代理无法识别的问题时，比如应用能正常访问，但是由于未升级或者其他未知错误，导致反向代理服务器无法识别，进而该应用实例将会持续性地继续对外提供服务，给用户展现的场景就是某些同样的功能偶发的出现不可用等问题，极大地影响了用户体验。

旧有的告警提示方案中，一般情况下为哪台应用实例出现问题，按照一定的告警规则，进行实例告警；更优化一些的告警方式还包括提示CPU、内存数、实例是否存活等简单告警提示内容；再优一些的还会进行告警数量聚合以及种类聚合，减少告警数量。但是这种聚合告警都只针对单台实例。这样处理带来的影响就是出现问题时，告警消息较多，导致无法全面了解整体问题情况。

因此，有必要提供一种能够优化告警方式，提高告警质量的方案。

发明内容

本发明所要解决的技术问题是：提供一种提高告警质量的方法及其系统，能够减少告警消息数量，提高告警质量，以提高问题解决效率。

为了解决上述技术问题，本发明采用的技术方案为：

一种提高告警质量的方法，包括：

S1：当一实例出现异常时，生成对应的异常日志；所述异常日志中的字段包括异常错误类、异常明细信息、异常接口类型、实例标识以及集群标识；所述异常错误类包括基础服务类和业务服务类；

S2：获取所述异常日志，依据其中的集群标识获取对应集群下各个实例在预设时间段内与所述异常日志的异常接口类型相同的所有异常日志；

S3：若所述所有异常日志的异常错误类均为业务服务类，且依据异常明细信息解析得到异常原因均为非基础服务异常，则判断告警消息表中对应所述预设时间段是否存在与所述异常日志的集群标识、异常接口类型以及异常错误类均相同的告警消息；若不存在，则发送对应所述异常日志的告警消息；若存在，则不对所述异常日志进行处理；

S4：若所述所有异常日志的异常错误类均为基础服务类，则判断告警消息表中对应所述预设时间段是否存在与所述异常日志的集群标识、异常接口类型以及异常错误类均相同的告警消息；若不存在，则发送对应所述异常日志的告警消息；若存在，则不对所述异常日志进行处理。

本发明提供的另一个技术方案为：

一种提高告警质量的系统，包括依序连接的日志生成模块、日志收集模块和日志分析与告警模块；

所述日志生成模块，用于当一实例出现异常时，生成对应的异常日志；所述异常日志中的字段包括异常错误类、异常明细信息、异常接口类型、实例标识以及集群标识；所述异常错误类包括基础服务类和业务服务类；

所述日志收集模块，用于收集生成的每一条异常日志；

所述日志分析与告警模块，用于包括：

获取所述异常日志，依据其中的集群标识获取对应集群下各个实例在预设时间段内与所述异常日志的异常接口类型相同的所有异常日志；

若所述所有异常日志的异常错误类均为业务服务类，且依据异常明细信息解析得到异常原因均为非基础服务异常，则判断告警消息表中对应所述预设时间段是否存在与所述异常日志的集群标识、异常接口类型以及异常错误类均相同的告警消息；若不存在，则发送对应所述异常日志的告警消息；若存在，则不对所述异常日志进行处理。

本发明的有益效果在于：在生成异常日志后不直接进行告警，而是自动聚合相同异常错误类以及相同接口的异常日志数量，在规定时间内只发出一条告警消息进行告警提示。这样能够显著减少所发出的告警消息的数量，特别是对相同异常对象和相同异常类型的反复告警。以此提高告警的针对性和告警质量，更有利于精确定位异常情况，更有效提高解决异常的效率。

附图说明

图1为本发明一实施例一种提高告警质量的方法的流程示意图；

图2为本发明实施例一一种提高告警质量的方法的流程示意图；

图3为本发明一实施例一种提高告警质量的系统的模块组成及连接示意图。

标号说明：

1、前端应用；2、反向代理服务器；3、实例；4、日志生成模块；

5、日志收集模块；6、日志分析与告警模块。

具体实施方式

为详细说明本发明的技术内容、所实现目的及效果，以下结合实施方式并配合附图予以说明。

本发明最关键的构思在于：在生成异常日志后不直接进行告警，而是自动聚合相同异常错误类以及相同接口的异常日志数量，在规定时间内只发出一条告警消息进行告警提示。

本发明涉及的技术术语解释:

请参照图1，本发明提供一种提高告警质量的方法，包括：

S1：当一实例出现异常时，生成对应的异常日志；所述异常日志中的字段包括异常错误类、异常明细信息、异常接口类型、实例标识以及集群标识；所述异常错误类包括基础服务类和业务服务类；

S2：获取所述异常日志，依据其中的集群标识获取对应集群下各个实例在预设时间段内与所述异常日志的异常接口类型相同的所有异常日志；

S3：若所述所有异常日志的异常错误类均为业务服务类，且依据异常明细信息解析得到异常原因均为非基础服务异常，则判断告警消息表中对应所述预设时间段是否存在与所述异常日志的集群标识、异常接口类型以及异常错误类均相同的告警消息；若不存在，则发送对应所述异常日志的告警消息；若存在，则不对所述异常日志进行处理。

从上述描述可知，本发明的有益效果在于：采用一种全新的告警方式，在业务集群中，当某实例存在异常并生成异常日志时，通过对单节点与集群内其他节点某时间段内的异常偏差进行统计分析，进行同类告警消息聚合，减少告警消息数量。

进一步地，还包括：

S4：若所述所有异常日志的异常错误类均为基础服务类，则判断告警消息表中对应所述预设时间段是否存在与所述异常日志的集群标识、异常接口类型以及异常错误类均相同的告警消息；若不存在，则发送对应所述异常日志的告警消息；若存在，则不对所述异常日志进行处理。

由上述描述可知，针对聚合结果进行再次分析，判断是否统一归属于某个基础服务功能的异常，如果是，则进行告警消息内容变更，将只进行基础服务消息告警消息发送，而无需大量发送业务告警消息，再一次精确定位异常消息，进一步减少告警消息数量，提高解决问题的效率。至此，本发明使用2层告警机制，即业务集群告警方式与基础服务告警方式相结合。

进一步地，所述S3之后，还包括：

S31：若所述所有异常日志的异常错误类均为业务服务类，且依据异常日志中的异常明细信息解析得到异常原因包括基础服务异常，则将所述所有异常日志升级为异常错误类为基础服务异常的异常日志。

由上述描述可知，针对异常错误类为业务服务类，但实际异常原因为基础服务异常而引起的异常情况，本发明将通过上述，通过对异常日志升级，将其划分到基础服务异常情况进行告警，以提高告警消息的准确性，更有利于准确定位异常，快速解决问题。

进一步地，所述S2包括：

S21：获取所述异常日志，依据其中的集群标识获取对应集群的实例标识列表；

S22：依据所述实例标识列表，获取各个实例在预设时间段内与所述异常日志的异常接口类型相同的所有异常日志。

由上述描述可知，实现了对与刚生成的异常日志的接口类型相同，且属于一集群，且在规定时间段内的所有异常日志进行聚合，有利于对该时段内同集群、同异常接口的异常日志进行更准确地分析，更有利于精准定位异常所在。

进一步地，还包括：

记录对应异常日志发出的告警消息至告警消息表，所述告警消息表中的字段包括主键ID、集群标识、异常接口类型、异常错误类和创建时间。

由上述描述可知，通过对告警消息的具体字段进行设定，有利于查询和分析规定时间段内特定告警信息的情况。

请参阅图3，本发明提供的另一个技术方案为：

一种提高告警质量的系统，包括依序连接的日志生成模块、日志收集模块和日志分析与告警模块；

所述日志生成模块，用于当一实例出现异常时，生成对应的异常日志；所述异常日志中的字段包括异常错误类、异常明细信息、异常接口类型、实例标识以及集群标识；所述异常错误类包括基础服务类和业务服务类；

所述日志收集模块，用于收集生成的每一条异常日志；

所述日志分析与告警模块，用于包括：

获取所述异常日志，依据其中的集群标识获取对应集群下各个实例在预设时间段内与所述异常日志的异常接口类型相同的所有异常日志；

若所述所有异常日志的异常错误类均为业务服务类，且依据异常明细信息解析得到异常原因均为非基础服务异常，则判断告警消息表中对应所述预设时间段是否存在与所述异常日志的集群标识、异常接口类型以及异常错误类均相同的告警消息；若不存在，则发送对应所述异常日志的告警消息；若存在，则不对所述异常日志进行处理。

进一步地，所述日志分析与告警模块，还用于：

若所述所有异常日志的异常错误类均为基础服务类，则判断告警消息表中对应所述预设时间段是否存在与所述异常日志的集群标识、异常接口类型以及异常错误类均相同的告警消息；若不存在，则发送对应所述异常日志的告警消息；若存在，则不对所述异常日志进行处理。

进一步地，所述日志分析与告警模块，还用于：

若所述所有异常日志的异常错误类均为业务服务类，且依据异常日志中的异常明细信息解析得到异常原因包括基础服务异常，则将所述所有异常日志升级为异常错误类为基础服务异常的异常日志。

进一步地，所述日志分析与告警模块在用于获取所述异常日志，依据其中的集群标识获取对应集群下各个实例在预设时间段内与所述异常日志的异常接口类型相同的所有异常日志时，具体执行包括：

获取所述异常日志，依据其中的集群标识获取对应集群的实例标识列表；

依据所述实例标识列表，获取各个实例在预设时间段内与所述异常日志的异常接口类型相同的所有异常日志。

进一步地，还包括连接所述日志分析与告警模块的告警消息表存储模块；

所述告警消息表存储模块，用于记录对应异常日志发出的告警消息至告警消息表，所述告警消息表中的字段包括主键ID、集群标识、异常接口类型、异常错误类和创建时间。

从上述描述可知，对应本领域普通技术人员可以理解实现上述技术方案中的全部或部分流程，是可以通过虚拟的功能模块来实现的，所述功能模块的组合，同样能够实现对应各方法的有益效果。

实施例一

请参照图2，本实施例提供一种提高告警质量的方法，其运用于现有的服务端与客户端交互系统，系统包括依序连接的前端应用1(客户端等)、反向代理服务器2(nginx或者SLB等)以及后端应用(一个或多个的WEB服务应用实例)。

本实施例的方法可以包括以下步骤：

S0：针对后端应用实例(后续简称实例)中对外提供服务的接口，进行日志格式的统一规范。具体将原本可能是各种格式的日志统一修改为必须包含以下字段：异异常错误类、异常明细信息、异常接口类型(用于明确是哪一个接口抛出的异常)、实例标识(如ID)以及集群标识(如ID)；其中，所述异常错误类分为两类：基础服务类和业务服务类。也就是说，当上述接口出现错误或者异常(下述统一为异常情况)时，均需要记录包含上述字段的日志信息，生成异常日志。

S1：当某一实例出现异常时，生成对应的异常日志。

例如，A实例的异常日志包括：GetInfoClass(异常错误类)、自身业务错误(异常明细信息)、GetInfo接口(异常接口类型)、实例A(实例id)和UC业务集群(集群id)等信息。

现有的告警方式为生成异常日志的同时还需要发送对应的告警消息，即单实例异常告警方式。在本实施例中，将不直接进行告警消息发送，而是执行下述步骤。

在本实施例中，所有对应异常日志发出的告警消息，都将被记录至告警消息表中。所述告警消息表中的字段包括：主键ID、集群标识、异常接口类型、异常错误类和创建时间。

S10：针对后端应用实例生成的异常日志进行收集和存储。优选地，可以存储在指定的存储区域中，方便快速调用和管理。

S2：获取步骤S1生成的异常日志，依据其中的集群标识获取该集群下各个实例在预设时间段内与所获取的异常日志的异常接口类型相同的所有异常日志。其中，所述预设时间段包括所述异常日志生成的时间点，或者是紧跟所述时间点之后的预设时长内。

在一具体实例中，将具体通过下述步骤来实现：

S21：获取S1生成的异常日志，依据其中的集群标识获取该集群的实例标识列表；一个实例标识列表记载有某一集群下所有实例的标识；

S22：依据所述实例标识列表，获取各个实例在预设时间段内与S1生成的异常日志的异常接口类型相同的所有异常日志。

下述针对S2所获取的所有异常日志进行的分析处理，具体包括两种情况：

一、业务服务异常

具体分为：

1、均为自身业务引起的业务服务异常；

2、部分自身业务原因，部分基础服务原因引起的业务服务异常。

二、基础服务异常，即均为基础服务引起的异常。

S3：若S2获取的所有异常日志的异常错误类均为业务服务类，则属于上述的“一、业务服务异常”情况，将进一步判断：

S30：若依据异常明细信息确定所有异常日志的异常原因均为非基础服务异常，即属于上述“一、”中的“1、”情况，则查询告警消息表中对应所述预设时间段是否存在与S1生成的异常日志的集群标识、异常接口类型以及异常错误类均相同的告警消息；若不存在，即说明还未发出同类型的告警信息，则发送对应所述异常日志的告警消息；若存在，即说明预设时间段内已经发出同类型的告警信息，则不对所述异常日志进行处理，以做到同一类型告警信息，在某一段时间内只会进行一次发送，以此大大减少消息发送数量。

S31：若依据异常明细信息确定所有异常日志的异常原因中部分为基础服务异常，部分为非基础服务异常，即属于上述“一、”中的“2、”情况，则将所有异常日志升级为异常错误类为基础服务异常的异常日志。然后，按照下述基础服务异常的方式进行处理，即执行下述S4；

另外，上述过程只要发送了告警消息，都将记录至告警消息表。

S4：若S2获取的所有异常日志的异常错误类均为基础服务类，则属于上述的“二、基础服务异常”的情况，则判断告警消息表中对应所述预设时间段是否存在与S1生成的异常日志的集群标识、异常接口类型以及异常错误类均相同的告警消息；若不存在，则发送对应所述异常日志的告警消息；若存在，则不对所述异常日志进行处理。

在一具体实例中，将存在专门存储对应基础服务异常的基础服务告警消息表。所述基础服务告警消息表中包括以下字段：主键ID、基础服务id、异常错误类以及创建时间。

因此，在上述S4中，只需在基础服务告警信息中进行判断即可。

本实施例实现了大大减少同类型告警消息的频繁发送，提高告警消息的针对性，提高了告警质量；同时，还实现了精确定位异常类型，有助快速且精确地定位异常所在，帮助更高效解决问题。

例如，某数据库异常，某集群上有10个应用实例依赖它。现有技术中，当该数据库异常，则每分钟每个实例都将生成业务异常消息，则管理系统在每分钟都会收到10条告警消息，而它们本质上都针对同一问题。采用本实施例的方法，将自动聚合同类型的异常消息，最终在规定时间之内只发出一条告警消息，例如，提示某段时间之内某些实例id均出现了同样的问题，通过该条告警消息，工作人员既能结合具体业务类型明确异常情况(由于是连接数据库，因此能够结合具体业务类型明确是数据库的问题)，又能减少处理时间，从而更高效地解决问题。

旧有方式中业务人员明确该问题后，需通知对应基础服务人员处理，此处又耗费时间。在本实施例中，如果明确出来是都是同一个数据库出现问题(当基础服务出现问题时，可以获取到对应基础服务的实例id，根据实例id是否一致来明确是否同一个基础服务实例)，则直接发出一条告警给对应数据库人员，由其进行针对性处理，则可快速解决问题。

综合以上的情况，本实施例不仅能减少告警消息数量，而且有助于精确定位异常信息，可以有效地提高开发人员解决问题的效率。

实施例二

本实施例对应实施例一提供一具体运用场景：

某个公司的帐户系统中存在一个集群，在此称为UC业务集群，该集群下存在3个tomcat应用实例，分别是A实例、B实例以及C实例。应用实例的功能主要提供获取用户信息接口，该接口从mysql数据库中获取用户的信息，并返回给调用方(即前端)。

假设1分钟之内，A实例中获取用户信息接口出现了5次获取用户信息接口失败的异常日志。(假设现有技术该接口1分钟之内出现3次异常则需要告警提示。

而对应实施例一的方法，则将执行包括：

1、若A实例中记录的5次异常日志内容均为：

GetInfoClass(异常错误类)、自身业务错误(异常明细信息)、GetInfo接口(接口类型)、实例A(实例id)和UC业务集群(集群id)。

2、根据异常日志中的集群id获取该集群下的实例ID列表，此时，所获取的实例ID列表中包括A实例、B实例和C实例。

3、根据步骤2中的实例ID列表，查询出该时间段之内，每个实例id关于GetInfo接口的异常日志。假设A实例出现5次，B实例出现2次，C实例出现1次。此时，这8次异常日志还可能存在以下3种场景：

3.1场景：这8次异常日志均为GetInfoClass类自身引起的业务异常(具体可以从异常日志中的异常错误类确定)；

该种场景下，会预先查询告警信息表(该表主要字段为：主键ID、集群id、接口类型、异常错误类和创建时间)；当该表在本时间段内未找到对应UC业务集群、GetInfo接口以及GetInfoClass类的告警消息时，说明还未发出告警消息，则直接发出对应步骤1的告警信息；如果查询到相关告警记录，则说明该时间段内已发出告警消息，此时不做处理，减少告警消息数量。

3.2场景：这8次日志信息中部分为GetInfoClass类自身引起的业务异常，部分为mysql类引起的基础服务异常，最终导致的业务异常。

该种场景下，可以进行2种异常日志的处理：

第一种，按照业务异常方式进行处理，处理步骤与步骤3.1一致；

第二种，说明是因为基础服务异常而引起的业务服务异常，则升级异常日志，按照基础服务异常的处理方式进行处理，处理步骤与如下步骤3.3一致。

3.3场景：这8次日志信息中全部为mysql类引起的基础服务异常，最终导致的业务异常。

该场景下说明全部均为基础服务异常而引起的业务异常。此时，预先查询基础告警信息表(该表主要字段为：主键ID、基础服务id(基础服务的实例id)、异常错误类、创建时间)；当该表在本时间段内未找到相同基础服务ID、基础服务异常类的告警记录时，说明还未发出告警消息，则直接发出告警信息；如果可以查询到相关告警记录，则说明该时间段内已发出告警信息，此时不做处理，减少告警消息数量。

实施例三

本实施例对应实施例一和实施例二，提供一种提高告警质量的系统，请参阅图3，具体包括依序连接的前端应用1(客户端等)、反向代理服务器2(nginx或者SLB等)以及后端应用实例3(一个或多个的WEB服务应用实例)；特别的，所述系统还包括依序连接的日志生成模块4、日志收集模块5和日志分析与告警模块6，其中，对应各个应用实例，将分别设置有所述日志生成模块4。

所述日志生成模块4，用于在对应实例4出现异常时，生成对应的异常日志；所述异常日志中的字段包括异常错误类、异常明细信息、异常接口类型、实例标识以及集群标识；所述异常错误类包括基础服务类和业务服务类；

所述日志收集模块5，优选为ELK日志收集模块，用于收集日志生成模块生成的每一条异常日志，并存储至ELK模块中；

所述日志分析与告警模块6，用于包括：

获取所述异常日志，依据其中的集群标识获取对应集群下各个实例在预设时间段内与所述异常日志的异常接口类型相同的所有异常日志；优选地，具体执行包括：获取所述异常日志，依据其中的集群标识获取对应集群的实例标识列表；依据所述实例标识列表，获取各个实例在预设时间段内与所述异常日志的异常接口类型相同的所有异常日志；

若所述所有异常日志的异常错误类均为业务服务类，且依据异常明细信息解析得到异常原因均为非基础服务异常，则判断告警消息表中对应所述预设时间段是否存在与所述异常日志的集群标识、异常接口类型以及异常错误类均相同的告警消息；若不存在，则发送对应所述异常日志的告警消息；若存在，则不对所述异常日志进行处理。

在一具体实例中，所述日志分析与告警模块，还用于：

若所述所有异常日志的异常错误类均为基础服务类，则判断告警消息表中对应所述预设时间段是否存在与所述异常日志的集群标识、异常接口类型以及异常错误类均相同的告警消息；若不存在，则发送对应所述异常日志的告警消息；若存在，则不对所述异常日志进行处理。

在一具体实例中，所述日志分析与告警模块，还用于：

若所述所有异常日志的异常错误类均为业务服务类，且依据异常日志中的异常明细信息解析得到异常原因包括基础服务异常，则将所述所有异常日志升级为异常错误类为基础服务异常的异常日志。

在一具体实例中，系统还包括连接所述日志分析与告警模块的告警消息表存储模块；

所述告警消息表存储模块，用于记录对应异常日志发出的告警消息至告警消息表，所述告警消息表中的字段包括主键ID、集群标识、异常接口类型、异常错误类和创建时间。

综上所述，本发明提供的一种提高告警质量的方法及其系统，能够对相同异常对象和相同异常类型的异常日志进行聚合，免去反复的告警，大大减少告警数量。由此，不仅能够提高告警的针对性和告警质量，而且有利于精确定位异常情况，从而有效提高解决异常的效率。进一步地，还能判断聚合结果是否统一归属于某个基础服务功能的异常，如果是，则进行告警消息内容变更，将只进行基础服务消息告警消息发送，而无需大量发送业务告警消息，再一次精确定位异常消息，进一步减少告警消息数量，提高解决问题的效率。

以上所述仅为本发明的实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等同变换，或直接或间接运用在相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种提高告警质量的方法，其特征在于，包括：

S1：当一实例出现异常时，生成对应的异常日志；所述异常日志中的字段包括异常错误类、异常明细信息、异常接口类型、实例标识以及集群标识；所述异常错误类包括基础服务类和业务服务类；

S2：获取所述异常日志，依据其中的集群标识获取对应集群下各个实例在预设时间段内与所述异常日志的异常接口类型相同的所有异常日志；

S3：若所述所有异常日志的异常错误类均为业务服务类，且依据异常明细信息解析得到异常原因均为非基础服务异常，则判断告警消息表中对应所述预设时间段是否存在与所述异常日志的集群标识、异常接口类型以及异常错误类均相同的告警消息；若不存在，则发送对应所述异常日志的告警消息；若存在，则不对所述异常日志进行处理；

所述基础服务类指底层的基础服务软件所提供的服务，所述业务服务类指所述基础服务类之外的服务，基础服务异常为均为基础服务引起的异常的情况，所述非基础服务异常指基础服务异常之外情况。

2.如权利要求1所述的一种提高告警质量的方法，其特征在于，还包括：

S4：若所述所有异常日志的异常错误类均为基础服务类，则判断告警消息表中对应所述预设时间段是否存在与所述异常日志的集群标识、异常接口类型以及异常错误类均相同的告警消息；若不存在，则发送对应所述异常日志的告警消息；若存在，则不对所述异常日志进行处理。

3.如权利要求2所述的一种提高告警质量的方法，其特征在于，所述S3之后，还包括：

S31：若所述所有异常日志的异常错误类均为业务服务类，且依据异常日志中的异常明细信息解析得到异常原因包括基础服务异常，则将所述所有异常日志升级为异常错误类为基础服务类的异常日志。

4.如权利要求1所述的一种提高告警质量的方法，其特征在于，所述S2包括：

S21：获取所述异常日志，依据其中的集群标识获取对应集群的实例标识列表；

S22：依据所述实例标识列表，获取各个实例在预设时间段内与所述异常日志的异常接口类型相同的所有异常日志。

5.如权利要求1所述的一种提高告警质量的方法，其特征在于，还包括：

记录对应异常日志发出的告警消息至告警消息表，所述告警消息表中的字段包括主键ID、集群标识、异常接口类型、异常错误类和创建时间。

6.一种提高告警质量的系统，其特征在于，包括依序连接的日志生成模块、日志收集模块和日志分析与告警模块；

所述日志生成模块，用于当一实例出现异常时，生成对应的异常日志；所述异常日志中的字段包括异常错误类、异常明细信息、异常接口类型、实例标识以及集群标识；所述异常错误类包括基础服务类和业务服务类；

所述日志收集模块，用于收集生成的每一条异常日志；

所述日志分析与告警模块，用于包括：

获取所述异常日志，依据其中的集群标识获取对应集群下各个实例在预设时间段内与所述异常日志的异常接口类型相同的所有异常日志；

若所述所有异常日志的异常错误类均为业务服务类，且依据异常明细信息解析得到异常原因均为非基础服务异常，则判断告警消息表中对应所述预设时间段是否存在与所述异常日志的集群标识、异常接口类型以及异常错误类均相同的告警消息；若不存在，则发送对应所述异常日志的告警消息；若存在，则不对所述异常日志进行处理；

所述基础服务类指底层的基础服务软件所提供的服务，所述业务服务类指所述基础服务类之外的服务，基础服务异常为均为基础服务引起的异常的情况，所述非基础服务异常指基础服务异常之外情况。

7.如权利要求6所述的一种提高告警质量的系统，其特征在于，所述日志分析与告警模块，还用于：

若所述所有异常日志的异常错误类均为基础服务类，则判断告警消息表中对应所述预设时间段是否存在与所述异常日志的集群标识、异常接口类型以及异常错误类均相同的告警消息；若不存在，则发送对应所述异常日志的告警消息；若存在，则不对所述异常日志进行处理。

8.如权利要求7所述的一种提高告警质量的系统，其特征在于，所述日志分析与告警模块，还用于：

若所述所有异常日志的异常错误类均为业务服务类，且依据异常日志中的异常明细信息解析得到异常原因包括基础服务异常，则将所述所有异常日志升级为异常错误类为基础服务类的异常日志。

9.如权利要求6所述的一种提高告警质量的系统，其特征在于，所述日志分析与告警模块在用于获取所述异常日志，依据其中的集群标识获取对应集群下各个实例在预设时间段内与所述异常日志的异常接口类型相同的所有异常日志时，具体执行包括：

获取所述异常日志，依据其中的集群标识获取对应集群的实例标识列表；

依据所述实例标识列表，获取各个实例在预设时间段内与所述异常日志的异常接口类型相同的所有异常日志。

10.如权利要求6所述的一种提高告警质量的系统，其特征在于，还包括连接所述日志分析与告警模块的告警消息表存储模块；

所述告警消息表存储模块，用于记录对应异常日志发出的告警消息至告警消息表，所述告警消息表中的字段包括主键ID、集群标识、异常接口类型、异常错误类和创建时间。

Images