log.Printf 不能用于微服务日志集中管理,因其输出非结构化纯文本、无 trace_id 关联、无法跨服务追踪;应统一使用 zerolog/zap 等结构化日志库,输出 JSON 到 stdout,并注入 service_name、trace_id、level、ts 等字段。
log.Printf 不能直接用于微服务日志集中管理微服务部署后,每个服务实例都独立写本地文件或控制台,log.Printf 输出的日志分散、无结构、缺少 trace ID 关联,根本无法跨服务追踪请求。ELK 或 Loki 这类日志系统只接受结构化(如 JSON)且带统一字段(service_name、trace_id、level)的日志流。log.Printf 默认输出纯文本,没有字段可提取,也没有上下文透传能力。
实操建议:
log.Printf 和 fmt.Println,哪怕只是临时调试zerolog
或 zap
JSON 格式输出到 os.Stdout(而非文件),由容器运行时(如 Docker、K8s)接管 stdout/stderr 流向service_name(硬编码或从环境变量读取)、level、ts、trace_id(从 HTTP header 或 context 提取)zerolog 自动注入 trace_id 和请求上下文zerolog 本身不自动解析 HTTP 请求,必须手动从 context.Context 或 http.Request 中提取并注入。常见错误是只在 handler 入口加一次 trace_id,但后续 goroutine 或异步调用丢失上下文。
实操建议:
http.Handler 中从 X-Request-ID 或 traceparent header 读取 trace_id,写入 context.WithValue
trace_id 并创建带字段的子 logger:logger := zerolog.Ctx(r.Context()).With().Str("trace_id", tid).Logger()zerolog.Ctx(ctx) 重新获取UnaryServerInterceptor 中做同样处理,并将 trace_id 写入 metadata.MD 向下游透传stderr 日志很多 Golang 服务把 error 日志写到 os.Stderr,但在 K8s 里,如果容器 runtime 没有正确配置日志驱动(如 json-file),或 DaemonSet 形式的采集器(如 Promtail、Filebeat)没监听 /var/log/pods/... 下对应 symlink 路径,stderr 就会静默丢弃。
实操建议:
json-file 日志驱动:docker info | grep "Logging Driver" 或检查 K8s node 上 /var/lib/docker/containers/**/config.v2.json 中 LogConfig.Type
scrape_configs 的 static_configs.paths 必须包含 /var/log/pods/*_YOUR-SERVICE-NAME*_*/**/*.log,否则 stderr 不会被识别os.Stderr 到文件——这会绕过 K8s 日志收集链路;所有日志统一走 os.Stdout,用 level 字段区分 "level":"error"
ls -l /proc/1/fd/{1,2},应看到指向 /dev/pts/0 或 pipe:,而非某个具体文件路径不是采集工具的问题,而是 Golang 程序自身日志时间戳生成时机与采集缓冲不一致。典型场景:多个 goroutine 并发调用 zerolog.TimeField,但未启用 zerolog.TimestampFunc 统一纳秒级时钟;或 Prometheus metrics push 与日志写入共享同一 stdout pipe,造成行缓冲错位。
实操建议:
zerolog.TimeFieldFormat = time.RFC3339Nano
zerolog.TimestampFunc = func() time.Time { return time.Now().UTC() }zerolog.NewConsoleWriter() 默认异步),改用同步 writer 或直接写 os.Stdout
logger.Info().Msg("user " + u.Name + " logged in")),改用结构化字段,避免因字符串拼接阻塞主线程导致时间戳偏移trace_id、精确时间戳和所属服务身份——这要求从第一行 main() 开始就约束日志初始化方式,而不是等日志查不到时再补中间件。