用云侧观测三板斧排查间歇性 5xx：日志、指标、追踪怎么串起来

线上偶发 5xx 最难的不是“看到报错”，而是把一次请求从网关、业务、依赖串成同一条故事线。下面是一套不依赖特定产品、但和华为云常见能力对齐的实用做法。

1. 先定“一次请求”的身份证

给入口（API 网关或负载均衡）写入/透传 X-Request-Id（或 TraceId），并要求业务服务原样写入应用日志。没有统一 ID，后面的日志检索只能靠时间窗硬猜，间歇故障几乎不可复现。

2. 指标只回答“有没有、多大面”

用错误率、P99 延迟、饱和度（CPU/连接池/队列深度）看是否成片。间歇故障常见形态是：错误率尖刺很短、平均延迟几乎不变，但 P99 或依赖超时计数先动。先确认是入口抖、还是某个下游抖，再决定下钻方向。

3. 日志回答“这一次怎么死的”

按 RequestId 拉全链路日志，优先看：超时、连接拒绝、鉴权失败、限流返回码。日志字段尽量结构化（status、latency_ms、downstream、error_code），方便过滤，而不是大段自然语言。

4. 追踪回答“时间花在谁身上”

若已接入分布式追踪，对照同一 Trace：哪一段 span 变长、哪次重试放大了尾延迟。很多“偶发 5xx”其实是下游慢 + 同步重试把尾延迟推过网关超时。

5. 落地检查清单（可直接贴进值班手册）

• 入口是否稳定生成并透传 RequestId？
• 应用日志是否强制带上同一 ID？
• 仪表盘是否同时有错误率、P99、依赖超时？
• 超时预算是否从入口到下游逐级递减，避免层层等满？
• 重试是否有抖动与上限，避免雪崩？

把“指标定位面、日志定因、追踪定段”当成固定顺序，比临时翻控制台更省时间。间歇故障不怕少，怕没有同一条 ID 把证据钉在一起。