TiDB 通过 Prometheus 与 Grafana 提供了非常全面且细致的监控指标。在排查数据库性能问题、稳定性异常或集群故障时，这些监控数据往往是定位问题的关键依据。不过，由于监控维度较多、细节较深，使用门槛也相对较高，刚接触 TiDB 运维或初学的 TiDB DBA 往往不太容易快速上手，例如：
如何快速判断当前 TiDB 集群中最耗时的是哪一类操作？
当发现写入延迟较高时，应该如何继续定位原因，需要重点查看哪些监控指标？
监控项数量很多，它们彼此之间的关联关系究竟是什么？
从 TiDB 4.0.7 开始，系统提供了一项新功能：可以将数据库内部各个流程的耗时监控按照父子关系绘制成关系图，帮助用户从全新的视角快速了解集群运行状态与性能瓶颈。
简介
监控关系图是指在指定时间范围内，将不同监控项按照父子依赖关系绘制而成的可视化关系图。图中的每一个方框节点都代表一个监控项，并包含以下信息：
监控项名称
监控项的总耗时
监控项总耗时占查询总耗时的比例
父节点的总耗时 = 自身耗时 + 所有子节点的耗时，因此部分节点还会额外展示自身耗时在总耗时中的占比。
以下图这个监控节点为例，tidb_execute 监控项的总耗时达到 19306.46 秒，占总查询耗时的 89.4%。其中，该监控项自身耗时为 9070.18 秒，占总查询耗时的 42%。当鼠标悬停在该方框节点上时，还可以查看该监控项的注释说明，以及总次数、平均耗时、平均 P99 耗时等更多与该监控相关的详细信息。
每个节点的大小和颜色深浅，都会随着该监控项自身耗时占总查询耗时比例的增加而变化。通常在分析 TiDB 性能监控关系图时，可以优先关注耗时较高的监控节点，再沿着父子关系逐层向下分析。更多说明可参考官方文档。接下来通过两个简单示例，看看如何利用这项能力进行问题定位。
示例 1
最近某个新业务上线后，原有 TiDB 集群的响应速度明显变慢。小明先看了服务器 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 集群各组件监控项之间的关系展示与问题定位能力。
如果你有任何疑问或建议，欢迎在 AskTUG 给我们留言交流~
