用 docker logs -f --tail=0 启动子进程并 bufio.Scanner 逐行读取最轻量；或调 Docker API 用 ContainerLogs 获取流，需处理权限、ANSI 控制符、多行日志及连接泄漏；结合 events API 动态跟踪容器启停，用 sync.Map 管理日志流，结构化解析 JSON 或正则日志为 LogEntry。
如何用 docker logs 实时抓取容器日志并转给 Go 程序处理
Go 本身不直接读取 Docker 容器的 stdout/stderr，得靠 docker logs 命令或 Docker API。最轻量、最常用的方式是调用 docker logs -f --tail=0 启动一个持续流式输出的子进程，再用 bufio.Scanner 逐行读取。
注意点：
-
--tail=0表示从当前最新日志开始（不是从头），避免重复拉取历史日志 - 必须加
-f才能保持连接不断开；不加的话命令执行完就退出，Go 程序收不到后续日志 - 如果容器重启，
docker logs -f不会自动重连，需在 Go 层做断连检测和重试逻辑 - 建议设置
Cmd.Stdout为os.Pipe()，避免缓冲区满导致子进程阻塞
cmd := exec.Command("docker", "logs", "-f", "--tail=0", "my-app")
stdout, _ := cmd.StdoutPipe()
scanner := bufio.NewScanner(stdout)
if err := cmd.Start(); err != nil {
log.Fatal(err)
}
for scanner.Scan() {
line := scanner.Text()
// 处理单行日志，比如解析 JSON、打时间戳、转发到 Kafka
}
用 github.com/docker/docker/api/types 直接调 Docker Engine API 获取日志流
比 shell 命令更可控，适合嵌入长期运行的 DevOps 工具中。关键在于构造正确的 ContainerLogsOptions 并用 Client.ContainerLogs 获取 io.ReadCloser。
常见陷阱：
- Docker daemon 默认只监听
unix:///var/run/docker.sock，Go 程序必须有读该 socket 的权限（常被忽略，报permission denied） -
Follow: true才能持续读新日志；Tail: "0"（字符串）才等效于--tail=0，填整数会 panic - 返回的 stream 是原始字节流，含 ANSI 控制字符和多行日志块（如 Java stack trace），需用
docker/pkg/stdcopy.StdCopy或手动按\r\n/\n拆分 - 不主动关闭
ReadCloser会导致连接泄漏，尤其在轮询多个容器时
如何让 Go 日志采集器支持容器生命周期变化（启停/重建）
真实场景中容器频繁重建，硬编码容器名或 ID 会立刻失效。必须结合 Docker events API 动态跟踪。
推荐做法：
- 启动一个 goroutine 调用
Client.Events，监听start/die/destroy事件 - 对每个
start事件，提取Actor.Attributes["name"]或Actor.ID，触发新日志流采集 - 对
die事件，查本地是否已有该容器的日志 reader，有则Close()并清理 goroutine - 用
sync.Map存储containerID → *logReader映射，避免并发 map 写冲突
别依赖容器名唯一性——同名容器重建后 ID 变了，但 name 可能复用；优先用 ID 关联日志流。
日志结构化：把原始容器日志转成带字段的 Go struct 再投递
裸日志（如 2024-05-12T10:23:45Z INFO api.go:123 user login success）很难过滤分析。应在 Go 层做初步解析，至少提取时间、级别、服务名、traceID。
实操建议：
- 用正则预编译匹配常见格式：
^(?P - 若容器应用输出 JSON 日志（如
{"level":"info","ts":"2024-05-12T10:23:45Z","msg":"login success"}），直接json.Unmarshal，跳过正则开销 - 对非结构化日志，不要强求 100% 解析；未匹配行保留原始字符串，打上
raw: true标记，避免丢日志 - 最终封装成统一 struct，例如
type LogEntry { Timestamp time.Time; Level string; Service string; TraceID string; Message string }，方便后续写入 ES 或发 Kafka
真正难的不是解析，而是当几十个容器同时输出乱序、跨行、无界日志时，保证每条记录的时间戳准确、上下文不丢失——这需要在 reader goroutine 内部做小缓冲和行边界判定，不能简单按 Scanner 的 Scan() 切分。
