一种报警消息处理方法、装置及电子设备与流程

1.本技术涉及安全技术领域，具体而言，涉及报警消息处理方法、装置及电子设备。


背景技术：

2.随着安全意识的不断提高，报警系统(alarmsystem)在通信、医疗等领域得到广泛应用。报警系统通常可以用于对被监控对象进行监控，比如可以针对被监控对象的一个或多个运行参数设定预设范围，然后对这些运行参数的实际值进行监控，当监控到实际值超出预设范围时，生成报警消息，并将报警消息发送至预先设置的报警消息接收对象。因此，对于报警系统而言，如何处理报警消息至关重要。


技术实现要素：

3.本技术实施例的目的在于提供报警消息处理方法、装置及电子设备，用于解决现有技术中的问题。
4.本技术实施例第一方面提供了一种报警消息处理方法，包括：
5.获取报警消息，其中，所述报警消息包括重要性等级以及时间戳；
6.根据所述重要性等级以及时间戳，将所述报警消息添加至消息处理队列，以用于对所述报警消息进行处理。
7.于一实施例中，报警消息还包括报警消息接收对象；则，
8.所述方法还包括：根据所述消息处理队列中各个报警消息的先后顺序，从所述消息处理队列中获取所述报警消息，并将所述报警消息发送至所述报警消息接收对象。
9.于一实施例中，所述方法还包括：若第一预设时间段内未收到所述报警消息接收对象所返回的消息已查收通知，则再次向所述报警消息接收对象发送所述报警消息。
10.于一实施例中，在再次向所述报警消息接收对象发送所述报警消息之后，所述方法还包括：
11.若第二预设时间段内未收到所述报警消息接收对象所返回的消息查收通知，则判断所述报警消息是否为服务器维护的报警消息，其中，所述服务器维护具体包括：磁盘清理和/或数据同步；
12.在所述报警消息为服务器维护的报警消息的情况下，发送脚本工具运行指令，以指示运行相应脚本工具，用于对服务器进行磁盘清理和/或数据同步。
13.于一实施例中，在所述消息处理队列中，对于重要性等级不同的报警消息，根据重要性等级由高到低的顺序先后排列；以及，在所述消息处理队列中，对于重要性等级相同的报警消息，根据时间戳的顺序先后排列；则，
14.根据所述重要性等级以及时间戳，将所述报警消息添加至消息处理队列，具体包括：
15.根据所获取的报警消息的重要性等级，确定所述消息处理队列中的待插入区域，其中，所述待插入区域中各个报警消息的重要性等级，与所获取的报警消息的重要性等级
相同；
16.根据所获取的报警消息的时间戳，以及所述待插入区域中各个报警消息的时间戳，确定待插入位置；
17.将所述所获取的报警消息插入所述待插入位置。
18.于一实施例中，根据所述重要性等级以及时间戳，将所述报警消息添加至消息处理队列，具体包括：
19.在tps大于qps的情况下，根据所述重要性等级以及时间戳，将所述报警消息添加至消息处理队列。
20.于一实施例中，所述方法还包括：预先通过压力测试确定所述qps。
21.本技术实施例第二方面提供了一种报警消息处理装置，包括：
22.获取单元，用于获取报警消息，其中，所述报警消息包括重要性等级以及时间戳；
23.添加单元，用于根据所述重要性等级以及时间戳，将所述报警消息添加至消息处理队列，以用于对所述报警消息进行处理。
24.于一实施例中，报警消息还包括报警消息接收对象；则，
25.所述装置还包括发送单元，用于根据所述消息处理队列中各个报警消息的先后顺序，从所述消息处理队列中获取所述报警消息，并将所述报警消息发送至所述报警消息接收对象。
26.本技术实施例第三方面提供了一种电子设备，包括：
27.存储器，用以存储计算机程序；
28.处理器，用以执行本技术任一实施例所提供的方法。
29.采用本技术实施例所提供的报警消息处理方法，在获取报警消息之后，根据所获取报警消息的重要性等级和时间戳，将该报警消息添加至消息处理队列。这样在将该报警消息添加至消息处理队列之后，能够通过处理消息处理队列中的各个报警消息，来实现报警消息的处理，从而解决现有技术中的问题。
附图说明
30.为了更清楚地说明本技术实施例的技术方案，下面将对本技术实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本技术的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
31.图1为本技术一实施例提供的，报警消息处理方法的具体流程示意图；
32.图2为本技术一实施例提供的电子设备的结构示意图；
33.图3为本技术一实施例提供的，电子设备与被监控对象交互示意图；
34.图4为本技术一实施例提供的，报警消息处理装置的具体结构示意图。
具体实施方式
35.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行描述。在本技术的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性或先后顺序。
36.如前所述，报警系统可以针对被监控对象的一个或多个运行参数设定预设范围，然后对该这些运行参数的实际值进行监控，当监控到实际值超出预设范围时，生成报警消息，并将报警消息发送至预先设置的报警消息接收对象。因此，对于报警系统而言，如何处理报警消息至关重要。比如，当报警系统收到多个报警消息时，容易出现报警消息被漏处理的情况。
37.基于此，本技术实施例提供了一种报警消息处理方法，能够用于解决现有技术中的问题。如图1所示为该方法的具体流程示意图，包括如下步骤：
38.步骤s11：获取报警消息，该报警消息包括重要性等级以及时间戳。
39.该报警消息可以是报警系统在监控到，被监控对象运行参数的实际值超出预设范围时，所生成的报警消息。被监控对象可以是诸如应用程序、公众号等虚拟的被监控对象，也可以是硬件的被监控对象，比如，手机、平板电脑、大型服务器等硬件设备。
40.运行参数可以是被监控对象的某些关键指标，比如为大型服务器时，为了确保大型服务器的正常运行，需要关注内存占用率、cpu占用率、cpu温度、磁盘占用率等关键指标，可以将这些关键指标作为运行参数，并通过报警系统进行监控。比如，运行参数为cpu占用率，可以针对cpu占用率设定预设范围(例如，小于50％)，当监控到cpu占用率超出预设范围时，生成报警消息。
41.需要说明的是，在报警系统中通常可以包括对象监控模块，该对象监控模块可以用于对被监控对象的运行参数的实际值进行监控，并在监控到实际值超出预设范围时，生成报警消息。
42.在该报警消息中包括重要性等级以及时间戳，其中，该时间戳可以是生成报警消息时的时间戳，也可以是获取到该报警消息时的时间戳。而重要性等级可以反映被监控对象或所监控的运行参数的重要性，比如，可以针对不同的被监控对象设置不同的重要性等级，或针对同一被监控对象中不同的运行参数，设置不同的重要性等级。比如，根据实际需要可以划分五个重要性等级，并且根据由高到低的顺序依次为等级1、等级2、等级3、等级4、等级5。
43.在实际应用中，可以提供一图形用户界面，使得用户可以在图形用户界面进行操作，从而针对不同的被监控对象设置不同的重要性等级，或针对同一被监控对象中不同的运行参数，设置不同的重要性等级。
44.步骤s12：根据所获取报警消息的重要性等级和时间戳，将该报警消息添加至消息处理队列，以用于对所述报警消息进行处理。
45.需要说明的是，在该消息处理队列中可以包括多个报警消息，这些报警消息分别包括对应的重要性等级和时间戳。并且在该消息处理队列中，对于重要性等级不同的报警消息，根据重要性等级由高到低的顺序先后排列，而对于重要性等级相同的报警消息，根据时间戳的顺序先后排列。
46.这样，在步骤s12中，根据所获取报警消息的重要性等级和时间戳，将该报警消息添加至消息处理队列的具体方式可以是，先根据所获取的报警消息的重要性等级，确定消息处理队列中的待插入区域，待插入区域中各个报警消息的重要性等级，与所获取的报警消息的重要性等级相同；然后，根据所获取的报警消息的时间戳，以及待插入区域中各个报警消息的时间戳，确定待插入位置，然后将所获取的报警消息插入该待插入位置。
47.也就是说，在将所获取的报警消息添加至消息处理队列时，先考虑重要性等级，重要性等级越高的报警消息越靠前，在重要性等级相同的情况下，再考虑时间戳，时间戳越早的报警消息越靠前。
48.采用本技术实施例所提供的报警消息处理方法，在获取报警消息之后，根据所获取报警消息的重要性等级和时间戳，将该报警消息添加至消息处理队列。这样在将该报警消息添加至消息处理队列之后，能够通过处理消息处理队列中的各个报警消息，来实现报警消息的处理，从而解决现有技术中的问题。
49.特别是，在实际应用中，当获取到的报警消息数量较多的情况下，对这些报警消息的处理过程中，通常容易导致警消息被漏处理。此时，利用本技术实施例所提供的方式，即使在获取到多个报警消息的情况下，也可以通过将这些报警消息添加到消息处理队列的方式，进而通过对消息处理队列中的各个报警消息进行处理的方式，对这些报警消息进行处理，因此还降低了报警消息被漏处理的可能性。
50.对于消息处理队列中的各个报警消息的处理方式，通常可以根据消息处理队列中各个报警消息的先后顺序，依次获取并发送，从而实现对报警消息的处理。
51.另外，为了将报警消息进行发送，通常报警消息中还可以包括报警消息接收对象，该报警消息接收对象可以是手机号、邮箱地址或其他类型的消息接收对象。
52.因此，步骤s11中的报警消息还可以包括报警消息接收对象，并且本技术实施例所提供的报警消息处理方法还可以包括，根据消息处理队列中各个报警消息的先后顺序，从消息处理队列中获取该报警消息，并将该报警消息发送至报警消息接收对象。
53.另外，在将报警消息发送至报警消息接收对象之后，该方法还可以进一步包括若第一预设时间段内未收到该报警消息接收对象所返回的消息已查收通知，则再次向该报警消息接收对象发送所述报警消息。
54.通常在报警消息接收对象已成功接收到报警消息之后，能够返回该消息已查收通知，因此如果在第一预设时间段内收到消息已查收通知，说明报警消息接收对象已成功接收到该报警消息，此时可以不再进行其他处理；而如果在第一预设时间段内未收到消息已查收通知，则说明报警消息接收对象可能并没有接收到该报警消息，此时需要再次向该报警消息接收对象发送所述报警消息。
55.特别是，该第一预设时间段可以根据实际需要进行设定，比如可以根据报警消息的重要性等级来设定该第一预设时间段，对于重要性等级越高的报警消息，其时间急迫性通常也越高，此时可以将该第一预设时间段设置的越短；反之，对于重要性等级越低的报警消息，其时间急迫性相对越低，此时可以将该第一预设时间段设置的越长。
56.比如，上述提到可以划分五个重要性等级，并且根据由高到低的顺序依次为等级1、等级2、等级3、等级4、等级5，对于重要性等级为等级1的报警消息，第一预设时间段可以为5分钟(当然也可以为10分钟、30分钟等)，而对于重要性等级为等级5的报警消息，第一预设时间段可以为3小时或其他时长。
57.需要进一步说明的是，在实际应用中，通常可以将服务器作为被监控对象，从而对服务器的维护进行监控，包括服务器的磁盘清理和/或数据同步等，比如，将磁盘占用率作为运行参数，从而对服务器磁盘占用率的进行监控，当该磁盘占用率超出预设范围时，生成服务器维护的报警消息。
58.此时，若第一预设时间段内未收到该报警消息接收对象所返回的消息已查收通知，并且在再次向报警消息接收对象发送报警消息之后，若第二预设时间段内仍未收到报警消息接收对象所返回的消息查收通知，则可以进一步判断该报警消息是否为服务器维护的报警消息，并且在该报警消息为服务器维护的报警消息的情况下，发送脚本工具运行指令，以指示运行相应脚本工具，从而通过运行相应脚本工具对服务器进行磁盘清理和/或数据同步。
59.其中，该第二预设时间段可以与第一预设时间段相同或不同，比如该第二预设时间段可以为10分钟、30分钟等。
60.在实际应用中，对于报警系统通常具有一定的处理能力，若所获取到的报警消息的数量在处理能力的范围内，对报警消息的处理效率较高，不容易出现报警消息被漏处理或严重延迟的情况。因此，对于报警系统，可以进一步设置报警优先级策略模式和非报警优先策略模式，当获取到的报警消息的数量在处理能力的范围内时，以非报警优先策略模式进行处理；或，当获取到的报警消息的数量超出处理能力时，以报警优先策略模式进行处理。
61.其中，以非报警优先策略模式进行处理，可以是接收到报警消息之后，直接进行处理，或只按照报警消息的时间戳添加到消息处理队列等，以用于对报警消息的处理。
62.以报警优先策略模式进行处理，即采用本技术所提供的报警消息处理方法，处理报警消息，也就是说，在获取报警消息后，根据该报警消息的重要性等级和时间戳，将该报警消息添加至消息处理队列，以用于报警消息的处理。
63.在实际应用中，通常可以通过压力测试来确定报警系统对报警消息的处理能力，比如可以先设定边界条件，该边界条件可以是报警信息延迟率《1％(或3％、5％或其他值)，报警信息丢失率《1％(或3％、5％或其他值)；然后，逐步增大报警系统每秒接收到并处理的报警消息的数量，从而最终确定在该边界条件内，报警系统每秒能够承载的最大报警信息处理量(query per second,qps)，该qps能够用于衡量报警系统的处理能力。比如，当报警系统每秒处理的报警信息的数量(transactions per second，tps)小于或等于该qps时，说明没有超出报警系统的处理能力，此时以非报警优先策略模式进行处理；或，当tps大于该qps时，说明超出了报警系统的处理能力，此时以报警优先策略模式进行处理。
64.在实际应用中，对于报警系统可以包括对象监控模块、异常监控模块和消息处理模块，该对象监控模块可以用于对被监控对象的运行参数的实际值进行监控，并在监控到实际值超出预设范围时，生成报警消息；异常监控模块用于监控tps是否大于qps；消息处理模块用于在tps大于qps的情况下，以报警优先策略模式进行处理，或在tps小于或等于qps的情况下，以非报警优先策略模式进行处理。
65.相对来说，以非报警优先策略模式对报警消息进行处理，与以报警优先策略模式对报警消息进行处理相比，由于非报警优先策略模式中并未考虑报警消息的重要性等级，可能容易造成某些重要性等级较高的报警消息被延后处理，尤其在报警消息数量较多的情况下，被延后处理的可能性也较高。而对于重要性等级越高的报警消息，其时间急迫性也相对越高，若出现被延后处理的情况，可能会对被监控对象的正常工作造成较大影响。因此，在tps大于qps的情况下的情况下，可以以报警优先策略模式对报警消息进行处理。
66.如图2所示，本实施例提供一种电子设备2，包括：至少一个处理器21和存储器22。
处理器21和存储器22通过总线20连接，存储器22存储有可被处理器21执行的指令，指令被处理器21执行，以使电子设备2可执行上述的实施例中方法的全部或部分流程。
67.在实际应用中，该电子设备2可以是手机、笔记本电脑、台式电脑或其组成的大型服务器或服务器集群等，在该电子设备2中可以设置报警系统的全部或部分模块。
68.如图3所示，电子设备2可以对接一个或多个被监控对象3，电子设备2可以分别和每个被监控对象3进行数据通信。在被监控对象3中可以设置由报警系统中的对象监控模块。
69.比如，可以将报警系统中的对象监控模块设置于被监控对象3，并将报警系统中的异常监控模块和消息处理模块，设置于电子设备2。
70.基于与本技术实施例所提供的报警消息处理方法相同的发明构思，本技术实施例还提供了一种报警消息处理装置，对于该装置实施例，如有不清楚之处，可以参考方法实施例的相应内容。如图4所示为该装置40的具体结构示意图，该装置40包括：获取单元401和添加单元402，其中：
71.获取单元401，用于获取报警消息，其中，所述报警消息包括重要性等级以及时间戳；
72.添加单元402，用于根据所述重要性等级以及时间戳，将所述报警消息添加至消息处理队列，以用于对所述报警消息进行处理。
73.采用本技术实施例所提供的装置40，由于该装置40采用与本技术实施例所提供的报警消息处理方法相同的发明构思，在该报警消息处理方法能够解决技术问题的前提下，该装置40也能够解决技术问题，这里对此不再赘述。
74.另外，在实际应用中，通过将该装置40与具体硬件设备、云技术等相结合所取得的技术效果，也在本技术的保护范围之内，比如采用分布式集群的方式将该装置40中的不同单元布设于分布式集群中的不同节点中，从而提高效率等。
75.报警消息通常还可以包括报警消息接收对象；则，装置40还可以包括发送单元，用于根据所述消息处理队列中各个报警消息的先后顺序，从所述消息处理队列中获取所述报警消息，并将所述报警消息发送至所述报警消息接收对象。
76.当然，该发送单元还可以包括发送子单元，用于若第一预设时间段内未收到所述报警消息接收对象所返回的消息已查收通知，则再次向所述报警消息接收对象发送所述报警消息。
77.在实际应用中，该装置40还可以包括判断单元和指令发送单元，其中：
78.该判断单元，用于在再次向所述报警消息接收对象发送所述报警消息之后，若第二预设时间段内未收到所述报警消息接收对象所返回的消息查收通知，则判断所述报警消息是否为服务器维护的报警消息，其中，所述服务器维护具体包括：磁盘清理和/或数据同步；
79.该指令发送单元，用于在所述报警消息为服务器维护的报警消息的情况下，发送脚本工具运行指令，以指示运行相应脚本工具，用于对服务器进行磁盘清理和/或数据同步。
80.所述添加单元402可以具体用于在tps大于qps的情况下，根据所述重要性等级以及时间戳，将所述报警消息添加至消息处理队列。
81.当然，该装置40还可以包括qps确定单元，用于预先通过压力测试确定所述qps。
82.在所述消息处理队列中，对于重要性等级不同的报警消息，根据重要性等级由高到低的顺序先后排列；以及，在所述消息处理队列中，对于重要性等级相同的报警消息，根据时间戳的顺序先后排列。
83.在实际应用中，所述添加单元402可以包括待插入区域确定子单元、待插入位置确定子单元和插入子单元，其中：
84.待插入区域确定子单元，用于根据所获取的报警消息的重要性等级，确定所述消息处理队列中的待插入区域，其中，所述待插入区域中各个报警消息的重要性等级，与所获取的报警消息的重要性等级相同；
85.待插入位置确定子单元，用于根据所获取的报警消息的时间戳，以及所述待插入区域中各个报警消息的时间戳，确定待插入位置；
86.插入子单元，用于将所述所获取的报警消息插入所述待插入位置。
87.本发明实施例还提供了一种电子设备可读存储介质，包括：程序，当其在电子设备上运行时，使得电子设备可执行上述实施例中方法的全部或部分流程。其中，存储介质可为磁盘、光盘、只读存储记忆体(read-only memory，rom)、随机存储记忆体(random access memory，ram)、快闪存储器(flash memory)、硬盘(hard disk drive，缩写：hdd)或固态硬盘(solid-state drive，ssd)等。存储介质还可以包括上述种类的存储器的组合。
88.虽然结合附图描述了本发明的实施例，但是本领域技术人员可以在不脱离本发明的精神和范围的情况下作出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。