echo 默认日志不支持分布式追踪上下文透传，因其 logger 无上下文感知、不绑定 echo.context 且不读取 context.context 中的 trace_id 等字段。
为什么 Echo 默认日志不支持分布式追踪上下文透传
Echo 自带的 echo.Logger 是本地内存级、无上下文感知的日志器，它不会自动提取或注入 trace_id、span_id 等分布式追踪字段。当你在微服务中用 echo.HTTPErrorHandler 或中间件打日志时，所有请求日志都丢失链路标识，导致 ELK 或 Loki 中无法按一次请求聚合多服务日志。
根本原因在于：Echo 的 Logger 不绑定 echo.Context，也不读取 context.Context 中的值 —— 它只认自己的 echo.Logger.Output 和固定字段（如 time、level、message）。
- 别试图给
echo.Logger.SetPrefix()拼接 trace_id：每次请求上下文不同，这个 prefix 是全局静态的 - 别直接在 handler 里用
log.Printf()：绕过 Echo 日志体系，丢失结构化能力，且无法统一采样或异步写入 - 必须让每条日志行携带从 HTTP Header（如
traceparent）或echo.Context中提取的追踪 ID
用 middleware.RequestID + 自定义 echo.Logger 注入 trace 字段
最轻量且兼容的做法是：先用官方 middleware.RequestID 生成/透传 request_id，再把它塞进自定义日志器；若需对接 OpenTelemetry，则额外加一层 otel.GetTextMapPropagator().Extract() 提取 trace_id。
实操关键点：
- 启用
middleware.RequestID并指定 Header 名（推荐X-Request-ID），它会把 ID 写入c.Request().Context()和c.Get("request-id") - 替换默认 logger：用
echo.New().Logger = &customLogger{}，其中customLogger实现echo.Logger接口，重写Output()方法，在写入前从echo.Context取 ID - 不要在
Output()里调c.Get()—— 因为Output()没有echo.Context参数；正确做法是：在中间件中把 ID 注入c.Logger的SetPrefix()或更推荐——用c.Logger.SetLevel()不行，得用字段式结构日志器（见下一条）
所以更可行的是弃用 echo.Logger，改用结构化日志库（如 zerolog）并绑定到 echo.Context：
// 在中间件中
e.Use(func(next echo.HandlerFunc) echo.HandlerFunc {
return func(c echo.Context) error {
// 从 header 或 context 提取 trace_id
traceID := c.Request().Header.Get("traceparent")
if traceID == "" {
traceID = c.Request().Header.Get("X-Trace-ID")
}
// 创建带字段的子 logger
log := zerolog.Ctx(c.Request().Context()).With().
Str("trace_id", traceID).
Str("request_id", c.Response().Header().Get(echo.HeaderXRequestID)).
Str("path", c.Request().URL.Path).
Logger()
c.Set("logger", &log)
return next(c)
}
})
对接 Loki / Fluentd 时避免 zerolog.ConsoleWriter 误用
开发期用 ConsoleWriter 看日志很直观，但它输出的是 ANSI 颜色编码 + 换行格式化文本，Loki 的 promtail 或 Fluentd 的 in_tail 插件会把它当多条日志解析（尤其遇到 \x1b[32m 这类控制字符），导致单次请求日志被切碎、trace_id 丢失。
上线必须切换为纯 JSON 输出：
- 禁用
ConsoleWriter，改用zerolog.New(os.Stdout)（默认就是 JSON） - 确保
zerolog.TimeFieldFormat设为zerolog.TimeFormatUnix或time.RFC3339，避免时间字段含空格或时区符号引发解析失败 - Loki 要求每行一个 JSON 对象，不能有空行或注释 —— 所以不要用
zerolog.PrettyJSONWriter - 如果用
gRPC直推 Loki（如通过loki-client-go），注意 batch size 和 timeout，否则高并发下日志堆积在内存里不发
echo.HTTPErrorHandler 中如何获取当前请求的 trace_id
默认 HTTPErrorHandler 只接收 error 和 echo.Context，但此时请求可能已结束、c.Get("logger") 已不可靠；更稳的方式是：在错误发生前，把必要字段（包括 trace_id）存进 c.Request().Context()，并在 handler 里显式取出。
示例：
e.HTTPErrorHandler = func(err error, c echo.Context) {
// 从 context 取 trace_id（前提是中间件已 set）
ctx := c.Request().Context()
traceID, _ := ctx.Value("trace_id").(string)
// 用结构化 logger 记录
log := zerolog.Ctx(ctx).With().
Str("trace_id", traceID).
Err(err).
Str("method", c.Request().Method).
Str("path", c.Request().URL.Path).
Int("status", c.Response().Status).
Logger()
log.Error().Msg("http error")
c.JSON(http.StatusInternalServerError, map[string]string{"error": "internal server error"})
}
注意：ctx.Value() 是非类型安全的，建议封装一个 type ctxKey string 常量作为 key，而不是硬写 "trace_id" 字符串。
真正容易被忽略的是：如果你用了 echo.HTTPErrorHandler，但没在中间件中把 trace_id 存进 context.Context，而是只存 c.Set()，那这里就拿不到 —— 因为 c.Set() 的生命周期只到 handler 返回，而 error handler 是独立调用的。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
