自去年开始，中台话题的热度不减，很多公司都投入到中台的建设中，从战略制定、组织架构调整、协作方式变动到技术落地实践，每个环节都可能出现各种各样的问题。技术中台最坏的状况是技术能力太差，不能支撑业务的发展，其次是技术脱离业务，不能服务业务的发展。前者是能力问题，后者是意识问题。在本专题中，伴鱼技术团队分享了从 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：表示执行语句时使用的database
query_time：表示执行这个语句花费的时间
total_keys：表示Coprocessor扫过的key的数量
process_keys：表示Coprocessor处理的key的数量
sql：执行的sql语句