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 倍。
立即学习“go语言免费学习笔记（深入）”；
- 如果你常做「指标 + 日志 + 链路」三者联动（比如 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 日志库参数重要得多。
