这个3层警报救了3192个连接：我们差点等到数据库崩溃才动手

PostgreSQL连接池爆满时，最糟的不是超过max_connections——是你超了却不知道为什么。

去年我们上线了一个叫pgwd的小工具，本意是"多个报警渠道"。结果它成了值班工程师的决策外挂：不是告诉你"出事了"，而是告诉你"现在该干什么"。

75/85/95：三个数字怎么改变值班体验

我们的生产环境曾出现过一次典型 escalation：Slack 消息在几分钟内从黄色跳到红色。关键不是阈值本身，而是pgwd附带的拆解数据——活跃连接、空闲连接、等待队列各占多少。

这让我们能在30秒内判断：是真·业务压力、连接泄漏，还是"看起来没事但其实快炸了"的idle-heavy模式。

我们定了三层模型：75%预警，85%准备介入，95%立即行动。在此之前，团队的第一信号往往是 FATAL: sorry, too many clients already——也就是用户已经打不进来的时候。

这次 rollout 我们刻意选了"有人盯着"的执行方式。关键步骤没有上无人自动化，操作员全程在场。

3192不是拍脑袋：一次有 guardrail 的扩容

基于这次运行，runbook里多了一条具体动作：把连接上限从2000提到3192。但附带四个动词——增加、观察、验证、调整。不是改完配置就关 ticket。

单纯拉高连接数而不看基础设施，会触发另一种故障模式：内存、CPU或I/O先扛不住，数据库反而死得更快。

所以我们的 runbook 明确加了 guardrail：扩容后24小时和72小时各检查一次——连接使用率是否回落到安全水位？活跃连接比例是否合理？有没有出现新的等待模式？

pgwd 的部署很轻。基础模式就是设好数据库地址、Slack webhook、轮询间隔，直接跑。改配置前可以用 -force-notification 测试通知链路，避免"我以为它会响"的尴尬。

Kubernetes 环境也能用，指定 service 名称和本地转发端口就行，不需要改应用代码。

从报警到行动：我们省下的不是时间，是决策带宽

这次经历让我重新理解"可观测性"三个字。不是仪表盘上的曲线多漂亮，是值班的人能不能在压力下做出不蠢的决定。

pgwd 的价值在于把"连接数过高"这个单一信号，拆成了可操作的情境。工程师看到消息时，脑子里已经有一条决策分支：idle 多就杀会话，active 多就准备扩容，both 高且涨得快——直接叫醒 DBA 团队。

社区里有人用法语写了安装教程，覆盖从编译到快速配置的完整流程。如果你也在跑 PostgreSQL 生产环境，我想问一个具体的问题：你的阈值策略是几层？runbook 里有没有写明"看到数字 X 后，Y 分钟内必须做 Z"？