处理报警通知的方法、装置以及存储介质与流程

1.本申请涉及计算机技术领域，特别是涉及一种处理报警通知的方法、装置以及存储介质。


背景技术：

2.在互联网领域，为了及时发现生产环境中的问题，一般搭建有监控系统，用于监控业务和环境是否有异常，一旦出现异常，可以发送报警，通知相关人员及时处理，使业务和环境尽快恢复正常，避免影响用户使用。
3.但是，实际上经常会出现这些情况：监控报警
……
监控恢复正常(报警解除)
……
监控报警
----
监控恢复正常(报警解除)
……
这样在监控阈值上下来回波动、循环，频繁报警的情况。比如说磁盘使用率80％、内存使用率85％、cpu使用率70％等，由于业务流量的波动造成实际资源使用情况也有波动，导致报警也随之波动，这种频繁的重复的无效的报警，是一种误报，不仅浪费报警资源，还会给报警接收人带来极大的精力消耗和困惑，严重影响报警接收人的业余生活，特别是晚上休息的质量。现有技术为了解决误报警、重复报警的问题采用的办法是牺牲报警的及时性，比如原来是监控结果连续三次异常，现在改为连续六次异常，这样可以减少误报，但是会导致报警从发现到发出通知的时间延长到原来的两倍，对于重要的业务监控是不可接受的。
4.针对上述的现有技术中存在的由于业务流量的波动造成实际资源使用情况也有波动，因此会出现频繁、反复以及无效的报警状况，这种误报浪费报警资源以及业务人员的时间和精力的技术问题，目前尚未提出有效的解决方案。


技术实现要素：

5.本公开的实施例提供了一种处理报警通知的方法、装置以及存储介质，以至少解决现有技术中存在的由于业务流量的波动造成实际资源使用情况也有波动，因此会出现频繁、反复以及无效的报警状况，这种误报浪费报警资源以及业务人员的时间和精力的技术问题。
6.根据本公开实施例的一个方面，提供了一种处理报警通知的方法，包括：获取需要进行监控的监控项；判断监控项的监控结果是否满足预设的与监控项对应的报警条件；以及在监控结果满足报警条件的情况下，向处理报警状况的目标对象发送报警通知，在监控结果不满足报警条件并且预定时间内已经向目标对象发送报警通知和报警消除通知的情况下，停止向目标对象发送报警消除通知。
7.根据本公开实施例的另一个方面，还提供了一种存储介质，存储介质包括存储的程序，其中，在程序运行时由处理器执行以上任意一项所述的方法。
8.根据本公开实施例的另一个方面，还提供了一种处理报警通知的装置，包括：获取模块，用于获取需要进行监控的监控项；条件判断模块，判断监控项的监控结果是否满足预设的与监控项对应的报警条件；以及通知发送模块，用于在监控结果满足报警条件的情况
下，向处理报警状况的目标对象发送报警通知，在监控结果不满足报警条件并且预定时间内已经向目标对象发送报警通知和报警消除通知的情况下，停止向目标对象发送报警消除通知。
9.根据本公开实施例的另一个方面，还提供了一种处理报警通知的装置，包括：处理器；以及存储器，与处理器连接，用于为处理器提供处理以下处理步骤的指令：获取需要进行监控的监控项；判断监控项的监控结果是否满足预设的与监控项对应的报警条件；以及在监控结果满足报警条件的情况下，向处理报警状况的目标对象发送报警通知，在监控结果不满足报警条件并且预定时间内已经向目标对象发送报警通知和报警消除通知的情况下，停止向目标对象发送报警消除通知。
10.在本公开实施例中，监控系统首先获取需要进行监控的监控项。进一步地，将监控项的监控结果与预设的报警条件进行比对，判断本次监控结果是否满足报警条件。最终，在满足报警条件的情况下向处理报警事项的目标对象发送报警通知，在监控结果不满足报警条件(即：监控项运行正常)并且预定时间内已经向目标对象发送报警通知和报警消除通知的情况下，停止向目标对象发送报警消除通知。从而，在监控项的运行状态连续波动的情况下，可以避免频繁、反复的发送误报的报警消除通知，并且在监控项异常的情况下可以保证报警的及时性。达到了兼顾报警的及时性以及准确性的技术效果。进而解决了现有技术中存在的由于业务流量的波动造成实际资源使用情况也有波动，因此会出现频繁、反复以及无效的报警状况，这种误报浪费报警资源以及业务人员的时间和精力的技术问题。
附图说明
11.此处所说明的附图用来提供对本公开的进一步理解，构成本申请的一部分，本公开的示意性实施例及其说明用于解释本公开，并不构成对本公开的不当限定。在附图中：
12.图1是用于实现根据本公开实施例1所述的方法的计算设备的硬件结构框图；
13.图2是根据本公开实施例1的第一个方面所述的处理报警通知的方法的流程示意图；
14.图3是根据本公开实施例1所述的报警系统的结构示意图；
15.图4是根据本公开实施例1所述的监控系统的工作流程图；
16.图5是根据本公开实施例2所述的处理报警通知的装置的示意图；以及
17.图6是根据本公开实施例3所述的处理报警通知的装置的示意图。
具体实施方式
18.为了使本技术领域的人员更好地理解本公开的技术方案，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本公开一部分的实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本公开保护的范围。
19.需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或
描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
20.实施例1
21.根据本实施例，提供了一种处理报警通知的方法的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
22.本实施例所提供的方法实施例可以在移动终端、计算机终端、服务器或者类似的计算设备中执行。图1示出了一种用于实现处理报警通知的方法的计算设备的硬件结构框图。如图1所示，计算设备可以包括一个或多个处理器(处理器可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)、用于存储数据的存储器、以及用于通信功能的传输装置。除此以外，还可以包括：显示器、输入/输出接口(i/o接口)、通用串行总线(usb)端口(可以作为i/o接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算设备还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。
23.应当注意到的是上述一个或多个处理器和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到计算设备中的其他元件中的任意一个内。如本公开实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。
24.存储器可用于存储应用软件的软件程序以及模块，如本公开实施例中的处理报警通知的方法对应的程序指令/数据存储装置，处理器通过运行存储在存储器内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用程序的处理报警通知的方法。存储器可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器可进一步包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至计算设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
25.传输装置用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算设备的通信供应商提供的无线网络。在一个实例中，传输装置包括一个网络适配器(network interface controller，nic)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置可以为射频(radio frequency，rf)模块，其用于通过无线方式与互联网进行通讯。
26.显示器可以例如触摸屏式的液晶显示器(lcd)，该液晶显示器可使得用户能够与计算设备的用户界面进行交互。
27.此处需要说明的是，在一些可选实施例中，上述图1所示的计算设备可以包括硬件元件(包括电路)、软件元件(包括存储在计算机可读介质上的计算机代码)、或硬件元件和
软件元件两者的结合。应当指出的是，图1仅为特定具体实例的一个实例，并且旨在示出可存在于上述计算设备中的部件的类型。
28.在上述运行环境下，根据本实施例的第一个方面，提供了一种处理报警通知的方法，图2示出了该方法的流程示意图，参考图2所示，该方法包括：
29.s202：获取需要进行监控的监控项；
30.s204：判断监控项的监控结果是否满足预设的与监控项对应的报警条件；以及
31.s206：在监控结果满足报警条件的情况下，向处理报警状况的目标对象发送报警通知，在监控结果不满足报警条件并且预定时间内已经向目标对象发送报警通知和报警消除通知的情况下，停止向目标对象发送报警消除通知。
32.正如背景技术中所述的，实际监控过程中经常会出现这些情况：监控报警
……
监控恢复正常(报警解除)
……
监控报警
----
监控恢复正常(报警解除)
……
这样在监控阈值上下来回波动、循环，频繁报警的情况。比如说磁盘使用率80％、内存使用率85％、cpu使用率70％等，由于业务流量的波动造成实际资源使用情况也有波动，导致报警也随之波动，这种频繁的重复的无效的报警，是一种误报，不仅浪费报警资源，还会给报警接收人带来极大的精力消耗和困惑，严重影响报警接收人的业余生活，特别是晚上休息的质量。现有技术为了解决误报警、重复报警的问题采用的办法是牺牲报警的及时性，比如原来是监控结果连续三次异常，现在改为连续六次异常，这样可以减少误报，但是会导致报警从发现到发出通知的时间延长到原来的两倍，对于重要的业务监控是不可接受的。
33.针对背景技术中存在的技术问题，本实施例技术方案的监控系统首先获取需要进行监控的监控项。进一步地，将监控项的监控结果与预设的报警条件进行比对，判断本次监控结果是否满足报警条件。最终，在满足报警条件的情况下向处理报警事项的目标对象发送报警通知，在本次监控结果不满足报警条件(即：监控项运行正常)并且预定时间内已经向目标对象发送报警通知和报警消除通知的情况下，停止向目标对象发送报警消除通知。从而，在监控项的运行状态连续波动的情况下，可以避免频繁、反复的发送误报的报警消除通知，并且在监控项异常的情况下可以保证报警的及时性。达到了兼顾报警的及时性以及准确性的技术效果。进而解决了现有技术中存在的由于业务流量的波动造成实际资源使用情况也有波动，因此会出现频繁、反复以及无效的报警状况，这种误报浪费报警资源以及业务人员的时间和精力的技术问题。
34.具体地，在步骤s202中，监控系统首先获取需要进行监控的监控项。用户可以在该监控系统按照需求建立监控项，监控项例如但不限于包括：磁盘使用率、内存使用率、cpu使用率。在一个实施例中，系统可以根据监控项的启用或停用状态，将启用的监控项放入到监控队列中，从而可以从监控队列中获取需要进行监控的监控项。监控系统还可以直接获取用户所创建的监控项。此外，用户所创建的监控项还包括监控项名称、监控优先级、监控类别、监控地址和端口、监控预期结果、监控运行间隔等参数，并且系统可以根据用户的需求新增、删除、修改、查询、启用、停用监控项。
35.进一步地，在步骤s204中，监控系统判断监控项的监控结果是否满足预设的与监控项对应的报警条件。其中，用户在创建监控项的过程中会设置相应的报警条件，在一个具体的实例中以阈值的形式作为报警条件，例如：当磁盘使用率大于80％(阈值)，则进行报警。此外，每个监控项都关联一个报警策略，以便发送报警给相关人员，报警策略一般包括
报警策略名称、报警策略优先级、邮件报警策略、短信报警策略、电话报警策略、钉钉或微信报警策略。报警策略包括监控项监控结果连续失败多少次发送报警，最多发送多少次报警，报警发送的时间段，报警接收人，监控项监控结果连续多少次发送报警消除通知等。并且系统可以根据用户的需求对监控策略进行新增、删除、修改、查询等维护操作。
36.最终，在步骤s206中，在本次监控结果满足报警条件的情况下(即，监控项运行异常)，向处理报警状况的目标对象发送报警通知，在本次监控结果不满足报警条件(监控项运行正常)并且预定时间内已经向目标对象发送报警通知和报警消除通知的情况下，停止向目标对象发送报警消除通知。例如：本次监控的磁盘使用率大于80％，则向处理报警状况的目标对象(相关人员)发送报警通知，以便及时提醒磁盘使用率出现问题。在本次监控的磁盘使用率小于80％(即磁盘使用率正常)，则判断预定时间内(例如：24小时)是否已经向目标对象发送报警通知和报警消除通知(历史监控结果)，在确定24小时内已经向目标对象发送报警通知和报警消除通知的情况下，停止向目标对象发送报警消除通知，即：在本次监控磁盘使用率正常的情况下，暂停向目标对象发送报警消除通知。
37.从而，在监控项的运行状态连续波动的情况下，可以避免频繁、反复的发送误报的报警消除通知，并且在监控项异常的情况下可以保证报警的及时性。达到了兼顾报警的及时性以及准确性的技术效果。进而解决了现有技术中存在的由于业务流量的波动造成实际资源使用情况也有波动，因此会出现频繁、反复以及无效的报警状况，这种误报浪费报警资源以及业务人员的时间和精力的技术问题。
38.可选地，还包括：设置用于发送报警消除通知的观察周期，并且在停止向目标对象发送报警消除通知之后，还包括：延长观察周期。
39.具体地，监控系统还设置用于发送报警消除通知的观察周期，并且在停止向目标对象发送报警消除通知之后，延长观察周期。例如：初始设置的监控项的观察周期为预定时间内连续2次正常，视为报警消除。在停止向目标对象发送报警消除通知之后，现在需要连续4次正常，才判定为报警消除，向目标对象发送报警恢复通知。即观察周期期间监控执行结果均是正常，则再发送报警消除通知，告知相关人员报警已经解除。在具体实现上，只需在现有监控体系里面，引入动态修改报警消除的观察期时间长度即可。
40.可选地，还包括：设置观察周期的最大值，并且在观察周期达到最大值的情况下，发送报警消除通知。
41.具体地，在一个具体实例中，观察周期的最大值为24小时，在24小时内的监控结果连续正常，视为报警消除。即：上述延长观察周期的步骤可以重复，每发送一次报警恢复通知，下一次报警恢复的观察周期动态扩大一次，直至扩大至24小时。即一天最多有一次报警通知、一次报警消除通知。这样最大限度的消除了干扰报警，又保障了报警的提醒功能。如果报警发现的问题依旧存在，每天都会有一个报警提醒，以便通知相关人员跟进处理。
42.可选地，通过以下任意一项方式向目标对象发送报警通知和/或报警消除通知：短信、邮件以及电话。
43.具体地，监控系统在发送报警通知或者报警消除通知可以通过短信、邮件以及电话的方式，还可以有其他方式，此处不做具体限定。
44.此外，图3还示例性地示出了监控系统的系统结构图，参考图3所示，监控系统包括监控管理模块301、监控调度模块302、监控执行模块303、监控报警模块304。其中：
45.一、监控管理模块301，用于监控项的管理，报警策略的管理，以及权限管理。并且监控管理模块301用于执行以下操作：
46.监控项的管理，包括监控项的新增、删除、修改、查询、启用、停用。监控项一般包括监控项名称、监控优先级、监控类别、监控地址和端口、监控预期结果、监控运行间隔等，每个监控项都要关联一个报警策略，以便发送报警给相关人员。
47.报警策略管理，用于报警策略的维护，包括报警策略的新增、删除、修改、查询。报警策略一般包括报警策略名称、报警策略优先级、邮件报警策略、短信报警策略、电话报警策略、钉钉或微信报警策略。报警策略包括监控项监控结果连续失败多少次发送报警，最多发送多少次报警，报警发送的时间段，报警接收人，监控项监控结果连续多少次发送报警恢复通知等。
48.权限管理，用于监控系统组织、用户和权限的管理，以保障系统的安全，其中包括部门和项目的管理、用户的管理、角色管理和权限管理。
49.二、监控调度模块302，用于监控项执行的调度。监控调度模块根据配置的监控项运行间隔，按时将待执行的监控项放入待执行监控项队列中。
50.三、监控执行模块303，用于监控项的执行。监控执行模块不断监听待执行监控项队列，如果有则获取一个监控项、并从队列中移除，然后执行该监控项，解析执行结果并和监控项配置的预期结果(报警条件)做对比，如果一致，则监控正常，将监控项和监控执行结果放入待恢复(消除)监控报警队列，等待发送报警消除通知；如果不一致，则监控异常，将监控项和监控执行结果放入待处理监控报警队列。在实际应用中，由于监控项的数量庞大，所以以集群的形式，用于监控项的并发执行，提高监控项执行效率。
51.四、监控报警模块304，用于报警发送和报警处理。其具体的功能如下所示：
52.发送报警：不断监听待处理监控报警队列，如果有，则获取一个监控报警，根据用户配置的报警策略、历史监控结果，判定是否满足报警策略，如果满足，则按照报警策略给相关人员以一定的方式发送报警，比如短信、邮件、电话等，并将本次监控结果和报警存储起来；如果不满足，则将本次监控结果保存起来。在报警接收人员收到报警后，可以先到报警平台，修改报警状态为处理中；待报警修复完成后，修改报警状态为已处理。后续可以根据报警处理记录，生成报告，度量报警处理的及时率、处理时长等。
53.报警消除判定：不断监听待恢复(消除)监控报警队列，如果有，则获取一个待消除监控报警，根据用户配置的报警恢复策略、历史监控结果，判定本次监控结果是否满足报警消除策略，如果满足，则按照报警消除策略给相关人员以一定的方式发送报警消除通知，比如短信、邮件、电话等，并将本次监控结果和报警消除通知存储起来；如果不满足，则将本次监控结果保存起来。
54.此外，图4还示例性地示出了监控系统的工作流程图，参考图4所示：
55.监控管理401：监控管理是整个监控流程的开始，可以按需创建项目并配置监控项，然后启用需要运行的监控项。
56.监控调度402：不断扫描监控配置，根据监控项配置的是否启用、运行间隔，以及监控项上次运行时间，将待运行的启用状态的监控项放入待执行监控项队列中。
57.监控执行403：不断监听待执行监控项队列，如果有则获取一个监控项、并从队列中移除，然后执行该监控项。
58.监控结果判定404：解析执行结果并存储，然后和监控项配置的预期结果做对比，如果一致，则监控结果正常，转405处理；如果不一致，则监控结果异常，转407处理。
59.报警恢复判定405：根据用户配置的报警恢复策略、历史监控结果、本次监控结果，判定是否满足报警恢复策略？
60.5.1，如果满足，则判断最近24小时内是否已经发送过报警通知、且有报警恢复通知，如果是，则报警恢复通知暂不发送，将监控恢复的观察窗口期动态延长，比如延长一倍；如果不是，则转406处理；
61.5.2，如果不满足，则不做处理，继续等待下次被调度执行。
62.保存报警恢复判定结果。
63.发送报警恢复通知406：按照报警恢复策略给相关人员以一定的方式发送报警恢复通知，比如短信、邮件、电话等，并将报警恢复通知记录存储起来。
64.报警判定407：根据用户配置的报警策略、历史监控结果、本次监控结果，判定是否满足报警策略，如果满足，则转408处理；如果不满足，则继续等待下次被调度执行。保存报警判断结果。
65.发送报警408：按照报警策略给相关人员以一定的方式发送报警，比如短信、邮件、电话等，并将本次监控结果和报警存储起来。然后继续等待下次被调度执行。
66.通过本实施例技术方案可以达到以下技术效果：
67.减少误报，提高报警准确率。本技术方案可以有效解决在监控项的监控执行结果值在监控阈值上下波动导致频繁、重复、无效报警的问题，减少由于误报导致的报警资源浪费、接收报警人员的精力消耗和干扰，进一步提高监控的准确率、可信度。
68.不影响报警的及时性。本技术方案从报警恢复通知发送策略的角度切入，没有变更报警发送的逻辑，所以报警的及时性没有任何影响。
69.可以兼容现有监控技术，只需在现有监控体系里面，引入动态修改报警恢复观察期时间长度即可。
70.此外，参考图1所示，根据本实施例的第二个方面，提供了一种存储介质。所述存储介质包括存储的程序，其中，在所述程序运行时由处理器执行以上任意一项所述的方法。
71.从而根据本实施例，在监控项的运行状态连续波动的情况下，可以避免频繁、反复的发送误报的报警消除通知，并且在监控项异常的情况下可以保证报警的及时性。达到了兼顾报警的及时性以及准确性的技术效果。进而解决了现有技术中存在的由于业务流量的波动造成实际资源使用情况也有波动，因此会出现频繁、反复以及无效的报警状况，这种误报浪费报警资源以及业务人员的时间和精力的技术问题。
72.需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。
73.通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有
技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
74.实施例2
75.图5示出了根据本实施例所述的处理报警通知的装置500，该装置500与根据实施例1的第一个方面所述的方法相对应。参考图5所示，该装置500包括：获取模块510，用于获取需要进行监控的监控项；条件判断模块520，判断监控项的监控结果是否满足预设的与监控项对应的报警条件；以及通知发送模块530，用于在监控结果满足报警条件的情况下，向处理报警状况的目标对象发送报警通知，在监控结果不满足报警条件并且预定时间内已经向目标对象发送报警通知和报警消除通知的情况下，停止向目标对象发送报警消除通知。
76.可选地，装置500还包括：第一设置模块，用于设置用于发送报警消除通知的观察周期，并且装置还包括：延长观察周期。
77.可选地，装置500还包括：第二设置模块，用于设置观察周期的最大值，并且在观察周期达到最大值的情况下，发送报警消除通知。
78.可选地，装置500通过以下任意一项方式向目标对象发送报警通知和/或报警消除通知：短信、邮件以及电话。
79.从而根据本实施例，通过处理报警通知的装置500，在监控项的运行状态连续波动的情况下，可以避免频繁、反复的发送误报的报警消除通知，并且在监控项异常的情况下可以保证报警的及时性。达到了兼顾报警的及时性以及准确性的技术效果。进而解决了现有技术中存在的由于业务流量的波动造成实际资源使用情况也有波动，因此会出现频繁、反复以及无效的报警状况，这种误报浪费报警资源以及业务人员的时间和精力的技术问题。
80.实施例3
81.图6示出了根据本实施例所述的处理报警通知的装置600，该装置600与根据实施例1的第一个方面所述的方法相对应。参考图6所示，该装置600包括：处理器610；以及存储器620，与处理器610连接，用于为处理器610提供处理以下处理步骤的指令：获取需要进行监控的监控项；判断监控项的监控结果是否满足预设的与监控项对应的报警条件；以及在监控结果满足报警条件的情况下，向处理报警状况的目标对象发送报警通知，在监控结果不满足报警条件并且预定时间内已经向目标对象发送报警通知和报警消除通知的情况下，停止向目标对象发送报警消除通知。
82.可选地，存储器620还用于为处理器610提供处理以下处理步骤的指令：设置用于发送报警消除通知的观察周期，并且在停止向目标对象发送报警消除通知之后，延长观察周期。
83.可选地，存储器620还用于为处理器610提供处理以下处理步骤的指令：设置观察周期的最大值，并且在观察周期达到最大值的情况下，发送报警消除通知。
84.可选地，装置600通过以下任意一项方式向目标对象发送报警通知和/或报警消除通知：短信、邮件以及电话。
85.从而根据本实施例，通过处理报警通知的装置600，在监控项的运行状态连续波动的情况下，可以避免频繁、反复的发送误报的报警消除通知，并且在监控项异常的情况下可以保证报警的及时性。达到了兼顾报警的及时性以及准确性的技术效果。进而解决了现有
技术中存在的由于业务流量的波动造成实际资源使用情况也有波动，因此会出现频繁、反复以及无效的报警状况，这种误报浪费报警资源以及业务人员的时间和精力的技术问题。
86.上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
87.在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
88.在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
89.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
90.另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
91.所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
92.以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。