如何使用Golang实现日志收集系统_日志采集与上报方案
生产环境需用zap或zerolog替代log包，因其支持结构化日志、高性能、轮转与多输出；采集端须用tail+Reopen处理rotate，上报需缓冲、重试、超时控制，并按Loki或ELK要求格式化。
用 log 包写本地日志不够，得用 zap 或 zerolog
Go 标准库的 log 包
zap（Uber 开源）或 zerolog（零分配设计），它们生成 JSON 日志，字段可被 Filebeat / Fluent Bit 识别。
-
zap启动快、日志格式稳定，但需显式调用Sync()避免进程退出时丢日志 -
zerolog更轻量，With().Str("service", "api").Msg("started")这种链式写法更直观 - 避免在日志中拼接字符串（如
log.Printf("user %s failed: %v", uid, err)），会丢失结构字段，改用结构化字段传参
用 tail + inotify 实时读取日志文件（Linux 场景）
日志采集器（如 Filebeat）本质就是持续监听文件末尾追加内容。自己实现简易版时，别用 os.OpenFile 每次重读——文件可能被 logrotate 切走。要用 golang.org/x/exp/inotify 或更成熟的 github.com/hpcloud/tail 库。
-
tail.TailFile("/var/log/myapp/app.log", tail.Config{Follow: true, Reopen: true})自动处理 rotate 后的文件重开 - 注意：
Reopen: true是关键，否则 rotate 后采集停摆 - 不要自己解析时间戳字段做排序，日志行顺序由写入顺序保证；采集端只负责“按行吐出”，排序交给后端（如 Loki、ES）
上报前必须加缓冲与重试，别让 HTTP 超时卡死主流程
日志上报是异步 IO 密集型任务，不能阻塞业务逻辑。常见错误是每条日志都 http.Post 一把，既慢又易失败。
- 用带缓冲的 channel 接收日志行（如
ch := make(chan []byte, 1000)），单独 goroutine 批量消费 - 批量大小建议 10–100 条/次，HTTP body 控制在 1MB 内，避免网关截断
- 失败时把整批日志回退到内存队列 or 本地磁盘暂存（如
os.WriteFile("log_buffer_20250512.tmp", data, 0644)），并指数退避重试 - 别忽略
http.Transport的超时设置：&http.Transport{IdleConnTimeout: 30 * time.Second}
上报目标选 Loki 还是 ELK？看标签维度和查询习惯
上报协议决定架构复杂度。Loki 只索引标签（job="myapp", level="error"），不索引日志内容，存储成本低；ELK 对全文检索友好，但资源消耗高。
- Loki 要求日志必须是 JSON 格式，且至少含
ts（RFC3339 时间戳）和line字段；上报 endpoint 是/loki/api/v1/push - ELK 常走 Logstash HTTP input 或直接发到 ES
/_bulk，但需预设 mapping，否则error.message可能被映射为 text 而无法聚合 - 如果业务日志里有敏感字段（如
"user_id": "u_123"），上报前必须用正则或结构体字段过滤，不能依赖后端脱敏
package mainimport ( "go.uber.org/zap" "time" )
func main() { logger, _ := zap.NewProduction() defer logger.Sync()
// 正确：结构化字段 logger.Info("request completed", zap.String("path", "/api/user"), zap.Int("status", 200), zap.Duration("duration_ms", 123*time.Millisecond), zap.String("trace_id", "abc123"), )}
日志采集真正的难点不在“怎么发”，而在“发丢了怎么办”和“发乱了怎么对齐”。buffer 大小、重试策略、rotate 检测时机、标签一致性——这些细节不压测根本看不出问题。
