Go不提供容器日志采集能力，需依赖外部机制：直接读取Docker JSON日志文件（注意inode变化与逐行解析）、调用docker logs流式获取（兼容性强但有性能开销）、或通过client-go调用Kubernetes API（推荐K8s场景），并需实现时间窗口聚合与上下文隔离的告警抑制。
Go 本身不提供容器日志采集能力，log 包只负责应用内打点；监控容器日志必须依赖外部机制——要么从宿主机读取 /var/log/containers/ 下的软链接文件，要么通过 docker logs 或 kubectl logs 实时拉取，再结合结构化解析与规则匹配做告警。
直接读取 Docker 容器日志文件（适用于 Docker Engine 环境）
Docker 默认将容器 stdout/stderr 日志以 JSON 格式写入 /var/lib/docker/containers/。Go 程序可监听这些文件的增量变化，但要注意：
-
os.OpenFile需用os.O_RDONLY | os.O_APPEND模式配合os.Seek移动到末尾，避免重复读取 - 每行是独立 JSON 对象（非 JSON 数组），需逐行
json.Unmarshal解析log、stream、time字段 - 容器重启后日志文件名不变但内容被覆盖，需监听
inode变化或定期检查文件是否被 truncate - 生产环境建议用
fsnotify监听目录事件，而非轮询
package mainimport ( "encoding/json" "fmt" "log" "os" "time" )
type LogLine struct { Log string
json:"log"Stream stringjson:"stream"Time stringjson:"time"}func tailContainerLog(path string) { f, err := os.Open(path) if err != nil { log.Fatal(err) } defer f.Close()
// 定位到文件末尾 fi, _ := f.Stat() f.Seek(fi.Size(), 0) buf := make([]byte, 1024) for { n, err := f.Read(buf) if err != nil { time.Sleep(100 * time.Millisecond) continue } if n == 0 { time.Sleep(50 * time.Millisecond) continue } lines := bytes.Split(buf[:n], []byte{'\n'}) for _, line := range lines { if len(line) == 0 { continue } var l LogLine if err := json.Unmarshal(line, &l); err == nil { if strings.Contains(l.Log, "ERROR") || strings.Contains(l.Log, "panic") { fmt.Printf("[ALERT] %s: %s\n", l.Time, l.Log) } } } }}
调用
docker logs流式获取（兼容性更强，但有性能开销）相比直接读文件，
exec.Command("docker", "logs", "-f", "--since=10m", containerID)更可靠：它自动处理日志轮转、容器重建、时间戳对齐等问题，且不依赖宿主机路径权限。但要注意：立即学习“go语言免费学习笔记（深入）”；
- 需确保 Go 进程所在容器或宿主机已安装
dockerCLI 且用户有docker.sock访问权限 -
-f参数使命令永不退出，需用cmd.Process.Kill()控制生命周期 - 输出无结构，若需提取字段（如 level、trace_id），得自行正则解析或要求应用输出结构化日志（如 logfmt、JSON）
- 频繁调用
docker logs会增加 daemon 负载，建议按容器分 goroutine + 限速
对接 Kubernetes kubectl logs 或 API Server（面向 K8s 场景）
在 K8s 中不应直接访问节点文件系统。推荐方式是使用 client-go 调用 CoreV1().Pods(namespace).GetLogs()，好处是：
- 自动处理 Pod 重建、多容器、initContainer 日志切换
- 支持
SinceTime、Previous、Follow等参数，语义清晰 - 可复用集群 RBAC 权限，无需暴露
docker.sock - 错误响应明确（如
NotFound、BadRequest），便于重试逻辑设计
注意：Follow=true 会保持长连接，务必设置 context.WithTimeout 并监听 channel 关闭信号，否则 goroutine 泄漏风险极高。
告警触发与去重的关键控制点
日志告警最常出问题的地方不是采集，而是“同一错误刷屏导致 100 封邮件”。必须做两层抑制：
-
时间窗口聚合：5 分钟内同一条错误消息（取
log字段 hash）只触发一次告警，用map[string]time.Time缓存最近触发时间 - 上下文隔离：不同容器、不同命名空间、不同 severity 级别应独立计数，避免一个 Pod 的 panic 抑制了另一个关键服务的 ERROR
- 告警发送前校验目标通道是否可用（如 Slack webhook 返回 429，邮件 SMTP 连接超时），失败需落盘重试，不能静默丢弃
真正难的从来不是“怎么拿到日志”，而是“怎么确定这条日志值得告警”——这需要业务语义理解，比如 "connection refused" 在数据库连接池里是严重故障，在重试逻辑里可能只是瞬时抖动。
