1. 背景
伴鱼少儿英语是目前飞速成长的互联网在线英语教育品牌之一，特别在疫情这段时间内，业务量增长近 3-4 倍。这期间，伴鱼慢日志系统对于帮助我们及时发现数据库性能问题、预防数据库性能风险和维护线上服务稳定性起到了很大的作用。
目前，伴鱼有 10 套 TiDB 数据库，20+套 MongoDB 数据库，近 200+数据库实例。日常数据库性能问题处理，需要分析数据库慢日志，由于慢日志分散在多台机器，我们面临日志查询/分析/统计等各种不便。因此，我们设计了伴鱼慢日志系统并满足以下几个要求：
下面详细介绍下伴鱼慢日志系统设计以及系统给我们带来的实实在在的效果。
2. 慢日志系统详解
我们认为数据库的性能问题，绝大部分原因都是由慢 SQL 导致的，当然像数据库 bug、业务异常流量等情况，在伴鱼还是比较少见的。所以，伴鱼慢日志系统主要围绕如何准实时收集分布式 TiDB 的慢日志、如何快速的做分析统计、定时向业务推送慢日志报表以及如何灵活的告警等方面进行设计。
2.1 准实时集中收集慢日志
我们采用了业界比较成熟的开源日志采集、分析、存储和展示架构，如下图所示。
其中，每个组件的功能如下：
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，我们可以把解析的字段作为查询和聚合的条件，很方便的对慢日志数据进行分析统计。
比如我们经常有如下操作：
通过近似数据库表查询操作，我们能对慢日志进行多维度的分析，及时探究线上的性能问题。当然操作远不止这些，研发同学还可以在 kibana 平台上定制所属业务 db 慢日志的趋势图、配置告警等。
2.3 定时发送慢日志报表
在伴鱼，通常一个服务对应一个 DB，并且要求 db 名和服务名相同，每个服务有明确的业务负责人（owner） 和服务等级以及所属的具体的业务组，如下图所示。所以根据 DB，可以将慢日志告警和报表推送给具体的业务负责人。
基于加工后的慢日志数据，从多种维度，比如集群、库、表、操作类型、慢日志数量、执行总时间、平均响应时间以及最大耗时等维度对慢日志进行分析统计，并生成报表定时发送给研发同学。
2.4 慢日志灵活告警
在伴鱼，一个 db 对应一个服务，所以告警都是在特定 db 下设置规则。目前，我们告警时间粒度默认是一分钟(粒度可以灵活控制)，主要基于以下三类规则进行告警。
告警规则的设置不是一蹴而就的，需要根据不同的业务场景，dba 和研发不断的调整，最终达到一个比较合理的阀值。
3. 慢日志系统给带来的收益
目前，我们 10 个生产 TiDB 集群，有 6 个核心集群请求过万，如下图所示。
慢日志系统主要给我们线上服务带来 3 个收益。
4. 总结
目前，伴鱼慢日志系统在性能问题发现和预防数据库性能风险等方面发挥了很重要的作用。未来，我们将继续挖掘慢日志里的信息，丰富慢日志系统的功能，为伴鱼数据库保驾护航。
《从 0 到 1 搭建技术中台之推送平台实践：高吞吐、低延迟、多业务隔离的设计与实现》
《从 0 到 1 搭建技术中台之技术文化篇》
《从 0 到 1 搭建技术中台之协作方式篇》
《从 0 到 1 搭建技术中台之报警平台实践：匹配器演进》
《从 0 到 1 搭建技术中台之发布系统实践：集泳道、灰度、四端和多区域于一体的设计与权衡》
《从 0 到 1 搭建技术中台之 A / B Testing 平台实践》
《从 0 到 1 搭建技术中台之组织架构篇》
