用夜莺监控 TiDB

TiDB、PD、TiKV 都通过 /metrics 暴露 Prometheus 指标，模板覆盖 SQL 延迟、Region 调度、存储和节点健康。

最后校对于 2026-10-13

TiDB 集群的各组件都自带 Prometheus 指标端点：TiDB Server 在 10080、PD 在 2379、TiKV 在 20180，TiFlash、TiCDC 等按各自配置。用 Categraf 的 prometheus 插件逐个抓取，或者直接把 TiUP 部署时自带的 Prometheus 接成夜莺数据源。

仪表盘依赖 k8s_cluster、tidb_cluster、job 和 instance 四个标签，非 Kubernetes 部署也要给前两个标签固定值。规则覆盖 TiDB 查询失败与慢查询、PD Region 异常、TiKV 存储和 Raft 延迟、组件宕机。

模板里有什么

• 1 张仪表盘，共 58 个面板
• 28 条告警规则，每条附处置步骤

怎么接入

这类组件自己就暴露 Prometheus 格式的 /metrics，用 Categraf 的 prometheus 插件抓取即可，不需要专门的插件。如果你已经有 Prometheus 或 VictoriaMetrics 在抓这些端点，直接把它接成夜莺的数据源，模板同样能用。

# conf/input.prometheus/tidb.toml
interval = 15

[[instances]]
urls = ["http://<tidb>:10080/metrics"]
labels = { job = "tidb", k8s_cluster = "", tidb_cluster = "prod" }

[[instances]]
urls = ["http://<pd>:2379/metrics"]
labels = { job = "pd", k8s_cluster = "", tidb_cluster = "prod" }

[[instances]]
urls = ["http://<tikv>:20180/metrics"]
labels = { job = "tikv", k8s_cluster = "", tidb_cluster = "prod" }

1. 在夜莺「集成中心」里找到 TiDB，把仪表盘和告警规则导入到业务组。
2. 导入的告警规则默认是停用的。先确认指标已经入库，再按自己环境的阈值逐条启用。

内置仪表盘

仪表盘	面板数
tidb-Overview	58

内置告警规则

共 28 条。每条给出触发条件（PromQL）和告警后的处置步骤，导入后可以直接改阈值。

TiDB-CPU 使用率大于 80%

TiDB(中控)

S2 警告 · 持续 1 分钟 · 触发条件:

avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by(instance) * 100 <= 20

处置步骤:

1. 用 top -H 定位是 tidb-server、tikv-server 还是其他进程占用；
2. TiKV 高 CPU 常见于 coprocessor 请求过多，查 TiDB 慢日志找扫描量大的 SQL；
3. TiDB 高 CPU 常见于复杂计算或大量小查询，看 Grafana 的 TiDB Query Summary；
4. 优化 SQL 后仍高则扩容节点。

TiDB-Node_exporter_is_down

TiDB(中控)

S1 紧急 · 持续 1 分钟 · 触发条件:

probe_success{group="node_exporter"} == 0

处置步骤:

1. 从告警标签取实例地址，先 ping/ssh 确认机器存活；
2. 到该节点确认对应进程是否运行、日志中有无 panic 或 OOM；
3. 进程存活但探测失败的排查端口监听与防火墙；
4. 用 tiup cluster display <集群名> 看整体拓扑状态，确认剩余节点是否仍满足多数派。

TiDB-PD 写盘延迟大于 1s ，leader 写盘慢会导致 leader 切换

TiDB(中控)

S3 提醒 · 持续 1 分钟 · 触发条件:

histogram_quantile(0.99, sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[1m])) by (instance,job,le) ) > 1

处置步骤:

1. 在 PD 节点用 iostat -x 1 确认磁盘 util 与 await，PD 必须用 SSD；
2. 确认 PD 数据目录未与 TiKV 数据盘混用；
3. 检查是否有其他进程在抢占该盘 IO；
4. 磁盘性能确实不足的，迁移 PD 到独立 SSD 是唯一根本解法。

TiDB-PD 无 leader

TiDB(中控)

S1 紧急 · 持续 1 分钟 · 触发条件:

sum(etcd_server_is_leader) !=1

处置步骤:

1. 用 pd-ctl member 查看各 PD 成员状态，确认存活节点是否已不足多数派；
2. 不足多数派的立即恢复宕掉的 PD 节点；
3. 节点都活着却选不出 leader 的，检查 PD 之间的网络连通性与时钟偏移；
4. 查各 PD 的日志定位选举失败原因，必要时按官方文档做 PD 恢复。

TiDB-PD 节点之间网络延迟大于 1s

TiDB(中控)

S3 提醒 · 持续 1 分钟 · 触发条件:

histogram_quantile(0.99, sum(rate(etcd_network_peer_round_trip_time_seconds_bucket[1m])) by (To,instance,job,le) ) > 1

处置步骤:

1. 在 PD 节点间用 mtr 确认延迟与丢包出现在哪一跳；
2. 确认 PD 节点是否被跨机房部署——PD 对网络延迟非常敏感，应同机房；
3. 检查网卡是否有错包丢包、带宽是否打满；
4. 联系网络侧排查，期间避免做大规模数据迁移加重网络压力。

TiDB-TCP 连接数大于 50000

TiDB(中控)

S2 警告 · 持续 1 分钟 · 触发条件:

node_netstat_Tcp_CurrEstab > 50000

处置步骤:

1. 用 ss -s 看连接状态分布，确认是 ESTABLISHED 还是 TIME_WAIT 为主；
2. 用 ss -tan | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn 定位连接来源；
3. 应用侧未复用连接的改用连接池；
4. TIME_WAIT 为主的开启 tcp_tw_reuse 并调大端口范围。

TiDB-TiDB_server_is_down

TiDB(中控)

S1 紧急 · 持续 1 分钟 · 触发条件:

probe_success{group="tidb"} == 0

处置步骤:

1. 从告警标签取实例地址，先 ping/ssh 确认机器存活；
2. 到该节点确认对应进程是否运行、日志中有无 panic 或 OOM；
3. 进程存活但探测失败的排查端口监听与防火墙；
4. 用 tiup cluster display <集群名> 看整体拓扑状态，确认剩余节点是否仍满足多数派。

TiDB-blackbox_is_down

TiDB(中控)

S1 紧急 · 持续 1 分钟 · 触发条件:

probe_success{group="blackbox_exporter"} == 0

处置步骤:

1. 从告警标签取实例地址，先 ping/ssh 确认机器存活；
2. 到该节点确认对应进程是否运行、日志中有无 panic 或 OOM；
3. 进程存活但探测失败的排查端口监听与防火墙；
4. 用 tiup cluster display <集群名> 看整体拓扑状态，确认剩余节点是否仍满足多数派。

TiDB-drainer_server_is_down

TiDB(中控)

S1 紧急 · 持续 1 分钟 · 触发条件:

probe_success{group="drainer"} == 0

处置步骤:

1. 从告警标签取实例地址，先 ping/ssh 确认机器存活；
2. 到该节点确认对应进程是否运行、日志中有无 panic 或 OOM；
3. 进程存活但探测失败的排查端口监听与防火墙；
4. 用 tiup cluster display <集群名> 看整体拓扑状态，确认剩余节点是否仍满足多数派。

TiDB-grafana_is_down

TiDB(中控)

S1 紧急 · 持续 1 分钟 · 触发条件:

probe_success{group="grafana"} == 0

处置步骤:

1. 从告警标签取实例地址，先 ping/ssh 确认机器存活；
2. 到该节点确认对应进程是否运行、日志中有无 panic 或 OOM；
3. 进程存活但探测失败的排查端口监听与防火墙；
4. 用 tiup cluster display <集群名> 看整体拓扑状态，确认剩余节点是否仍满足多数派。

TiDB-pd_server_is_down

TiDB(中控)

S1 紧急 · 持续 1 分钟 · 触发条件:

probe_success{group="pd"} == 0

处置步骤:

1. 从告警标签取实例地址，先 ping/ssh 确认机器存活；
2. 到该节点确认对应进程是否运行、日志中有无 panic 或 OOM；
3. 进程存活但探测失败的排查端口监听与防火墙；
4. 用 tiup cluster display <集群名> 看整体拓扑状态，确认剩余节点是否仍满足多数派。

TiDB-pump_server_is_down

TiDB(中控)

S1 紧急 · 持续 1 分钟 · 触发条件:

probe_success{group="pump"} == 0

处置步骤:

1. 从告警标签取实例地址，先 ping/ssh 确认机器存活；
2. 到该节点确认对应进程是否运行、日志中有无 panic 或 OOM；
3. 进程存活但探测失败的排查端口监听与防火墙；
4. 用 tiup cluster display <集群名> 看整体拓扑状态，确认剩余节点是否仍满足多数派。

TiDB-tidb CPU 使用率超过可用 CPU的 80%

TiDB(中控)

S2 警告 · 持续 1 分钟 · 触发条件:

rate(process_cpu_seconds_total{job="tidb"}[1m]) > tidb_server_maxprocs{job="tidb"} * 0.8

处置步骤:

1. 看 Grafana 的 TiDB Query Summary 找 QPS 与耗时最高的语句类型；
2. 用 TiDB 慢日志定位具体 SQL，检查是否缺索引导致大量数据回表；
3. 确认 tidb_server_maxprocs 配置是否与容器/机器规格匹配；
4. 优化 SQL 后仍高则扩容 tidb-server 实例。

TiDB-tidb 最近 15 分钟加载 schema 出现错误

TiDB(中控)

S1 紧急 · 持续 1 分钟 · 触发条件:

increase(tidb_session_schema_lease_error_total{type="outdated"}[15m]) > 0

处置步骤:

1. 查该 tidb-server 的日志搜 schema lease 相关报错；
2. 常见根因是该实例与 PD/TiKV 网络不稳，或 GC 压力大导致租约续期失败；
3. 确认是否有长时间运行的大事务阻塞 schema 变更；
4. 单实例问题可先摘流量重启该实例，全局问题需排查 PD 与网络。

TiDB-tidb 最近五分钟出现跳过 binlog

TiDB(中控)

S2 警告 · 持续 1 分钟 · 触发条件:

increase( tidb_server_critical_error_total[5m] ) > 0

处置步骤:

1. 查 tidb-server 日志搜 critical error 与 binlog 相关记录，确认跳过的原因与范围；
2. 检查 pump/drainer 是否可用——写不进 binlog 是最常见原因；
3. 确认下游数据是否已缺失，必要时用工具做数据校验与补齐；
4. 修复 binlog 链路后持续观察，确认不再跳过。

TiDB-tidb 最近十分钟加载 schema 失败大于 10 次

TiDB(中控)

S1 紧急 · 持续 1 分钟 · 触发条件:

increase( tidb_domain_load_schema_total{type="failed"}[10m] ) > 10

处置步骤:

1. 查该实例日志确认失败的具体报错；
2. 排查到 PD/TiKV 的网络连通性与延迟；
3. 确认是否有 DDL 长时间卡住（ADMIN SHOW DDL JOBS）阻塞了 schema 版本推进；
4. 卡住的 DDL 可用 ADMIN CANCEL DDL JOBS 取消后重做。

TiDB-tiflash_server_is_down

TiDB(中控)

S1 紧急 · 持续 1 分钟 · 触发条件:

probe_success{group="tiflash"} == 0

处置步骤:

1. 从告警标签取实例地址，先 ping/ssh 确认机器存活；
2. 到该节点确认对应进程是否运行、日志中有无 panic 或 OOM；
3. 进程存活但探测失败的排查端口监听与防火墙；
4. 用 tiup cluster display <集群名> 看整体拓扑状态，确认剩余节点是否仍满足多数派。

TiDB-tikv 5分钟内内存增长大于 5G

TiDB(中控)

S3 提醒 · 持续 1 分钟 · 触发条件:

process_resident_memory_bytes{job=~"tikv",instance=~".*"} - (process_resident_memory_bytes{job=~"tikv",instance=~".*"} offset 5m) > 5*1024*1024*1024

处置步骤:

1. 用 TiDB 慢日志与 Grafana 的 TiKV Coprocessor 面板定位是否有超大范围扫描的 SQL；
2. 必要时 KILL 该查询止血；
3. 检查 block-cache-size 配置是否超过物理内存的合理比例（建议不超过 45%）；
4. 若为实例刚启动的正常预热，可忽略但需确认后续趋于平稳。

TiDB-tikv 发生重启

TiDB(中控)

S1 紧急 · 持续 1 分钟 · 触发条件:

changes(process_start_time_seconds{job="tikv"}[5m]) > 0

处置步骤:

1. 查 tikv 日志尾部与 dmesg -T | grep -i 'killed process'，区分崩溃、被 OOM 杀死、人工重启；
2. OOM 的核对 block-cache-size 与机器内存；
3. panic 的收集日志并对照 TiDB 版本的已知问题；
4. 重启后用 pd-ctl store 确认该 store 已恢复 Up 且 region 已重新均衡。

TiDB-tikv 可用空间低于 20%

TiDB(中控)

S2 警告 · 持续 1 分钟 · 触发条件:

sum(tikv_store_size_bytes{type="available"}) by (instance) / sum(tikv_store_size_bytes{type="capacity"}) by (instance) < 0.2

处置步骤:

1. 用 pd-ctl store 看各 store 的容量与使用率，确认是个别还是普遍；
2. 个别节点满的检查 region 是否分布不均，用 pd-ctl 调整调度；
3. 普遍满的必须扩容 TiKV 节点；
4. 确认 GC 是否正常运行（GC life time 是否被设得过长导致旧版本堆积）。

TiDB-tikv_server_is_down

TiDB(中控)

S1 紧急 · 持续 1 分钟 · 触发条件:

probe_success{group="tikv"} == 0

处置步骤:

1. 从告警标签取实例地址，先 ping/ssh 确认机器存活；
2. 到该节点确认对应进程是否运行、日志中有无 panic 或 OOM；
3. 进程存活但探测失败的排查端口监听与防火墙；
4. 用 tiup cluster display <集群名> 看整体拓扑状态，确认剩余节点是否仍满足多数派。

TiDB-内存使用大于 80%

TiDB(中控)

S2 警告 · 持续 1 分钟 · 触发条件:

(((node_memory_MemTotal_bytes-node_memory_MemFree_bytes-node_memory_Cached_bytes)/(node_memory_MemTotal_bytes)*100)) >= 80

处置步骤:

1. 用 ps aux --sort=-%mem | head 确认是哪个进程占用最高；
2. TiKV 内存高优先核对 block-cache-size；TiDB 内存高排查是否有大查询未设 mem-quota-query；
3. 设置 tidb_mem_quota_query 限制单查询内存；
4. 确认无泄漏后仍不足的，扩内存或迁移实例。

TiDB-挂载点状态变为只读

TiDB(中控)

S1 紧急 · 持续 1 分钟 · 触发条件:

node_filesystem_readonly{fstype=~"(ext.|xfs)"} == 1

处置步骤:

1. 用 dmesg -T | grep -iE 'i/o error|remount|read-only' 确认触发原因；
2. 用 smartctl -a /dev/sdX 检查磁盘健康，多数是坏道；
3. 立即把该节点上的服务下线（pd-ctl store delete 或 tiup 摘除），避免继续尝试写入；
4. 换盘后重新加入集群并等待数据回补。

TiDB-文件系统 inode 使用率大于 80%

TiDB(中控)

S1 紧急 · 持续 1 分钟 · 触发条件:

node_filesystem_files_free{fstype=~"(ext.|xfs)"} / node_filesystem_files{fstype=~"(ext.|xfs)"} * 100 < 20

处置步骤:

1. 用 df -i 确认是哪个挂载点；
2. 逐层统计文件数找出小文件最多的目录；
3. TiDB 场景常见是日志文件未轮转清理，先清理旧日志；
4. 长期可调整日志保留策略或格式化时提高 inode 密度。

TiDB-磁盘使用率大于 80%

TiDB(中控)

S1 紧急 · 持续 1 分钟 · 触发条件:

node_filesystem_avail_bytes{fstype=~"(ext.|xfs)", mountpoint!~"/boot"} / node_filesystem_size_bytes{fstype=~"(ext.|xfs)", mountpoint!~"/boot"} * 100 <= 20

处置步骤:

1. 用 df -h 与 du -x --max-depth=1 定位占用最大的目录；
2. TiDB 节点常见是日志与慢日志堆积，先清理；
3. TiKV 数据盘满的需扩容或加节点，并确认 GC 正常运行；
4. 用 lsof +L1 检查已删除但句柄未释放的文件。

TiDB-网卡-入向有丢包

TiDB(中控)

S2 警告 · 持续 1 分钟 · 触发条件:

increase(net_drop_in[1m]) > 0

处置步骤:

1. 用 ip -s link show <网卡> 与 ethtool -S <网卡> 确认丢包计数与原因；
2. 环形缓冲区不足的用 ethtool -G <网卡> rx 调大；
3. 确认带宽是否打满——大规模 region 迁移会打满网卡；
4. 必要时用 pd-ctl 调低调度并发（leader-schedule-limit、region-schedule-limit）。

TiDB-网卡-出向有丢包

TiDB(中控)

S2 警告 · 持续 1 分钟 · 触发条件:

increase(net_drop_out[1m]) > 0

处置步骤:

1. 用 ip -s link show <网卡> 与 ethtool -S <网卡> 确认发送侧丢包；
2. 调大 txqueuelen 与发送队列；
3. 确认是否跑满带宽，必要时降低 PD 调度并发；
4. 排查网卡驱动与对端交换机端口状态。

TiDB-集群中出现状态为 down 的 tikv 数量大于 0

TiDB(中控)

S1 紧急 · 持续 1 分钟 · 触发条件:

(sum(pd_cluster_status{type="store_down_count"}) by (instance) > 0) and (sum(etcd_server_is_leader) by (instance) > 0)

处置步骤:

1. 用 pd-ctl store 确认是哪个 store、down 了多久；
2. 到该节点确认 tikv 进程与磁盘状态；
3. 短时间内能恢复的尽快拉起，避免 PD 触发大规模副本补充造成额外负载；
4. 确实无法恢复的用 pd-ctl store delete <id> 优雅下线，让数据有序迁走。

相关链接

• [TiDB 模板源文件](https://github.com/ccfos/nightingale/tree/main/integrations/TiDB）：仪表盘、规则和采集配置的 JSON 原文，欢迎提 PR。
• 导入仪表盘和告警规则
• 核对指标是否入库
• 全部集成目录