Golang微服务日志收集核心是请求入口注入上下文（含traceID、requestID等），用结构化日志库（如Zap）输出JSON格式日志至stdout，通过中间件生成唯一requestID、自动记录全链路信息（方法、路径、状态码、耗时等），并确保context传递、header透传及字段命名统一，便于Loki/ELK等平台集中采集与关联分析。
用 Golang 实现微服务日志收集并统一记录请求信息，核心在于：在每个 HTTP 请求入口处注入上下文（含 traceID、requestID、method、path、status 等），通过结构化日志库输出，并将日志集中采集到统一平台（如 Loki、ELK 或 SLS）。不依赖外部框架也能做到轻量、可控、可扩展。
1. 生成唯一请求标识（requestID / traceID）
每次请求进来，需生成一个全局唯一 ID，贯穿整个请求生命周期（包括下游调用）。推荐使用 github.com/google/uuid 或更轻量的 github.com/oklog/ulid（时间有序，适合排序排查）。
在中间件中生成并写入 context：
func RequestIDMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
reqID := ulid.Make().String()
ctx := context.WithValue(r.Context(), "request_id", reqID)
r = r.WithContext(ctx)
// 写入响应头，方便前端或网关追踪
w.Header().Set("X-Request-ID", reqID)
next.ServeHTTP(w, r)
})
}
2. 使用结构化日志库统一打点
避免 fmt.Printf 或 log.Printf，改用支持字段注入的结构化日志库，如 go.uber.org/zap（高性能）或 github.com/sirupsen/logrus（易上手）。Zap 推荐搭配 zapcore.AddSync 支持写入文件、网络或 stdout。
立即学习“go语言免费学习笔记（深入）”；
封装一个带上下文的日志函数：
func LogWithRequest(ctx context.Context, fields ...zap.Field) *zap.Logger {
reqID, _ := ctx.Value("request_id").(string)
return zap.L().With(
zap.String("request_id", reqID),
zap.String("service", "user-svc"),
zap.String("host", os.Getenv("HOSTNAME")),
fields...,
)
}
// 在 handler 中使用
func UserHandler(w http.ResponseWriter, r *http.Request) {
logger := LogWithRequest(r.Context(),
zap.String("method", r.Method),
zap.String("path", r.URL.Path),
zap.String("client_ip", getClientIP(r)),
)
logger.Info("received user request")
// ...业务逻辑
logger.Info("user request completed", zap.Int("status", 200))
}
3. 自动记录 HTTP 全链路基础信息（访问日志 + 错误日志）
用中间件自动记录耗时、状态码、路径、方法、错误等，避免每个 handler 重复写：
- 使用
http.ResponseWriter包装器捕获 status code 和 body size - 记录开始时间，defer 中计算耗时
- panic 或 error 发生时，额外记录堆栈（仅限 zap 开启 development 模式或配置 error level）
type responseWriter struct {
http.ResponseWriter
statusCode int
size int
}
func (rw *responseWriter) WriteHeader(code int) {
rw.statusCode = code
rw.ResponseWriter.WriteHeader(code)
}
func (rw *responseWriter) Write(b []byte) (int, error) {
size, err := rw.ResponseWriter.Write(b)
rw.size += size
return size, err
}
func LoggingMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
start := time.Now()
rw := &responseWriter{
ResponseWriter: w,
statusCode: 200,
}
next.ServeHTTP(rw, r)
duration := time.Since(start)
logger := LogWithRequest(r.Context(),
zap.String("method", r.Method),
zap.String("path", r.URL.Path),
zap.Int("status", rw.statusCode),
zap.Int("size", rw.size),
zap.Duration("duration", duration),
)
if rw.statusCode >= 400 {
logger.Error("http request failed")
} else {
logger.Info("http request completed")
}
})
}
4. 日志输出与统一采集对接
本地日志建议输出为 JSON 格式（便于解析），并通过标准流（stdout）输出，由容器编排平台（如 Kubernetes）统一收集：
- K8s 配合 Fluent Bit / Filebeat → Kafka / Loki / ES
- 若直连 Loki，可用
grafana/loki/clients/golangSDK 异步推送（不推荐，增加耦合和失败风险） - 关键：确保每条日志含
request_id、service、timestamp，便于跨服务关联
示例 Zap 配置（JSON 输出到 stdout）：
cfg := zap.NewProductionConfig()
cfg.OutputPaths = []string{"stdout"}
cfg.ErrorOutputPaths = []string{"stderr"}
logger, _ := cfg.Build()
zap.ReplaceGlobals(logger)
不复杂但容易忽略：所有 goroutine 启动前，务必显式传递携带 request_id 的 context；下游 HTTP 调用需透传 X-Request-ID 头；日志字段命名保持服务间一致（如都用 request_id 而非 reqId），才能被统一检索系统识别。
