伴鱼数据库之性能大盘

背景

在维护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、等等

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

6 个赞

学习了