CubeSandbox资源监控与指标采集：节点与沙箱资源用量全览（完全指南）
【免费下载链接】CubeSandboxInstant, Concurrent, Secure & Lightweight Sandbox for AI Agents.项目地址: https://gitcode.com/GitHub_Trending/cu/CubeSandbox
CubeSandbox 是面向 AI Agent 的即时、并发、安全、轻量沙箱平台，其资源监控与指标采集能力覆盖从 guest 内部到宿主机节点、再到控制平面的三层体系，帮助新手快速看懂每个沙箱与每台节点用了多少 CPU、内存和磁盘。本文将带你完整梳理 CubeSandbox 的指标采集链路，做到节点与沙箱资源用量全览。
一、为什么需要三层资源监控？
🔍 对沙箱平台来说，"资源用在哪"是运维的第一问题。CubeSandbox 把监控拆成三个层次，各司其职：
| 层级 | 组件 | 看什么 |
|---|---|---|
| 沙箱内部 | Agent（guest 内进程） | guest OS 的负载、CPU、内存、磁盘、网络明细 |
| 宿主机节点 | Cubelet | 节点上沙箱占用的 CPU 配额、内存、微虚机数量 |
| 控制平面 | CubeOps + Redis | 全集群节点的容量、已分配资源、磁盘水位 |
这种设计让调度器（CubeMaster）能拿到新鲜、低成本的资源视图，而运维人员可以在控制平面看到每台节点的完整快照。
二、第一层：沙箱内部 Agent 指标采集
每个沙箱 guest 内部都运行着一个 agent 进程，它是资源用量的"第一现场"。核心实现在 agent/src/metrics.rs，对外提供get_metrics接口，输出标准 Prometheus 文本格式，外部系统可以直接抓取。
Agent 采集两大类指标：
- agent 进程自身（命名空间
kata_agent）：线程数、进程总耗时、虚拟内存与 RSS 常驻内存、IO 统计、上下文切换次数等，用于观察 agent 自身健康度； - guest 系统整体（命名空间
kata_guest）：- 系统负载（1/5/15 分钟）与任务数
- 每颗 CPU 的 user / system / idle / iowait / irq 时间
/proc/meminfo全量内存信息（总量、可用、swap、slab、hugepages 等）- 网卡收发包、丢包、错误计数
- 磁盘读写次数、扇区数、IO 等待时间
💡 新手提示：这些指标几乎全部直接读取/proc虚拟文件系统（通过procfs库实现），零侵入、无性能开销，非常适合轻量沙箱场景。
三、第二层：宿主机节点上的 Cubelet 指标
Cubelet 部署在每台计算节点上，负责本节点沙箱的生命周期管理，同时是资源用量的"本地账房"。其调度器指标采集器位于 Cubelet/plugins/cube/internals/metric/collector.go，以 Prometheus 格式暴露一组cube_cubebox_scheduler_前缀的指标：
quota_cpu_usage_milli：节点 CPU 配额用量（毫核）quota_mem_mb_usage：节点内存配额用量（MB）mvm_num/mvm_running_num：微虚机总数 / 运行中数量nic_queues：已分配网卡队列数realtime_create_num/realtime_destroy_num：进行中的创建 / 销毁请求数
除调度器指标外，Cubelet 还通过 cgroup 读取每个沙箱的实际资源消耗（见 Cubelet/plugins/cube/internals/cgroup/local.go），并在 Cubelet/services/cubebox/metric.go 中提供沙箱级（cubebox）的指标查询接口，实现"单沙箱资源用量"级别的观测。
四、第三层：CubeOps 控制平面的节点指标汇聚
控制平面由 CubeOps 负责。每台节点上的 Cubelet 定期向 CubeOps 发送心跳，心跳报文（见 CubeOps/internal/nodemanagement/model/node.go）携带：
- 已分配资源
AllocatedResources：CPU 毫核、内存 MB、微虚机数量、网卡队列、数据盘 / 存储盘占用 MB - 磁盘水位
DiskUsage：数据盘、存储盘、系统盘使用率（0~100%） - 节点条件（conditions）、镜像与模板清单、组件版本
CubeOps 将指标写入 Redis，键为cube:v1:master:node:metric:<节点ID>，TTL 600 秒，实现逻辑在 CubeOps/internal/nodemanagement/nodemetric/redis_metric.go。Redis 过期机制保证"心跳停止 = 指标自动消失"，避免调度器看到僵尸节点。
最终，CubeOps 维护每台节点的权威视图NodeSnapshot（model/node.go），字段覆盖：
- 容量 / 可分配量：
capacity、allocatable（毫核 + MB） - 配额与用量：
quota_cpu、quota_cpu_usage、quota_mem_mb、quota_mem_mb_usage - 运行规模：
mvm_num、max_mvm_num、create_concurrent_num - 磁盘水位：
data_disk_usage_per、storage_disk_usage_per、sys_disk_usage_per - 健康度：
healthy、unhealthy_reason、心跳时间
这些节点快照再供 CubeMaster 调度器使用（本地缓存见 CubeMaster/pkg/localcache/），决定新沙箱落在哪台节点。
五、节点与沙箱资源用量全览：关键指标清单 📊
把三层指标串起来，一张表看清"节点与沙箱资源用量全览"：
| 观测对象 | 关键指标 | 来源 |
|---|---|---|
| 节点 CPU | 配额用量（毫核）、容量、可分配 | CubeOps NodeSnapshot |
| 节点内存 | 配额用量（MB）、容量 | CubeOps NodeSnapshot |
| 节点磁盘 | 数据 / 存储 / 系统盘使用率 | 心跳 DiskUsage |
| 沙箱规模 | mvm_num、运行数、网卡队列 | Cubelet 调度器指标 |
| 单沙箱 | cgroup 实际 CPU/内存消耗 | Cubelet cgroup 采集 |
| guest 内部 | 负载、每核 CPU、meminfo、网卡、磁盘 IO | Agent Prometheus 指标 |
六、资源监控的典型使用场景
- 容量规划：通过
allocatable - quota_usage判断节点还能放多少沙箱； - 热点发现：某节点
mvm_running_num或磁盘水位持续偏高时，可临时关闭调度（scheduling_disabled）； - 沙箱成本分析：结合单沙箱 cgroup 用量与配额，评估 AI Agent 任务的真实资源成本；
- 故障定位：guest 内
iowait、网卡丢包、mem_available突降等指标可快速定位资源瓶颈。
七、资源相关模块速查
- Agent guest 指标：agent/src/metrics.rs
- Cubelet 调度器指标采集：Cubelet/plugins/cube/internals/metric/collector.go
- Cubelet 沙箱级指标：Cubelet/services/cubebox/metric.go
- CubeOps 节点模型：CubeOps/internal/nodemanagement/model/node.go
- CubeOps Redis 指标读写：CubeOps/internal/nodemanagement/nodemetric/redis_metric.go
- CubeMaster 节点指标缓存：CubeMaster/pkg/localcache/
总结
CubeSandbox 的资源监控以"三层采集 + Redis 汇聚"为核心：agent 在 guest 内提供细粒度的系统指标，Cubelet 在节点上记账并暴露 Prometheus 指标，CubeOps 通过心跳汇聚成全集群的节点资源快照，最终让"节点与沙箱资源用量全览"触手可及。对新手而言，掌握上述三层指标的来源与含义，就具备了运维 CubeSandbox 集群的基本功。
【免费下载链接】CubeSandboxInstant, Concurrent, Secure & Lightweight Sandbox for AI Agents.项目地址: https://gitcode.com/GitHub_Trending/cu/CubeSandbox
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
