从一次 P0 故障看可观测性建设：缺少了什么数据导致排查失败

从一次 P0 故障看可观测性建设缺少了什么数据导致排查失败一、一次故障排查了 3 个小时日志里竟然找不到任何有用信息故障描述某天下午 3 点支付服务的成功率从 99.8% 骤降到 87%。用户投诉激增技术团队紧急排查。看了一圈应用日志全部是payment failed没有更详细的错误原因监控面板CPU、内存、QPS 都正常数据库没有慢查询第三方支付网关返回状态码 200一切正常3 个小时过去了根本找不到根因。最后是偶然翻到一个边缘服务的日志发现第三方支付网关在 3:00-3:30 期间间歇性返回了内部错误——但因为上层代码把错误信息吃了所有重试也都吞了异常监控面板上显示的成功率是重试成功的那部分。二、故障排查为何失败缺失的数据链路缺失的数据分四类第三方 API 的原始响应体只有成功/失败的布尔值、重试日志每次重试的原因和时间不详、全链路 Trace ID无法关联一次支付请求在 4 个服务中的日志、以及错误信息的结构化分类。三、修复后的可观测性架构package payment import ( context fmt time encoding/json go.opentelemetry.io/otel go.opentelemetry.io/otel/attribute ) // PaymentRequest 支付请求 type PaymentRequest struct { TraceID string json:trace_id OrderID string json:order_id Amount int64 json:amount Channel string json:channel // alipay, wechat } // StructuredPaymentLog 结构化支付日志 type StructuredPaymentLog struct { TraceID string json:trace_id OrderID string json:order_id Channel string json:channel Amount int64 json:amount Status string json:status // success, failed, retrying ErrorCode string json:error_code // 结构化错误码 ErrorDetail string json:error_detail Duration time.Duration json:duration_ms RetryCount int json:retry_count GatewayResp json.RawMessage json:gateway_resp // 原始网关响应 ExtraTags map[string]string json:extra_tags // 灵活的自定义标签 } // ProcessPayment 支付处理带完整可观测性 func (s *PaymentService) ProcessPayment( ctx context.Context, req *PaymentRequest, ) error { // 1. 创建 Trace Span tracer : otel.Tracer(payment-service) ctx, span : tracer.Start(ctx, ProcessPayment, attribute.String(order_id, req.OrderID), attribute.String(channel, req.Channel), attribute.Int64(amount, req.Amount), ) defer span.End() // 2. 初始化结构化日志 paymentLog : StructuredPaymentLog{ TraceID: req.TraceID, OrderID: req.OrderID, Channel: req.Channel, Amount: req.Amount, ExtraTags: make(map[string]string), } startTime : time.Now() // 3. 带重试的第三方调用记录每次重试 var lastErr error for attempt : 1; attempt s.maxRetries; attempt { paymentLog.RetryCount attempt // 创建子 Span 追踪每次重试 retryCtx, retrySpan : tracer.Start(ctx, fmt.Sprintf(GatewayCall_Attempt_%d, attempt), ) resp, err : s.callGateway(retryCtx, req) retrySpan.End() // 记录网关原始响应关键改进 if resp ! nil { rawJSON, _ : json.Marshal(resp) paymentLog.GatewayResp rawJSON // 添加 Span 属性 retrySpan.SetAttributes( attribute.String(gateway.resp_code, resp.Code), attribute.String(gateway.resp_msg, resp.Message), ) } if err nil resp.Code SUCCESS { paymentLog.Status success break } // 记录失败原因结构化错误码 if resp ! nil { paymentLog.ErrorCode resp.Code paymentLog.ErrorDetail resp.Message } if err ! nil { paymentLog.ErrorCode GATEWAY_TIMEOUT paymentLog.ErrorDetail err.Error() } lastErr fmt.Errorf(支付尝试%d失败: code%s, detail%s, attempt, paymentLog.ErrorCode, paymentLog.ErrorDetail) paymentLog.Status retrying paymentLog.Duration time.Since(startTime) // 记录每次重试的结构化日志 s.logStructuredPayment(ctx, paymentLog) // 重试间隔指数退避 time.Sleep(time.Duration(1uint(attempt)) * 100 * time.Millisecond) } // 4. 记录最终结果 paymentLog.Duration time.Since(startTime) if lastErr ! nil { paymentLog.Status failed s.logStructuredPayment(ctx, paymentLog) return fmt.Errorf(支付失败(重试%d次后): %w, s.maxRetries, lastErr) } paymentLog.Status success s.logStructuredPayment(ctx, paymentLog) return nil } // logStructuredPayment 写结构化日志到 ELK func (s *PaymentService) logStructuredPayment( ctx context.Context, log *StructuredPaymentLog, ) { // 同时写入应用日志和指标 logJSON, _ : json.Marshal(log) // 应用日志ELK 可搜索 s.logger.InfoContext(ctx, string(logJSON)) // Prometheus 指标 s.paymentCounter.WithLabelValues( log.Channel, log.Status, log.ErrorCode, ).Inc() s.paymentDuration.WithLabelValues( log.Channel, log.Status, ).Observe(float64(log.Duration.Milliseconds())) }四、排查能力对比修复前 vs 修复后排查维度修复前修复后错误原因支付失败GATEWAY_TIMEOUT: 第三方网关在重试3次后仍返回transient_error链路追踪无4个服务日志无法关联TraceID 贯穿全链路一次查询定位所有服务日志故障定位时间3 小时人工推测30 秒ES 搜索 ErrorCodeGATEWAY_TIMEOUT第三方网关行为不可见每次调用原始响应被记录可以看到间歇性故障模式五、总结这次 P0 故障暴露的可观测性缺失是系统性的——不是监控少了某个指标而是日志没有结构化、错误没有分类、链路没有追踪。三个核心改进所有第三方 API 调用必须记录原始响应体不能简化为成功/失败布尔值、所有错误必须有结构化错误码不能是自由文本的error.Error()、所有请求必须带 TraceID 跨越服务边界。可观测性建设不是一次性工程用出了故障能快速找到根因吗这个标准来衡量——如果回答不能说明数据还不够。