慢请求排查卡在哪一步说不清，根源在于链路观测存在断层，单点日志和性能指标只能告诉你“系统慢”，却无法回答“到底哪一跳最慢”，需要依靠全链路追踪和分段计时来精准定位。
为什么慢请求排查总是卡在“说不清”这一步
很多团队排查慢请求时,习惯性打开监控看CPU、内存、磁盘IO，发现指标都正常，再翻日志，能看到某个接口耗时超过2秒，但日志里只记录了总耗时，没有中间每一跳的时间消耗。
链路模糊的本质是数据粒度不够细。 一个请求从浏览器出发到返回页面，中间经过DNS解析、建立连接、Nginx转发、网关鉴权、服务处理、数据库查询、Redis缓存命中、第三方接口调用，任何一环掉链子都会让总耗时飙升，但传统监控体系下，应用层只知道整体时间，基础设施层只知道资源水位，两者对不上号，排查就成了猜谜。
业内专家指出,大部分慢请求问题在分布式链路追踪体系下，平均定位时间能从小时级压缩到分钟级，前提是每个环节都有可量化的耗时记录。
慢请求排查最容易卡住的四个环节
卡在“客户端还是服务端”的判断
用户反馈系统很慢,第一件事不是查代码，而是先区分慢发生在哪个端，打开浏览器开发者工具，看Network面板里的Timing。如果Waiting (TTFB)时间占了大头，问题出在服务端；如果Content Download时间很长，带宽或静态资源加载是疑点。
这里有个实践细节：用curl命令带上-w参数，能看到DNS解析时间、连接时间、首字节时间、总耗时，比浏览器更精准，不经过渲染层干扰。
curl -o /dev/null -s -w 'DNS: %{time_namelookup}sn连接: %{time_connect}sn首字节: %{time_starttransfer}sn总耗时: %{time_total}sn' https://你的域名/api/xxx如果首字节时间接近总耗时,链路后端大概率存在慢查询或业务逻辑阻塞。
卡在网关和负载均衡层
Nginx、Gateway、SLB这类中间层是排查的重灾区，它们不像应用代码那样容易打印业务日志，出问题时表现很有迷惑性日志里没有报错，但转发就是慢。
常见诱因包括：worker进程数配置不足、upstream keepalive没开导致频繁握手、access_log磁盘IO争抢。 排查手法是先看Nginx的upstream_response_time变量，它直接记录后端服务器处理消耗的时间，如果这个值很高，问题在后端服务；如果request_time很高但upstream_response_time很低，瓶颈在Nginx自身或网络层。
nginx慢请求排查方法中,在location块里加入以下配置可以记录每个请求的耗时分布：
log_format timed '$remote_addr - $request_time s, upstream: $upstream_response_time s, $request'; access_log /var/log/nginx/access_timed.log timed;
对比request_time和upstream_response_time的差值,就能判断耗时是否消耗在Nginx处理环节，比如限流策略触发的等待、SSL握手、代理缓冲区配置不合理等。
卡在数据库和Redis交互
数据库慢查询是最常见的后端瓶颈,但光看慢查询日志有时候不够，因为慢SQL日志只记录超过阈值的语句，没到阈值但被频繁调用的SQL，才是隐形的耗时刺客。
较稳妥的做法是三个阶段递进排查：
- 先开慢查询日志,设置阈值到1秒，抓出真正执行缓慢的SQL，用EXPLAIN检查是否走索引，是否全表扫描
- 再看数据库的连接池使用情况,连接数打满时新请求会排队等待，这种等待不会出现在慢SQL日志里，但接口耗时明显上涨
- 最后查数据库服务器自身的CPU和IO等待,可能是其他业务的大查询把你所在库的资源抢走了
Redis排查相对简单,重点看bigkey和慢日志，大key的序列化反序列化会阻塞单线程，导致Redis整体响应变慢，进而拖慢依赖它的所有接口，用redis-cli --bigkeys可以快速扫出大key。
卡在外部依赖调用
很多接口不是自己慢,而是调的第三方服务慢，比如支付回调、短信网关、地图定位服务，这些外部接口的响应时间完全不可控。如果没有设置超时和熔断，一个上游慢服务会通过线程池占满向下游传播，最终拖垮整个服务。
建议给所有外部HTTP调用加上分级超时策略：普通依赖500ms，核心依赖1秒，并且任何一层的RPC调用都要传递trace_id，这样才能说清楚到底是哪个外部服务拖了后腿。
用链路追踪把慢请求“钉死”在某一环
全链路追踪的核心理念：trace与span
行业内公认的解法是引入分布式追踪系统,比如SkyWalking、Zipkin或Jaeger，它们的模型把一次请求拆分成若干span（跨度），每个span有独立的开始时间和结束时间，span之间用trace_id串联。
作用很直接：一次请求的完整链路树会自动生成，每一跳的耗时一目了然，不用再登录十几台机器翻日志对时间戳。
排查场景这样落地：用户告诉你某个订单接口很慢，你只需要去SkyWalking里输入trace_id搜索，就能看到整条调用链上哪个span耗时最长，是Gateway转发耗时800ms，还是订单服务里数据库查询占了1.5秒，还是调用库存接口花了2秒，这个问题其实就是“慢请求排查卡在哪一步链路能说清吗”的标准解法用数据回答而不是靠感觉。
落在代码里的分段打点
引入完整APM系统对旧项目改造成本较高,如果暂时上不了，可以在应用内手动打点，在业务代码的关键路径上，用AOP或拦截器记录每个方法或每个RPC调用的耗时，输出成日志。
long start = System.currentTimeMillis();
调用远程服务();
long cost = System.currentTimeMillis() - start;
log.info("调用xx服务耗时: {}ms", cost);
一套成熟做法是给日志加上traceId（通过MDC机制），这样一次请求打出的所有耗时日志可以通过同一个traceId聚合起来，手动串联整条链路，排查时在日志平台搜traceId，就能从上到下看清楚请求经过的每个节点的耗时分摊，结合耗时数据，可以进一步分析是连接等待、响应内容处理还是重试机制导致的延迟。
跟进服务端硬件与网络层的瓶颈
排除应用代码逻辑问题后,如果慢请求仍然随机零散出现，需要回头关注机器层面的因素，例如宿主机CPU steal时间偏高（在top命令中查看%st字段），意味着云服务器在争抢物理CPU资源；网卡软中断集中在单个CPU核上，也会形成处理瓶颈，此时可以配合perf工具分析内核态热点，或借助nicstat查看网卡吞吐饱和度。网络层的重传（TCP retransmission）是非常隐蔽的延迟来源，丢包触发的重传会让请求时间凭空增加数百毫秒，代码和数据库层面都看不出异常，只有用ss -s或netstat -s查看重传计数才能发现，排查路径完善后，“接口耗时高怎么定位”这类问题就有了清晰的答题框架。
慢请求排查的每一步：从现象到根因
归档一套通用的排查清单,遇到慢请求的时候按顺序走完，能少踩很多坑：
- 第一步,确认慢请求的百分位分布，是个别请求慢还是整体变慢，个别慢大概率是资源竞争或GC暂停，整体慢要查容量和路由策略
- 第二步,按客户端→网关→应用→存储的链路顺序分段验证，每层用
time、curl -w或APM的span做隔离分析 - 第三步,查应用层JVM状态，用
jstat -gcutil <pid> 1000观察GC频率和停顿，用thread dump抓慢请求期间的线程栈，看是否阻塞在锁、数据库连接池获取或外部IO - 第四步,验证依赖资源，MySQL执行
SHOW FULL PROCESSLIST看当前会话状态，Redis执行SLOWLOG GET 50拉取慢命令，HTTP依赖看连接池是否有超时等待 - 第五步,复现并对比优化效果，在流量低峰模拟请求，优化后对比同样的trace链路耗时差异
这个流程执行到位,基本能把90%以上的慢请求定位到单台机器、单个进程、单个方法级别。
慢请求链路追踪工具的选型参考
| 工具 | 侵入性 | 能力侧重 | 适用场景 |
|---|---|---|---|
| SkyWalking | 低，JavaAgent | 全链路拓扑、服务监控 | 中大型微服务架构，开箱即用 |
| Zipkin | 中，需要埋点 | 链路追踪，轻量 | 需要快速落地全链路查询的场景 |
| Grafana Tempo | 低 | 基于trace的存储和查询 | 已使用Grafana体系，接受用日志驱动追踪 |
| 自研埋点 | 高，代码侵入 | 业务级分段耗时 | 旧系统改造受限，只需针对核心接口做精细分析 |
选型的核心依据是团队维护能力和技术栈现状,没有APM系统的情况下，curl、jstack、DBA的慢查询日志和Redis的slowlog，也能撑起一套轻量排查方案。
慢请求排查相关的常见疑问
慢请求和慢SQL是同一个问题吗
不是,慢SQL是慢请求的子集，慢请求的范围更大，包括网络延迟、GC停顿、线程阻塞、外部接口调用超时、磁盘IO过高等所有这些因素，一个慢请求里可能包含多条慢SQL，也可能一条慢SQL都没有，纯属于代码逻辑或资源竞争问题，排查时不要只盯着数据库。
为什么监控显示TP99很低，但用户一直反馈卡
监控的TP99统计的是聚合数据,会被高并发下的慢请求稀释，假设1分钟内有900个请求耗时100ms，另有100个请求耗时10秒，算出来的P99是100ms多，看起来一切正常，但那100个用户实际体验已经崩溃了，监控慢请求建议同时关注TOP N的绝对耗时值和最大耗时（MAX），拉出最慢的具体请求和trace_id逐一分析，才有排查价值。
后端服务接口慢如何分析CPU和内存
先确认CPU占用是否居高不下,如果是，用top -Hp <pid>定位线程ID，再通过printf '%x'转成十六进制，配合jstack <pid>抓线程栈，找到哪个线程在占用CPU，是GC线程还是业务线程，如果是内存问题，重点检查堆使用量和GC频率，频繁Full GC会造成明显的停顿和CPU飙升，要注意区分CPU高代表计算密集，内存高代表对象分配太多，两者的排查方向完全不同，前者看代码热点，后者看对象引用和缓存策略，所有排查得出根因后，仍然要回归到链路追踪数据来验证修复效果，形成闭环。
用一句话收束全文：慢请求排查的关键不是会用什么工具，而是能不能把耗时精确拆解到每一个链路节点做到这一步，“卡在哪”就不再是一个问题。