TiDB 使用 Prometheus 和 Grafana 提供了非常详细的监控指标。在遇到各种性能或稳定性问题时，这些监控一般是问题的关键线索。但详尽的细节监控指标使用门槛较高，刚入门的 TiDB DBA 可能难以上手，例如：
-
如何快速了解当前集群最耗时的是哪类操作？
-
发现写入耗时很长，如何进一步定位原因，应该查看哪些监控项？
-
监控项这么多，它们之间的关系是什么？
TiDB 4.0.7 起提供了一个新功能，可以将数据库各个内部流程的耗时监控按父子关系绘制为关系图，帮助用户快速以另一种维度了解集群状态。
简介
监控关系图是在指定的时间范围内，将各个监控项按父子关系绘制的关系图。图中每个方框节点代表一个监控项，包含了以下信息：
-
监控项的名称
-
监控项的总耗时
-
监控项总耗时和查询总耗时的比例
父节点监控的总耗时 = 自己的耗时 + 孩子节点的耗时，所以有些节点还会显示自己的耗时和总耗时的比例。
例如下面监控节点表示：tidb_execute 监控项的总耗时为 19306.46 秒，占总查询耗时的 89.4%，其中本身的耗时是 9070.18 秒，占总查询耗时的 42%。将鼠标悬停在该方框上，可以看到监控项的注释说明，总次数，平均耗时，平均 P99 耗时等更多该监控的信息。
每个节点的大小和颜色深浅，与监控项自己的耗时占总查询耗时的比例成正比。一般在这个图中可以重点关注耗时较多的监控节点，然后顺着父子关系向下梳理。详细介绍请参考官方文档。话不多说，来看两个简单的示例吧。
示例 1
最近新上线一个业务后，原来的集群响应突然变慢了很多，小明看服务器 CPU 都挺空闲的呀，然后抓了一个监控关系图如下：
可以很快发现，上图中：
-
tidb_query.Update 表示 update 语句的执行耗时占总查询耗时的 99.59%。
-
tidb_execute 表示 TiDB 的执行引擎本身耗时占 68.69%
-
tidb_txn_cmd.commit 表示事务提交的耗时占总耗时的 30.66%
-
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 集群中各个组件监控项之间的关系。