从 0 到 1 搭建技术中台之慢日志系统

自去年开始，中台话题的热度不减，很多公司都投入到中台的建设中，从战略制定、组织架构调整、协作方式变动到技术落地实践，每个环节都可能出现各种各样的问题。技术中台最坏的状况是技术能力太差，不能支撑业务的发展，其次是技术脱离业务，不能服务业务的发展。前者是能力问题，后者是意识问题。在本专题中，伴鱼技术团队分享了从 0 到 1 搭建技术中台的过程及心得。

1. 背景

伴鱼少儿英语是目前飞速成长的互联网在线英语教育品牌之一，特别在疫情这段时间内，业务量增长近 3-4 倍。这期间，伴鱼慢日志系统对于帮助我们及时发现数据库性能问题、预防数据库性能风险和维护线上服务稳定性起到了很大的作用。

目前，伴鱼有 10 套 TiDB 数据库，20+套 MongoDB 数据库，近 200+数据库实例。日常数据库性能问题处理，需要分析数据库慢日志，由于慢日志分散在多台机器，我们面临日志查询/分析/统计等各种不便。因此，我们设计了伴鱼慢日志系统并满足以下几个要求：

• 慢日志集中准实时收集

• 日志查询/分析/统计可视化

• 慢日志定时报表

• 慢日志灵活告警

下面详细介绍下伴鱼慢日志系统设计以及系统给我们带来的实实在在的效果。

2. 慢日志系统详解

我们认为数据库的性能问题，绝大部分原因都是由慢 SQL 导致的，当然像数据库 bug、业务异常流量等情况，在伴鱼还是比较少见的。所以，伴鱼慢日志系统主要围绕如何准实时收集分布式 TiDB 的慢日志、如何快速的做分析统计、定时向业务推送慢日志报表以及如何灵活的告警等方面进行设计。

2.1 准实时集中收集慢日志

我们采用了业界比较成熟的开源日志采集、分析、存储和展示架构，如下图所示。

其中，每个组件的功能如下：

• filebeat 负责增量收集 TiDB 产生的慢日志，由于 filebeat 比较轻量，对线上性能基本无影响。

• kafka 负责缓冲存储 filebeat 采集的原始日志

• logstash 负责把原始日志解析成我们想要的键值对

• es 负责存储经过 logstash 加工后的数据

• kibana 负责数据的查询/分析/统计的可视化

filebeat 采集 TiDB 的慢日志配置，如下图所示。

原始慢日志经过 filebeat 采集阶段简单处理后存储到 kafka，原始慢日志如下图所示。

存储到 kafka 的慢日志部分内容格式，如下图所示。

日志存储到 kafka 后，logstash 负责读取其中的慢日志并进行解析，转换成我们想要的 kv 键值对，如下图所示。

对于 TiDB 的慢日志，我们重点关注慢日志中的某些字段，比如：

index_name: 语句执行过程中是否用到索引DB：表示执行语句时使用的databasequery_time：表示执行这个语句花费的时间total_keys：表示Coprocessor扫过的key的数量process_keys：表示Coprocessor处理的key的数量sql：执行的sql语句

解析后的数据最终存储到到 es，供 kibana 查询、分析以及统计使用。

2.2 慢日志查询分析统计的可视化

慢日志通过 logstash 解析入到 es 后，通过 kibana，我们可以把解析的字段作为查询和聚合的条件，很方便的对慢日志数据进行分析统计。

比如我们经常有如下操作：

• 5 分钟内，慢请求分别按照 db 和 table 聚合

• 5 分钟内，Process_keys 大于 5000 的慢请求

• 5 分钟内，query_time 大于 200ms 的请求

通过近似数据库表查询操作，我们能对慢日志进行多维度的分析，及时探究线上的性能问题。当然操作远不止这些，研发同学还可以在 kibana 平台上定制所属业务 db 慢日志的趋势图、配置告警等。

2.3 定时发送慢日志报表

在伴鱼，通常一个服务对应一个 DB，并且要求 db 名和服务名相同，每个服务有明确的业务负责人（owner） 和服务等级以及所属的具体的业务组，如下图所示。所以根据 DB，可以将慢日志告警和报表推送给具体的业务负责人。

基于加工后的慢日志数据，从多种维度，比如集群、库、表、操作类型、慢日志数量、执行总时间、平均响应时间以及最大耗时等维度对慢日志进行分析统计，并生成报表定时发送给研发同学。

2.4 慢日志灵活告警

在伴鱼，一个 db 对应一个服务，所以告警都是在特定 db 下设置规则。目前，我们告警时间粒度默认是一分钟(粒度可以灵活控制)，主要基于以下三类规则进行告警。

• 某个 db 下的请求时间达到 100ms 且慢日志达到一定数量则告警

• 某个 db 下的请求时间达到 500ms 且慢日志达到一定数量则告警

• 某个 db 下的请求 Process_keys 大于 5000 且慢日志达到一定数量则告警

告警规则的设置不是一蹴而就的，需要根据不同的业务场景，dba 和研发不断的调整，最终达到一个比较合理的阀值。

3. 慢日志系统给带来的收益

目前，我们 10 个生产 TiDB 集群，有 6 个核心集群请求过万，如下图所示。

慢日志系统主要给我们线上服务带来 3 个收益。

• 响应延时低，6 个请求过万核心集群，999 线基本维持在 16ms 左右，如下图所示

• 慢日志越来越少，tidb 所有集群的慢日志(大于 200ms)，30 分钟内，高峰期条数基本维持在 1000 以内

• 故障少，除一次 tidb 优化器 bug 导致大表查询故障，影响线上近 15 分钟外。近半年没有 tidb 引发的线上故障。

4. 总结

目前，伴鱼慢日志系统在性能问题发现和预防数据库性能风险等方面发挥了很重要的作用。未来，我们将继续挖掘慢日志里的信息，丰富慢日志系统的功能，为伴鱼数据库保驾护航。

相关文章推荐：

《从 0 到 1 搭建技术中台之推送平台实践：高吞吐、低延迟、多业务隔离的设计与实现》

《从 0 到 1 搭建技术中台之技术文化篇》

《从 0 到 1 搭建技术中台之协作方式篇》

《从 0 到 1 搭建技术中台之报警平台实践：匹配器演进》

《从 0 到 1 搭建技术中台之发布系统实践：集泳道、灰度、四端和多区域于一体的设计与权衡》

《从 0 到 1 搭建技术中台之 A / B Testing 平台实践》

《从 0 到 1 搭建技术中台之组织架构篇》