伴鱼数据库之性能大盘

作者： Hacker_ubN7WXjw 原文来源：https://tidb.net/blog/cf28e1e5

背景

在维护 TiDB 时，专业 DBA 应该会经常翻翻各个集群的指标、看看各个集群的慢日志和给集群核心指标配置告警等操作。一个 TiDB 集群有上百个指标监控，当维护少数几个 TiDB 集群时，应该比较 happy。当维护的集群达到十几个，甚至几十个集群时，是不是不那么 happy 了。

有时，我们被问到以下等问题：

• 老板问，马上国庆节了，线上集群有没有风险？

• 业务 leader 问，某某集群，过节会有风险吗？

• 。。。。

然后，一个个集群的去排查，累不说，可能效果也不怎么好。

每个数据库集群的核心指标、核心指标的告警阀值和容忍度、一段时间核心指标的历史平均值等，这些内容关乎底层服务的稳定性，dba 必须每天多次关注，随时做到全局掌控，心中有数，而不是等线上服务出了问题或者数据库告警了才去了解。

但是，这么多集群，这么多指标，如何快速的做到？我们是这样思考的：

• 集群指标虽然很多，可否挑选出少数几个指标来反映集群性能

• TiDB 集群那么多，到每个集群浏览集群指标比较耗时，可否把这些关注的指标定制到一个页面，这样可以快速熟悉

基于上述需求，通常有以下几种做法：

• 搭建一套单独的 grafana，数据源配置成各集群 TiDB prometheus 地址，再定制各指标 dashboard

• 采用 prometheus 联邦机制

• 单独采集，定制 dashboard

我们采用了第一种方案，简单高效，下面介绍下如何定制 TiDB 性能大盘。

大盘定制过程

1、安装 grafana

2、定制你所需要的数据源，比如线上 TiDB 集群地址，如下图所示

3、定制自己想要的监控指标和页面，对于一个 TiDB 集群，我们挑选了 node cpu、raftstore cpu、comprocessor cpu 和 duration4 个指标，日常问题，这几个指标很快能反映出问题，大家可以挑选自己关注的指标。定制过程如下所示。

• 参考源集群，拷贝对应的指标公式到定制的大盘

• 最终把我们需要关注的业务 TiDB 集群指标定制在一个页面上，我们配置的其中 3 个集群的指标，如下图所示

日常案例

由于对集群指标进行了精简，DBA 每天都会在业务早高峰、午高峰和晚高峰对大盘进行巡检，几秒内线上十几个集群的性能尽收眼底。同时由于每天例行做这个事情，每个集群的指标历史平均值，DBA 都能熟记于心了。一个业务集群，请求量大 + 业务快速迭代，对于服务的稳定性，挑战还是非常大的，所以只要指标有个小波动，DBA 都会及时处理掉。这样做带来几个好处：

• 性能问题扼杀在萌芽阶段。事前把这些事给做好，代价较小，事后做可能花的代价很大

• 无形中，研发同学对数据库性能问题更重视了

• DBA 越来越轻松

我们通过巡检，发现和解决了很多萌芽的性能问题，所以我们数据库 (除一次优化器 bug，导致大表走错索引，短暂影响线上外) 性能还是比较优秀的，下面讲讲，我们发现并处理的几个性能问题。

第一个例子：

我们最核心的直播集群，巡检发现，某天延迟出现小幅抖动，如下图。

我们的时延告警阀值是 125ms，此时这种波动，监控是无法告警出来的。这种小幅度的波动，基本不会影响线上其它请求。从其它 2 个指标可以看出来，如下图。

这种问题，短时间不处理，也不会出现什么大的问题。但如果发展到事后做，可能付出的代价会很大。

第二个例子：

某集群巡检发现，comprocessor cpu 较历史值，有小幅增长 (历史值维持在 10% 以下，我们的机器是 64 核，理论承载能力可以达到 5000%-6000%)，如下图所示。

通过慢日志系统发现，查询只走了部分索引，导致性能变差，我们通过修改索引，迅速解决。

在业务高速发展的背景下，数据库服务，要做到一个季度、半年、甚至一年不出故障，还是有挑战的。最好的方式，是在事前，把很多事情做好，做到数据库运维精细化，比如 SQL 审核，慢日志、规范等等。

最后

上述技巧没有什么技术含量，但是方便实用。比如：

1、DBA 可以快速熟悉各业务集群的性能，预测风险

2、业务研发做什么操作时，比如跑批等，可以随时关注操作对线上性能有无影响

3、等等

小技巧希望能帮到大家。每天花几秒钟看看，再也不担心老板问了 😆