CN109600279A - 基于日志流的动态监控方法、设备、存储介质及装置 - Google Patents

Abstract

本发明公开了一种基于日志流的动态监控方法、设备、存储介质及装置，该方法包括：获取系统中应用程序的第一服务重要级别，查找与第一服务重要级别对应的第一监控规则，根据第一监控规则监控对应的应用程序；获取系统的应用程序日志，每隔预设间隔时间从应用程序日志中提取出当前请求数据；根据当前请求数据判断是否调整第一服务重要级别，获得判断结果；若判断结果为需要调整，则根据当前请求数据调整第一服务重要级别，获得应用程序的第二服务重要级别；查找与第二服务重要级别对应的第二监控规则，根据第二监控规则监控对应的应用程序。基于安全监控，监控规则基于实际数据动态调整，更加贴近实际业务场景，提高监控的准确性。

Description

基于日志流的动态监控方法、设备、存储介质及装置

技术领域

本发明涉及安全监控技术领域，尤其涉及一种基于日志流的动态监控方法、设备、存储介质及装置。

背景技术

目前，市面的监控系统监控项一般为静态配置，需要用户或技术人员事先设定监控规则，对于监控的目标、阈值和规则的精度较差，预警效果不理想，并且高度依赖技术人员的业务水平，事后需要技术人员不断调整，达到理想阀值，依赖人工操作，规则的复用性较差，预警效果也不理想。因此，如何合理设置监控规则以提高监控的准确性是亟待解决的技术问题。

上述内容仅用于辅助理解本发明的技术方案，并不代表承认上述内容是现有技术。

发明内容

本发明的主要目的在于提供一种基于日志流的动态监控方法、设备、存储介质及装置，旨在解决现有技术中监控规则设置不合理及监控准确性低的技术问题。

为实现上述目的，本发明提供一种基于日志流的动态监控方法，所述基于日志流的动态监控方法包括以下步骤：

获取系统中应用程序的第一服务重要级别，查找与所述第一服务重要级别对应的第一监控规则，根据所述第一监控规则监控对应的应用程序；

获取所述系统的应用程序日志，每隔预设间隔时间从所述应用程序日志中提取出当前请求数据；

根据所述当前请求数据判断是否调整所述第一服务重要级别，获得判断结果；

若所述判断结果为需要调整，则根据所述当前请求数据调整所述第一服务重要级别，获得应用程序的第二服务重要级别；

查找与所述第二服务重要级别对应的第二监控规则，根据所述第二监控规则监控对应的应用程序。

优选地，所述查找与所述第二服务重要级别对应的第二监控规则，根据所述第二监控规则监控对应的应用程序之后，所述基于日志流的动态监控方法还包括：

实时监测所述应用程序日志，当监测到新的应用程序时，获取与所述新的应用程序同一链路的关联配置规则；

通过所述关联配置规则对所述新的应用程序进行监控。

优选地，所述通过所述关联配置规则对所述新的应用程序进行监控之后，所述基于日志流的动态监控方法还包括：

查找与所述第二服务重要级别对应的目标预警阈值；

从所述当前请求数据中提取出应用程序对应的报错数据，判断所述报错数据是否超过所述目标预警阈值；

若所述报错数据超过所述目标预警阈值，则发送所述报错数据至用户设备，以进行预警。

优选地，所述若所述报错数据超过所述目标预警阈值，则发送所述报错数据至用户设备，以进行预警，包括：

若所述报错数据超过所述目标预警阈值，则通过预设预警模型评估所述报错数据的目标预警等级；

发送所述报错数据和所述目标预警等级至用户设备，以进行预警。

优选地，所述发送所述报错数据和所述目标预警等级至用户设备，以进行预警之后，所述基于日志流的动态监控方法还包括：

接收用户对所述报错数据和所述目标预警等级的反馈信息；

根据所述反馈信息调整所述目标预警阈值。

优选地，所述根据所述反馈信息调整所述目标预警阈值，包括：

从所述反馈信息中提取出反馈的目标事件级别，查找与所述目标事件级别对应的目标调整幅度；

根据所述目标调整幅度调整所述目标预警阈值。

优选地，所述获取系统中应用程序的第一服务重要级别，查找与所述第一服务重要级别对应的第一监控规则，根据所述第一监控规则监控对应的应用程序之前，所述基于日志流的动态监控方法还包括：

获取系统的应用程序日志，从所述应用程序日志中提取预设历史时段的历史请求数据；

根据所述历史请求数据设置系统中应用程序的第一服务重要级别。

此外，为实现上述目的，本发明还提出一种基于日志流的动态监控设备，所述基于日志流的动态监控设备包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的基于日志流的动态监控程序，所述基于日志流的动态监控程序配置为实现如上文所述的基于日志流的动态监控方法的步骤。

此外，为实现上述目的，本发明还提出一种存储介质，所述存储介质上存储有基于日志流的动态监控程序，所述基于日志流的动态监控程序被处理器执行时实现如上文所述的基于日志流的动态监控方法的步骤。

此外，为实现上述目的，本发明还提出一种基于日志流的动态监控装置，所述基于日志流的动态监控装置包括：

监控模块，用于获取系统中应用程序的第一服务重要级别，查找与所述第一服务重要级别对应的第一监控规则，根据所述第一监控规则监控对应的应用程序；

提取模块，用于获取所述系统的应用程序日志，每隔预设间隔时间从所述应用程序日志中提取出当前请求数据；

判断模块，用于根据所述当前请求数据判断是否调整所述第一服务重要级别，获得判断结果；

调整模块，用于若所述判断结果为需要调整，则根据所述当前请求数据调整所述第一服务重要级别，获得应用程序的第二服务重要级别；

所述监控模块，还用于查找与所述第二服务重要级别对应的第二监控规则，根据所述第二监控规则监控对应的应用程序。

本发明中，通过获取系统中应用程序的第一服务重要级别，查找与所述第一服务重要级别对应的第一监控规则，根据所述第一监控规则监控对应的应用程序，根据服务重要级别不同配置不同的监控规则，监控策略灵活，更符合实际需求，以使重要的服务能够更大力度地被监控；获取所述系统的应用程序日志，每隔预设间隔时间从所述应用程序日志中提取出当前请求数据，根据所述当前请求数据判断是否调整所述第一服务重要级别，获得判断结果，若所述判断结果为需要调整，则根据所述当前请求数据调整所述第一服务重要级别，获得应用程序的第二服务重要级别，查找与所述第二服务重要级别对应的第二监控规则，根据所述第二监控规则监控对应的应用程序，基于安全监控，监控规则及服务重要级别基于实际数据动态调整，更加贴近实际业务场景，从而提高监控的准确性。

附图说明

图1是本发明实施例方案涉及的硬件运行环境的基于日志流的动态监控设备的结构示意图；

图2为本发明基于日志流的动态监控方法第一实施例的流程示意图；

图3为本发明基于日志流的动态监控方法第二实施例的流程示意图；

图4为本发明基于日志流的动态监控方法第三实施例的流程示意图；

图5为本发明基于日志流的动态监控装置第一实施例的结构框图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

参照图1，图1为本发明实施例方案涉及的硬件运行环境的基于日志流的动态监控设备结构示意图。

如图1所示，该基于日志流的动态监控设备可以包括：处理器1001，例如中央处理器(Central Processing Unit，CPU)，通信总线1002、用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)，可选用户接口1003还可以包括标准的有线接口、无线接口，对于用户接口1003的有线接口在本发明中可为USB接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如无线保真(WIreless-FIdelity，WI-FI)接口)。存储器1005可以是高速的随机存取存储器(Random Access Memory，RAM)存储器，也可以是稳定的存储器(Non-volatileMemory，NVM)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的结构并不构成对基于日志流的动态监控设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及基于日志流的动态监控程序。

在图1所示的基于日志流的动态监控设备中，网络接口1004主要用于连接后台服务器，与所述后台服务器进行数据通信；用户接口1003主要用于连接用户设备；所述基于日志流的动态监控设备通过处理器1001调用存储器1005中存储的基于日志流的动态监控程序，并执行本发明实施例提供的基于日志流的动态监控方法。

基于上述硬件结构，提出本发明基于日志流的动态监控方法的实施例。

参照图2，图2为本发明基于日志流的动态监控方法第一实施例的流程示意图，提出本发明基于日志流的动态监控方法第一实施例。

在第一实施例中，所述基于日志流的动态监控方法包括以下步骤：

步骤S10：获取系统中应用程序的第一服务重要级别，查找与所述第一服务重要级别对应的第一监控规则，根据所述第一监控规则监控对应的应用程序。

应理解的是，本实施例的执行主体是所述基于日志流的动态监控设备，其中，所述基于日志流的动态监控设备可为个人电脑或服务器等电子设备。操作系统都设计有各种各样的日志文件，如应用程序日志，安全日志、系统日志、调度程序(Scheduler)服务日志和文件传输协议(File Transfer Protocol，简写FTP)日志等。为了实现对应用程序设置相应的监控规则，可获取应用程序日志，对应用程序日志进行分析，以对各应用程序设置更符合需求的监控规则。可从所述应用程序中提取出预设历史时段的历史请求数据，所述预设历史时段可以是从当前时刻往前24小时或48小时等时段，所述历史请求数据包括接口访问量和接口响应时间等信息。根据所述历史请求数据设置各应用程序的所述第一服务重要级别。比如，所述第一服务重要级别可设置为1-4个级别，对所述服务重要级别可通过预设颜色区分规则来区分不同级别，可以根据色块的颜色深浅来区分不同的级别，所述第一服务重要级别的数值越小说明级别越高，对应的服务色块越深(ColorBolck)，说明重要程度越高。还可以设置其他数量的级别及颜色区分规则，本实施例对此不加以限制。本实施例中，所述步骤S10之前，还包括：获取系统的应用程序日志，从所述应用程序日志中提取预设历史时段的历史请求数据；根据所述历史请求数据设置系统中应用程序的第一服务重要级别。

例如，在所述预设历史时段，应用程序A的接口访问量为大于10万次，则可将所述应用程序A的所述第一服务重要级别设置为1级，即最高级别，重要程度最高，色块颜色最深；应用程序B的接口访问量为5万次-10万次，则可将所述应用程序B的服务重要级别设置为2级，重要程度第二高，色块颜色第二深；应用程序C的接口访问量为1万次-5万次，则可将所述应用程序C的服务重要级别设置为3级，重要程度第三高，色块颜色第三深；应用程序D的接口访问量为小于1万次，则可将所述应用程序D的服务重要级别设置为4级，即最低级别，重要程度最低，色块颜色最浅。

可理解的是，为了更加贴合实际需求，对于不同的所述第一服务重要级别的应用程序设置不同的所述第一监控规则。所述第一服务重要级别越高，也就是越重要的应用程序，设置监控力度越大的所述第一监控规则。可根据所述历史请求数据，结合以往设置的监控规则，为不同的服务重要级别的应用程序预先设置对应的监控规则，可预先建立所述服务重要级别与监控规则之间的对应关系，并将所述服务重要级别与监控规则之间的对应关系存储于第一映射关系表中。对于不同的应用程序，获取所述应用程序对应的所述第一服务重要级别，从所述第一映射关系表中查找与所述第一服务重要级别对应的第一监控规则，所述第一映射关系表包括服务重要级别与监控规则之间的对应关系。则可根据所述第一监控规则监控对应的应用程序。

比如，1级的服务重要级别，重要程度最高，可设置对应的1级监控规则为：httpCode>400监控、访问时延Delay超过200ms监控和访问错误比例高于1％监控等策略；而对于4级的服务重要级别，重要程度较弱，则可设置对应的4级监控规则为：httpCode>500监控、访问时延Delay超过400ms监控和访问错误比例高于4％监控等策略。若应用程序A为的所述第一服务重要级别为1级，则可通过上述1级监控规则对所述应用程序A进行监控。

步骤S20：获取所述系统的应用程序日志，每隔预设间隔时间从所述应用程序日志中提取出当前请求数据。

需要说明的是，为了使得所述服务重要级别更贴近真实数据情况，对所述应用程序日志进行实时监测，每隔所述预设间隔时间从所述应用程序日志中提取出所述当前服务请求数据，所述当前服务请求数据包括在所述预设间隔时间内各应用程序的接口访问量和接口响应时间等信息。所述预设间隔时间为根据以往经验值设置的所述监控规则的执行时间范围，可根据所述预设历史时段的告警次数进行设置，比如所述预设历史时段为前一天，若前一天的告警次数较多，则可将所述预设间隔时间设置为较小的值，从而更加频繁的对所述应用程序日志中数据进行分析，能够快速发现系统中的众多异常信息。为了避免过于频繁的调整监控规则，所述预设间隔时间可结合监控周期来设置，通常以日为周期，所述当前监测周期为T日，上一监测周期即是T-1日，可根据所述应用程序日志在T-1日内的接口访问量和接口响应时间等信息来设置所述预设间隔时间。若所述T-1日内的接口访问量和接口响应时间波动不大，则可将所述预设间隔时间设置为较大的值，从而避免太过频繁的从所述应用程序日志中提取出当前请求数据；若所述T-1日内的接口访问量和接口响应时间波动较大，则可将所述预设间隔时间设置为较小的值，从而更加频繁的对所述应用程序日志中数据进行分析，能够使得监控规则更加贴合实际业务场景。

步骤S30：根据所述当前请求数据判断是否调整所述第一服务重要级别，获得判断结果。

应理解的是，所述第一服务重要级别通常是根据所述预设历史时段的历史请求数据进行设置的，可能与当前监控周期内的实际业务数据有偏差，所述当前请求数据能够反映当前监控周期内的实际业务数据。不同服务重要级别的设定通常是根据接口访问量进行设置的，可根据所述预设间隔时间的不同设置不同服务重要级别对应的接口访问量。从所述当前请求数据中提取出当前接口访问量，获取在所述预设间隔时间内所述第一服务重要级别对应的第一接口访问量，若所述当期接口访问量满足所述第一接口访问量，则所述判断结果为无需调整所述第一服务重要级别；若所述当期接口访问量不满足所述第一接口访问量，则所述判断结果为需要调整所述第一服务重要级别。

步骤S40：若所述判断结果为需要调整，则根据所述当前请求数据调整所述第一服务重要级别，获得应用程序的第二服务重要级别。

在具体实现中，从所述当前服务请求数据中提取出各应用程序在所述预设间隔时间内的接口访问量或者接口响应时间等信息，根据所述接口访问量或者接口响应时间等信息判断是否对各应用程序的服务重要级别进行调整。比如，上述例子中的所述应用程序A的所述第一服务重要级别为1级，所述预设间隔时间为6小时，在所述预设间隔时间内所述应用程序A的接口访问量为20000次，1级的服务重要级别在所述预设间隔时间内的接口访问量为超过25000次，2级的服务重要级别在所述预设间隔时间内的接口访问量为12500次至25000次，在所述预设间隔时间内所述应用程序A的接口访问量不满足1级的服务重要级别在所述预设间隔时间内的接口访问量，则调整所述第一服务重要级别，获得所述第二服务重要级别为2级的服务重要级别。

步骤S50：查找与所述第二服务重要级别对应的第二监控规则，根据所述第二监控规则监控对应的应用程序。

应理解的是，预先建立所述服务重要级别与监控规则之间的对应关系，并将所述服务重要级别与监控规则之间的对应关系存储于所述第一映射关系表中。则从所述第一映射关系表中查找与所述第二服务重要级别对应的第二监控规则，所述第一映射关系表包括服务重要级别与监控规则之间的对应关系。则可根据所述第一监控规则监控对应的应用程序。

例如，比如，1级的服务重要级别，重要程度最高，可设置对应的1级监控规则为：httpCode>400监控、访问时延Delay超过200ms监控和访问错误比例高于1％监控等策略；2级的服务重要级别，重要程度第二高，可设置对应的2级监控规则为：httpCode>400监控、访问时延Delay超过300ms监控和访问错误比例高于2％监控等策略。上述例子中的所述应用程序A在所述预设间隔时间内的接口访问量比所述应用程序B低，但比所述应用程序C高，则可调整所述应用程序A的服务重要级别为2级，所述应用程序B的服务重要级别为1级，则根据所述2级监控规则对所述应用程序A进行监控，根据所述1级监控规则对所述应用程序B进行监控。

本实施例中，通过获取系统中应用程序的第一服务重要级别，查找与所述第一服务重要级别对应的第一监控规则，根据所述第一监控规则监控对应的应用程序，根据服务重要级别不同配置不同的监控规则，监控策略灵活，更符合实际需求，以使重要的服务能够更大力度地被监控；获取所述系统的应用程序日志，每隔预设间隔时间从所述应用程序日志中提取出当前请求数据，根据所述当前请求数据判断是否调整所述第一服务重要级别，获得判断结果，若所述判断结果为需要调整，则根据所述当前请求数据调整所述第一服务重要级别，获得应用程序的第二服务重要级别，查找与所述第二服务重要级别对应的第二监控规则，根据所述第二监控规则监控对应的应用程序，基于安全监控，监控规则及服务重要级别基于实际数据动态调整，更加贴近实际业务场景，从而提高监控的准确性。

参照图3，图3为本发明基于日志流的动态监控方法第二实施例的流程示意图，基于上述图2所示的第一实施例，提出本发明基于日志流的动态监控方法的第二实施例。

在第二实施例中，在所述步骤S50之后，还包括：

步骤S60：实时监测所述应用程序日志，当监测到新的应用程序时，获取与所述新的应用程序同一链路的关联配置规则。

可理解的是，获取所述应用程序日志，对所述应用程序日志进行分析，获得正在运行中的原始应用程序，对各原始应用程序配置相应的配置规则，所述配置规则是由系统配套进行预设的。对所述应用程序日志进行实时监控，若所述应用程序日志中出现新的应用程序对应的请求数据信息，则认定出现新的应用程序，获取与所述新的应用程序在同一链路中的原始应用程序，同一链路中的原始应用程序对应的配置规则即为所述关联配置规则，通过所述关联配置规则对新的应用程序进行监测。多次使用相同跟踪地址(TraceID)进行服务提供的应用程序认为是在同一链路中。

步骤S70：通过所述关联配置规则对所述新的应用程序进行监控。

应理解的是，在获取到同一链路中的所述关联配置规则，同一链路中的各应用程序提供同等效力的服务，可通过相同的监控规则进行监控，则可对所述新的应用程序通过所述关联配置规则进行监控。同时，还会对所述新的应用程序配置“访问时延(Delay)监控”和“服务HttpCode(4xx或5xx)监控”。

例如：如原来应用程序A调用应用程序B，某日新增了一个应用程序C，调用链路变成了应用程序A调用应用程序B、应用程序B再调用应用程序C。此时应用程序C即为新的应用程序，所述关联配置规则即为应用程序A和应用程序B中出现过的规则，应用程序C由于与应用程序A和应用程序B提供同等效力的服务，则应用程序C也会自动加上相关的监控规则。同时应用程序C会配置上“访问时延(Delay)监控”和“服务HttpCode(4xx或5xx)监控”等静默规则，具体的静默规则由系统预设。

在第二实施例中，在所述步骤S70之后，还包括：

步骤S80：查找与所述第二服务重要级别对应的目标预警阈值。

需要说明的是，不同的服务重要级别分别设置了不同的预警阈值，对于服务重要级别的数值越小说明级别越高，对应的服务色块越深(ColorBolck)，说明重要程度越高，相应的预警阈值越严格，涉及的需要预警的数据范围更宽。各种服务重要级别对应的监控规则中都设置了各监控项目对应的预警阈值，若在实际监测过程中，监测到监控项目对应的数据超过对应的预警阈值，则会进行预警。也就是说可从所述第二服务重要级别的监控规则中查找到对应的所述目标预警阈值。

比如，1级的服务重要级别，重要程度最高，可设置监控规则为：httpCode>400监控、访问时延Delay超过200ms监控和访问错误比例高于1％监控等策略；而对于4级的服务重要级别，重要程度最弱，则可设置监控规则为：httpCode>500监控、访问时延Delay超过400ms监控和访问错误比例高于4％监控等策略。该例子中httpCode>400、时延Delay超过200ms和访问错误比例高于1％等为预警阈值，1级的服务重要级别高于4级的服务重要级别，因此相应的预警阈值越严格，涉及的需要预警的数据范围更宽，对于访问时延Delay的预警阈值，在所述第二服务重要级别为1级时，对应的所述目标预警阈值为超过200ms，在所述第二服务重要级别为4级时，对应的所述目标预警阈值为超过400ms，从而实现对越重要的服务预警的数据范围更宽，以便能够及时对重要的服务定位故障，保证重要的服务能够顺利执行。

步骤S90：从所述当前请求数据中提取出应用程序对应的报错数据，判断所述报错数据是否超过所述目标预警阈值。

在具体实现中，所述报错数据包括应用程序的httpCode、时延信息、请求错误数和请求错误占比中的至少一项，判断各报错数据是否超过对应的目标预警阈值，若超过，则需要发送所述报错数据至用户设备，以进行预警。在上述例子中，对于时延信息，在所述第二服务重要级别为1级时，对应的所述目标预警阈值为超过200ms，若从所述当前请求数据中提取出应用程序对应的报错数据中时延为300ms，超过所述目标预警阈值，则需要进行预警；若所述报错数据中时延为100ms，未超过所述目标预警阈值，则不需要进行预警。

步骤S100：若所述报错数据超过所述目标预警阈值，则发送所述报错数据至用户设备，以进行预警。

应理解的是，若所述报错数据超过所述目标预警阈值，说明所述应用程序可能存在异常，需要发送所述报错数据至所述用户设备，以进行预警，使得技术人员通过对所述报错数据进行分析，及时定位出异常服务。所述用户终端可以是个人计算机、智能手机、平板电脑或者服务器等电子设备，本实施例对此不加以限制。具体为推送至所述用户终端中的终端平台上，所述终端平台包括邮件、短信或微信等，从而实现对异常应用程序的预警。用户或技术人员通过所述用户设备查看所述报错数据，可根据所述报错数据进行相关处理，以及时解决异常点。

在第二实施例中，实时监测所述应用程序日志，当监测到新的应用程序时，获取与所述新的应用程序同一链路的关联配置规则，通过所述关联配置规则对所述新的应用程序进行监控，通过日志内容自动发现新应用程序，并自动加入链路相关的静默监控规则配置，实现了预警内容精准化，覆盖链路完整化；查找与所述第二服务重要级别对应的目标预警阈值，从所述当前请求数据中提取出应用程序对应的报错数据，判断所述报错数据是否超过所述目标预警阈值，若所述报错数据超过所述目标预警阈值，说明所述应用程序可能存在异常，则发送所述报错数据至用户设备，以进行预警，使得技术人员通过所述用户设备查看所述报错数据，根据所述报错数据进行相关处理，以及时解决异常点。

参照图4，图4为本发明基于日志流的动态监控方法第三实施例的流程示意图，基于上述图3所示的第二实施例，提出本发明基于日志流的动态监控方法的第三实施例。

在第三实施例中，所述步骤S100，包括：

步骤S101：若所述报错数据超过所述目标预警阈值，则通过预设预警模型评估所述报错数据的目标预警等级。

可理解的是，可获取以往的历史应用程序日志，从所述历史应用程序日志中提取出大量的历史请求数据，从所述历史请求数据中提取出各应用程序对应的历史报错数据及对应的历史预警等级，将所述历史报错数据及对应的历史预警等级输入卷积神经网络模型中进行训练，获得所述预设预警模型。预警等级包括：提示(INFO)、警告(WARN)、严重(ERROR)和致命(FATAL)等。则将应用程序对应的所述报错数据输入所述预设预警模型，所述预设预警模型输出所述目标预警等级。输出的所述目标预警等级为提示(INFO)、警告(WARN)、严重(ERROR)和致命(FATAL)中的一项。

步骤S102：发送所述报错数据和所述目标预警等级至用户设备，以进行预警。

需要说明的是，具体为将应用程序对应的所述报错数据和所述目标预警等级推送至所述用户终端中的终端平台上，所述终端平台包括邮件、短信或微信等，从而实现对应用程序存在的异常服务进行预警。用户或技术人员通过所述用户设备查看所述报错数据，可根据所述报错数据进行相关处理，以及时解决异常点，根据所述目标预警等级识别异常服务的重要程度，从而对所述目标预警等级为致命和严重的异常服务进行优先处理。

在第三实施例中，所述步骤S102之后，还包括：

步骤S110：接收用户对所述报错数据和所述目标预警等级的反馈信息。

在具体实现中，通常所述报错数据包括预警的应用程序相关的事件或服务，以使用户对所述报错数据进行处理，所述用户可以是技术人员或运营人员，并根据处理结果反馈所述报错数据涉及的服务或者事件为无效事件，普通事件、告警事件或者严重故障等。若认定所述报错数据为普通事件，则系统会接收技术人员或运营人员对所述报错数据的反馈信息，所述反馈信息包括所述报错数据对应的事件为无效事件，所述报错数据对应的事件为普通事件、所述报错数据对应的事件为告警事件或者所述报错数据对应的事件为严重故障等信息。

步骤S120：根据所述反馈信息调整所述目标预警阈值。

应理解的是，根据所述反馈信息进行对应的所述监控规则的调整，包括对所述监控规则中的所述目标预警阈值进行调整，可以是提高所述目标预警阈值，从而提高预警门槛。例如：原监控规则中对某服务接口的响应时间监控为200ms，设置的调整策略为反信息为所述报错数据为普通事件，则提升幅度50％，根据服务级别及事件处理结构对应不同幅度，当接收到所述反馈信息为事件被判定为普通事件，则所述目标预警阀值中响应时间监控对应的预警阈值提升为300ms，由200ms+200ms*50％＝300ms计算获得。

需要说明的是，还可根据所述反馈信息对所述目标预警等级进行调整，通常无效事件，普通事件、告警事件和严重故障分别对应的预警等级为提示、警告、严重和致命。比如，应用程序对应的所述目标预警等级为警告，但接收的反馈信息中的事件认定为无效事件，则后续相同的所述报错数据进行预警时，发送的所述目标预警等级为提示。

进一步地，在第三实施例中，所述步骤S120，包括：

从所述反馈信息中提取出反馈的目标事件级别，查找与所述目标事件级别对应的目标调整幅度；

根据所述目标调整幅度调整所述目标预警阈值。

可理解的是，所述目标事件级别包括无效事件，普通事件、告警事件或者严重故障等。不同的事件级别对应不同的调整幅度，对于无效事件和普通事件，为了避免过多的告警信息的发送，通常会适当提升所述目标预警阈值；对于告警事件和严重故障，为了能够及早发现故障信息，通常会适当降低所述目标预警阈值，从而及时对异常点进行处理。根据所述目标调整幅度调整所述监控规则中各监控项对应的所述目标预警阈值，所述监控项包括：httpCode监控项、访问时延和访问错误比例等。

比如，在所述目标事件级别为无效事件时，所述目标调整幅度设置为所述监控规则中各监控项对应的预警阈值都提升幅度为100％；在所述目标事件级别为普通事件，所述目标调整幅度设置为所述监控规则中各监控项对应的预警阈值都提升幅度为50％；在所述目标事件级别为告警事件，所述目标调整幅度设置为所述监控规则中各监控项对应的预警阈值都降低幅度为20％；在所述目标事件级别为告警事件，所述目标调整幅度设置为所述监控规则中各监控项对应的预警阈值都降低幅度为30％，还可以是其他幅度的设置，可根据历史请求数据进行分析而设置合理的所述目标调整幅度。

在第三实施例中，若所述报错数据超过所述目标预警阈值，则通过预设预警模型评估所述报错数据的目标预警等级，发送所述报错数据和所述目标预警等级至用户设备，以进行预警，根据所述目标预警等级识别异常服务的重要程度，从而对所述目标预警等级为致命和严重的异常服务进行优先处理；接收用户对所述报错数据和所述目标预警等级的反馈信息，根据所述反馈信息调整所述目标预警阈值，监控服务预警规则基于实际数据动态调整，更加贴近实际业务场景，提高了监控的准确性。

此外，本发明实施例还提出一种存储介质，所述存储介质上存储有基于日志流的动态监控程序，所述基于日志流的动态监控程序被处理器执行时实现如上文所述的基于日志流的动态监控方法的步骤。

此外，参照图5，本发明实施例还提出一种基于日志流的动态监控装置，所述基于日志流的动态监控装置包括：

监控模块10，用于获取系统中应用程序的第一服务重要级别，查找与所述第一服务重要级别对应的第一监控规则，根据所述第一监控规则监控对应的应用程序；

提取模块20，用于获取所述系统的应用程序日志，每隔预设间隔时间从所述应用程序日志中提取出当前请求数据；

判断模块30，用于根据所述当前请求数据判断是否调整所述第一服务重要级别，获得判断结果；

调整模块40，用于若所述判断结果为需要调整，则根据所述当前请求数据调整所述第一服务重要级别，获得应用程序的第二服务重要级别；

所述监控模块10，还用于查找与所述第二服务重要级别对应的第二监控规则，根据所述第二监控规则监控对应的应用程序。

应理解的是，操作系统都设计有各种各样的日志文件，如应用程序日志，安全日志、系统日志、调度程序(Scheduler)服务日志和文件传输协议(File Transfer Protocol，简写FTP)日志等。为了实现对应用程序设置相应的监控规则，可获取应用程序日志，对应用程序日志进行分析，以对各应用程序设置更符合需求的监控规则。可从所述应用程序中提取出预设历史时段的历史请求数据，所述预设历史时段可以是从当前时刻往前24小时或48小时等时段，所述历史请求数据包括接口访问量和接口响应时间等信息。根据所述历史请求数据设置各应用程序的所述第一服务重要级别。比如，所述第一服务重要级别可设置为1-4个级别，对所述服务重要级别可通过预设颜色区分规则来区分不同级别，可以根据色块的颜色深浅来区分不同的级别，所述第一服务重要级别的数值越小说明级别越高，对应的服务色块越深(ColorBolck)，说明重要程度越高。还可以设置其他数量的级别及颜色区分规则，本实施例对此不加以限制。本实施例中，所述获取系统中应用程序的第一服务重要级别，查找与所述第一服务重要级别对应的第一监控规则，根据所述第一监控规则监控对应的应用程序之前，还包括：获取系统的应用程序日志，从所述应用程序日志中提取预设历史时段的历史请求数据；根据所述历史请求数据设置系统中应用程序的第一服务重要级别。

例如，在所述预设历史时段，应用程序A的接口访问量为大于10万次，则可将所述应用程序A的所述第一服务重要级别设置为1级，即最高级别，重要程度最高，色块颜色最深；应用程序B的接口访问量为5万次-10万次，则可将所述应用程序B的服务重要级别设置为2级，重要程度第二高，色块颜色第二深；应用程序C的接口访问量为1万次-5万次，则可将所述应用程序C的服务重要级别设置为3级，重要程度第三高，色块颜色第三深；应用程序D的接口访问量为小于1万次，则可将所述应用程序D的服务重要级别设置为4级，即最低级别，重要程度最低，色块颜色最浅。

可理解的是，为了更加贴合实际需求，对于不同的所述第一服务重要级别的应用程序设置不同的所述第一监控规则。所述第一服务重要级别越高，也就是越重要的应用程序，设置监控力度越大的所述第一监控规则。可根据所述历史请求数据，结合以往设置的监控规则，为不同的服务重要级别的应用程序预先设置对应的监控规则，可预先建立所述服务重要级别与监控规则之间的对应关系，并将所述服务重要级别与监控规则之间的对应关系存储于第一映射关系表中。对于不同的应用程序，获取所述应用程序对应的所述第一服务重要级别，从所述第一映射关系表中查找与所述第一服务重要级别对应的第一监控规则，所述第一映射关系表包括服务重要级别与监控规则之间的对应关系。则可根据所述第一监控规则监控对应的应用程序。

比如，1级的服务重要级别，重要程度最高，可设置对应的1级监控规则为：httpCode>400监控、访问时延Delay超过200ms监控和访问错误比例高于1％监控等策略；而对于4级的服务重要级别，重要程度较弱，则可设置对应的4级监控规则为：httpCode>500监控、访问时延Delay超过400ms监控和访问错误比例高于4％监控等策略。若应用程序A为的所述第一服务重要级别为1级，则可通过上述1级监控规则对所述应用程序A进行监控。

需要说明的是，为了使得所述服务重要级别更贴近真实数据情况，对所述应用程序日志进行实时监测，每隔所述预设间隔时间从所述应用程序日志中提取出所述当前服务请求数据，所述当前服务请求数据包括在所述预设间隔时间内各应用程序的接口访问量和接口响应时间等信息。所述预设间隔时间为根据以往经验值设置的所述监控规则的执行时间范围，可根据所述预设历史时段的告警次数进行设置，比如所述预设历史时段为前一天，若前一天的告警次数较多，则可将所述预设间隔时间设置为较小的值，从而更加频繁的对所述应用程序日志中数据进行分析，能够快速发现系统中的众多异常信息。为了避免过于频繁的调整监控规则，所述预设间隔时间可结合监控周期来设置，通常以日为周期，所述当前监测周期为T日，上一监测周期即是T-1日，可根据所述应用程序日志在T-1日内的接口访问量和接口响应时间等信息来设置所述预设间隔时间。若所述T-1日内的接口访问量和接口响应时间波动不大，则可将所述预设间隔时间设置为较大的值，从而避免太过频繁的从所述应用程序日志中提取出当前请求数据；若所述T-1日内的接口访问量和接口响应时间波动较大，则可将所述预设间隔时间设置为较小的值，从而更加频繁的对所述应用程序日志中数据进行分析，能够使得监控规则更加贴合实际业务场景。

应理解的是，所述第一服务重要级别通常是根据所述预设历史时段的历史请求数据进行设置的，可能与当前监控周期内的实际业务数据有偏差，所述当前请求数据能够反映当前监控周期内的实际业务数据。不同服务重要级别的设定通常是根据接口访问量进行设置的，可根据所述预设间隔时间的不同设置不同服务重要级别对应的接口访问量。从所述当前请求数据中提取出当前接口访问量，获取在所述预设间隔时间内所述第一服务重要级别对应的第一接口访问量，若所述当期接口访问量满足所述第一接口访问量，则所述判断结果为无需调整所述第一服务重要级别，若所述当期接口访问量不满足所述第一接口访问量，则所述判断结果为需要调整所述第一服务重要级别。

在具体实现中，从所述当前服务请求数据中提取出各应用程序在所述预设间隔时间内的接口访问量或者接口响应时间等信息，根据所述接口访问量或者接口响应时间等信息判断是否对各应用程序的服务重要级别进行调整。比如，上述例子中的所述应用程序A的所述第一服务重要级别为1级，所述预设间隔时间为6小时，在所述预设间隔时间内所述应用程序A的接口访问量为20000次，1级的服务重要级别在所述预设间隔时间内的接口访问量为超过25000次，2级的服务重要级别在所述预设间隔时间内的接口访问量为12500次至25000次，在所述预设间隔时间内所述应用程序A的接口访问量不满足1级的服务重要级别在所述预设间隔时间内的接口访问量，则调整所述第一服务重要级别，获得所述第二服务重要级别为2级的服务重要级别。

应理解的是，预先建立所述服务重要级别与监控规则之间的对应关系，并将所述服务重要级别与监控规则之间的对应关系存储于所述第一映射关系表中。则从所述第一映射关系表中查找与所述第二服务重要级别对应的第二监控规则，所述第一映射关系表包括服务重要级别与监控规则之间的对应关系。则可根据所述第一监控规则监控对应的应用程序。

例如，比如，1级的服务重要级别，重要程度最高，可设置对应的1级监控规则为：httpCode>400监控、访问时延Delay超过200ms监控和访问错误比例高于1％监控等策略；2级的服务重要级别，重要程度第二高，可设置对应的2级监控规则为：httpCode>400监控、访问时延Delay超过300ms监控和访问错误比例高于2％监控等策略。上述例子中的所述应用程序A在所述预设间隔时间内的接口访问量比所述应用程序B低，但比所述应用程序C高，则可调整所述应用程序A的服务重要级别为2级，所述应用程序B的服务重要级别为1级，则根据所述2级监控规则对所述应用程序A进行监控，根据所述1级监控规则对所述应用程序B进行监控。

本实施例中，通过获取系统中应用程序的第一服务重要级别，查找与所述第一服务重要级别对应的第一监控规则，根据所述第一监控规则监控对应的应用程序，根据服务重要级别不同配置不同的监控规则，监控策略灵活，更符合实际需求，以使重要的服务能够更大力度地被监控；获取所述系统的应用程序日志，每隔预设间隔时间从所述应用程序日志中提取出当前请求数据，根据所述当前请求数据判断是否调整所述第一服务重要级别，获得判断结果，若所述判断结果为需要调整，则根据所述当前请求数据调整所述第一服务重要级别，获得应用程序的第二服务重要级别，查找与所述第二服务重要级别对应的第二监控规则，根据所述第二监控规则监控对应的应用程序，基于安全监控，监控规则及服务重要级别基于实际数据动态调整，更加贴近实际业务场景，从而提高监控的准确性。

在一实施例中，所述基于日志流的动态监控装置还包括：

实时监测模块，用于实时监测所述应用程序日志，当监测到新的应用程序时，获取与所述新的应用程序同一链路的关联配置规则；

所述监控模块10，还用于通过所述关联配置规则对所述新的应用程序进行监控。

在一实施例中，所述基于日志流的动态监控装置还包括：

查找模块，用于查找与所述第二服务重要级别对应的目标预警阈值；

所述提取模块20，还用于从所述当前请求数据中提取出应用程序对应的报错数据，判断所述报错数据是否超过所述目标预警阈值；

发送模块，用于若所述报错数据超过所述目标预警阈值，则发送所述报错数据至用户设备，以进行预警。

在一实施例中，所述基于日志流的动态监控装置还包括：

评估模块，用于若所述报错数据超过所述目标预警阈值，则通过预设预警模型评估所述报错数据的目标预警等级；

所述发送模块，还用于发送所述报错数据和所述目标预警等级至用户设备，以进行预警。

在一实施例中，所述基于日志流的动态监控装置还包括：

接收模块，用于接收用户对所述报错数据和所述目标预警等级的反馈信息；

所述调整模块40，还用于根据所述反馈信息调整所述目标预警阈值。

在一实施例中，所述查找模块，还用于从所述反馈信息中提取出反馈的目标事件级别，查找与所述目标事件级别对应的目标调整幅度；

所述调整模块40，还用于根据所述目标调整幅度调整所述目标预警阈值。

在一实施例中，所述提取模块20，还用于获取系统的应用程序日志，从所述应用程序日志中提取预设历史时段的历史请求数据；

设置模块，用于根据所述历史请求数据设置系统中应用程序的第一服务重要级别。

本发明所述基于日志流的动态监控装置的其他实施例或具体实现方式可参照上述各方法实施例，此处不再赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。词语第一、第二、以及第三等的使用不表示任何顺序，可将这些词语解释为标识。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如只读存储器镜像(Read Only Memory image，ROM)/随机存取存储器(Random AccessMemory，RAM)、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

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

Claims (10)

1.一种基于日志流的动态监控方法，其特征在于，所述基于日志流的动态监控方法包括以下步骤：

获取系统中应用程序的第一服务重要级别，查找与所述第一服务重要级别对应的第一监控规则，根据所述第一监控规则监控对应的应用程序；

获取所述系统的应用程序日志，每隔预设间隔时间从所述应用程序日志中提取出当前请求数据；

根据所述当前请求数据判断是否调整所述第一服务重要级别，获得判断结果；

若所述判断结果为需要调整，则根据所述当前请求数据调整所述第一服务重要级别，获得应用程序的第二服务重要级别；

查找与所述第二服务重要级别对应的第二监控规则，根据所述第二监控规则监控对应的应用程序。

2.如权利要求1所述的基于日志流的动态监控方法，其特征在于，所述查找与所述第二服务重要级别对应的第二监控规则，根据所述第二监控规则监控对应的应用程序之后，所述基于日志流的动态监控方法还包括：

实时监测所述应用程序日志，当监测到新的应用程序时，获取与所述新的应用程序同一链路的关联配置规则；

通过所述关联配置规则对所述新的应用程序进行监控。

3.如权利要求2所述的基于日志流的动态监控方法，其特征在于，所述通过所述关联配置规则对所述新的应用程序进行监控之后，所述基于日志流的动态监控方法还包括：

查找与所述第二服务重要级别对应的目标预警阈值；

从所述当前请求数据中提取出应用程序对应的报错数据，判断所述报错数据是否超过所述目标预警阈值；

若所述报错数据超过所述目标预警阈值，则发送所述报错数据至用户设备，以进行预警。

4.如权利要求3所述的基于日志流的动态监控方法，其特征在于，所述若所述报错数据超过所述目标预警阈值，则发送所述报错数据至用户设备，以进行预警，包括：

若所述报错数据超过所述目标预警阈值，则通过预设预警模型评估所述报错数据的目标预警等级；

发送所述报错数据和所述目标预警等级至用户设备，以进行预警。

5.如权利要求4所述的基于日志流的动态监控方法，其特征在于，所述发送所述报错数据和所述目标预警等级至用户设备，以进行预警之后，所述基于日志流的动态监控方法还包括：

接收用户对所述报错数据和所述目标预警等级的反馈信息；

根据所述反馈信息调整所述目标预警阈值。

6.如权利要求5所述的基于日志流的动态监控方法，其特征在于，所述根据所述反馈信息调整所述目标预警阈值，包括：

从所述反馈信息中提取出反馈的目标事件级别，查找与所述目标事件级别对应的目标调整幅度；

根据所述目标调整幅度调整所述目标预警阈值。

7.如权利要求1-6中任一项所述的基于日志流的动态监控方法，其特征在于，所述获取系统中应用程序的第一服务重要级别，查找与所述第一服务重要级别对应的第一监控规则，根据所述第一监控规则监控对应的应用程序之前，所述基于日志流的动态监控方法还包括：

获取系统的应用程序日志，从所述应用程序日志中提取预设历史时段的历史请求数据；

根据所述历史请求数据设置系统中应用程序的第一服务重要级别。

8.一种基于日志流的动态监控设备，其特征在于，所述基于日志流的动态监控设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的基于日志流的动态监控程序，所述基于日志流的动态监控程序被所述处理器执行时实现如权利要求1至7中任一项所述的基于日志流的动态监控方法的步骤。

9.一种存储介质，其特征在于，所述存储介质上存储有基于日志流的动态监控程序，所述基于日志流的动态监控程序被处理器执行时实现如权利要求1至7中任一项所述的基于日志流的动态监控方法的步骤。

10.一种基于日志流的动态监控装置，其特征在于，所述基于日志流的动态监控装置包括：

监控模块，用于获取系统中应用程序的第一服务重要级别，查找与所述第一服务重要级别对应的第一监控规则，根据所述第一监控规则监控对应的应用程序；

提取模块，用于获取所述系统的应用程序日志，每隔预设间隔时间从所述应用程序日志中提取出当前请求数据；

判断模块，用于根据所述当前请求数据判断是否调整所述第一服务重要级别，获得判断结果；

调整模块，用于若所述判断结果为需要调整，则根据所述当前请求数据调整所述第一服务重要级别，获得应用程序的第二服务重要级别；

所述监控模块，还用于查找与所述第二服务重要级别对应的第二监控规则，根据所述第二监控规则监控对应的应用程序。