企业官网建设流程全解析

vm0监控指南：用Axiom日志+自定义脚本搭建Runner监控体系

【免费下载链接】vm0Zero, your trustworthy AI teammate for real work.项目地址: https://gitcode.com/GitHub_Trending/vm/vm0

vm0（产品名 Zero）是一个开源 AI 队友平台：你在 Slack 或网页里 @它，它就会在隔离的 Firecracker 微虚拟机里替你完成报告、分诊、调研等真实工作。每台承载这些沙箱的宿主机称为Runner，如何对它们做 vm0 监控，正是本指南的主题。本文将带你用Axiom 日志 + 两个自定义采集脚本 + Grafana Alloy，快速搭建一套完整的 Runner 监控体系：指标远程写入 Grafana Cloud，告警日志汇聚到 Axiom，新手也能照着跑通。

为什么 vm0 需要一套专门的监控？

一台 Runner 宿主机上可能同时运行多个沙箱，涉及 CPU、内存、磁盘、网络等大量动态资源；工作区镜像还会在宿主机上缓存成 ext4 镜像文件，磁盘占用会随使用量悄悄增长。🔍

vm0 的监控方案把数据分成两条互补的链路：

官方用一份 Ansible Playbook 就能把整套体系部署到多台裸机，核心文件是 ansible/playbooks/provision-monitoring.yml。

一键部署：用 Ansible 完成监控配置

只需在 Runner 宿主机上执行一条 playbook（参数来自 playbook 头部注释）：

ansible-playbook -i "host1,host2," playbooks/provision-monitoring.yml \ -e "ansible_user=ubuntu" \ -e "grafana_cloud_prometheus_url=https://..." \ -e "grafana_cloud_prometheus_user=123456" \ -e "grafana_cloud_api_key=glc_..." \ -e "env_label=prod"

执行后，Ansible 会自动完成以下工作：

1. 安装 Grafana Alloy（1.13.2）并写入 ansible/playbooks/provision-monitoring.yml 中内嵌的采集配置；
2. 安装两个自定义采集脚本，并注册为 systemd 服务 + 定时器；
3. 创建指标文本目录/var/lib/vm0-monitoring/textfile-collector；
4. 启动 Alloy 并按 15 秒间隔抓取、远程写入 Grafana Cloud。

Alloy 侧内置了三路数据源：prometheus.exporter.unix（CPU、磁盘、内存、网络等系统指标 + 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。

产出的核心指标：

用这几条曲线，你可以直观回答"哪台 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。

产出的核心指标：

配合 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.md；SSH 连接复用等运维细节见 ansible/ansible.cfg。

验证清单：如何确认监控已生效

部署完成后，建议按下面顺序自查 ✅

1. 文本文件已生成：检查/var/lib/vm0-monitoring/textfile-collector/下是否存在workspace-image-cache.prom与runner-status.prom，且内容包含vm0_前缀指标；
2. 定时器在跑：用systemctl list-timers确认两个vm0-monitoring-*定时器处于active；
3. Alloy 正常：systemctl status alloy无报错，且 Grafana Cloud 中能看到带env标签的新序列；
4. Axiom 有数据：若配置了两个AXIOM_*环境变量，制造一条 WARN（或重启 Runner 观察启动事件）后在 Axiom 数据集中检索runner_hostname；
5. 缓存曲线合理：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