基于应用性能数据的告警方法、系统、设备和存储介质与流程

1.本发明涉及计算机应用技术领域，更为具体而言，涉及一种基于应用性能数据的告警方法、系统、设备和存储介质。


背景技术：

2.随着公司开发部署系统的日渐增多，并且一个系统通常又由许多不同的应用组成，应用和应用之间、系统和系统之间需要必要的通信才能完成业务需求，使得应用、系统的调用关系日渐复杂。传统的性能监控技术主要是针对单个应用的性能监测，但是面向主机、网络、数据库、单应用的监控都是孤立、单独的监控与管理，无法识别整个系统的性能或解决整个系统的根源问题。同时，由于缺乏完整的监控体系以及快速故障定位的能力，传统的性能监控技术也无法在第一时间获悉异常实例与服务，使得日常故障排查的实现较为困难。
3.此外，目前的监控技术还存在指标单一、监控颗粒度粗、报警监控的时效性差，无法达到实时业务监控要求等问题。


技术实现要素：

4.为解决上述现有技术存在的问题或部分问题，本发明实施方式提供了一种基于应用性能数据的告警方法、系统、设备和存储介质，可以实现多维度、细粒度监控统一管理，并且，当采集到的应用性能数据触发报警规则时及时发送报警信息，可以实现自动化、近实时的主动预警，避免造成严重的业务影响。
5.根据本发明的第一方面，本发明实施方式提供了一种基于应用性能数据的告警方法，其包括：获取针对应用服务、应用实例、应用接口的待更新的报警监控规则并确定所述待更新的报警监控规则对应的节点，所述报警监控规则包括报警阀值和报警次数；当所述对应的节点中的至少一个节点拉取所述待更新的报警监控规则时，更新待同步节点数；当所述待同步节点数与所述对应的节点的个数相同时，所述待更新的报警监控规则生效；当采集到的应用性能数据超过所述报警阈值的次数大于等于所述报警次数时，发送报警信息。
6.根据本发明上述实施方式，通过获取应用服务、应用实例、应用接口三个维度的新报警监控规则，并在新报警监控规则对应的所有节点都获取到该规则后再使所有节点拉取的新规则生效，可以实现多维度、细粒度监控统一管理。并且，当采集到的应用性能数据触发报警规则时及时发送报警信息，可以实现自动化、近实时的主动预警，避免造成严重的业务影响。
7.在本发明的一些实施方式中，所述告警方法还包括：根据所述报警信息确定故障应用服务，并降低所述故障应用服务的优先级、增加所述故障应用服务对应的正常节点或增加所述故障应用服务的服务器资源量。
8.根据本发明上述实施方式，通过报警信息快速确定故障应用服务，并通过降低故
障应用服务的优先级、增加故障应用服务对应的正常节点或增加故障应用服务的服务器资源量，可以将故障影响的范围降低到最低。
9.在本发明的一些实施方式中，所述告警方法还包括：基于字节码增强技术对所述应用服务部署并加载探针；通过所述探针采集所述应用服务的所述应用性能数据。
10.根据本发明上述实施方式，通过字节码增强技术加载探针，可以在无代码侵入的情况下完成探针部署，并通过加载探针高效实时地采集系统内众多且复杂的应用服务对应的应用性能数据。
11.在本发明的一些实施方式中，所述告警方法还包括：当所述应用服务作为调用链路的初始应用服务时，所述初始应用服务的探针生成该初始应用服务的追踪参数，并将所述追踪参数按照所述调用链路中的应用服务调用顺序传递至所述调用链路上的每个应用服务；以及根据所述追踪参数生成基于所述调用链路的链路追踪信息。
12.在本发明的一些实施方式中，所述告警方法还包括：根据所述链路追踪信息和报警信息确定故障应用服务之间的依赖关系和故障影响范围。
13.根据本发明上述实施方式，通过调用链路的初始应用服务的探针生成追踪参数并传递至该调用链路上的每个应用服务，以生成调用链路的链路追踪信息，能够基于该链路追踪信息快速简便地判断故障的影响范围以及故障应用之间的依赖关系，以便快速制定故障恢复的方案，降低故障影响范围。
14.根据本发明的第二方面，本发明实施方式提供了一种基于应用性能数据的告警系统，其包括：规则更新模块，用于获取针对应用服务、应用实例、应用接口的待更新的报警监控规则并确定所述待更新的报警监控规则对应的节点，所述报警监控规则包括报警阀值和报警次数；规则同步模块，用于当所述对应的节点中的至少一个节点拉取所述待更新的报警监控规则时，更新待同步节点数；规则生效模块，用于当所述待同步节点数与所述对应的节点的个数相同时，所述待更新的报警监控规则生效；报警模块，用于当采集到的应用性能数据超过所述报警阈值的次数大于等于所述报警次数时，发送报警信息。
15.根据本发明上述实施方式，通过获取应用服务、应用实例、应用接口三个维度的新报警监控规则，并在新报警监控规则对应的所有节点都获取到该规则后再使所有节点拉取的新规则生效，可以实现多维度、细粒度监控统一管理。并且，当采集到的应用性能数据触发报警规则时及时发送报警信息，可以实现自动化、近实时的主动预警，避免造成严重的业务影响。
16.在本发明的一些实施方式中，所述告警系统还包括：故障处理模块，用于根据所述报警信息确定故障应用服务，并降低所述故障应用服务的优先级、增加所述故障应用服务对应的正常节点或增加所述故障应用服务的服务器资源量。
17.根据本发明上述实施方式，通过报警信息快速确定故障应用服务，并通过降低故障应用服务的优先级、增加故障应用服务对应的正常节点或增加故障应用服务的服务器资源量，可以将故障影响的范围降低到最低。
18.在本发明的一些实施方式中，所述告警系统还包括数据获取模块，用于执行下述操作：基于字节码增强技术对所述应用服务部署并加载探针；通过所述探针采集所述应用服务的所述应用性能数据。
19.根据本发明上述实施方式，通过字节码增强技术加载探针，可以在无代码侵入的
情况下完成探针部署，并通过加载探针高效实时地采集系统内众多且复杂的应用服务对应的应用性能数据。
20.在本发明的一些实施方式中，所述告警系统还包括信息生成模块，用于执行下述操作：当所述应用服务作为调用链路的初始应用服务时，所述初始应用服务的探针生成该初始应用服务的追踪参数，并将所述追踪参数按照所述调用链路中的应用服务调用顺序传递至所述调用链路上的每个应用服务；以及根据所述追踪参数生成基于所述调用链路的链路追踪信息。
21.在本发明的一些实施方式中，所述告警系统还包括故障追踪模块，用于根据所述链路追踪信息和报警信息确定故障应用服务之间的依赖关系和故障影响范围。
22.根据本发明上述实施方式，通过调用链路的初始应用服务的探针生成追踪参数并传递至该调用链路上的每个应用服务，以生成调用链路的链路追踪信息，能够基于该链路追踪信息快速简便地判断故障的影响范围以及故障应用之间的依赖关系，以便快速制定故障恢复的方案，降低故障影响范围。
23.根据本发明的第三方面，本发明实施方式提供一种计算机可读存储介质，其上存储有计算机可读指令，所述计算机可读指令被处理器执行时，使得计算机执行如下操作：所述操作包括如上任意一种实施方式所述告警方法所包含的步骤。
24.根据本发明的第四方面，本发明实施方式提供一种包括存储器和处理器的计算机设备，所述存储器存储有计算机可读指令，其中，所述计算机可读指令被所述处理器执行时能够实现如上任意一种实施方式所述的告警方法。
25.由上述可知，实施本发明提供的基于应用性能数据的告警方法、系统、设备和存储介质，通过获取多个维度的新报警监控规则，并在新报警监控规则对应的所有节点都获取到该规则后再使所有节点拉取的新规则生效，可以实现多维度、细粒度监控统一管理。并且，当采集到的应用性能数据触发报警规则时及时发送报警信息，可以实现自动化、近实时的主动预警，避免造成严重的业务影响。
附图说明
26.图1是根据本发明一种实施方式的基于应用性能数据的告警方法的流程示意图；
27.图2是根据本发明一种进一步实施方式的基于应用性能数据的告警方法的流程示意图；
28.图3是根据本发明一种实施方式的基于应用性能数据的告警系统的架构图。
具体实施方式
29.以下结合附图和具体实施方式对本发明的各个方面进行详细阐述。其中，众所周知的模块、单元及其相互之间的连接、链接、通信或操作没有示出或未作详细说明。并且，所描述的特征、架构或功能可在一个或一个以上实施方式中以任何方式组合。本领域技术人员应当理解，下述的各种实施方式只用于举例说明，而非用于限制本发明的保护范围。还可以容易理解，本文所述和附图所示的各实施方式中的模块或单元或处理方式可以按各种不同配置进行组合和设计。
30.下面对本文中使用的术语进行简要说明。
31.elasticsearch：一种分布式、高扩展、高实时的搜索与数据分析的引擎。
32.aop：面向切面编程。
33.mpsc：multi producer single consumer，多生产者单消费者队列。
34.oom：out of memory，内存溢出。
35.webhook：用户通过自定义回调的方式来改变应用的一种行为。
36.uuid：universally unique identifier，通用唯一识别码。
37.图1是根据本发明一种实施方式的基于应用性能数据的告警方法的流程示意图。
38.如图1所示，在本发明的一种实施方式中，所述告警方法可包括：步骤s11、步骤s12、步骤s13和步骤s14，下面对上述步骤进行具体的描述。
39.在步骤s11中，获取针对应用服务、应用实例、应用接口的待更新的报警监控规则并确定所述待更新的报警监控规则对应的节点，所述报警监控规则包括报警阀值和报警次数。在一些实施方式中，所述报警监控规则包括但不限于下述一种或多种：报警指标、报警阀值、操作符、报警周期、报警次数、静默时间、响应时间、平均响应时间、接口请求成功率、调用次数、每分钟的调用次数、应用服务实例的请求成功率。
40.在进一步实施方式中，所述报警监控规则针对应用服务、应用实例、应用接口三个维度，并且针对不同维度的不同对象均能够制定单独的个性化规则，此外，还可以针对不同的节点制定不同的报警规则。由此，可以针对每个服务分别制定不同的报警监控规则，并且每个接入的服务可制定的报警监控规则种类和数目无限制，服务和报警监控规则之间是一对多的关系，服务和服务之间的报警规则互不影响。同时，针对每个接口进行差异化报警监控规则配置，可以满足各类服务不同的监控报警的需求；针对目前服务多节点部署的环境进行对各节点的报警监控规则制定，可以适配不同集群或者不同机房的资源差异性带来的服务质量区别。
41.在一些实施方式中，通过报警监控规则配置平台为需要监控的应用服务、应用实例和应用接口新增待更新的报警监控规则配置。具体而言，根据应用服务id、应用实例id、应用接口id与报警监控规则进行绑定后，存储到elasticsearch中，并将该待更新的报警监控规则对应的同步状态设置为更新；多节点部署的观测平台以预设周期从所述elasticsearch中拉取待更新的报警监控规则配置至内存中，例如每5分钟拉取一次待更新的报警监控规则配置。
42.在步骤s12中，当所述对应的节点中的至少一个节点拉取所述待更新的报警监控规则时，更新待同步节点数。在一些实施方式中，当待更新的报警监控规则对应的节点中的一个拉取规则时，将待同步节点数的数量+1。
43.在步骤s13中，当所述待同步节点数与所述对应的节点的个数相同时，所述待更新的报警监控规则生效。在所有节点全部拉取待更新的报警监控规则到内存后，该待更新的报警监控规则才生效，可以避免多节点内存中的报警规则不一致的问题。
44.在步骤s14中，当采集到的应用性能数据超过所述报警阈值的次数大于等于所述报警次数时，发送报警信息。其中，全量采集的应用性能数据包括但不限于一种或多种：调用接口的响应时间、调用接口在某段时间内的平均响应时间、调用接口本次调用的成功状态、调用接口某段时间的成功率、调用接口某段时间的调用次数等等。在一些实施方式中，每经过一个周期的时间轮询，如果采集到的应用性能数据达到发送告警信息的标准，则以
线程池异步的方式调用webhook接口发送告警信息，具体而言，webhook接口由使用者自行定义，从而可以在指定的webhook接口中自行编写各种告警方式，例如钉钉告警、邮件告警、企业微信告警等等。在进一步实施方式中，当需要发送告警信息时，定时监测是否在处于静默期内，若不处于静默期内才发送告警信息。
45.在一些实施方式中，基于报警监控规则的报警是通过时间窗口滑块的设计方式进行监控报警，举例而言，首先，每分钟滑动一个时间窗口(1分钟)，探针上报某个接口的应用性能数据；然后，初始化该报警监控规则的时间窗口，当该时间窗口内的应用性能数据超过报警监控规则的阈值，则记录本次命中报警规则，使得应用性能数据超过报警阈值的次数+1，当采集到的应用性能数据超过报警阈值的次数大于等于报警次数，并且不在静默期内时，发送报警信息。
46.采用本发明实施方式的上述管理应用配置的方法，通过获取应用服务、应用实例、应用接口三个维度的新报警监控规则，并在新报警监控规则对应的所有节点都获取到该规则后再使所有节点拉取的新规则生效，可以实现多维度、细粒度监控统一管理。并且，当采集到的应用性能数据触发报警规则时及时发送报警信息，可以实现自动化、近实时的主动预警，避免造成严重的业务影响。
47.在进一步实施方式中，根据所述报警信息确定故障应用服务，并降低所述故障应用服务的优先级、增加所述故障应用服务对应的正常节点或增加所述故障应用服务的服务器资源量。由此，可以将故障影响的范围降低到最低。
48.在一些实施方式中，通过下述方法采集所述应用性能数据：基于字节码增强技术对应用服务部署并加载探针；通过所述探针采集所述应用服务的所述应用性能数据。具体而言，基于java agent探针技术，通过字节码注入的方式实现调用拦截和数据收集，可以做到真正的代码无侵入，只需要在启动服务器的时候添加报警监控系统(可观测平台)的地址和接入该报警监控系统的应用名称，以确定探针采集数据的接收方以及探针采集到的数据的数据生成方，就可以完成探针的部署，进而通过探针完成待监控的应用性能数据的收集、分析、汇总，最终将汇总的数据定时储存到web界面供使用者进行直观的观测，例如应用性能监控平台根据不同的性能监控指标，根据探针收集的数据进行计算最终生成监控指标数据，可视化平台通过暴露的接口获取监控指标数据，展示在前端供用户使用。在进一步的实施方式中，从服务和云原生基础设施收集应用性能数据，并对采集到的应用性能数据进行分析、聚合及可视化展示，可以看到服务与端点之间的拓扑结构，以及每个应用服务、应用实例、应用接口的各种性能指标。
49.通过无侵入性部署和加载探针，被监控本身的系统发生故障时，不会对探针采集应用性能数据的过程造成任何影响，并且通过探针监控对应用运行的性能损耗很小，低于5％，可以在无代码侵入的情况下完成探针部署，并通过加载探针高效实时地采集系统内众多且复杂的应用服务对应的应用性能数据。
50.在一些实施方式中，java agent内插件开发所使用的aop机制是基于模板方法模式实现的，该方法可以实现有效的风控效果，即使插件的实现逻辑有异常也不影响接入应用的用户逻辑的执行。在可选的实施方式中，通过插件采集应用性能数据的逻辑和上报应用性能数据的逻辑之间应用轻量级的无锁环形队列进行解耦，达到在上报数据时不对采集数据的动作造成影响的效果，以实现对应用的保护，并且，该无锁环形队列在mpsc场景下性
能较好，同时，该无锁环形队列采用满时丢弃的策略，避免积压阻塞和oom。
51.在一些实施方式中，通过自定义类加载器来加载管理插件类，可以增强探针功能，以避免对接入的系统产生冲突和污染。举例而言，接入的应用使用了mysql数据库，探针就会可选择加载mysql的插件，探针进而可以获取到mysql的使用指标，如执行的sql内容、sql执行时间等。除数据库类的插件外，插件还包括web服务器、httpclient、mq、redis等中间件的插件。通过自定义类加载器使探针本身加载的插件和应用使用的中间件之间相互不影响，例如对于mysql的插件而言，不因为探针加载的mysql插件，而影响应用使用的mysql数据库。
52.在进一步实施方式中，当所述应用服务作为调用链路的初始应用服务时，所述初始应用服务的探针生成该初始应用服务的追踪参数，并将所述追踪参数按照所述调用链路中的应用服务调用顺序传递至所述调用链路上的每个应用服务；以及根据所述追踪参数生成基于所述调用链路的链路追踪信息。更进一步的，根据所述链路追踪信息和报警信息确定故障应用服务之间的依赖关系和故障影响范围。其中，所述追踪参数包括但不限于：traceid(追踪id)、应用服务id和链路序号。
53.通过调用链路的初始应用服务的探针生成追踪参数并传递至该调用链路上的每个应用服务，以生成调用链路的链路追踪信息，能够基于该链路追踪信息快速简便地判断故障的影响范围以及故障应用之间的依赖关系，以便快速制定故障恢复的方案，降低故障影响范围。
54.本发明给出一种进一步实施方式的基于应用性能数据的告警方法，采用该方法通过追踪参数生成基于调用链路的链路追踪信息，由此可以基于该链路追踪信息快速简便地判断故障的影响范围以及故障应用之间的依赖关系，以便快速制定故障恢复的方案，降低故障影响范围。如图2所示，该进一步实施方式的基于应用性能数据的告警方法包括如下步骤：
55.步骤1，接入的应用(服务)分别部署加载探针；
56.步骤2a，应用a通过http请求调用应用b的接口；
57.步骤2b，应用a的探针生成全局唯一的traceid和此应用的ida以及链路序号01，在应用a通过http请求调用应用b的接口的同时，把生成的链路追踪的参数传递给应用b。其中，当应用发起http请求调用时，探针会针对此次调用，采用类似雪花算法(32位uuid+当前线程id+当前时间戳+4位随机数)的方式，生成一个全局唯一的traceid；
58.步骤3a，应用b通过http请求调用应用c的接口；
59.步骤3b，应用b的探针通过应用a的探针传递的traceid和应用b的idb以及链路序号02，在应用b通过http请求调用应用c的接口的同时，把生成的链路追踪的参数传递给应用c；
60.步骤4a，应用c通过http请求调用应用d的接口；
61.步骤4b，应用c通过应用b的探针传递的traceid和应用c的idc以及链路序号03，在应用c通过http请求调用应用d的接口的同时，把生成的链路追踪的参数传递给应用d；
62.步骤5，应用d完成代码逻辑最终返回http请求的数据；
63.步骤6，应用d的探针把此次整个请求的调用路径(a
→b→c→
d)的链路追踪信息：traceid、ida和链路序号01、idb和链路序号02、idc和链路序号03、idd和链路序号04，上传
到监控系统的存储介质进行存储。
64.在进一步实施方式中，当故障发生时，根据保存在存储介质中的traceid，可以快速依据traceid检索出整个http请求所经过的所有应用及调用方向，从而判断出故障的影响范围。举例而言，针对确定的慢请求，可以根据链路追踪信息快速找到慢请求的来源，并分析调用链路上所有服务的性能问题，确定慢请求的影响范围
65.在一些实施方式中，本发明一种实施方式的告警方法还包括下述删除报警监控规则的步骤：(1)按照业务和服务的实际情况在报警监控规则配置平台删除报警监控规则，并将该待删除的报警监控规则对应的同步状态设置为删除；(2)，当可观测平台中待删除的报警监控规则对应的节点中的一个拉取删除状态的报警监控规则时，将待同步节点数的数量+1：(3)可观测平台待检查同步节点的数量，当待检查同步节点的数量与待删除的报警监控规则对应的节点个数相同时，删除该报警监控规则。
66.图3是根据本发明一种实施方式的基于应用性能数据的告警系统的架构图。
67.如图3所示，所述告警系统包括：
68.规则更新模块310，用于获取针对应用服务、应用实例、应用接口的待更新的报警监控规则并确定所述待更新的报警监控规则对应的节点，所述报警监控规则包括报警阀值和报警次数。在一些实施方式中，所述报警监控规则包括但不限于下述一种或多种：报警指标、报警阀值、操作符、报警周期、报警次数、静默时间、响应时间、平均响应时间、接口请求成功率、调用次数、每分钟的调用次数、应用服务实例的请求成功率。
69.在进一步实施方式中，所述报警监控规则针对应用服务、应用实例、应用接口三个维度，并且针对不同维度的不同对象均能够制定单独的个性化规则，此外，还可以针对不同的节点制定不同的报警规则。由此，可以针对每个服务分别制定不同的报警监控规则，并且每个接入的服务可制定的报警监控规则种类和数目无限制，服务和报警监控规则之间是一对多的关系，服务和服务之间的报警规则互不影响。同时，针对每个接口进行差异化报警监控规则配置，可以满足各类服务不同的监控报警的需求；针对目前服务多节点部署的环境进行对各节点的报警监控规则制定，可以适配不同集群或者不同机房的资源差异性带来的服务质量区别。
70.规则同步模块320，用于当所述对应的节点中的至少一个节点拉取所述待更新的报警监控规则时，更新待同步节点数。在一些实施方式中，当待更新的报警监控规则对应的节点中的一个拉取规则时，将待同步节点数的数量+1。
71.规则生效模块330，用于当所述待同步节点数与所述对应的节点的个数相同时，所述待更新的报警监控规则生效。
72.数据获取模块340，用于基于字节码增强技术对所述应用服务部署并加载探针；通过所述探针采集所述应用服务的应用性能数据。具体而言，基于java agent探针技术，通过字节码注入的方式实现调用拦截和数据收集，可以做到真正的代码无侵入，只需要在启动服务器的时候添加报警监控系统(可观测平台)的地址和接入该报警监控系统的应用名称，就可以完成探针的部署，进而通过探针完成待监控的应用性能数据的收集、分析、汇总，最终将汇总的数据定时储存到web界面供使用者进行直观的观测，例如应用性能监控平台根据不同的性能监控指标，根据探针收集的数据进行计算最终生成监控指标数据，可视化平台通过暴露的接口获取监控指标数据，展示在前端供用户使用。通过无侵入性部署和加载
探针，被监控本身的系统发生故障时，不会对探针采集应用性能数据的过程造成任何影响，并且通过探针监控对应用运行的性能损耗很小，低于5％，可以在无代码侵入的情况下完成探针部署，并通过加载探针高效实时地采集系统内众多且复杂的应用服务对应的应用性能数据。
73.报警模块350，用于当采集到的所述应用性能数据超过所述报警阈值的次数大于等于所述报警次数时，发送报警信息。其中，全量采集的的应用性能数据包括但不限于一种或多种：调用接口的响应时间、调用接口在某段时间内的平均响应时间、调用接口本次调用的成功状态、调用接口某段时间的成功率、调用接口某段时间的调用次数等等。在一些实施方式中，每经过一个周期的时间轮询，如果采集到的应用性能数据达到发送告警信息的标准，则以线程池异步的方式调用webhook接口发送告警信息，具体而言，webhook接口由使用者自行定义，从而可以在指定的webhook接口中自行编写各种告警方式，例如钉钉告警、邮件告警、企业微信告警等等。在进一步实施方式中，当需要发送告警信息时，定时监测是否在处于静默期内，若不处于静默期内才发送告警信息。
74.故障处理模块360，用于根据所述报警信息确定故障应用服务，并降低所述故障应用服务的优先级、增加所述故障应用服务对应的正常节点或增加所述故障应用服务的服务器资源量。由此，可以将故障影响的范围降低到最低。
75.信息生成模块370，用于当所述应用服务作为调用链路的初始应用服务时，所述初始应用服务的探针生成该初始应用服务的追踪参数，并将所述追踪参数按照所述调用链路中的应用服务调用顺序传递至所述调用链路上的每个应用服务；以及根据所述追踪参数生成基于所述调用链路的链路追踪信息。在一些实施方式中，所述追踪参数包括但不限于：traceid(追踪id)、应用服务id和链路序号。
76.故障追踪模块380，用于根据所述链路追踪信息和报警信息确定故障应用服务之间的依赖关系和故障影响范围。通过调用链路的初始应用服务的探针生成追踪参数并传递至该调用链路上的每个应用服务，以生成调用链路的链路追踪信息，能够基于该链路追踪信息快速简便地判断故障的影响范围以及故障应用之间的依赖关系，以便快速制定故障恢复的方案，降低故障影响范围。
77.采用本发明实施方式的上述告警系统，通过获取应用服务、应用实例、应用接口三个维度的新报警监控规则，并在新报警监控规则对应的所有节点都获取到该规则后再使所有节点拉取的新规则生效，可以实现多维度、细粒度监控统一管理。并且，当采集到的应用性能数据触发报警规则时及时发送报警信息，可以实现自动化、近实时的主动预警，避免造成严重的业务影响。
78.通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件结合硬件平台的方式来实现。基于这样的理解，本发明的技术方案对背景技术做出贡献的全部或者部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施方式或者实施方式的某些部分所述的方法。
79.对应的，本发明实施方式还提供一种计算机可读存储介质，其上存储有计算机可读指令或程序，所述计算机可读指令或程序被处理器执行时，使得计算机执行如下操作：所
述操作包括如上任意一种实施方式所述告警方法所包含的步骤，在此不再赘述。其中，所述存储介质可以包括：例如，光盘、硬盘、软盘、闪存、磁带等。
80.另外，本发明实施方式还提供一种包括存储器和处理器的计算机设备，所述存储器用于存储一条或多条计算机可读指令或程序，其中，所述一条或多条计算机可读指令或程序被所述处理器执行时能够实现如上任意一种实施方式所述的告警方法。所述计算机设备可以是，例如，服务器、台式计算机、笔记本计算机、平板电脑等。
81.最后应说明的是：以上实施方式仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施方式对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施方式所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施方式技术方案的精神和范围。因此本发明的保护范围应以权利要求为准。