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 ManagementPMM这样的全方位监控平台一类是pgAdmin这样附带简单图表的官方管理工具还有一类是以postgres_exporterPrometheusGrafana为代表的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本身很轻量内存占用通常只有几十MBPrometheus采用拉模式采集只要在配置文件里写好targets就能新增监控实例Grafana的社区dashboard模板更是多到用不完。我后面会详细讲这套方案的具体配置和踩坑点这里先给个结论如果你想认真做PostgreSQL监控并且愿意花半天时间搭建PrometheusGrafana是性价比最高的选择。2.4 其他值得注意的工具Datadog、PgHero、pgDash除了上面三类还有一些工具值得知道但我不展开讲。Datadog是SaaS监控的头部选手PostgreSQL集成做得很好有托管agent、一键安装、开箱即用的告警规则适合没有专职DBA的团队按量付费的价格不算便宜而且数据都在云端需要权衡合规问题。PgHero是个很有意思的轻量工具Ruby写的能自动分析慢查询并给出优化建议界面非常简单清爽但它的定位是SQL性能分析助手而不是全维度监控适合和Prometheus搭配使用作为慢查询分析的补充。pgDash则是商业化的PostgreSQL监控产品指标很专业可视化也做得漂亮但部署方式和许可证让很多国内团队望而却步。3. 你真的需要什么按团队规模和业务场景来选说了这么多工具的差异其实选型的核心逻辑倒很简单看你有多少数据库实例有多少人力去运维。3.1 小型团队、单实例业务的实用配置如果你的团队只有一两个后端开发数据库就两三套没有专职DBA那我建议直接上云数据库用云厂商自带的监控面板比如阿里云RDS的监控虽然指标不如专业工具多但胜在不用自己搭告警推送也完善。自建数据库的话推荐PostgreSQL自带的管理工具配一个轻量级方案一台小机器装PrometheusGrafana数据库机器上跑postgres_exporter再用Node exporter采集系统指标。这套方案只需要一台2核4G的云主机就能跑得很顺畅而且每天数据能保留三到六个月比pgAdmin的看一眼当前状态强太多了。3.2 中大型集群、多实例场景的监控方案如果数据库实例超过10套或者你有主从复制集群、读写分离架构那监控就开始变成一件严肃的事了。这时候我反而推荐分期走先上PrometheusGrafana统一纳管所有实例这个阶段重点解决是否有监控的问题下一步再考虑引入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_exporterpostgres_exporter是Prometheus官方维护的PostgreSQL导出器核心配置就是指定DATA_SOURCE_NAME。我用的是Docker方式一条命令就能起docker run -d \ --name postgres-exporter \ -e DATA_SOURCE_NAMEpostgresql://monitor_user:passwordlocalhost:5432/postgres?sslmodedisable \ -p 9187:9187 \ prometheuscommunity/postgres-exporter:latest注意这个monitor_user不能是超级用户建议单独创建一个角色只授予监控需要的权限安全第一。这里我踩过一个坑直接用pg_read_all_stats权限的用户结果在某个旧版本PostgreSQL上报错因为pg_stat_statements视图的权限要求更高。第二步装PrometheusPrometheus本身没有太多PostgreSQL相关的配置你在prometheus.yml里加一个job就行scrape_configs: - job_name: postgresql static_configs: - targets: [数据库IP:9187] labels: instance: prod-pg-01第三步配GrafanaGrafana启动后去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官方只支持订阅模式免费版功能有限制。如果追求完全开源还是得回到PrometheusGrafana方案。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监控方案前前后后也换过好几茬工具最初的诉求不过是想在出问题时少花点排查时间。现在这套PrometheusGrafana的架构已经稳定跑了一年多最大的体会是工具不是关键指标口径和对业务的理解才是关键。同样的工具有的人把它用成了故障通知器连接数超了才知道看一眼有的人把它用成了预防保健科医生从趋势图上提前嗅到风险。如果你也正在选型我的最后一条建议是别追求大而全先把你最头疼的2~3个故障场景监控起来比如连接数暴涨、慢查询突变、复制延迟失控把这些指标和告警做到可靠再考虑覆盖更多边角指标。监控这件事稳比多重要别让告警规则成为半夜唯一叫醒你的声音。 
长河君 · 2026/9/30 8:04:47 · 阅读 1.2k PostgreSQL图形化监控：工具对比与Prometheus+Grafana实践
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 ManagementPMM这样的全方位监控平台一类是pgAdmin这样附带简单图表的官方管理工具还有一类是以postgres_exporterPrometheusGrafana为代表的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本身很轻量内存占用通常只有几十MBPrometheus采用拉模式采集只要在配置文件里写好targets就能新增监控实例Grafana的社区dashboard模板更是多到用不完。我后面会详细讲这套方案的具体配置和踩坑点这里先给个结论如果你想认真做PostgreSQL监控并且愿意花半天时间搭建PrometheusGrafana是性价比最高的选择。2.4 其他值得注意的工具Datadog、PgHero、pgDash除了上面三类还有一些工具值得知道但我不展开讲。Datadog是SaaS监控的头部选手PostgreSQL集成做得很好有托管agent、一键安装、开箱即用的告警规则适合没有专职DBA的团队按量付费的价格不算便宜而且数据都在云端需要权衡合规问题。PgHero是个很有意思的轻量工具Ruby写的能自动分析慢查询并给出优化建议界面非常简单清爽但它的定位是SQL性能分析助手而不是全维度监控适合和Prometheus搭配使用作为慢查询分析的补充。pgDash则是商业化的PostgreSQL监控产品指标很专业可视化也做得漂亮但部署方式和许可证让很多国内团队望而却步。3. 你真的需要什么按团队规模和业务场景来选说了这么多工具的差异其实选型的核心逻辑倒很简单看你有多少数据库实例有多少人力去运维。3.1 小型团队、单实例业务的实用配置如果你的团队只有一两个后端开发数据库就两三套没有专职DBA那我建议直接上云数据库用云厂商自带的监控面板比如阿里云RDS的监控虽然指标不如专业工具多但胜在不用自己搭告警推送也完善。自建数据库的话推荐PostgreSQL自带的管理工具配一个轻量级方案一台小机器装PrometheusGrafana数据库机器上跑postgres_exporter再用Node exporter采集系统指标。这套方案只需要一台2核4G的云主机就能跑得很顺畅而且每天数据能保留三到六个月比pgAdmin的看一眼当前状态强太多了。3.2 中大型集群、多实例场景的监控方案如果数据库实例超过10套或者你有主从复制集群、读写分离架构那监控就开始变成一件严肃的事了。这时候我反而推荐分期走先上PrometheusGrafana统一纳管所有实例这个阶段重点解决是否有监控的问题下一步再考虑引入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_exporterpostgres_exporter是Prometheus官方维护的PostgreSQL导出器核心配置就是指定DATA_SOURCE_NAME。我用的是Docker方式一条命令就能起docker run -d \ --name postgres-exporter \ -e DATA_SOURCE_NAMEpostgresql://monitor_user:passwordlocalhost:5432/postgres?sslmodedisable \ -p 9187:9187 \ prometheuscommunity/postgres-exporter:latest注意这个monitor_user不能是超级用户建议单独创建一个角色只授予监控需要的权限安全第一。这里我踩过一个坑直接用pg_read_all_stats权限的用户结果在某个旧版本PostgreSQL上报错因为pg_stat_statements视图的权限要求更高。第二步装PrometheusPrometheus本身没有太多PostgreSQL相关的配置你在prometheus.yml里加一个job就行scrape_configs: - job_name: postgresql static_configs: - targets: [数据库IP:9187] labels: instance: prod-pg-01第三步配GrafanaGrafana启动后去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官方只支持订阅模式免费版功能有限制。如果追求完全开源还是得回到PrometheusGrafana方案。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监控方案前前后后也换过好几茬工具最初的诉求不过是想在出问题时少花点排查时间。现在这套PrometheusGrafana的架构已经稳定跑了一年多最大的体会是工具不是关键指标口径和对业务的理解才是关键。同样的工具有的人把它用成了故障通知器连接数超了才知道看一眼有的人把它用成了预防保健科医生从趋势图上提前嗅到风险。如果你也正在选型我的最后一条建议是别追求大而全先把你最头疼的2~3个故障场景监控起来比如连接数暴涨、慢查询突变、复制延迟失控把这些指标和告警做到可靠再考虑覆盖更多边角指标。监控这件事稳比多重要别让告警规则成为半夜唯一叫醒你的声音。