监控数据处理方法、装置及监控系统与流程

本申请涉及云监控技术领域，具体提供了一种监控数据处理方法、装置及监控系统。

背景技术：

监控系统能够应用于工业生产、传统互联网、移动互联网、移动通信技术等领域中，用来监测某项业务的运行数据，并能够在运行数据满足告警条件时发出告警消息。通常，对于一项运行数据，对应的警告条件是恒定不变的。由于某些领域的业务在一天中会出现高峰期和低谷期，因此在低谷期对运行数据的告警就比较迟钝，无法对真实的故障进行告警；而在高峰期的告警过于敏感，产生多次告警从而影响业务的正常运行。

技术实现要素：

本申请提供一种监控数据处理方法、装置及监控系统，用于解决上述相关技术中告警不准确的问题。

本申请第一方面实施例提供一种监控数据处理方法，包括：

获取待监控数据；

当所述待监控数据满足告警条件时，发出告警信息；

根据所述待监控数据被获取的时间调整所述告警条件。

如上所述的方法，根据所述待监控数据被获取的时间调整所述告警条件，包括：

根据所述待监控数据对应业务的繁忙程度将业务运行时间划分为至少两个时间区间，每个时间区间对应一个目标告警条件；

确定所述待监控数据被获取的时间所落入的时间区间；

将告警条件修改为落入的时间区间所对应的目标告警条件。

如上所述的方法，所述待监控数据对应业务的繁忙程度包括：空闲状态、一般繁忙状态及繁忙状态。

如上所述的方法，还包括：

根据所述待监控数据对应业务处于繁忙状态的持续时间调整所述告警条件。

如上所述的方法，根据所述待监控数据对应业务处于繁忙状态的持续时间调整所述告警条件，包括：

若所述待监控数据对应业务处于繁忙状态的持续时间超过对应的时间区间，将告警条件修改为繁忙状态所对应的目标告警条件。

如上所述的方法，根据所述待监控数据对应业务处于繁忙状态的持续时间调整所述告警条件，还包括：

若所述待监控数据对应业务处于繁忙状态的持续时间少于对应的时间区间，将告警条件修改为一般繁忙状态或空闲状态所对应的目标告警条件。

如上所述的方法，还包括：

若识别出有能够改变待监控数据对应业务繁忙程度的事件被触发，则根据待监控数据对应业务的繁忙程度调整告警条件。

本申请第二方面实施例提供一种监控数据处理装置，包括：

待监控数据获取模块，用于获取待监控数据；

告警信息发出模块，用于当所述待监控数据满足告警条件时，发出告警信息；

告警条件调整模块，用于根据所述待监控数据被获取的时间调整所述告警条件。

本申请第三方面实施例一种监控系统，包括：

存储器；

处理器；以及

计算机程序；

其中，所述计算机程序存储在所述存储器中，并被配置为由所述处理器执行以实现如上所述的方法。

本申请第四方面实施例一种计算机可读存储介质，其上存储有计算机程序；所述计算机程序被处理器执行以实现如上所述的方法。

本申请实施例提供的技术方案，通过根据待监控数据被获取的时间来调整告警条件，根据调整后的告警条件确定待监控数据是否满足，若满足调整后的告警条件，则发出告警信息，相当于设定了至少两个告警条件，根据时段不同采用不同的告警条件，使得监控系统进行告警的准确度更高。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请实施例一提供的监控数据处理方法的流程图；

图2为本申请实施例二提供的监控数据处理方法的流程图；

图3为本申请实施例三提供的监控数据处理装置的结构示意图；

图4为本申请实施例四提供的监控系统的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

实施例一

本实施例提供一种监控数据处理方法，可以应用于多个领域中，例如：工业生产、传统互联网、移动互联网、移动通信等领域，该方法可以由监控系统中的处理器来执行。

本实施例所提供的方法能够应用在一个电子终端中，该电子终端可以是服务器、智能手机、平板电脑、便携计算机、桌上型计算机等具有运算功能的终端设备。该电子终端包括：处理器、存储器、网络接口及通信总线。

其中，存储器包括至少一种类型的可读存储介质。所述至少一种类型的可读存储介质可为如闪存、硬盘、多媒体卡、卡型存储器等的非易失性存储介质。在一些实施例中，所述可读存储介质可以是电子终端的内部存储单元，例如该电子终端的硬盘。在另一些实施例中，所述可读存储介质也可以是所述电子终端的外部存储器，例如所述电子终端上配备的插接式硬盘，智能存储卡(smartmediacard,smc)，安全数字(securedigital,sd)卡，闪存卡(flashcard)等。

在本实施例中，所述存储器的可读存储介质通常用于存储安装于所述电子终端的处理程序及预存的告警条件所对应的上限阈值或下限阈值等。所述存储器还可以用于暂时地存储已经输出或者将要输出的数据。

处理器在一些实施例中可以是一中央处理器(centralprocessingunit,cpu)，微处理器或其他数据处理芯片，用于运行存储器中存储的程序代码或处理数据。

网络接口可选地可以包括标准的有线接口、无线接口(如wi-fi接口)，通常用于在该电子终端与其他电子终端之间建立通信连接。

通信总线用于实现这些组件之间的连接通信。

可选地，该电子终端还可以包括用户接口，用户接口可以包括输入单元比如键盘(keyboard)、语音输入装置比如麦克风(microphone)等具有语音识别功能的设备、语音输出装置比如音响、耳机等，可选地用户接口还可以包括标准的有线接口、无线接口。

可选地，该电子终端还可以包括显示器，显示器也可以称为显示屏或显示单元。在一些实施例中可以是led显示器、液晶显示器、触控式液晶显示器以及有机发光二极管(organiclight-emittingdiode，oled)触摸器等。显示器用于显示在电子终端中处理的信息以及用于显示可视化的用户界面。

可选地，该电子终端还包括触摸传感器。所述触摸传感器所提供的供用户进行触摸操作的区域称为触控区域。此外，这里所述的触摸传感器可以为电阻式触摸传感器、电容式触摸传感器等。而且，所述触摸传感器不仅包括接触式的触摸传感器，也可包括接近式的触摸传感器等。此外，所述触摸传感器可以为单个传感器，也可以为例如阵列布置的多个传感器。

此外，该电子终端的显示器的面积可以与所述触摸传感器的面积相同，也可以不同。可选地，将显示器与所述触摸传感器层叠设置，以形成触摸显示屏。该装置基于触摸显示屏侦测用户触发的触控操作。

可选地，该电子终端还可以包括射频(radiofrequency，rf)电路，传感器、音频电路等等，在此不再赘述。

图1为本申请实施例一提供的监控数据处理方法的流程图。如图1所示，作为一种计算机存储介质的存储器中可以包括操作系统、以及监控数据处理程序；处理器执行存储器中存储的监控数据处理程序时实现如下步骤：

步骤101、获取待监控数据。

待监控数据可根据监控系统应用的领域及所要监控的业务来设定。例如：监控系统应用在移动互联网中，想要对安装在智能手机上的某个应用程序进行监控，如某一个外卖应用程序，待监控数据具体可以为中央处理器(centralprocessingunit，简称：cpu)的使用率，则通过监控系统能够获知在该外卖应用程序运行期间，cpu的使用率的变化情况，并对其进行监控和告警。

监控系统可以设置在电子终端中，例如：通过软件的形式设置在电子终端中，在外卖应用程序运行期间获取cpu的使用率并对其进行监控和告警。或者，监控系统也可以设置在服务器端，通过移动互联网获取cpu的使用率并对其进行监控和告警。

步骤102、当待监控数据满足告警条件时，发出告警信息。

若监控数据处于异常运行范围内，视为满足告警条件；若处于正常范围内，视为不满足告警条件。

例如：当cpu的利用率大于或等于85％时，满足告警条件，可发出告警信息；当cpu的利用率小于85％时，视为不满足告警条件。

步骤103、根据待监控数据被获取的时间调整告警条件。

根据待监控数据被获取的时间调整告警条件，例如：在一个自然日中的不同时段设置不同的告警条件，在获取待监控数据的同时记录当前时刻，判断当前时刻处于一天中的哪个时段内，并提取该时段内所对应的告警条件，判断监控数据是否满足该告警条件。

例如：在一个自然日中9:00-18:00的时间段内，若cpu使用率大于或等于95％，视为满足告警条件，可发出告警信息；若cpu使用率小于95％，视为不满足告警条件。在一个自然日的其余时间段内若cpu使用率大于或等于50％，视为满足告警条件，可发出告警信息；若cpu使用率小于50％，视为不满足告警条件。

本实施例提供的技术方案，通过根据待监控数据被获取的时间来调整告警条件，根据调整后的告警条件确定待监控数据是否满足，若满足调整后的告警条件，则发出告警信息，相当于设定了至少两个告警条件，根据时段不同采用不同的告警条件，使得监控系统进行告警的准确度更高。

上述cpu使用率仅作为一个例子，并不表示cpu使用率是唯一的一种待监控数据。待监控数据还可以为内存占用率或其它需要监控的数据。

实施例二

本实施例是在上述实施例的基础对监控数据处理方法进行优化，尤其是对调整告警条件的方式进行进一步的优化。

图2为本申请实施例二提供的监控数据处理方法的流程图。如图2所示，本实施例提供的监控数据处理方法包括：

步骤101、获取待监控数据。

待监控数据可根据监控系统应用的领域及所要监控的业务来设定。例如：监控系统应用在移动互联网中，想要对安装在智能手机上的某个应用程序进行监控，如某一个外卖应用程序，待监控数据具体可以为中央处理器(centralprocessingunit，简称：cpu)的使用率，则通过监控系统能够获知在该外卖应用程序运行期间，cpu的使用率的变化情况，并对其进行监控和告警。

监控系统可以设置在电子终端中，例如：通过软件的形式设置在电子终端中，在外卖应用程序运行期间获取cpu的使用率并对其进行监控和告警。或者，监控系统也可以设置在服务器端，通过移动互联网获取cpu的使用率并对其进行监控和告警。

步骤102、当待监控数据满足告警条件时，发出告警信息。

若监控数据处于异常运行范围内，视为满足告警条件；若处于正常范围内，视为不满足告警条件。

例如：当cpu的利用率大于或等于85％时，满足告警条件，可发出告警信息；当cpu的利用率小于85％时，视为不满足告警条件。

上述实施例一中的步骤103，具体可采用如下方式来实现：

步骤1031、根据待监控数据对应业务的繁忙程度将业务运行时间划分为至少两个时间区间。

每个时间区间对应一个目标告警条件。

繁忙程度可以用该业务的使用频率或使用量来进行考量，从狭义上说能够通过传输数据包的数量来确定该业务是否繁忙。

该步骤中，可将业务的繁忙程度分为：繁忙和空闲两个状态，繁忙状态对应一个时间区间，空闲状态对应另一个时间区间。或者，还可以将业务的繁忙程度分为：繁忙、一半繁忙及空闲，分别对应一个时间区间。

例如：在人们的工作时间9:00-18:00，邮箱的使用率较高，繁忙程度较高；而在非工作时间18:00-次日9:00，邮箱的使用率较低，繁忙程度不高。则可以根据邮箱的使用繁忙程度划分为9:00-18:00和18:00-次日9:00两个时间区间。

每个时间区间对应一个目标告警条件，9:00-18:00所对应的目标告警条件为95％，18:00-次日9:00所对应的目标告警条件为50％。

再例如：在10:00-13:00，很多人会在这个时间段通过电子终端上设置的应用程序点外卖，该应用程序的繁忙程度较高；在13:00-20:00，少部分人会通过该应用程序点外卖，该应用程序的繁忙程度较低；在20:00-次日10:00，极少数人会通过该应用程序点外卖，该应用程序的繁忙程度非常低。因此，可根据点外卖的应用程序的繁忙程度将一个自然日划分为三个时间段：10:00-13:00、13:00-20:00、以及20:00-次日10:00。

每个时间区间对应一个目标告警条件，10:00-13:00所对应的目标告警条件为95％，13:00-20:00对应的目标告警条件为85％，20:00-次日10:00所对应的目标告警条件为50％。

步骤1032、确定待监控数据被获取的时间所落入的时间区间。

具体就是确定待监控数据被获取的时间处于哪个时间区间内，通过该时间区间就能获知当前业务繁忙的程度。

步骤1033、将告警条件修改为落入的时间区间所对应的目标告警条件。

根据当前业务繁忙的程度来修改告警条件，若落入的时间区间对应繁忙状态，则采用繁忙状态所对应的目标告警条件来对待监控数据进行告警判断；若落入的时间区间对应空闲状态，则采用空闲状态所对应的目标告警条件来对待监控数据进行告警判断。

以点外卖的应用程序作为监控业务为例，若cpu使用率被获取的时间为12:00，落入了时间区间10:00-13:00，对应繁忙状态。则将告警条件修改为时间区间10:00-13:00所对应的目标告警条件，即：修改为95％。相当于在时间区间10:00-13:00内，cpu使用率大于或等于95％，才满足告警条件，发出告警信息。

相比于相关技术中，在时间区间10:00-13:00内，点外卖的人比较多，应用程序比较繁忙，cpu使用率通常都会大于85％，属于正常情况，而不属于故障。若依照相关技术将告警条件固定设置为85％，则在这个时间区间内，监控系统会频繁的发出告警信息，对业务的正常运行造成了干扰。

另一方面，若cpu使用率被获取的时间为22:00，落入了时间区间20:00-次日10:00，对应空闲状态。则将告警条件修改为时间区间20:00-次日10:00所对应的目标告警条件，即：修改为50％。相当于在时间区间20:00-次日10:00内，cpu使用率大于或等于50％，才满足告警条件，发出告警信息。

相比于相关技术中，在时间区间20:00-次日10:00内，点外卖的人极少，应用程序处于空闲时段，cpu使用率通常都会小于50％，一旦大于70％就视为不正常。若依照相关技术将告警条件固定设置为85％，则在这个时间区间内，只要cpu使用率低于85％就不会产生告警信息，会漏掉可能发生的异常事件。

而采用本实施例所提供的方案，根据业务的繁忙程度划分为至少两个时间段，每个时间段对应一个目标告警条件，根据不同的时段采用相应的告警条件来对待监控数据进行判断和告警处理，不但能够避免业务高峰期产生较多的误告警，还能够提高业务低谷期的告警敏感度，避免遗漏。

上述繁忙程度可根据业务的种类来进行设定，例如上述业务类型为邮箱，就可以将繁忙程度设定为：繁忙状态和空闲状态，对应划分为两个时间段。若上述业务类型为外卖应用程序，则可以将繁忙程度设定为：空闲状态、一般繁忙状态及繁忙状态，对应划分为三个时间段。

进一步的，还可以根据待监控数据对应业务处于繁忙状态的持续时间调整告警条件。若业务处于繁忙状态的持续时间较长，相比于正常的持续时间延长了，则可以依据繁忙状态所对应的目标告警条件对待监控数据进行处理。若业务处于繁忙状态的持续时间较短，相当于繁忙状态提前结束了，可以根据空闲状态的目标告警条件对待监控数据进行处理。

具体的，若待监控数据对应业务处于繁忙状态的持续时间超过对应的时间区间，将告警条件修改为繁忙状态所对应的目标告警条件。

例如：繁忙状态所对应的设定时间段为10:00-13:00，所采用的告警条件为95％。但是在实际运行过程中，业务在13：00后仍处于繁忙状态，若将告警条件修改为85％，则会出现误报警的现象。因此，在13:00后，根据繁忙状态所对应的目标告警条件95％对待监控数据进行处理。

若待监控数据对应业务处于繁忙状态的持续时间少于对应的时间区间，相当于提前结束了，则将告警条件修改为一般繁忙状态或空闲状态所对应的目标告警条件。

例如：繁忙状态所对应的设定时间段为10:00-13:00，所采用的告警条件为95％。但是在实际运行过程中，繁忙状态在12:30就提前结束了，若仍然采用95％的告警条件，则有可能漏掉一些关键故障数据。因此，在繁忙状态结束后，将告警条件修改为一般繁忙状态或空闲状态所对应的目标告警条件，即：85％或50％，就能够避免漏掉关键的故障数据。

再进一步，若识别出有能够改变待监控数据对应业务繁忙程度的事件被触发，则根据待监控数据对应业务的繁忙程度调整告警条件。

能够改变待监控数据对应业务繁忙程度的事件被触发，在一种正常的运行情况，只是改变了业务的繁忙程度，但不属于需要告警的情况。

例如：对于待监控数据为cpu使用率的情况而言，能够改变待监控数据对应业务繁忙程度的事件可以为系统更新，在系统更新的过程中cpu的使用率较高，这属于正常现象。在电子终端启动了系统更新之后，如若依照相关技术中按照恒定的告警条件对待监控数据进行处理，则会出现误报警。

因此，本实施例中，当识别出启动了系统更新，则根据业务的繁忙程度调整告警条件，例如：当业务处于繁忙状态时，可以增大告警条件，如增大至98％；当业务处于空闲状态时，可以增大告警条件，如增大至60％。

上述繁忙程度的获取方式可根据历史数据或经验来设定，监控系统预先考察一段时间内业务的繁忙程度，确定变化规律，然后根据变化规律确定繁忙程度。业务的繁忙程度可通过传输的数据包来确定，若数据包数量较多，表明业务较为繁忙；若数据包数量较少，表明业务空闲。

上述邮箱应用程序和点外卖的应用程序仅作为两个例子，二者均能够应用本实施例所提供的方法，当然，本实施例所提供的方法不仅能够应用于该两个应用程序中，还可以应用于电子终端中的其它应用程序，也能够对电子终端本身的运行状态进行监控。本领域技术人员可以根据实际应用的场景，对本实施例所提供的方法进行直接应用或进行适应性修改后进行应用。

实施例三

图3为本申请实施例三提供的监控数据处理装置的结构示意图。如图3所示，本实施例提供一种监控数据处理装置，包括：待监控数据获取模块31、告警信息发出模块32和告警条件调整模块33。

其中，待监控数据获取模块31用于获取待监控数据。告警信息发出模块32用于当待监控数据满足告警条件时，发出告警信息。告警条件调整模块33用于根据待监控数据被获取的时间调整告警条件，以使新获取到的待监控数据根据调整后的告警条件进行告警。

待监控数据可根据监控系统应用的领域及所要监控的业务来设定。例如：监控系统应用在移动互联网中，想要对安装在智能手机上的某个应用程序进行监控，如某一个外卖应用程序，待监控数据具体可以为cpu的使用率，则通过监控系统能够获知在该外卖应用程序运行期间，cpu的使用率的变化情况，并对其进行监控和告警。

监控系统可以设置在电子终端中，例如：通过软件的形式设置在电子终端中，在外卖应用程序运行期间获取cpu的使用率并对其进行监控和告警。或者，监控系统也可以设置在服务器端，通过移动互联网获取cpu的使用率并对其进行监控和告警。

本实施例提供的技术方案，通过根据待监控数据被获取的时间来调整告警条件，根据调整后的告警条件确定待监控数据是否满足，若满足调整后的告警条件，则发出告警信息，相当于设定了至少两个告警条件，根据时段不同采用不同的告警条件，使得监控系统进行告警的准确度更高。

上述告警条件调整模块33具体包括：时间区间划分单元、时间区间确定单元和告警条件修改单元。其中，时间区间划分单元用于根据待监控数据对应业务的繁忙程度将业务运行时间划分为至少两个时间区间，每个时间区间对应一个目标告警条件。时间区间确定单元用于确定待监控数据被获取的时间所落入的时间区间。告警条件修改单元将告警条件修改为落入的时间区间所对应的目标告警条件。

上述待监控数据对应业务的繁忙程度包括：空闲状态、一般繁忙状态及繁忙状态。

进一步的，告警条件调整模块33还用于根据待监控数据对应业务处于繁忙状态的持续时间调整所述告警条件，具体用于当待监控数据对应业务处于繁忙状态的持续时间超过对应的时间区间时，将告警条件修改为繁忙状态应的目标告警条件；当待监控数据对应业务处于繁忙状态的持续时间少于对应的时间区间，将告警条件修改为一般繁忙状态或空闲状态所对应的目标告警条件。

告警条件调整模块33还用于当识别出有能够改变待监控数据对应业务繁忙程度的事件被触发，则根据待监控数据对应业务的繁忙程度调整告警条件。

上述监控数据处理装置能够执行上述任一实施例所提供的方法，具备与方法相同的技术效果。

实施例四

图4为本申请实施例四提供的监控系统的结构示意图。如图4所示，本实施例提供一种监控系统，包括：存储器、处理器、以及计算机程序。

其中，计算机程序存储在存储器中，并被配置为由处理器执行以实现如上述任一实施例所提供的方法。

本实施例提供的监控系统，通过根据待监控数据被获取的时间来调整告警条件，根据调整后的告警条件确定待监控数据是否满足，若满足调整后的告警条件，则发出告警信息，相当于设定了至少两个告警条件，根据时段不同采用不同的告警条件，使得监控系统进行告警的准确度更高。

本实施例还提供一种计算机可读存储介质，其特征在于，其上存储有计算机程序；该计算机程序被处理器执行以实现如上任一实施例所提供的方法，具备与方法相同的技术效果。

本领域内的技术人员应明了，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。