Go应用在云原生环境中需输出JSON格式结构化日志到stdout，使用zap等高性能库替代标准log，结合Fluentd或Promtail采集，通过EFK或Loki实现集中式日志管理，并注入trace_id实现跨服务追踪。
在云原生环境中，Go应用通常部署在Kubernetes等容器编排平台中，日志聚合的关键在于统一格式、集中采集和高效传输。Golang本身没有内置的日志聚合机制，但可以通过标准库结合外部工具实现完整的日志收集链路。
使用结构化日志输出（JSON格式）
云原生环境推荐使用结构化日志，便于后续解析和检索。Go标准库log功能较弱，建议使用uber-go/zap或rs/zerolog这类高性能结构化日志库。
以zap为例：
logger, _ := zap.NewProduction()
defer logger.Sync()
logger.Info("请求处理完成",
zap.String("method", "GET"),
zap.String("path", "/api/users"),
zap.Int("status", 200),
)
输出为JSON格式，包含时间戳、级别、消息和自定义字段，适合被Fluentd、Loki等工具抓取解析。
立即学习“go语言免费学习笔记（深入）”；
将日志写入标准输出
Kubernetes默认通过kubelet采集容器的stdout和stderr日志。Go应用应避免直接写文件，而是将结构化日志打印到控制台。
- 禁用本地日志文件，交由Sidecar或DaemonSet采集
- 确保每条日志一行输出，避免换行干扰采集
- 使用环境变量控制日志级别，如LOG_LEVEL=info
集成日志采集系统
常见方案有EFK（Elasticsearch + Fluentd + Kibana）或Grafana Loki + Promtail组合。
在K8s中部署方式：
- 使用DaemonSet部署Fluentd或Promtail，监听所有节点的容器日志目录
- 日志经处理后发送至Elasticsearch或Loki存储
- 通过Kibana或Grafana查询分析
Loki更轻量，按标签索引，适合与Prometheus监控体系集成。
添加上下文追踪信息
在微服务中，单个请求可能经过多个Go服务。为日志注入trace_id、span_id等字段，可实现跨服务日志关联。
结合OpenTelemetry，自动注入追踪上下文：
ctx := context.WithValue(context.Background(), "trace_id", "abc123")
logger.Info("处理订单", zap.Any("ctx", ctx))
采集系统可根据trace_id串联整个调用链日志。
基本上就这些。核心是：Go服务输出结构化日志到stdout，采集代理统一收集，后端系统做存储和查询。不复杂但容易忽略细节。
