vm0监控指南用Axiom日志自定义脚本搭建Runner监控体系【免费下载链接】vm0Zero, your trustworthy AI teammate for real work.项目地址: https://gitcode.com/GitHub_Trending/vm/vm0vm0产品名 Zero是一个开源 AI 队友平台你在 Slack 或网页里 它它就会在隔离的 Firecracker 微虚拟机里替你完成报告、分诊、调研等真实工作。每台承载这些沙箱的宿主机称为Runner如何对它们做 vm0 监控正是本指南的主题。本文将带你用Axiom 日志 两个自定义采集脚本 Grafana Alloy快速搭建一套完整的 Runner 监控体系指标远程写入 Grafana Cloud告警日志汇聚到 Axiom新手也能照着跑通。为什么 vm0 需要一套专门的监控一台 Runner 宿主机上可能同时运行多个沙箱涉及 CPU、内存、磁盘、网络等大量动态资源工作区镜像还会在宿主机上缓存成 ext4 镜像文件磁盘占用会随使用量悄悄增长。vm0 的监控方案把数据分成两条互补的链路链路数据去向指标链路系统资源 沙箱生命周期 磁盘缓存Alloy 抓取 → 远程写入 Grafana Cloud日志链路Runner 的 WARN/ERROR 事件、环境别名状态事件直接批量上报 Axiom官方用一份 Ansible Playbook 就能把整套体系部署到多台裸机核心文件是 ansible/playbooks/provision-monitoring.yml。一键部署用 Ansible 完成监控配置只需在 Runner 宿主机上执行一条 playbook参数来自 playbook 头部注释ansible-playbook -i host1,host2, playbooks/provision-monitoring.yml \ -e ansible_userubuntu \ -e grafana_cloud_prometheus_urlhttps://... \ -e grafana_cloud_prometheus_user123456 \ -e grafana_cloud_api_keyglc_... \ -e env_labelprod执行后Ansible 会自动完成以下工作安装 Grafana Alloy1.13.2并写入 ansible/playbooks/provision-monitoring.yml 中内嵌的采集配置安装两个自定义采集脚本并注册为 systemd 服务 定时器创建指标文本目录/var/lib/vm0-monitoring/textfile-collector启动 Alloy 并按 15 秒间隔抓取、远程写入 Grafana Cloud。Alloy 侧内置了三路数据源prometheus.exporter.unixCPU、磁盘、内存、网络等系统指标 textfile 收集器、prometheus.exporter.process专门统计runner、mitmdump、firecracker三类进程数以及远程写入端点附带env环境标签方便区分 prod/staging。自定义脚本一采集工作区镜像缓存指标脚本 ansible/files/vm0-monitoring-workspace-image-cache-collect.sh 是一个 Bash 脚本由 systemd 定时器每 1 分钟触发一次扫描缓存目录默认/var/lib/vm0-runner/workspace-image-cache可用环境变量OKOU_WORKSPACE_IMAGE_CACHE_DIR覆盖统计每个current.ext4镜像的实际分配块而非文件大小并按 7 个容量桶lt_16MiB到gte_16GiB归类原子写出 Prometheus 文本文件workspace-image-cache.prom。产出的核心指标指标名含义vm0_workspace_image_cache_entries缓存中的镜像数量vm0_workspace_image_cache_allocated_bytes缓存占用的磁盘总字节数vm0_workspace_image_cache_bucket_entries{bucket}各容量桶的条目数vm0_workspace_image_cache_bucket_allocated_bytes{bucket}各容量桶的分配字节数用这几条曲线你可以直观回答哪台 Runner 的磁盘快被镜像缓存吃掉了。自定义脚本二采集 Runner 生命周期指标脚本 ansible/files/vm0-monitoring-runner-status-collect.py 是一个 Python 脚本由定时器每 15 秒触发一次粒度比缓存指标更高遍历 Runners 目录默认/var/lib/vm0-runner/runners可用OKOU_RUNNERS_DIR覆盖下每个 Runner 的status.json严格校验沙箱 ID 必须是 UUID非法文件、符号链接都会被标记为invalid并告警汇总沙箱状态与 Runner 模式原子写出runner-status.prom。产出的核心指标指标名含义vm0_runner_sandboxes{state}各状态沙箱数active/idle/preparing/unknownvm0_runner_instances{mode}各模式 Runner 数starting/running/draining/stopping/unknownvm0_runner_status_files{result}状态文件采集结果included/stopped/invalidvm0_runner_status_collection_success本次采集是否全部成功1/0配合 Alloy 统计的firecracker进程数你就有了宿主机上到底有多少活着的沙箱的完整视角。⏱️用 Axiom 接收 Runner 告警日志指标看面日志看点。Runner 内置的 Axiom 上报层源码在 crates/runner/src/axiom_layer.rs设计上有几个值得新手了解的细节默认关闭、显式开启只有同时设置AXIOM_TOKEN_TELEMETRY和AXIOM_DATASET_SUFFIX两个环境变量才会启用避免误上报只发关键事件仅上报 WARN 及以上级别日志外加一个专用的操作员环境别名状态事件噪声很小批量 有界50 条事件一批、每 5 秒强制刷新内部通道容量 1024单字段超 4KB 自动截断绝不阻塞业务热路径双写兜底本地 stderr 日志文件照常写入Axiom 只是额外的汇聚点自动带上身份标签每条事件自动附带runner_hostname与runner_version。在 Axiom 中查询和告警时建议直接用这两个维度过滤例如某台主机某版本突然涌现 ERROR。关于hostname的写入规范与查询约定可参考官方文档 docs/runner-host-configuration.mdSSH 连接复用等运维细节见 ansible/ansible.cfg。验证清单如何确认监控已生效部署完成后建议按下面顺序自查 ✅文本文件已生成检查/var/lib/vm0-monitoring/textfile-collector/下是否存在workspace-image-cache.prom与runner-status.prom且内容包含vm0_前缀指标定时器在跑用systemctl list-timers确认两个vm0-monitoring-*定时器处于activeAlloy 正常systemctl status alloy无报错且 Grafana Cloud 中能看到带env标签的新序列Axiom 有数据若配置了两个AXIOM_*环境变量制造一条 WARN或重启 Runner 观察启动事件后在 Axiom 数据集中检索runner_hostname缓存曲线合理vm0_workspace_image_cache_allocated_bytes应随任务运行缓慢增长配合容量桶分布判断磁盘压力。小结vm0 的 Runner 监控体系并不神秘Ansible 一键部署 Grafana Alloy 负责系统指标与远程写入两个轻量自定义脚本Bash Python负责沙箱生命周期与磁盘缓存这类业务级指标Axiom 层负责把关键错误日志按主机和版本维度聚合。三条链路互相补位让你既能在 Grafana 上看趋势也能在 Axiom 里定位根因——这正是开源项目 vm0 给自托管用户的一份完整监控答卷。【免费下载链接】vm0Zero, your trustworthy AI teammate for real work.项目地址: https://gitcode.com/GitHub_Trending/vm/vm0创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考