1. PostgreSQL数据库监控的必要性
作为一款功能强大的开源关系型数据库，PostgreSQL在企业级应用中扮演着关键角色。但就像汽车需要定期保养一样，数据库也需要持续监控才能保持最佳性能。我管理过的生产环境中，90%的性能问题都源于监控盲区——等用户报障才发现问题就太迟了。
有效的监控能帮我们：
- 提前发现锁等待、连接池耗尽等潜在风险
- 快速定位慢查询和资源瓶颈
- 预测存储增长趋势避免突发磁盘告警
- 验证配置调整后的实际效果
2. 关键监控指标分类
2.1 连接与会话指标
连接数监控是最基础的防线。上周刚处理过一个案例：应用连接泄漏导致max_connections被占满，整个系统不可用。关键指标包括：
- 当前连接数：
SELECT count(*) FROM pg_stat_activity; - 空闲连接比例：
SELECT count(*) FILTER (WHERE state='idle') FROM pg_stat_activity; - 等待锁的连接数：
SELECT count(*) FROM pg_stat_activity WHERE wait_event_type='Lock';
建议设置告警阈值在max_connections的80%，并定期检查idle_in_transaction_session_timeout配置。
2.2 查询性能指标
慢查询是性能杀手，我习惯从三个维度监控：
- 平均查询耗时：
SELECT avg(total_time) FROM pg_stat_statements; - 最耗时的TOP 10查询：
SELECT query, calls, total_time, mean_time FROM pg_stat_statements ORDER BY total_time DESC LIMIT 10; - 临时文件使用量：
SELECT sum(temp_bytes) FROM pg_stat_database;
曾通过这个定位到一个报表查询未使用索引，优化后从12秒降到200ms。
2.3 复制与高可用指标
对于采用流复制的环境，这些指标关乎数据安全：
- 复制延迟：
SELECT pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) FROM pg_stat_replication; - 备库状态：
SELECT client_addr, state, sync_state FROM pg_stat_replication; - WAL归档状态：
SELECT archived_count, failed_count FROM pg_stat_archiver;
去年我们曾因网络抖动导致3小时复制延迟，现在设置延迟超过1GB就触发告警。
3. 存储与资源监控
3.1 表空间使用情况
磁盘写满的后果有多严重？我见过整个集群只读的惨剧。必查项包括：
- 数据库大小：
SELECT pg_size_pretty(pg_database_size(current_database())); - 表膨胀率：
SELECT schemaname, relname, pg_size_pretty(pg_relation_size(relid)) as size, n_dead_tup FROM pg_stat_user_tables ORDER BY n_dead_tup DESC; - 索引使用率：
SELECT schemaname, relname, indexrelname, idx_scan FROM pg_stat_user_indexes;
3.2 系统资源指标
操作系统层面的监控同样重要：
- CPU使用率：重点关注user%和iowait%
- 内存使用：检查shared_buffers实际使用率
- 磁盘IOPS：特别是WAL日志所在磁盘
- Swap使用：任何swap使用都值得警惕
4. 高级监控技巧
4.1 自定义监控项
除了常规指标，这些自定义监控往往能救命：
- 长事务监控：
SELECT pid, now()-xact_start FROM pg_stat_activity WHERE state<>'idle'; - 预备事务：
SELECT count(*) FROM pg_prepared_xacts; - 锁等待链：使用pg_blocking_pids()函数
4.2 监控工具选型
根据环境规模可选择：
- 轻量级：pgBadger + 自定义脚本
- 中等规模：Prometheus + Grafana（配postgres_exporter）
- 企业级：Datadog/NewRelic等商业方案
我们团队用Grafana搭建的监控看板包含37个关键指标，通过颜色区分健康状态。
5. 典型问题排查案例
5.1 连接池耗尽
现象：应用报"too many connections" 排查步骤：
- 检查连接来源：
SELECT client_addr, application_name, count(*) FROM pg_stat_activity GROUP BY 1,2 ORDER BY 3 DESC; - 确认是否有连接泄漏（应用未正确关闭连接）
- 检查连接池配置是否合理
5.2 查询性能退化
现象：平时很快的查询突然变慢 排查步骤：
- 检查执行计划是否改变：
EXPLAIN ANALYZE [问题查询] - 确认统计信息是否最新：
ANALYZE [相关表]; - 检查是否有锁冲突
6. 监控策略建议
根据多年经验，我建议采用分级监控策略：
- 实时告警：连接数、复制状态、磁盘空间等核心指标
- 每小时检查：慢查询、锁等待、事务时长
- 每日分析：表膨胀、索引效率、统计信息
- 每周汇总：趋势分析、容量规划
监控配置要随业务变化调整。去年双十一前，我们提前增加了连接数和磁盘空间的监控频率，成功避免了3次潜在事故。
