Go微服务日志采集关键在于可追踪、聚合、关联，需解决归属、对齐、串联、收集四问题；应使用结构化日志（zap/zerolog）、透传trace_id等上下文、stdout输出JSON、跨服务传播trace、按环境配置编码器与级别。
在 Go 微服务架构中实现日志采集，关键不是“把日志写到文件”，而是让日志可追踪、可聚合、可关联——尤其在多实例和分布式环境下，必须解决日志归属、时间对齐、链路串联和统一收集四个核心问题。
使用结构化日志 + 上下文透传
避免用 log.Printf 输出非结构化文本。推荐 zap 或 zerolog，它们原生支持字段键值对，便于后续解析与过滤。
每个请求进入时，应从 HTTP Header（如 X-Request-ID、X-Trace-ID）或 gRPC Metadata 中提取或生成唯一标识，并注入到日志上下文中：
- 用
zap.With(zap.String("trace_id", tid))或zerolog.Ctx(ctx).Info().Str("trace_id", tid).Msg("handling request") - 将 trace_id、span_id、service_name、host、pid 等作为默认字段自动附加，避免每处手动加
- HTTP 中间件或 gRPC UnaryInterceptor 是注入上下文的最佳位置
统一日志输出格式并直连采集代理
不建议微服务直接写入远程日志中心（如 ES、Loki），而应输出到本地 stdout/stderr 或本地文件，再由专用采集器（如 Filebeat、Fluent Bit、Promtail）抓取。
立即学习“go语言免费学习笔记（深入）”；
- Go 进程启动时设置
os.Stdout为 JSON 编码的 writer（zerolog.New(os.Stdout).With().Timestamp().Logger()） - 确保所有日志行是单行 JSON，无换行符，否则采集器会切碎日志
- 容器环境中，stdout 日志会被 Docker / Kubernetes 自动捕获，配合 DaemonSet 部署的 Fluent Bit 即可自动发现并转发
跨服务调用传递 trace 上下文
分布式环境下，单条请求可能流经多个服务，需保证 trace_id 在 HTTP/gRPC 调用中透传，才能在日志中串联行为。
- HTTP 客户端：每次请求前从当前 context 提取
trace_id，写入req.Header.Set("X-Trace-ID", tid) - gRPC 客户端：用
metadata.Pairs("trace-id", tid)构造 metadata 并传入ctx - 服务端统一中间件/拦截器解析并塞回 context，供日志模块读取
- 可集成 OpenTelemetry SDK，自动完成 context 注入、传播与 span 生命周期管理
按环境差异化配置日志行为
开发、测试、生产环境对日志的要求不同：本地需要可读性，线上需要低开销和高一致性。
-
开发环境：启用 human-readable encoder（
zap.NewDevelopmentConfig()），输出带颜色、文件名和行号 - 生产环境：强制使用
zap.NewProductionConfig()，禁用 caller、堆栈，开启日志采样（如zap.LevelEnablerFunc(func(lvl zapcore.Level) bool { return lvl >= zapcore.InfoLevel })） - 通过环境变量（如
LOG_LEVEL=debug、LOG_FORMAT=json）动态控制编码器和级别，无需重启服务
不复杂但容易忽略的是日志生命周期管理：采集器要能识别 Pod 重建、实例扩缩容带来的日志源变化；日志字段命名需团队约定（如统一用 service 而非 svc 或 app_name）；时间必须用 UTC，避免时区混乱。做好这几点，多实例日志就能真正“看得清、查得准、关联合”。
