Go监控容器需通过Docker/K8s API拉取指标，关键在安全稳定低开销地获取与判断：本地Docker连接需用户加入docker组并用API版本协商；K8s环境须用client-go+Metrics Server；告警应发HTTP至Alertmanager而非直连通知渠道。

Go 本身不直接监控容器，而是通过调用 Docker API 或 Kubernetes API 获取指标，再结合 Prometheus、Alertmanager 或自定义逻辑实现报警。关键不在“用 Go 写个容器”，而在“用 Go 安全、稳定、低开销地拉取和判断指标”。

如何用 docker/client 连接本地 Docker daemon 并获取容器状态

多数人卡在连接失败，错误信息通常是 dial unix /var/run/docker.sock: connect: permission denied 或 client is not initialized。

• 确保 Go 进程运行在 docker 用户组中：sudo usermod -aG docker $USER，然后重新登录终端
• 初始化 client 必须指定 API 版本，硬编码 "v1.41" 容易在新版 Docker 上 panic，建议用 dockerapi.DefaultVersion 或先调 /version 接口动态获取
• 不要复用未检查错误的 client：每次 client.ContainerList() 后必须检查 err != nil，Docker daemon 临时不可用时会返回 net/http: request canceled 类错误，需重试或降级

import (
    "context"
    "time"
    "github.com/docker/docker/api/types"
    "github.com/docker/docker/client"
)

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

cli, err := client.NewClientWithOpts(
    client.FromEnv,
    client.WithAPIVersionNegotiation(),
)
if err != nil {
    log.Fatal(err)
}

containers, err := cli.ContainerList(ctx, types.ContainerListOptions{All: true})
if err != nil {
    log.Printf("failed to list containers: %v", err)
    return
}

为什么不用 exec.Command("docker", "stats") 而要走 API

看似简单，但 docker stats 是 CLI 工具，底层仍走 Unix socket；直接 exec 存在三类问题：

• 输出格式不稳定：Docker 24+ 默认启用 --no-stream 模式，但旧版本默认流式输出，解析容易错位
• 权限更难控制：需要给二进制文件 + docker 命令双重 PATH 和执行权限，比 socket 文件权限更难审计
• 无法批量获取：每个 docker stats 是独立 HTTP 请求，而 client.ContainerStats() 可并发拉取多个容器，且支持 stream=false 单次快照

真正需要指标（如 CPU 百分比、内存使用量）时，ContainerStats() 返回的 *types.ContainerStats 结构体里，memory_stats.Usage 和 cpu_stats.CPUUsage.TotalUsage 需手动计算——Docker 不提供现成百分比，得自己拿 cpu_stats.SystemCPUUsage 做归一化。

在 Kubernetes 环境下，该用 client-go 还是继续用 docker/client

Kubernetes 1.24+ 已移除 dockershim，节点上大概率没 Docker daemon；此时 docker/client 直接失效。必须切到 client-go + Metrics Server。

• client-go 不能直接读容器进程指标，需先确保集群已部署 metrics-server（否则 GET /apis/metrics.k8s.io/v1beta1/pods 404）
• Pod 级指标（CPU/Mem）从 Metrics Server 获取，但容器级（如单个 container 的 restartCount）仍要走 Core API：clientset.CoreV1().Pods(ns).Get()
• 告警逻辑别写死阈值：把 CPU > 80% 这种判断抽成配置项，用 map[string]float64 支持 per-namespace 或 per-label selector 动态规则

一个常被忽略的事实：Kubernetes 的 container_status.restart_count 是累计值，但告警关心的是“5 分钟内是否突增”，得自己缓存前次值做 delta 计算——这个状态管理，比拉指标本身更易出错。

报警触发后，为什么推荐发 HTTP 而不是直接发邮件或钉钉

不是不能发，而是 Go 进程直连 SMTP 或钉钉 Webhook 在生产环境风险高：

• SMTP 超时阻塞主线程：一次发信卡住 30 秒，整个采集循环就停摆
• 钉钉限频难控制：高频报警可能触发接口限流，返回 errcode: 101001，但 Go 默认不重试带退避的 HTTP 请求
• 职责混杂：监控程序该专注“发现异常”，不该承担“通知渠道调度”。统一走 Alertmanager 或企业内部 webhook 网关，才能做去重、静默、分级路由

最简健壮做法：把告警事件序列化为 JSON，POST 到本地 http://localhost:9093/api/v1/alerts（Alertmanager 默认地址），由它负责后续分发。这样你的 Go 程序只需处理 HTTP 200/503，无需理解钉钉签名或邮件 MIME 格式。