用 exec.Command("docker", "logs", "-f", containerID) 启动子进程并 StdoutPipe() 实时读取日志，需设置 Cmd.Stderr = Cmd.Stdout 防丢失、手动处理 io.EOF 重试、避免高频启进程；日志结构化用 slog.NewJSONHandler 注入容器上下文，指标采集通过 Docker API /stats 或 cgroup 解析，关联日志与指标需透传 trace ID。
如何用 docker logs + Go 实时读取容器日志
Go 本身不直接管理 Docker 日志，但可通过调用 docker logs 命令或 Docker Engine API 获取。直接 exec docker logs -f 最简单，适合轻量集成：
- 用
exec.Command("docker", "logs", "-f", containerID)启动子进程，StdoutPipe()接流，注意设置Cmd.Stderr = Cmd.Stdout避免日志丢失 - 必须手动处理连接中断：容器重启、Docker daemon 挂掉时，
Read会返回io.EOF或os.SyscallError，需重试逻辑，不能只靠 defer 关闭 - 若用 Docker API（如
github.com/docker/docker/api/types），需传Follow: true和Timestamps: true，否则默认只返回历史日志且无时间戳 - 避免在高并发场景为每个容器启一个
docker logs -f进程——资源开销大；可改用 Docker events + logs API 组合，监听start事件后再拉日志
用 github.com/prometheus/client_golang 采集容器指标
Go 程序自身暴露指标容易，但要采集运行中容器的 CPU、内存等，得依赖 cgroup 数据或 Docker API，而非直接用 Prometheus 客户端库“抓”容器：
-
client_golang只负责暴露 HTTP 端点（如/metrics）和定义指标类型；真正采集容器指标需自己读/sys/fs/cgroup/...或调GET /containers/{id}/stats - Docker stats API 返回流式 JSON，需用
bufio.Scanner分帧解析，不能直接json.Decode整个响应体，否则阻塞 - 内存指标单位是字节，但
memory_stats.usage包含内核内存，实际可用值应看memory_stats.stats.cache和memory_stats.stats.rss的差值 - 别把容器 stats 指标直接注册成
prometheus.GaugeVec后反复.Set()——高频更新（如 1s 一次）会导致 Prometheus 抓取时样本堆积；建议用prometheus.NewGaugeFunc动态计算
日志结构化：用 log/slog 输出 JSON 并打上容器上下文
Go 程序跑在容器里时，原生日志只是纯文本，不利于后续用 Loki 或 ELK 聚类分析。关键不是“怎么输出”，而是“怎么让每条日志自带身份信息”：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 启动时从环境变量读取
HOSTNAME、CONTAINER_ID（可通过/proc/1/cgroup解析），注入到slog.HandlerOptions.AddSource = true之外的字段中 - 用
slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{AddSource: false})，避免源码路径干扰日志解析；同时通过slog.With("container_id", id)统一前置属性 - 别在 handler 里动态查
/proc/self/cgroup——每次写日志都 open+read，性能暴跌；应在初始化阶段解析一次并缓存 - 如果程序作为 sidecar 注入，且宿主机已挂载
/var/run/docker.sock，可额外补全镜像名、标签等字段，但要注意 socket 权限和超时控制（默认 30s 太长）
指标与日志关联：用 trace ID 对齐 Prometheus 和 Loki 查询
排查问题时，单看 CPU 高或某条错误日志都不够，需要知道“这个请求在哪个容器里耗了 2s，期间打了哪些日志”。核心是让日志和指标共享同一个 trace 上下文：
立即学习“go语言免费学习笔记（深入）”；
- 用
go.opentelemetry.io/otel/trace生成 trace ID，并在日志中显式注入：slog.String("trace_id", span.SpanContext().TraceID().String()) - Prometheus 不原生支持 trace ID 标签，但可在指标 label 中加
trace_id（仅调试用，切勿高频打点，否则 cardinality 爆炸） - Loki 查询时用
{job="my-app"} |= "trace_id=..."，Prometheus 查对应时间窗口的container_cpu_usage_seconds_total，二者时间对齐即可定位 - 注意 trace ID 是 16 字节 hex 字符串，Loki 默认索引只建在前 128 字符，过长的 trace ID 可能无法被索引——建议截断或用 base32 编码压缩
真正难的不是写几行代码把日志吐出去，而是让日志字段和指标 label 在语义上一致、生命周期上同步、查询时能互相跳转。很多团队卡在 trace ID 没透传到日志、cgroup 路径拼错、或者 stats API 返回空流却没设 timeout——这些细节不验证，监控就只是摆设。
