PostgreSQL 的 Health Score：健康监控

PostgreSQL健康评分：数据库状态的综合指标

传统监控依赖数十个Grafana仪表盘，常导致仪表盘疲劳——运维人员忽视图表，告警要么频繁误报，要么响应过晚。健康评分通过整合150多个pg_stat_*指标，将数据库状态浓缩为0到100的单一分数，实现快速评估：95分以上为正常，低于70分需立即干预。

基础公式：健康评分 = 100 - Σ(惩罚值_i × 权重_i)。惩罚值采用非线性计算，能敏锐捕捉趋势与异常。这并非简单的阈值告警，而是一个复合指标，类似APM中的Apdex或医疗领域的EWS评分。

分类结构与计算逻辑

健康评分基于五个固定权重的类别构建，每个类别通过SQL查询分析PostgreSQL系统视图的关键指标。

连接数（权重 0.20）

衡量连接池饱和度与空闲状态：

SELECT 
    count(*) FILTER (WHERE state = 'active') AS active_connections,
    count(*) FILTER (WHERE state = 'idle in transaction') AS idle_in_transaction,
    (SELECT setting::int FROM pg_settings WHERE name = 'max_connections') AS max_connections,
    now() - min(xact_start) AS longest_transaction_age
FROM pg_stat_activity
WHERE pid != pg_backend_pid();

当连接使用率超过80%时，惩罚值呈指数增长。空闲事务超过30秒的会额外扣分，因其会阻塞自动清理并加剧数据膨胀。

性能（权重 0.25）

聚焦用户体验：缓存命中率与慢查询情况。

-- 缓存命中率
SELECT 
    round(100.0 * sum(heap_blks_hit) / nullif(sum(heap_blks_hit) + sum(heap_blks_read), 0), 2) AS cache_hit_ratio
FROM pg_statio_user_tables;

-- 慢查询统计
SELECT count(*), round(avg(mean_exec_time)::numeric, 2)
FROM pg_stat_statements
WHERE mean_exec_time > 1000 AND calls > 10;

命中率低于95%即触发惩罚，低于90%则属严重问题。执行时间对比历史基线，用于识别异常波动。

存储（权重 0.20）

监控死元组与数据膨胀情况：

SELECT 
    schemaname, relname, n_dead_tup, n_live_tup,
    round(100.0 * n_dead_tup / nullif(n_live_tup + n_dead_tup, 0), 2) AS dead_ratio,
    pg_size_pretty(pg_total_relation_size(relid))
FROM pg_stat_user_tables
WHERE n_live_tup + n_dead_tup > 10000
ORDER BY dead_ratio DESC LIMIT 20;

数据膨胀通过pgstattuple或基于relpages的启发式方法评估。磁盘使用量与文件系统限制进行比对。

复制（权重 0.15）

检测从库延迟：

SELECT application_name, state, (sent_lsn - replay_lsn) AS lag_bytes,
    write_lag, flush_lag, replay_lag
FROM pg_stat_replication;

延迟超过1MB或5秒即产生惩罚。若无从库，该类别不扣分。

维护（权重 0.20）

追踪VACUUM进度与XID年龄：

-- XID年龄
SELECT datname, age(datfrozenxid), 2147483648 - age(datfrozenxid)
FROM pg_database ORDER BY age(datfrozenxid) DESC;

-- VACUUM年龄
SELECT schemaname, relname, now() - greatest(last_vacuum, last_autovacuum) AS vacuum_age
FROM pg_stat_user_tables WHERE n_live_tup > 10000
ORDER BY vacuum_age DESC NULLS FIRST LIMIT 20;

XID年龄超过15亿将触发高惩罚，因存在事务ID回绕风险。

权重设定与解读逻辑

权重基于实测经验确定：性能权重最高（0.25），因其直接影响用户体验；连接与维护（0.20）为快速失效点；复制（0.15）为可选项。

• 95+：运行稳定
• 70–94：持续监控，规划修复
• 40–69：需立即处理
• <40：已进入事件状态

自动化诊断与优化建议

健康评分内置优先级问题清单：

• 高危：表中死元组占比超40%且最近一次VACUUM超过4天 —— 执行 VACUUM ANALYZE，调整 autovacuum_vacuum_scale_factor。
• 中等：复制延迟 >500ms —— 检查从库负载与 wal_receiver_timeout 设置。
• 低危：缓存命中率 <99% —— 将 shared_buffers 提升至物理内存的25%。

建议由规则引擎生成，包含对自动清理阈值的校验逻辑。

SELECT relname, n_dead_tup > (n_live_tup * current_setting('autovacuum_vacuum_scale_factor')::float + current_setting('autovacuum_vacuum_threshold')::float) AS vacuum_due
FROM pg_stat_user_tables;

核心价值总结

• 健康评分融合加权指标，揭示阈值告警难以发现的组合问题，如空闲事务叠加数据膨胀。
• 非线性算法在关键阈值前提供早期预警。
• 可通过postgres_exporter无缝集成Prometheus/Grafana。
• 自动诊断输出可操作建议，并附真实SQL示例。
• 具备可扩展性：通过历史趋势对比，精准识别异常。

— Editorial Team