配置参考
pg_exporter 的所有业务指标都由 YAML 采集器(Collector)定义驱动:每个采集器就是一条 SQL 查询,外加它的执行条件(版本、角色、标签、谓词)与运行控制(缓存、超时)。本页是采集器定义的完整参考。
配置可以是单个 YAML 文件(如默认的 pg_exporter.yml),也可以是包含多个 YAML 文件的目录——官方默认配置包正是由 config/ 目录下 58 个 YAML 文件(57 个采集器文件与 1 个配置参考文件)按字典序合并而来;共 96 个分支、59 个命名空间、460 个去重后的指标定义,包含默认禁用的采集器与 2 个尚未展开的直方图定义。
配置加载
PG Exporter 按以下顺序搜索配置:
- 命令行参数:
--config=/path/to/config - 环境变量:
PG_EXPORTER_CONFIG=/path/to/config - 当前目录:
./pg_exporter.yml - 系统配置文件:
/etc/pg_exporter.yml - 系统配置目录:
/etc/pg_exporter/
目录模式说明:
- 仅加载该目录下的
.yml/.yaml文件(非递归) - 按文件名字典序合并;同名采集器以后加载者覆盖先前定义
- 如果目录中有 YAML 文件但全部解析失败,导出器会直接返回错误而不是静默忽略
- 部分文件解析失败时记录错误,仍加载其余有效文件;目录加载并非全有或全无
- 空的单个 YAML 文件是合法空配置;重载它会清空采集器。解析失败的重载则保留原计划与缓存
采集器结构
每个采集器是 YAML 配置中的一个顶级对象,具有唯一名称和多种属性:
配置校验约束:
- 每个
metrics列表项必须且只能定义一个列映射 - 每个采集器至少要有一个
GAUGE/COUNTER/HISTOGRAM列 usage仅支持GAUGE/COUNTER/HISTOGRAM/LABEL/DISCARDHISTOGRAM列必须定义bucket:有限、严格递增的桶上界列表,+Inf桶自动追加- 指标名、标签名会在加载阶段进行 Prometheus 规则校验,非法配置会直接报错
- 常量标签会在加载阶段检查冲突;它们不能与查询标签重名,也不能与内置动态标签
datname/query冲突;配置了HISTOGRAM采集器时,le为保留标签,不能用作常量标签 - SQL 查询结果必须包含所有声明为
LABEL的列;自v1.4.1起,缺少任一标签列都会使该采集器本轮采集失败,不再生成空标签或沿用旧结果,其他非致命采集器不受影响 - 如果使用单行内联
metrics写法,description建议始终使用双引号包裹,避免 YAML 歧义
核心配置元素
采集器分支名称
顶级键在整个配置中唯一标识一个采集器:
查询定义
检索指标的 SQL 查询:
指标类型
查询结果中的每一列必须映射到一个指标类型:
| 用途 | 描述 | 示例 |
|---|---|---|
GAUGE | 可上下波动的瞬时值 | 当前连接数 |
COUNTER | 只增不减的累计值 | 总事务数 |
HISTOGRAM | 快照直方图,派生 _bucket / _count / _sum 序列 | 事务年龄分布 |
LABEL | 用作 Prometheus 标签 | 数据库名称 |
DISCARD | 忽略此列 | 内部值 |
直方图列(HISTOGRAM)
v1.4.0 引入 HISTOGRAM 列类型:查询返回的每一行都作为一次观测,按标签组聚合为经典
Prometheus 直方图快照,派生 <name>_bucket(含 le 标签与 +Inf 桶)、<name>_count、
<name>_sum 三族序列:
使用注意:
- 这是 快照 直方图:每次抓取重建整个分布,桶计数可增可减,语义上更接近 Gauge。
histogram_quantile()可以直接使用,但对_count/_sum使用rate()/increase()没有意义 - SQL
NULL默认忽略不计入观测;显式配置default时按默认值计入 scale在分桶前应用于观测值;与标量列一致,时间戳与布尔值不受scale影响- 默认配置包中的
pg_xact_age采集器即为参考实现
缓存控制(TTL)
ttl 参数控制结果缓存:
最佳实践:
- 将 TTL 设置为小于您的抓取间隔
- 对昂贵的查询使用较长的 TTL
- TTL 为 0 表示禁用缓存
ttl与谓词ttl必须为非负有限数,且转换为 Gotime.Duration后不能溢出;v1.5.0 拒绝 NaN、无穷大和过大的值
超时控制
防止查询运行时间过长:
timeout: 0 或省略该字段使用默认 100ms;有限负值关闭查询期限。v1.5.0 拒绝 NaN、无穷大和转换后会溢出的正超时。超时覆盖本次谓词与主查询的总执行时间。
版本兼容性
控制哪些 PostgreSQL 版本可以运行此采集器:
版本号使用 PostgreSQL 内部 server_version_num 规则:
100000表示 10.0130002表示 13.2160001表示 16.1190000表示 19.090600表示 9.6(Legacy 配置场景)
执行模型
理解一个采集器从定义到产出指标的完整路径,有助于回答"为什么这个指标没出来":
- 规划(首次抓取、热重载或元数据变化时):对每个采集器分支依次检查——目标类型(PostgreSQL / pgBouncer)、
min_version/max_version版本门槛、tags与服务器角色及 exporter 标签的匹配、skip开关。未通过的分支不会安装到该目标上。curl localhost:9630/explain展示的正是这一步的裁决结果。 - 抓取(每次
/metrics请求):对已安装的采集器——缓存在ttl内则直接返回缓存结果;否则先执行predicate_queries(任一返回假则本轮跳过,pg_exporter_query_scrape_predicate_skip_count计数),再在timeout限制下执行主查询,结果转为指标并写入缓存。 - 失败语义:普通采集器失败只影响自身(
pg_exporter_query_scrape_error_count上升,本轮缺失该组指标);标记fatal: true的采集器失败会使整次服务器抓取被判定为失败。
v1.5.0 在成功预检后比较用户名、Schema 与扩展集合;变化时重新规划,新增/删除扩展或 Schema 无需手动重载。集合不变时保留计划与缓存,重新规划会重置查询缓存和统计。
标签系统
标签控制采集器的执行时机和位置:
内置标签
| 标签 | 描述 |
|---|---|
cluster | 每个 PostgreSQL 集群执行一次 |
primary / master | 仅在主服务器上执行 |
standby / replica | 仅在从服务器上执行 |
pgbouncer | 仅用于 pgBouncer 连接 |
前缀标签
| 前缀 | 示例 | 描述 |
|---|---|---|
dbname: | dbname:postgres | 仅在特定数据库上执行 |
username: | username:monitor | 仅使用特定用户时执行 |
extension: | extension:pg_stat_statements | 仅当扩展已安装时执行 |
schema: | schema:public | 仅当模式存在时执行 |
not: | not:slow | 当导出器没有该标签时执行 |
自定义标签
向导出器传递自定义标签:
然后在配置中使用:
谓词查询
在执行主查询之前进行条件检查:
只有当所有谓词返回 true 时,主查询才会执行。
指标定义
基本定义
高级选项
采集器组织
PG Exporter 自带预先组织好的采集器:
| 范围 | 类别 | 描述 |
|---|---|---|
| 0xx | 文档 | 示例和文档 |
| 1xx | 基础 | 服务器信息、设置、元数据 |
| 2xx | 复制 | 复制、槽位、接收器 |
| 3xx | 持久化 | I/O、检查点、WAL |
| 4xx | 活动 | 连接、锁、查询 |
| 5xx | 进度 | Vacuum、索引创建进度 |
| 6xx | 数据库 | 每数据库统计 |
| 7xx | 对象 | 表、索引、函数 |
| 8xx | 可选 | 昂贵/可选指标 |
| 9xx | pgBouncer | 连接池指标 |
| 10xx+ | 扩展 | 扩展特定指标 |
实际示例
简单的 Gauge 采集器
带标签的 Counter
版本特定采集器
扩展依赖采集器
自定义采集器
创建自己的指标
- 在配置目录中创建新的 YAML 文件:
- 测试您的采集器:
条件指标
使用谓词查询实现条件指标:
性能优化
查询优化技巧
使用适当的 TTL 值:
- 快速查询:1-10 秒
- 中等查询:10-60 秒
- 昂贵查询:300-3600 秒
设置合理的超时:
- 默认:100ms
- 复杂查询:500ms-1s
- 生产环境中不要禁用超时
使用集群级标签:
禁用昂贵的采集器:
监控采集器性能
检查采集器执行统计:
指标与告警的升级检查
升级 Exporter 时,应合并并部署配套采集器 YAML。只替换二进制不会应用 SQL、标签或状态编码修正;在 Pigsty 管理的实例上,还应确认最终部署的配置包含这些定义。升级 PostgreSQL 大版本时,必须重新检查按版本选中的采集器分支。
- Exporter v1.4.1 → v1.5.0: 内置 SQL 指标名、类型与单位不变,但
pg_sub_*增加datname,pg_recv_state修正状态编码。检查跨库同名订阅的连接/聚合,以及 Grafana 值映射。 - PG18 → PG19: 已有指标没有删除或改名,但
pg_sub_sync_error_count扩大为表与序列同步错误之和,pg_subrel_count也包含序列。pg_sub_has_worker可区分订阅行存在与 apply worker 运行;不能只看pg_sub_id是否存在。 - 跨越 PG17/18: 部分
pg_bgwriter_*指标需要改用pg_checkpointer_*或按后端筛选的 I/O 指标;pg_wal_write、pg_wal_sync、pg_wal_write_time、pg_wal_sync_time自 PG18 起需要迁移到pg_io_*{object="wal"},并调整标签聚合。逐项替代关系见 兼容性对照表。
完整变更见 v1.5.0 发布说明 和 PG19 指标对照表。PG19 支持最早随 v1.3.0 发布,验收证据对应 19 RC1;这些说明不表示所有仪表盘已通过运行验收。
部署前后检查 /metrics、/explain、/stat、pg_exporter_query_scrape_error_count 和日志,再执行实际仪表盘、记录规则与告警表达式,检查返回时序、标签、单位和状态映射。用 promtool check rules 检查规则语法,并用 promtool test rules 覆盖正常输入和时序缺失。HTTP 200、up == 1 或 pg_up == 1 都不能证明每个预期指标存在;空向量也不等于健康的零值。
对预期启用内置 WAL 采集器的 PG19 目标,可使用以下逐目标缺失检查,并在告警规则中设置 for: 5m:
job="pg19" 只是示例,须替换为实际目标选择器,并按部署方式补齐匹配标签;分别监控 up 和 pg_up 故障。缺失检查须考虑版本、主备角色与对象是否存在,例如主库不应要求 pg_recovery_state_*。不要用无条件 or vector(0) 掩盖缺失;整个集群的 absent(metric) 也无法识别其他目标仍有数据时的单目标缺失。完整规则见 缺失指标检查。
配置故障排查
验证配置
常见问题
| 问题 | 解决方案 |
|---|---|
| 指标缺失 | 检查标签和版本兼容性 |
| 抓取缓慢 | 增加 TTL、添加超时、禁用昂贵查询 |
| 内存使用高 | 减少结果集大小,使用 LIMIT |
| 权限错误 | 验证监控用户的查询权限 |
调试日志
启用调试日志进行故障排查:
这个页面对您有帮助吗?
感谢反馈,我们会据此改进这篇文档。
哪里没有解决?(可选)