企业官网建设流程全解析

PostgreSQL的图形化监控，这个话题我本来以为没什么好说的，毕竟网上教程一抓一大把。但真到自己给生产环境搞监控的时候，才发现能把"看图表"和"懂指标"这两件事同时做明白的工具，远比想象中少。尤其是我经历过一次凌晨三点被慢查询拖垮、却连瓶颈在哪都说不清楚的尴尬之后，才认真把市面上主流的方案挨个试了一遍。这篇文章就把我实际部署和对比的体会写下来，希望能帮你少走点弯路。

1. 先搞清楚监控要看什么：命令行里看不见的维度

很多人一上来就纠结选哪个工具，其实方向错了。选工具之前，得先明白PostgreSQL监控到底需要盯哪些东西。这不是废话，而是我对比之后发现，不同工具的侧重点差异极大，有的擅长看数据库内部状态，有的擅长看操作系统资源，有的则盯着SQL执行计划不放。

1.1 原生视图能告诉你的，和不能告诉你的

PostgreSQL自带的pg_stat_activity和pg_stat_statements视图，是任何监控方案的数据源头。前者告诉你当前有哪些连接、在跑什么SQL、锁等待情况如何；后者则是SQL性能分析的利器，能统计每条SQL的执行次数、总耗时、平均耗时、缓存命中率等。

但问题也很明显。这两个视图本质上是"快照"，你看到的只是某一瞬间的状态。比如pg_stat_activity里有一条查询跑了10秒，你很难判断它是偶发还是持续性的；pg_stat_statements里的累计值虽然能看出哪些SQL消耗最大，但时间维度上的趋势变化，单靠命令行两条SQL根本看不出来。

这也是我坚持要上图形化监控的根本原因：命令行解决的是"现在怎么了"，图形化解决的是"从什么时候开始变慢的"以及"还会不会继续恶化"。

1.2 真正值得监控的指标分层

我整理了一下自己生产环境的监控指标，大致分成四层：

• 实例层：连接数、事务提交/回滚量、WAL生成速率、checkpoint频率、缓冲区命中率。这一层反映数据库整体健康状况。
• 资源层：CPU、内存、磁盘IO、网络吞吐。虽然这些不是PostgreSQL直接暴露的，但数据库性能问题十有八九根子在资源上，尤其是磁盘延迟和内存命中率。
• SQL性能层：慢查询数量、最长耗时、锁等待次数、临时文件使用量。这一层直接决定业务体验。
• 复制层：主从延迟、WAL归档状态、slot堆积情况。如果你用了流复制，这层不监控等于裸奔。

不同工具对这四层的覆盖深度完全不同。有的工具连复制延迟都没有，有的工具却连每个表的膨胀率都能看到。所以下面我在对比工具的时候，会按照这个分层框架去衡量，而不是单纯看界面好不好看。

2. 主流图形化监控工具的实际体验：从全家桶到轻量级

市面上的工具我大致归成三类：一类是Percona Monitoring and Management（PMM）这样的全方位监控平台，一类是pgAdmin这样附带简单图表的官方管理工具，还有一类是以postgres_exporter+Prometheus+Grafana为代表的DIY组合。老实说，每类我都踩过坑，下面一个一个说。

2.1 PMM：功能是真的全，但重量也是真的重

PMM是Percona公司开源的数据库监控平台，专门为MySQL和PostgreSQL设计。我一开始对它期望很高，因为Percona在数据库领域的口碑摆在那，监控粒度确实细到令人发指。部署方式是Docker运行一个server容器，然后在被监控的数据库机器上装client，两行命令就能注册进来。

PMM的PostgreSQL监控面板是我见过的工具里最完整的，从实例吞吐、事务状态、连接池使用率，到WAL写入速率、复制队列深度、每个表的热度，几乎你能想到的都有。它还内置了Query Analytics功能，可以按SQL指纹聚合分析，直接比对各时间段的执行计划变化。

但我实际用了两周之后，还是把它撤下来了，原因有两个：

第一，资源占用不低。PMM的agent和exporter进程在数据库服务器上常驻，内存占用大概在100MB到300MB之间，对于动辄几十GB内存的数据库主机来说不算什么，但在低配云主机上就有点肉痛了。第二，部署链路复杂。PMM server需要单独的机器或容器跑，而且你一旦想自定义告警规则，就得去研究它那一套内置的告警模板，学习成本并不低。

如果你维护的是几十上百套数据库，需要统一纳管，PMM是值得考虑的；但如果只是三五套单机或小集群，它多少有点"杀鸡用牛刀"的味道。

2.2 pgAdmin 4：管理工具，不是监控工具

pgAdmin 4是PostgreSQL官方推荐的图形化管理工具，它自带一个Dashboard页面，能显示连接数、事务、锁信息等几个基础图表，刷新频率默认是5秒。很多新手以为这就是监控了，其实这个页面的定位是"让你在管理数据库时快速看一眼状态"，和历史趋势、告警、异常检测完全不沾边。

pgAdmin的优势在于部署简单，也是很多DBA日常操作数据库的首选，但用它来做监控会面临两个硬伤：一是没有历史数据存储，图表关掉再打开，前5分钟的数据就没了；二是没有告警机制，它不会在连接数暴涨或者复制中断的时候主动通知你。

我做监控选型的时候，把pgAdmin定位为"日常管理工具+手动检查入口"，监控主力还是得靠专门的方案。

2.3 postgres_exporter + Prometheus + Grafana：折腾但最灵活

这套组合是目前互联网公司用得最多的开源方案，我也是最终选定它作为生产环境的监控主力。postgres_exporter负责从PostgreSQL的统计视图里抓数据并转成Prometheus指标格式，Prometheus负责时序存储和告警计算，Grafana负责可视化。

单看链路，比PMM要麻烦不少，因为组件多，环节也多，任何一个环节出问题都会导致数据链路中断。但换来的是极强的定制能力和较低的资源占用。postgres_exporter本身很轻量，内存占用通常只有几十MB；Prometheus采用拉模式采集，只要在配置文件里写好targets就能新增监控实例；Grafana的社区dashboard模板更是多到用不完。

我后面会详细讲这套方案的具体配置和踩坑点，这里先给个结论：如果你想认真做PostgreSQL监控，并且愿意花半天时间搭建，Prometheus+Grafana是性价比最高的选择。

2.4 其他值得注意的工具：Datadog、PgHero、pgDash

除了上面三类，还有一些工具值得知道，但我不展开讲。Datadog是SaaS监控的头部选手，PostgreSQL集成做得很好，有托管agent、一键安装、开箱即用的告警规则，适合没有专职DBA的团队，按量付费的价格不算便宜，而且数据都在云端，需要权衡合规问题。

PgHero是个很有意思的轻量工具，Ruby写的，能自动分析慢查询并给出优化建议，界面非常简单清爽，但它的定位是"SQL性能分析助手"，而不是全维度监控，适合和Prometheus搭配使用，作为慢查询分析的补充。

pgDash则是商业化的PostgreSQL监控产品，指标很专业，可视化也做得漂亮，但部署方式和许可证让很多国内团队望而却步。

3. 你真的需要什么：按团队规模和业务场景来选

说了这么多工具的差异，其实选型的核心逻辑倒很简单：看你有多少数据库实例，有多少人力去运维。

3.1 小型团队、单实例业务的实用配置

如果你的团队只有一两个后端开发，数据库就两三套，没有专职DBA，那我建议直接上云数据库，用云厂商自带的监控面板，比如阿里云RDS的监控，虽然指标不如专业工具多，但胜在不用自己搭，告警推送也完善。

自建数据库的话，推荐PostgreSQL自带的管理工具配一个轻量级方案：一台小机器装Prometheus+Grafana，数据库机器上跑postgres_exporter，再用Node exporter采集系统指标。这套方案只需要一台2核4G的云主机就能跑得很顺畅，而且每天数据能保留三到六个月，比pgAdmin的"看一眼当前状态"强太多了。

3.2 中大型集群、多实例场景的监控方案

如果数据库实例超过10套，或者你有主从复制集群、读写分离架构，那监控就开始变成一件严肃的事了。这时候我反而推荐分期走：先上Prometheus+Grafana统一纳管所有实例，这个阶段重点解决"是否有监控"的问题；下一步再考虑引入PMM这类平台，利用它自带的PMM Agent进行深度巡检和自动化问题定位。

我要特别提醒的是，集群级监控的复制延迟和slot堆积是重中之重，这两个指标在单机监控里不常见，但一旦出问题，往往是全局故障。如果你用的是流复制，一定要在Grafana里把复制延迟单独画出来，并且配上告警。

3.3 云托管与混合部署环境的经验心得

现在很多企业是混合架构：一部分业务在云上，用RDS、TDSQL-C这类托管服务；一部分业务因为合规原因要自建机房。这种情况最怕的就是两套监控各管各的，最后没人知道整个系统的整体状态。

我的经验是用Prometheus统一拉取：云数据库那边，云厂商一般都提供Prometheus API或者可以接入开源exporter的端口；自建那边，直接部署exporter即可。两边都汇到同一套Grafana，用不同的数据源前缀做区分，仪表盘可以复用。这样你只需要一个入口、一套告警规则，运维体验会好很多。

4. 核心监控指标实战：哪些不能漏，哪些别过度

选定工具之后，更重要的是配置正确的监控指标和告警阈值。很多团队装了Grafana，面板上一堆花花绿绿的图表，但关键指标却没有告警，等出事了才后知后觉。我把生产环境里验证过的重点指标和阈值整理了一份清单，供你参考。

4.1 连接数监控：比你想象的更容易爆

PostgreSQL默认max_connections是100，很多小团队根本不改或者改完忘记扩充连接池。连接打满的直接表现是应用侧疯狂报remaining connection slots are reserved，这个问题在我处理过的故障里能排前三。

监控连接数不能只看当前值，要看使用率和增长趋势。我的经验是设置两级告警：使用率达到70%时Info提醒，达到85%时立刻Page Oncall。注意，连接数峰值往往发生在每天固定时段，比如秒杀活动、凌晨的定时任务，所以告警要区分业务高峰和低谷，避免半夜被非关键告警吵醒。

另外，连接数本身高不一定有罪，还要配合pg_stat_activity里state的分布来看。如果idle in transaction连接占大头，往往是应用层没正确释放事务，这种"僵尸连接"会直接耗光连接池；如果是wait_event卡在锁上，则是SQL逻辑问题，光加连接池解决不了。

4.2 慢查询、复制延迟和锁等待的告警经验值

慢查询和复制延迟是不需要解释的监控项，但我踩过几次坑，想分享一些细微经验。

慢查询阈值我习惯设在500ms和2s两档：500ms是性能劣化的预警线，2s是核心告警线。你可以用pg_stat_statements里的mean_exec_time做基线，如果某条SQL的执行时间从200ms飙升到800ms，才说明真的有问题。

复制延迟的告警要谨慎处理。很多人一看主从延迟超过1秒就发告警，结果造成告警疲劳。部署在同一机房的同步复制延迟通常只有几十毫秒，跨机房或者走公网的复制延迟可能稳定在几百毫秒。建议先观察一周的基线数据，在"历史均值+3倍标准差"的位置设告警阈值。异步复制下，延迟达到几十秒甚至几分钟都有可能出现，你要关心的不是偶发的毫秒波动，而是不间断地在涨。

锁等待这块，最容易漏掉的是deadlock_timeout默认1秒，而很多应用在秒级锁冲突时会先超时再重试，于是慢查询、连接数上升、CPU飙高全来了，但你在pg_stat_activity里又看不到死锁记录。所以锁等待事件必须单独统计，而且要持续观察，不能只看有没有死锁死锁，要看长时间加锁的会话。

4.3 从一次故障看监控的救场能力

去年我们有一台PostgreSQL实例在晚上8点出现明显的CPU和IO飙升，业务方反馈订单查询变很慢。我打开Grafana看板，发现两条线索：xact_commit的TPS在半小时内涨了三倍，以及checkpoints_req触发明显增多。同时pg_stat_statements面板上发现某条带DISTINCT的订单聚合SQL平均耗时从100ms飙到900ms。

顺着checkpoints_req往上翻，发现是半小时前上线的一次变更给某个大表加了一个索引，随后定时任务对该表的统计信息重新采集，触发了大量的全表扫描和WAL写入。如果没有历史趋势图，光靠命令行真的很难在几分钟内定位到"新索引触发统计归因"这个问题。

这个案例让我彻底确信：监控工具的扛把子能力不是"展示当前指标"，而是"提供时间轴上的因果链路"。

5. 动手搭建：一套能用的监控方案需要装哪些东西

有了选型判断和指标清单，我来说说实际部署这套方案踩过的坑和具体的组件依赖，方便你看完脑子里就有清晰的线路图。

5.1 基础栈：exporter、Prometheus和Grafana的安装顺序建议

我的建议是先装Grafana再装Prometheus，最后配上exporter，原因是Grafana的初始化比较费时间，先配置好数据源和看板，不会被后续步骤打断灵感。

第一步：装postgres_exporter

postgres_exporter是Prometheus官方维护的PostgreSQL导出器，核心配置就是指定DATA_SOURCE_NAME。我用的是Docker方式，一条命令就能起：

docker run -d \ --name postgres-exporter \ -e DATA_SOURCE_NAME="postgresql://monitor_user:password@localhost:5432/postgres?sslmode=disable" \ -p 9187:9187 \ prometheuscommunity/postgres-exporter:latest

注意这个monitor_user不能是超级用户，建议单独创建一个角色，只授予监控需要的权限，安全第一。这里我踩过一个坑：直接用pg_read_all_stats权限的用户，结果在某个旧版本PostgreSQL上报错，因为pg_stat_statements视图的权限要求更高。

第二步：装Prometheus

Prometheus本身没有太多PostgreSQL相关的配置，你在prometheus.yml里加一个job就行：

scrape_configs: - job_name: 'postgresql' static_configs: - targets: ['数据库IP:9187'] labels: instance: 'prod-pg-01'

第三步：配Grafana

Grafana启动后，去Configuration里添加Prometheus数据源，然后导入社区ID为9628的PostgreSQL Dashboard，这个模板覆盖了我在前文提到的绝大多数实例层、复制层和SQL性能层指标，导入后改改数据源名称就能看到数据。

5.2 一套更省心的组合：pg_dashboard和pg_stat_monitor插件

如果嫌一堆exporter配置费劲，PostgreSQL生态里还有一个非常推荐的插件叫pg_stat_monitor，它是percona开源的一个持续采集统计模块，比内置的pg_stat_statements数据丰富很多，自带了一些图形化Dashboard，支持查看执行计划、锁信息、缓存命中率等。

搭配的pg_dashboard是一个基于Rails的轻量级图形界面，部署方式和PgHero类似，连接数据库后直接展示慢查询、表大小、索引使用率和缓冲命中率。这个组合的监控深度完全能满足中小团队，而且部署成本很低。

可惜的是pg_dashboard官方只支持订阅模式，免费版功能有限制。如果追求完全开源，还是得回到Prometheus+Grafana方案。

5.3 告警的实践心得：规则别贪多，Push和Pull各有取舍

告警规则我建议控制在20条以内，重合度高的放在一起。Prometheus自带的Alertmanager支持基于标签做路由，你要是嫌麻烦，也可以用Grafana的告警，它可以直接发送到钉钉、企业微信甚至邮件。

我个人的做法是：Prometheus只做指标采集，Grafana负责告警展示和推送。原因是Grafana的告警规则配置相对可视化，修改Alertmanager配置时还需要热加载Prometheus，略繁琐。不过如果你对运维自动化要求高，Alertmanager的接收者路由和静默管理会强大得多。

最后提醒两个易错点：一是exporter和node_exporter都要监控，数据库出问题常常是CPU、IO和网络先亮红灯；二是告警要按业务低峰和高峰设置了不同的接收方式，否则白天人多吵，晚上没人应。

5.4 演进：从单机到集群，监控方案怎么跟着变

如果你的数据库从单机演进到主从复制，再到分库分表，监控方案不能停留在"每台机器各看各的"。我有两条进阶经验：

第一，在exporter指标里统一打上集群标签。比如主从两台机器，targets里都配上对应的集群名，Grafana面板上就能按集群聚合查看，主从延迟、双主延迟等对比一目了然。

第二，把归档和备份状态也纳入监控。很多团队只盯着实时性能，却不关注pg_basebackup和WAL归档是否成功，真到故障恢复发现备份是坏的，才追悔莫及。在Prometheus里加一个自定义指标，定时检查备份成功时间点，超过24小时没有成功备份就报警，这个小习惯能救你于微时。

6. 写在最后：监控永远是为了更快找到因果链

我折腾PostgreSQL监控方案前前后后也换过好几茬工具，最初的诉求不过是想在出问题时少花点排查时间。现在这套Prometheus+Grafana的架构已经稳定跑了一年多，最大的体会是：工具不是关键，指标口径和对业务的理解才是关键。同样的工具，有的人把它用成了"故障通知器"，连接数超了才知道看一眼；有的人把它用成了"预防保健科医生"，从趋势图上提前嗅到风险。

如果你也正在选型，我的最后一条建议是：别追求大而全，先把你最头疼的2~3个故障场景监控起来，比如连接数暴涨、慢查询突变、复制延迟失控，把这些指标和告警做到可靠，再考虑覆盖更多边角指标。监控这件事，稳比多重要，别让告警规则成为半夜唯一叫醒你的声音。