日志链路故障复盘应沉淀什么日志数量多并不等于证据完整。一个请求跨越网关、服务、队列和数据库时如果没有统一的追踪上下文排查人员只能依靠时间、字段和猜测关联日志。复盘应沉淀的不是一段戏剧化的事故描述而是可复查的请求路径、观察到的信号、已经验证的原因和实际生效的改动。Trace ID 或 OpenTelemetry 上下文能帮助把相关记录串起来但它也有边界异步消息、批处理和第三方调用需要明确传播规则采样可能导致链路不完整日志和 trace 中不得随意记录用户输入、令牌或完整地址。设计时应确定哪些字段可以记录、保留多久、谁能检索。让上下文随请求传播入口服务应提取合法的追踪上下文或创建新 span并把上下文放入请求的context.Context。下游 HTTP、gRPC 和消息客户端使用相应的 instrumentation 自动或显式注入。业务日志从 context 获取 trace ID 与 span ID而不是生成临时字符串临时 ID 无法与真实 trace 关联也可能造成重复。func handler(w http.ResponseWriter, r *http.Request) { ctx, span : tracer.Start(r.Context(), payment.request) defer span.End() sc : trace.SpanContextFromContext(ctx) logger.Info(payment request, zap.String(trace_id, sc.TraceID().String()), zap.String(span_id, sc.SpanID().String()), zap.String(route, r.URL.Path), ) if err : callDependency(ctx); err ! nil { span.RecordError(err) http.Error(w, service unavailable, http.StatusServiceUnavailable) return } w.WriteHeader(http.StatusNoContent) }该代码仍需要正确初始化 provider、导出器和采样策略。日志中记录客户端 IP、完整 URL 参数、数据库地址或错误原文前应评估隐私与安全要求面向用户的错误响应也不要把内部 trace 信息当作调试细节直接暴露。可以返回请求标识并让支持人员在授权范围内查询。查询与复盘都需要时间边界检索单个 trace 时按时间排序并同时查看服务版本、环境、重试次数和依赖 span 状态。出现超时不表示最慢的日志就是根因它可能是下游等待、连接池耗尽、队列积压或取消传播失败的结果。复盘将假设和证据分栏未采集到的 span 也要注明避免用缺失数据得出确定结论。防复发事项应是可验收的工作为某个调用设置并测试超时与取消传播为异步消息补充 context 注入给一类错误增加脱敏字段在仪表盘中关联 trace、日志和指标。超时时间、采样比例和告警阈值应从服务基线与依赖约束推导不要把某个固定数值写成通用规则。最后保留与事件相关的查询、图表链接、变更记录和恢复验证。这样下一位排查者能从同一组证据出发而不需要重新从海量日志中猜测系统发生了什么。日志字段规范也应随服务演进维护。新增消息消费者、切换网关或引入新的语言运行时后检查上下文是否仍被正确传递字段名是否一致采样是否覆盖关键路径。这样才能避免观测链路在架构变化中悄悄断开。