Golang Web项目如何记录访问日志_访问日志设计与存储方案

应使用结构化JSON日志中间件,通过包装responseWriter获取状态码,异步批量写入并脱敏敏感字段,配合lumberjack实现文件轮转。

net/http 中间件记录结构化访问日志

Go 标准库没有内置访问日志中间件,必须自己封装。关键不是“打日志”,而是避免阻塞请求、不丢失字段、不拖慢响应。

常见错误是直接在 HandlerFunc 里调用 log.Printf,这会导致日志写入磁盘时阻塞 goroutine;更糟的是,如果用 time.Now() 记录开始时间但没在 defer 里捕获结束时间,会漏掉耗时和状态码。

  • http.ResponseWriter 包装器(如 responseWriter 结构体)拦截 WriteHeaderWrite,确保能拿到真实 status code
  • 记录字段至少包含:remote_addrmethodpathstatuslatency_msuser_agent(可选)、referer(可选)
  • 日志输出走 io.Writer 接口,不要硬编码到 os.Stdout 或文件 —— 后续可无缝切到 lumberjack.Logger 或 Kafka
func loggingMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        lw := &loggingResponseWriter{ResponseWriter: w, status: 200}
        next.ServeHTTP(lw, r)
    log.Printf("%s %s %d %dms %s",
        r.RemoteAddr,
        r.Method+" "+r.URL.Path,
        lw.status,
        time.Since(start).Milliseconds(),
        r.UserAgent(),
    )
})

}

日志格式选 JSON 还是文本?优先 JSON

文本日志看着简单,但后续做聚合分析、接入 ELK 或 Loki 时,字段提取极易出错 —— 比如 User-Agent 里含空格或引号,正则一崩全崩。

JSON 日志天然结构化,且 Go 的 encoding/json 性能足够应付万级 QPS(实测单核 3–5k 条/秒无压力),关键是字段名统一、可嵌套、易扩展。

  • 避免用 map[string]interface{} 动态拼 JSON,字段顺序不可控,且反射开销大;定义结构体 + json:"field_name" 标签更稳
  • 敏感字段如 Authorization 头、cookie 值必须脱敏(置空或哈希),不能原样记录
  • 时间字段用 time.Time 类型,序列化时指定 RFC3339 或 Unix 毫秒,别用字符串拼接
type AccessLog struct {
    Time     time.Time `json:"time"`
    IP       string    `json:"ip"`
    Method   string    `json:"method"`
    Path     string    `json:"path"`
    Status   int       `json:"status"`
    Latency  float64   `json:"latency_ms"`
    UserAgent string   `json:"user_agent,omitempty"`
}

// 使用示例 logEntry := AccessLog{ Time: time.Now(), IP: r.RemoteAddr, Method: r.Method, Path: r.URL.Path, Status: lw.status, Latency: time.Since(start).Seconds() * 1000, UserAgent: r.UserAgent(), } enc := json.NewEncoder(os.Stdout) enc.Encode(logEntry)

本地文件滚动:用 lumberjack.Logger 而非自实现

自己写文件 rotate 逻辑容易出错:竞态条件导致日志丢失、rename 失败卡死、inode 泄露。社区成熟的 lumberjack 已覆盖所有边界场景。

它不是日志框架,只是一个符合 io.WriteCloser 接口的轮转文件写入器,可直接传给 log.SetOutput 或任何需要 io.Writer 的地方。

  • MaxSize 建议设为 100(MB),太大难排查,太小频繁切换影响性能
  • MaxBackups 控制保留几个历史文件,线上建议 7(一周)
  • MaxAge 是按天清理,和 MaxBackups 是“或”关系,两个都设更稳妥
  • 注意:它不支持按小时切分,如需小时级归档,得配合外部脚本或换用 file-rotatelogs
logWriter := &lumberjack.Logger{
    Filename:   "/var/log/myapp/access.log",
    MaxSize:    100, // MB
    MaxBackups: 7,
    MaxAge:     7, // days
    Compress:   true,
}
log.SetOutput(logWriter)

高并发下日志写入瓶颈在哪?异步批量刷盘是关键

当 QPS 超过 1k,同步写文件或网络日志服务(如 Loki)会成为瓶颈,表现为 HTTP 延迟陡增、goroutine 积压。根本原因不是磁盘慢,而是每次写都触发系统调用

+ 锁竞争。

解决思路不是“更快地写”,而是“少写几次”。用 channel + worker goroutine 批量缓冲日志条目,再统一落盘或发往远端。

  • channel 缓冲区大小建议设为 1000–5000,太小易丢日志,太大内存占用高
  • worker 每次从 channel 取 min(100, len(ch)) 条批量处理,兼顾延迟与吞吐
  • 务必加 recover 防止 worker panic 导致日志静默丢失
  • 进程退出前要 close(ch) 并等待 worker 清空缓冲,否则最后几条日志会丢

真正复杂的点不在代码,而在权衡:buffer 太大,OOM 风险上升;batch 太大,故障时丢失更多日志;异步后无法保证日志 100% 不丢 —— 如果业务要求强一致性(如支付回调日志),就得退回到同步写 + SSD + 写缓存优化。