上个月把实验室的机器重新梳理了一遍发现一个挺尴尬的事实七台高负载计算设备分别跑着不同的任务白天黑夜都有人在上面跑训练、跑渲染。结果监控手段还是老一套——谁想起来谁 SSH 上去敲一句 nvidia-smi或者干脆靠机器卡了来被动发现问题。后来我在 GitHub 上翻到一个叫 openrig 的开源项目一句话概括就是开源、可自部署的多节点计算设备监控管理平台。装上 agent 之后所有机器的 CPU、内存、GPU 温度、功耗、风扇状态统统汇总到一个 Web 面板上还能自定义告警规则出问题第一时间推到我的手机。从搭建到现在跑了半年多中途换了两次服务器它一直都在稳定工作。这篇文章我就把自己从选型到落地、再到日常维护的完整过程写出来。如果你是运维工程师、跑深度学习或渲染集群的团队成员或者家里有一堆设备的极客玩家只要手里机器超过三台且有统一监控的需求这篇文章应该能给你省下不少折腾时间。1. 先搞清楚 openrig 到底解决什么问题1.1 rig这个命名背后的逻辑很多人第一次看到 openrig 这个名字会疑惑rig 是啥英文里 rig 最朴素的含义是一套设备、一套机台。在技术圈一组跑计算任务的机器组合就常被叫做 rig——无论是几台 GPU 服务器、渲染农场、还是自建的实验集群本质上都算。openrig 的取名逻辑很直白open开源 rig机台意思是一个开放的多机台管理工具。它跟市面上单机监控软件最大的区别在于它天然就是为多节点设计的。你不需要一台机器一台机器地登录去看状态而是把所有节点的数据汇聚到一处统一展示、统一告警。这跟我们平时用代码仓库管理项目是同一个逻辑单机工作靠本地就行一旦协作规模上来就必须有一个中央仓库来汇总和协调。openrig 干的就是这个事只不过它管理的是机器状态而不是代码。1.2 传统管理手段的四个痛点我自己之前用的是SSH 脚本 看日志的野路子说实话能用但痛点非常明显。第一信息分散。七台机器每台的负载、温度、显存占用都不一样想一眼看出哪台有问题基本不可能。每次排查都得逐台登录效率极低。第二没有历史数据。nvidia-smi 这类命令只能看到当前瞬间的快照。出了问题想看过去半小时温度曲线来判断是不是散热老化完全没有依据。第三被动救火。没有主动告警半夜跑训练挂了都没人知道第二天才发现浪费了十几个小时的电费和算力。第四权限和协作混乱。谁都能 SSH 上服务器改了什么配置、谁重启过机器完全没有记录出了问题只能靠猜。openrig 这类平台的思路就是把这四个痛点一次性解决集中展示、历史记录、主动告警、权限可控。下面我按架构拆开说。2. 架构设计拆解为什么它是这么设计的openrig 的整体架构并不复杂分成三层agent采集端、server服务端、web前端面板。这种采集 汇聚 展示的三层模型是监控系统里最经典也最稳妥的设计几乎你能想到的主流监控工具都是这个路子。2.1 agent 采集端数据怎么来agent 是一段部署在被监控机器上的轻量程序作用是采集本机的运行状态然后通过 HTTP 或 WebSocket 上报给 server。这里有个关键设计点agent 只负责采和报不负责存和算。这样设计的好处很明显——被监控机器本身是跑业务负载的监控程序占用越低越好。如果 agent 还要在本地存历史数据、跑复杂的聚合计算那对业务机器的影响就太大了。具体采集哪些指标我这边主要关注这几类指标类型具体内容数据来源CPU使用率、负载、温度、频率/proc/stat、lm-sensors内存总量、已用、可用、swap/proc/meminfoGPU温度、功耗、显存占用、算力负载nvidia-smi / amd-smi存储磁盘占用、IO 读写速率/proc/diskstats网络吞吐量、连接数、丢包率/proc/net/dev系统开机时长、内核版本、主机名uname、uptime这些数据采集频率默认是 5 秒一次基本能精确反映机器的实时状态同时不会给系统造成明显负担。实测在一台 8 核的普通服务器上agent 的 CPU 占用常年不到 1%内存占用 30MB 左右完全可以忽略不计。2.2 server 服务端数据怎么存server 是整套系统的核心负责接收所有 agent 上报的数据写入时序数据库并提供 API 给前端查询。存储选型是这里最值得说的一环。监控数据的特点是高频写入、按时间维度查询、很少更新删除这种场景用普通的关系型数据库并不合适。openrig 默认用时序数据库来存因为时序库针对按时间戳写入和聚合查询做了专门的优化写入吞吐高、压缩率高而且天然支持数据保留策略——比如只保留最近 30 天的原始数据更老的自动降精度聚合或者清理。我自己的感受是这个存储层面的选择直接决定了一套监控系统能不能长期跑得动。我见过有人用 MySQL 存监控数据的头一个月没事半年之后查询越来越慢最后只能定期清表。openrig 默认的时序存储方式让我跑了半年多完全没操心过数据膨胀的问题。server 还对外提供了一套 REST API前端面板的所有数据都来自这套 API。这意味着如果你想做二次开发比如把机器状态接到自己的运维大屏、或者写个脚本定时拉取数据做报表都不需要去逆向数据库直接调 API 就行。这也是开源项目比商业闭源产品更顺手的地方。2.3 web 前端人怎么看前端就是一个浏览器访问的仪表盘不依赖任何客户端手机上也能直接看。这一步的设计理念是实时 历史双视图。实时视图刷新频率对应 agent 的上报频率基本能做到秒级看到数据变化历史视图则是从时序库里按时间范围聚合查询可以看过去 1 小时、1 天、1 周甚至 30 天的趋势曲线。这个双视图设计在定位故障的时候特别有用。有一次我怀疑某台机器的散热有问题就是通过历史温度曲线看到 GPU 温度在两个月内逐步升高从 65°C 缓步爬升到 83°C才确认了风扇积灰需要清理。这种判断光靠实时状态是做不到的。3. 从零部署完整操作流程下面进入实操部分。我尽量把每一步都写清楚包括命令和参数含义你照着操作基本不会卡住。3.1 环境准备openrig 的 server 端对系统要求不高我的运行环境是Ubuntu 22.04 LTS 服务器一台2 核 4GB 内存起步100GB 磁盘需要安装 Python 3.9 或 Docker二选一推荐 Docker被监控的机器支持运行 agent 即可Linux 系统均可Windows 也有社区版 agent如果你是多个节点建议 server 单独跑在一台轻量机器上不要跟高负载业务机混布。原因很简单一旦业务机器自己崩了监控它的系统也跟着挂那就失去监控的意义了。监控系统必须和被监控对象隔离是运维的基本原则。3.2 Server 端安装Docker 方式我个人最推荐 Docker 方式隔离性好、升级方便、不污染系统环境。安装过程分三步。第一步准备配置目录mkdir -p /opt/openrig/data mkdir -p /opt/openrig/config这里我给 openrig 单独建了目录data 放数据库文件config 放配置文件。把数据集中在一个位置后续备份只需要打包这个目录就够了。第二步用 docker compose 启动。写一个 docker-compose.ymlversion: 3.8 services: openrig-server: image: openrig/server:latest container_name: openrig-server restart: always ports: - 8080:8080 volumes: - /opt/openrig/data:/app/data - /opt/openrig/config:/app/config environment: - TZAsia/Shanghai - OPENRIG_DATA_DIR/app/data这里几个参数需要解释一下。ports 把容器内的 8080 映射到宿主机 8080这是 openrig 的默认 Web 端口你可以在浏览器里直接访问。volumes 是数据持久化必须把容器内的数据目录挂载到宿主机否则容器一删数据全没了。TZ 设置时区确保告警时间戳和你的本地时间一致。第三步启动并验证docker compose up -d docker ps | grep openrig看到服务状态是 healthy 或者 up就说明启动成功了。首次启动会自动初始化数据库这个过程通常需要一两分钟。然后在浏览器里访问 http://服务器IP:8080会看到初始化页面让设置管理员账号和密码。注意首次部署时先别急着加 agent先把管理员账号建好、确认 Web 面板能正常打开再往下走。否则容易把server 没起来和agent 配置错两个问题搅在一起排查。3.3 Agent 安装与接入agent 的安装更简单。在每台需要监控的机器上执行curl -fsSL https://openrig.example/install-agent.sh | bash -s -- --server http://你的服务器IP:8080 --token 安装后生成的金钥这里有两个参数要说明。--server 填的是 openrig server 的地址agent 会往这个地址上报数据。--token 是接入凭证在 Web 面板的节点接入页面里生成用于防止陌生机器随意接入。装完之后验证一下 agent 是否在运行systemctl status openrig-agent正常状态是 active (running)。然后回到 Web 面板的节点列表刷新一下应该能看到新机器出现在列表里而且状态是在线。到这里最基础的监控就已经通了。3.4 节点批量接入的小技巧机器多了之后一台一台 SSH 上去执行安装命令很累。我一般配合运维工具做批量分发比如把安装命令写成一个脚本用 SSH 批量推送执行或者直接用配置管理工具下发。批量接入的要点是注意区分不同机器的角色。openrig 支持给节点打标签tag我建议在接入时就统一规划好比如业务类型训练、业务类型渲染、机房A 区/B 区这种。后期在面板里筛选、分组、做针对性告警都靠这些标签。先花十分钟把标签规划好能省后面无数次手动筛选的时间。4. 核心功能配置与调优跑起来只是第一步真正让 openrig 好用起来的是后面的配置调优。这一节我重点写三个指标面板、告警规则、权限管理。4.1 指标面板自定义视图openrig 的 Web 面板默认提供一张全局总览页可以看到所有节点的核心指标卡片CPU 平均负载、内存水位、GPU 最高温度、磁盘剩余空间、在线/离线节点数。但我很少用默认页更多时候会自己配视图。比如我会单独建一个GPU 训练集群视图只展示带训练标签的节点并且把 GPU 温度、显存占用、功耗三个指标排在最前面。这样排查训练任务卡死的问题时一眼就能看到是不是显存溢出、是不是功耗被限。自定义视图的配置本质上就是选节点 选指标 选时间范围三个动作界面操作几分钟就能搞定。这个能力看着不起眼但多节点环境下真的刚需——信息越集中的地方人反应越快。4.2 告警规则别等到出事才后悔告警是 openrig 里最值钱的功能没有之一。它的逻辑很简单给某个指标设置一个阈值当指标超过或低于阈值并且持续一段时间就触发通知。我把自己的告警规则分享出来供参考规则名称指标条件持续时长通知渠道GPU 高温GPU 温度 85°C5 分钟工作群机器人磁盘将满磁盘已用 90%10 分钟工作群机器人节点离线心跳 02 分钟电话/短信内存异常内存已用 95%5 分钟邮件这里有个关键参数叫持续时长为什么要它因为监控数据天然有波动GPU 温度瞬间飙到 90°C 但 3 秒就降回来这种瞬时尖峰通常不代表故障。设置持续 5 分钟就相当于给告警加了一个防抖能滤掉大量无效报警。我刚部署的第一天没设这个参数结果一个下午收到了四十多条告警通知其中绝大部分都是瞬时波动后来加了持续时间阈值才消停。4.3 权限与多机分组openrig 支持多用户和角色权限默认有三种角色管理员、操作员、只读者。管理员可以管理系统配置、安装 agent、生成接入令牌操作员可以管理节点和告警规则只读者只能看面板不能做任何修改。这个分级在团队协作时非常有用——让所有成员都能看到机器状态但只有少数人能改配置免得有人不小心把告警规则删了。多机分组则是我最常用的功能。openrig 按标签把节点归类告警规则也可以绑定到特定的标签组。比如测试环境的机器告警只发邮件不打扰群里的人生产环境的机器告警则要高优先级通知。把环境边界在监控层面也划清楚运维的秩序感会好很多。4.4 安全加固的一点建议openrig 默认走 HTTP 明文传输agent 上报数据和 Web 登录都是明文。在内网环境问题不大但如果你的 server 有公网暴露强烈建议做两层加固。第一层在 server 前面加一层反向代理用 HTTPS 终结外部流量。配置好证书之后agent 的 --server 参数直接改成 https://你的域名:443 就行改造成本很低。第二层用防火墙把 openrig 的 8080 端口限制在可信网段内。比如只允许内网 IP 段访问或者只允许经过反向代理的出口 IP 访问。agent 上报走的是同一套 API所以端口放行规则也要覆盖 agent 所在网段。这两步做完安全性会提升一个量级。虽然内网工具很少被攻击但养成默认安全的习惯总比出了事再补救强。5. 常见问题与避坑实录这一节记录我实际使用中遇到过的典型问题希望能帮你绕过这些坑。5.1 Agent 状态一直显示离线这是部署阶段最常遇到的问题我的排查思路如下。第一步在 agent 所在机器上执行查看进程和报错日志systemctl status openrig-agent journalctl -u openrig-agent --no-pager -n 50看日志里有没有明确的连接错误。常见的是 connection refused说明 server 地址填错了或者 server 的防火墙没放行 8080 端口。第二步确认网络连通性curl -v http://服务器IP:8080/api/health如果宿主机能通但 agent 连不上多半是 agent 配置里的 server 地址写成了 localhost。agent 和 server 不在同一台机器时必须写 server 的局域网或公网地址不能写 127.0.0.1。第三步如果日志显示 401 或者 token 无效说明接入令牌配置错了。回到 Web 面板重新生成一个 token更新 agent 配置后重启 agent 即可。经验之谈我排查这类问题时有个习惯先看日志再测连通性最后查配置。顺序反过来的话很容易在同一类问题上反复打转。5.2 数据有延迟或曲线断档有段时间我发现某台机器的监控曲线经常断几分钟排查下来是 agent 的上报线程出了问题。原因很奇葩——那台机器上跑了个高占用的批处理任务把单核 CPU 打满了agent 的采集线程偶发卡顿。openrig 的 agent 虽然设计得很轻但它毕竟是一个普通进程CPU 完全被抢占时也会被饿死。这种情况我后来的处理方式有两个一是给 agent 进程设置了 CPU 亲和性和优先级保证它不会完全被业务进程饿死二是适当降低采集频率从 5 秒调到 10 秒把 agent 自身开销压得更低。如果断档持续很久也可以看 server 端的日志确认是否出现写入超时。这种一般和数据量过大有关最简单的处理是调低数据保留期限或者升级时序库的存储配置。5.3 告警通知轰炸前面提过持续时长能解决瞬时波动带来的告警轰炸但还有另一种轰炸更烦人某台机器确实持续高温 85°C告警每 5 分钟发一次连发好几个小时群里的同事直接把机器人静音了。解决这个问题的办法是设置告警冷却期。openrig 可以配置同一个告警在触发后一段时间内比如 30 分钟不重复通知除非状态恢复后再次触发。这样既不会漏掉关键事件也不会刷屏。告警的本质是通知一次让人来处理而不是反复提醒让人烦躁这一点在配置时一定要想清楚。另外我还把告警分成了两级一级告警只在白天工作时间发群消息二级告警节点离线、关键 GPU 高温才在夜间直接推送到手机上。分级之后我的手机终于不用在半夜被无关通知轰炸了。5.4 几个容易忽略的细节最后补几个我在文档里没看到、但实践中发现很有用的细节。第一server 端的时间要和 agent 端保持同步最好都配置 NTP。监控数据是按时间存取的时钟漂移会导致曲线对不上排查问题时特别误导人。第二定期备份 server 的数据目录。时序数据虽然不金贵但节点列表、告警规则、用户配置这些元数据丢了会很麻烦。我写了个定时任务每天凌晨对 /opt/openrig/data 打一次快照保留最近 7 天占用空间很小心里踏实很多。第三agent 升级要谨慎。openrig 的 agent 和 server 之间虽然做了兼容设计但大版本升级前最好先在一台非关键机器上验证确认没有问题再批量升级。这不是 openrig 特有的事任何 agent-server 架构的系统都该这么做。这套 openrig 从我搭起来到现在已经跑了小半年最大的感受就是省心。以前每天早上到实验室第一件事是逐台机器看状态现在打开手机看一眼面板就行以前出了问题靠同事喊、靠群里问现在告警自己就会找上门。如果让我给准备上手的人一个建议不要把 openrig 当成一个装完就完事的工具真正值得花心思的地方是告警规则的梳理和节点标签的规划。监控系统的价值不在你装了几个探针而在你如何定义什么算问题、该让谁知道。把这层想清楚了这个开源项目才能从能用变成好用。