Go应用在Kubernetes中应仅向stdout输出单行结构化JSON日志，禁用文件写入；由Promtail或Vector等采集器自动注入K8s元标签并解析字段；日志须含与OpenTelemetry一致的trace_id，且需配置采样防止流量过载。

Go 应用在云原生环境（如 Kubernetes）中不做日志聚合——它只负责结构化输出，聚合由外部可观测性链路完成。真正要做的，是让 os.Stdout 输出的每一行都可被采集器无损解析、自动打标、精准路由。

用 zap 或 zerolog 输出 JSON 到 stdout，别写文件

容器日志机制（如 Docker/Kubelet）默认只捕获 stdout 和 stderr；写文件不仅增加 I/O 开销，还容易因挂载遗漏或权限问题导致日志丢失。Kubernetes 不会自动收集 /var/log/app.log，除非你额外部署采集器去轮询它——这是反模式。

• 禁用文件写入：zerolog.SetOutput(os.Stdout) 或 zap.NewProduction()（默认已输出到 os.Stderr，需显式重定向）
• 确保每条日志是单行合法 JSON：zap.String("trace_id", span.SpanContext().TraceID().String()) 比拼接字符串安全
• 全局注入字段，避免重复传参：logger = logger.With(zap.String("service", "order-api"), zap.String("env", os.Getenv("ENV")))
• 错误日志必须带堆栈：logger.Error("db query failed", zap.Error(err))（zap.Error 会自动展开 err.Error() 和 fmt.Sprintf("%+v", err)）

在 Pod 中让日志带上 k8s 元信息（namespace/pod_name/labels）

Go 程序本身无法获取所在 Pod 的元数据，硬编码或通过 Downward API 注入环境变量再读取，既不安全又难维护。正确做法是交给采集器在采集时自动 enrich。

• 用 Promtail（Loki 方案）或 Vector（通用方案）以 DaemonSet 模式部署，它们能自动从 /var/log/pods/ 下的软链接解析出 namespace、pod_name、container_name
• 配置 Promtail 的 pipeline_stages 解析 JSON 并提升字段：

  pipeline_stages:
  - json:
      expressions:
        level: level
        trace_id: trace_id
  - labels:
      level: ""
      trace_id: ""

• 避免用 Fluentd 自己写正则解析 JSON——性能差、易出错；Fluent Bit 虽支持 parser 插件，但不如 Promtail/Vector 原生 JSON 处理稳定

选 Loki 还是 Elasticsearch？看你的查询习惯和成本敏感度

不是技术优劣问题，而是使用场景匹配问题。Loki 不索引日志内容，只索引标签（job="go-service", level="error"），所以查 {job="go-service"} |= "timeout" 是先过滤标签再流式 grep；ES 是全文倒排索引，查 "timeout AND status:500" 极快，但存储和内存开销高 3–5 倍。

• 如果你常做「指标 + 日志 + 链路」三者联动（比如 Grafana 中点击一个慢请求的 trace，直接跳转对应日志），Loki + Tempo 是更轻量闭环的选择
• 如果你需要高频做模糊匹配、正则提取字段（如从非结构化 access log 中抽 user_agent）、或已有 ES 技能栈，EFK 仍是可靠选项
• 无论选哪个，Go 日志里必须含 trace_id 字段，且与 OpenTelemetry SDK 生成的 trace ID 格式一致（16 或 32 字符 hex），否则跳转失败

最容易被忽略的一点：日志采样。生产环境不设采样，debug 日志会瞬间压垮采集链路和后端存储。Promtail 支持 sample_rate，Vector 支持 route + sample，哪怕只对 level=debug 采样 1%，也能降低 90% 以上日志流量——这比调优 Go 日志库参数重要得多。