Go生产级日志收集需自主组装输入源、解析器、过滤逻辑和输出目标；核心是可靠搬运加工日志流；推荐fsnotify监听具体文件、slog结构化输出、bufio.Reader安全读取、Kafka配置RequiredAcks与重试。
Go 本身不内置日志收集服务，log 包只适合单机调试；真要开发生产级日志收集工具，得自己组装：输入源（文件、socket、stdout）、解析器（正则或结构化解析）、过滤/转换逻辑、输出目标（ES、Kafka、本地文件）。核心不是“怎么打日志”，而是“怎么可靠地搬运和加工日志流”。
用 fsnotify 监听日志文件变动而不是轮询
轮询（time.Ticker + os.Stat）浪费 CPU 且延迟高；fsnotify 基于 inotify/kqueue，事件驱动，实时性好。但要注意：
- 监听路径必须是**具体文件**，不能是通配符（如
/var/log/nginx/*.log），需先filepath.Glob找出所有匹配文件，再逐个监听 - 文件 rotate 后（如
app.log → app.log.1）旧 fd 会失效，需监听OpRemove或OpRename并重新Open - 多个进程写同一文件时，
fsnotify不保证事件顺序，需在读取时用Seek(0, io.SeekEnd)定位到最新位置
用 log/slog（Go 1.21+）统一结构化日志格式
如果收集的是 Go 应用自身日志，别用 log.Printf，直接上 slog 输出 JSON：
slog.With(
slog.String("service", "api"),
slog.String("host", os.Getenv("HOSTNAME")),
).Info("request completed",
slog.Int("status", 200),
slog.Duration("duration_ms", time.Since(start)),
)这样下游解析无需正则，字段名、类型、嵌套结构全保留在 JSON 中。若兼容老项目，可用 slog.Handler 实现自定义输出，把 log.Printf 日志转成结构体再序列化。
立即学习“go语言免费学习笔记（深入）”；
避免用 bufio.Scanner 读大日志文件导致 OOM
Scanner 默认缓冲区 64KB，遇到超长日志行（如堆栈+base64 payload）会 panic：“scan: too long”。生产环境必须改用 bufio.Reader + 手动按行切分：
- 设置足够大的缓冲区：
reader := bufio.NewReaderSize(file, 1（1MB） - 用
reader.ReadString('\n')替代Scan()，捕获io.EOF和bufio.ErrTooLong - 遇到
ErrTooLong时，跳过当前行（io.Discard）并记录告警，防止卡死
向 Kafka 写日志时必须启用 RequiredAcks 和重试
默认 sarama.AsyncProducer 是“发完即弃”，网络抖动或 broker 挂掉会导致日志丢失。关键配置：
-
Config.Producer.RequiredAcks = sarama.WaitForAll：等所有 ISR 副本写入才返回 -
Config.Producer.Retry.Max = 5+Config.Producer.Retry.Backoff = 200 * time.Millisecond - 务必监听
Errors()channel，对失败消息做降级（如写本地磁盘暂存）
没有确认机制的日志管道，和没加保险丝的电路一样——看着在跑，一出事就断档。
