共计 1573 个字符，预计需要花费 4 分钟才能阅读完成。
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 集群中各个组件监控项之间的关系。
如有任何疑难或者倡议，欢送在 AskTUG 下给咱们留言~
