Overview 面板重要监控指标详解
Overview 面板重要监控指标详解
使用 TiDB Ansible 或 TiUP 部署 TiDB 集群时，一键部署监控系统 (Prometheus & Grafana)，监控架构参见 TiDB 监控框架概述。
目前 Grafana Dashboard 整体分为 PD、TiDB、TiKV、Node_exporter、Overview 等。
对于日常运维，我们单独挑选出重要的 Metrics 放在 Overview 页面，方便日常运维人员观察集群组件 (PD, TiDB, TiKV) 使用状态以及集群使用状态。
以下为 Overview Dashboard 监控说明：
Services Port Status
• Services Up：各服务在线节点数量
PD
• PD role：当前 PD 的角色
• Storage capacity：TiDB 集群总可用数据库空间大小
• Current storage size：TiDB 集群目前已用数据库空间大小，TiKV 多副本的空间占用也会包含在内
• Normal stores：处于正常状态的节点数目
• Abnormal stores：处于异常状态的节点数目，正常情况应当为 0
• Number of Regions：当前集群的 Region 总量，请注意 Region 数量与副本数无关
• 99% completed_cmds_duration_seconds：单位时间内，99% 的 pd-server 请求执行时间小于监控曲线的值，一般 <= 5ms
• Handle_requests_duration_seconds：PD 发送请求的网络耗时
• Region health：每个 Region 的状态，通常情况下，pending 的 peer 应该少于 100，miss 的 peer 不能一直大于 0
• Hot write Region’s leader distribution：每个 TiKV 实例上是写入热点的 leader 的数量
• Hot read Region’s leader distribution：每个 TiKV 实例上是读取热点的 leader 的数量
• Region heartbeat report：TiKV 向 PD 发送的心跳个数
• 99% Region heartbeat latency：99% 的情况下，心跳的延迟
TiDB
• Statement OPS：不同类型 SQL 语句每秒执行的数量。按 SELECT、INSERT、UPDATE 等来统计
• Duration：执行的时间
• 客户端网络请求发送到 TiDB，到 TiDB 执行结束后返回给客户端的时间。一般情况下，客户端请求都是以 SQL 语句的形式发送，但也可以包含 COM_PING、COM_SLEEP、COM_STMT_FETCH、COM_SEND_LONG_DATA 之类的命令执行的时间
• 由于 TiDB 支持 Multi-Query，因此，可以接受客户端一次性发送的多条 SQL 语句，如：select 1; select 1; select 1;。此时，统计的执行时间是所有 SQL 执行完之后的总时间
• QPS By Instance：每个 TiDB 上的 QPS。按照命令和执行结果成功或失败来统计
• Failed Query OPM：每个 TiDB 实例上，每秒钟执行 SQL 语句发生错误按照错误类型的统计（例如语法错误、主键冲突等）。包含了错误所属的模块和错误码
• Connection count：每个 TiDB 的连接数
• Memory Usage：每个 TiDB 实例的内存使用统计，分为进程占用内存和 Golang 在堆上申请的内存
• Transaction OPS：每秒事务执行数量统计
• Transaction Duration：事务执行的时间
• KV Cmd OPS：KV 命令执行数量统计
• KV Cmd Duration 99：KV 命令执行的时间
• PD TSO OPS：TiDB 每秒从 PD 获取 TSO 的数量
• PD TSO Wait Duration：TiDB 等待从 PD 获取 TS 的时间
• TiClient Region Error OPS：TiKV 返回 Region 相关错误信息的数量
• Lock Resolve OPS：TiDB 清理锁操作的数量。当 TiDB 的读写请求遇到锁时，会尝试进行锁清理
• Load Schema Duration：TiDB 从 TiKV 获取 Schema 的时间
• KV Backoff OPS：TiKV 返回错误信息的数量
TiKV
• leader：各个 TiKV 节点上 Leader 的数量分布
• region：各个 TiKV 节点上 Region 的数量分布
• CPU：各个 TiKV 节点的 CPU 使用率
• Memory：各个 TiKV 节点的内存使用量
• store size：每个 TiKV 实例的使用的存储空间的大小
• cf size：每个列族的大小
• channel full：每个 TiKV 实例上 channel full 错误的数量，正常情况下应当为 0
• server report failures：每个 TiKV 实例上报错的消息个数，正常情况下应当为 0
• scheduler pending commands：每个 TiKV 实例上 pending 命令的个数
• coprocessor executor count：TiKV 每秒收到的 coprocessor 操作数量，按照 coprocessor 类型统计
• coprocessor request duration：处理 coprocessor 读请求所花费的时间
• raft store CPU：raftstore 线程的 CPU 使用率，线程数量默认为 2 (通过 raftstore.store-pool-size 配置)。如果单个线程使用率超过 80%，说明使用率很高
• Coprocessor CPU：coprocessor 线程的 CPU 使用率
System Info
• Vcores：CPU 核心数量
• Memory：内存总大小
• CPU Usage：CPU 使用率，最大为 100%
• Load [1m]：1 分钟的负载情况
• Memory Available：剩余内存大小
• Network Traffic：网卡流量统计
• TCP Retrans：TCP 重传数量统计
• IO Util：磁盘使用率，最高为 100%，一般到 80% – 90% 就需要考虑加节点
TiDB 重要监控指标详解
目前 Grafana Dashboard 整体分为 PD、TiDB、TiKV、Node_exporter、Overview 等。TiDB 分为 TiDB 和 TiDB Summary 面板，两个面板的区别如下：
• TiDB 面板：提供尽可能全面的信息，供排查集群异常。
• TiDB Summary 面板：将 TiDB 面板中用户最为关心的部分抽取出来，并做了些许修改。主要用于提供数据库日常运行中用户关心的数据，如 QPS、TPS、响应延迟等，以便作为外部展示、汇报用的监控信息。
以下为 TiDB Dashboard 部分监控说明：
说明
• Query Summary
• Duration：执行时间
• 客户端网络请求发送到 TiDB，到 TiDB 执行结束后返回给客户端的时间。一般情况下，客户端请求都是以 SQL 语句的形式发送，但也可以包含 COM_PING、COM_SLEEP、COM_STMT_FETCH、COM_SEND_LONG_DATA 之类的命令执行时间
• 由于 TiDB 支持 Multi-Query，因此，可以接受客户端一次性发送多条 SQL 语句，如 select 1; select 1; select 1;。此时，统计的执行时间是所有 SQL 语句执行完之后的总时间
• QPS：所有 TiDB 实例上的每秒执行的 SQL 语句数量。按照执行成功或失败（OK/Error）进行了区分
• Statement OPS：不同类型的 SQL 语句每秒执行的数量。按 SELECT、INSERT、UPDATE 等来统计
• QPS By Instance：每个 TiDB 实例上的 QPS。按照命令和执行结果成功或失败来统计
• Failed Query OPM：每个 TiDB 实例上，对每秒钟执行 SQL 语句发生的错误按照错误类型的统计（例如语法错误、主键冲突等）。包含了错误所属的模块和错误码
• Slow query：慢查询处理时间统计（整个慢查询耗时、Coprocessor 耗时、Coprocessor 调度等待时间）
• 999/99/95/80 Duration：不同类型的 SQL 语句执行耗时统计（不同百分位）
• Query Detail
• Duration 80/95/99/999 By Instance：每个 TiDB 实例执行 SQL 语句的耗时统计（不同百分位）。
• Failed Query OPM Detail：每个 TiDB 实例执行 SQL 语句发生的错误按照错误类型统计（例如语法错误、主键冲突等）。
• Internal SQL OPS：整个 TiDB 集群内部 SQL 语句执行的 QPS。内部 SQL 语句是 TiDB 内部自动执行的 SQL 语句，一般由用户 SQL 语句来触发或者内部定时任务触发。
• Server
• Uptime：每个 TiDB 实例的运行时间
• Memory Usage：每个 TiDB 实例的内存使用统计，分为进程占用内存和 Golang 在堆上申请的内存
• CPU Usage：每个 TiDB 实例的 CPU 使用统计
• Connection Count：每个 TiDB 的连接数
• Open FD Count：每个 TiDB 实例的打开的文件描述符统计
• Goroutine Count：每个 TiDB 实例的 Goroutine 数量
• Go GC Duration：每个 TiDB 实例的 Golang GC 耗时
• Go Threads：每个 TiDB 实例的线程数量
• Go GC Count：每个 TiDB 实例的 Golang GC 执行次数
• Go GC CPU Usage：每个 TiDB 实例的 Golang GC 使用的 CPU
• Events OPM：每个 TiDB 实例关键事件统计，例如 start，close，graceful-shutdown，kill，hang 等
• Keep Alive OPM：每个 TiDB 实例每分钟刷新监控的次数，通常不需要关注
• Prepare Statement Count：每个 TiDB 实例现存的 Prepare 语句数以及总数
• Time Jump Back OPS：每个 TiDB 实例上每秒操作系统时间回跳的次数
• Write Binlog Error：每个 TiDB 每秒写入 Binlog 失败的次数
• Get Token Duration：每个连接获取 Token 的耗时
• Handshake Error OPS：每个 TiDB 实例每秒握手错误的次数
• Transaction
• Transaction OPS：每秒事务的执行数量
• Duration：事务执行的时间
• Transaction Statement Num：事务中的 SQL 语句数量
• Transaction Retry Num：事务重试次数
• Session Retry Error OPS：每秒事务重试时遇到的错误数量
• KV Transaction OPS：每个 TiDB 内部每秒执行的事务数量
• 一个用户的事务，在 TiDB 内部可能会触发多次事务执行，其中包含，内部元数据的读取，用户事务原子性地多次重试执行等
• TiDB 内部的定时任务也会通过事务来操作数据库，这部分也包含在这个面板里
• KV Transaction Duration：每个 TiDB 内部执行事务的耗时
• Commit Token Wait Duration：事务提交时的流控队列等待耗时。当出现较长等待时，代表提交事务过大，正在限流。如果系统还有资源可以使用，可以通过增大 TiDB 配置文件中 committer-concurrency 来加速提交
• Transaction Max Write KV Num：单个事务写入的最大键值对数量
• Transaction Max Write Size Bytes：单个事务写入的最大键值对大小
• Transaction Regions Num 90：单个事务写入的 Region 数量的 90% 分位
• Send HeartBeat Duration：事务发送心跳的时间间隔
• TTL Lifetime Reach Counter：事务的 TTL 达到了上限的数量。TTL 上限默认值 10 分钟，它的含义是从悲观事务第一次加锁，或者乐观事务的第一个 prewrite 开始，超过了 10 分钟。可以通过修改 TiDB 配置文件中 max-txn-ttl 来改变 TTL 寿命上限
• Statement Lock Keys：单个语句的加锁个数
• Acquire Pessimistic Locks Duration：加锁所消耗的时间
• Pessimistic Statement Retry OPS：悲观语句重试次数统计。当语句尝试加锁时，可能遇到写入冲突，此时，语句会重新获取新的 snapshot 并再次加锁
• Load Safepoint OPS：加载 Safepoint 的次数统计。Safepoint 作用是在事务读数据时，保证不读到 Safepoint 之前的数据，保证数据安全。因为，Safepoint 之前的数据有可能被 GC 清理掉
• Executor
• Parse Duration：SQL 语句解析耗时统计
• Compile Duration：将解析后的 SQL AST 编译成执行计划耗时统计
• Execution Duration：执行 SQL 语句执行计划耗时统计
• Expensive Executor OPS：每秒消耗系统资源比较多的算子统计，包括 Merge Join，Hash Join，Index Look Up Join，Hash Agg，Stream Agg，Sort，TopN 等
• Queries Using Plan Cache OPS：每秒使用 Plan Cache 的查询数量统计
• Distsql
• Distsql Duration：Distsql 处理的时长
• Distsql QPS：Distsql 的数量统计
• Distsql Partial QPS：每秒 Partial Results 的数量
• Scan Keys Num：每个 Query 扫描的 Key 的数量
• Scan Keys Partial Num：每一个 Partial Result 扫描的 Key 的数量
• Partial Num：每个 SQL 语句 Partial Results 的数量
• KV Errors
• KV Backoff Duration：KV 每个请求重试的总时间。TiDB 向 TiKV 发送请求时可能遇到错误，TiDB 对每个向 TiKV 的请求都有重试机制，这里记录的是一个请求重试的总时间
• TiClient Region Error OPS：TiKV 返回 Region 相关错误信息的数量
• KV Backoff OPS：TiKV 返回错误信息的数量
• Lock Resolve OPS：TiDB 清理锁操作的数量。当 TiDB 的读写请求遇到锁时，会尝试进行锁清理
• Other Errors OPS：其他类型的错误数量，包括清锁和更新 SafePoint
• KV Request
• KV Request OPS：KV Request 执行次数，根据 TiKV 显示
• KV Request Duration 99 by store：KV Request 执行时间，根据 TiKV 显示
• KV Request Duration 99 by type：KV Request 执行时间，根据类型显示
• PD Client
• PD Client CMD OPS：PD Client 每秒执行命令数量统计
• PD Client CMD Duration：PD Client 执行命令耗时
• PD Client CMD Fail OPS：PD Client 每秒执行命令失败统计
• PD TSO OPS：TiDB 每秒从 PD 获取 TSO 的数量
• PD TSO Wait Duration：TiDB 等待从 PD 返回 TSO 的时间
• PD TSO RPC Duration：TiDB 从向 PD 发送获取 TSO 的请求到接收到 TSO 花费的时间
• Start TSO Wait Duration：TiDB 从向 PD 发送获取 start tso 请求开始到开始等待 tso 返回的时间
• Schema Load
• Load Schema Duration：TiDB 从 TiKV 获取 Schema 的时间
• Load Schema OPS：TiDB 从 TiKV 每秒获取 Schema 的数量统计
• Schema Lease Error OPM：Schema Lease 出错，包括 change 和 outdate 两种，change 代表 schema 发生了变化，outdate 代表无法更新 schema，属于较严重错误，出现 outdate 错误时会报警
• Load Privilege OPS：TiDB 从 TiKV 每秒获取权限信息的数量统计
• DDL
• DDL Duration 95：DDL 语句处理时间的 95% 分位
• Batch Add Index Duration 100：创建索引时每个 Batch 所花费的最大时间统计
• DDL Waiting Jobs Count：等待的 DDL 任务数量
• DDL META OPM：DDL 每分钟获取 META 的次数
• DDL Worker Duration 99：每个 DDL worker 执行时间 99% 分位
• Deploy Syncer Duration：Schema Version Syncer 初始化，重启，清空等操作耗时
• Owner Handle Syncer Duration：DDL Owner 在执行更新，获取以及检查 Schema Version 的耗时
• Update Self Version Duration：Schema Version Syncer 更新版本信息耗时
• DDL OPM：DDL 语句的每秒执行次数
• DDL add index progress in percentage：添加索引的进度展示
• Statistics
• Auto Analyze Duration 95：自动 ANALYZE 耗时统计
• Auto Analyze QPS：自动 ANALYZE 数量统计
• Stats Inaccuracy Rate：统计信息不准确度统计
• Pseudo Estimation OPS：使用假的统计信息优化 SQL 的数量统计
• Dump Feedback OPS：存储统计信息 Feedback 的数量统计
• Store Query Feedback QPS：存储合并查询的 Feedback 信息的每秒操作数量，该操作在 TiDB 内存中进行
• Significant Feedback：重要的 Feedback 更新统计信息的数量统计
• Update Stats OPS：利用 Feedback 更新统计信息的数量统计
• Fast Analyze Status 100：快速收集统计信息的状态统计
• Owner
• New ETCD Session Duration 95：创建一个新的 etcd 会话花费的时间。TiDB 通过 etcd client 连接 PD 中的 etcd 保存/读取部分元数据信息。这里记录了创建会话花费的时间
• Owner Watcher OPS：DDL owner watch PD 的 etcd 的元数据的 goroutine 的每秒操作次数
• Meta
• AutoID QPS：AutoID 相关操作的数量统计，包括全局 ID 分配、单个 Table AutoID 分配、单个 Table AutoID Rebase 三种操作
• AutoID Duration：AutoID 相关操作的耗时
• Region Cache Error OPS：TiDB 缓存的 region 信息每秒遇到的错误次数
• Meta Operations Duration 99：元数据操作延迟
• GC
• Worker Action OPM：GC 相关操作的数量，包括 run_job，resolve_lock，delete_range 等操作
• Duration 99：GC 相关操作的耗时统计
• Config：GC 的数据保存时长（life time）和 GC 运行间隔（run interval）配置
• GC Failure OPM：GC 相关操作失败数量统计
• Delete Range Failure OPM：Delete range 失败的次数
• Too Many Locks Error OPM：GC 清锁过多错误的数量
• Action Result OPM：GC 相关操作结果数量
• Delete Range Task Status：Delete range 的任务状态，包含完成和失败状态
• Push Task Duration 95：将 GC 子任务推送给 GC worker 的耗时
• Batch Client
• Pending Request Count by TiKV：等待处理的 Batch 消息数量
• Wait Duration 95：等待处理的 Batch 消息延迟
• Batch Client Unavailable Duration 95：Batch 客户端不可用的时间
• No Available Connection Counter：Batch 客户端找不到可用链接的次数
PD 重要监控指标详解
使用 TiDB Ansible 部署 TiDB 集群时，一键部署监控系统 (Prometheus/Grafana)，监控架构请看 TiDB 监控框架概述。
目前 Grafana Dashboard 整体分为 PD、TiDB、TiKV、Node_exporter、Overview 等。
对于日常运维，我们通过观察 PD 面板上的 Metrics，可以了解 PD 当前的状态。
以下为 PD Dashboard 监控说明：
• PD role：当前 PD 的角色
• Storage capacity：TiDB 集群总可用数据库空间大小
• Current storage size：TiDB 集群目前已用数据库空间大小
• Current storage usage：TiDB 集群存储空间的使用率
• Normal stores：处于正常状态的节点数目
• Number of Regions：当前集群的 Region 总量
• Abnormal stores：处于异常状态的节点数目，正常情况应当为 0
• Region health：集群所有 Region 的状态。通常情况下，pending 或 down 的 peer 应该少于 100，miss 的 peer 不能一直大于 0，empty Region 过多需及时打开 Region Merge
• Current peer count：当前集群 peer 的总量
Cluster
• PD scheduler config：PD 调度配置列表
• Cluster ID：集群的 cluster id，唯一标识
• Current TSO：当前分配 TSO 的物理时间戳部分
• Current ID allocation：当前可分配 ID 的最大值
• Region label isolation level：不同 label 所在的 level 的 Region 数量
• Label distribution：集群中 TiKV 节点的 label 分布情况
Operator
• Schedule operator create：新创建的不同 operator 的数量，单位 opm 代表一分钟内创建的个数
• Schedule operator check：已检查的 operator 的次数，主要检查是否当前步骤已经执行完成，如果是，则执行下一个步骤
• Schedule operator finish：已完成调度的 operator 的数量
• Schedule operator timeout：已超时的 operator 的数量
• Schedule operator replaced or canceled：已取消或者被替换的 operator 的数量
• Schedule operators count by state：不同状态的 operator 的数量
• Operator finish duration：已完成的 operator 所花费的最长时间
• Operator step duration：已完成的 operator 的步骤所花费的最长时间
Statistics – Balance
• Store capacity：每个 TiKV 实例的总的空间大小
• Store available：每个 TiKV 实例的可用空间大小
• Store used：每个 TiKV 实例的已使用空间大小
• Size amplification：每个 TiKV 实例的空间放大比率
• Size available ratio：每个 TiKV 实例的可用空间比率
• Store leader score：每个 TiKV 实例的 leader 分数
• Store Region score：每个 TiKV 实例的 Region 分数
• Store leader size：每个 TiKV 实例上所有 leader 的大小
• Store Region size：每个 TiKV 实例上所有 Region 的大小
• Store leader count：每个 TiKV 实例上所有 leader 的数量
• Store Region count：每个 TiKV 实例上所有 Region 的数量
Statistics – hot write
• Hot Region’s leader distribution：每个 TiKV 实例上成为写入热点的 leader 的数量
• Total written bytes on hot leader Regions：每个 TiKV 实例上所有成为写入热点的 leader 的总的写入流量大小
• Hot write Region’s peer distribution：每个 TiKV 实例上成为写入热点的 peer 的数量
• Total written bytes on hot peer Regions：每个 TiKV 实例上所有成为写入热点的 peer 的写入流量大小
• Store Write rate bytes：每个 TiKV 实例总的写入的流量
• Store Write rate keys：每个 TiKV 实例总的写入 keys
• Hot cache write entry number：每个 TiKV 实例进入热点统计模块的 peer 的数量
• Selector events： 热点调度中选择器的事件发生次数
• Direction of hotspot move leader：热点调度中 leader 的调度方向，正数代表调入，负数代表调出
• Direction of hotspot move peer：热点调度中 peer 的调度方向，正数代表调入，负数代表调出
Statistics – hot read
• Hot Region’s leader distribution：每个 TiKV 实例上成为读取热点的 leader 的数量
• Total read bytes on hot leader Regions：每个 TiKV 实例上所有成为读取热点的 leader 的总的读取流量大小
• Store read rate bytes：每个 TiKV 实例总的读取的流量
• Store read rate keys：每个 TiKV 实例总的读取 keys
• Hot cache read entry number：每个 TiKV 实例进入热点统计模块的 peer 的数量
Scheduler
• Scheduler is running：所有正在运行的 scheduler
• Balance leader movement：leader 移动的详细情况
• Balance Region movement：Region 移动的详细情况
• Balance leader event：balance leader 的事件数量
• Balance Region event：balance Region 的事件数量
• Balance leader scheduler：balance-leader scheduler 的状态
• Balance Region scheduler：balance-region scheduler 的状态
• Replica checker：replica checker 的状态
• Rule checker：rule checker 的状态
• Region merge checker：merge checker 的状态
• Filter target：尝试选择 Store 作为调度 taget 时没有通过 Filter 的计数
• Filter source：尝试选择 Store 作为调度 source 时没有通过 Filter 的计数
• Balance Direction：Store 被选作调度 target 或 source 的次数
• Store Limit：Store 的调度限流状态
gRPC
• Completed commands rate：gRPC 命令的完成速率
• 99% Completed commands duration：99% 命令的最长消耗时间
etcd
• Handle transactions count：etcd 的事务个数
• 99% Handle transactions duration：99% 的情况下，处理 etcd 事务所需花费的时间
• 99% WAL fsync duration：99% 的情况下，持久化 WAL 所需花费的时间，这个值通常应该小于 1s
• 99% Peer round trip time seconds：99% 的情况下，etcd 的网络延时，这个值通常应该小于 1s
• etcd disk WAL fsync rate：etcd 持久化 WAL 的速率
• Raft term：当前 Raft 的 term
• Raft committed index：最后一次 commit 的 Raft index
• Raft applied index：最后一次 apply 的 Raft index
TiDB
• PD Server TSO handle time and Client recv time：从 PD 开始处理 TSO 请求到 client 端接收到 TSO 的总耗时
• Handle requests count：TiDB 的请求数量
• Handle requests duration：每个请求所花费的时间，99% 的情况下，应该小于 100ms
Heartbeat
• Heartbeat region event QPS：心跳处理 region 的 QPS， 包括更新缓存和持久化
• Region heartbeat report：TiKV 向 PD 发送的心跳个数
• Region heartbeat report error：TiKV 向 PD 发送的异常的心跳个数
• Region heartbeat report active：TiKV 向 PD 发送的正常的心跳个数
• Region schedule push：PD 向 TiKV 发送的调度命令的个数
• 99% Region heartbeat latency：99% 的情况下，心跳的延迟
Region storage
• Syncer Index：Leader 记录 Region 变更历史的最大 index
• history last index：Follower 成功同步的 Region 变更历史的 index
TiKV 监控指标详解
以下为 TiKV-Details 默认的监控信息：
Cluster
• Store size：每个 TiKV 实例的使用的存储空间的大小
• Available size：每个 TiKV 实例的可用的存储空间的大小
• Capacity size：每个 TiKV 实例的存储容量的大小
• CPU：每个 TiKV 实例 CPU 的使用率
• Memory：每个 TiKV 实例内存的使用情况
• IO utilization：每个 TiKV 实例 IO 的使用率
• MBps：每个 TiKV 实例写入和读取的数据量大小
• QPS：每个 TiKV 实例上各种命令的 QPS
• Errps：每个 TiKV 实例上 gRPC 消息失败的速率
• leader：每个 TiKV 实例 leader 的个数
• Region：每个 TiKV 实例 Region 的个数
• Uptime：自上次重启以来 TiKV 正常运行的时间
Errors
• Critical error：严重错误的数量
• Server is busy：各种会导致 TiKV 实例暂时不可用的事件个数，如 write stall，channel full 等，正常情况下应当为 0
• Server report failures：server 报错的消息个数，正常情况下应当为 0
• Raftstore error：每个 TiKV 实例上 raftstore 发生错误的个数
• Scheduler error：每个 TiKV 实例上 scheduler 发生错误的个数
• Coprocessor error：每个 TiKV 实例上 coprocessor 发生错误的个数
• gRPC message error：每个 TiKV 实例上 gRPC 消息发生错误的个数
• Leader drop：每个 TiKV 实例上 drop leader 的个数
• Leader missing：每个 TiKV 实例上 missing leader 的个数
Server
• CF size：每个列族的大小
• Store size：每个 TiKV 实例的使用的存储空间的大小
• Channel full：每个 TiKV 实例上 channel full 错误的数量，正常情况下应当为 0
• Active written leaders：各个 TiKV 实例中正在被写入的 Leader 的数量
• Approximate Region size：每个 Region 近似的大小
• Approximate Region size Histogram：每个 Region 近似大小的直方图
• Region average written keys：每个 TiKV 实例上所有 Region 的平均 key 写入个数
• Region average written bytes：每个 TiKV 实例上所有 Region 的平均写入大小
gRPC
• gRPC message count：每种 gRPC 请求的速度
• gRPC message failed：失败的 gRPC 请求的速度
• 99% gRPC message duration：99% gRPC 请求的执行时间小于该值
• Average gRPC message duration：gRPC 请求平均的执行时间
• gRPC batch size：TiDB 与 TiKV 之间 grpc 请求的 batch 大小
• raft message batch size：TiKV 与 TiKV 之间 raft 消息的 batch 大小
Thread CPU
• Raft store CPU：raftstore 线程的 CPU 使用率，通常应低于 80% * raftstore.store-pool-size
• Async apply CPU：async apply 线程的 CPU 使用率，通常应低于 90% * raftstore.apply-pool-size
• Scheduler worker CPU：scheduler worker 线程的 CPU 使用率，通常应低于 90% * storage.scheduler-worker-pool-size
• gRPC poll CPU：gRPC 线程的 CPU 使用率，通常应低于 80% * server.grpc-concurrency
• Unified read pool CPU：unified read pool 线程的 CPU 使用率
• Storage ReadPool CPU：storage read pool 线程的 CPU 使用率
• Coprocessor CPU：coprocessor 线程的 CPU 使用率
• RocksDB CPU：RocksDB 线程的 CPU 使用率
• Split check CPU：split check 线程的 CPU 使用率
• GC worker CPU：GC worker 线程的 CPU 使用率
• Snapshot worker CPU：snapshot worker 线程的 CPU 使用率
PD
• PD requests：TiKV 发送给 PD 的请求速度
• PD request duration (average)：TiKV 发送给 PD 的请求处理的平均时间
• PD heartbeats：发送给 PD 的心跳的速度
• PD validate peers：TiKV 发送给 PD 用于验证 TiKV 的 peer 有效的消息的速度
Raft IO
• Apply log duration：Raft apply 日志所花费的时间
• Apply log duration per server：每个 TiKV 实例上 Raft apply 日志所花费的时间
• Append log duration：Raft append 日志所花费的时间
• Append log duration per server：每个 TiKV 实例上 Raft append 日志所花费的时间
• Commit log duration：Raft commit 日志所花费的时间
• Commit log duration per server：每个 TiKV 实例上 Raft commit 日志所花费的时间
Raft process
• Ready handled：Raft 中不同 ready 类型的 ops
• 0.99 Duration of Raft store events：99% 的 raftstore 事件所花费的时间
• Process ready duration：处理 ready 所花费的时间
• Process ready duration per server：每个 TiKV 实例处理 ready 所花费的时间，99.99% 的情况下，应该小于 2s
Raft message
• Sent messages per server：每个 TiKV 实例发送 Raft 消息的 ops
• Flush messages per server：每个 TiKV 实例中 raft client 往外 flush Raft 消息的 ops
• Receive messages per server：每个 TiKV 实例接受 Raft 消息的 ops
• Messages：发送不同类型的 Raft 消息的 ops
• Vote：Raft 投票消息发送的 ops
• Raft dropped messages：每秒钟丢弃不同类型的 Raft 消息的个数
Raft propose
• Raft apply proposals per ready：在一个 batch 内，apply proposal 时每个 ready 中包含 proposal 的个数的直方图
• Raft read/write proposals：不同类型的 proposal 的 ops
• Raft read proposals per server：每个 TiKV 实例发起读 proposal 的 ops
• Raft write proposals per server：每个 TiKV 实例发起写 proposal 的 ops
• Propose wait duration：proposal 的等待时间的直方图
• Propose wait duration per server：每个 TiKV 实例上每个 proposal 的等待时间的直方图
• Apply wait duration：apply 的等待时间的直方图
• Apply wait duration per server：每个 TiKV 实例上每个 apply 的等待时间的直方图
• Raft log speed：peer propose 日志的平均速度
Raft admin
• Admin proposals：admin proposal 的 ops
• Admin apply：apply 命令的 ops
• Check split：split check 命令的 ops
• 99.99% Check split duration：99.99% 的情况下，split check 所需花费的时间
Local reader
• Local reader requests：所有请求的总数以及 local read 线程拒绝的请求数量
Unified Read Pool
• Time used by level：在 unified read pool 中每个级别使用的时间，级别 0 指小查询
• Level 0 chance：在 unified read pool 中调度的 level 0 任务的比例
• Running tasks：在 unified read pool 中并发运行的任务数量
Storage
• Storage command total：收到不同命令的 ops
• Storage async request error：异步请求出错的 ops
• Storage async snapshot duration：异步处理 snapshot 所花费的时间，99% 的情况下，应该小于 1s
• Storage async write duration：异步写所花费的时间，99% 的情况下，应该小于 1s
Scheduler
• Scheduler stage total：每种命令不同阶段的 ops，正常情况下，不会在短时间内出现大量的错误
• Scheduler writing bytes：每个 TiKV 实例正在处理的命令的写入字节数量
• Scheduler priority commands：不同优先级命令的 ops
• Scheduler pending commands：每个 TiKV 实例上 pending 命令的 ops
Scheduler – commit
• Scheduler stage total：commit 中每个命令所处不同阶段的 ops，正常情况下，不会在短时间内出现大量的错误
• Scheduler command duration：执行 commit 命令所需花费的时间，正常情况下，应该小于 1s
• Scheduler latch wait duration：由于 latch wait 造成的时间开销，正常情况下，应该小于 1s
• Scheduler keys read：commit 命令读取 key 的个数
• Scheduler keys written：commit 命令写入 key 的个数
• Scheduler scan details：执行 commit 命令时，扫描每个 CF 中 key 的详细情况
• Scheduler scan details [lock]：执行 commit 命令时，扫描每个 lock CF 中 key 的详细情况
• Scheduler scan details [write]：执行 commit 命令时，扫描每个 write CF 中 key 的详细情况
• Scheduler scan details [default]：执行 commit 命令时，扫描每个 default CF 中 key 的详细情况
Scheduler – pessimistic_rollback
• Scheduler stage total：pessimistic_rollback 中每个命令所处不同阶段的 ops，正常情况下，不会在短时间内出现大量的错误
• Scheduler command duration：执行 pessimistic_rollback 命令所需花费的时间，正常情况下，应该小于 1s
• Scheduler latch wait duration：由于 latch wait 造成的时间开销，正常情况下，应该小于 1s
• Scheduler keys read：pessimistic_rollback 命令读取 key 的个数
• Scheduler keys written：pessimistic_rollback 命令写入 key 的个数
• Scheduler scan details：执行 pessimistic_rollback 命令时，扫描每个 CF 中 key 的详细情况
• Scheduler scan details [lock]：执行 pessimistic_rollback 命令时，扫描每个 lock CF 中 key 的详细情况
• Scheduler scan details [write]：执行 pessimistic_rollback 命令时，扫描每个 write CF 中 key 的详细情况
• Scheduler scan details [default]：执行 pessimistic_rollback 命令时，扫描每个 default CF 中 key 的详细情况
Scheduler – prewrite
• Scheduler stage total：prewrite 中每个命令所处不同阶段的 ops，正常情况下，不会在短时间内出现大量的错误
• Scheduler command duration：执行 prewrite 命令所需花费的时间，正常情况下，应该小于 1s
• Scheduler latch wait duration：由于 latch wait 造成的时间开销，正常情况下，应该小于 1s
• Scheduler keys read：prewrite 命令读取 key 的个数
• Scheduler keys written：prewrite 命令写入 key 的个数
• Scheduler scan details：执行 prewrite 命令时，扫描每个 CF 中 key 的详细情况
• Scheduler scan details [lock]：执行 prewrite 命令时，扫描每个 lock CF 中 key 的详细情况
• Scheduler scan details [write]：执行 prewrite 命令时，扫描每个 write CF 中 key 的详细情况
• Scheduler scan details [default]：执行 prewrite 命令时，扫描每个 default CF 中 key 的详细情况
Scheduler – rollback
• Scheduler stage total：rollback 中每个命令所处不同阶段的 ops，正常情况下，不会在短时间内出现大量的错误
• Scheduler command duration：执行 rollback 命令所需花费的时间，正常情况下，应该小于 1s
• Scheduler latch wait duration：由于 latch wait 造成的时间开销，正常情况下，应该小于 1s
• Scheduler keys read：rollback 命令读取 key 的个数
• Scheduler keys written：rollback 命令写入 key 的个数
• Scheduler scan details：执行 rollback 命令时，扫描每个 CF 中 key 的详细情况
• Scheduler scan details [lock]：执行 rollback 命令时，扫描每个 lock CF 中 key 的详细情况
• Scheduler scan details [write]：执行 rollback 命令时，扫描每个 write CF 中 key 的详细情况
• Scheduler scan details [default]：执行 rollback 命令时，扫描每个 default CF 中 key 的详细情况
GC
• MVCC versions：每个 key 的版本个数
• MVCC delete versions：GC 删除掉的每个 key 的版本个数
• GC tasks：由 gc_worker 处理的 GC 任务的个数
• GC tasks Duration：执行 GC 任务时所花费的时间
• GC keys (write CF)：在 GC 过程中，write CF 中 受影响的 key 的个数
• TiDB GC worker actions：TiDB GC worker 的不同 action 的个数
• TiDB GC seconds：TiDB 执行 GC 花费的时间
• GC speed：GC 每秒删除的 key 的数量
• TiKV AutoGC Working：Auto GC 管理器的工作状态
• ResolveLocks Progress：GC 第一阶段（ResolveLocks）的进度
• TiKV Auto GC Progress：GC 第二阶段的进度
• TiKV Auto GC SafePoint：TiKV GC 的 safe point 的数值，safe point 为当前 GC 的时间戳
• GC lifetime：TiDB 设置的 GC lifetime
• GC interval：TiDB 设置的 GC 间隔
Snapshot
• Rate snapshot message：发送 Raft snapshot 消息的速率
• 99% Handle snapshot duration：99% 的情况下，处理 snapshot 所需花费的时间
• Snapshot state count：不同状态的 snapshot 的个数
• 99.99% Snapshot size：99.99% 的 snapshot 的大小
• 99.99% Snapshot KV count：99.99% 的 snapshot 包含的 key 的个数
Task
• Worker handled tasks：worker 每秒钟处理的任务的数量
• Worker pending tasks：当前 worker 中，每秒钟 pending 和 running 的任务的数量，正常情况下，应该小于 1000
• FuturePool handled tasks：future pool 每秒钟处理的任务的数量
• FuturePool pending tasks：当前 future pool 中，每秒钟 pending 和 running 的任务的数量
Coprocessor Overview
• Request duration：从收到 coprocessor 请求到处理结束所消耗的总时间
• Total Requests：每种类型的总请求的 ops
• Handle duration：每分钟实际处理 coprocessor 请求所消耗的时间的直方图
• Total Request Errors：Coprocessor 每秒请求错误的数量，正常情况下，短时间内不应该有大量的错误
• Total KV Cursor Operations：各种类型的 KV cursor 操作的总数量的 ops，例如 select、index、analyze_table、analyze_index、checksum_table、checksum_index 等
• KV Cursor Operations：每秒各种类型的 KV cursor 操作的数量，以直方图形式显示
• Total RocksDB Perf Statistics：RocksDB 性能统计数据
• Total Response Size：coprocessor 回应的数据大小
Coprocessor Detail
• Handle duration：每秒钟实际处理 coprocessor 请求所消耗的时间的直方图
• 95% Handle duration by store：每秒钟中 95% 的情况下，每个 TiKV 实例处理 coprocessor 请求所花费的时间
• Wait duration：coprocessor 每秒钟内请求的等待时间，99.99% 的情况下，应该小于 10s
• 95% Wait duration by store：每秒钟 95% 的情况下，每个 TiKV 实例上 coprocessor 请求的等待时间
• Total DAG Requests：DAG 请求的总数量的 ops
• Total DAG Executors：DAG executor 的总数量的 ops
• Total Ops Details (Table Scan)：coprocessor 中请求为 select 的 scan 过程中每秒钟各种事件发生的次数
• Total Ops Details (Index Scan)：coprocessor 中请求为 index 的 scan 过程中每秒钟各种事件发生的次数
• Total Ops Details by CF (Table Scan)：coprocessor 中对于每个 CF 请求为 select 的 scan 过程中每秒钟各种事件发生的次数
• Total Ops Details by CF (Index Scan)：coprocessor 中对于每个 CF 请求为 index 的 scan 过程中每秒钟各种事件发生的次数
Threads
• Threads state：TiKV 线程的状态
• Threads IO：TiKV 各个线程的 I/O 流量
• Thread Voluntary Context Switches：TiKV 线程自主切换的次数
• Thread Nonvoluntary Context Switches：TiKV 线程被动切换的次数
RocksDB – kv/raft
• Get operations：get 操作的 ops
• Get duration：get 操作的耗时
• Seek operations：seek 操作的 ops
• Seek duration：seek 操作的耗时
• Write operations：write 操作的 ops
• Write duration：write 操作的耗时
• WAL sync operations：sync WAL 操作的 ops
• Write WAL duration：write 操作中写 WAL 的耗时
• WAL sync duration：sync WAL 操作的耗时
• Compaction operations：compaction 和 flush 操作的 ops
• Compaction duration：compaction 和 flush 操作的耗时
• SST read duration：读取 SST 所需的时间
• Write stall duration：由于 write stall 造成的时间开销，正常情况下应为 0
• Memtable size：每个 CF 的 memtable 的大小
• Memtable hit：memtable 的命中率
• Block cache size：block cache 的大小。如果将 shared block cache 禁用，即为每个 CF 的 block cache 的大小
• Block cache hit：block cache 的命中率
• Block cache flow：不同 block cache 操作的流量
• Block cache operations 不同 block cache 操作的个数
• Keys flow：不同操作造成的 key 的流量
• Total keys：每个 CF 中 key 的个数
• Read flow：不同读操作的流量
• Bytes / Read：每次读的大小
• Write flow：不同写操作的流量
• Bytes / Write：每次写的大小
• Compaction flow：compaction 相关的流量
• Compaction pending bytes：等待 compaction 的大小
• Read amplification：每个 TiKV 实例的读放大
• Compression ratio：每一层的压缩比
• Number of snapshots：每个 TiKV 的 snapshot 的数量
• Oldest snapshots duration：最旧的 snapshot 保留的时间
• Number files at each level：每一层的文件个数
• Ingest SST duration seconds：ingest SST 所花费的时间
• Stall conditions changed of each CF：每个 CF stall 的原因
Titan – All
• Blob file count：Titan blob 文件的数量
• Blob file size：Titan blob 文件总大小
• Live blob size：有效 blob record 的总大小
• Blob cache hit：Titan 的 blob cache 命中率
• Iter touched blob file count：单个 Iterator 所涉及到 blob 文件的数量
• Blob file discardable ratio distribution：blob 文件的失效 blob record 比例的分布情况
• Blob key size：Titan 中 blob key 的大小
• Blob value size：Titan 中 blob value 的大小
• Blob get operations：blob 的 get 操作的数量
• Blob get duration：blob 的 get 操作的耗时
• Blob iter operations：blob 的 iter 操作的耗时
• Blob seek duration：blob 的 seek 操作的耗时
• Blob next duration：blob 的 next 操作的耗时
• Blob prev duration：blob 的 prev 操作的耗时
• Blob keys flow：Titan blob 读写的 key 数量
• Blob bytes flow：Titan blob 读写的 bytes 数量
• Blob file read duration：blob 文件的读取耗时
• Blob file write duration：blob 文件的写入耗时
• Blob file sync operations：blob 文件 sync 次数
• Blob file sync duration：blob 文件 sync 耗时
• Blob GC action：Titan GC 细分动作的次数
• Blob GC duration：Titan GC 的耗时
• Blob GC keys flow：Titan GC 读写的 key 数量
• Blob GC bytes flow：Titan GC 读写的 bytes 数量
• Blob GC input file size：Titan GC 输入文件的大小
• Blob GC output file size：Titan GC 输出文件的大小
• Blob GC file count：Titan GC 涉及的 blob 文件数量
Lock manager
• Thread CPU：lock manager 的线程 CPU 使用率
• Handled tasks：lock manager 处理的任务数量
• Waiter lifetime duration：事务等待锁释放的时间
• Wait table：wait table 的状态信息，包括锁的数量和等锁事务的数量
• Deadlock detect duration：处理死锁检测请求的耗时
• Detect error：死锁检测遇到的错误数量，包含死锁的数量
• Deadlock detector leader：死锁检测器 leader 所在节点的信息
Memory
• Allocator Stats：内存分配器的统计信息
Backup
• Backup CPU：backup 的线程 CPU 使用率
• Range Size：backup range 的大小直方图
• Backup Duration：backup 的耗时
• Backup Flow：backup 总的字节大小
• Disk Throughput：实例磁盘的吞吐量
• Backup Range Duration：backup range 的耗时
• Backup Errors：backup 中发生的错误数量
Encryption
• Encryption data keys：正在使用的加密 data key 的总数量
• Encrypted files：被加密的文件数量
• Encryption initialized：显示加密是否被启用，1 代表已经启用
• Encryption meta files size：加密相关的元数据文件的大小
• Encrypt/decrypt data nanos：每次加密/解密数据的耗时的直方图
• Read/write encryption meta duration：每秒钟读写加密文件所耗费的时间
面板常见参数的解释
gRPC 消息类型
1. 使用事务型接口的命令：
• kv_get：事务型的 get 命令，获取指定 ts 能读到的最新版本数据
• kv_scan：扫描连续的一段数据
• kv_prewrite：2PC 的第一阶段，预写入事务要提交的数据
• kv_pessimistic_lock：对 key 加悲观锁，防止其他事务修改
• kv_pessimistic_rollback：删除 key 上的悲观锁
• kv_txn_heart_beat：更新悲观事务或大事务的 lock_ttl 以防止其被回滚
• kv_check_txn_status：检查事务的状态
• kv_commit：2PC 的第二阶段，提交 prewrite 阶段写入的数据
• kv_cleanup：回滚一个事务（此命令将会在 4.0 中废除）
• kv_batch_get：与 kv_get 类似，一次性获取批量 key 的 value
• kv_batch_rollback：批量回滚多个预写的事务
• kv_scan_lock：扫描所有版本号在 max_version 之前的锁，用于清理过期的事务
• kv_resolve_lock：根据事务状态，提交或回滚事务的锁
• kv_gc：触发垃圾回收
• kv_delete_range：从 TiKV 中删除连续的一段数据
2. 非事务型的裸命令：
• raw_get：获取 key 所对应的 value
• raw_batch_get：获取一批 key 所对应的 value
• raw_scan：扫描一段连续的数据
• raw_batch_scan：扫描多段连续的数据
• raw_put：写入一个 key/value 对
• raw_batch_put：直接写入一批 key/value 对
• raw_delete：删除一个 key/value 对
• raw_batch_delete：删除一批 key/value 对
• raw_delete_range：删除连续的一段区间
TiFlash 集群监控
本文介绍 TiFlash 集群的相关监控项及说明。
COPROCESSOR 相关监控
监控指标名称 监控指标说明
tiflash_coprocessor_request_count 收到的 coprocessor 请求数量，其中 batch 是 batch 请求数量，batch_cop 是 batch 请求中的 coprocessor 请求数量，cop 是直接通过 coprocessor 接口发送的 coprocessor 请求数量，cop_dag 是所有 coprocessor 请求中 dag 请求数量
tiflash_coprocessor_executor_count 每种 dag 算子的数量，其中 table_scan 是扫表算子，selection 是过滤算子，aggregation 是聚合算子，top_n 是 TopN 算子，limit 是 limit 算子
tiflash_coprocessor_request_duration_seconds 每个 coprocessor request 总时间直方图，总时间为接收到该 coprocessor 请求至请求应答完毕的时间，其中 batch 是 batch 请求的总时间，cop 是直接通过 coprocessor 接口发送的 coprocessor 请求总时间
tiflash_coprocessor_request_error coprocessor 请求的错误数量，其中 meet_lock 为读取的数据有锁，region_not_found 为 Region 不存在，epoch_not_match 为读取的 Region epoch 与本地不一致，kv_client_error 为与 TiKV 通信产生的错误，internal_error 为 TiFlash 内部系统错误，other 为其他错误
tiflash_coprocessor_request_handle_seconds 每个 coprocessor 请求处理时间直方图，处理时间为该 coprocessor 请求开始执行到执行结束的时间，其中 batch 是 batch 请求的处理时间，cop 是直接通过 coprocessor 接口发送的 coprocessor 请求处理时间
tiflash_coprocessor_response_bytes 应答总字节数
DDL 相关监控
监控指标名称 监控指标说明
tiflash_schema_version TiFlash 目前缓存的 schema 版本
tiflash_schema_apply_count 分为 diff apply、full apply 和 failed apply：diff apply 是正常的单次 apply 过程，如果 diff apply 失败，则 failed apply +1，并回退到 full apply
tiflash_schema_internal_ddl_count TiFlash 内部进行的具体 DDL 操作的总数
tiflash_schema_apply_duration_seconds 单次 apply schema 消耗的时间
Raft 相关监控
监控指标名称 监控指标说明
tiflash_raft_read_index_count coprocessor 触发 read_index 请求的次数，等于一个 coprocessor 触发的 Region 总数
tiflash_raft_read_index_duration_seconds read_index 消耗的时间，主要消耗时间在于和 leader 的交互和重试时间
tiflash_raft_wait_index_duration_seconds wait_index 消耗的时间，即拿到 read_index 请求后，等待 local index >= read_index 所花费的时间
来自 <https://www.bookstack.cn/read/TiDB-4.0/tiflash-monitor-tiflash.md>