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 做归一化。
立即学习“go语言免费学习笔记（深入）”；
在 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/pods404） - 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 格式。
