统一日志收集应让服务只输出结构化JSON到stdout，由Promtail/Fluent Bit采集并提取trace_id等标签；禁用caller和堆栈，用OpenTelemetry自动注入trace_id，命名需统一规范。
统一收集不是靠 Go 代码“主动发日志”，而是让每个服务只管输出结构化日志，剩下的交给外围系统——这是最稳定、可扩展性最强的做法。关键在于格式一致、上下文不丢、采集不漏。
用 zap.NewProduction() 输出单行 JSON 到 stdout
容器环境下，stdout 是唯一可靠出口。写文件反而会引入权限、轮转、挂载、清理等运维负担，且 Kubernetes 无法自动注入 Pod 元数据（如 pod_name、namespace）。
- 必须禁用
caller和堆栈（zap.AddCaller()在生产环境要关），否则 JSON 里混入换行或特殊字符，Filebeat或Promtail会切碎日志 - 不要用
log.Printf或自定义字符串拼接，字段缺失或命名不一致会导致后续查trace_id失败 - 推荐配置：启用时间戳、服务名、环境标签，用
zap.String("service", "order-service")显式传入，别依赖环境变量动态读取（容易漏）
logger, _ := zap.NewProduction()
defer logger.Sync()
// 正确：字段明确、无嵌套、单行 JSON
logger.Info("order created",
zap.String("service", "order-service"),
zap.String("trace_id", tid),
zap.String("order_id", "ORD-789"),
zap.Int("status_code", 201),
)
用 Promtail 或 Fluent Bit 从容器日志目录抓取
Kubernetes 中，容器日志默认落在 /var/log/pods/...，Promtail 能自动发现并打上 job、pod、container 等标签；Fluent Bit 更轻量，适合资源受限节点。
- 避免用
Filebeat直连容器 stdout（需额外配置dockerinput 插件），它更适合宿主机文件场景 -
Promtail的pipeline_stages可解析 JSON 字段并提升为日志标签，例如把trace_id提成trace_id="abc123"，这样在 Grafana 中就能直接用{trace_id="abc123"}过滤 - 别跳过日志采样——高并发下
INFO日志量极大，可在zap层加zap.LevelEnablerFunc控制采样率，比如每 100 条只记 1 条
用 OpenTelemetry SDK 自动注入 trace_id，不靠中间件手传
手动在每个 HTTP handler 或 gRPC interceptor 里取 header、塞 context、再传给 logger，极易遗漏或错位。OpenTelemetry Go SDK 能自动完成：
立即学习“go语言免费学习笔记（深入）”；
- HTTP server：用
otelhttp.NewHandler包裹 handler，自动从X-Trace-ID或traceparent解析并注入 context - HTTP client：用
otelhttp.NewTransport，自动透传traceparentheader - 日志联动：通过
zap.ReplaceCore+otelplog.NewZapCore，让每条logger.Info自动带上当前 span 的trace_id和span_id
这样你写的日志代码里就不用再写 zap.String("trace_id", ...) ——字段由 SDK 注入，一致性有保障。
选 Loki 还是 Elasticsearch？看团队实际需求
不是越重越好。Loki 按标签索引、无全文分析、存储成本低；Elasticsearch 支持复杂聚合和模糊搜索，但资源开销大、运维复杂。
- 如果你主要做“查某次请求在哪几个服务报错”，用 Loki + Grafana 足够快，
{service="payment", trace_id="xyz"}一秒返回 - 如果你常做“统计过去一小时所有 5xx 错误的 URL 分布”，Elasticsearch 的
terms aggregation更直观 - 注意：Loki 不解析日志内容，所以
trace_id必须作为标签提取出来（靠Promtailpipeline），不能只藏在 JSON body 里
最容易被忽略的点是字段命名规范——比如有的服务用 trace_id，有的用 traceId，有的甚至用 x-trace-id，结果在 Loki 或 Kibana 里根本关联不上。早期定好命名规则，并用 CI 检查日志语句，比后期写脚本补救省十倍力气。
