Gin默认Logger()不适用于日志聚合，因其输出为带颜色的纯文本，无固定分隔符、缺trace_id/service_name等关键字段、时间戳非ISO8601、无显式level字段，导致Loki/ELK无法解析和聚合。
Gin 默认日志不能直接用于微服务日志聚合，必须改造成结构化、可解析的格式（如 JSON），否则 Loki/ELK 无法提取字段、做聚合分析。
为什么默认 gin.Logger() 输出不适用于日志聚合
默认日志是带颜色的纯文本，例如：[GIN] 2024/05/20 - 15:30:00 | 200 | 1.2345ms | 127.0.0.1 | GET "/api/user/info"。这种格式的问题很实际：
- 没有固定分隔符，正则解析脆弱，稍一改格式就崩
- 缺少 trace_id、service_name、host 等关键上下文字段，无法跨服务串联请求
- 时间戳不是 ISO8601 标准格式（
2024/05/20 - 15:30:00vs2024-05-20T15:30:00Z），Loki 的 `line_format` 或 PromQL 时间函数会失效 - 日志级别隐含在状态码里（比如 5xx 才算 error），但聚合系统需要显式的
level="error"字段才能做告警
用 gin.LoggerWithConfig() 输出 JSON 日志（不引入第三方库）
如果你只想用 Gin 原生能力快速上线结构化日志，gin.LoggerWithConfig() 配合自定义 Formatter 就够用，关键是把所有字段塞进 JSON 字符串里：
loggerConfig := gin.LoggerConfig{
Output: os.Stdout, // 或 io.MultiWriter(os.Stdout, file)
DisableColors: true,
SkipPaths: []string{"/health", "/metrics"},
Formatter: func(param gin.LogFormatterParams) string {
// 注意：这里必须手动 escape 双引号，或用 json.Marshal
b, _ := json.Marshal(map[string]interface{}{
"time": param.TimeStamp.Format(time.RFC3339),
"status": param.StatusCode,
"latency": param.Latency.String(),
"client_ip": param.ClientIP,
"method": param.Method,
"path": param.Path,
"user_agent": param.Request.UserAgent(),
"referer": param.Request.Referer(),
"level": map[int]string{400: "warn", 401: "warn", 403: "warn", 404: "warn", 500: "error", 502: "error", 503: "error", 504: "error"}[param.StatusCode],
})
return string(b) + "\n"
},
}
r.Use(gin.LoggerWithConfig(loggerConfig))
- 不要直接拼接 JSON 字符串（容易漏转义），优先用
json.Marshal -
level字段需按状态码映射，Gin 原生无日志级别概念，这是你补足的关键一环 - 若需 trace_id，得提前在中间件中从 header 提取并存入
c.Set("trace_id", ...)，再在Formatter中通过param.Context.Value("trace_id")拿到
生产环境必须补上的三个字段：trace_id、service_name、env
只靠请求信息远远不够。日志聚合系统（如 Grafana Loki）依赖这三者做多维过滤和下钻分析：
-
trace_id：必须从X-Trace-ID或traceparentheader 注入，否则无法关联下游调用 -
service_name：硬编码为你的服务名，比如"auth-service"，不能用主机名或 IP -
env：明确标出"prod"/"staging"，避免测试日志污染生产仪表盘
示例补全逻辑（放在 Formatter 中）：
traceID := "unknown"
if t := param.Context.GetString("trace_id"); t != "" {
traceID = t
}
// 然后加进上面的 map： "trace_id": traceID, "service_name": "order-service", "env": "prod"
注意：param.Context 是 *gin.Context，它支持 GetString，但前提是上游中间件已调用过 c.Set("trace_id", ...)。
logrus + zap 真正该用在哪？
原生 gin.LoggerWithConfig 能解决“有无结构化日志”的问题，但不该用来替代业务日志。真正的分层应该是：
- HTTP 访问日志：用
gin.LoggerWithConfig输出 JSON，轻量、低开销、只含必要字段 - 业务日志（如“用户支付成功”、“库存扣减失败”）：用
logrus或zap，走 Hook 写文件+网络，支持字段打点、异步写入、采样 - panic 日志：仍用
gin.Recovery()，但它的输出也要重定向成 JSON，并确保包含stacktrace字段（原生 Recovery 不带）
最容易被忽略的一点：很多人把所有日志都塞进一个 logrus 实例，结果访问日志和业务日志混在一起，导致 Loki 查询变慢、字段冲突。保持分离才是可维护性的起点。
