慢接口排查实录：指标、链路与日志的三板斧（2026-11-07）

一、现象与第一反应

某个核心查询接口的 P99 从 120ms 涨到 1.8s，但 CPU 与内存曲线都很平稳。第一反应往往是加机器，可容量指标没有明显变化，说明问题更可能出在单次请求的等待路径上，而不是整体吞吐不足。

二、指标：先分清平均值与分位数

平均值会把长尾掩盖掉。把监控切成 P50、P95、P99 三条线后可以看到，P50 几乎没动，P99 却翻了十几倍，说明绝大多数请求仍然正常，只有少数请求踩到了某个慢路径。随后按接口、实例、下游依赖三个维度拆分，发现慢请求集中在一个可用区的实例上。

三、链路追踪：找到最慢的 Span

打开分布式追踪后，把 P99 请求的 Trace 按耗时排序，最慢的 Span 不是数据库查询，而是连接池获取连接的等待。继续看连接池指标，活跃连接数长期贴着上限，等待队列在流量高峰时快速堆积。根因于是从模糊的接口慢收敛为连接池容量与超时配置不匹配。

四、日志与火焰图：验证假设

把连接池等待时间打进结构化日志，并按分钟聚合，等待时间的峰值与慢请求的时间段完全吻合，假设得到验证。火焰图进一步显示，业务线程大量时间耗在等待锁而不是计算，这与连接池争用的结论一致。调整池大小与获取超时后，P99 回落到 150ms 以内。

五、可复用的排查清单

一，先看分位数而不是平均值；二，按实例与依赖维度拆分，避免全局视角掩盖局部问题；三，用追踪定位最慢 Span，再顺着 Span 找资源等待；四，用日志验证假设而不是凭直觉改配置；五，把结论固化成监控告警与容量基线，防止同类问题复发。