CN111352921A - 基于elk的慢查询监控方法、装置、计算机设备及存储介质 - Google Patents

Abstract

本发明公开了一种基于ELK的慢查询监控方法、装置、计算机设备及存储介质，所述方法包括：通过配置慢查询条件，并根据慢查询条件，记录数据库执行查询处理时的基础语句以及基础语句对应的查询耗时，得到初始日志文件，通过预设脚本，保存初始日志文件的状态，并周期性对状态进行检查，若状态发送变化，则获取初始日志文件中的变化数据，作为基础资源数据，节约了监控所需消耗的系统资源，提高了监控的及时性，再通过ELK系统实时接收基础资源数据，并对基础资源数据进行过滤分析，得到实时分析结果，判断实时分析结果是否达到预设预警条件，达到时，进行预警，实现实时对分布式数据库的慢查询进行监控，有利于提高数据库慢查询监控的效率和及时性。

Description

基于ELK的慢查询监控方法、装置、计算机设备及存储介质

技术领域

本发明涉及数据库运维领域，尤其涉及一种基于ELK的慢查询监控方法、装置、计算机设备及存储介质。

背景技术

目前，随着IOE(IBM，ORACLE，EMC)运动的大力发展，越来越多的互联网企业使用MySQL数据库作为它的后台数据库。MySQL是一个关系型数据库管理系统，在WEB应用方面MySQL是最好的RDBMS(Relational Database Management System，关系数据库管理系统)应用软件之一。MySQL将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。MySQL所使用的SQL语言是用于访问数据库的最常用标准化语言。MySQL数据库在企业中，由于成本、水平扩展等优势原因受到越来越广泛的应用。

然而，在实现本发明的过程中，发明人意识到现有的实现方式至少存入如下问题：在实际应用中，当MySQL在运行过程中出现问题时，很大比例的问题都与数据库有关，而与数据有关的性能、容量问题往往都能在单条查询语句执行时间看出来。涉及查询较多时，会存在一些查询慢的情况，查询慢往往代表数据库即将或者已经出现了某种性能问题，通常将超过指定时间的SQL语句查询称为慢查询。在Oracle、PostgreSQL等数据库中可以通过专门的数据库语句查询出查询语句的执行时间，然而在MySql中缺乏这种手段，使得无法有效对慢查询进行监控，在慢查询较多时，容易导致数据库性能障碍。因而，寻找一种有效针对MySql慢查询进行有效监控的方法，成了一个亟待解决的难题。

发明内容

本发明实施例提供一种基于ELK的慢查询监控方法、装置、计算机设备和存储介质，以提高MySQL数据库中慢查询的监控效率。

为了解决上述技术问题，本申请实施例提供一种基于ELK的慢查询监控方法，包括：

配置慢查询条件，并根据所述慢查询条件，记录数据库执行查询处理时的基础语句以及所述基础语句对应的查询耗时，得到初始日志文件；

通过预设脚本，保存所述初始日志文件的状态，并周期性对所述状态进行检查，若所述状态发送变化，则获取所述初始日志文件中的变化数据，作为基础资源数据；

通过所述ELK系统实时接收所述基础资源数据，并对所述基础资源数据进行过滤分析，得到实时分析结果；

判断所述实时分析结果是否达到预设预警条件，若达到，则进行预警。

可选地，所述通过所述ELK系统实时接收所述基础资源数据，并对所述基础资源数据进行过滤分析，得到实时分析结果包括：

通过所述ELK系统中的日志采集框架Logstash，从分布式节点中采集所述基础资源数据；

对所述基础资源数据进行过滤处理，并将过滤结果存入到搜索引擎Elasticsearch中；

通过所述搜索引擎Elasticsearch对所述过滤结果进行优化分析，得到实时分析结果，并通过可视化框架Kibana展示所述实时分析结果。

可选地，通过所述ELK系统中的日志采集框架Logstash，从分布式节点中采集所述基础资源数据包括：

部署分布式发布订阅消息系统Kafka和所述日志采集框架Logstash；

通过所述分布式发布订阅消息系统Kafka实时从分布式节点中获取所述资源数据，并生成日志文件分布存储在索引序列Offset中；

使用所述日志采集框架Logstash定时从分布存储的索引序列Offset中获取资源数据，并将获取到的资源数据作为所述基础资源数据。

可选地，所述使用所述日志采集框架Logstash定时从分布存储的索引序列Offset中获取资源数据，并将获取到的资源数据作为所述基础资源数据包括：

获取预设时间间隔内的索引序列Offset，作为目标索引序列；

获取所述目标索引序列对应的日志文件；

采用所述日志采集框架Logstash对所述日志文件进行分类，并获取与预设条件匹配的分类对应的资源数据，作为所述基础资源数据。

可选地，在所述通过所述ELK系统实时接收所述基础资源数据，并对所述基础资源数据进行过滤分析，得到实时分析结果之后，所述基于ELK的慢查询监控方法还包括：

根据所述实时分析结果，构建可视化图表，其中，所述可视化图表包括趋势图、频数图、比重图或数据表格中的至少一个；

在可视化界面中显示所述可视化图表。

可选地，所述预设预警条件包括第一预警范围和第二预警范围，所述判断所述实时分析结果是否达到预设预警条件，若达到，则进行预警包括：

若所述实时分析结果满足预设的第一预警范围，则发送预警信息；

若所述实时分析结果满足预设的第二预警范围，则执行相应的应急预警措施。

为了解决上述技术问题，本申请实施例还提供一种基于ELK的慢查询监控装置，包括：

查询配置模块，用于配置慢查询条件，并根据所述慢查询条件，记录数据库执行查询处理时的基础语句以及所述基础语句对应的查询耗时，得到初始日志文件；

状态监控模块，用于通过预设脚本，保存所述初始日志文件的状态，并周期性对所述状态进行检查，若所述状态发送变化，则获取所述初始日志文件中的变化数据，作为基础资源数据；

数据分析模块，用于通过所述ELK系统实时接收所述基础资源数据，并对所述基础资源数据进行过滤分析，得到实时分析结果；

预警模块，用于判断所述实时分析结果是否达到预设预警条件，若达到，则进行预警。

可选地，所述数据分析模块包括：

数据采集子模块，用于通过所述ELK系统中的日志采集框架Logstash，从分布式节点中采集所述基础资源数据；

数据存储子模块，用于对所述基础资源数据进行过滤处理，并将过滤结果存入到搜索引擎Elasticsearch中；

数据分析子模块，用于通过所述搜索引擎Elasticsearch对所述过滤结果进行优化分析，得到实时分析结果，并通过可视化框架Kibana展示所述实时分析结果。

可选地，所述数据采集子模块包括：

部署单元，用于部署分布式发布订阅消息系统Kafka和所述日志采集框架Logstash；

数据接收单元，用于通过所述分布式发布订阅消息系统Kafka实时从分布式节点中获取所述资源数据，并生成日志文件分布存储在索引序列Offset中；

数据采集单元，用于使用所述日志采集框架Logstash定时从分布存储的索引序列Offset中获取资源数据，并将获取到的资源数据作为所述基础资源数据。

可选地，所述数据采集单元包括：

索引获取子单元，用于获取预设时间间隔内的索引序列Offset，作为目标索引序列；

日志获取子单元，用于获取所述目标索引序列对应的日志文件；

信息分类子单元，用于采用所述日志采集框架Logstash对所述日志文件进行分类，并获取与预设条件匹配的分类对应的资源数据，作为所述基础资源数据。

可选地，所述基于ELK的慢查询监控方法还包括：

图标构建模块，用于根据所述实时分析结果，构建可视化图表，其中，所述可视化图表包括趋势图、频数图、比重图或数据表格中的至少一个；

可视化模块，用于在可视化界面中显示所述可视化图表。

可选地，所述预设预警条件包括第一预警范围和第二预警范围，所述预警模块包括：

第一预警单元，用于若所述实时分析结果满足预设的第一预警范围，则发送预警信息；

第二预警单元，用于若所述实时分析结果满足预设的第二预警范围，则执行相应的应急预警措施。

为了解决上述技术问题，本申请实施例还提供一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述基于ELK的慢查询监控方法的步骤。

为了解决上述技术问题，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述基于ELK的慢查询监控方法的步骤。

本发明实施例提供的基于ELK的慢查询监控方法、装置、计算机设备及存储介质，通过配置慢查询条件，并根据慢查询条件，记录数据库执行查询处理时的基础语句以及基础语句对应的查询耗时，得到初始日志文件，通过预设脚本，保存初始日志文件的状态，并周期性对状态进行检查，若状态发送变化，则获取初始日志文件中的变化数据，作为基础资源数据，节约了监控所需消耗的系统资源，提高了监控的及时性，再通过ELK系统实时接收基础资源数据，并对基础资源数据进行过滤分析，得到实时分析结果，判断实时分析结果是否达到预设预警条件，在达到预设预警条件时，进行预警，实现实时对分布式数据库的慢查询进行监控，有利于提高数据库慢查询监控的效率和及时性。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请可以应用于其中的示例性系统架构图；

图2是本申请的基于ELK的慢查询监控方法的一个实施例的流程图；

图3是根据本申请的基于ELK的慢查询监控装置的一个实施例的结构示意图；

图4是根据本申请的计算机设备的一个实施例的结构示意图。

具体实施方式

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同；本文中在申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请；本申请的说明书和权利要求书及上述附图说明中的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。本申请的说明书和权利要求书或上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

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

请参阅图1，如图1所示，系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、电子书阅读器、MP3播放器(Moving Picture E界面显示perts Group Audio Layer III，动态影像专家压缩标准音频层面3)、MP4(Moving PictureE界面显示perts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对终端设备101、102、103上显示的页面提供支持的后台服务器。

需要说明的是，本申请实施例所提供的基于ELK的慢查询监控方法由服务器执行，相应地，基于ELK的慢查询监控装置设置于服务器中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器，本申请实施例中的终端设备101、102、103具体可以对应的是实际生产中的应用系统。

请参阅图2，图2示出本发明实施例提供的一种基于ELK的慢查询监控方法，以该方法应用在图1中的服务端为例进行说明，详述如下：

S201：配置慢查询条件，并根据慢查询条件，记录数据库执行查询处理时的基础语句以及基础语句对应的查询耗时，得到初始日志文件。

具体地，服务端对慢查询的条件进行配置，并根据该配置好的慢查询条件，对慢查询进行启用监控，记录数据库在执行查询初始时的基础语句以及基础语句对应的查询耗时，得到初始日志文件。

其中，慢查询(The slow query)是一种分析MySQL语句查询性能的方法，让MySQL记录下查询超过指定时间的语句，将查询到超过指定时间的SQL语句查询称为“慢查询”。

MySQL提供一种MySQL慢查询日志日志记录，用来记录某些查询语句，这些语句的执行时长超过了预设的阀值，也就是说指运行花费的时间超过了long_query_time的值的SQL语句，这些语句会被记录在慢查询生成的日志中。long_query_time默认预设的值是10秒，同时在默认安装的情况下，MySQL数据库默认是关闭慢查询的日志的，所以需要手动设置这个参数。对于互联网应用来说这个默认值太长，优选地，本实施例中，long_query_time设置为5秒。

慢查询日志的主要作用，可以查找出哪些查询语句的执行效率很低，以便进行优化或者解决潜在的问题。一般的建议是开启这个功能，它对服务器性能的压力可以忽略不计，但却能够记录MySQL服务器上查询花费了很长时间的sql语句。慢查询可以帮助我们定位mysql性能问题所在。

需要说的是，本实施例对应的应用场景为分布式的数据库的查询，服务端监控着集群的不同节点服务器，在该场景下，往往存在大量正在被执行的数据库查询语句，每条正在被数据库查询语句状态经常会发生变化，且存在于不同的节点服务端中，使得初始日志文件的采集成为一个难题。

S202：通过预设脚本，保存初始日志文件的状态，并周期性对状态进行检查，若状态发送变化，则获取初始日志文件中的变化数据，作为基础资源数据。

具体地，服务端通过预设脚本，对初始日志文件的状态进行记录和存储，并周期性地对状态进行检查，若发现初始日志文件的状态与存储的状态不一致，也即，状态发生变化时，获取初始日志文件中的变化数据，并将该变化数据作为基础资源数据。

优选地，预设脚本为python脚本文件。

其中，基础资源数据是指初始日志文件中记录的数据库查询语句对应的数据，包括查询语句、查询耗时和当前状态等。

S203：通过ELK系统实时接收基础资源数据，并对基础资源数据进行过滤分析，得到实时分析结果。

其中，ELK系统是ElasticSearch、日志收集框架Logstash和可视化平台Kibana组合成的日志分析管理系统的简称。

其中，Logstash是一款轻量级的日志搜集处理框架，具有方便的把分散的、多样化的日志搜集起来的特性。在本实施例中，分布式的数据库查询日志一般进行分布式存放，通过Logstash快速实现这些分布式日志文件的收集和过滤，提高数据采集效率，有利于提高慢查询监控的及时性和效率，通过Logstash进行日志文件的采集的具体实现过程具体可参考后续实施例的描述，为避免重复，此处不再赘述。

其中，ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java语言开发的，并作为Apache许可条款下的开放源码发布，是一种流行的企业级搜索引擎。ElasticSearch用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。官方客户端在Java、.NET(C#)、PHP、Python、Apache Groovy、Ruby和许多其他语言中都是可用的。根据DB-Engines的排名显示，Elasticsearch是最受欢迎的企业搜索引擎，其次是Apache Solr，也是基于Lucene。ElasticSearch是一个分布式、高扩展、高实时的搜索与数据分析引擎。它能很方便的使大量数据具有搜索、分析和探索的能力。充分利用ElasticSearch的水平伸缩性，能使数据在生产环境变得更有价值。

ElasticSearch的实现原理主要分为以下几个步骤：

A)用户将数据提交到Elastic Search数据库中；

B)通过分词控制器去将对应的语句分词，将其权重和分词结果一并存入数据；

C)当用户搜索数据时候，再根据权重将结果排名，打分，再将返回结果呈现给用户。

其中，Kibana是一个开源的分析和可视化平台，设计用于和Elasticsearch一起工作。可使用Kibana来搜索，查看，并和存储在Elasticsearch索引中的数据进行交互。可以轻松地执行高级数据分析，并且以各种图标、表格和地图的形式可视化数据。Kibana使得理解大量数据变得很容易。它简单的、基于浏览器的界面使你能够快速创建和共享动态仪表板，实时显示Elasticsearch查询的变化，在本实施例中，可以通过Kibana将得到的实时分析结果展示给服务端，以使服务端的用户直观及时对慢查询进行监控。

S204：判断实时分析结果是否达到预设预警条件，若达到，则进行预警。

具体地，根据实时分析结果与预设预警条件，判断是否需要进行预警，在实时分析结果达到预设预警条件时，执行预警处理，以便服务端管理人员及时对数据库慢查询进行处理，提高数据库慢查询的监控的及时性。

在本实施例中，通过配置慢查询条件，并根据慢查询条件，记录数据库执行查询处理时的基础语句以及基础语句对应的查询耗时，得到初始日志文件，通过预设脚本，保存初始日志文件的状态，并周期性对状态进行检查，若状态发送变化，则获取初始日志文件中的变化数据，作为基础资源数据，节约了监控所需消耗的系统资源，提高了监控的及时性，再通过ELK系统实时接收基础资源数据，并对基础资源数据进行过滤分析，得到实时分析结果，判断实时分析结果是否达到预设预警条件，在达到预设预警条件时，进行预警，实现实时对分布式数据库的慢查询进行监控，有利于提高数据库慢查询监控的效率和及时性。

在本实施例的一些可选的实现方式中，步骤S203中，从实时视频流中，获取包含当前用户的面部图像的图像集合包括：

通过ELK系统中的日志采集框架Logstash，从分布式节点中采集基础资源数据；

对基础资源数据进行过滤处理，并将过滤结果存入到搜索引擎Elasticsearch中；

通过搜索引擎Elasticsearch对过滤结果进行优化分析，得到实时分析结果，并通过可视化框架Kibana展示实时分析结果。

在本实施例中，通过ELK系统中的日志采集框架Logstash，从分布式节点中采集基础资源数据，进而对基础资源数据进行过滤处理，并将过滤结果存入到搜索引擎Elasticsearch中，再通过搜索引擎Elasticsearch对过滤结果进行优化分析，得到实时分析结果，并通过可视化框架Kibana展示实时分析结果，有利于快速将分布式的日志数据快速收集过滤并存储，进而定时进行分析，有利于提高慢查询日志文件分析的及时性和效率。

在本实施例的一些可选的实现方式中，通过ELK系统中的日志采集框架Logstash，从分布式节点中采集基础资源数据包括：

部署分布式发布订阅消息系统Kafka和日志采集框架Logstash；

通过分布式发布订阅消息系统Kafka实时从分布式节点中获取资源数据，并生成日志文件分布存储在索引序列Offset中；

使用日志采集框架Logstash定时从分布存储的索引序列Offset中获取资源数据，并将获取到的资源数据作为基础资源数据。

具体地，在本实施例中，采用进行分布式发布订阅消息系统Kafka和日志采集框架Logstash进行日志采集，位于各个节点服务器上的Logstash Agent先将数据/日志传递给Kafka，并将队列中消息或数据间接传递给Logstash，Logstash过滤、分析后将数据传递给Elasticsearch存储。最后由Kibana将日志和数据呈现给用户。因为引入了Kafka(或者Redis),所以即使远端Logstash server因故障停止运行，数据将会先被存储下来，从而避免数据丢失。

其中，Kafka集群获取到的每条消息都有一个类别，这个类别被称为Topic。不同Topic的消息分开存储，存储位置可以根据需求进行自定义并记录在Offset中，消费者只需指定消息的Topic即可获取数据而不必关心数据具体存储在哪个地方。

其中，Offset为存储位置的索引序列，Offset包括但不限于：Offset编号、消息类别、服务器IP地址、存储位置和消息时间，消息类别具体可以是查询语句的类别，或者查询语句的耗时类别等，可根据实际需求进行设定。

需要说明的是，由于Kafka采用解耦的设计思想，并非原始的发布订阅，生产者把数据推送给每个Topic，消费者从Topic中获取数据，这种方式具有如下优势：

a)生产者的负载与消费者的负载解耦。

b)消费者按照自己的需要获取数据，避免了消费者集群中产生大量没必要的垃圾数据。其中，获取数据使用Fetch方法，Fetch方法提供了获取资源数据的API接口和更强大更灵活的功能集，消费者可以根据自己的能力来获取接口，不受生产者的服务器限制。

c)消费者可以自定义消费的数量。

可以理解地，由于这些优势，使得Kafka能够实时获取并存储所有基础资源数据。

在本实施例中，在服务端署分布式发布订阅消息系统Kafka和日志分析工具Logstash，服务端通过分布式发布订阅消息系统Kafka实时获取分布式数据库上的每个查询日志，并分布式存储在索引序列中，使得资源数据的采集和存储效率得到极大提高，进一步使用日志分析工具Logstash定时对索引序列中的资源数据进行采集过滤，得到基础资源数据，实现了对资源数据的实时收集并按需要进行过滤，得到基础资源数据，在有效获取所需要的基础资源数据的同时，也避免了过多的冗余数据对数据库查询的管理效率带来的不利影响。

在本实施例的一些可选的实现方式中，使用日志采集框架Logstash定时从分布存储的索引序列Offset中获取资源数据，并将获取到的资源数据作为基础资源数据包括：

获取预设时间间隔内的索引序列Offset，作为目标索引序列；

获取目标索引序列对应的日志文件；

采用日志采集框架Logstash对日志文件进行分类，并获取与预设条件匹配的分类对应的资源数据，作为基础资源数据。

具体地，由于上述实施例中所提到的Kafka所具有的特性，使得Kafka可以实时获取并存储所有基础资源数据，出于性能方面的考虑，Logstash在处理这些基础资源数据的时候，需要预设一个时间间隔，通过获取预设时间间隔内的所有索引序列Offset来得到相关消息的记录，并对这些记录进行分类，与预设条件进行匹配，将符合预设条件的资源数据作为有效的基础资源数据。

其中，预设条件可以根据实际需求进行设定，该预设条件的目的是过滤掉与慢查询无关的日志消息。

在本实施例中，通过日志采集框架Logstash定时从分布存储的索引序列Offset中获取资源数据，实现定时对数据库的查询日志进行采集过滤，有利于提高数据库查询的日志数据的效率。

在本实施例的一些可选的实现方式中，在步骤S203之后，该基于ELK的慢查询监控方法还包括：

根据实时分析结果，构建可视化图表，其中，可视化图表包括趋势图、频数图、比重图或数据表格中的至少一个；

在可视化界面中显示可视化图表。

具体地，服务端获取数据库查询的实时分析结果后，基于该实时分析结果，构建可视化图表，将存在慢查询的资源数据，以及这些资源数据对应的耗时，以预设的显示方式进行显示，预设的显示方式包括但不限于：趋势图、频数图、比重图或数据表格等。

在本实施例中，根据实时分析结果，构建可视化图表，并在可视化界面中显示可视化图表，以便管理人员可根据可视化界面中显示的可视化图标，及时对异常情况进行处理监控，有利于提高数据库慢查询的监控效率。

在本实施例的一些可选的实现方式中，步骤S204中，预设预警条件包括第一预警范围和第二预警范围，判断实时分析结果是否达到预设预警条件，若达到，则进行预警包括：

若实时分析结果满足预设的第一预警范围，则发送预警信息；

若实时分析结果满足预设的第二预警范围，则执行相应的应急预警措施。

具体地，若服务端的通过预警脚本监测到当前获取的实时分析结果处于第一预警范围内，则向可视化界面推送预警信息，以便提醒管理人员作出相应处理，若服务端通过预警脚本监测到当前获取的实时分析结果处于第二预警范围内，则根据预先设置的实时分析结果与预警措施的对应关系，选取相应的应急预警措施自动执行。

预警信息具体可以包括处于第一预警范围的实时分析结果的内容，该实时分析结果所在的集群端中数据库查询的详细信息，以及解除该预警的优化方法等。

其中，预设的第一预警范围和预设的第二预警范围可根据实际需求进行设定，此处不做限定。

可以理解的是，若预警脚本监控到实时分析结果中的部分数据处于第二预警范围，部分数据处于第一预警范围，则按照第二预警范围进行预警处理。

在本实施例中，服务端通过预先部署的预警脚本对数据库查询的实时分析结果进行实时监控，当实时分析结果处于预设的第一预警范围或者第二预警范围时，进行相应的预警处理，实现了分级别的预警以及在数据库在大量慢查询存在的情况下，导致发生故障时能够及时采取应急措施，避免未及时发现和处理异常情况而导致数据库性能受到影响，从而有效提高了数据库慢查询的监控的效率。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

图3示出与上述实施例基于ELK的慢查询监控方法一一对应的基于ELK的慢查询监控装置的原理框图。如图3所示，该基于ELK的慢查询监控装置包括查询配置模块31、状态监控模块32、数据分析模块和预警模块34。各功能模块详细说明如下：

查询配置模块31，用于配置慢查询条件，并根据慢查询条件，记录数据库执行查询处理时的基础语句以及基础语句对应的查询耗时，得到初始日志文件；

状态监控模块32，用于通过预设脚本，保存初始日志文件的状态，并周期性对状态进行检查，若状态发送变化，则获取初始日志文件中的变化数据，作为基础资源数据；

数据分析模块33，用于通过ELK系统实时接收基础资源数据，并对基础资源数据进行过滤分析，得到实时分析结果；

预警模块34，用于判断实时分析结果是否达到预设预警条件，若达到，则进行预警。

可选地，数据分析模块33包括：

数据采集子模块，用于通过ELK系统中的日志采集框架Logstash，从分布式节点中采集基础资源数据；

数据存储子模块，用于对基础资源数据进行过滤处理，并将过滤结果存入到搜索引擎Elasticsearch中；

数据分析子模块，用于通过搜索引擎Elasticsearch对过滤结果进行优化分析，得到实时分析结果，并通过可视化框架Kibana展示实时分析结果。

可选地，数据采集子模块包括：

部署单元，用于部署分布式发布订阅消息系统Kafka和日志采集框架Logstash；

数据接收单元，用于通过分布式发布订阅消息系统Kafka实时从分布式节点中获取资源数据，并生成日志文件分布存储在索引序列Offset中；

数据采集单元，用于使用日志采集框架Logstash定时从分布存储的索引序列Offset中获取资源数据，并将获取到的资源数据作为基础资源数据。

可选地，数据采集单元包括：

索引获取子单元，用于获取预设时间间隔内的索引序列Offset，作为目标索引序列；

日志获取子单元，用于获取目标索引序列对应的日志文件；

信息分类子单元，用于采用日志采集框架Logstash对日志文件进行分类，并获取与预设条件匹配的分类对应的资源数据，作为基础资源数据。

可选地，基于ELK的慢查询监控方法还包括：

图标构建模块，用于根据实时分析结果，构建可视化图表，其中，可视化图表包括趋势图、频数图、比重图或数据表格中的至少一个；

可视化模块，用于在可视化界面中显示可视化图表。

可选地，预设预警条件包括第一预警范围和第二预警范围，预警模块40包括：

第一预警单元，用于若实时分析结果满足预设的第一预警范围，则发送预警信息；

第二预警单元，用于若实时分析结果满足预设的第二预警范围，则执行相应的应急预警措施。

关于基于ELK的慢查询监控装置的具体限定可以参见上文中对于基于ELK的慢查询监控方法的限定，在此不再赘述。上述基于ELK的慢查询监控装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

为解决上述技术问题，本申请实施例还提供计算机设备。具体请参阅图4，图4为本实施例计算机设备基本结构框图。

所述计算机设备4包括通过系统总线相互通信连接存储器41、处理器42、网络接口43。需要指出的是，图中仅示出了具有组件连接存储器41、处理器42、网络接口43的计算机设备4，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。其中，本技术领域技术人员可以理解，这里的计算机设备是一种能够按照事先设定或存储的指令，自动进行数值计算和/或信息处理的设备，其硬件包括但不限于微处理器、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程门阵列(Field－Programmable Gate Array，FPGA)、数字处理器(Digital Signal Processor，DSP)、嵌入式设备等。

所述计算机设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述计算机设备可以与用户通过键盘、鼠标、遥控器、触摸板或声控设备等方式进行人机交互。

所述存储器41至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或D界面显示存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器41可以是所述计算机设备4的内部存储单元，例如该计算机设备4的硬盘或内存。在另一些实施例中，所述存储器41也可以是所述计算机设备4的外部存储设备，例如该计算机设备4上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。当然，所述存储器41还可以既包括所述计算机设备4的内部存储单元也包括其外部存储设备。本实施例中，所述存储器41通常用于存储安装于所述计算机设备4的操作系统和各类应用软件，例如电子文件的控制的程序代码等。此外，所述存储器41还可以用于暂时地存储已经输出或者将要输出的各类数据。

所述处理器42在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器42通常用于控制所述计算机设备4的总体操作。本实施例中，所述处理器42用于运行所述存储器41中存储的程序代码或者处理数据，例如运行电子文件的控制的程序代码。

所述网络接口43可包括无线网络接口或有线网络接口，该网络接口43通常用于在所述计算机设备4与其他电子设备之间建立通信连接。

本申请还提供了另一种实施方式，即提供一种计算机可读存储介质，所述计算机可读存储介质存储有界面显示程序，所述界面显示程序可被至少一个处理器执行，以使所述至少一个处理器执行如上述的基于ELK的慢查询监控方法的步骤。

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

显然，以上所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例，附图中给出了本申请的较佳实施例，但并不限制本申请的专利范围。本申请可以以许多不同的形式来实现，相反地，提供这些实施例的目的是使对本申请的公开内容的理解更加透彻全面。尽管参照前述实施例对本申请进行了详细的说明，对于本领域的技术人员来而言，其依然可以对前述各具体实施方式所记载的技术方案进行修改，或者对其中部分技术特征进行等效替换。凡是利用本申请说明书及附图内容所做的等效结构，直接或间接运用在其他相关的技术领域，均同理在本申请专利保护范围之内。

Claims (10)

1.一种基于ELK的慢查询监控方法，其特征在于，所述基于ELK的慢查询监控方法包括：

配置慢查询条件，并根据所述慢查询条件，记录数据库执行查询处理时的基础语句以及所述基础语句对应的查询耗时，得到初始日志文件；

通过预设脚本，保存所述初始日志文件的状态，并周期性对所述状态进行检查，若所述状态发送变化，则获取所述初始日志文件中的变化数据，作为基础资源数据；

通过所述ELK系统实时接收所述基础资源数据，并对所述基础资源数据进行过滤分析，得到实时分析结果；

判断所述实时分析结果是否达到预设预警条件，若达到，则进行预警。

2.如权利要求1所述的基于ELK的慢查询监控方法，其特征在于，所述通过所述ELK系统实时接收所述基础资源数据，并对所述基础资源数据进行过滤分析，得到实时分析结果包括：

通过所述ELK系统中的日志采集框架Logstash，从分布式节点中采集所述基础资源数据；

对所述基础资源数据进行过滤处理，并将过滤结果存入到搜索引擎Elasticsearch中；

通过所述搜索引擎Elasticsearch对所述过滤结果进行优化分析，得到实时分析结果，并通过可视化框架Kibana展示所述实时分析结果。

3.如权利要求2所述的基于ELK的慢查询监控方法，其特征在于，通过所述ELK系统中的日志采集框架Logstash，从分布式节点中采集所述基础资源数据包括：

部署分布式发布订阅消息系统Kafka和所述日志采集框架Logstash；

通过所述分布式发布订阅消息系统Kafka实时从分布式节点中获取所述资源数据，并生成日志文件分布存储在索引序列Offset中；

使用所述日志采集框架Logstash定时从分布存储的索引序列Offset中获取资源数据，并将获取到的资源数据作为所述基础资源数据。

4.如权利要求3所述的基于ELK的慢查询监控方法，其特征在于，所述使用所述日志采集框架Logstash定时从分布存储的索引序列Offset中获取资源数据，并将获取到的资源数据作为所述基础资源数据包括：

获取预设时间间隔内的索引序列Offset，作为目标索引序列；

获取所述目标索引序列对应的日志文件；

采用所述日志采集框架Logstash对所述日志文件进行分类，并获取与预设条件匹配的分类对应的资源数据，作为所述基础资源数据。

5.如权利要求1所述的基于ELK的慢查询监控方法，其特征在于，在所述通过所述ELK系统实时接收所述基础资源数据，并对所述基础资源数据进行过滤分析，得到实时分析结果之后，所述基于ELK的慢查询监控方法还包括：

根据所述实时分析结果，构建可视化图表，其中，所述可视化图表包括趋势图、频数图、比重图或数据表格中的至少一个；

在可视化界面中显示所述可视化图表。

6.如权利要求1至5任一项所述的基于ELK的慢查询监控方法，其特征在于，所述预设预警条件包括第一预警范围和第二预警范围，所述判断所述实时分析结果是否达到预设预警条件，若达到，则进行预警包括：

若所述实时分析结果满足预设的第一预警范围，则发送预警信息；

若所述实时分析结果满足预设的第二预警范围，则执行相应的应急预警措施。

7.一种基于ELK的慢查询监控装置，其特征在于，所述基于ELK的慢查询监控装置包括：

查询配置模块，用于配置慢查询条件，并根据所述慢查询条件，记录数据库执行查询处理时的基础语句以及所述基础语句对应的查询耗时，得到初始日志文件；

状态监控模块，用于通过预设脚本，保存所述初始日志文件的状态，并周期性对所述状态进行检查，若所述状态发送变化，则获取所述初始日志文件中的变化数据，作为基础资源数据；

数据分析模块，用于通过所述ELK系统实时接收所述基础资源数据，并对所述基础资源数据进行过滤分析，得到实时分析结果；

预警模块，用于判断所述实时分析结果是否达到预设预警条件，若达到，则进行预警。

8.如权利要求7所述的基于ELK的慢查询监控装置，其特征在于，所述数据分析模块包括：

数据采集子模块，用于通过所述ELK系统中的日志采集框架Logstash，从分布式节点中采集所述基础资源数据；

数据存储子模块，用于对所述基础资源数据进行过滤处理，并将过滤结果存入到搜索引擎Elasticsearch中；

数据分析子模块，用于通过所述搜索引擎Elasticsearch对所述过滤结果进行优化分析，得到实时分析结果，并通过可视化框架Kibana展示所述实时分析结果。

9.一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至6任一项所述的基于ELK的慢查询监控方法。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至6任一项所述的基于ELK的慢查询监控方法。

Images