基于openrig构建多节点GPU服务器监控与告警平台实践

上个月把实验室的机器重新梳理了一遍，发现一个挺尴尬的事实：七台高负载计算设备，分别跑着不同的任务，白天黑夜都有人在上面跑训练、跑渲染。结果监控手段还是老一套——谁想起来谁 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 还要在本地存历史数据、跑复杂的聚合计算，那对业务机器的影响就太大了。

具体采集哪些指标？我这边主要关注这几类：

这些数据采集频率默认是 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.yml：

version: "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: - TZ=Asia/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 温度瞬间飙到 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 当成一个"装完就完事"的工具，真正值得花心思的地方是告警规则的梳理和节点标签的规划。监控系统的价值不在你装了几个探针，而在你如何定义"什么算问题、该让谁知道"。把这层想清楚了，这个开源项目才能从"能用"变成"好用"。