CN112433919B

CN112433919B - 一种信息告警方法、设备及存储介质

Info

Publication number: CN112433919B
Application number: CN202011340177.8A
Authority: CN
Inventors: 李云龙; 胡盼盼; 卢道和
Original assignee: WeBank Co Ltd
Current assignee: WeBank Co Ltd
Priority date: 2020-11-25
Filing date: 2020-11-25
Publication date: 2023-01-24
Anticipated expiration: 2040-11-25
Also published as: WO2022111265A1; CN112433919A

Abstract

本申请实施例公开了一种信息告警方法，该方法包括：按照第一采样间隔采集目标监控对象的目标监控指标，得到当前时刻的第一监控值；获取历史时刻采集所述目标监控指标得到的第一历史监控值；基于所述第一监控值和所述第一历史监控值，确定目标阈值；其中，所述目标阈值包括至少一个不同的阈值；基于所述第一监控值和所述目标阈值，确定告警提示信息；其中，所述告警提示信息用于针对所述目标监控对象的目标监控指标进行告警提示；显示所述告警提示信息。本申请实施例还公开了一种信息告警设备和存储介质。

Description

一种信息告警方法、设备及存储介质

技术领域

本申请涉及计算机应用技术领域，尤其涉及一种信息告警方法、设备及存储介质。

背景技术

随着计算机技术的飞速发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技(Fintech)转变，但由于金融行业的安全性和实时性要求，也对技术提出了更高的要求。随着互联网技术的飞速发展，数据库的应用越来越不可或缺，这样，对数据库的监控变得越来越重要。目前，监控数据库是否出现异常的过程主要是通过判断数据库指标值是否超过对应的固定阈值，或者同比环比增长比例是否超过对应的固定阈值来实现。

但是目前数据库使用过程中，由于不同时间段，数据库的请求量变化较大，不同的时间段的请求过程可以呈现出一定的周期性。比如凌晨属于业务低峰期，白天属于业务高峰期，再比如银行夜间的批量任务又会导致请求量很大，这样，导致对数据库进行异常监控时，采用数据库指标值与对应的固定阈值进行比较，导致不能准确实现数据库在各个时间段的告警需求，造成告警失误率较高。

申请内容

为解决上述技术问题，本申请实施例期望提供一种信息告警方法、设备及存储介质，解决了目前的采用固定阈值来实现数据库监控导致不能准确实现数据库在各个时间段的告警需求的问题，实现了根据实际情况自适应调整阈值来实现数据库监控的方案，有效提高了针对数据库告警的准确率。

本申请的技术方案是这样实现的：

第一方面，一种信息告警方法，所述方法包括：

按照第一采样间隔采集目标监控对象的目标监控指标，得到当前时刻的第一监控值；

获取历史时刻采集所述目标监控指标得到的第一历史监控值；

基于所述第一监控值和所述第一历史监控值，确定目标阈值；其中，所述目标阈值包括至少一个不同的阈值；

基于所述第一监控值和所述目标阈值，确定告警提示信息；其中，所述告警提示信息用于针对所述目标监控对象的目标监控指标进行告警提示；

显示所述告警提示信息。

第二方面，一种信息告警设备，所述设备包括存储器、处理器和通信总线；其中：

所述存储器，用于存储可执行指令；

所述通信总线，用于实现所述处理器和所述存储器之间的通信连接；

所述处理器，用于执行所述存储器中存储的信息告警程序，实现如上述任一项所述的信息告警方法的步骤。

第三方面，一种存储介质，所述存储介质上存储有信息告警程序，所述信息告警程序被处理器执行时实现如上述任一项所述的信息告警方法的步骤。

本申请实施例中，信息告警设备按照第一采样间隔采集目标监控对象的目标监控指标，得到当前时刻的第一监控值后，获取历史时刻采集所述目标监控指标得到的第一历史监控值，并基于所述第一监控值和所述第一历史监控值，确定目标阈值，然后基于所述第一监控值和所述目标阈值，确定告警提示信息，最后显示所述告警提示信息。这样，信息告警设备根据实时根据当前时刻的第一监控值和历史时刻的第一历史监控值动态确定目标阈值，来根据目标阈值和第一监控值之间的关系，生成告警提示信息，解决了目前的采用固定阈值来实现数据库监控导致不能准确实现数据库在各个时间段的告警需求的问题，实现了根据实际情况自适应调整阈值来实现数据库监控的方案，有效提高了针对数据库告警的准确率。

附图说明

图1为本申请实施例提供的一种信息告警方法的流程示意图；

图2为本申请实施例提供的另一种信息告警方法的流程示意图；

图3为本申请实施例提供的又一种信息告警方法的流程示意图；

图4为本申请另一实施例提供的一种信息告警方法的流程示意图；

图5为本申请另一实施例提供的另一种信息告警方法的流程示意图；

图6为本申请另一实施例提供的又一种信息告警方法的流程示意图；

图7为本申请实施例提供的一种信息告警设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

本申请的实施例提供一种信息告警方法，参照图1所示，方法应用于信息告警设备，该方法包括以下步骤：

步骤101、按照第一采样间隔采集目标监控对象的目标监控指标，得到当前时刻的第一监控值。

在本申请实施例中，信息告警设备可以是运行目标监控对象的设备，例如可以是服务器，也可是计算机设备等具备运行能力的设备。目标监控对象可以是应用程序，可运行于信息告警设备上。目标监控指标可以是信息告警设备运行目标监控对象时所消耗的资源，例如需占用的中央处理器(central processing unit，CPU)资源，包括CPU数量即内核数量和/或CPU运行时长等，还可以是输入输出(Input Output)资源等，目标监控指标具体可以是预先默认设置的，也可以是用户根据实际监控需求进行设置的。第一采样间隔即用于采集目标监控对象的目标监控指标的采样频率，可以是用户进行设置的，也可以是根据大量实验或者实际经验得到的经验值，通常第一采样间隔不能太小即采样频率不能太高，以防增加信息告警设备对目标监控对象进行监控时造成的监控压力。在实际应用过程中，第一采样间隔可以进行不断的校正或者用户根据实际监控需求进行不断的修改。

步骤102、获取历史时刻采集目标监控指标得到的第一历史监控值。

在本申请实施例中，信息告警设备在对目标监控指标进行采集时，会将采集到的监控值进行存储，这样，可以得到历史时刻采集的第一历史监控值。第一历史监控值可以是当前时刻之前一段时间内的监控值。

步骤103、基于第一监控值和第一历史监控值，确定目标阈值。

其中，目标阈值包括至少一个不同的阈值。

在本申请实施例中，信息告警设备对当前时刻的第一监控值和历史时刻的第一历史监控值进行分析处理，得到目标阈值。这样，根据当前时刻采集到的监控值和历史时刻的历史监控值，实现动态确定目标阈值。

步骤104、基于第一监控值和目标阈值，确定告警提示信息。

其中，告警提示信息用于针对目标监控对象的目标监控指标进行告警提示。

在本申请实施例中，确定目标阈值后，确定第一监控值所在目标阈值的范围，从而确定对应的告警等级，生成对应的告警提示信息，以通过告警提示信息对用户进行提示目标监控对象是否存在风险，是否需要及时对目标监控对象进行风险排除处理。

步骤105、显示告警提示信息。

在本申请实施例中，信息告警设备生成告警提示信息后，可以将告警提示信息显示在信息告警设备对应的显示区域。信息告警设备对应的显示区域可以是信息告警设备的显示屏幕，也可以是与信息告警设备具有通信连接的其他具有显示功能的设备，例如可以是与信息告警设备具有通信连接的移动通信设备，即信息告警设备生成告警提示信息后，将告警提示信息发送至与信息告警设备具有通信连接的移动通信设备，以通过移动通信设备显示告警提示信息。

本申请实施例中，信息告警设备按照第一采样间隔采集目标监控对象，得到目标监控指标的当前时刻的第一监控值后，获取历史时刻采集目标监控指标得到的第一历史监控值，并基于第一监控值和第一历史监控值，确定目标阈值，然后基于第一监控值和目标阈值，确定告警提示信息，最后显示告警提示信息。这样，信息告警设备根据实时根据当前时刻的第一监控值和历史时刻的第一历史监控值动态确定目标阈值，来根据目标阈值和第一监控值之间的关系，生成告警提示信息，解决了目前的采用固定阈值来实现数据库监控导致不能准确实现数据库在各个时间段的告警需求的问题，实现了根据实际情况自适应调整阈值来实现数据库监控的方案，有效提高了针对数据库告警的准确率。

基于前述实施例，本申请的实施例提供一种信息告警方法，参照图2所示，方法应用于信息告警设备，该方法包括以下步骤：

步骤201、按照第一采样间隔采集目标监控对象的目标监控指标，得到当前时刻的第一监控值。

在本申请实施例中，以信息告警设备是服务器，目标监控对象是数据库为例进行说明，服务器在运行数据库时，设置服务器以第一采样间隔采集数据库的目标监控指标，这样，即可得到当前时刻的第一监控值。目标监控指标至少可以包括以下之一：服务器的CPU使用率和/或IO使用率。需说明的是，信息告警设备采集得到当前时刻的第一监控值后，将第一监控值进行存储，以便后续进行分析使用。

步骤202、获取历史时刻采集目标监控指标得到的第一历史监控值。

在本申请实施例中，服务器从存储区域中获取在历史时刻采集存储的目标监控的监控值，得到第一历史监控值。存储区域可以是服务器本地存储区域，也可以是服务器可以访问的云端存储区域。

步骤203、获取目标监控对象的参考监控指标的当前时刻的第二监控值和参考监控指标的历史时刻采集到的第二历史监控值。

其中，参考监控指标与目标监控指标具有关联关系。

在本申请实施例中，目标监控对象的参考监控指标可以是目标监控对象的除目标监控指标外的其他指标，参考监控指标对目标监控指标具有一定的影响。信息告警设备也以第一采样间隔采集目标监控对象的参考监控指标，从而可以得到参考监控指标当前时刻的第二监控值和历史时刻的第二历史监控值。需说明的是，获取参考监控指标历史时刻的第二历史监控值时，第二历史监控值的历史时刻与目标监控时刻的第一历史监控值的历史时刻一一对应。参考监控指标可以是数据库中的总请求量指标。示例性的，获取当前时刻之前一段时间内例如一个月内针对目标监控指标采集得到的第一历史监控值和针对参考监控指标采集得到的第二历史监控值。参考监控指标与目标监控指标具有关联关系指的是参考监控指标的改变会影响目标监控指标的改变。例如，在数据库运行正常的情况下，服务器的CPU使用率和IO使用率，会与数据库的总请求量保持一定的正相关性，在数据库运行异常的情况下，出现数据库的总请求量下降，CPU使用率和IO使用率反而升高的情况。

步骤204、基于第一监控值、第一历史监控值、第二监控值和第二历史监控值，确定目标权重系数。

在本申请实施例中，服务器对第一监控值、第一历史监控值、第二监控值和第二历史监控值进行分析，得到目标权重系数。

步骤205、基于第一历史监控值，确定第一参考值。

在本申请实施例中，信息告警设备对第一历史监控值进行分析，得到第一参考值。

步骤206、从第一历史监控值中，获取与当前时刻相邻的前一时刻的第一历史子监控值。

在本申请实施例中，以第一采样间隔为1分钟为例进行说明，从第一历史监控值中，获取当前时刻11月11日14:00相邻的前一时刻11月11日13:59的第一历史子监控值。

步骤207、确定第一监控值与第一历史子监控值的差值，得到第二参考值。

在本申请实施例中，通过公式“第二参考值＝第一监控值-第一历史子监控值”计算得到第二参考值。

步骤208、基于目标权重系数、第二参考值、第一监控值、至少一个预设权重系数和第一参考值，得到目标阈值。

其中，目标阈值包括至少一个不同的阈值。

在本申请实施例中，对目标权重系数、第二参考值、第一监控值、至少一个预设权重系数和第一参考值进行分析计算，得到包括至少一个不同阈值的目标阈值，目标阈值包括的阈值的数量与至少一个预设权重系数的数量相同。假设至少一个预设权重系数包括两个不同的预设权重系数，为预设权重系数1和预设权重系数2时，这样，根据预设权重系数1、目标权重系数、第二参考值、第一监控值和第一参考值，可以确定一个目标阈值中的一个阈值，根据预设权重系数2、目标权重系数、第二参考值、第一监控值和第一参考值，可以确定一个目标阈值中的另一个阈值。

步骤209、基于第一监控值和目标阈值，确定告警提示信息。

步骤210、显示告警提示信息。

在本申请实施例中，在确定目标监控指标对应的目标阈值时，除了分析目标监控指标对应当前时刻的第一监控值和对应的第一历史监控值外，还考虑了与目标监控指标具有关联关系的参考监控指标的当前时刻的第二监控值和对应的第二历史监控值，这样能够得到更加符合实际应用情况的目标阈值，有效提高了目标阈值的可靠性，并提高了针对数据库进行自动告警的准确性。

基于前述实施例，在本申请其他实施例中，步骤204可以由步骤a11～a14来实现：

步骤a11、通过确定第二时刻的监控值与第一时刻的监控值的差值的方式对第一监控值和第一历史监控值进行处理，得到目标监控指标不同时刻的第二差值。

其中，第一时刻与第二时刻是两个相邻时刻，第一时刻距离当前时刻比第二时刻距离当前时刻远。

在本申请实施例中，针对第一监控值和第一历史监控值中任意两个相邻时刻的监控值，采用后一时刻的监控值即第二时刻的监控值减去前一时刻的监控值即后一时刻的监控值的计算方式，确定得到不同时刻的第二差值。

步骤a12、通过确定第二时刻的监控值与第一时刻的监控值的差值的方式对第二监控值和第二历史监控值进行处理，得到参考监控指标不同时刻的第三差值。

在本申请实施例中，针对第二监控值和第二历史监控值中任意两个相邻时刻的监控值，采用后一时刻的监控值即第二时刻的监控值减去前一时刻的监控值即第一时刻的监控值的计算方式，确定得到不同时刻的第三差值。

步骤a13、确定同一时刻的第三差值与第二差值比值，得到参考比值。

在本申请实施例中，由于同一时刻的参考监控指标与目标监控指标之间才有相互制约、相互影响的作用，因此，对得到的同一时刻的第三差值和第二差值进行比值计算，得到参考比值。

步骤a14、基于参考比值，确定目标权重系数。

基于前述实施例，在本申请其他实施例中，步骤a14可以由步骤a141～a142来实现：

步骤a141、从参考比值中获取比值大于零，且距离当前时刻最近的第二预设数量个目标比值。

在本申请实施例中，第二预设数量可以是大量实验或实际应用场景得到的一个经验值，也可以是用户根据实际需求进行设定的。参考比值大于零，能够表明目标监控对象运行于正常工作状态。在相邻时刻，目标监控对象的运行状态一般不会突然出现较大的问题，因此，可以获取正常工作状态下，与当前时刻距离更近的第二预设数量个比值，得到第二预设数量个目标比值。

步骤a142、基于第二预设数量个目标比值，得到目标权重系数。

在本申请实施例中，采用预设的处理方法对第二预设数量个目标比值进行处理，得到一个值，并将该值作为目标权重系数。预设的处理方法例如可以是求和后计算平均值，或者加权求和后计算平均值，或者求标准差等数学统计归纳方法。

在本申请其他实施例中，步骤a142可以由以下步骤来实现：确定第二预设数量个目标比值的平均值，得到目标权重系数。

在本申请实施例中，计算第二预设数量个目标比值的累加值，然后计算第二预设数量个目标比值的累加值与第二预设数量的比值，得到对应的平均值，并将该平均值作为目标权重系数。

在本申请实施例中，对同一时刻的目标监控指标值对应的第三差值和参考监控指标值对应的第二差值进行分析，来确定得到目标权重系数，由于对数据库的操作具有一定的规律性，保证了目标权重系数的有效性，更加符合实际使用需求。

基于前述实施例，在本申请其他实施例中，步骤205可以由步骤b11～b12来实现：

步骤b11、从第一历史监控值中，获取当前时刻之前的第一预设数量个时间周期内，与当前时刻相同时刻的第一预设数量个第二历史子监控值。

在本申请实施例中，第一预设数量为根据大量实验得到的一个经验值，或者是用户根据实际需求进行设定的一个数值。以时间周期为天，第一预设数量为7为例进行说明，从第一历史监控值中，获取当前时刻之前的7天内，与当前时刻相同时刻的7个监控值，作为7个第二历史子监控值。示例性的，当前时刻为11月11日14：00，获取11月11日14:00前7天14:00时刻的监控值，得到11月4日14:00、11月5日14:00、11月6日14:00、11月7日14:00、11月8日14:00、11月9日14:00、11月10日14:00这些时刻的监控值，作为7个第二历史子监控值。

步骤b12、确定第一预设数量个第二历史子监控值的标准差，得到第一参考值。

在本申请实施例中，采用标准差计算公式对第一预设数量个第二历史子监控值进行计算，得到第一预设数量个第二历史子监控值的标准差，并将第一预设数量个第二历史子监控值的标准差作为第一参考值。

在本申请实施例中，通过距离当前时刻最近的一段时间内的历史监控值进行分析，由于数据库在一段时间内的性能基本保持一定，有效降低了计算分析过程中的计算资源消耗，同时也能保证监控效果。

基于前述实施例，在本申请其他实施例中，步骤208可以由步骤c11～c13来实现：

步骤c11、确定目标权重系数与第二参考值的第一乘积。

步骤c12、确定至少一个预设权重系数与第一参考值的乘积，得到至少一个第二乘积。

步骤c13、确定第一乘积、至少一个第二乘积中每一第二乘积和第一监控值的累加值，得到目标阈值。

在本申请实施例中，计算最近一段时间周同一个时刻的第一预设数量个值的标准差，用标准差的值来调整阈值，因为观测到的指标不可能完全符合模型预期，通过添加标准差来允许一定的容差，这样可以更符合检测的实际需要。

在本申请实施例中，通过设置得到多个不同的阈值，提高了针对各种应用情况的普适性，进而能够实现不同的告警，有效提高了用户的使用体验效果。

基于前述实施例，在本申请其他实施例中，步骤209可以由步骤209a～209f来实现：

步骤209a、获取目标监控指标的目标上限值。

在本申请实施例中，目标上限值是预先设定的一个上限值，即针对目标监控指标时，允许目标监控指标对应的最大值。

其中，信息告警设备执行步骤209a之后，可以选择执行步骤209b～209c，或者步骤209d，或者步骤209e，或者步骤209f。

步骤209b、若第一监控值小于目标上限值，且第一监控值大于或等于第一阈值，按照第二采样间隔连续采集目标监控指标的第三预设数量个第三监控值。

其中，第二采样间隔小于第一采样间隔，目标阈值包括第一阈值。

在本申请实施例中，第一阈值为目标阈值包括的至少一个阈值中的最小阈值。第三预设数量为根据大量实验得到的经验值或为用户设定值，通常第三预设数量小于第一预设数量。以第二采样间隔为3秒、第三预设数量为2为例进行说明，在第一监控值小于目标上限值，且第一监控值大于或等于第一阈值时，针对每隔3秒连续采集2次目标监控指标，得到2个第三监控值。

步骤209c、若第三预设数量个第三监控值均小于目标上限值，且至少一个第三监控值大于或等于第二阈值，生成第一告警信息。

其中，目标阈值包括第二阈值，第二阈值大于第一阈值，第一告警信息用于实现针对目标监控对象的重大告警。

在本申请实施例中，以有3个第三监控值为例进行说明，至少一个第三监控值大于或等于第二阈值的情况包括：3个第三监控值中的任意一个监控值大于或等于第二阈值、3个第三监控值中的任意两个监控值大于或等于第二阈值和3个第三监控值均大于或等于第二阈值。

步骤209d、若第一监控值大于或等于目标上限值，生成第二告警信息。

其中，第二告警信息用于实现针对目标监控对象的严重告警。

步骤209e、若第三预设数量个第三监控值中的至少一个第三监控值大于或等于目标上限值，生成第二告警信息。

步骤209f、若第三预设数量个第三监控值均小于第二阈值，生成第三告警信息。

其中，第三告警信息用于实现针对目标监控对象的次要告警。

在本申请其他实施例中，若第一监控值小于第一阈值，确定目标监控对象正常运行，无需进行任何告警。

在本申请实施例中，实现了不同等级的告警，有效提高了用户的使用体验效果。

基于前述实施例，本申请实施例提供一种信息告警方法，参照图3所示，包括以下步骤：

步骤31、采集数据库的目标监控指标的监测值。

其中，针对数据库的监控指标进行分类，可以参照表1所示。表1中列举了指标类型，指标名称以及对应的指标属性。表中所列举的资源型指标，每个实例因为承载不同的业务，不同的请求量，会有不同的阈值标准，且该类指标属于重点监控对象，故使用自适应阈值来监控该类资源型指标中的CPU使用率和IO使用率，即目标监控指标为CPU使用率和/或IO使用率。信息告警设备运行的监控系统按某一采样频率循环采集目标监控指标的监控数据，其中，采样频率为采样的时间间隔，可以按需调整，默认1分钟采集1次，采样太频繁会导致监控库压力太大。

表1

步骤32、生成自适应阈值。

其中，以目标监控指标为IO使用率为例进行说明，自适应阈值U(t)＝p(t)+β·δ。其中：

p(t)可以通过公式p(t)＝α(I_t-I_t-1)+I_t-1计算得到，I_t表示当前时刻t时刻的IO使用率的监测值；I_t-1是IO使用率的监测值。

α是加权比例，用于控制当前时刻的目标监控指标的监测值在公式中所占的比重，p(t)公式能够用于适应局部行为的快慢程度，如果将α设置成一个固定常数往往没有很好的适用性。因此，α随着监控指标随着运行时间的改变，α也会发生改变。在数据库非异常情况下，数据库的监控指标IO使用率和CPU使用率的监测值，会与数据库的总请求量保持一定的正相关性，在数据库异常情况下，往往出现总请求量下降，监控指标IO使用率和CPU使用率的监测值反而升高的情况。因此，只需考虑正常情况下IO使用率和CPU使用率分别与总请求量的相关性，Q_t表示当前时刻t时刻的总请求量值，则t时刻IO使用率与总请求量的两指标相关系数q可以记为q＝(Q_t-Q_t-1)/(I_t-I_t-1)，这样，可以取举例当前时刻t时刻最近的7次q为正系数(正常情况下该系数为正)的值后取其平均值，得到当前时刻t时刻的α值。

δ是标准差。其中，得到δ的过程为：由于监控系统是一直对数据库进行检测的，因此，每天的同一时刻，对目标监控指标均会有一个观测值，这样，在目标监控指标为IO使用率时，可以获取在过去的一段时间例如一周就有7个同一时刻的IO使用率的历史检测值。对这7个同一时刻的IO使用率的历史检测值进行标准差计算，即可得到标准差δ。

β的取值决定了不同的容差度，如果设置成一个固定的值，也可能有普适性问题。因此，此处针对目标监控指标进行告警，可以设置不同的β值。设置的β值通常为经验值。这样，在β值不同时，例如设置2个β值分别为β1、β2(β1<β2，均为正整数)时，分别对应的自适应阈值U(t)标记为U1、U2，且U1<U2。

步骤33、匹配对应告警级别。

其中，在资源型指标的监控过程中，通常会考虑资源上限，上限记为L(L为固定常数)。超过上限L时需以高级别的告警输出。这样，针对当前时刻采集到的IO使用率的监控值，与上限L、自适应阈值U1和U2进行对应告警级别监控的流程可以参照图4所示，其中，U1<U2。如图4所示，包括以下步骤：

步骤41、获取当前时刻的IO使用率的监控值。

步骤42、判断IO使用率的监控值是否大于上限L，若IO使用率的监控值大于或等于上限L，执行步骤43，若IO使用率的监控值小于上限L，执行步骤44。

步骤43、生成CRITICAL告警。

其中，CRITICAL告警对应前述的第一告警信息，CRITICAL级别告警，表明数据库已经出现异常，需要马上处理。

步骤44、判断IO使用率的监控值是否大于自适应阈值U1，若IO使用率的监控值小于自适应阈值U1，执行步骤45，若IO使用率的监控值大于或等于自适应阈值U1，执行步骤46。

步骤45、确定数据库正常。

步骤46、按照3秒的采集间隔连续采集2次IO使用率的监控值，得到2个监控值。

步骤47、判断2个监控值是否大于上限L，若2个监控值中的至少一个监控值大于或等于上限L，执行步骤43，若2个监控值均小于上限L，执行步骤48。

步骤48、判断2个监控值是否大于自适应阈值U2，若2个监控值中的至少一个监控值大于或等于自适应阈值U2，执行步骤49，若2个监控值均小于自适应阈值U2，执行步骤410。

步骤49、生成MAJOR告警。

其中，MAJOR告警对应前述第二告警信息，MAJOR级别告警,需要重点关注，可能会产生一定的影响。

步骤410、生成MINOR告警。

其中，MINOR告警对应前述第三告警信息，MINOR级别的告警，无需马上处理，可事后采集数据进行潜在风险分析。

基于前述实施例，在本申请其他实施例中，提供的是在告警提示信息为第一告警信息或第二告警信息时，进行根因推荐的一种实现方法，参照图5所示，信息告警设备执行步骤201～208和步骤209a～209c，或步骤201～208、步骤209a和步骤209d，或步骤201～208、步骤209a和步骤209e之后，还用于执行步骤211～215：

步骤211、若告警提示信息是第一告警信息或第二告警信息，获取目标监控对象在当前时刻执行的至少一条结构化查询语言SQL语句。

步骤212、获取至少一条SQL语句对应的执行计划。

在本申请实施例中共，执行计划(Execution Plan，也叫查询计划或者解释计划)是数据库执行SQL语句的具体步骤，例如通过索引还是全表扫描访问表中的数据，连接查询的实现方式和连接的顺序等。

步骤213、基于至少一条SQL语句对应的执行计划，确定每一SQL语句对应目标监控指标的消耗成本，得到至少一条SQL语句对应的消耗成本。

在本申请实施例中，对至少一条SQL语句对应的执行计划中的每一SQL语句对应的执行计划进行分析，确定每一SQL语句对应目标监控指标的消耗成本，从而得到至少一条SQL语句对应的消耗成本。例如，信息告警设备确定数据库当前执行的SQL语句有3条，分别获取这3条SQL语句对应的执行计划，并根据这3条SQL语句对应的执行计划中的每一条SQL语句对应的执行计划，确定每一条SQL语句对应的目标监控指标的消耗成本，从而得到3条SQL语句各自对应的消耗成本。

步骤214、基于至少一条SQL语句对应的消耗成本，按照消耗成本从高到低的排序顺序对至少一条SQL语句进行排序，得到SQL语句排序结果。

在本申请实施例中，假设3条SQL语句包括SQL语句1、SQL语句2和SQL语句3，对应的IO消耗成本依次为IO_cost1、IO_cost2、IO_cost3，对这3条SQL语句的消耗成本进行从高到低的排序顺序例如为IO_cost3>IO_cost1>IO_cost12，这样，对应的3条SQL语句的排序顺序即SQL语句排序结果为：IO_cost3、IO_cost1、IO_cost2。

步骤215、显示SQL语句排序结果。

需说明的是，步骤211～215可以在步骤210之前执行，其中，步骤215与步骤210可以同时执行，步骤215也可以在步骤210之后执行。

基于前述实施例，在本申请其他实施例中，步骤213可以由步骤d11～d19和/或步骤e11～e16来实现，其中，步骤d11～d19对应的实施例提供的是确定目标监控对象的消耗成本为IO消耗成本时的方案实现过程，步骤e11～e16对应的实施例提供的是确定目标监控对象的消耗成本为CPU消耗成本时的方案实现过程。需说明的是，在目标监控对象的目标监控指标为IO指标时，在确定消耗成本时，可以只需确定IO消耗成本，也可以在确定IO消耗成本的同时，还确定CPU消耗成本；同理，在目标监控对象的目标监控指标为CPU指标时，在确定消耗成本时，可以只需确定CPU消耗成本，也可以在确CPU消耗成本的同时，还确定CPU消耗成本，具体实际执行过程可以参照实际应用要求来确定。

步骤d11、基于至少一条SQL语句对应的执行计划，确定每一SQL语句对应的执行计划中包括的每一身份标识ID的行数。

在本申请实施例中，每一SQL语句对应的执行计划中包括id列，id列用于指示对应的SQL语句中的选择(SELECT)的序号，即对应的ID。其中，ID值大的先执行，ID值相同的从上往下执行。如果id值为Null，表示利用其他id值的行结果进行union操作，需根据table列的值<union m,n>的值判断放在哪一步，放在min(m,n)(取m和n中较小的值)后一步执行。

其中，信息告警设备执行步骤d11后，可以选择执行步骤d12～d13，或者步骤d14～d18。在每一ID的行数为1时，选择执行步骤d12～d13；在每一ID的行数大于1时，选择执行步骤d14～d18。

步骤d12、确定每一SQL语句对应的行数为1的ID为第一ID，获取第一ID对应的第一行数和平均长度。

其中，第一行数记录于每一SQL语句对应的执行计划中。

在本申请实施例中，第一行数记录于每一SQL语句对应的执行计划中的rows列中，第一行数可以用rows来表示。每一SQL语句对应的第一ID的平均长度AVG_ROW_LENGTH，可以从文件名为information_schema.tables的文件中获取得到。

步骤d13、对第一行数与平均长度的乘积与预设InnoDB数据页大小进行向上取整处理，得到第一ID的IO消耗成本。

在本申请实施例中，InnoDB数据页在MySQL默认的非压缩数据页为16KB，数据页包括七个部分，数据页文件管理头信息，数据页面头信息，最大最小记录，用户记录，空闲空间，数据目录(槽)，数据页尾部。预设InnoDB数据页大小可以记为innodb_page_size，对应的，行数为1的SQL语句的IO消耗成本

其中，符号

用于表示向上取整。InnoDB数据页用户可以进行设置。

步骤d14、确定每一SQL语句对应的行数大于1的ID为第二ID，确定第二ID的每一行的返回行数和扫描行数。

在本申请实例中，假设SQL语句1中的某一个ID例如为ID1具有多行例如为k行时，统计ID1的每一行的返回行数和扫描行数。其中，一种确定每一SQL语句的每一ID的每一行的返回行数和扫描行数的方式可以如下所示：从SQL语句1对应的执行计划中，确定ID1对应的k行，并根据ID1对应的k行的行从上往下的顺序，依次确定每一行的返回行数。在确定每一SQL语句的每一ID的每一行的扫描行数时，需根据Join方式来确定，即需统计join比较次数。其中，join比较次数可以通过表2来确定，在表2中，RN表示外表记录数，SN表示内表记录数。

表2

在表2的Join方式中，SNLJ指的是简单嵌套循环联接，对应的英文全拼为SimpleNested-Loops Join的Join方式，INLJ指的是基于索引的嵌套循环联接，对应的英文全拼为Index Nested-Loops Join，BN L指的是基于块的嵌套循环联接，对应的英文全拼为BlockNested-Loops Join，CHJ指的是经典哈希连接，对应的英文全拼为Classic Hash Join。

其中，ID1对应的K行中的第1行的返回行数记为return_rows_1＝rows_1*filtered_1；其中，rows_1可以从SQL语句1对应的执行计划中的ID1对应的第1行的rows列中获取，filtered_1可以从SQL语句1对应的执行计划ID1对应的第1行的filtered列中获取。除第1行外，其他行的返回行数均与各自行对应的join方式有关，join方式记录于SQL语句1对应的执行计划中。

示例性的，确定SQL语句1对应的执行计划中的ID1对应的第2行的返回行数时，在第2行的join方式为inner join时，第2行的返回行数return_rows_2＝return_rows_1*(rows_2*filtered_n2)，在第2行的join方式为leftjoin时，第2行的返回行数return_rows_2＝return_rows_1,在第2行的join方式为right join时，第2行的返回行数return_rows_2＝table_rows_2；…；确定SQL语句1对应的执行计划中的ID1对应的第k行的返回行数，在第k行的join方式为inner join时，return_rows_k＝return_rows_(k-1)*(rows_k*filtered_k)，在第k行的join方式为left join时，return_rows_k＝return_rows_(k-1)，在第k行的join方式为right join时，return_rows_k＝table_rows_k。其中，以nk为例，则return_rows_(k-1)即第k-1行返回的行数，为执行顺序外表行数，table_rows_k为内表行数。

假设SQL语句1使用的Join方式为INLJ时，对应的SQL语句1中的ID1对应的第k行的扫描行数记为examine_rows_k＝return_rows_(k-1)*(1+table_rows_k/index_cdl)，其中，index_cdl表示索引区分度。如果需要回表即key的值不是PRIMARY，extra中不包含using index,且有using where时，SQL语句1中的ID1对应的第k行的扫描行数记为examine_rows_k＝return_rows_(k-1)*(1+table_rows_k/index_cdl)*2。

SQL语句1中的ID1对应的第k行的Join的比较次数可以记为join_compare_k＝table_rows_k*index_height，其中，index_height用于表示索引高度。需说明的是，索引区分度index_cdl和索引高度index_height可以从SQL语句1中的ID1对应的mysql.innodb_index_stat表中获取得到。

步骤d15、获取对应的第二ID对应的平均长度。

在本申请实施例中，第二ID对应的平均长度AVG_ROW_LENGTH，可以从每一SQL语句对应的information_schema.tables中获取得到。

步骤d16、确定第二ID的每一行的扫描行数与对应的相邻的前一行的返回行数的差值，得到第一差值。

在本申请实施例中，计算得到第一差值的公式可以记为：第一差值＝examine_rows_k–return_rows_(k-1)。

步骤d17、确定第一差值与平均长度乘积与预设InnoDB数据页大小进行向上取整处理，得到第二ID的每一行对应的IO消耗子成本。

在本申请实施例中，SQL语句1中的ID1对应的第k行的IO消耗子成本可以记为

其中，i＝1,2,……,k，innodb_page_size用于表示预设InnoDB数据页大小，符号

用于表示向上取整。。

步骤d18、确定第二ID的每一行对应的IO消耗子成本的累加值，得到第二ID的IO消耗成本。

在本申请实施例中，SQL语句1的第二ID的IO消耗成本

符号∑表示累加。

步骤d19、确定每一SQL语句对应的执行计划中包括的每一ID的IO消耗成本的累加值，得到至少一条SQL语句对应的消耗成本。

其中，每一ID的IO消耗成本的累加值包括第一ID的IO消耗成本和/或第二ID的IO消耗成本。

在本申请实施例中，假设SQL语句1中包括5个ID，其中3个ID例如为ID1、ID2和ID3的行数为1行，其余2个ID例如ID4和ID5的行数包括至少2行，因此，可以通过步骤d12～d13分别确定得到ID1的IO消耗成本、ID2的IO的消耗成本和ID3的IO消耗成本，通过步骤d14～d17分别确定得到ID4的IO消耗成本和ID5的IO消耗成本，然后将ID1的IO消耗成本、ID2的IO的消耗成本、ID3的IO消耗成本、ID4的IO消耗成本和ID5的IO消耗成本进行累加，得到SQL语句1的消耗成本，同理，也可以得到至少一条SQL语句中的其他SQL语句的消耗成本。

示例性的，假设某一SQL语句包括的ID为1的计划表可以参照表3所示。针对表3中id为1的行从上往下依次进行计算，可以确定：第一行扫描行数examine_rows_1＝rows＝54952,第一行返回行数return_rows_1＝54952*100％＝54952；第二行扫描行数examine_rows_2＝tables_rows*(1+table_rows_2/index_cal)＝54952*(1+413141/137713)＝219808,第二行返回行数return_rows_2＝219808*100％＝219808；第三行扫描行数examine_rows_3＝219808*(1+1)＝439616，第三行返回行数return_rows_3＝219808*1*100％＝219808；第四行扫描行数examine_rows_4＝219808*(1+1)＝439616。

表3

计算某一SQL语句包括的ID为1的IO消耗成本为io_cost＝(439616-219808)*140/16000+(439616-219808)*350/16000+(219808–54952)*295/16000+(54592-0)*465/16000，约等于11300。

计算某一SQL语句包括的ID为1的CPU消耗成本为cpu_cost＝(54952+54952*log54952)+(54952*3)+(219808*4+219808*3)+(219808*4+219808*3)，约等于3500000。

这样，根据当前时刻的至少一条SQL语句的IO消耗成本和/或CPU消耗成本，对至少一条SQL语句中的SQL语句进行排序，以得到排序结果。进一步的，在一些实施例中，还可以结合SQL语句的执行条数，进行根因排序，其中，可以按照执行次数从高到低的方式对SQL语句进行排序，执行次数相同的SQL语句可以根据IO消耗成本或CPU消耗成本进行排序。

步骤e11、基于至少一条SQL语句对应的执行计划，确定每一SQL语句对应的执行计划中包括的每一身份标识ID的行数。

步骤e12、确定行数为1的ID为第一ID。

步骤e13、基于第一ID的执行计划，确定第一ID对应的CPU消耗成本。

步骤e14、确定行数大于1的ID为第二ID。

步骤e15、基于第二ID的每一行的执行计划，确定第二ID的每一行对应的CPU消耗成本。

在本申请实施例中，假设第二ID包括3行，根据第二ID的每一行的执行计划中包括的参数，确定第二ID的每一行对应的CPU消耗成本，得到第二ID的第一行对应的CPU消耗成本，第二行对应的CPU消耗成本，第三行对应的CPU消耗成本。

步骤e16、将第二ID的每一行对应的CPU消耗成本进行累加，得到第二ID对应的CPU消耗成本。

在本申请其他实施例中，将第二ID包括的3行中每一行对应的CPU消耗成本进行累加，即计算第二ID的第一行对应的CPU消耗成本、第二行对应的CPU消耗成本和第三行对应的CPU消耗成本的累加值，得到第二ID对应的CPU消耗成本。

基于前述实施例，在本申请其他实施例中，步骤e13可以由步骤e131～e135来实现：

步骤e131、基于第一ID的执行计划，确定第一ID对应的第一行数和返回行数。

步骤e132、从第一ID的执行计划中，获取第一ID对应的访问类型Type和额外字段信息Extra。

在本申请实施例中，以SQL语句1的ID为2的行数为1行为例进行说明，假设针对SQL语句1ID为2的行的执行计划可以参照表4所示。

表4

这样，可以从表4的Select_Type列中获取得到SQL语句1ID为2的行的访问类型Type，从表4的Extra列中获取得到SQL语句1ID为2的行的Extra。

步骤e133、基于第一ID对应的Type、Extra和第一行数，得到第一ID对应的第一CPU消耗子成本。

在本申请实施例中，根据预先设置的不同Type下，不同Extra时，第一行数与消耗子成本之间的关系，确定得到第一ID对应的Type、Extra和第一行数对应的第一ID对应的第一CPU消耗子成本。

示例性的，预先设置的不同Type下，不同Extra时，第一行数rows与消耗子成本之间的关系f_filter(rows)可以参照表5所示。其中，在表5中，primary_key_height标识组件索引高度，一般为3或4。

表5

步骤e134、确定返回行数的对数和返回行数的乘积，得到第一ID对应的第二CPU消耗子成本。

在本申请实施例中，第一ID对应的第二CPU消耗子成本可以记为f_sort(return_rows)＝return_rows*logreturn_rows,其中，log为对数函数。

步骤e135、确定第一ID对应的第一CPU消耗子成本和第二CPU消耗子成本的和值，得到第一ID对应的CPU消耗成本。

在本申请实施例中，第一ID对应的CPU消耗成本可以记为cpu_cost＝f_filter(rows)+f_sort(return_rows)。

对应的，步骤e15可以由步骤e151～e156来实现:

步骤e151、基于第二ID的每一行的执行计划，确定第二ID的每一行的第二行数和返回行数。

步骤e152、从第二ID的每一行对应的执行计划中，获取第二ID的每一行对应的访问类型Type和额外字段信息Extra，和第二ID的每一行对应的表行数。

步骤e153、基于第二ID的每一行对应的Type、Extra和第二行数，得到第二ID的每一行对应的第三CPU消耗子成本。

在本申请实施例中，步骤e153的具体实现过程可以参照步骤e133的具体实现过程，此处不再详细赘述。

步骤e154、确定第二ID的每一行的返回行数的对数与对应的返回行数的乘积，得到第二ID的每一行对应的第四CPU消耗子成本。

在本申请实施例中，步骤e154的具体实现过程可以参照步骤e134的具体实现过程，此处不再详细赘述。

步骤e155、确定第二ID的每一行对应的表行数和第二ID的每一行对应的索引高度的乘积，得到第二ID的每一行对应的第五CPU消耗子成本。

在本申请实施例中，第二ID的每一行对应的第五CPU消耗子成本可以记为join_compare＝table_rows*index_height，其中，index_height用于表示索引高度，table_rows表示第二ID的每一行对应的表行数。

步骤e156、确定第二ID的每一行对应的第三CPU消耗子成本、第四CPU消耗子成本和第五CPU消耗子成本的累加值，得到第二ID的每一行的CPU消耗成本。

在本申请实施例中，在不同的告警情况下，对CPU消耗成本和/或IO成本进行分析，并在告警时，输出分析结果，实现根因推荐，有效降低了分析人员的工作难度，提高了分析人员进行告警故障确定的效率，提高了分析人员的使用效率。

基于前述实施例，在本申请其他实施例中，提供的是在告警提示信息为第一告警信息或第二告警信息时，进行根因推荐的另一种实现方法，参照图6所示，信息告警设备执行步骤208和步骤209a～209c，或步骤201～208、步骤209a和步骤209d，或步骤201～208、步骤209a和步骤209e之后，还用于执行步骤216～223：

步骤216、若告警提示信息是第一告警信息或第二告警信息，获取目标监控对象在当前时刻执行的至少一条SQL语句。

在本申请实施例中，可以从当前高负载的数据库表例如表文件名为information_schema.processlist中获取当前时刻正在执行的sql语句。

步骤217、对至少一条SQL语句按照语句相同的方式进行分组，得到至少一组SQL语句。

在本申请实施例中，按照语句相同的方式进行分组时，具体可以是将句式一样，但参数值不一样的SQL语句归为一组SQL，在一些应用场景中，分组后还可以基于每一组SQL语句的特征，生成SQL指纹作为该组SQL语句的标记。

步骤218、基于至少一组SQL语句，统计每一组SQL语句包括的SQL语句数量。

在本申请实施例中，对至少一组SQL语句中的每一组SQL语句包括的SQL语句条数进行统计，得到每一组SQL语句包括的SQL语句数量。

步骤219、从至少一组SQL语句的每一组SQL语句中获取一条SQL语句，得到至少一条目标SQL语句。

在本申请实施例中，假设对至少一条SQL语句按照语句相同的方式进行分组，得到4组SQL语句，则从每一组SQL语句中随机抽取一条SQL语句，得到4条目标SQL语句。

步骤220、确定目标备用数据库，通过目标备用数据库分别运行每一目标SQL语句。

在本申请实施例中，目标备用数据库指的是负载较低的备用数据库。开启备用数据库profiling时，可以通过语句setprofiling＝1来实现。

步骤221、确定目标备用数据库运行每一目标SQL语句时消耗的资源消耗子成本，得到每一目标SQL语句的资源消耗子成本。

在本申请实施例中，在目标备用数据库运行每一目标SQL语句时，目标备用数据均会记录资源消耗情况，因此，可以对目标备用数据库运行每一目标SQL语句时记录的资源消耗情况来确定每一目标SQL语句的资源消耗子成本。

步骤222、确定每一目标SQL语句的资源消耗子成本与每一目标SQL语句所在组包括的SQL语句数量的乘积，得到每一组SQL语句的资源消耗成本。

步骤223、按照每一组SQL语句的资源消耗成本从大到小的排序顺序，对至少一组SQL语句进行排序，得到排序结果，并显示排序结果。

需说明的是，步骤216～223可以在步骤210之前执行，其中，步骤223与步骤210可以同时执行，步骤223也可以在步骤210之后执行。

基于前述实施例，在本申请其他实施例中，步骤221可以由步骤f11～f13来实现：

步骤f11、若目标备用数据库运行每一目标SQL语句的时长大于或等于预设时长，确定每一目标SQL语句的资源消耗子成本为第一数值。

在本申请实施例中，预设时长为一个经验值，通常是根据大量实验或实际经验得到的，在一些应用场景下，用户也可以自己自行进行设置。第一数值为一个经验值，通常用于表示最高资源消耗成本。

步骤f12、若目标备用数据库运行每一目标SQL语句的时长小于预设时长，获取目标备用数据库运行每一目标SQL语句时对应的资源消耗表。

在本申请实施例中，目标备用数据库运行每一目标SQL语句时对应的资源消耗表获取方式可以通过如下语句来实现：

Show profiles；//显示执行sql的编号Query_ID

show profile cpu,block io for query Query_ID；//显示编号Query_ID的资源消耗表

这样，通过上述语句得到每一目标SQL语句的资源消耗表示例性的可以如表6所示。在表6中，status表示状态，Duration表示状态持续时间，单位通常为秒，CPU_user表示用户态所消耗的CPU资源，CPU_system表示核心态所消耗的CPU资源，Block_ops_in表示输入块操作的数量，Block_ops_out表示输出块操作的数量。

表6

步骤f13、从每一目标SQL语句对应的资源消耗表中获取第一消耗资源和第二消耗资源，确定第一消耗资源和第二消耗资源的和值，得到每一目标SQL语句对应的资源消耗子成本。

其中，第一消耗资源为用户态所消耗的CPU资源，第二消耗资源为核心态所消耗的CPU资源，和/或第一消耗资源为输入块操作的数量，第二消耗资源为输出块操作的数量。

在本申请实施例中，示例性的，在有4条目标SQL语句时，可以得到4张分别与每一条目标SQL语句对应的如表6所示的资源消耗表。在目标监控指标为CPU时，针对每一目标SQL语句，对如表6所示的资源消耗表中的表示用户态所消耗的CPU资源CPU_user列内容，和表示核心态所消耗的CPU资源CPU_system列内容进行累加，得到每一目标SQL语句对应的CPU资源消耗子成本。

在目标监控指标为IO时，针对每一目标SQL语句，对如表6所示的资源消耗表中的表示输入块操作的数量的Block_ops_in列内容，和表示输出块操作的数量的Block_ops_out列内容进行累加，得到每一目标SQL语句对应的IO资源消耗子成本。

需说明的是，在一些应用场景中，针对目标监控指标为CPU时，除了计算每一目标SQL语句对应的CPU资源消耗子成本，还可以计算每一目标SQL语句对应的IO资源消耗子成本。同理，在针对目标监控指标为IO时，除了计算每一目标SQL语句对应的IO资源消耗子成本，还可以计算每一目标SQL语句对应的CPU资源消耗子成本。

需要说明的是，本实施例中与其它实施例中相同步骤和相同内容的说明，可以参照其它实施例中的描述，此处不再赘述。

本申请实施例中，信息告警设备按照第一采样间隔采集目标监控对象的目标监控指标，得到当前时刻的第一监控值后，获取历史时刻采集目标监控指标得到的第一历史监控值，并基于第一监控值和第一历史监控值，确定目标阈值，然后基于第一监控值和目标阈值，确定告警提示信息，最后显示告警提示信息。这样，信息告警设备根据实时根据当前时刻的第一监控值和历史时刻的第一历史监控值动态确定目标阈值，来根据目标阈值和第一监控值之间的关系，生成告警提示信息，解决了目前的采用固定阈值来实现数据库监控导致不能准确实现数据库在各个时间段的告警需求的问题，实现了根据实际情况自适应调整阈值来实现数据库监控的方案，有效提高了针对数据库告警的准确率。并且，实现不同等级的告警提示，能够告知用户数据库当前的具体风险等级，以使用户根据风险等级决定是都需要立即进行相应处理。并根据不同风险等级，对造成风险的可能原因进行显示，方便用户进行分析处理，有效提高了人机交互过程，并提高了用户的使用体验效果。

基于前述实施例，本申请的实施例提供一种信息告警设备，参照图7所示，该信息告警设备5可以包括：处理器51、存储器52和通信总线53，其中：

存储器52，用于存储可执行指令；

通信总线53，用于实现处理器51和存储器52之间的通信连接；

处理器51，用于执行存储器52中存储的信息告警程序，以实现以下步骤：

获取历史时刻采集目标监控指标得到的第一历史监控值；

基于第一监控值和第一历史监控值，确定目标阈值；其中，目标阈值包括至少一个不同的阈值；

基于第一监控值和目标阈值，确定告警提示信息；其中，告警提示信息用于针对目标监控对象的目标监控指标进行告警提示；

显示告警提示信息。

在本申请实施例中，处理器执行步骤基于第一监控值和第一历史监控值，确定目标阈值时，可以通过以下步骤来实现：

获取目标监控对象的参考监控指标的当前时刻的第二监控值和参考监控指标的历史时刻采集到的第二历史监控值；其中，参考监控指标与目标监控指标具有关联关系；

基于第一监控值、第一历史监控值、第二监控值和第二历史监控值，确定目标权重系数；

基于第一历史监控值，确定第一参考值；

从第一历史监控值中，获取与当前时刻相邻的前一时刻的第一历史子监控值；

确定第一监控值与第一历史子监控值的差值，得到第二参考值；

基于目标权重系数、第二参考值、第一监控值、至少一个预设权重系数和第一参考值，得到目标阈值。

在本申请实施例中，处理器执行步骤基于第一监控值、第一历史监控值、第二监控值和第二历史监控值，确定目标权重系数时，可以通过以下步骤来实现：

通过确定第二时刻的监控值与第一时刻的监控值的差值的方式对第一监控值和第一历史监控值进行处理，得到目标监控指标不同时刻的第二差值；其中，第一时刻与第二时刻是两个相邻时刻，第一时刻距离当前时刻比第二时刻距离当前时刻远；

通过确定第二时刻的监控值与第一时刻的监控值的差值的方式对第二监控值和第二历史监控值进行处理，得到参考监控指标不同时刻的第三差值；

确定同一时刻的第三差值与第二差值比值，得到参考比值；

基于参考比值，确定目标权重系数。

在本申请实施例中，处理器执行步骤基于参考比值，确定目标权重系数时，可以通过以下步骤来实现：

从参考比值中获取比值大于零，且距离当前时刻最近的第二预设数量个目标比值；

确定第二预设数量个目标比值的平均值，得到目标权重系数。

在本申请实施例中，处理器执行步骤基于第一历史监控值，确定第一参考值时，可以通过以下步骤来实现：

从第一历史监控值中，获取当前时刻之前的第一预设数量个时间周期内，与当前时刻相同时刻的第一预设数量个第二历史子监控值；

确定第一预设数量个第二历史子监控值的标准差，得到第一参考值。

在本申请实施例中，处理器执行步骤基于目标权重系数、第二参考值、第一监控值、至少一个预设权重系数和第一参考值，得到目标阈值时，可以通过以下步骤来实现：

确定目标权重系数与第二参考值的第一乘积；

确定至少一个预设权重系数与第一参考值的乘积，得到至少一个第二乘积；

确定第一乘积、至少一个第二乘积中每一第二乘积和第一监控值的累加值，得到目标阈值。

在本申请实施例中，处理器执行步骤基于第一监控值和目标阈值，确定告警提示信息时，可以通过以下步骤来实现：

获取目标监控指标的目标上限值；

若第一监控值小于目标上限值，且第一监控值大于或等于第一阈值，按照第二采样间隔连续采集目标监控指标的第三预设数量个第三监控值；其中，第二采样间隔小于第一采样间隔，目标阈值包括第一阈值；

若第三预设数量个第三监控值均小于目标上限值，且至少一个第三监控值大于或等于第二阈值，生成第一告警信息；其中，目标阈值包括第二阈值，第二阈值大于第一阈值，第一告警信息用于实现针对目标监控对象的重大告警。

在本申请实施例中，处理器还用于执行以下步骤：

若第一监控值大于或等于目标上限值，生成第二告警信息；其中，第二告警信息用于实现针对目标监控对象的严重告警；

若第三预设数量个第三监控值中的至少一个第三监控值大于或等于目标上限值，生成第二告警信息；

若第三预设数量个第三监控值均小于第二阈值，生成第三告警信息；其中，第三告警信息用于实现针对目标监控对象的次要告警。

在本申请实施例中，处理器执行步骤基于第一监控值和目标阈值，确定告警提示信息之后，还用于执行以下步骤：

若告警提示信息是第一告警信息或第二告警信息，获取目标监控对象在当前时刻执行的至少一条结构化查询语言SQL语句；

获取至少一条SQL语句对应的执行计划；

基于至少一条SQL语句对应的执行计划，确定每一SQL语句对应目标监控指标的消耗成本，得到至少一条SQL语句对应的消耗成本；

基于至少一条SQL语句对应的消耗成本，按照消耗成本从高到低的排序顺序对至少一条SQL语句进行排序，得到SQL语句排序结果；

显示SQL语句排序结果。

在本申请实施例中，每一SQL语句对应目标监控指标的消耗成本包括输入输出IO消耗成本，处理器执行步骤基于至少一条SQL语句对应的执行计划，确定每一SQL语句对应目标监控指标的消耗成本，得到至少一条SQL语句对应的消耗成本时，可以通过以下步骤来实现：

基于至少一条SQL语句对应的执行计划，确定每一SQL语句对应的执行计划中包括的每一身份标识ID的行数；

确定行数为1的ID为第一ID，获取第一ID对应的第一行数和平均长度；其中，第一行数记录于每一SQL语句对应的执行计划中；

对第一行数与平均长度的乘积与预设InnoDB数据页大小进行向上取整处理，得到第一ID的IO消耗成本；

确定行数大于1的ID为第二ID，确定第二ID的每一行的返回行数和扫描行数；

获取对应的第二ID对应的平均长度；

确定第二ID的每一行的扫描行数与对应的相邻的前一行的返回行数的差值，得到第一差值；

确定第一差值与平均长度乘积与预设InnoDB数据页大小进行向上取整处理，得到第二ID的每一行对应的IO消耗子成本；

确定第二ID的每一行对应的IO消耗子成本的累加值，得到第二ID的IO消耗成本；

确定每一SQL语句对应的执行计划中包括的每一ID的IO消耗成本的累加值，得到至少一条SQL语句对应的消耗成本；其中，每一ID的IO消耗成本的累加值包括第一ID的IO消耗成本和/或第二ID的IO消耗成本。

在本申请其他实施例中，每一SQL语句对应目标监控指标的消耗成本包括中央处理器CPU消耗成本，处理器执行步骤基于至少一条SQL语句对应的执行计划，确定每一SQL语句对应目标监控指标的消耗成本，得到至少一条SQL语句对应的消耗成本时，可以通过以下步骤来实现：

确定行数为1的ID为第一ID；

基于第一ID的执行计划，确定第一ID对应的CPU消耗成本；

确定行数大于1的ID为第二ID；

基于第二ID的每一行的执行计划，确定第二ID的每一行对应的CPU消耗成本；

将第二ID的每一行对应的CPU消耗成本进行累加，得到第二ID对应的CPU消耗成本。

在本申请其他实施例中，处理器用于执行步骤基于第一ID的执行计划，确定第一ID对应的CPU消耗成本时，可以用于执行以下步骤：

基于第一ID的执行计划，确定第一ID对应的第一行数和返回行数；

从第一ID的执行计划中，获取第一ID对应的访问类型Type和额外字段信息Extra；

基于第一ID对应的Type、Extra和第一行数，得到第一ID对应的第一CPU消耗子成本；

确定返回行数的对数和返回行数的乘积，得到第一ID对应的第二CPU消耗子成本；

确定第一ID对应的第一CPU消耗子成本和第二CPU消耗子成本的和值，得到第一ID对应的CPU消耗成本。

在本申请其他实施例中，处理器用于执行步骤基于第二ID的每一行的执行计划，确定第二ID的每一行对应的CPU消耗成本时，可以通过以下步骤来实现：

基于第二ID的每一行的执行计划，确定第二ID的每一行的第二行数和返回行数；

从第二ID的每一行对应的执行计划中，获取第二ID的每一行对应的访问类型Type和额外字段信息Extra，和第二ID的每一行对应的表行数；

基于第二ID的每一行对应的Type、Extra和第二行数，得到第二ID的每一行对应的第三CPU消耗子成本；

确定第二ID的每一行的返回行数的对数与对应的返回行数的乘积，得到第二ID的每一行对应的第四CPU消耗子成本；

确定第二ID的每一行对应的表行数和第二ID的每一行对应的索引高度的乘积，得到第二ID的每一行对应的第五CPU消耗子成本；

确定第二ID的每一行对应的第三CPU消耗子成本、第四CPU消耗子成本和第五CPU消耗子成本的累加值，得到第二ID的每一行的CPU消耗成本。

在本申请其他实施例中，处理器执行步骤基于第一监控值和目标阈值，确定告警提示信息之后，还用于执行以下步骤：

若告警提示信息是第一告警信息或第二告警信息，获取目标监控对象在当前时刻执行的至少一条SQL语句；

对至少一条SQL语句按照语句相同的方式进行分组，得到至少一组SQL语句；

基于至少一组SQL语句，统计每一组SQL语句包括的SQL语句数量；

从至少一组SQL语句的每一组SQL语句中获取一条SQL语句，得到至少一条目标SQL语句；

确定目标备用数据库，通过目标备用数据库分别运行每一目标SQL语句；

确定目标备用数据库运行每一目标SQL语句时消耗的资源消耗子成本，得到每一目标SQL语句的资源消耗子成本；

确定每一目标SQL语句的资源消耗子成本与每一目标SQL语句所在组包括的SQL语句数量的乘积，得到每一组SQL语句的资源消耗成本；

按照每一组SQL语句的资源消耗成本从大到小的排序顺序，对至少一组SQL语句进行排序，得到排序结果，并显示排序结果。

在本申请实施例中，处理器执行步骤确定目标备用数据库运行每一目标SQL语句时消耗的资源消耗子成本，得到每一目标SQL语句的资源消耗子成本时，可以通过以下步骤来实现：

若目标备用数据库运行每一目标SQL语句的时长大于或等于预设时长，确定每一目标SQL语句的资源消耗子成本为第一数值；

若目标备用数据库运行每一目标SQL语句的时长小于预设时长，获取目标备用数据库运行每一目标SQL语句时对应的资源消耗表；

从每一目标SQL语句对应的资源消耗表中获取第一消耗资源和第二消耗资源，确定第一消耗资源和第二消耗资源的和值，得到每一目标SQL语句对应的资源消耗子成本；其中，第一消耗资源为用户态所消耗的CPU资源，第二消耗资源为核心态所消耗的CPU资源，和/或第一消耗资源为输入块操作的数量，第二消耗资源为输出块操作的数量。

需要说明的是，本申请实施例中个或者多个程序可被一个或者多个处理器的步骤的解释说明，可以参照图1～2和图5～6对应的实施例提供的方法实现过程，此处不再赘述。

基于前述实施例，本申请的实施例提供一种计算机可读存储介质，简称为存储介质，该计算机可读存储介质存储有一个或者多个程序，该一个或者多个程序可被一个或者多个处理器执行，以实现如图1～2和图5～6对应的实施例提供的信息告警方法实现过程，此处不再赘述。

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

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

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

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

以上所述，仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。

Claims

1.一种信息告警方法，其特征在于，所述方法包括：

显示所述告警提示信息；

其中，所述基于所述第一监控值和所述第一历史监控值，确定目标阈值，包括：

获取所述目标监控对象的参考监控指标的当前时刻的第二监控值和所述参考监控指标的历史时刻采集到的第二历史监控值；其中，所述参考监控指标与所述目标监控指标具有关联关系；

基于所述第一监控值、所述第一历史监控值、所述第二监控值和所述第二历史监控值，确定目标权重系数；

基于所述第一历史监控值，确定第一参考值；

从所述第一历史监控值中，获取与所述当前时刻相邻的前一时刻的第一历史子监控值；

确定所述第一监控值与所述第一历史子监控值的差值，得到第二参考值；

基于所述目标权重系数、所述第二参考值、所述第一监控值、至少一个预设权重系数和所述第一参考值，得到所述目标阈值。

2.根据权利要求1所述的方法，其特征在于，所述基于所述第一监控值、所述第一历史监控值、所述第二监控值和所述第二历史监控值，确定目标权重系数，包括：

通过确定第二时刻的监控值与第一时刻的监控值的差值的方式对所述第一监控值和所述第一历史监控值进行处理，得到所述目标监控指标不同时刻的第二差值；其中，所述第一时刻与所述第二时刻是两个相邻时刻，所述第一时刻距离所述当前时刻比所述第二时刻距离所述当前时刻远；

通过确定第二时刻的监控值与第一时刻的监控值的差值的方式对所述第二监控值和所述第二历史监控值进行处理，得到所述参考监控指标不同时刻的第三差值；

确定同一时刻的所述第三差值与所述第二差值比值，得到参考比值；

基于所述参考比值，确定目标权重系数。

3.根据权利要求2所述的方法，其特征在于，所述基于所述参考比值，确定目标权重系数，包括：

从所述参考比值中获取比值大于零，且距离所述当前时刻最近的第二预设数量个目标比值；

确定所述第二预设数量个所述目标比值的平均值，得到所述目标权重系数。

4.根据权利要求1所述的方法，其特征在于，所述基于所述第一历史监控值，确定第一参考值，包括：

从所述第一历史监控值中，获取所述当前时刻之前的第一预设数量个时间周期内，与所述当前时刻相同时刻的所述第一预设数量个第二历史子监控值；

确定所述第一预设数量个所述第二历史子监控值的标准差，得到所述第一参考值。

5.根据权利要求1所述的方法，其特征在于，所述基于所述目标权重系数、所述第二参考值、所述第一监控值、至少一个预设权重系数和所述第一参考值，得到所述目标阈值，包括：

确定所述目标权重系数与所述第二参考值的第一乘积；

确定所述至少一个预设权重系数与所述第一参考值的乘积，得到至少一个第二乘积；

确定所述第一乘积、所述至少一个第二乘积中每一所述第二乘积和所述第一监控值的累加值，得到所述目标阈值。

6.根据权利要求1所述的方法，其特征在于，所述基于所述第一监控值和所述目标阈值，确定告警提示信息，包括：

获取所述目标监控指标的目标上限值；

若所述第一监控值小于所述目标上限值，且所述第一监控值大于或等于第一阈值，按照第二采样间隔连续采集所述目标监控指标的第三预设数量个第三监控值；其中，所述第二采样间隔小于所述第一采样间隔，所述目标阈值包括所述第一阈值；

若所述第三预设数量个第三监控值均小于所述目标上限值，且至少一个所述第三监控值大于或等于第二阈值，生成第一告警信息；其中，所述目标阈值包括所述第二阈值，所述第二阈值大于所述第一阈值，所述第一告警信息用于实现针对所述目标监控对象的重大告警。

7.根据权利要求6所述的方法，其特征在于，所述方法还包括：

若所述第一监控值大于或等于所述目标上限值，生成第二告警信息；其中，所述第二告警信息用于实现针对所述目标监控对象的严重告警；

若所述第三预设数量个第三监控值中的至少一个所述第三监控值大于或等于所述目标上限值，生成所述第二告警信息；

若所述第三预设数量个第三监控值均小于所述第二阈值，生成第三告警信息；其中，所述第三告警信息用于实现针对所述目标监控对象的次要告警。

8.根据权利要求7所述的方法，其特征在于，所述基于所述第一监控值和所述目标阈值，确定告警提示信息之后，所述方法还包括：

若所述告警提示信息是所述第一告警信息或所述第二告警信息，获取所述目标监控对象在所述当前时刻执行的至少一条结构化查询语言SQL语句；

获取所述至少一条SQL语句对应的执行计划；

基于所述至少一条SQL语句对应的执行计划，确定每一所述SQL语句对应所述目标监控指标的消耗成本，得到所述至少一条SQL语句对应的消耗成本；

基于所述至少一条SQL语句对应的消耗成本，按照消耗成本从高到低的排序顺序对所述至少一条SQL语句进行排序，得到SQL语句排序结果；

显示所述SQL语句排序结果。

9.根据权利要求8所述的方法，其特征在于，每一所述SQL语句对应所述目标监控指标的消耗成本包括输入输出IO消耗成本，所述基于所述至少一条SQL语句对应的执行计划，确定每一所述SQL语句对应所述目标监控指标的消耗成本，得到所述至少一条SQL语句对应的消耗成本，包括：

基于所述至少一条SQL语句对应的执行计划，确定每一所述SQL语句对应的执行计划中包括的每一身份标识ID的行数；

确定行数为1的ID为第一ID，获取所述第一ID对应的第一行数和平均长度；其中，所述第一行数记录于每一所述SQL语句对应的执行计划中；

对所述第一行数与所述平均长度的乘积与预设InnoDB数据页大小进行向上取整处理，得到所述第一ID的IO消耗成本；

确定行数大于1的ID为第二ID，确定所述第二ID的每一行的返回行数和扫描行数；

获取对应的所述第二ID对应的平均长度；

确定所述第二ID的每一行的扫描行数与对应的相邻的前一行的返回行数的差值，得到第一差值；

确定所述第一差值与所述平均长度乘积与所述预设InnoDB数据页大小进行向上取整处理，得到所述第二ID的每一行对应的IO消耗子成本；

确定所述第二ID的每一行对应的IO消耗子成本的累加值，得到所述第二ID的IO消耗成本；

确定每一所述SQL语句对应的执行计划中包括的每一ID的IO消耗成本的累加值，得到所述至少一条SQL语句对应的消耗成本；其中，每一ID的IO消耗成本的累加值包括所述第一ID的IO消耗成本和/或所述第二ID的IO消耗成本。

10.根据权利要求8所述的方法，其特征在于，每一所述SQL语句对应所述目标监控指标的消耗成本包括中央处理器CPU消耗成本，所述基于所述至少一条SQL语句对应的执行计划，确定每一所述SQL语句对应所述目标监控指标的消耗成本，得到所述至少一条SQL语句对应的消耗成本，包括：

确定行数为1的ID为第一ID；

基于所述第一ID的执行计划，确定所述第一ID对应的CPU消耗成本；

确定行数大于1的ID为第二ID；

基于所述第二ID的每一行的执行计划，确定所述第二ID的每一行对应的CPU消耗成本；

将所述第二ID的每一行对应的CPU消耗成本进行累加，得到所述第二ID对应的CPU消耗成本。

11.根据权利要求10所述的方法，其特征在于，所述基于所述第一ID的执行计划，确定所述第一ID对应的CPU消耗成本，包括：

基于所述第一ID的执行计划，确定所述第一ID对应的第一行数和返回行数；

从所述第一ID的执行计划中，获取所述第一ID对应的访问类型Type和额外字段信息Extra；

基于所述第一ID对应的所述Type、所述Extra和所述第一行数，得到所述第一ID对应的第一CPU消耗子成本；

确定所述返回行数的对数和所述返回行数的乘积，得到所述第一ID对应的第二CPU消耗子成本；

确定所述第一ID对应的所述第一CPU消耗子成本和所述第二CPU消耗子成本的和值，得到所述第一ID对应的所述CPU消耗成本。

12.根据权利要求10所述的方法，其特征在于，所述基于所述第二ID的每一行的执行计划，确定所述第二ID的每一行对应的CPU消耗成本，包括：

基于所述第二ID的每一行的执行计划，确定所述第二ID的每一行的第二行数和返回行数；

从所述第二ID的每一行对应的执行计划中，获取所述第二ID的每一行对应的访问类型Type和额外字段信息Extra，和所述第二ID的每一行对应的表行数；

基于所述第二ID的每一行对应的所述Type、所述Extra和所述第二行数，得到所述第二ID的每一行对应的第三CPU消耗子成本；

确定所述第二ID的每一行的所述返回行数的对数与对应的所述返回行数的乘积，得到所述第二ID的每一行对应的第四CPU消耗子成本；

确定所述第二ID的每一行对应的表行数和所述第二ID的每一行对应的索引高度的乘积，得到所述第二ID的每一行对应的第五CPU消耗子成本；

确定所述第二ID的每一行对应的所述第三CPU消耗子成本、所述第四CPU消耗子成本和所述第五CPU消耗子成本的累加值，得到所述第二ID的每一行的CPU消耗成本。

13.根据权利要求7所述的方法，其特征在于，所述基于所述第一监控值和所述目标阈值，确定告警提示信息之后，所述方法还包括：

若所述告警提示信息是所述第一告警信息或所述第二告警信息，获取所述目标监控对象在所述当前时刻执行的至少一条SQL语句；

对所述至少一条SQL语句按照语句相同的方式进行分组，得到至少一组SQL语句；

基于所述至少一组SQL语句，统计每一组SQL语句包括的SQL语句数量；

从所述至少一组SQL语句的每一组SQL语句中获取一条SQL语句，得到至少一条目标SQL语句；

确定目标备用数据库，通过所述目标备用数据库分别运行每一所述目标SQL语句；

确定所述目标备用数据库运行每一所述目标SQL语句时消耗的资源消耗子成本，得到每一所述目标SQL语句的资源消耗子成本；

确定每一所述目标SQL语句的资源消耗子成本与每一所述目标SQL语句所在组包括的SQL语句数量的乘积，得到每一组所述SQL语句的资源消耗成本；

按照每一组所述SQL语句的资源消耗成本从大到小的排序顺序，对所述至少一组SQL语句进行排序，得到排序结果，并显示所述排序结果。

14.根据权利要求13所述的方法，其特征在于，所述确定所述目标备用数据库运行每一所述目标SQL语句时消耗的资源消耗子成本，得到每一所述目标SQL语句的资源消耗子成本，包括：

若所述目标备用数据库运行每一所述目标SQL语句的时长大于或等于预设时长，确定每一所述目标SQL语句的资源消耗子成本为第一数值；

若所述目标备用数据库运行每一所述目标SQL语句的时长小于所述预设时长，获取所述目标备用数据库运行每一所述目标SQL语句时对应的资源消耗表；

从每一所述目标SQL语句对应的所述资源消耗表中获取第一消耗资源和第二消耗资源，确定所述第一消耗资源和所述第二消耗资源的和值，得到每一所述目标SQL语句对应的资源消耗子成本；其中，所述第一消耗资源为用户态所消耗的CPU资源，所述第二消耗资源为核心态所消耗的CPU资源，和/或所述第一消耗资源为输入块操作的数量，所述第二消耗资源为输出块操作的数量。

15.一种信息告警设备，其特征在于，所述设备包括存储器、处理器和通信总线；其中：

所述存储器，用于存储可执行指令；

所述处理器，用于执行所述存储器中存储的信息告警程序，实现如权利要求1至14中任一项所述的信息告警方法的步骤。

16.一种存储介质，其特征在于，所述存储介质上存储有信息告警程序，所述信息告警程序被处理器执行时实现如权利要求1至14中任一项所述的信息告警方法的步骤。