CN110888785A - 一种监控告警的方法及装置 - Google Patents

Abstract

本发明提供的一种监控告警的方法及装置，通过对不同类型服务的监控过程进行拆分，得到通用流程，提取不同类型服务的配置信息，得到配置文件，根据所述通用流程和所述配置文件进行监控告警，从监听告警的构架上进行改进，可在根本上解决现有监控告警中存在的误报和非工作时间响应不及时的问题，而且通过通用流程结合配置文件的方式，可在不改变通用流程步骤的情况下，增加新的个性化功能，不仅保证了服务监控的流程通用，还可满足个性化需求。

Description

一种监控告警的方法及装置

技术领域

本发明涉及计算机技术领域，特别涉及一种监控告警的方法及装置。

背景技术

现有监控过程一般通过定时拨测的方式，一次性/或串行发出对多个业务接口/基础服务的请求,解析返回的数据来判断业务接口/基础服务是否正常。在实践的过程中一般也只考虑了将不同类型的接口/服务监控请求区分开触发的时间点，但是对于如何区分不同监控服务的重要性，如何优先进行监控所得异常信息的二次过滤，以及服务发生异常的时间点、已出错次数等因素对错误等级乃至通知方式的影响，未对这些需求进行通盘的考虑，基本都是采用一个标准和有错就报的方式来进行监控的。这样的监控方式往往存在着误报、重复报以及推送后响应不及时，尤其是非工作时间，导致用户体验差。

发明内容

本发明所要解决的技术问题是：一种监控告警的方法及装置，能够有效减少误报和响应不及时问题，提高用户体验。

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

一种监控告警的方法，包括步骤：

S1、对不同类型服务的监控过程进行拆分，得到通用流程；

S2、提取不同类型服务的配置信息，得到配置文件；

S3、根据所述通用流程和所述配置文件进行监控告警。

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

一种监控告警的装置，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现以下步骤：

S1、对不同类型服务的监控过程进行拆分，得到通用流程；

S2、提取不同类型服务的配置信息，得到配置文件；

S3、根据所述通用流程和所述配置文件进行监控告警。

本发明的有益效果在于：通过对不同类型服务的监控过程进行拆分，得到通用流程，提取不同类型服务的配置信息，得到配置文件，根据所述通用流程和所述配置文件进行监控告警，从监听告警的构架上进行改进，可在根本上解决现有监控告警中存在的误报和非工作时间响应不及时的问题，而且通过通用流程结合配置文件的方式，可在不改变通用流程步骤的情况下，增加新的个性化功能，不仅保证了服务监控的流程通用，还可满足个性化需求。

附图说明

图1为本发明实施例的监控告警的方法流程图；

图2为本发明实施例的监控告警的装置的结构示意图；

标号说明：

1、监控告警的装置；2、存储器；3、处理器。

具体实施方式

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

本发明最关键的构思在于:通过对服务的监控过程进行拆分，得到通用流程，提取服务的配置信息，得到配置文件，根据所述通用流程和所述配置文件进行监控告警，从监听告警的构架上进行改进，在根本上解决了误报和非工作时间响应不及时的问题。

请参照图1，一种监控告警的方法，包括步骤：

S1、对不同类型服务的监控过程进行拆分，得到通用流程；

S2、提取不同类型服务的配置信息，得到配置文件；

S3、根据所述通用流程和所述配置文件进行监控告警。

从上述描述可知，本发明的有益效果在于：通过对不同类型服务的监控过程进行拆分，得到通用流程，提取不同类型服务的配置信息，得到配置文件，根据所述通用流程和所述配置文件进行监控告警，从监听告警的构架上进行改进，可在根本上解决现有监控告警中存在的误报和非工作时间响应不及时的问题，而且通过通用流程结合配置文件的方式，可在不改变通用流程步骤的情况下，增加新的个性化功能，不仅保证了服务监控的流程通用，还可满足个性化需求。

进一步的，所述通用流程具体包括：

S11、监控流程，用于采集服务的监控数据，并根据所述监控数据判断所述服务是否正常，若否，则执行步骤S12；

S12、异常处理流程，用于对所述服务进行异常处理，并根据异常处理结果判断是否为误报，若否，则判断是否满足预设条件，若是，执行步骤S13；

S13、推送流程，用于发送监控告警信息。

由上述描述可知，通过配置通用流程包括监控流程、异常处理流程和推送流程，不仅保证了监控告警的安全性，还提高了监控告警的兼容性，便于后续在通用流程的基础上增加个性化功能，可有效满足不同服务的需求，灵活性好。

进一步的，所述配置信息包括服务ID、错误时间、服务类型、错误通知条件、连续出错次数异常处理配置和错误等级计算方式。

由上述描述可知，通过获取服务ID、错误时间、服务类型、错误通知条件、连续出错次数异常处理配置和错误等级计算方式等配置信息，便于后续基于所述配置信息和通用流程进行监控告警，可适用于不同类型服务的监控告警。

进一步的，步骤S3具体包括：

S31、读取第一服务的第一配置信息，并根据所述第一配置信息中第一服务ID启动监控流程判断所述第一服务是否正常，若否，则执行步骤S32；

S32、根据所述第一服务ID和第一服务类型执行相应的异常处理流程，若不是误报且满足第一错误通知条件，则执行步骤S33；

S33、根据所述第一服务类型、第一错误时间、第一连续出错次数和错误等级计算方式计算得到当前错误等级，并根据与所述当前错误等级执行相应的推送流程。

由上述描述可知，通过通用流程和配置信息相结合进行监控告警，在保证灵活性的同时，还提高了监控告警的准确性，通过计算当前错误等级，并根据所述当前错误等级执行相应的推送流程，有效的减少了非工作时间推送后响应不及时，从而提高了用户体验。

进一步的，步骤S12中所述的对所述服务进行异常处理，并根据异常处理结果判断是否为误报具体为：

获取所述服务对应的异常处理配置，得到与所述服务关联的第二服务；

根据所述第二服务进行二次验证，并根据二次验证的结果判断是否为误报。

由上述描述可知，通过获取与所述服务关联的第二服务，根据所述第二服务进行二次验证，并根据二次验证的结果判断是否为误报，提高了监控告警的精确度，可有效减少误报的发生。

请参照图2，一种监控告警的装置1，包括存储器2、处理器3及存储在存储器2上并可在处理器3上运行的计算机程序，所述处理器3执行所述程序时实现以下步骤：

S1、对不同类型服务的监控过程进行拆分，得到通用流程；

S2、提取不同类型服务的配置信息，得到配置文件；

S3、根据所述通用流程和所述配置文件进行监控告警。

从上述描述可知，本发明的有益效果在于：通过对不同类型服务的监控过程进行拆分，得到通用流程，提取不同类型服务的配置信息，得到配置文件，根据所述通用流程和所述配置文件进行监控告警，从监听告警的构架上进行改进，可在根本上解决现有监控告警中存在的误报和非工作时间响应不及时的问题，而且通过通用流程结合配置文件的方式，可在不改变通用流程步骤的情况下，增加新的个性化功能，不仅保证了服务监控的流程通用，还可满足个性化需求。

进一步的，所述通用流程具体包括：

S11、监控流程，用于采集服务的监控数据，并根据所述监控数据判断所述服务是否正常，若否，则执行步骤S12；

S12、异常处理流程，用于对所述服务进行异常处理，并根据异常处理结果判断是否为误报，若否，则判断是否满足预设条件，若是，执行步骤S13；

S13、推送流程，用于发送监控告警信息。

由上述描述可知，通过配置通用流程包括监控流程、异常处理流程和推送流程，不仅保证了监控告警的安全性，还提高了监控告警的兼容性，便于后续在通用流程的基础上增加个性化功能，可有效满足不同服务的需求，灵活性好。

进一步的，所述配置信息包括服务ID、错误时间、服务类型、错误通知条件、连续出错次数异常处理配置和错误等级计算方式。

由上述描述可知，通过获取服务ID、错误时间、服务类型、错误通知条件、连续出错次数异常处理配置和错误等级计算方式等配置信息，便于后续基于所述配置信息和通用流程进行监控告警，可适用于不同类型服务的监控告警。

进一步的，步骤S3具体包括：

S31、读取第一服务的第一配置信息，并根据所述第一配置信息中第一服务ID启动监控流程判断所述第一服务是否正常，若否，则执行步骤S32；

S32、根据所述第一服务ID和第一服务类型执行相应的异常处理流程，若不是误报且满足第一错误通知条件，则执行步骤S33；

S33、根据所述第一服务类型、第一错误时间、第一连续出错次数和错误等级计算方式计算得到当前错误等级，并根据与所述当前错误等级执行相应的推送流程。

由上述描述可知，通过通用流程和配置信息相结合进行监控告警，在保证灵活性的同时，还提高了监控告警的准确性，通过计算当前错误等级，并根据所述当前错误等级执行相应的推送流程，有效的减少了非工作时间推送后响应不及时，从而提高了用户体验。

进一步的，步骤S12中所述的对所述服务进行异常处理，并根据异常处理结果判断是否为误报具体为：

获取所述服务对应的异常处理配置，得到与所述服务关联的第二服务；

根据所述第二服务进行二次验证，并根据二次验证的结果判断是否为误报。

由上述描述可知，通过获取与所述服务关联的第二服务，根据所述第二服务进行二次验证，并根据二次验证的结果判断是否为误报，提高了监控告警的精确度，可有效减少误报的发生。

实施例一

请参照图1，一种监控告警的方法，包括步骤：

S1、对不同类型服务的监控过程进行拆分，得到通用流程；

所述通用流程具体包括：

S11、监控流程，用于采集服务的监控数据，并根据所述监控数据判断所述服务是否正常，若否，则执行步骤S12；

S12、异常处理流程，用于对所述服务进行异常处理，并根据异常处理结果判断是否为误报，若否，则判断是否满足预设条件，若是，执行步骤S13；

S13、推送流程，用于发送监控告警信息；

步骤S12中所述的对所述服务进行异常处理，并根据异常处理结果判断是否为误报具体为：

获取所述服务对应的异常处理配置，得到与所述服务关联的第二服务；

根据所述第二服务进行二次验证，并根据二次验证的结果判断是否为误报；

S2、提取不同类型服务的配置信息，得到配置文件；

所述配置信息包括服务ID、错误时间、服务类型、错误通知条件、连续出错次数异常处理配置和错误等级计算方式；

S3、根据所述通用流程和所述配置文件进行监控告警；

步骤S3具体包括：

S31、读取第一服务的第一配置信息，并根据所述第一配置信息中第一服务ID启动监控流程判断所述第一服务是否正常，若否，则执行步骤S32；

S32、根据所述第一服务ID和第一服务类型执行相应的异常处理流程，若不是误报且满足第一错误通知条件，则执行步骤S33；

S33、根据所述第一服务类型、第一错误时间、第一连续出错次数和错误等级计算方式计算得到当前错误等级，并根据与所述当前错误等级执行相应的推送流程。

实施例二

本实施例将结合具体的应用场景，进一步说明本发明上述监控告警的方法是如何实现的：

1、对不同类型服务的监控过程进行拆分，得到通用流程，所述通用流程具体包括：

1.1、监控流程，用于采集服务的监控数据，并根据所述监控数据判断所述服务是否正常，若否，则执行步骤1.2；

1.2、异常处理流程，用于对所述服务进行异常处理，并根据异常处理结果判断是否为误报，若否，则判断是否满足预设条件，若是，执行步骤1.3；

1.3、推送流程，用于发送监控告警信息；

2、提取不同类型服务的配置信息，得到配置文件，所述配置文件包括监控服务配置文件、服务异常处理配置文件和推送配置文件，并根据配置文件的类型构建相应的配置模块，具体包括：

2.1、根据所述监控服务配置文件构建相应的监控服务配置模块，所述监控服务配置文件中的配置信息包括：服务的ID、错误时间、服务类型、触发频率、连续出错次数、错误通知条件(如每次错误都通知或每连续错误5次通知一次)和服务异常联系人；

2.2、根据所述服务异常处理配置文件构建相应的服务异常处理配置模块，服务异常处理配置文件中的配置信息包括：服务类型和与所述服务类型对应的异常处理流程以及相关的子项(如重试、配对服务验证等)；

配对服务验证的过程和正常监控服务的验证是一样的，都是解析监控请求返还的结果，验证是否符合预期来判断是否正常的(预期结果一般是返回HTTP代码200或对应返回参数的预期值---可以配置在监控服务配置模块中)，关键在于配对服务的选择，一般可以选择有实现上依赖关系，或者业务联系很紧密的服务作为配对服务，如下文例子中提到的，删除订单(相当于第一服务)前要先获取订单(相当于第二服务)以确认订单是否存在，那么意味着获取订单失败的话，删除订单肯定是无法执行成功的。后者可以作为前者配对的服务验证，如果出现获取订单失败而删除订单成功的情况，那么前者误报的概率就很大了；

2.3、根据所述推送配置文件构建相应的推送模块，所述推送配置文件中的配置信息包括：错误等级计算方式和与所述错误等级对应的推送流程；

错误等级计算方式放作为配置信息保存在配置文件中，可根据项目实际需求可以灵活调整，这里可以举一个例子：

错误数值＝服务类型系数*异常时间系数*连续错误次数系数

服务类型系数匹配：高：系数1 中：系数0.5 低：系数0.2，其中高、中和低表示服务类型的重要程度，具体的高：系数1表示当服务类型为高时对应的服务类型系数为1；

异常时间系数匹配：0：00-08：00：系数0.2 08：00-18：00：系数0.5 18：00-24：00：系数1，其中，0：00-08：00、08：00-18：00和18：00-24：00表示一天中不同的时间段，具体的0：00-08：00：系数0.2表示在0点至早上8点出现异常时对应的异常时间系数为0.2；

连续出错次数系数匹配：首次出错：系数1连续出错5次：系数1.5 连续出错10次及以上：系数2

错误等级＝3级 (0.04<＝错误数值<0.25)

2级 (0.25<＝错误数值<1)

1级 (错误数值>＝1)

3、在指定的时间启动监控流程，采集服务的监控数据，并根据所述监控数据判断所述服务是否正常，若否，则执行步骤4；

如果数据返回正常，则判断当前监控的服务正常，把监控的返回写入正常日志，重置服务连续出错次数后，结束本次监控；

4、异常处理流程，用于对所述服务进行异常处理，并根据异常处理结果判断是否为误报，若否，则判断是否满足预设条件，若是，执行步骤5；

所述的对所述服务进行异常处理，并根据异常处理结果判断是否为误报具体为：

获取所述服务对应的异常处理配置，得到与所述服务关联的第二服务；

根据所述第二服务进行二次验证，并根据二次验证的结果判断是否为误报；

若证实为误报，实际服务正常，则结果写入正常日志，同样重置服务连续出错次数后，结束本次监控；

若证实服务确实异常(配对服务验证的过程和正常监控服务的验证是一样的，都是解析监控请求返还的结果，验证是否符合预期来判断是否正常的预期结果一般是返回HTTP代码200或对应返回参数的预期值---可以配置在监控服务配置模块中)，则返回写入异常日志，同时服务的连续错误次数加1；

若满足预设条件，则读取与计算错误等级相关的配置信息，计算当前错误等级，并根据与所述当前错误等级执行相应的推送流程；

5、通过推送流程发送监控告警信息至服务异常联系人；

本方案主要将服务监控、异常信息过滤、告警推送等核心功能进行拆分，得到底层的通用流程+上层的配置文件，底层的通用流程负责将整个监控过程中的通用步骤用代码实现串联起来，在通用流程中针对不同的监控服务个性化的信息，比如服务ID、触发频率、告警条件等配置信息，要做到兼容支持并抽象成对应的接口参数，每次执行对应服务监控都是通用流程调用+配置文件读取传参的过程，保证了web服务监控的流程通用和个性化需求的满足；

如果想要进行扩展的话，在不改变通用流程步骤的情况下，一般只需要在对应流程模块下兼容一个新的个性化能力即可，例如在服务异常处理配置模块中，现在打算新加一个“后台日志搜索匹配”的策略项，大体思路是针对服务异常返回的错误码或者异常信息，到后台中指定时间段去搜索，如果匹配的到，就认为服务确实异常，如果没有匹配到，则判断为误报(需要异常日志实时写入后台)，底层通用流程不变，只需要在服务异常处理配置模块中，新增一种类型支持上述思路的实现，有异常服务需要用到该策略，就在该服务的异常处理策略中配置上该类型，如果不用，则保持原有配置，不会受到影响。

实施例三

本实施例将结合实际的应用场景，以Web应用查询订单信息返回失败为例进行说明：

1.凌晨两点，读取监控服务配置信息，发起对接口获取订单信息的请求，分析接口返回后发现获取订单信息失败，进入异常处理流程；

2.进入异常处理流程后，读取获取订单信息的异常处理配置(重试两次和辅助接口配对---删除订单接口)；

3.执行所述异常处理配置，重试------又重新发起两次获取订单信息的请求，返回仍然失败后执行第二步辅助接口配对，发起对删除订单接口的请求(删除订单前业务会先获取订单信息以确保订单存在，两个接口有依赖关系可作为辅助判断依据)，分析返回后发现删除订单也失败了；

4.判断前面获取订单信息的异常返回非误报，相关信息记录到异常日志中，同时将监控服务配置中的获取订单信息接口连续出错次数加1.

5.根据之前获取到获取订单接口配置，该接口属于中等业务类型接口，监控之前连续出错次数为0，错误通知条件为：首次错误推送，之后每连续5次错误推送一次，接口联系人为小王(包含小王的邮箱微信手机号码信息)具体的通知方式可根据实际需要进行选择，并不仅限于本实施中所述三种通知方式；

6.判断当前为首次错误，符合推送要求，于是读取推送配置，根据配置中的错误等级计算公式，结合传入的错误信息，当前连续出错次数，接口服务类型，服务异常时间点这些参数，计算出当前错误等级为3级，匹配对应通知方式为邮件通知，将相关信息发邮件给小王；

7.小王凌晨正在休息，没有及时查看邮件，获取订单信息接口仍然在持续报错，等到凌晨五点，该接口连续第六次出错，再次触发推送要求，结合连续出错次数和异常时间点，将错误等级升级为2级，相关信息以微信的方式通知给小王；

8.小王仍然未能及时查看消息，获取订单信息接口继续报错，等到早上八点，接口已经连续11次出错，再次触发推送要求，根据错误等级公式将错误等级升级为1级，直接打电话通知了小王；

9.小王收到电话后以最快的速度修复了故障，等到下次监控请求发起后，获取订单信息接口返回正常，将该接口连续出错次数重置为0，相关信息写入正常日志。

实施例四

请参照图2，一种监控告警的装置1，包括存储器2、处理器3及存储在存储器2上并可在处理器3上运行的计算机程序，所述处理器3执行所述程序时实现实施例一中的各个步骤。

综上所述，本发明提供的一种监控告警的方法及装置，通过对不同类型服务的监控过程进行拆分，得到通用流程，提取不同类型服务的配置信息，得到配置文件，根据所述通用流程和所述配置文件进行监控告警，从监听告警的构架上进行改进，可在根本上解决现有监控告警中存在的误报和非工作时间响应不及时的问题，而且通过通用流程结合配置文件的方式，可在不改变通用流程步骤的情况下，增加新的个性化功能，不仅保证了服务监控的流程通用，还可满足个性化需求，通过通用流程和配置信息相结合进行监控告警，在保证灵活性的同时，还提高了监控告警的准确性，通过计算当前错误等级，并根据所述当前错误等级执行相应的推送流程，有效的减少了非工作时间推送后响应不及时，从而提高了用户体验，通过获取与所述服务关联的第二服务，根据所述第二服务进行二次验证，并根据二次验证的结果判断是否为误报，提高了监控告警的精确度，可有效减少误报的发生。

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

Claims (10)

1.一种监控告警的方法，其特征在于，包括步骤：

S1、对不同类型服务的监控过程进行拆分，得到通用流程；

S2、提取不同类型服务的配置信息，得到配置文件；

S3、根据所述通用流程和所述配置文件进行监控告警。

2.根据权利要求1所述的监控告警的方法，其特征在于，所述通用流程具体包括：

S11、监控流程，用于采集服务的监控数据，并根据所述监控数据判断所述服务是否正常，若否，则执行步骤S12；

S12、异常处理流程，用于对所述服务进行异常处理，并根据异常处理结果判断是否为误报，若否，则判断是否满足预设条件，若是，执行步骤S13；

S13、推送流程，用于发送监控告警信息。

3.根据权利要求2所述的监控告警的方法，其特征在于，所述配置信息包括服务ID、错误时间、服务类型、错误通知条件、连续出错次数异常处理配置和错误等级计算方式。

4.根据权利要求3所述的监控告警的方法，其特征在于，步骤S3具体包括：

S31、读取第一服务的第一配置信息，并根据所述第一配置信息中第一服务ID启动监控流程判断所述第一服务是否正常，若否，则执行步骤S32；

S32、根据所述第一服务ID和第一服务类型执行相应的异常处理流程，若不是误报且满足第一错误通知条件，则执行步骤S33；

S33、根据所述第一服务类型、第一错误时间、第一连续出错次数和错误等级计算方式计算得到当前错误等级，并根据与所述当前错误等级执行相应的推送流程。

5.根据权利要求2所述的监控告警的方法，其特征在于，步骤S12中所述的对所述服务进行异常处理，并根据异常处理结果判断是否为误报具体为：

获取所述服务对应的异常处理配置，得到与所述服务关联的第二服务；

根据所述第二服务进行二次验证，并根据二次验证的结果判断是否为误报。

6.一种监控告警的装置，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现以下步骤：

S1、对不同类型服务的监控过程进行拆分，得到通用流程；

S2、提取不同类型服务的配置信息，得到配置文件；

S3、根据所述通用流程和所述配置文件进行监控告警。

7.根据权利要求6所述的监控告警的装置，其特征在于，所述通用流程具体包括：

S11、监控流程，用于采集服务的监控数据，并根据所述监控数据判断所述服务是否正常，若否，则执行步骤S12；

S12、异常处理流程，用于对所述服务进行异常处理，并根据异常处理结果判断是否为误报，若否，则判断是否满足预设条件，若是，执行步骤S13；

S13、推送流程，用于发送监控告警信息。

8.根据权利要求7所述的监控告警的装置，其特征在于，所述配置信息包括服务ID、错误时间、服务类型、错误通知条件、连续出错次数异常处理配置和错误等级计算方式。

9.根据权利要求8所述的监控告警的装置，其特征在于，步骤S3具体包括：

S31、读取第一服务的第一配置信息，并根据所述第一配置信息中第一服务ID启动监控流程判断所述第一服务是否正常，若否，则执行步骤S32；

S32、根据所述第一服务ID和第一服务类型执行相应的异常处理流程，若不是误报且满足第一错误通知条件，则执行步骤S33；

S33、根据所述第一服务类型、第一错误时间、第一连续出错次数和错误等级计算方式计算得到当前错误等级，并根据与所述当前错误等级执行相应的推送流程。

10.根据权利要求7所述的监控告警的装置，其特征在于，步骤S12中所述的对所述服务进行异常处理，并根据异常处理结果判断是否为误报具体为：

获取所述服务对应的异常处理配置，得到与所述服务关联的第二服务；

根据所述第二服务进行二次验证，并根据二次验证的结果判断是否为误报。

Images