使用zap等结构化日志库输出JSON格式日志，通过stdout由Fluentd或Promtail采集，结合trace_id关联分布式调用链，集中存储至Loki或Elasticsearch，实现高效可观测性。
在Golang中实现微服务日志收集，核心是统一日志格式、集中存储和高效传输。微服务架构下，每个服务独立运行，日志分散，必须通过结构化方式采集并汇聚到统一平台，便于排查问题和监控系统状态。
使用结构化日志库（如zap或logrus）
Go标准库的log包功能有限，不适合生产环境。推荐使用支持结构化输出的日志库：
- uber-go/zap：性能高，适合高并发场景，原生支持JSON格式输出
- Sirupsen/logrus：API友好，插件丰富，可轻松输出JSON
示例（zap）：
logger, _ := zap.NewProduction()
defer logger.Sync()
logger.Info("请求处理完成",
zap.String("method", "GET"),
zap.String("path", "/api/users"),
zap.Int("status", 200),
)
这样输出的日志天然适合被收集系统解析。
立即学习“go语言免费学习笔记（深入）”；
将日志输出到标准输出供采集器抓取
在容器化部署中（如Kubernetes），不要将日志写入本地文件。应将结构化日志打印到stdout或stderr，由日志采集组件统一捕获。
- Docker默认会捕获容器的标准输出
- Kubernetes中配合Fluentd、Filebeat等sidecar或DaemonSet采集
确保每条日志包含关键字段：时间戳、服务名、trace ID、级别、消息内容。
集成分布式追踪以关联日志
微服务调用链复杂，单靠日志难以串联请求流程。结合OpenTelemetry或Jaeger，在日志中注入trace_id和span_id。
- 请求入口生成唯一trace_id
- 跨服务传递该ID（通过HTTP header或gRPC metadata）
- 每条日志记录当前trace_id，便于在ELK或Loki中按链路查询
这样可以在Grafana或Kibana中根据trace_id查看完整调用链日志。
使用日志聚合系统集中管理
将各服务输出的日志汇总到中心化平台：
- EFK Stack（Elasticsearch + Fluentd + Kibana）：适合全文检索和复杂查询
- Grafana Loki + Promtail：轻量级，与Prometheus生态集成好，按标签索引
部署Promtail作为日志收集代理，从容器stdout读取日志，打上标签（如service=auth-service, env=prod），推送到Loki。在Grafana中即可按服务、时间、关键词快速过滤。
基本上就这些。关键是服务内用zap这类库输出结构化日志，不写本地文件，通过trace_id串联上下文，再由外部系统统一收集分析。这样既能保证性能，又能实现高效的日志可观测性。
