答案是：用docker stats快速查看、cadvisor+prometheus获取精确指标、kubectl top查集群视图。docker stats适合本地调试，输出cpu%、mem usage/limit等；cadvisor读取cgroups数据，提供cpu核秒/秒、memory working set等关键指标；kubectl top依赖metrics server，返回pod级平均资源使用，但不反映限流问题。
实时监控容器的 CPU 和内存占用率，核心是选对工具、抓准指标、避开常见误读。不需要堆复杂架构，从开发调试到生产运维，有三类可靠路径可直接落地。
用 docker stats 快速查看运行中容器
这是最轻量、零依赖的方式，适合本地验证或应急排查：
- 执行
docker stats，实时刷新显示所有运行中容器的 CPU%、MEM USAGE / LIMIT、MEM%、NET I/O、BLOCK I/O - 加
--no-stream参数只输出一次快照，方便脚本调用或日志记录 - 加
--format自定义输出字段，例如只看内存使用率：docker stats --no-stream --format "{{.Name}}: {{.MemPerc}}" - 注意：该命令展示的是容器内进程视角的资源使用，不包含被内核回收的缓存（如 page cache），数值通常略低于 cgroups 实际统计
通过 cAdvisor + Prometheus 获取精确指标
cAdvisor 内置于 Kubelet（K8s）或 Docker daemon 中，直接读取 cgroups 数据，是生产环境事实标准：
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- CPU 使用率真实值 =
rate(container_cpu_usage_seconds_total[1m])，单位是“核秒/秒”，即等效 CPU 核数 - 内存使用量用
container_memory_usage_bytes，它等于 RSS + cache + tmpfs，反映实际内存压力 - 更关键的是内存工作集：
container_memory_working_set_bytes—— Kubernetes OOM 判定依据，比 usage 更贴近真实风险 - Prometheus 抓取地址通常是
http://<node-ip>:10250/metrics/cadvisor</node-ip>（需 Kubelet 开启--cadvisor-port=4194或直连 metrics 端点）
在 Kubernetes 中用 kubectl top 查集群级视图
适合快速掌握命名空间或 Pod 层面的整体负载，依赖 Metrics Server：
-
kubectl top pod -n <ns></ns>查看各 Pod 的 CPU 和内存使用（单位：mCPU / MiB） -
kubectl top pod <pod-name> --containers=true</pod-name>拆解到每个容器维度 - 注意：top 命令返回的是采样窗口内的平均值（默认 30 秒），且不体现限流（throttling）——即使 CPU% 显示很低，也可能因 cfs_quota 被严重压制
- 若需发现 CPU 限流问题，必须查
container_cpu_cfs_throttled_periods_total并计算限流比例，而非只看 usage
真正影响服务稳定性的，往往不是“用了多少”，而是“能不能持续用”。CPU 看 throttling ratio，内存看 working set 与 limit 的差值，这两个细节比单纯的百分比更有诊断价值。
