Go微服务日志收集必须结构化输出至文件或stdout，配合Filebeat（推荐）或Fluent Bit（K8s首选）采集，禁用网络直传；需配置multiline、force_close_files、JSON解析等关键参数确保trace_id可查、panic堆栈完整、日志不丢失。
Go微服务日志收集不能靠 log.Printf 直接打 stdout 或文件就完事——那样进不了 ELK，查不到 trace_id，panic 堆栈被切成几十条，线上出问题时连哪条日志属于同一个请求都串不起来。真正能落地的方案只有两类：基于 Filebeat 的文件采集（推荐），或基于 Fluent Bit 的容器 stdout 采集（K8s 场景首选）。
Go 服务该往哪写日志？别碰网络直传
Go 程序本身没有内置日志转发能力，zap、zerolog 都只负责格式化和写入，不负责发 HTTP / TCP 到 ES 或 Logstash。硬接 elastic/go-elasticsearch 容易协程卡死、连接泄漏、丢日志；用 logrus + logstash 插件更是小众且维护停滞。
- ✅ 正确做法：把结构化 JSON 日志写到文件（用
lumberjack.Logger轮转）或 stdout（Docker/K8s 场景） - ❌ 错误做法：在 handler 里 new 一个 ES client 写日志；或用
log.SetOutput塞http.Post的 body - ⚠️ 注意：
os.OpenFile必须带os.O_APPEND | os.O_CREATE，并发写安全；别用io.MultiWriter套多个文件句柄，会竞争 offset
Filebeat 配置关键点：路径、multiline、force_close_files
Filebeat 不是“装上就能用”的工具，它对 Go 日志有强依赖——尤其 panic 堆栈和轮转行为。
-
paths必须精确匹配，比如/var/log/myapp/*.log；Filebeat 用户（如filebeat）得有读权限，否则 silent fail - Go 的 panic 是多行的，必须开
multiline：multiline.pattern: '^panic:'+multiline.negate: true+multiline.match: before；用after会吞掉第一行，ES 里搜不到panic关键词 -
lumberjack轮转后新文件 inode 变了，Filebeat 默认还盯着旧 inode 读——必须设force_close_files: true，否则日志“消失” -
scan_frequency建议调成1s（默认 10s），但别更低；close_inactive: 5m和clean_removed: false配合MaxBackups: 5防删太快
Fluent Bit 更适合 K8s 场景：不用改 Go 代码
如果你的 Go 服务跑在 Kubernetes 里，直接输出 JSON 到 stdout 是最轻量、最可靠的方式。Fluent Bit 作为 DaemonSet 部署，自动采集所有容器日志，比 Filebeat 更省心。
立即学习“go语言免费学习笔记（深入）”；
- Go 侧只需初始化
zerolog.New(os.Stdout)或zap.NewStdLogAt(..., zapcore.InfoLevel)，中间件注入trace_id和service字段 - Fluent Bit 的
[INPUT]用tail（读/var/log/containers/*.log）或forward（收 Docker logs API）；[FILTER]开parser解析 JSON，加kubernetes插件注入 pod name、namespace - 避免用
stdout输出非 JSON 内容（比如调试时的fmt.Println），否则 Fluent Bit 解析失败，整条日志进log字段变成字符串 - 字段命名统一用小写字母+下划线（如
trace_id），ES 不支持驼峰或点号嵌套字段（req.user.id会被当字符串）
ELK 搭建本身不是难点，难点在日志从 Go 进去那一刻是否“可检索、可关联、不丢”。Filebeat 的 force_close_files、Fluent Bit 的 parser 配置、以及 Go 侧 lumberjack 的 MaxAge 和 MaxBackups ——这些参数看着琐碎，但任意一个配错，都会导致线上查日志时发现“明明打了日志，却在 Kibana 里搜不到”。
