云原生Go日志聚合核心是标准化JSON输出+外部工具链协同：服务只输出含time/level/msg/service/env/host/trace_id/request_id的结构化日志到stdout，由Fluent Bit/Vector采集并提升字段为标签，后端选用Loki（低成本标签索引）或ELK（全文检索），通过统一trace_id实现跨服务关联查询。
用 Golang 实现云原生应用日志聚合，核心是让日志“可采集、可关联、可查询”。不是靠 Go 自己做汇总，而是通过标准化输出 + 外部工具链协同完成。关键不在写多少代码，而在设计好日志结构和流转路径。
统一输出结构化 JSON 日志到 stdout
Go 服务不写文件，只往 os.Stdout 打印单行 JSON。这是 Kubernetes 日志采集的默认入口。
- 选用 zap（生产推荐）或 zerolog：性能高、原生支持结构化字段，避免用标准
log包拼字符串 - 每条日志必须含基础字段：
time、level、msg、service、env、host - HTTP 请求场景下，中间件中注入
request_id和trace_id（从 OpenTelemetry Context 提取），并透传到所有子日志 - 错误日志要带完整堆栈：
logger.Error("db timeout", zap.Error(err))，zap/zerolog 会自动序列化
配合采集器做轻量增强与路由
Kubernetes 中不依赖应用自己转发日志，而是由采集器在节点或 Pod 层处理。
- 推荐 Fluent Bit（资源省）或 Vector（功能强）：以 Sidecar 容器部署，读取同一 Pod 的 stdout 流
- 采集器需开启 JSON 解析，把日志中的字段提升为 top-level 标签（如
service="order-api"），方便 Loki/ES 按标签索引 - 可按 level 或 service 做简单分流：比如
level=error同时发 Slack 和 ES；service=payment单独存入长期归档桶 - 避免在采集器里做复杂清洗，保持低延迟；真正需要的 enrichment（如解析 user-agent）放在后端处理更稳妥
选择后端存储并打通查询体验
日志后端不求大而全，而要贴合团队技术栈和排查习惯。
立即学习“go语言免费学习笔记（深入）”；
-
Loki + Grafana：适合多数 Go 微服务场景。它不索引日志内容，只索引标签（
{service="user", level="error"}），存储成本低，LogQL 查询简洁，天然与 Prometheus 指标联动 - ELK（Elasticsearch + Filebeat + Kibana）：适合需要全文检索、正则匹配、高频关键词分析的团队。注意 ES 资源消耗明显更高，需合理设置分片与 TTL
- 无论选哪个，都要启用 日志采样（如 debug 日志只保留 1%）和 生命周期管理（如 error 日志保留 30 天，info 保留 7 天）
让日志真正可追踪、可关联
单条日志没意义，关键在于跨服务串联。
- 所有 Go 服务使用同一套 trace propagation 规范（如 W3C Trace Context），确保
trace_id在 HTTP Header、gRPC Metadata、消息队列中正确透传 - 日志字段中固定使用
trace_id（不是traceId或TraceID），保证 LogQL/Elasticsearch 查询一致性 - Grafana 中点击某条日志的
trace_id，可一键跳转到 Tempo 查看完整调用链；Kibana 中可用 Discover 页面按trace_id过滤全部相关日志 - 避免手动拼接 trace_id 字段，用中间件或 context 封装通用 logger 构造逻辑，减少遗漏
