伴鱼数据库之慢日志系统
source link: https://tech.ipalfish.com/blog/2020/07/21/tidb_slowlog/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
伴鱼少儿英语是目前飞速成长的互联网在线英语教育品牌之一，特别在疫情这段时间内，业务量增长近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的慢日志，我们重点关注慢日志中的某些字段，比如：
1
2
3
4
5
6
index_name: 语句执行过程中是否用到索引
DB：表示执行语句时使用的database
query_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引发的线上故障。
目前，伴鱼慢日志系统在性能问题发现和预防数据库性能风险等方面发挥了很重要的作用。未来，我们将继续挖掘慢日志里的信息，丰富慢日志系统的功能，为伴鱼数据库保驾护航。
Recommend
-
60
平台的快速发展和规模化，必然要求教学和教研同步跟进。优质版权内容的争夺，成为在线教育品牌的战略重点。 i黑马&火柴盒讯 10月31日消息...
-
65
前言 经常会有群友问起webpack、react、redux、甚至create-react-app配置等等方面的问题，有些是我也不懂的，慢慢从大家的相互交流中，也学到了不少。 今天就尝试着一起来聊聊Webpack吧，旨在帮大家加深理解、新手更容易上路
-
52
技术选型是由技术方向和业务场景 trade-off 决定的，脱离业务场景来说技术选型是没有任何意义的，所以本文只是阐述了伴鱼技术团队数据库选型的过程，这并不是 MySQL、MongoDB 和 TiDB 之间直接的比较，只能说明 TiDB 更适合伴鱼的业务场景...
-
15
伴鱼数据库之监控系统 2020-07-222020-12-09数据库 ...
-
14
TL;DR本文将调用链追踪系统的设计维度归结于以下 5 个：调用链数据模型、元数据结构、因果关系、采样策略以及数据可视化。我们可以把这 5 个维度当作一个分析框架，用它帮助我们在理论上解构市面上任意一个调用链追踪系统，在实践中根据使用场景进行技...
-
12
在 理论篇 中，我们介绍了伴鱼在调用链追踪领域的调研工作，本篇继续介绍伴鱼的调用链追踪实践。在正式介绍前，简单交代一下背景：2015 年，在伴鱼服务端起步...
-
11
伴鱼分布式调度系统 Jarvis 的设计与实现 闫云龙、宋园园...
-
19
在伴鱼，我们在多个在线场景使用机器学习提高用户的使用体验，例如：在伴鱼绘本中，我们根据用户的帖子浏览记录，为用户推荐他们感兴趣的帖子；在转化后台里，我们根据用户的绘本购买记录，为用户推荐他们可能感兴趣的课程；等等。 特征是机器学习模型的...
-
2
伴鱼早期，整个大数据仓库下的数据基本处于裸奔状态，没有做任何的权限校验与审计，用户可以对数据为所欲为，这个阶段主要考虑效率优先。随着业务的发展，数据安全的重要性愈发突显，大数据权限系统因运而生，本文将向大家介绍伴鱼大数据权限系统的设计与实现。...
-
6
什么是慢查询慢查询日志，顾名思义，就是查询慢的日志，是指mysql记录所有执行超过 long_query_time参数设定的时间阈值的SQL语句的日志。该日志能为SQL...
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK