Go微服务日志集中管理核心是结构化、带trace_id直传后端：禁用fmt.Println，用zerolog/zap注入service/host/pid/env，HTTP中间件透传trace_id，直连Loki/OTel Collector，过滤敏感信息，避免高频日志。
Go 微服务的日志集中管理，核心不是“把日志打到文件里再用 Filebeat 传走”，而是从设计之初就切断 log.Printf 和 fmt.Println 这类裸输出，让每条日志自带服务名、实例 ID、请求 trace_id、结构化字段，并直连日志后端（如 Loki、ELK 或 OpenTelemetry Collector）。
用 zerolog 或 zap 替代标准库 log
标准库 log 不支持结构化字段、无上下文传播能力、性能差，无法满足微服务日志要求。
-
zerolog更轻量，API 简洁，适合高吞吐场景；zap功能更全（支持采样、多写入器、字段类型校验），但依赖稍重 - 必须禁用控制台彩色/时间戳等默认格式，统一由日志后端处理展示逻辑
- 初始化时强制注入固定字段：
service（服务名）、host（主机名）、pid（进程 ID）、env（环境如prod）
import "github.com/rs/zerolog"
func initLogger() {
log := zerolog.New(os.Stdout).With().
Str("service", "order-svc").
Str("host", os.Getenv("HOSTNAME")).
Int("pid", os.Getpid()).
Str("env", os.Getenv("ENV")).
Logger()
zerolog.SetGlobalLevel(zerolog.InfoLevel)
zerolog.DefaultContextLogger = &log
}
为每个 HTTP 请求注入 trace_id 并透传日志上下文
没有 trace_id 的日志在微服务中等于无效日志 —— 你无法把一次下单请求在 order、payment、inventory 三个服务中的日志串起来。
- 使用
gorilla/mux或net/http中间件，在请求入口生成或提取X-Request-ID或traceparent（W3C Trace Context） - 将该 ID 绑定到
context.Context，再通过zerolog.Ctx(r.Context())获取带上下文的 logger 实例 - 避免用全局变量或 map 存 trace_id：并发不安全，且无法跨 goroutine 传递
func loggingMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
ctx := r.Context()
traceID := r.Header.Get("X-Request-ID")
if traceID == "" {
traceID = uuid.New().String()
}
ctx = context.WithValue(ctx, "trace_id", traceID)
r = r.WithContext(ctx)
log := zerolog.Ctx(ctx).With().Str("trace_id", traceID).Logger()
zerolog.Ctx(ctx) = &log
next.ServeHTTP(w, r)
})
}
日志直接发往 Loki / OpenTelemetry Collector，别碰本地文件
写本地文件 + 轮转 + Filebeat 同步，是遗留系统妥协方案。Go 微服务应优先走 HTTP 或 gRPC 直传，降低运维链路和丢日志风险。
- Loki 推荐用
prom/logproto+ HTTP POST，每条日志作为PushRequest发送；注意设置user_id（如租户 ID）和labels（如{service="order-svc", env="prod"}） - 若已接入 OpenTelemetry，用
go.opentelemetry.io/otel/sdk/log+otlploghttpexporter，自动对齐 trace_id 和 span_id - 禁用异步缓冲（如 zerolog 的
SyncWriter包裹os.Stdout）—— 它只解决 IO 阻塞，不解决网络失败重试；应使用带重试、背压、队列的专用 client（如grafana/loki/clients/pkg/promtail/client）
避免日志敏感信息泄露和性能陷阱
微服务日志最常踩的两个坑：一是把用户手机号、token、SQL 参数原样打出来；二是高频日志导致 GC 压力暴增或 goroutine 泄漏。
- 禁止在日志中拼接
fmt.Sprintf("%+v", user)—— 改用显式字段：.Str("user_id", u.ID).Int64("balance_cents", u.Balance) - 对密码、token、auth header 等字段做白名单过滤，可在中间件或 logger hook 中统一 scrub
- 高频路径（如健康检查、metrics 拉取）必须设日志等级为
DebugLevel并默认关闭；用zerolog.LevelField+ 日志后端 filter 控制展示，而非代码里 if 判断 - 不要用
defer logger.Info().Msg("end")包裹整个 handler —— 若 handler panic，defer 可能拿不到完整上下文；改用 recover + 显式 error 日志
真正难的不是选哪个库或怎么发日志，而是让每个开发在写 logger.Info() 前，下意识想清楚：这个字段是否可被搜索？是否带 trace_id？会不会暴露凭证？有没有在 for 循环里狂打？
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
