p styletext-align:centerimg srchttps://platform-outputs.agnes-ai.space/images/t2i/task_gpTy9OZkYY493iexyiY3PQm4aCNqnHyo/output_820a33f97baa4bc3833be2896d9721f5.png alt封面图 stylemax-width:100%;height:auto //p微服务链路追踪实战没效果多半是 TraceId 没搞透昨晚生产接口超时大家第一反应查链路追踪结果 Jaeger 界面空空如也。这种“有监控等于没监控”的尴尬运维老哥都遇到过。微服务链路追踪实战不是装个 agent 就完事大部分失败都栽在采样、上下文传递和 Exporter 配置上。今天把踩过的坑填平直接上干货。坑一采样率配置不当关键数据丢失很多团队为了性能把采样率Sampling Rate设得太低甚至固定为 0.1%。一旦出故障恰好没被采样排查直接断档。生产环境建议动态调整错误请求必须 100% 采样。# otel-collector-config.yaml processors: probabilistic_sampler: sampling_percentage: 10 # 默认 10% tail_sampling: policies: - name: always-sample-errors type: status_code status_code: {status_codes: [ERROR]} # 错误全采**输出/效果说明**上述配置保证日常 10% 流量入库节省存储成本但凡返回 5xx 错误的请求全部保留。既省存储又不漏故障现场避免关键时刻掉链子。坑二上下文传递断裂TraceId 对不上这是最隐蔽的坑。网关层收了 TraceId但转发给后端服务时没透传 HTTP Header。导致链路断成几截Jaeger 里只能看到孤岛根本无法串联调用链。// Go 客户端请求示例 ctx, span : tracer.Start(context.Background(), call-service) defer span.End() req, _ : http.NewRequest(GET, http://svc/api, nil) // 关键注入上下文到 HTTP Header propagator.Inject(ctx, propagation.HeaderCarrier(req.Header))**输出/效果说明**执行后req.Header 中会自动带上 traceparent 或 uber-trace-id。后端服务解析该 Header 才能关联到同一个 TraceId形成完整链路否则每个服务都是独立的 Trace。坑三Exporter 地址配置错误数据发不出去Agent 装好了数据也生了但 Jaeger 收不到。多半是 OTel Collector 的 Exporter 地址写错或者网络策略拦截了 gRPC 端口导致数据堵在门口。# 验证数据是否到达 Collector curl -X POST http://localhost:4318/v1/traces \ -H Content-Type: application/json \ -d {resource_spans: []} # 检查 Collector 日志是否有 Exporting failed**输出/效果说明**如果 Collector 日志无报错且 Jaeger 查询不到检查防火墙是否放行 14250 (gRPC) 或 14268 (HTTP) 端口。内网 DNS 解析错误也是高频原因务必 ping 通 Collector 域名。生产环境避坑清单1. **采样策略**错误请求必须 100% 采样慢请求单独标记。2. **Header 透传**检查 Nginx/Gateway 是否放行 traceparent 字段。3. **时间同步**所有节点 NTP 同步时间偏差会导致 Trace 排序混乱。4. **资源限制**给 Collector 预留足够内存避免高并发下丢数据。5. **版本兼容**OTel 协议升级快确保 Agent 与 Collector 版本匹配。链路追踪是排查分布式问题的眼睛眼睛瞎了运维就是瞎蒙。以上配置你检查过几项
