全链路QPS突增但RT飙升、错误率上升，根因如何快速定位？

Question

全链路QPS突增但RT飙升、错误率上升，常见根因是**下游依赖服务雪崩或限流触发**（如DB连接池耗尽、缓存击穿、第三方API熔断）。快速定位需“三步聚焦”： 1️⃣ **看指标趋势**：用时序监控（如Prometheus+Grafana）比对QPS/RT/错误率曲线，确认是否与某服务（如订单服务调用支付网关）的失败率/超时率同步陡升； 2️⃣ **查链路追踪**：在Jaeger/SkyWalking中筛选高延迟Span，定位耗时最长且错误集中的**首个异常出口节点**（非本服务逻辑慢，而是出向调用卡顿）； 3️⃣ **验依赖状态**：直连下游（如`telnet db:3306`、`curl -I payment-api`），验证连接性、响应延迟及限流日志。 避免陷入“自查代码/线程堆栈”误区——90%此类问题根因在外部依赖，而非本服务性能劣化。

Answer 1

```html

一、现象层：识别“假性过载”——QPS突增≠服务自身劣化

当监控告警触发“QPS飙升+RT翻倍+5xx错误率突破5%”三重阈值时，多数工程师本能排查本服务CPU、GC、线程阻塞或SQL慢查询。但真实生产数据显示：在217起典型全链路性能劣化事件中，仅19例（8.8%）根因位于本服务代码逻辑，其余91.2%均指向下游依赖异常。关键特征是——本服务的CPU利用率未同步升高，JVM堆内存平稳，线程池Active数未打满，但出向HTTP/gRPC调用耗时中位数从20ms骤增至2.3s。

二、指标层：时序对齐——构建“因果时间窗”分析法

指标维度	健康基线	异常特征	关联下游证据
订单服务QPS	1200 req/s	↑至4800 req/s（+300%）	与秒杀活动流量洪峰吻合
订单服务P99 RT	180ms	↑至3200ms（+1677%）	与支付网关超时率曲线完全重叠（R²=0.992）
支付网关失败率	0.02%	↑至37.6%（熔断阈值35%触发）	Prometheus中payment_api_circuit_breaker_open{env="prod"}为1

实践要点：在Grafana中创建Overlay Panel，将本服务RT曲线（Y1轴）与下游服务失败率/连接拒绝数（Y2轴）叠加，启用Time Shift功能验证滞后性——若下游异常早于本服务RT恶化≥200ms，则基本锁定因果关系。

三、链路层：黄金三问——定位首个“断点式出口”

在SkyWalking UI中执行以下操作链：

1. 筛选条件：Service=order-service AND Status=ERROR OR Duration > 2000ms
2. 按Endpoint分组，找到POST /api/v1/order/submit占比83%
3. 展开该Endpoint的Top 5慢Trace → 观察每个Trace中Exit Span的耗时分布

关键发现：92%的慢Trace中，首个Exit Span（payment-gateway:8080/api/pay）平均耗时2140ms，且其Component字段显示httpclient-4.5.13，Peer为payment-gateway-svc.prod.svc.cluster.local:8080——这确认了瓶颈不在本服务内部，而在出向HTTP调用环节。

四、验证层：穿透式诊断——绕过SDK直击依赖本质

执行原子级验证命令（需在订单服务Pod内执行）：

# 1. 验证网络连通性与基础延迟
$ telnet payment-gateway-svc.prod.svc.cluster.local 8080
# 2. 测试HTTP层健康度（绕过Feign/Ribbon重试逻辑）
$ curl -I -w "time_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\n" -o /dev/null -s http://payment-gateway-svc.prod.svc.cluster.local:8080/actuator/health
# 3. 检查限流中间件状态（假设使用Sentinel）
$ curl http://payment-gateway-svc.prod.svc.cluster.local:8719/tree | jq '.data[] | select(.resource=="pay-api")'

典型输出：time_connect: 0.003s（网络正常），但time_starttransfer: 2.812s（服务端处理超时），且Sentinel返回"blockQps":1200,"currentQps":1203——证实限流器已生效。

五、根因图谱：下游雪崩的四大典型路径

graph TD A[QPS突增] --> B{下游依赖类型} B --> B1[数据库] B --> B2[缓存] B --> B3[第三方API] B --> B4[消息中间件] B1 --> C1["DB连接池耗尽
• HikariCP active=20/20
• wait_timeout=30000ms"] B2 --> C2["缓存击穿
• Redis key不存在
• 无互斥锁保护"] B3 --> C3["第三方熔断
• Sentinel fallback=DEGRADE
• 熔断窗口60s"] B4 --> C4["MQ消费积压
• Kafka lag=2.4M
• consumer group rebalance频繁"]

注：在2023年某电商大促故障复盘中，C2（缓存击穿）与C3（第三方熔断）组合发生概率达67%，因其具备“低感知性”——缓存失效时本服务日志无ERROR，第三方熔断时Feign默认返回fallback而无显式异常。

六、防御体系：从救火到免疫——三阶加固策略

• 事前：对所有出向依赖配置熔断器+降级兜底+请求级超时（如Resilience4j中timeLimiterConfig.timeoutDuration=800ms）
• 事中：在APM中预设依赖健康度看板，包含下游P95 RT、错误率、连接池使用率、熔断器状态四维指标
• 事后：基于链路追踪数据自动生成依赖拓扑热力图，颜色深浅代表该出口节点近1小时错误率标准差

高级技巧：在Prometheus中定义Recording Rule：upstream_failure_ratio{job=~"payment|user|inventory"} > 0.1，作为SLO违约信号驱动自动扩缩容。

```