摘要
数据库监控是保障业务稳定性的核心环节。本文系统讲解可观测性三支柱，详解 TiDB 内置的 Prometheus + Grafana 全链路监控方案，覆盖关键指标体系、告警规则与 TiDB Dashboard 一体化运维实践。本文适合 DBA、运维工程师、SRE 及架构师阅读。
一、为什么数据库监控至关重要
在生产环境中，数据库是绝大多数业务系统的核心依赖。一次数据库故障可能导致全站不可用，造成直接经济损失。数据库监控的核心目标包括：
- 故障发现：在用户感知之前识别异常，缩短 MTTR（平均恢复时间）
- 容量规划：基于历史数据预测资源需求，提前扩容
- 性能优化：定位慢查询、热点 Region、连接池瓶颈等性能问题
- 合规审计：满足金融、医疗等行业对系统可观测性的合规要求
根据 Gartner 报告，完善的可观测体系可将 MTTR 缩短 60% 以上。
二、可观测性三支柱
现代可观测性建立在三个核心支柱之上：
| 支柱 | 作用 | 工具示例 |
|---|---|---|
| 指标（Metrics） | 量化系统状态，适合趋势分析与告警 | Prometheus、OpenTSDB |
| 日志（Logs） | 记录离散事件，适合问题排查与审计 | ELK Stack、Fluentd |
| 链路追踪（Tracing） | 追踪请求全路径，适合延迟分析与依赖梳理 | Jaeger、OpenTelemetry |
三个支柱并非孤立存在，需协同配合才能构建完整的可观测体系。TiDB 的设计原生整合了这三者。
三、TiDB 内置 Prometheus + Grafana 监控方案
TiDB 从设计之初就内置了完整的监控栈，无需额外安装即可获得开箱即用的可观测能力。
3.1 架构概览
TiDB Cluster
├── TiDB Server ──────┐
├── TiKV Server ──────┤── PushMetrics ──► Prometheus ──► Grafana Dashboard
├── PD Server ────────┤ │
├── TiFlash ──────────┘ └── Alertmanager
│
└── TiDB Dashboard ────► 浏览器直接访问
3.2 组件说明
Prometheus：负责采集和存储所有 TiDB 组件的时序指标。每个 TiDB 节点内置 Prometheus 客户端，默认通过 9090 端口暴露指标。TiDB 部署时自动配置采集规则，支持 15 秒粒度数据采集。
Grafana：提供预置的可视化 Dashboard。TiDB 官方维护超过 20 个 Dashboard 模板，覆盖集群概览、性能分析、故障诊断等场景，导入即可使用。
Alertmanager：处理 Prometheus 告警路由与通知分发，支持邮件、Slack、钉钉、Webhook 等渠道。
四、关键监控指标体系
4.1 核心指标一览
| 指标类别 | 关键指标 | 健康阈值参考 |
|---|---|---|
| 吞吐量 | QPS（每秒查询数）、TPS（每秒事务数） | 基于业务基线，偏离 >30% 需关注 |
| 延迟 | P99/P95 查询延迟、事务提交延迟 | P99 < 100ms（OLTP 场景参考值） |
| 连接管理 | 活跃连接数、连接等待数 | 活跃连接 < max_connections 的 80% |
| Region 健康 | Region 数量、Peer 数量、副本健康率 | 缺副本 Region = 0 |
| 存储容量 | 磁盘使用率、TiKV 存储增长趋势 | 使用率 < 80%，触发扩容预警 |
| 错误率 | SQL 错误率、连接拒绝率、OOM 次数 | 错误率 < 0.1% |
4.2 Prometheus 关键查询示例
# TiDB QPS
sum(rate(tidb_server_query_total[1m])) by (instance)
# TiDB P99 查询延迟
histogram_quantile(0.99,
sum(rate(tidb_server_handle_query_duration_seconds_bucket[1m])) by (le, instance)
)
# TiKV Region 缺副本数量
sum(pd_cluster_region_health{state="missing_peer"})
# 磁盘使用率
(1 - (node_filesystem_avail_bytes{mountpoint="/data"} / node_filesystem_size_bytes{mountpoint="/data"})) * 100
五、TiDB Dashboard 一体化监控
TiDB Dashboard 是集成在 PD 组件中的 Web 管理界面，提供以下核心功能：
5.1 核心功能
- 集群概览：一键查看集群拓扑、节点状态、资源使用情况
- SQL 诊断：自动捕获慢查询，展示执行计划、耗时分布与优化建议
- Region 热点分析：可视化热点 Region 分布，辅助数据均衡决策
- 故障诊断：当集群出现问题时自动生成诊断报告，包含时间线与根因分析
- 性能分析：Continuous Profiling，持续采集 CPU 火焰图，定位代码级性能瓶颈
5.2 访问方式
# 通过 TiUP 查看 Dashboard 地址
tiup cluster display <cluster-name>
# 或直接访问 PD 地址
http://<pd-ip>:2379/dashboard
六、告警规则最佳实践
6.1 告警分级策略
| 级别 | 描述 | 响应时间 | 示例 |
|---|---|---|---|
| P0 - 紧急 | 服务不可用或数据丢失风险 | 5 分钟内 | TiKV 节点宕机、磁盘满 |
| P1 - 严重 | 性能严重下降或容量预警 | 15 分钟内 | P99 延迟 > 1s、Region 缺副本 |
| P2 - 警告 | 需关注但未影响业务 | 1 小时内 | 连接数接近上限、副本同步延迟 |
| P3 - 通知 | 信息性告警，无需立即处理 | 下个工作日 | 备份任务完成、证书即将过期 |
6.2 告警规则示例
groups:
- name: tidb_critical_alerts
rules:
- alert: TiKVNodeDown
expr: up{job="tikv"} == 0
for: 1m
labels:
severity: P0
annotations:
summary: "TiKV 节点 {{ $labels.instance }} 已宕机"
description: "该节点已持续 1 分钟不可达，请立即检查"
- alert: HighQueryLatency
expr: histogram_quantile(0.99, sum(rate(tidb_server_handle_query_duration_seconds_bucket[5m])) by (le)) > 1
for: 5m
labels:
severity: P1
annotations:
summary: "TiDB P99 查询延迟超过 1 秒"
description: "当前值: {{ $value }}s，持续 5 分钟"
6.3 告警降噪建议
- 设置合理的 `for` 持续时间，避免瞬态波动触发告警
- 利用标签聚合，避免同一问题产生大量重复告警
- 定期审查告警规则，关闭无效或噪音告警
- 配合自动化工具实现告警自愈（如自动扩容、节点替换）
七、监控方案部署建议
| 部署模式 | 适用场景 | 优势 |
|---|---|---|
| 随集群部署（推荐） | 生产环境 | 自动配置，零维护成本 |
| 独立监控集群 | 大规模多集群 | 统一管理，资源隔离 |
| 托管监控（TIFB） | 无运维团队或小规模部署 | 免运维，自动升级 |
八、总结
数据库监控不是可选项，而是生产环境的必备能力。TiDB 通过内置 Prometheus + Grafana + Dashboard，提供了从指标采集、可视化分析到智能告警的完整可观测方案，大幅降低了运维复杂度。建议企业根据自身业务规模，选择合适的部署模式，并持续完善告警规则与容量规划策略。
下一步行动
- 免费试用 TiDB：TiDB Cloud 免费试用 — 注册 TiDB Cloud，30 秒启动集群，自带完整监控面板
- 获取监控方案白皮书：TiDB 监控文档 — 查看官方监控架构详细文档
- 加入 TiDB 社区：TiDB 社区 — 与社区专家交流监控最佳实践
常见问题（FAQ）
Q1：TiDB 的监控组件会占用多少资源？
Prometheus 和 Grafana 各需约 2-4 GB 内存和 2-4 CPU 核心。建议监控组件与数据库节点分开部署，避免资源竞争。TiDB Cloud 托管模式下这些资源不计入用户配额。
Q2：如何自定义 Grafana Dashboard？
Grafana 支持通过 JSON 导入自定义 Dashboard。TiDB 官方提供 20+ 预置模板，可在 Grafana 的 Dashboard 导入功能中搜索 "tidb" 获取。自定义面板可通过 PromQL 查询任意指标。
Q3：TiDB 支持哪些告警通知渠道？
Alertmanager 原生支持 Email、Slack、企业微信、钉钉、PagerDuty、Webhook 等。通过 Webhook 还可对接飞书、Telegram 等平台，实现灵活的通知路由。
Q4：监控数据保留多久？
Prometheus 默认本地存储保留 15 天。生产环境建议配置 30-90 天保留期，或接入 Thanos/VictoriaMetrics 实现长期存储。TiDB Cloud 托管监控支持 30 天数据保留。
Q5：如何监控跨集群场景？
多集群部署时，建议使用 Thanos 或 Victoria Metrics 实现联邦查询，统一在一个 Grafana 中查看所有集群状态。TiDB Cloud 的 Organization 功能支持在控制台统一管理多个集群的监控视图。