Telegraf procstat监控PostgreSQL时running=0i异常问题排查

核心问题在于：PostgreSQL进程实际正常运行（可通过psql连接），但postgresql-10.service的MainPID=0，导致Telegraf的procstat插件无法识别到运行中的进程，返回running=0i。结合服务处于disabled状态，本质原因是PostgreSQL并未通过postgresql-10.service这个systemd单元启动，而是通过命令行、自定义脚本等方式直接启动，导致systemd单元未关联到实际运行的进程实例。

排查步骤 #

1. 确认PostgreSQL进程的启动来源

   • 执行ps aux | grep postgres定位PostgreSQL主进程的PID
   • 执行pstree -p <postgres主PID>查看进程树，若父进程不是systemd（PID=1），说明进程并非由systemd管理
   • 执行systemctl status postgresql-10.service，异常机器会显示服务处于inactive状态，与实际运行的进程形成矛盾

2. 验证进程与systemd单元的关联关系

   • 执行systemctl is-active postgresql-10.service，异常机器会返回inactive
   • 查看进程的cgroup归属：cat /proc/<postgres主PID>/cgroup，若输出中不包含system.slice/postgresql-10.service，则证明进程不属于该systemd单元

解决办法 #

方法1：通过systemd重新管理PostgreSQL（推荐） #

这是最规范的解决方式，能恢复systemd对PostgreSQL的监控、自动重启、日志管理等能力：

1. 停止当前运行的PostgreSQL进程：

   sudo su - postgres -c "pg_ctl stop -D /var/lib/pgsql/10/data"
   

   （注意：替换为实际的PostgreSQL数据目录路径）
2. 启用并启动systemd服务：

   sudo systemctl enable postgresql-10.service
   sudo systemctl start postgresql-10.service
   

3. 验证：执行systemctl show postgresql-10.service | grep MainPID，应返回非0的有效PID；此时Telegraf procstat插件会正常返回running=1i

方法2：调整Telegraf procstat配置（临时替代方案） #

若暂时无法切换到systemd管理，可修改procstat配置，直接匹配进程属性而非依赖systemd单元：

[[inputs.procstat]]
  pattern = "postgres"
  user = "postgres"

或者通过可执行文件路径匹配：

[[inputs.procstat]]
  exe = "/usr/pgsql-10/bin/postgres"

方法3：修复Ansible部署脚本 #

由于所有机器通过Ansible批量部署，需检查剧本中的PostgreSQL启动逻辑：

• 确保剧本中执行systemctl enable --now postgresql-10.service，而非直接调用pg_ctl启动进程
• 排查是否存在自定义启动脚本，覆盖了systemd的启动流程，导致进程脱离systemd管控

内容的提问来源于stack exchange，提问作者GUISSOUMA Issam