共计 4164 个字符，预计需要花费 11 分钟才能阅读完成。
TiDB 慢日志在伴鱼的实际
作者简介：刘江，伴鱼英语数据库负责人，TUG 2020 年度 MOA。负责伴鱼数据库运维、大数据运维以及数据库平台化建设。
本文来自于伴鱼英语 DBA 组负责人刘江在「能量钛」第二期流动的分享，刘江为大家分享了 TiDB 慢日志在伴鱼的实际。本文将从以下三个方面开展：
- 第一局部是 背景与需要，首先介绍伴鱼做 TiDB 慢日志零碎的背景，以及基于这个背景，要把慢日志零碎做成什么样子；
- 第二局部介绍下 慢日志零碎 具体是怎么做的；
- 第三局部通过几个 线上案例，看看慢日志零碎是如何定位线上问题的。
背景与需要
往年上半年，阿里云公布了新一代 DAS（数据库自治服务）服务，外面谈到数据库的问题，90% 以上的问题都是来源于数据库的 异样申请。其实在咱们日常的数据库问题场景，大部分的问题也都是异样 SQL 申请，像数据库的 bug 或者是机器导致的故障问题，平时遇到还是绝对较少的。对于异样 SQL 的定位，数据库的慢日志剖析，是一种特地无效的伎俩。
那么咱们在平时利用慢日志剖析问题的时候，会有哪些痛点？在做慢日志零碎之前，集群的慢日志是散布在多台机器下面的，如果数据库呈现了问题，就须要登录到多台机器一台台的去剖析，问题解决的效率很低。特地是当集群规模特地大的时候，基本上没方法去疾速定位问题。
当然，TiDB 在 4.0 版本反对了 Dashboard，咱们能够通过 Dashboard 查看整个集群的慢日志信息，比方最近 15 分钟的或者最近半个小时的慢日志。但当零碎真正呈现问题的时候，慢日志会特地多，Dashboard 会面临 计算加载 等性能问题，同时 Dashboard 不反对检索和剖析统计，这不利于咱们疾速定位到异样 SQL。
TiDB 零碎库自带了一张表 （INFORMATION_SCHEMA.SLOW_QUERY） 来实时存储慢日志，咱们也能够通过它来定位异样 SQL，但这张表是一个关系型的表，自身是没有索引的，当日志量特地大的时候，多维检索和剖析是特地慢的。同时，对于关系型表的多维检索和剖析统计，也不是它所善于的。
基于以上的痛点，伴鱼的慢日志零碎须要满足以下几个需要：
首先，就是慢日志集中式收集，可能把线上多个集群甚至几十个集群的慢日志全副收拢在一起，便于集中剖析，这样做 入口 就对立 了。
其次，要保障收集的慢日志是 准实时 的。因为如果收集的慢日志提早太大的话，对于解决线上问题和剖析问题是没有帮忙的。
而后，慢日志能够 检索和统计分析。因为当呈现问题的时候慢日志是特地多的，这个时候如果可能检索和统计分析的话，就能够疾速定位到异样 SQL。
最初，慢日志零碎须要反对 监控和告警。
零碎详解
基于以上的背景和需要，咱们来看一下伴鱼的慢日志零碎是怎么做的。
零碎架构
伴鱼慢日志零碎 整体架构 ，如下图所示。咱们在 TiDB Server 机器初始化时部署了 Filebeat 组件，通过它把采集的慢日志，写入到 Kafka，同时打上机器 IP 信息。而后通过 logstash 解析出咱们关注的字段，存储到 ES。ES 自身是一个搜索引擎，做数据的剖析和统计，速度是特地快的。同时咱们通过 Kibana 查看 ES 里的慢日志数据，做 可视化 的统计和检索。
当然，慢日志零碎还有一种架构，如下图所示。Clickhouse 是最近几年比拟火的剖析型数据库，有些公司通过把监控数据发送到 Clickhouse，做 实时监控和告警剖析 。咱们能够用 Flink 替换 logstash 组件，通过简略的计算，把慢日志数据写入到 Clickhouse。
因为伴鱼的慢日志零碎做得比拟早，所以采纳的是 ELK 的架构。
首先，Filebeat 足够 轻量。咱们在线上对几百兆文件做过解析测试，论断是对数据库的性能基本上没有影响。
其次，当线上呈现问题时，刹时的日志量是特地大的，如果把慢日志间接写入到 Logstash，会对 Logstash 机器负载造成冲击，所以通过 Kafka 来消峰。
当 Logstash 解析慢日志的时候，应尽量少用含糊匹配的规定。因为用含糊匹配的规定去解析慢日志，会导致机器 CPU 飙高的问题。
而后，ES 索引自身就是 Schema Free 的，而后加上倒排索引这种数据结构，这种个性非常适合统计分析类场景。
同时，通过 Kibana 做可视化检索和统计分析。
最初，咱们每 2 分钟读取一次 ES 的慢日志数据，做监控报警。
日志采集
接下来看一下每个组件的细节，右边是 Filebeat 采集的配置，如下图所示。咱们在部署 Filebeat 的时候，会把部署机器的 IP 给传进去，这样在前期统计的时候，就晓得慢日志是来源于哪台机器。而后左边是 Kafka 的配置，数据收集好之后，会发送到 Kafka 集群。
上面是一条 TiDB 慢日志的示例，格局是这样的。
慢日志以 Time 结尾，带有 Query_time，Total_keys，Process_keys，DB 等字段，最初还有 SQL 的信息。这条慢日志在通过 Filebeat 的采集之后，会变成上面这样的一行文本，如下图所示。如果把这行文本间接存到 ES 的话，是没方法去做检索和统计分析的。
字段筛选
一条文本没法做统计分析和多维检索的，如果咱们要做，就须要把这行文本外面的 字段解析 进去，那么咱们关注哪些字段呢？首先来看一下 MySQL 5.7 的慢日志，如下图所示。咱们在解决 MySQL 故障的时候，首先会看一条 SQL 的查问工夫，如果改 SQL 查问工夫比拟长，咱们认为它可能会是导致线上问题的起因。
然而当线上申请量比拟大的时候，查问工夫长并不能代表它就是呈现问题的根本原因，还要联合其余关键字来综合剖析。比方慢日志里一个特地重要的关键字 Rows_examined，Rows_examined 代表了数据逻辑扫描的行数，通常咱们通过 Query_time 和 Rows_examined 综合剖析，才能够定位问题 SQL。
接下来，咱们看一下 TiDB 的慢日志。首先来看一下 TiDB 3.0.13 走 KV 接口的慢日志，如下图所示。这里有一些比拟重要的关键字，比如说 Query_time，DB，SQL 和 Prewrite_time，这些关键字对于定位线上问题是很有帮忙的。
上面是另外一种格局的 TiDB 3.0.13 的慢日志，它是走 DistSQL 接口的，如下图所示。
它除了把 Query_time、Total_keys 同时打印进去之后，还有 Index_names，代表这条 SQL 有没有走索引，同时 Index_names 字段外面还有表名等信息。
看完了 TiDB 3.0.13 的慢日志，咱们再来看一下 TiDB 4.0.13 的慢日志，慢日志内容相比 TiDB 3.0.13 版本又减少了一些字段，比方 KV_total，PD_total，Backoff_total 等信息。
通过下面的慢日志，咱们能够发现其中蕴含了很多要害信息，咱们甚至能够看到申请慢在数据库的哪个环节。如果咱们把慢日志收集起来，通过某些关系进行检索，甚至聚合，对于发现问题是很有帮忙的。
在伴鱼，咱们关注的 TiDB 慢日志字段次要有以下几个：
- TiDB IP：在部署 Filebeat 的时候，会把机器的 IP 给传进去。有了这个 IP，咱们能够晓得日志的起源以及依照 IP 的维度进行统计；
- DB：执行语句时应用的 DATABASE。咱们能够依照 DB 维度进行统计，同时也能够通过外部零碎将 DB 和具体的数据库集群映射起来；
- TABLE：有些慢日志是能够解析出表名的，可依照表的维度进行统计；
- IDX_NAME：除 Insert 语句 和走 KV 接口的语句外，慢日志信息记录了语句有没有走索引；
- TOTAL_KEYS：Coprocessor 扫过的 Key 的数量；
- PROCESS_KEYS：Coprocessor 解决的 Key 的数量；
- QUERY_TIME：语句执行的工夫；
- SQL：具体的 SQL 语句。
字段解析
通过 Logstash 的 Grok 语法将一条慢日志所须要的字段解析进去，如下图所示。
统计分析
上面这个图是咱们所有集群在最近 30 分钟之内的慢日志状况。咱们通过 Kibana，能够看到慢日志的总条数，能够通过 DB、Quwry_time、Total_keys 来进行检索，还能够按 DB、Table、IP 等维度进行统计。这样可能极大地提高定位问题 SQL 的效率。
除了通过 Kibana 进行可视化检索和聚合之外，咱们外部平台零碎也会通过慢日志的各种维度去进行聚合和排序，聚合维度包含 集群，库、表、IP 和操作类型 等，排序规定能够依照 总耗时，均匀耗时，最大耗时和日志条数 等维度。咱们能够定期向研发发送慢日志报表。
监控告警
除了可视化检索和统计分析之外，咱们还对慢日志做了监控和告警，如下图所示。通过统计每个库下的慢 SQL 条数，每个库设置 两种告警规定。比如说 advertising 这个库，通用的规定是执行工夫超过 200 毫秒，告警阀值达到 5 条的会告警。
然而咱们发现线上也存在执行频率特地低，然而执行工夫特地长的状况，就没方法通过通用的规定去笼罩。所以前面又加了一条规定：执行工夫超过 500 毫秒 ，告警阀值达到 2 条就告警。这样对于线上的慢 SQL 就基本上全笼罩了。
告警信息 ，如下图所示。能够看一下右边的这张图，咱们采集了慢日志的 DB 字段，通过外部零碎把 DB 和数据库集群关联起来，咱们能够看到慢日志产生在哪个集群，哪个库。慢日志产生的时候，这些慢日志超过了多少 阀值，总的 SQL 执行工夫以及均匀工夫等信息，通过这样的慢日志告警信息，咱们能在短时间内判断问题 SQL 对线上的冲击有多大。
案例分享
讲完了慢日志零碎是怎么做的，接下来来看一下咱们是如何通过慢日志零碎去发现线上问题。
第一个案例，如下图所示。咱们在某天发现集群的 Coprocessor CPU 下来了，同时对应着左边的延时也下来了，通过慢日志零碎很快就能发现问题 SQL，它的 Total_keys 和 Process_keys 耗得比拟多，另外它的 index_name 是空的，阐明它没有走到索引。咱们通过给这条 SQL 加上索引，性能问题就疾速地解决了。
第二个案例也相似，咱们发现 Coprocessor CPU 指标下来了，而后通过慢日志零碎检索一下，就能发现 SQL 没有索引。定位问题的速度很快，因为通过 ES 去进行聚合和检索是特地快的。
总结
以上是伴鱼慢日志零碎在性能问题发现和预防数据库性能危险等方面的一些教训，心愿对大家有所帮忙。将来，咱们将持续开掘慢日志的信息，丰盛慢日志零碎的性能，为伴鱼数据库保驾护航。