go服务需显式初始化tracer并配置jaeger/otlp exporter，否则span被丢弃；须设service name、正确透传context、统一时间基准、避免时钟漂移。
Go 服务怎么把 trace 数据发给 Jaeger / OTLP 后端
Go 服务默认不自动上报 trace，必须显式初始化 tracer 并配置 exporter。不配 exporter 的后果是：本地 Tracer.Start() 看似跑通，但 span 全部丢弃，监控面板永远空白。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
go.opentelemetry.io/otel/exporters/jaeger或go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp，别手写 HTTP client 发送 span - Jaeger exporter 需要设
agentEndpoint（udp）或collectorEndpoint（HTTP），常见错误是混淆两者，导致连接拒绝但无明确报错 - OTLP exporter 默认走
http://localhost:4318/v1/traces，K8s 环境里务必改成 service 名，比如http://otel-collector.default.svc:4318 - 别漏掉
otel.SetTextmapPropagator，否则 HTTP 中间件（如 gin、echo）无法透传 traceparent header，链路在网关就断了
Gin/Echo 中间件里如何正确提取和注入 context
Web 框架中间件里没把 req.Context() 传给 span，会导致 span parent 丢失，所有请求都变成根 span —— 面板里看到的全是孤立的单层调用，没有上下游关系。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- Gin 中用
c.Request = c.Request.WithContext(span.Context())，不是c.Set("ctx", span.Context())—— 后者只存 map，下游 handler 拿不到 - Echo 中类似，必须用
c.SetRequest(c.Request().WithContext(span.Context())) - 若用了自定义中间件（比如 auth、rate limit），每个中间件都要做一次 context 注入，漏一个就断链
- 注意
span.End()必须在 handler 返回后、response 写出前调用，否则 status code 和 latency 统计不准
为什么 prometheus metrics 和 trace 数据对不上时间线
根本原因是 Go 的 otelmetric 默认用纳秒级时间戳，而 Prometheus scrape 是毫秒级拉取 + 服务端做时间对齐；trace 的 span 时间戳若没统一用 time.Now() 基准，两个系统的时间偏移会放大到秒级。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有 span 的
StartOption别手动传time.Time，让 SDK 自动用clock.Now() - Prometheus exporter 配置里加
WithInstrumentationVersion("v1.2.0")，避免旧版 SDK 对 timestamp 处理不一致 - 检查是否同时启用了
otelhttp和自定义 metrics 中间件：重复采集会导致 counter 翻倍，且时间戳来源不同步 - K8s Pod 内时钟漂移超过 100ms 就会影响对齐，建议 DaemonSet 部署
chrony或启用hostTimevolume
监控面板里 trace 显示“unknown_service:go”怎么办
这是 OpenTelemetry SDK 初始化时没设 service name，SDK 降级为默认值，导致所有服务混在一起，无法按服务维度筛选或告警。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 初始化 tracer provider 时必须传
Resource.WithAttributes(semconv.ServiceNameKey.String("order-service")) - service name 要和 kubernetes Deployment 名、Prometheus job 标签保持一致，否则 grafana 面板里关联不到 metrics
- 别用环境变量拼接 service name（如
os.Getenv("ENV") + "-svc"），启动时未设置会导致空字符串，被识别为unknown_service:go - 如果用了 istio，确认
istio-proxy没覆盖OTEL_SERVICE_NAME—— 它会把 sidecar 的名字塞进来，覆盖业务侧设置
真正麻烦的是跨语言链路：Java 服务用 spring Boot Actuator 上报的 service name 格式和 Go 不一致（比如带下划线或大写），这时候得靠 collector 的 attributes processor 统一重命名，而不是在每个服务里硬改。