生产部署
PgBouncer 目标、自动发现、凭据与 TLS,以及 systemd、Docker 与 Kubernetes。
快速上手
安装、连接、验证、抓取。 一个静态二进制读取一个 PostgreSQL 实例,并在 :9630 上应答。没有代理要部署,没有 sidecar 要调度,也不需要编译任何东西。
你只需要一个可达的 PostgreSQL 10–19+(或 PgBouncer 1.8+)实例,以及在其中创建角色的权限
整条路径
每一条都能独立验证,因此出错时你立刻知道该看链路的哪一半。
长期运行的主机用仓库软件包,其他场景用发布压缩包。
sudo apt install -y pg-exporterpg_monitor 自 PostgreSQL 10 起是内置角色,已覆盖默认采集器需要的全部读取权限。
GRANT pg_monitor TO monitor;连接串可以来自命令行参数、环境变量或密钥文件,但不该只留在你迟早会忘记的 shell 历史里。
export PG_EXPORTER_URL='postgres://monitor:S3cret@localhost:5432/postgres'--dry-run 打印合并后的采集器集合并退出;不带它则会监听 :9630。
pg_exporter --dry-run && pg_exporterpg_up 1 说明每一层都正常。只有到这一步,这个目标才该被写进 Prometheus 任务。
curl -s localhost:9630/metrics | grep '^pg_up '第 01 步
在 Linux amd64 上,发布压缩包是最短路径。托管软件包、其他平台、容器、Pigsty 与源码构建请使用下载页面。
确认安装结果:
RPM/DEB 路径额外提供升级路径、文件归属、/etc/default/pg_exporter,以及以 prometheus 用户运行的 systemd 单元。压缩包只给你二进制,服务定义要你自己负责。
第 02 步
在目标实例上创建一个专用的最小权限角色。自 PostgreSQL 10 起内置的 pg_monitor 角色授予默认采集器需要的全部读取权限——仅此而已。
只是用 postgres 这类超级用户在本地试一试?可以跳过这一步——但不要把这个捷径带到别人也能访问的主机上。
第 03 步
先解析配置,再真正启动。两条命令读取同一个连接串,因此拼写错误会在任何端口开始监听之前就暴露出来。
完全不提供 URL 时,pg_exporter 会回退到本地优先的默认值 postgresql:///?sslmode=disable,适合与 PostgreSQL 同机运行。完整优先级 —— --url › PG_EXPORTER_URL › PGURL › PG_EXPORTER_URL_FILE › 默认值 —— 记录在生产部署中。
在另一个终端拉取指标:
健康的目标长什么样
pg_up 1 说明整条链路已经打通——余下 600+ 指标(pg_db_*、pg_table_*、pg_wal_* ……)全部来自 pg_exporter.yml 中的声明式采集器定义。如果 pg_up 是 0,用 --log.level=debug 重启并阅读连接错误。
pg_up 1 # 目标可达时为 1,否则为 0
pg_in_recovery 0 # 从库为 1,主库为 0
pg_version 170000 # server_version_num 形式的版本号如果不对劲
导出器不仅暴露数据库指标,也暴露运维它自身所需的证据。先用 /explain 与 /stat,再去翻日志。
pg_up 0 —— 连接失败用 pg_exporter --log.level=debug 重启,并阅读它打印的错误。原因几乎总是三者之一:连接串指向了错误的主机、数据库或用户;pg_hba.conf 规则不允许监控角色从该地址接入;或者网络根本到不了那个端口。
直接问导出器。curl localhost:9630/explain 会打印每个采集器的规划结论——哪个分支被选中,哪个因为版本门限、角色不匹配、标签或谓词失败而被跳过。
curl localhost:9630/stat 返回按采集器统计的错误计数、耗时与缓存状态。非致命采集器的失败是隔离的:其余采集器照常上报,因此单条查询出问题不会让整个目标下线。
在 /stat 中找到最慢的采集器,然后要么调高它的 ttl 让结果跨抓取复用,要么在不需要时设置 skip: true。采集成本属于配置,而不是二进制的固有属性。
/stat、/explain 与 /reload 会描述并控制导出器本身。生产环境请用 --web.config.file 配置 TLS 与认证,或者把监听地址限制在可信网络内。