专栏 - TiDB 监控指标的取数方式研究

一、引言

在分布式数据库 TiDB 的日常运维中，监控指标的采集与使用至关重要。精准、实时地获取指标不仅是容量规划和性能优化的基础，也直接关系到告警体系与自动化诊断机制的构建。本文以 “存储空间使用量”（storage_size）为例，系统梳理 TiDB 中三种主流指标采集方法，探讨其优劣与适用场景，为实际运维提供可行参考。

二、指标和取数方式样例

TiDB 采用 Prometheus 作为核心指标采集系统，各组件（如 TiDB、PD、TiKV）通过 /metrics 接口暴露内部状态。

我们以 PD 的 storage_size 为例，来讲解取数方式。该指标位于 Grafana 面板中的：

[cluster-name] Overview → PD → Current storage size

取数方式一：通过 SQL 查询 METRICS_SCHEMA

mysql> select max(value/1024/1024/1024) as size_GiB from METRICS_SCHEMA.pd_cluster_status where type='storage_size' ;
+---------------------+
| size_GiB            |
+---------------------+
| 0.10942541062831879 |
+---------------------+
1 row in set (0.01 sec)

取数方式二：直接 curl PD/TiKV/TiDB 实例 /metrics 接口

curl -s 172.16.201.124:2379/metrics  | grep storage_size
pd_cluster_status{type="storage_size"} 1.1751836e+08

取数方式三：通过 Prometheus HTTP API 查询

 curl -G 'http://172.16.201.22:9090/api/v1/query' --data-urlencode 'query=pd_cluster_status{type="storage_size"} / 1024 / 1024 / 1024'
{"status":"success","data":{"resultType":"vector","result":[{"metric":{"instance":"172.16.201.124:3379","job":"pd","type":"storage_size"},"value":[1744856037.284,"0.10956016182899475"]}]}}

三、方式对比汇总


方式	优点	缺点
方式一：通过 SQL 查询 `METRICS_SCHEMA`	- 简单直观：几乎零学习成本，SQL 可以轻松处理数据成需要的，以便后续统一入库。比如行内基本需要汇总指标，SQL 可以轻松做到聚合。 - 取更多的数据库指标：有些指标属于数据库特有的，没有 metric ，也无法通过暴露 metric 实现，需要查询 information_schema 等系统库。	- 性能开销：对 metric 表做聚合等操作，可能有微量性能影响（metric 表都保留10分钟数据，数据量都很小，查询频率低的情况下，影响可忽略） - 数据精度有限：每个实例每个指标是1分钟产生一次记录，精度一般（可调整到精度与 prometheus 一致） - 权限要求高：需要有对 `METRICS_SCHEMA` 的查询权限 - 依赖 Prometheus：如果 prometheus 不可用，则 metric 表无数据。
方式二：直接 curl PD/TiKV/TiDB 实例 `/metrics` 接口	- 实时性好：直接从组件实例的 `/metrics` 接口拿到最新抓取值 - 易于脚本化：shell 一行命令即可完成抓取 - 不依赖 Prometheus：直接组件取数据并不依赖 Prometheus	- 自行解析：需自己写正则或 `grep`、`awk` 来提取字段和单位转换 - 安全性：对外暴露接口可能需要做访问控制 - 单实例：只能拿到单个节点的数据，若想聚合多实例需额外脚本
方式三：通过 Prometheus HTTP API 查询	- 集中化管理：Prometheus 已聚合了全量实例指标，查询时可自动汇总 - 强大查询能力：支持算术运算、函数、时间序列操作和历史数据回溯 - 可靠性高：Prometheus 会自动重试和缓存，接口稳定	- 依赖 Prometheus：如果 prometheus 不可用，则无法取 metric 数据。 - 学习成本：需掌握 PromQL 语法并维护查询表达式。 - 解析较复杂：返回 JSON，需要用 `jq` 等工具处理

四、结论与建议

不同指标采集方式适用于不同场景：

日常聚合分析：推荐使用 SQL 查询 METRICS_SCHEMA，便于统计和报表生成。
临时采样与排障：推荐使用 curl 访问组件 /metrics，实时性强、独立于 Prometheus。
告警与趋势分析：推荐使用 Prometheus API + PromQL，支持聚合、多实例与历史查询。

建议按指标类型、实时性需求及环境约束灵活选择，并注意接口权限和 Prometheus 的可用性保障。