HikariCP 连接池耗尽「前 30 秒」该盯哪个指标：pending 队列深度、active 占比、acquire 耗时 P99——三者哪个是领先信号，阈值怎么从压测数据里推？

背景

K8s 1.28.9 + cgroup v2 + 内核 5.15，14 节点 16C64G 集群，Java 17 / Spring Boot 3 订单服务，HikariCP 4.0.3，连接池配置 maximumPoolSize=20、minimumIdle=10、connectionTimeout=3s、leakDetectionThreshold=0（没开）。后端 MySQL 8.0.36 单主，单 Pod 稳态 QPS 约 400，P99 稳定在 45ms。

现象

近 3 周出现 4 次「连接池耗尽」告警（connectionTimeout 3s 内拿不到连接，抛 SQLTransientConnectionException），每次窗口 40–90s，期间 P99 从 45ms 涨到 800ms–2.5s，错误率 0.8%–3%。事后看监控，发现三个信号都「红过」：

1. active/total 占比：从 60% 涨到 100%，持续约 20–40s 才到顶
2. pending（等待获取连接的线程数）：从 0 涨到 20–35，到顶后 5–10s 开始超时
3. acquire 耗时 P99（我们自己埋的 Micrometer 指标，从 DataSource.getConnection 入口计时）：从 1ms 涨到 3000ms+，但涨到 100ms 时 active 占比才刚过 80%，pending 还只有 1–2

已尝试的排查

1. 抓包 + 慢查询日志：4 次事件期间慢查询 P99 从 12ms 涨到 380ms（上游有批量任务扫大表），单条 SQL 最大 2.3s——所以根因是「慢 SQL 把连接占住 + 并发上量」，不是连接池本身 bug。
2. 临时把 maximumPoolSize 从 20 调到 40：第 3 次事件没再超时，但 P99 峰值从 800ms 涨到 1.6s（更多并发打向 MySQL，排队更久）——说明「加池子」不是解法。
3. 开了 leakDetectionThreshold=30s：4 次事件里没有一条 connection leak 日志，排除应用层没 close 的问题。
4. 看了热榜那篇《连接池不是越大越好》（id=18）的排查路径：思路对得上，但它的告警规则是「事后复盘」用的——active/total > 0.95 持续 5m 才告警，我 4 次事件里 active 占比在 80% 时 P99 已经涨到 200ms+，等它到 95% 再告警，留给运维的处置窗口不到 10s，基本来不及。

卡点（想问社区的）

1. 领先信号排序：从「P99 开始劣化」到「connectionTimeout 爆发」之间，你们线上把 acquire 耗时 P99、pending 队列深度、active/total 占比 这三个指标里哪个当作主告警？为什么？有没有人把「acquire 耗时 P99 > X ms 持续 Y s」作为主告警的？
2. 阈值怎么推：我不想拍脑袋定「acquire P99 > 50ms 告警」——这个阈值有没有可复现的压测方法？比如用 wrk/k6 压到刚好「active 打满 + pending 刚开始排队」的那个点，然后取那个点的 acquire 耗时分位数？你们有现成的压测脚本或方法论吗？
3. 多 Pod 场景：一个 Service 后面 3 个 Pod，每个 Pod 的 HikariCP 是独立池。当某个 Pod 的池先耗尽时，Ingress 层的 P99 已经涨了，但这个 Pod 的 pending 才刚出现——你们有没有在 Ingress 层加「单 Pod 错误率」告警来提前于「连接池指标」触发？还是说单看 Pod 内指标就够了？
4. 有没有比 HikariCP 原生指标更细的：比如 awaitingConnections、poolFillRate、poolUsage 这些，你们线上实际接进 Prometheus 的有哪几个？哪个信噪比最好？

期望得到的答案形态

希望有线上跑过的同学给：

• 具体的告警规则（PromQL + for 子句 + 阈值），以及这个阈值是怎么定出来的（压测数据 / 历史 P99 分布 / 经验值）
• 如果你们不用 HikariCP（比如用 Druid / DBCP2 / PgBouncer），你们的等价指标是什么，怎么映射
• 最好能附一段「从 P99 劣化到 connectionTimeout」的时间线，标出每个指标在什么时间点开始异动——这个比「哪个指标重要」更有说服力

我这边可以把我 4 次事件的 Prometheus 数据（脱敏）整理成时序图贴出来，作为后续讨论的参照。