内置采集器

PG Exporter v1.4.1 在 config/ 中提供 58 个采集器定义文件，make conf 按文件名顺序将它们合并为默认的 pg_exporter.yml。

文件名前缀只负责排序，并不是指标名。一个文件可以为同一指标命名空间定义多个版本或角色分支。PG Exporter 启动时根据目标实例事实只安装符合条件的分支；对真实目标访问 GET /explain，即可查看最终执行计划。

编号分区

完整清单

启用前先看计划

不要把 58 个文件理解成 58 条无条件执行的查询。规划器会根据 PostgreSQL 或 PgBouncer 版本、恢复角色、目标数据库、扩展、模式、用户名与谓词结果筛选分支。调优前先检查真实计划：

curl -fsS http://127.0.0.1:9630/explain
curl -fsS http://127.0.0.1:9630/explain | jq '.[] | {name, status, reason}'

默认禁用的采集器必须经过有意识的审核。pg_origin、pg_shmem、两个膨胀采集器、TimescaleDB 采集器和 pg_heartbeat 都需要额外权限、辅助对象、特定扩展或明确的写入/读取流程，因此不会进入通用默认计划。

基数与开销

每对象和每查询采集器是主要的基数来源。在大规模环境中启用前重点检查：

• pg_table、pg_index、pg_func、pg_seq 会为每个对象产生一组或多组时序。
• pg_query 的规模随 pg_stat_statements 保留的归一化语句数量增长。
• pg_table_size、pg_table_bloat、pg_index_bloat 在关系很多时可能成本较高。
• 等待事件采样依赖扩展，并可能产生随负载变化的维度。

用采集器 ttl 缓存高成本结果，设置符合实际的单采集器 timeout，并让抓取间隔大于最慢采集器的预期耗时。变更前后都应比较 /metrics 的耗时与时序数量，不能只凭“配置验证通过”判断生产安全性。

安全定制

把本地覆盖放在独立配置目录中，不要直接修改生成的单体文件。只复制最小相关文件，确保所有顶层分支名全局唯一、版本范围不重叠，然后执行：

pg_exporter --config=/path/to/collectors --dry-run
PG_EXPORTER_CONFIG=/path/to/collectors pg_exporter
curl -fsS http://127.0.0.1:9630/explain
curl -fsS http://127.0.0.1:9630/metrics >/dev/null

采集器模式、查询到指标的映射、标签、谓词、缓存、超时与直方图规则详见采集器配置。