OpenTelemetry 是当前 Go 微服务链路监控的首选方案，因其是 CNCF 毕业项目、Go 生态原生支持好，且能同时对接 Jaeger/Zipkin/OTLP 等后端，避免厂商锁定；老旧方案如 jaeger-client-go 已停更，缺乏指标与日志关联能力。
为什么 OpenTelemetry 是当前 Go 微服务链路监控的首选方案
因为它是云原生计算基金会（CNCF）毕业项目，Go 生态原生支持好，且能同时对接 Jaeger、Zipkin、OTLP 后端，避免被厂商锁定。用 opentelemetry-go 替代老旧的 jaeger-client-go 或自研埋点，不是“升级”，而是止损——后者已不维护，且缺乏指标/日志关联能力。
常见错误现象：context canceled 导致 span 丢失；手动传 context.Context 忘记用 otel.GetTextMapPropagator().Inject() 注入 trace header；HTTP 中间件里没调用 otelhttp.NewHandler() 包裹 handler。
- 所有 HTTP handler 必须走
otelhttp.NewHandler()，否则 inbound 请求无法自动创建 root span - gRPC 服务需用
otelgrpc.UnaryServerInterceptor()和otelgrpc.UnaryClientInterceptor()，不能只在业务层手动 StartSpan - 异步任务（如 goroutine 或消息消费）必须显式传递带 trace 的
context.Context，用trace.ContextWithSpan()补全上下文
Go 服务中如何正确注入 trace context 并透传到下游 HTTP 请求
核心是 propagator 配置和中间件顺序。默认的 B3 格式兼容性最好，但若后端是 Jaeger 且版本 ≥1.22，建议切到 W3C（traceparent header），否则跨语言调用时 parent span id 会错乱。
典型错误：在 http.Client 发起请求前，只调用 req = req.WithContext(ctx)，却没调用 otel.GetTextMapPropagator().Inject(req.Context(), propagation.HeaderCarrier(req.Header)) —— 这会导致下游收不到 trace header，链路直接断裂。
立即学习“go语言免费学习笔记（深入）”；
- 使用
http.DefaultClient时，务必包装为otelhttp.NewClient()实例，它会自动完成 inject + extract - 自定义
http.Client时，需在每次Do()前手动 inject；更稳妥的做法是封装一个DoWithContext(ctx, req)工具函数 - 若调用的是非 Go 服务（如 Python/Node.js），确认对方使用的 propagator 类型一致，可在启动时加日志打印
otel.GetTextMapPropagator().Fields()查看生效字段名
otel-collector 配置里哪些字段直接影响 Go 服务 trace 上报成功率
Go SDK 默认通过 OTLP gRPC 上报数据，默认 endpoint 是 localhost:4317。但生产环境常因 collector 配置疏漏导致上报静默失败——没有 error 日志，span 就消失了。
关键配置项：exporters.otlp.endpoint 必须可连通；service.pipelines.traces.exporters 必须包含你启用的 exporter（如 jaeger 或 logging）；最易忽略的是 receivers.otlp.protocols.grpc.endpoint 若未显式设为 0.0.0.0:4317，容器内可能 bind 到 127.0.0.1 导致 Go 服务连不上。
- 本地开发可用
loggingexporter 直接打日志验证数据是否生成，避免先配 Jaeger 却卡在传输环节 - 启用
health_checkreceiver，并 curlhttp://localhost:13133/healthz确认 collector 活着 - Go 服务启动时加
otel.SetTextMapPropagator(propagation.NewCompositeTextMapPropagator(propagation.B3{}, propagation.TraceContext{}))，兼容多协议接收
为什么 runtime.MemStats 和 http.Server 指标不该直接塞进 trace span
Span 是链路追踪单元，设计目标是低开销、高吞吐；而内存统计、HTTP 连接数这类指标属于度量（metrics），采样频率、存储方式、查询逻辑完全不同。混在一起会导致 span 数据膨胀、collector OOM、查询变慢，甚至触发后端限流。
真实踩坑案例：某服务把每秒 runtime.ReadMemStats() 结果作为 span attribute 上报，单个 span size 超过 256KB，otel-collector 直接丢弃且无提示；换成独立 metrics pipeline 后，资源消耗下降 70%。
- 用
prometheusexporter 收集 Go runtime 指标，搭配otel-collector的prometheusremotewriteexporter 推送到 Prometheus - HTTP server metrics（如 request duration、status code 分布）应由
otelhttp.NewHandler()自动采集，不要自己写 middleware 打点 - 若需 trace 和 metrics 关联，靠 trace ID（
Span.SpanContext().TraceID().String()）做 join，而不是硬编码进 span 属性
链路监控真正难的不是埋点，是让 trace、metrics、logs 三者能在同一个 trace ID 下对齐。很多团队卡在日志没注入 trace ID，或 metrics 标签漏了 service.name —— 这些细节不补全，再全的 span 数据也形同孤岛。
