Debian cpustat在容器化环境中的使用技巧
一 工具选择与版本差异
- 容器里常见的“cpustat”主要有两类，请先确认你安装的是哪一个，命令与参数差异很大：
- sysstat 的 cpustat：Debian 仓库中由sysstat提供，侧重系统级CPU统计，典型用法如“每5秒采样一次，持续60秒”：
cpustat -i 5 -s 60。适合在容器或宿主机上查看整体CPU负载与分布。
- Uber 的 cpustat（Go 版）：第三方高频采样工具，能按进程/线程展示CPU占用，适合定位短时尖峰与“谁在吃CPU”。但该工具依赖NETLINK taskstats接口，通常需要root或显式赋予CAP_NET_ADMIN能力；且项目已标注为deprecated（不再维护）。
二 在容器中运行的正确姿势
- 运行 sysstat 的 cpustat（系统级监控）
- 容器内安装：
apt-get update && apt-get install -y sysstat
- 直接在容器内执行：
cpustat -i 1 -n 20（按你的需求调整间隔与次数）
- 若需观察宿主机全局CPU（而非仅容器视角），可在宿主机上运行，或使用具备宿主机视图的编排/特权方式（见下文“进阶”）。
- 运行 Uber 的 cpustat（进程级高频采样）
- 容器内安装（示例）：
apt-get update && apt-get install -y golang && go install github.com/uber-common/cpustat@latest
- 权限配置（二选一）：
- 以 root 运行：
sudo cpustat ...
- 最小权限：
sudo setcap cap_net_admin+ep /go/bin/cpustat
- 常见用法：
cpustat -i 200ms -n 50（每200ms采样、汇总50次），或加上-r输出相对变化、-x输出额外统计（如平均负载、平均CPU频率）。
- 若启动报“socket: operation not permitted”或“requires root”，优先检查容器是否缺少NET_ADMIN能力或受AppArmor/SELinux限制。
三 高频采样的实践要点
- 采样粒度与开销：Uber 版 cpustat 为降低开销做过优化，典型情况下自身CPU占用约为top 的 ~35%；在容器中应控制采样频率与次数，避免对业务造成干扰。
- 容器视角 vs 宿主机视角：容器默认只看到自身命名空间内的进程。若需排查“宿主机上其他容器/Pod”导致的CPU尖峰，优先在宿主机运行；或使用具备宿主机视图的特权/绑定挂载方式（见下文“进阶”）。
- 输出与回溯：使用
-r输出相对变化、-x输出额外统计、-t添加时间戳；如需离线分析，可重定向输出到文件，便于后续绘图或对比。
四 进阶 宿主机视角与权限最小化
- 在宿主机直接运行：最稳妥的“全局视角”，适合生产排查。
- 在容器中获取宿主机视图（谨慎开启，遵循最小权限原则）：
- 提升能力集合：如
--cap-add=NET_ADMIN（Uber cpustat必需）、必要时再叠加其他必要能力，避免--privileged一把梭。
- 安全策略：放行NETLINK相关系统调用，避免被AppArmor/SELinux拦截。
- 资源与隔离：为采样容器设置CPU/内存限制，避免采样器本身成为瓶颈或干扰业务。
- 绑定挂载与系统路径：仅在确有必要时挂载
/proc、/sys等敏感目录，并只读挂载，减少攻击面。
五 常见问题快速排查
- “requires root / socket: operation not permitted”：Uber 版 cpustat 缺少NET_ADMIN能力或未以 root 运行；解决：加
--cap-add=NET_ADMIN或CAP_NET_ADMIN+ep绑定，或以 root 执行。
- 容器里无输出或立即退出：多因权限不足、安全策略限制或工具版本不匹配；检查能力、策略，并确认安装的是sysstat 的 cpustat还是Uber 的 cpustat，两者命令参数差异较大。
- 采样开销过大：降低采样频率/次数，或改用系统级工具（如 sysstat）做长时段观测，高频尖峰定位再用进程级工具短时采样。