Docker 容器谁在吃 CPU？用 cAdvisor 把资源占用直接看清楚

Docker 容器谁在吃 CPU？用 cAdvisor 把资源占用直接看清楚

前言

Docker 服务刚装两三个时，我基本不会专门想监控这件事，真有问题就先跑 docker stats 看一眼；可容器越来越多以后，这种方式很快就不够用了。主机突然变慢，到底是哪一个容器在吃 CPU？内存为什么一直往上涨？磁盘和网络是不是某个服务在持续读写？这些问题如果只能靠临时命令逐个猜，排障很容易变成“先怀疑一圈再说”。我更希望先有一个简单的资源观察入口，把宿主机和每个容器当前的 CPU、内存、文件系统、网络等数据集中看清楚，再决定下一步查谁。尤其 NAS 上往往同时跑下载、媒体、数据库和各种小服务，只看宿主机总负载，很难直接判断究竟是哪一个容器在拖慢整台机器。

这次我在飞牛 NAS 上通过 Docker 部署 cAdvisor v0.47.0，把容器内部 8080 映射到宿主机 8087，先查看主机资源页，再进入 /docker 和 Subcontainers 逐个看容器状态。确认局域网监控页面能正常使用以后，再安装 cpolar，把 8087 Web 页面提供到公网，先验证随机地址，最后配置固定二级子域名 cadvisor。我不会把一个实时页面直接说成完整监控体系；这次重点就是先把“容器现在用了多少资源、从哪里看”这件事跑通。只有先看得见，后面的日志排查、性能优化和更完整的监控体系才有明确方向。

1.什么是cAdvisor？

cAdvisor（Container Advisor）是一款用于收集、分析和展示容器资源使用情况的工具。

它更适合解决的不是“自动修复故障”，而是先把容器运行状态变得可见。当前页面可以观察的内容包括：

• CPU 使用情况；
• 内存用量；
• 磁盘 I/O；
• 网络 I/O；
• 容器镜像、启动时间、标签等元数据；
• 宿主机整体资源状态。

cAdvisor 自身以容器或进程运行，通过 Linux 的 cgroups、procfs、sysfs 等机制读取资源统计信息，再通过 Web 页面展示。

这次部署并不继续搭 Prometheus、InfluxDB 或 Grafana，所以我先把它当成一个直接观察当前资源状态的入口，不把“高级可视化、长期历史或告警”一起算进已经完成的范围。

2. 先准备 SSH 和 Docker

2.1 在飞牛打开 SSH

进入飞牛设置页面，开启 SSH 服务。

随后通过 Windows PowerShell 或 Mac Terminal 登录飞牛。

2.2 检查 Docker

执行当前命令：

docker -v
systemctl status -v

这里先确认 Docker 环境已经可用。

当前记录里的 systemctl status -v 保持原样，不在这一步额外替换成其他命令。

3. 部署 cAdvisor

3.1 创建目录

先创建并进入目录：

mkdir -p cadvisor
cd cadvisor/

当前目录只是用来整理部署过程，真正运行 cAdvisor 依赖的是后面的 Docker 容器。

3.2 启动 cAdvisor 容器

执行：

docker run -d –name=cadvisor \\
–privileged \\
–volume=/:/rootfs:ro \\
–volume=/var/run:/var/run:ro \\
–volume=/sys:/sys:ro \\
–volume=/var/lib/docker/:/var/lib/docker:ro \\
–publish=8087:8080 \\
gcr.io/cadvisor/cadvisor:v0.47.0

这条命令里的几个关键点需要看清楚：

• 容器名：cadvisor
• 使用 –privileged
• 挂载 /、/var/run、/sys、/var/lib/docker/
• 宿主机端口：8087
• 容器端口：8080
• 镜像：gcr.io/cadvisor/cadvisor:v0.47.0

也就是说，这次浏览器访问使用的是宿主机上的：

8087

端口。

部署完成以后，在浏览器打开：

http://飞牛IP:8087

页面能正常出现以后，cAdvisor 本地 Web 服务就已经跑起来。

4. 先看宿主机整体资源

当前示例访问：

http://192.168.42.147:8087/containers/

首页可以看到主机层面的资源状态。

这里主要用于观察：

• CPU；
• 内存；
• 文件系统；
• 网络。

我比较喜欢先从宿主机整体看一眼，因为如果整台 NAS 的资源都很平稳，就没必要一上来把所有容器都逐个翻一遍。

5. 再进入 Docker 容器列表

继续访问：

http://192.168.42.147:8087/docker

这个页面会显示 Docker 的基础信息以及当前正在运行的容器。

在：

Subcontainers

区域里，可以看到当前主机上的容器列表。

点击某一个容器后，就能继续查看它的详细运行状态。

继续往下，还能看到更细的资源数据。

这一层才是我觉得 cAdvisor 真正方便的地方：

主机整体状态 → Docker 容器列表 → 单个容器资源详情

排查时不用先记一堆命令，先从页面里找出“谁明显不对”，再决定是否继续进容器或查日志。

6. cAdvisor 能看资源，但别把它和完整监控平台混在一起

当前介绍还提到，cAdvisor 可以继续和 Prometheus、InfluxDB 等工具集成，并配合 Grafana 做更进一步的展示。

但这次没有继续部署这些组件。

所以我会把当前这套环境理解成：

cAdvisor 负责采集并展示容器资源状态。

如果后面真的要做更完整的历史趋势、统一仪表盘或告警，再在这个基础上继续扩展会更清楚。

这样也能避免一个常见误区：页面能打开、当前指标能看到，不代表完整的历史监控体系已经自动搭好了。

7. 本地监控能用了，再考虑外网访问

cAdvisor 默认是在 NAS 局域网里访问。

如果人在公司、出差，或者需要从外部网络查看家里的容器状态，就要再增加公网入口。

这里 cpolar 的职责很明确：

只把 cAdvisor 的 8087 Web 页面提供到公网。

CPU、内存、磁盘和网络指标仍然由 cAdvisor 采集，cpolar 不参与容器监控本身。

8. 在飞牛安装 cpolar

执行当前安装命令：

sudo curl https://get.cpolar.sh | sh

安装完成以后检查服务状态：

sudo systemctl status cpolar

服务正常以后，通过主机 IP + 9200 打开 cpolar Web 管理页面。

当前页面同时写到：

http://ip:9200

以及链接目标：

http://localhost:9200/

实际访问时，以当前环境真正能够打开的管理地址为准。

9. 给 cAdvisor 创建随机公网地址

进入【隧道管理 → 创建隧道】。

当前配置为：

• 隧道名称：cadvisor
• 协议：http
• 本地地址：8087
• 域名类型：随机域名
• 地区：China Top

创建成功以后，进入在线隧道列表查看生成的公网地址。

从其他电脑或移动设备访问。

页面能够正常打开。

这一层真正验证的是：

cAdvisor 8087 → cpolar 随机公网地址 → 外部浏览器。

前面的章节表述偏开发场景，但这里实际用途是远程查看容器监控页面，所以整条链按远程监控来理解更准确。

10. 长期查看再配置固定二级子域名

随机地址适合先验证公网链路。

如果后面会经常从外部网络查看 cAdvisor，固定入口会更方便。

进入 cpolar 预留页面：

https://dashboard.cpolar.com/reserved

选择保留二级子域名。

当前记录为：

• 地区：china Top
• 二级子域名：cadvisor

然后回到【隧道管理 → 隧道列表】，找到对应隧道并编辑。

修改为：

• 域名类型：二级子域名
• Sub Domain：填写已经保留的二级子域名
• 地区：China Top

点击更新

更新完成以后，在线隧道列表中的随机地址会切换成固定二级子域名形式。

最后再从任意设备访问。

页面能够正常打开。

总结

cAdvisor 对我来说最实用的地方，不是把 Docker 监控包装成一套很重的运维体系，而是先把最基础的“资源到底被谁用了”这件事看清楚。

这次实际跑通的主线是：

飞牛 SSH → Docker → gcr.io/cadvisor/cadvisor:v0.47.0 → 8087:8080 → 主机资源页 → /docker → Subcontainers → 单容器资源详情 → cpolar → 8087 → 随机公网 → 固定二级子域名 cadvisor。

几个边界也比较明确：

• 当前真正验证的是 cAdvisor 本地 Web 页面、主机资源、Docker 容器列表和单容器详细状态；
• Prometheus、InfluxDB、Grafana 只在功能介绍里提到，这次没有继续部署；
• cpolar 只负责公网 Web 入口，不参与容器资源采集；
• systemctl status -v 按现有技术步骤保留，没有擅自改写；
• 固定二级子域名解决的是长期访问入口问题，不会改变 cAdvisor 本身的监控能力。

如果 NAS 上已经跑了不少 Docker 服务，我更建议先把 cAdvisor 这种基础观察入口跑起来。下一次机器突然变慢时，至少不用先猜，先看哪一个容器的 CPU、内存或 I/O 明显异常，再往下查会更有方向。