17370845950

log包直接写文件不适合生产Web日志收集，因其缺乏轮转、并发安全、结构化输出、动态调级等能力，易导致锁竞争、磁盘爆满、日志错乱、丢失等问题；推荐zap+lumberjack组合实现高性能结构化日志。

为什么 log 包直接写文件不适合生产 Web 日志收集

Go 标准库的 log 包默认输出到 os.Stderr，即使重定向到文件，也缺乏轮转、并发安全写入、结构化字段支持等关键能力。线上服务一旦高并发打日志，容易出现文件锁竞争、磁盘爆满、无法按天/大小切分等问题。

• 多个 goroutine 同时调用 log.Printf 写同一文件句柄，可能触发 write: broken pipe 或日志错乱（尤其配合 rotatelogs 时）
• 没有内置 JSON 输出，排查时需额外解析非结构化文本
• 无法动态调整日志级别（如运行中从 INFO 切到 DEBUG）
• log.SetOutput 替换为 *os.File 后，进程重启不自动 reopen，日志会丢失

用 zap + lumberjack 实现带轮转的结构化日志

推荐组合：Uber 的 zap（高性能结构化日志） + lumberjack（轻量轮转 writer）。它比 rotatelogs 更可控，且与 zap 的 WriteSyncer 接口天然契合。

安装依赖：

go get go.uber.org/zap
go get gopkg.in/natefinch/lumberjack.v2

核心配置要点：

• lumberjack.Logger 必须设置 LocalTime: true，否则轮转时间按 UTC 计算，和本地运维习惯不符
• MaxSize 单位是 MB（不是字节），MaxBackups: 7 表示最多保留 7 个历史日志文件
• 务必用 zapcore.AddSync 包裹 lumberjack 实例，否则 zap 不会调用其 Sync() 方法，导致日志延迟刷盘
• HTTP 请求日志建议单独用 zap.String("path", r.URL.Path) 等显式记录字段，而非依赖中间件自动提取

简易初始化示例：

import (
    "go.uber.org/zap"
    "go.uber.org/zap/zapcore"
    "gopkg.in/natefinch/lumberjack.v2"
)

func newZapLogger() (*zap.Logger, error) {
    writer := zapcore.AddSync(&lumberjack.Logger{
        Filename:   "logs/app.log",
        MaxSize:    100, // MB
        MaxBackups: 7,
        MaxAge:     28,  // days
        LocalTime:  true,
    })

    encoderConfig := zap.NewProductionEncoderConfig()
    encoderConfig.EncodeTime = zapcore.ISO8601TimeEncoder

    core := zapcore.NewCore(
        zapcore.NewJSONEncoder(encoderConfig),
        writer,
        zapcore.InfoLevel,
    )

    return zap.New(core), nil
}

在 HTTP handler 中注入请求上下文日志实例

不要在每个 handler 里重复调用 logger.With(...)。用 context.Context 透传带 trace ID 的子 logger，既避免全局变量，又保证链路可追溯。

• 中间件中生成唯一 trace_id（如用 uuid.NewString()），并存入 context.WithValue
• 用 logger.With(zap.String("trace_id", tid)) 创建子 logger，再塞回 context
• handler 函数通过 ctx.Value(loggerKey) 取出该子 logger，所有日志自动携带 trace ID
• 避免在子 logger 上反复调用 With()，每次调用都会拷贝字段 map，高频请求下有 GC 压力

关键代码片段：

type loggerKey struct{}

func LoggingMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        tid := uuid.NewString()
        logger := globalLogger.With(zap.String("trace_id", tid))
        ctx := context.WithValue(r.Context(), loggerKey{}, logger)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

func MyHandler(w http.ResponseWr
iter, r *http.Request) {
    logger := r.Context().Value(loggerKey{}).(*zap.Logger)
    logger.Info("request received", zap.String("method", r.Method), zap.String("path", r.URL.Path))
}

日志采集中容易被忽略的三个细节

日志能写出来只是第一步，真正影响可观测性的往往是这些“小地方”：

• lumberjack 的 Compress: true 会启用 gzip 压缩归档日志，但压缩过程阻塞写入 goroutine，QPS > 500 时可能拖慢主流程，建议关闭或改用异步压缩工具（如 logrotate）
• 使用 zap.Stringer 记录自定义类型时，若 String() 方法 panic，整个日志会静默丢弃——务必加 recover 包裹
• 容器环境（Docker/K8s）中，日志文件路径必须映射到宿主机或挂载 volume，否则容器重启后日志丢失；更推荐直接 stdout 输出，由日志采集 agent（如 filebeat）统一收集