Golang微服务调用链监控核心是统一Trace ID透传、结构化日志自动注入、关键Span手动埋点及Trace数据导出；通过context.Context传递ID，zap日志封装注入trace_id/span_id，HTTP/DB/RPC层埋点记录操作元信息，最终上报Jaeger或OTLP后端。
用 Golang 实现微服务调用链监控，核心是把日志、Trace ID 和上下文传播统一起来，让一次请求的完整路径可追溯。不依赖复杂中间件也能落地，关键是设计好上下文透传、日志打点和 Trace 数据采集三个环节。
统一 Trace ID 并透传到下游服务
每次入口请求（如 HTTP）生成唯一 Trace ID，并通过 context.Context 一路向下传递。推荐用 go.opentelemetry.io/otel 或轻量级方案如 uber-go/zap + 自定义 context key。
- 在 HTTP handler 中从 header（如
X-Trace-ID）读取，不存在则新建；用context.WithValue注入到 ctx - 调用下游服务时，把 Trace ID 写入 request header（如
req.Header.Set("X-Trace-ID", traceID)） - gRPC 场景用
metadata.MD透传，客户端加 metadata，服务端从 ctx 解析
日志中自动携带 Trace ID 和 Span 信息
避免手动拼接日志，改用结构化日志库（如 zap）配合 hook 或 logger wrapper，在每条日志里自动注入当前 trace_id、span_id、service_name。
- 定义一个带 trace 字段的
Logger封装，每次从 ctx 提取traceID和spanID，用With追加为字段 - 示例：
logger.With(zap.String("trace_id", traceID), zap.String("span_id", spanID)).Info("user fetched", zap.Int64("uid", 123)) - 所有业务日志、错误日志、DB 慢查询日志都走这个 logger，确保全链路日志可关联
手动或自动埋点记录关键 Span
Span 表示一个操作单元（如 HTTP 处理、DB 查询、RPC 调用），需记录开始时间、结束时间、状态、标签（tag）和事件（event）。
立即学习“go语言免费学习笔记（深入）”；
- HTTP 层：用 middleware 包裹 handler，
StartSpan在进入时，EndSpan在返回前（注意 recover panic） - DB 层：包装 sql.DB 或使用
sqlx+driver.Valuer埋点，记录 SQL、耗时、行数 - RPC 层：封装 client 方法，在调用前后打 start/end，把下游返回码、耗时作为 tag 记录
- 建议至少标记：
http.method、http.url、db.statement、rpc.service、status.code
导出 Trace 数据到后端分析系统
Trace 数据最终要上报给可观测平台，常见选择有 Jaeger、Zipkin、OpenTelemetry Collector 或阿里云 SLS / 腾讯云 TSF。
- 用
go.opentelemetry.io/otel/exporters/jaeger直连 Jaeger Agent（UDP） - 或通过 OTLP exporter 推送到 OpenTelemetry Collector，再路由到多个后端（Prometheus + Loki + Tempo 组合）
- 简单场景可先写本地 JSON 文件或发到 Kafka，后续做批处理解析
- 注意采样策略：高并发下默认 1% 采样，避免性能损耗；异常请求（5xx、panic）强制 100% 上报
基本上就这些。不需要一开始就上全套 OpenTelemetry SDK，从 Trace ID 透传 + 日志打标 + 关键 Span 手动埋点做起，就能快速看到调用链轮廓。等稳定后再补全自动 instrumentation 和指标联动。
