好多好多监控
文档非常详细，监控项非常多，入门选手从overview面板开始，官方文档支持全文搜索，可以很方便找到每个监控项定义。
1.官方文档
- 监控说明，概述TiDB的监控架构，部署方式
- 监控指标，各组件监控面板划分，及监控指标
- 告警规则，各组件的报警规则及重要等级，包括 TiDB、TiKV、PD、TiDB Binlog、Node_exporter 和 Blackbox_exporter 的各报警项的规则描述及处理方法。
2.主要监控项
-
Overview 面板，集群概况，各组件主要信息状态，可以大致缩小排查集群瓶颈的范围，再结合组件详细面板，慢日志，实例错误日志和业务日志定位问题
-
Services Port Status，各组件状态，异常么有显示具体组件地址，结合告警信息查看
- count(probe_success{group="{各组件名}"} == 1) ，是否存在异常状态节点
-
PD，集群容量，region 基本健康状态信息
-
region health，在迁移或者扩容的过程中，可以监控到store及region的平衡状态
-
是否存在读/写热点，也可以根据慢日志里统计是否都来自同一个kv实例
-
region heartbeat，每个tikv上报pd的心跳，如果心跳上报过多，超过10w，考虑扩容kv，或者尝试静默region，结合99% region health latency 判断
-
-
TiDB，db组件状态，直接反映集群对外提供服务的健康程度，QPS，Duration现象直观
-
集群当前的QPS 以及 每个db实例的连接数
-
执行耗时三个纬度，结合kv cmd duration 判断耗时主要在哪个组件
-
db节点内存使用量，结合告警阀值配置及时扩容
-
kv命令执行数量和kv命令执行时间，结合上面的QPS和duration，缩小定位范围
-
kv返回的错误信息，事务冲突数量
-
-
TiKV，kv组件状态，存储层资源状态，容量使用情况等
-
scheduler pending commands 写入是否有堆积
-
coprocessor, TiKV 中查询消耗的时间及各类查询耗时
-
Coprocessor CPU：TiKV 查询线程的 CPU 使用率，和业务相关，复杂查询会使用大量的 CPU 资源
-
raftstore 线程的 CPU 使用率，线程数量默认为 2 (通过 conf/tikv.toml raftstore.store-pool-size 配置)。如果单个线程使用率超过 80%，说明使用率很高
-
-
System Info，服务器层概况，CPU，内存，IO，网络四大名捕
-
-
PD面板，PD配置，集群调度情况
-
Cluster 集群容量，基本配置信息，当前tso，集群ID等
- PD scheduler config：PD 调度配置列表
-
-
TiDB面板，Query信息，慢查询的统计信息，也可以看日志来分析
-
TiKV面板，Store信息，region分布，raft监控项
- scheduler pending commands,是否存在写入堆积
-
tikv-summary 面板，kv信息汇
-
tikv-details面板，各项详情
-
thread cpu
- raft store cpu (这个图overview有，在tikv目录)，3.0版本默认最多使用2个线程，所以上限制是200%，如果系统已经达到这个限制，说明raft写入存在瓶颈，需要进一步排查
-
gRPCa
- gRPC message count，每种 gRPC 消息的个数
-
coprocess，
- coprocess cpu & scan keys (这个图overview有，在tikv目录)，展示当前集群读请求的状态是否存在热点
-
-
tikv-trouble-shooting面板，按照异常分类，可以定位到具体某个kv实例异常
-
还有其他比如binlog,drainer,syncer,lighting,DM 等工具的监控项
更多阅读：