慢查询日志分析方法、系统、电子设备及计算机可读存储介质

摘要

本发明提出一种慢查询日志分析方法、系统、电子设备及计算机可读存储介质，其方法技术方案包括日志汇总步骤，将产生的慢查询日志汇总；日志分析步骤，将汇总的所述慢查询日志通过一流数据处理框架进行分析；结果获取步骤，将分析结果输出至数据库中并进行展示。本发明减少了人力劳动，可以自动化对慢查询进行分析，及结果展示，高效率且实时，可以对大量的慢查询进行快速的分析，从而尽快尽早的对查询很慢的原因进行定位。且适用广泛，凡是json类型的慢查询都可以适用。

说明书

技术领域

本发明属于数据处理领域，尤其涉及一种慢查询日志分析方法、系统、电子设备及计算机可读存储介质。

背景技术

通过日常观察检索引擎会发现各个机器的慢查询日志有每天都会慢查询产生，有时在某些情况下会有大量的慢查询产生，从而导致集群出现问题。这些慢查询一般很长，每一个慢查询基本占据三页左右的篇幅。如何实时并且快速分析这些慢查询，发现查询本身可能存在的不合理的地方，是形势所趋，同时可以辅助业务组及运维相关人员尽快解决问题，提高效率，收益也会很好。

目前针对慢查询的大多数处理方式是人工分析的方式，虽然有一些工具如Profile API以及kibana中的search profiler，但是这些工具在对大的查询进行分析时，仅仅分析一条慢查询都需要很长时间，而且最后所给出的时间分析结果，粒度过细难以分析，对解决实际中的查询慢的问题并没有太大的作用，而单纯的人工分析更加耗费人力物力。

发明内容

本申请实施例提供了一种慢查询日志分析方法、系统、电子设备及存储介质，以至少解决现有慢查询日志分析技术耗时长、效率低的问题。

第一方面，本申请实施例提供了一种慢查询日志分析方法，包括：

日志汇总步骤，将产生的慢查询日志汇总；

日志分析步骤，将汇总的所述慢查询日志通过一流数据处理框架进行分析；

结果获取步骤，将分析结果输出至数据库中并进行展示。

优选的，所述日志汇总步骤包括通过编写脚本拉取所述慢查询日志，并通过一日志传输工具将所述慢查询日志汇总输入到一发布与订阅消息系统中。

优选的，所述日志传输工具包括Logstash工具。

优选的，所述发布与订阅消息系统包括Kafka。

优选的，所述日志分析步骤包括在流数据处理框架中编程以实现统计查询体的各个key字段出现频率，并将所述各个key字段按所述出现频率降序排列。

优选的，所述日志分析步骤还包括：若所述查询体中出现query_string字段，则分析所述query_string字段的内部参数；所述内部参数包括query字段、max_determinized_states字段、fuzzy_prefix_length字段、fuzzy_max_expansions字段所对应的value值。

优选的，所述流数据处理框架包括Spark Streaming。

第二方面，本申请实施例提供了一种慢查询日志分析系统，适用于上述一种慢查询日志分析方法，包括：

日志汇总单元，将产生的慢查询日志汇总；

日志分析单元，将汇总的所述慢查询日志通过一流数据处理框架进行分析；

结果获取单元，将分析结果输出至数据库中并进行展示。

在其中一些实施例中，所述日志汇总单元包括通过编写脚本拉取所述慢查询日志，并通过一日志传输工具将所述慢查询日志汇总输入到一发布与订阅消息系统中。

在其中一些实施例中，所述日志传输工具包括Logstash工具。

在其中一些实施例中，所述发布与订阅消息系统包括Kafka。

在其中一些实施例中，所述日志分析单元包括在流数据处理框架中编程以实现统计查询体的各个key字段出现频率，并将所述各个key字段按所述出现频率降序排列。

在其中一些实施例中，所述日志分析单元还包括：若所述查询体中出现query_string字段，则分析所述query_string字段的内部参数；所述内部参数包括query字段、max_determinized_states字段、fuzzy_prefix_length字段、fuzzy_max_expansions字段所对应的value值。

第三方面，本申请实施例提供了一种电子设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面所述的一种慢查询日志分析方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述第一方面所述的一种慢查询日志分析方法。

相比于相关技术，本申请实施例提供的一种慢查询日志分析方法：

1、减少了人力劳动，可以自动化对慢查询进行分析及结果展示；

2、高效率且实时，可以对大量的慢查询进行快速的分析，从而尽快尽早的对查询很慢的原因进行定位；

3、通用性，适用广泛，凡是json类型的慢查询(一般DSL查询都是Json格式)，无论是哪种业务，都可以适用。

本申请的一个或多个实施例的细节在以下附图和描述中提出，以使本申请的其他特征、目的和优点更加简明易懂。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的慢查询日志分析方法流程图；

图2是根据本申请实施例中的慢查询日志分析系统的框架图；

图3是根据本申请实施例的电子设备的框架图；

以上图中：

11、日志汇总单元；12、日志分析单元；13、结果获取单元；20、总线；21、处理器；22、存储器；23、通信接口。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行描述和说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。基于本申请提供的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。此外，还可以理解的是，虽然这种开发过程中所作出的努力可能是复杂并且冗长的，然而对于与本申请公开的内容相关的本领域的普通技术人员而言，在本申请揭露的技术内容的基础上进行的一些设计，制造或者生产等变更只是常规的技术手段，不应当理解为本申请公开的内容不充分。

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

除非另作定义，本申请所涉及的技术术语或者科学术语应当为本申请所属技术领域内具有一般技能的人士所理解的通常意义。本申请所涉及的“一”、“一个”、“一种”、“该”等类似词语并不表示数量限制，可表示单数或复数。本申请所涉及的术语“包括”、“包含”、“具有”以及它们任何变形，意图在于覆盖不排他的包含；例如包含了一系列步骤或模块(单元)的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可以还包括没有列出的步骤或单元，或可以还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

通过日常观察检索引擎会发现各个机器的慢查询日志有每天都会慢查询产生，有时在某些情况下会有大量的慢查询产生，从而导致集群出现问题。这些慢查询一般很长，每一个慢查询基本占据三页左右的篇幅。如何实时并且快速分析这些慢查询，发现查询本身可能存在的不合理的地方，是形势所趋，同时可以辅助业务组及运维相关人员尽快解决问题，提高效率，收益也会很好。

目前针对慢查询的大多数处理方式是人工分析的方式，虽然有一些工具如Profile API以及kibana中的search profiler，但是这些工具在对大的查询进行分析时，仅仅分析一条慢查询都需要很长时间，而且最后所给出的时间分析结果，粒度过细难以分析，对解决实际中的查询慢的问题并没有太大的作用。而单纯的人工分析更加耗费人力物力。

在通过人工方式处理慢查询时，由于对慢查询语言的不熟悉，因此耗时耗力；借助分析工具进行分析也存在耗时长、效率低等多种问题，在解决实际慢查询问题时没有收效，因此本申请实施例提出了一种慢查询日志分析方法、系统、电子设备及存储介质，本申请实施例可应用于Elasticsearch。

以下对本发明涉及到的部分专业术语进行说明：

Elasticsearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java语言开发的，并作为Apache许可条款下的开放源码发布，是一种流行的企业级搜索引擎。Elasticsearch用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。官方客户端在Java、.NET(C#)、PHP、Python、ApacheGroovy、Ruby和许多其他语言中都是可用的。根据DB-Engines的排名显示，Elasticsearch是最受欢迎的企业搜索引擎，其次是Apache Solr，也是基于Lucene。

分析数据库语句查询性能的方法除了使用EXPLAIN输出执行计划，还可以让数据库记录下查询超过指定时间的语句，我们将超过指定时间的数据库语句查询称为“慢查询”。

Logstash是一个应用程序日志、事件的传输、处理、管理和搜索的平台。可以用它来统一对应用程序日志进行收集管理，提供Web接口用于查询和统计。

Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。这种动作(网页浏览，搜索和其他用户的行动)是在现代网络上的许多社会功能的一个关键因素。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。对于像Hadoop一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消息。

Spark Streaming是Spark核心API的一个扩展，可以实现高吞吐量的、具备容错机制的实时流数据的处理。Spark Streaming支持从多种数据源获取数据，包括Kafka、Flume、Twitter、ZeroMQ、Kinesis以及TCP Sockets。从数据源获取数据之后，可以使用诸如map、reduce、join和window等高级函数进行复杂算法的处理，最后还可以将处理结果存储到文件系统、数据库和现场仪表盘中。在Spark统一环境的基础上，可以使用Spark的其他子框架，如机器学习、图计算等，对流数据进行处理。

本申请实施例所提出的慢查询日志分析方法避免了人工分析的费时费力、低效率，所涉及慢查询相关内容基本齐全，可以对大多数慢查询日志的内容进行具体分析，快速协助业务组及运维相关人员进行问题定位，其次，结合了Spark Streaming后，可以实现实时快速对大量的慢查询进行分析。

请参见图1，为本申请实施例的慢查询日志分析方法流程图，包括如下步骤：

S101.将产生的慢查询日志汇总；

S102.将汇总的所述慢查询日志通过一流数据处理框架进行分析；

S103.将分析结果输出至数据库中并进行展示。

需要说明的是，在上述流程中或者附图的流程图中示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

Elasticsearch集群中每台Datanode节点的机器都会在每天的不固定时刻产生一些慢查询，并将其存到特定目录下的日志文件中。其中，所述日志汇总步骤包括通过编写脚本拉取所述慢查询日志，并通过一日志传输工具将所述慢查询日志汇总输入到一发布与订阅消息系统中。通过编写一个get_slowlog.sh脚本可以做到实时自动检查并拉取各个机器新产生的的慢查询日志。

其中，所述日志传输工具包括Logstash工具，所述发布与订阅消息系统包括Kafka。在本申请实施例中，脚本拉取的慢查询日志借助Logstash将其汇总输入到Kafka中。

其中，所述日志分析步骤包括在流数据处理框架中编程以实现统计查询体的各个key字段出现频率，并将所述各个key字段按所述出现频率降序排列。

其中，所述日志分析步骤还包括：若所述查询体中出现query_string字段，则分析所述query_string字段的内部参数；所述内部参数包括query字段、max_determinized_states字段、fuzzy_prefix_length字段、fuzzy_max_expansions字段所对应的value值。

其中，其特征在于，所述流数据处理框架包括Spark Streaming。为了实现高吞吐量的、具备容错机制的实时流数据的处理，选择使用Spark Streaming，在Spark Streaming内编程实现慢查询的分析功能，将分析的结果存入database(数据库)，最终展示在web页面上。

本申请实施例的核心是在Spark Streaming上实现对慢查询的分析。因为对于慢查询来说，即Elasticsearch Query DSL查询，它包含多种搜索及过滤方式，当一个查询体很大的时候，往往会涉及到各式各样的查询，而其中某些的查询方式是很耗时的，具体包括如下：

(1)match_phrase_prefix查询：会对最后一个Token在倒排序索引列表中进行通配符搜索。其中重要参数：模糊匹配数控制：max_expansions其默认值为50，最小值为1。这种查询方式一般不推荐，因为进行通配符搜索不确定性因素很大，是很耗时的；

(2)wildcard查询：此种方式在关键词首尾加上通配符进行模糊搜索，如果所输入的字符串长度没有做限制，此查询就会很慢，非常消耗CPU；

(3)script查询：在使用脚本语言查询时需要好好评估自己所写的脚本，如果用其计算动态字段等某些操作，将会非常耗费资源，减慢整个系统；

(4)query_string查询：此查询正常使用没有问题，但其内部的多个参数需要在使用前认真进行评估。

综上所述，本申请实施例重点关注上述字段出现的情况，同时，也需要关注其它字段，如：是否进行了多次过滤，换言之，filter出现次数是否足够多(因为在查询前进行过滤可以大大加快查询速度)。

具体的，本申请实施例日志分析步骤统计这个查询体的各个key字段出现的次数，例如query、filter、bool、term等出现的次数，并按照count由大到小排序，在上述字段中，重点关注filter、match_phrase_prefix、wildcard、script、query_string五个字段出现的频率。

当query_string字段出现，需要再单独分析query_string它内部的参数，主要涉及query、max_determinized_states、fuzzy_prefix_length、fuzzy_max_expansions这四个字段所对应的value值；对于query字段来说，统计它内部OR、AND及NOT出现的总次数，用来侧面反映这个查询涉及了多少个关键词的查询；对于max_determinized_states字段，判断其值是不是过大，限制过于复杂的正则表达式；对于fuzzy_prefix_length字段，判断其值是不是过小，如果太小则模糊搜索就会很大，会拖慢查询；对于fuzzy_max_expansions字段，判断其值是不是过大，太大也会导致模糊搜索内容过多，从而耗时长。

在本申请实施例中，步骤S103将一些超过预设定指标的结果进行标黄或标红，从而更直观的展示.

本申请实施例提供了一种慢查询日志分析系统，适用于上述的一种慢查询日志分析方法。如以下所使用的，术语“模块”、“单元”、“子单元”等可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件、或者软件和硬件的组合的实现也是可能并被构想的。

图2为根据本申请实施例中的慢查询日志分析系统的框架图，包括日志获取单元11、日志分析单元12、结果获取单元13，其中：

日志汇总单元11，将产生的慢查询日志汇总；

日志分析单元12，将汇总的所述慢查询日志通过一流数据处理框架进行分析；

结果获取单元13，将分析结果输出至数据库中并进行展示。

在其中一些实施例中，Elasticsearch集群中每台Datanode节点的机器都会在每天的不固定时刻产生一些慢查询，并将其存到特定目录下的日志文件中。其中，所述日志汇总步骤包括通过编写脚本拉取所述慢查询日志，并通过一日志传输工具将所述慢查询日志汇总输入到一发布与订阅消息系统中。通过编写一个get_slowlog.sh脚本可以做到实时自动检查并拉取各个机器新产生的的慢查询日志。

在其中一些实施例中，所述日志传输工具包括Logstash工具。

在其中一些实施例中，所述发布与订阅消息系统包括Kafka。

在本申请实施例中，脚本拉取的慢查询日志借助Logstash将其汇总输入到Kafka中。

在其中一些实施例中，所述日志分析单元包括在流数据处理框架中编程以实现统计查询体的各个key字段出现频率，并将所述各个key字段按所述出现频率降序排列。

在其中一些实施例中，所述日志分析单元还包括：若所述查询体中出现query_string字段，则分析所述query_string字段的内部参数；所述内部参数包括query字段、max_determinized_states字段、fuzzy_prefix_length字段、fuzzy_max_expansions字段所对应的value值。

具体的，本申请实施例日志分析步骤统计这个查询体的各个key字段出现的次数，例如query、filter、bool、term等出现的次数，并按照count由大到小排序，在上述字段中，重点关注filter、match_phrase_prefix、wildcard、script、query_string五个字段出现的频率。

当query_string字段出现，需要再单独分析query_string它内部的参数，主要涉及query、max_determinized_states、fuzzy_prefix_length、fuzzy_max_expansions这四个字段所对应的value值；对于query字段来说，统计它内部OR、AND及NOT出现的总次数，用来侧面反映这个查询涉及了多少个关键词的查询；对于max_determinized_states字段，判断其值是不是过大，限制过于复杂的正则表达式；对于fuzzy_prefix_length字段，判断其值是不是过小，如果太小则模糊搜索就会很大，会拖慢查询；对于fuzzy_max_expansions字段，判断其值是不是过大，太大也会导致模糊搜索内容过多，从而耗时长。

需要说明的是，上述各个单元可以是功能单元也可以是程序单元，既可以通过软件来实现，也可以通过硬件来实现。对于通过硬件来实现的单元而言，上述各个单元可以位于同一处理器中；或者上述各个单元还可以按照任意组合的形式分别位于不同的处理器中。

另外，结合图1描述的本申请实施例一种慢查询日志分析方法可以由电子设备来实现。图3为根据本申请实施例的电子设备的硬件结构示意图。

电子设备可以包括处理器21以及存储有计算机程序指令的存储器22。

具体地，上述处理器21可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，简称为ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

其中，存储器22可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器22可包括硬盘驱动器(Hard Disk Drive，简称为HDD)、软盘驱动器、固态驱动器(SolidState Drive，简称为SSD)、闪存、光盘、磁光盘、磁带或通用串行总线(Universal SerialBus，简称为USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器22可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器22可在数据处理装置的内部或外部。在特定实施例中，存储器22是非易失性(Non-Volatile)存储器。在特定实施例中，存储器22包括只读存储器(Read-Only Memory，简称为ROM)和随机存取存储器(RandomAccess Memory，简称为RAM)。在合适的情况下，该ROM可以是掩模编程的ROM、可编程ROM(Programmable Read-Only Memory，简称为PROM)、可擦除PROM(Erasable ProgrammableRead-Only Memory，简称为EPROM)、电可擦除PROM(Electrically Erasable ProgrammableRead-Only Memory，简称为EEPROM)、电可改写ROM(Electrically Alterable Read-OnlyMemory，简称为EAROM)或闪存(FLASH)或者两个或更多个以上这些的组合。在合适的情况下，该RAM可以是静态随机存取存储器(Static Random-Access Memory，简称为SRAM)或动态随机存取存储器(Dynamic Random Access Memory，简称为DRAM)，其中，DRAM可以是快速页模式动态随机存取存储器(Fast Page Mode Dynamic Random Access Memory，简称为FPMDRAM)、扩展数据输出动态随机存取存储器(Extended Date Out Dynamic RandomAccess Memory，简称为EDODRAM)、同步动态随机存取内存(Synchronous Dynamic Random-Access Memory，简称SDRAM)等。

存储器22可以用来存储或者缓存需要处理和/或通信使用的各种数据文件，以及处理器21所执行的可能的计算机程序指令。

处理器21通过读取并执行存储器22中存储的计算机程序指令，以实现上述实施例中的任意一种慢查询日志分析方法。

在其中一些实施例中，电子设备还可包括通信接口23和总线20。其中，如图2所示，处理器21、存储器22、通信接口23通过总线20连接并完成相互间的通信。

通信端口23可以实现与其他部件例如：外接设备、图像/数据采集设备、数据库、外部存储以及图像/数据处理工作站等之间进行数据通信。

总线20包括硬件、软件或两者，将电子设备的部件彼此耦接在一起。总线20包括但不限于以下至少之一：数据总线(Data Bus)、地址总线(Address Bus)、控制总线(ControlBus)、扩展总线(Expansion Bus)、局部总线(Local Bus)。举例来说而非限制，总线20可包括图形加速接口(Accelerated Graphics Port，简称为AGP)或其他图形总线、增强工业标准架构(Extended Industry Standard Architecture，简称为EISA)总线、前端总线(FrontSide Bus，简称为FSB)、超传输(Hyper Transport，简称为HT)互连、工业标准架构(Industry Standard Architecture，简称为ISA)总线、无线带宽(InfiniBand)互连、低引脚数(Low Pin Count，简称为LPC)总线、存储器总线、微信道架构(Micro ChannelArchitecture，简称为MCA)总线、外围组件互连(Peripheral Component Interconnect，简称为PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(Serial AdvancedTechnology Attachment，简称为SATA)总线、视频电子标准协会局部(Video ElectronicsStandards Association Local Bus，简称为VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线20可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

该电子设备可以执行本申请实施例中的一种慢查询日志分析方法。

另外，结合上述实施例中的一种慢查询日志分析方法，本申请实施例可提供一种计算机可读存储介质来实现。该计算机可读存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现上述实施例中的任意一种慢查询日志分析方法。

而前述的存储介质包括：U盘、移动硬盘、只读存储器(ReadOnly Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。