作者：刘江@伴鱼
背景
伴鱼少儿英语是目前飞速成长的互联网在线英语教育品牌之一，特别在疫情这段时间内，业务量增长近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的慢日志，我们重点关注慢日志中的某些字段，比如：
|
|
解析后的数据最终存储到到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. 总结
目前，伴鱼慢日志系统在性能问题发现和预防数据库性能风险等方面发挥了很重要的作用。未来，我们将继续挖掘慢日志里的信息，丰富慢日志系统的功能，为伴鱼数据库保驾护航
