Go微服务日志需结构化输出JSON至stdout，通过Fluent Bit等采集器接入Loki/ELK；用zerolog中间件注入trace_id、service、env等字段，统一schema并透传trace_id以支持跨服务日志聚合与排查。
在 Go 微服务架构中，日志不能只写到本地文件或标准输出，必须统一采集、结构化、可检索。核心思路是：用结构化日志库（如 zerolog 或 zap）打日志 → 添加请求上下文（trace ID、service name、path 等）→ 输出为 JSON 到 stdout → 由日志采集器（如 Filebeat、Fluent Bit）转发至集中式日志系统（如 ELK、Loki + Grafana）。
使用 zerolog 打印结构化请求日志
Go 原生 log 不适合微服务日志。推荐 zerolog：轻量、零分配、默认 JSON 输出。关键是在 HTTP 中间件里注入 trace ID 和请求元信息：
- 用
gorilla/mux或net/http的中间件拦截每个请求 - 生成唯一
trace_id（如用uuid.NewString()），存入context.Context - 创建带字段的 logger：
logger.With().Str("trace_id", tid).Str("method", r.Method).Str("path", r.URL.Path).Logger() - 记录请求开始、响应状态码、耗时（用
time.Since()）
注入服务名与环境信息
单靠 trace ID 不足以区分服务来源。需在 logger 初始化时预置静态字段：
- 通过环境变量读取
SERVICE_NAME和ENV（如 "order-service"、"prod"） - 全局 logger 示例：
zerolog.New(os.Stdout).With().Str("service", svcName).Str("env", env).Timestamp().Logger() - 避免每个 handler 重复写 service/env；中间件里用
logger.With().Caller().Logger()可加文件行号（调试用，生产可关）
对接日志采集器（以 Fluent Bit 为例）
Golang 进程只负责输出结构化 JSON 到 stdout，不直连 Elasticsearch 或 Loki。Fluent Bit 作为 sidecar 或宿主机 agent 收集：
立即学习“go语言免费学习笔记（深入）”；
- Docker/K8s 中，让 Go 容器
stdout日志被容器运行时捕获（默认行为） - Fluent Bit 配置
[INPUT]使用tail（读容器日志文件）或forward（收 Docker logs API） -
[FILTER]可解析 JSON 字段、添加 Kubernetes 元数据（pod name、namespace） -
[OUTPUT]发往 Loki（loki插件）或 ES（es插件），自动按service、trace_id建索引
在 Loki + Grafana 中按 trace_id 聚合请求链路
Loki 本身不存储 trace，但可通过日志字段关联同一请求的多个服务调用：
- 所有服务都写
trace_id字段，且跨服务透传（HTTP HeaderX-Trace-ID） - Grafana 中用 LogQL 查询：
{job="go-service"} | json | trace_id=="abc123" | line_format "{{.method}} {{.path}} {{.status}}" - 搭配 Tempo（或 Jaeger）做真正分布式追踪；Loki 日志可作为补充证据，验证某次 trace 的具体参数和错误堆栈
基本上就这些。不复杂但容易忽略的是：字段命名统一（比如都叫 trace_id 而不是有的用 traceId）、所有服务共用一套日志 schema、采集器配置要覆盖 error 日志级别过滤。做好这三点，排查线上问题效率能明显提升。
