容器运行时监控需分层采集cpu节流、内存活跃集、运行态状态三类关键指标，结合运行时差异定制采集路径，并通过双条件告警与明确owner标签实现可解释、可响应的轻量落地。
容器运行时性能监控不是堆砌工具，而是围绕真实运行状态建立可解释、可响应的指标逻辑。核心在于分层采集、关联分析、阈值合理——不追求指标数量，而要每个指标都能回答一个具体问题：比如“这个容器是否快被杀掉？”“这次请求延迟是网络还是应用导致？”
运行时三层关键指标选型
指标必须对应容器生命周期中的实际瓶颈点，避免采集无业务意义的冗余数据：
- CPU类：优先看cgroup CPU throttling time（节流时间），比单纯CPU%更有价值——它直接反映容器是否因超限被内核限制执行；配合cpuacct.usage_percpu定位单核热点
- 内存类：必须同时采集container_memory_usage_bytes（已用）和container_memory_working_set_bytes（活跃集），OOM前兆常表现为working set逼近limit但usage波动大
- 运行态类：关注container_last_seen（确认存活）、container_restarts_total（隐含健康度）、container_status_phase（Pending/Running/Succeeded/Failed）——这些来自kube-state-metrics或cAdvisor，是判断容器是否“活着”的第一信号
RuntimeClass与底层运行时的差异化采集
不同运行时（containerd、CRI-O、gVisor）暴露的指标路径和语义存在差异，不能统一套用一套Prometheus配置：
- 使用containerd时，通过
/metrics端口获取containerd_task_start_seconds_count和containerd_shim_start_seconds_count，可分析容器启动慢是否卡在shim初始化 - 使用CRI-O时，启用
--enable-metrics后，重点看crio_runtime_operations_duration_seconds直方图，P99超过2s需排查镜像拉取或rootfs解压 - 对gVisor等沙箱运行时，额外采集runsc_sandbox_uptime_seconds和runsc_syscall_count_total，syscall频次突增往往预示应用频繁陷入内核态
从指标到告警的实用配置原则
告警不是指标的简单翻版，而是带上下文的动作触发器：
- 内存告警不只设“>80%”，而是：
(container_memory_usage_bytes / container_spec_memory_limit_bytes) > 0.85 and on(pod, namespace) (container_memory_working_set_bytes / container_spec_memory_limit_bytes) > 0.75——双条件过滤掉缓存抖动误报 - CPU节流告警用：
rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0.1，即每分钟有6秒以上被节流，说明持续超配，不是瞬时毛刺 - 容器异常退出告警结合事件：
count by (pod, namespace)(kube_pod_container_status_restarts_total > 0) > 0 and on(pod, namespace) kube_pod_status_phase{phase="Failed"} == 1，精准捕获刚失败的Pod
轻量级落地建议：先跑通再扩展
不必一上来就部署全套Prometheus+Grafana+Alertmanager。可按节奏推进：
- 第一步：用
docker stats --format json或crictl stats -o json脚本化采集，写入本地SQLite或InfluxDB，验证指标真实性 - 第二步：部署cAdvisor + Prometheus单节点实例，聚焦采集
container_.*系列指标，用Grafana画出CPU/MEM/RESTARTS趋势图 - 第三步：引入ServiceMonitor或PodMonitor，按Namespace和服务标签自动发现目标，再逐步接入OpenTelemetry做应用层打点
不复杂但容易忽略：所有指标采集必须绑定明确的owner label（如team、service、env），否则在100+服务的集群里，你永远不知道哪个告警该找谁。
