看不懂监控怎么办？TiDB新推出了耗时关系图

TiDB 使用 Prometheus 和 Grafana 提供了非常详细的监控指标。在遇到各种性能或稳定性问题时，这些监控一般是问题的关键线索。但详尽的细节监控指标使用门槛较高，刚入门的 TiDB DBA 可能难以上手，例如：

• 如何快速了解当前集群最耗时的是哪类操作？

• 发现写入耗时很长，如何进一步定位原因，应该查看哪些监控项？

• 监控项这么多，它们之间的关系是什么？

TiDB 4.0.7 起提供了一个新功能，可以将数据库各个内部流程的耗时监控按父子关系绘制为关系图，帮助用户快速以另一种维度了解集群状态。

简介

监控关系图是在指定的时间范围内，将各个监控项按父子关系绘制的关系图。图中每个方框节点代表一个监控项，包含了以下信息：

• 监控项的名称

• 监控项的总耗时

• 监控项总耗时和查询总耗时的比例

父节点监控的总耗时 = 自己的耗时 + 孩子节点的耗时，所以有些节点还会显示自己的耗时和总耗时的比例。

拿下面这个监控节点来说，tidb_execute监控项的总耗时达到了19306.46秒，这可是占了总查询耗时的89.4%呢！其中它本身的耗时是9070.18秒，占总查询耗时的42%。只要把鼠标悬停在这个方框上，就能看到监控项的注释说明，还有总次数、平均耗时、平均P99耗时等更多与该监控相关的信息。

每个节点的大小和颜色深浅，与监控项自己的耗时占总查询耗时的比例成正比。一般在这个图中可以重点关注耗时较多的监控节点，然后顺着父子关系向下梳理。详细介绍请参考官方文档。话不多说，来看两个简单的示例吧。

示例 1

最近新上线一个业务后，原来的集群响应突然变慢了很多，小明看服务器 CPU 都挺空闲的呀，然后抓了一个监控关系图如下：

可以很快发现，上图中：

1. tidb_query.Update 表示 update 语句的执行耗时占总查询耗时的 99.59%。

2. tidb_execute 表示 TiDB 的执行引擎本身耗时占 68.69%

3. tidb_txn_cmd.commit 表示事务提交的耗时占总耗时的 30.66%

4. tidb_kv_backoff.txnLock 表示事务遇到锁冲突的 backoff 总耗时占 15%，这要比发送 prewrite 和 commit 的 tidb_kv_request 的耗时高很多。

到此，可以确定 update 语句存在严重的写冲突，可以按照 乐观事务模型下写写冲突问题排查 进一步排查冲突的表和 SQL 语句，然后和业务方沟通从业务上避免写冲突。

示例 2

最近需要导入一批数据到 TiDB 集群，导入速度有点慢，小明想看看系统现在慢在哪儿，然后看能不能优化下，他抓了一个导入数据时的监控耗时关系图如下：

从上图可见，tikv的raftstore在处理propose前的等待耗时很长，这表明raftstore存在瓶颈。此时，可进一步查看raftstore cpu、append/apply log的延迟情况。若raftstore的thread cpu使用率不高，大概率是磁盘问题。具体可按照Performance TiKV Map中raftstore相关模块和TiDB磁盘I/O过高的处理办法进行排查。

除此之外，可以排查是否存在热点，可以按照 TiDB 热点问题处理 进一步排查是否有热点。

使用介绍

注：生成监控关系图时，会从 prometheus 中读取各项监控的数据。所以 TiDB 集群需要部署 prometheus ，推荐使用 tiup 部署集群。

登录 Dashboard 后点击左侧导航的集群诊断可以进入此功能页面：

设置区间起始时间和区间长度参数后，点击生成监控关系图按钮后，会进入监控关系图页面。

最后

本文介绍的监控关系图旨在帮助用户快速了解 TiDB 集群的负载情况和众多监控项之间的关系，后续计划集成 TiDB Performance Map，把和该项监控项相关的其他监控以及配置也关联上，进一步完善 TiDB 集群中各个组件监控项之间的关系。

如有任何疑问或者建议，欢迎在 AskTUG 下给我们留言~