本发明涉及数据库技术领域，特别涉及一种数据库性能监控方法、系统、设备及计算机可读存储介质。
背景技术：
目前数据库监控主要是在出现问题之后进行警报，根据简单的判断规则，对数据库的几个运行参数进行判断报警，因为是硬性的判断规则，往往会产生误报，增加运维成本。
目前使用的数据库监控软件有qmonintor，qmonintor是一款针对oracle和mysql的专业数据库监控平台软件。根据用户设置及时有效地将数据库的异常进行报警，方便用户查看各种实时状态曲线指标，并且对监控、性能数据进行统计分析，从运维者到决策者多个层面的视角生成相关报表。
但是，该软件只是对数据库的各项参数进行展示和简单的判断，报警规则过于单一，然而数据库出现性能问题往往不是一个因素造成的，而是由多种因素或者多种因素相互作用造成的，有可能某个指标的增加是因为其他因素造成的。因此，观测单一因素并不能真实反映数据库的性能状况。例如，案例数据中的数据库报警邮件报警产生的原因就是耗时过长(22s)。
目前使用的数据库监控工具还有spotlightonoracle，spotlightonoracle是业内比较主流的工具，在监控预警方面备受欢迎。spotlightonoracle是通过获得操作系统自带的计数器数据，然后通过图形工具图形化。采用客户端、服务端监控的方式均可。既可以在客户端安装，由可以在服务端安装。但spotlightonoracle不支持awr日志数据，awr是oracle10g之后新提供的自动收集数据库统计数据的内置工具，它是oracle数据库整体运行状况的全面展示，可以为数据库性能调优和故障诊断提供有力的帮助。
通过上述现有的传统工具监控数据库，每天触发很多警报，其中大多数是虚警情况，虚警率太高，使得增加了很多运维成本，消耗了大量运维资源。
技术实现要素：
本发明实施例提供了一种数据库性能监控方法，以解决现有技术中数据库监控过程中虚警率高的技术问题。该方法包括：实时采集数据库的日志数据和所述数据库所在服务器的硬件信息；将所述日志数据和所述硬件信息实时输入预警监测模型，所述预警监测模型输出所述数据库的预警监测结果，其中，所述预警监测模型是采用所述数据库的历史日志数据和所述数据库所在服务器的历史硬件信息作为输入数据训练得到的。
本发明实施例还提供了一种计算机设备，以解决现有技术中数据库监控过程中虚警率高的技术问题。该计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述任意的数据库性能监控方法。
本发明实施例还提供了一种计算机可读存储介质，以解决现有技术中数据库监控过程中虚警率高的技术问题。所述计算机可读存储介质存储有执行上述任意的数据库性能监控方法的计算机程序。
本发明实施例还提供了一种数据库性能监控系统，以解决现有技术中数据库监控过程中虚警率高的技术问题。该系统包括：数据采集装置，用于实时采集数据库的日志数据和所述数据库所在服务器的硬件信息；监测装置，用于将所述日志数据和所述硬件信息实时输入预警监测模型，所述预警监测模型输出所述数据库的预警监测结果，其中，所述预警监测模型是采用所述数据库的历史日志数据和所述数据库所在服务器的历史硬件信息作为输入数据训练得到的。
在本发明实施例中，实时将数据库的日志数据和数据库所在的服务器的硬件信息输入预警监测模型，预警监测模型实时输出数据库的预警监测结果。实现了结合数据库的日志数据和服务器的硬件信息来监测数据库的性能状态，有利于避免基于单一因素监控数据库导致的虚警率高的问题，有利于更准确的监控数据库的性能状态，降低虚警率。
附图说明
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，并不构成对本发明的限定。在附图中：
图1是本发明实施例提供的一种数据库性能监控方法的流程图；
图2是本发明实施例提供的一种数据库报警原理示意图；
图3是本发明实施例提供的一种获取预警监测模型的方案示意图；
图4是本发明实施例提供的一种数据采集的流程示意图；
图5是本发明实施例提供的一种训练预警监测模型的流程示意图；
图6是本发明实施例提供的一种预警监测模型输出数据示意图；
图7是本发明实施例提供的一种应用预警监测模型监控数据库的流程示意图；
图8是本发明实施例提供的一种数据库性能监控系统的结构框图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施方式和附图，对本发明做进一步详细说明。在此，本发明的示意性实施方式及其说明用于解释本发明，但并不作为对本发明的限定。
在本发明实施例中，提供了一种数据库性能监控方法，如图1所示，该方法包括：
步骤101：实时采集数据库的日志数据和所述数据库所在服务器的硬件信息；
步骤102：将所述日志数据和所述硬件信息实时输入预警监测模型，所述预警监测模型输出所述数据库的预警监测结果，其中，所述预警监测模型是采用所述数据库的历史日志数据和所述数据库所在的服务器的历史硬件信息作为输入数据训练得到的。
由图1所示的流程可知，在本发明实施例中，实时将数据库的日志数据和数据库所在的服务器的硬件信息输入预警监测模型，预警监测模型实时输出数据库的预警监测结果。实现了结合数据库的日志数据和服务器的硬件信息来监测数据库的状态，有利于避免基于单一因素监控数据库导致的虚警率高的问题，有利于更准确的监控数据库的性能状态，降低虚警率。
具体实施时，如图2所示，上述数据库以彩票业务数据库为例，通过以下步骤来监控数据库的报警：采集数据库系统数百的性能变量状态快照；通过数据库性能变量的状态，结合设定的预警监测模型，来判断数据库性能变量中的相关指标是否达到报警条件，如果达到，则发送报警邮件；否则，忽略。
对此，本申请发明人发现，要想准确的对数据库进行预警，首先，需要确定采用哪些数据作为预警因素。
(1)业务数据库系统监测报警主要是针对于sql语句实时监控，局限于对于性能视图的简单查询，例如，单位采样时间内对数据库的整体sql语句进行轮询监控，主要是基于数据库提供的动态性能变量中的cpu耗时、语句整体耗时、逻辑读次数、物理读次数、解析调用次数、io等待时间、应用等待时间、集群等待时间、plsql执行时间等指标占整体sql消耗资源的比值设定相关阈值，并对查询结果进行排序，选取前几条超出阈值的sql语句进行报警。
awr(自动工作负载信息库)主要包含两个部分：在内存中，通过读取动态性能视图和数据字典里的数据，收集数据库工作负载的相关信息，这些信息包括数据库的基本统计信息、衡量数据库活动的各个指标值、ash(活动会话记录)、顾问建议、快照信息；每隔一段时间，通过mmon(管理监视器)的后台进程，将内存里的数据写入到磁盘上的表空间。awr包含了数百个表，这些表均为sysman用户所有，并存放在sysaux表空间中。
自动工作负载信息库(awr)是oracle自动化管理的一个重要组成部分，通过awr生成的数据库快照报表提供了丰富的数据库运行状况信息，dba(数据库管理员)可以通过分析awr报表来了解数据库的性能瓶颈和可能存在的问题，及时作出调整，保障数据库平稳、高效地运行。
本申请发明人对awr日志数据进行了认真的分析，从中提取出389个字段。对389个字段首先进行了字段理解，即了解每个字段是什么含义、代表数据库处于什么样的状态，然后对这些指标进行了综合分类。形成磁盘i/o(数据库中发生的每个动作几乎都将产生某种类型的i/o活动，该活动可以是逻辑的(在内存中)，也可以是物理的(在磁盘上的))、用户响应时间(响应时间是指用户从提交sql语句开始到获得结果集的第一行所需要的时间，是应用做出反应的时间，以毫秒或秒表示)、内存使用情况(内存使用情况主要体现在可共享内存、永久性内存和运行内存这三者的分配使用上)、数据库命中率(oracle用户进程所需要的所有数据都是经过缓冲区高速缓存来存取的，用户对数据库的需求能否在内存中得到满足，给出快速的响应，可用缓冲区高速缓存命中率来衡量)、吞吐量(吞吐量是指单位时间内数据库完成的sql语句数目，以每秒钟的事务量(tps)表示)5个综合指标，这五个指标可以代表数据库的性能状况。
(2)服务器硬件数据是用来监测服务器硬件信息的字段信息，包括监测时间点，监测时间点内各字段的参数值。本申请发明人对服务器硬件信息进行处理，服务器硬件信息共包括监测时间点(date_time)、cpu使用状况(cpu_util)、磁盘使用状况(disk_util)、内存使用状况(memory_util)、交换空间使用状况(swap_util)和网络等待(net_wait)。监测时间点表示是在什么时刻进行的硬件信息采集；cpu使用状况表示当前cpu的使用状况，如cpu单元值为10.6，则表示cpu使用率为10.6％；磁盘使用状况表示磁盘当前时刻的使用状况，如值为74.5，则表示磁盘使用率为74.5％；内存使用情况表示当前时刻内存的使用情况，如值为70.9，则表示内存使用率为70.9％；交换空间使用情况表示当前时刻交换空间的使用情况；网络等待表示当前时刻的网络状况。本申请发明人发现，某一时刻的硬件数据信息，可以在一定程度上反映数据库的性能状况。
因此，本申请发明人提出采用数据库的日志数据和数据库所在服务器的硬件信息来对数据库进行预警监控。
其次，确定出采用哪些数据作为预警因素之后，需要确定预警规则。报警邮件主要来源于oracle企业管理器的报警设置模块，在该模块通过对观测指标设置预设阈值，监测数据库性能状况；若观测指标超过预设阈值，oracle企业管理器则会向运维人员发送报警邮件，通常情况下，出于安全和低风险因素的考虑，阈值往往设置比较低，这样就会造成较多的报警邮件，而且由于监测的是单个因素，因而许多报警邮件属于虚警。
在本申请中，由于采用了服务器的硬件信息进行预警，涉及到多台服务器，服务器类型不同，需要监测的指标不尽相同，因此，对应的报警规则也不相同，对应的报警邮件模板也不同。本申请发明人提出，将针对不同的报警邮件模板，设置不同的邮件抽取规则，将报警邮件中的报警数据抽取到数据库中，报警数据主要包括报警主机、报警类型、报警详情、报警时间、报警严重程度等。具体的，拟将所有涉及到的报警类型、报警严重程度整理出来，请业务人员帮忙进行人工标注，人工识别哪些属于真正的警告或者错误，哪些属于虚假警告。然后将人工标注过的报警数据匹配到实际的预警监测模型训练数据集的输出项中(注意，报警数据和日志数据、硬件信息的时间匹配)，进行模型训练。
具体实施时，如图3所示，本申请提出的数据库监控具体方案为，通过流数据采集平台将流数据(即日志数据和数据库所在服务器的硬件信息)采集并预处理后存储到数据仓库中，其中包括两部分，一部分是实时数据，另一部分是历史数据，实时数据作为预警监测模型的输入数据，来得到数据库的预警监测结果；历史数据将用于数据库性能监测可视化的数据输入，并作为输入数据来训练预警监测模型；可以设置一个模型库，模型库同时包括多个训练完成的预警监测模型，用于数据库状况监测的只有一个最优模型，在运行模型的时候会同时有一个模型监控部分对模型性能评估，若当前最优模型不能达到要求，则将其移除，将训练好的潜在最优模型用于数据库监测，替换掉当前最优模型，此过程将是一个循环迭代的过程；最后就是将训练完成的预警监测模型部署并应用到实际业务系统当中去，对业务系统中的数据库进行健康状况监测。
具体实施时，如图4所示，采集日志数据和服务器的硬件信息，主要包括日志文件定位、流数据采集、流数据处理以及流数据存储几个部分。首先是对日志文件定位，这主要包括数据库报警邮件的源数据位置以及awr日志中数据库相关统计指标导出的位置，当然还包括统计信息的导出频率；在流数据采集中可以采用flume加kafka的方案，使用flume动态监测日志文件(目录)的变化，将增量数据输出到kafka消息队列中，对于kafka消息队列来说等待流数据处理模块处理数据；流数据处理模块主要有三个备选方案：spark、storm及influxdata，若对实时性要求不高的话就采用spark，对实时性要求很高的话就采用storm，当然如果希望使用一体化方案的话也可以考虑使用infuxdata，包括采集、监控、存储以及可视化，缺点就是可能还不够成熟；在将数据永久存储或者在预警监测模型运算之前，会先将数据存到中间的临时数据库中，可以使用mysql数据库。
具体实施时，采集到数据库的日志数据和数据库所在服务器的硬件信息之后，可以通过以下步骤来根据历史日志数据和历史硬件信息训练预警监测模型：将所述数据库的历史日志数据和所述数据库所在服务器的历史硬件信息作为所述预警监测模型的输入数据；将预设时长内的所述历史日志数据和所述历史硬件信息对应的预警信息标记出为对应的预警级别，其中，所述预警信息是所述历史日志数据和所述历史硬件信息超过预设阈值时得到的(即首先将固定时间段的所需历史日志数据和历史硬件信息从源数据中抽取出来，然后将该固定时间段内报警邮件中的报警事件类型和报警详情等报警信息标记为对应的预警级别)；对所述预警级别设置权重值，所述预警级别与权重值相乘得到预警分数；将预警监测结果作为所述预警监测模型的输出数据，其中，所述预警监测结果包括所述预警分数和健康监测状态，不同区间段的预警分数对应不同的健康监测状态。
具体的，上述训练预警监测模型的过程可以采用决策树、随机森林等算法实现，若结果不理想可以考虑使用神经网络等深度学习算法实现。
具体的，如图6所示，将预警监测模型训练好以后，通过打分模型来完成数据库的健康状况监测，即针对每一个特征字段预警监测模型都会给出一个权重值；然后通过时间窗口来选取特征字段，即选取的特征字段数据是时间段数据，对选取的数据做处理后，根据它们所对应的权重就可以得出一个此时刻的数据库健康状况的预警分数；按照事先定义好的规则，根据数据库具体的预警分数给出对数据库健康状况的综合评价，不同区间段的预警分数对应不同的健康监测状态。例如，预警分数90至100，健康状况为优秀；预警分数80至90，健康状况为良好；预警分数70至80，健康状况为一般；预警分数60至70，健康状况为警告；预警分数0至60，健康状况为危险。
具体实施时，在使用训练好的预警监测模型监控数据库的过程中，为了进一步提高监控的准确性，在本实施例中，如图3所示，实时判断当前的所述预警监测模型对于所述数据库是否是最优预警监测模型，其中，所述最优预警监测模型是指预警准确度达到预设值的预警监测模型；若不是(例如，当前监测所述数据库的预警监测模型的预警准确度低于预设值时，则认为该预警监测模型不是最优预警监测模型)，则在模型库中选择所述数据库的最优预警监测模型来监测所述数据库，实时更新最优预警监测模型是一个循环迭代的过程，有助于达到提高报警准确率的目的。
具体的，在训练预警监测模型的过程中，将历史日志数据和历史硬件信息存于测试数据库中，通过测试数据库中的历史日志数据和历史硬件信息来训练预警监测模型，训练得到多个预警监测模型，预警监测模型输出的预测结果与历史日志数据和历史硬件信息对应的预警信息之间的一致程度表示预警监测模型的预警准确度，在多个预警监测模型中，预测准确度最高的预警监测模型为上述最优预警监测模型。
具体实施时，上述数据库性能监控方法可以通过监测系统的形式作为一个独立的第三方系统部署，如图7所示，不对数据库原有的系统做更改，只需从业务数据库所在服务器读取所需日志数据用于预警监测模型即可；在预警监测模型应用上，将数据库特征字段权重数据作为配置文件(即图7中的打分规则文件)的形式放到监测系统中，监测系统只需读取配置文件即可，方便预警监测模型更新与优化，当数据库性能出现异常时能够及时的将预警监测结果反馈给相应的管理人员及时处理。
基于同一发明构思，本发明实施例中还提供了一种数据库性能监控系统，如下面的实施例所述。由于数据库性能监控系统解决问题的原理与数据库性能监控方法相似，因此数据库性能监控系统的实施可以参见数据库性能监控方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
图8是本发明实施例的数据库性能监控系统的一种结构框图，如图8所示，该系统包括：
数据采集装置801，用于实时采集数据库的日志数据和所述数据库所在服务器的硬件信息；
监测装置802，用于将所述日志数据和所述硬件信息实时输入预警监测模型，所述预警监测模型输出所述数据库的预警监测结果，其中，所述预警监测模型是采用所述数据库的历史日志数据和所述数据库所在服务器的历史硬件信息作为输入数据训练得到的。
在一个实施方式中，数据库性能监控系统还包括：
模型训练装置803，用于将所述数据库的历史日志数据和所述数据库所在服务器的历史硬件信息作为所述预警监测模型的输入数据；将预设时长内的所述历史日志数据和所述历史硬件信息对应的预警信息标记出为对应的预警级别，其中，所述预警信息是所述历史日志数据和所述历史硬件信息超过预设阈值时得到的；对所述预警级别设置权重值，所述预警级别与权重值相乘得到预警分数；将预警监测结果作为所述预警监测模型的输出数据，其中，所述预警监测结果包括所述预警分数和健康监测状态，不同区间段的预警分数对应不同的健康监测状态。
在一个实施方式中，数据库性能监控系统还包括：
模型更新装置804，用于实时判断当前的所述预警监测模型对于所述数据库是否是最优预警监测模型，其中，所述最优预警监测模型是指预警准确度达到预设值的预警监测模型；若不是，则在模型库中选择所述数据库的最优预警监测模型来监测所述数据库，其中，所述模型库中包括多个预警监测模型。
在一个实施方式中，所述日志数据包括磁盘i/o、用户响应时间、内存使用情况、数据库命中率以及吞吐量；所述硬件信息包括检测时间点和检测时间点内的硬件参数值。
在另外一个实施例中，还提供了一种计算机设备，该计算机设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述任意的数据库性能监控方法
在另外一个实施例中，还提供了一种软件，该软件用于执行上述实施例及优选实施方式中描述的技术方案。
在另外一个实施例中，还提供了一种存储介质，该存储介质中存储有上述软件，该存储介质包括但不限于：光盘、软盘、硬盘、可擦写存储器等。
本发明实施例实现了如下技术效果：实时将数据库的日志数据和数据库所在的服务器的硬件信息输入预警监测模型，预警监测模型实时输出数据库的预警监测结果。实现了结合数据库的日志数据和服务器的硬件信息来监测数据库的状态，有利于避免基于单一因素监控数据库导致的虚警率高的问题，有利于更准确的监控数据库的性能状态，降低虚警率。
显然，本领域的技术人员应该明白，上述的本发明实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明实施例不限制于任何特定的硬件和软件结合。
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明实施例可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。