如果你管过五台以上的物理机，肯定能理解这种状态：一台台 SSH 上去看负载、看温度、看硬盘读写，偶尔还要手忙脚乱地重启。我以前靠脚本，脚本越写越厚，最后连我自己都不太敢碰。后来我把这套脚本换成了 OpenRig，一个面向小型物理机群的开放式设备管理工具。从部署到接入第一台设备，我只用了一个下午；之后每台工作站的状态都集中在一个 Web 面板里，温度过高会自动告警，也能远程开机、重启。这篇文章把我从选型到踩坑的整个过程完整写出来，给同样要管十几台甚至几十台实体设备的人一个参考。
1. OpenRig 是什么：一台小主机管住整排物理设备
1.1 我为什么放弃"脚本 + SSH"的老路子
一开始只有三台机器的时候，脚本方案是完全成立的。写一个循环，逐个 SSH 上去执行uptime、df -h、sensors，把结果拼在一起发到群里，加上一个简单的关键字判断，够用。但设备一旦超过五台，问题就来了。
首先是脚本本身的维护成本。每台设备的 Linux 发行版不同，sensors的输出格式就不一样；有的机器有 IPMI，有的没有；有的 Windows 机器连 SSH 都懒得开，我只能用 ping 判断死活。于是脚本里开始出现大量if分支，每个分支都对应一种设备型号。今天加一台新工作站，明天换一块网卡，脚本就要改一行，改完还要找台机器验证。
更大的问题是历史数据全丢。脚本能告诉我"现在这台机器 CPU 90%"，但如果我想知道"过去一周它每天什么时段CPU高"，脚本方案就完全无能为力。监控的意义本来就在于趋势，没有历史曲线的"监控"其实只算半个告警器。
还有一个最伤人的场景：某天深夜，一台机器的 CPU 风扇卡住，温度一路飙升。脚本每五分钟跑一次，但那次刚好因为磁盘写满卡住了，没发出任何告警。直到第二天早上有人去机房闻到焦味才发现。那一刻我就知道，靠脚本打补丁这条路到终点站了。
这时候我想过要不要上 Zabbix 或者 Nagios，但这些重量级平台是为几百上千个节点设计的，装起来一堆组件，学习成本不低。对我这种就管十几台机器的小团队来说，像是开着一辆牵引车去送快递。OpenRig 刚好卡在中间：保留轻量部署的特点，又能把设备发现、指标采集、告警、远程电源管理做进一套系统里。
1.2 设备管理的边界：OpenRig 管什么、不管什么
OpenRig 这个名字里的 rig，在英文里本来就有一整套装备、一台架起来跑任务的机器的意思。它瞄准的设备是机房和实验室里那些看得见摸得着的物理机，而不是云上的临时容器。
我实际用下来，它的管理边界大致可以分为四块：
- 资产盘点：自动发现网段内的设备，识别操作系统、厂商型号、IP 和 MAC 地址，形成一份可以搜索的资产清单。
- 状态监控：采集 CPU、内存、磁盘、网络流量、温度、风扇转速这些硬件级指标，而不是应用内部的数据。
- 远程电源控制：通过 Wake-on-LAN、IPMI 或者智能 PDU 执行开机、关机、重启。
- 告警通知：针对指标设置阈值，触发后通过 Webhook、邮件等渠道发出通知。
至于更上层的容器编排、Kubernetes 调度、应用性能追踪、日志收集，OpenRig 明确不做，也没打算做。它不是 Prometheus 的替代品，也不应该拿来当 APM 用。理解了这条边界，后面配置的时候就不会老想着让它干不属于它的活儿。
1.3 和大而全的监控平台相比，它的取舍在哪
我给自己列过一张对比表，这里也分享出来：
| 方案 | 部署复杂度 | 数据粒度 | 远程控制能力 | 适合规模 |
|---|---|---|---|---|
| Zabbix | 较复杂 | 强 | 基本没有 | 200+ 节点 |
| Nagios | 配置繁琐 | 强 | 基本没有 | 100+ 节点 |
| Prometheus + Exporter | 中等 | 强 | 没有 | 云原生场景 |
| 自写脚本 | 初期快 | 差 | 自己造轮子 | 少于 5 台 |
| OpenRig | 低 | 中等 | 内建 | 5–100 台物理设备 |
这张表不是说 OpenRig 比 Zabbix 强，而是两者解决的问题不一样。Zabbix 适合那种需要审批、分权、多人协作、几百台设备统一纳管的团队；OpenRig 更像个独立的工具箱，适合一个管理员直接面对所有机器。它把"操作系统监控""网络设备监控""电源控制"这些原本得用好几个工具拼起来的活儿，合并到了一个界面里。
如果你手里刚好有几十台工作站、几台内部服务器、一堆网络设备，又不想为监控单独养一个运维团队，OpenRig 这个定位就非常合适。
2. 拆开 OpenRig：它靠哪几个技术点实现对整机群的控制
2.1 设备自动发现：不装 Agent，也能认出设备
OpenRig 的自动发现有两个层级。第一个层级是网段扫描，原理和我们常用的网络扫描工具差不多：通过 ICMP ping 探测存活主机，再尝试连接常见端口识别服务。第二个层级是协议层的指纹识别，默认走 SNMP 协议。
SNMP 的标准管理信息库里有几个关键节点：.1.3.6.1.2.1.1.1是系统描述，.1.3.6.1.2.1.1.5是主机名，.1.3.6.1.2.1.1.6是物理位置。OpenRig 扫描到设备之后，会主动发 SNMP GET 请求读这些节点，根据返回的内容判断设备类型。比如同一台设备，如果只开放 80 端口，它会猜测是 Web 设备；但如果 SNMP 返回了厂商 OID，它就能精确到某个品牌的工作站或网络交换机。
这种"Agentless 优先"的设计，对网络设备特别友好。交换机、防火墙、IPMI 管理网卡这些设备上一般很难安装第三方 Agent，但它们几乎都内置了 SNMP 支持。OpenRig 用标准协议去读，就能拿到不少信息。
代价也有。标准 SNMP 只能暴露设备主动提供的通用指标，如果你非要采集某个自定义进程的状态，或者想看某块 GPU 核心的显存温度，SNMP 默认是拿不到的。这时候就需要第二种模式，给机器装一个轻量 Agent，由 Agent 直接读 sysfs、传感器芯片和/proc，再把结果上报给服务端。我在实际部署中通常让网络设备走 SNMP，让 X86 工作站和服务器装 Agent，两者互补。
2.2 指标采集链路：从硬件传感器到 Web 界面
OpenRig 的监控链路可以简化为四个环节：硬件传感器、采集器、数据库、前端页面。
硬件传感器暴露数据的方式各有不同。x86 服务器的 IPMI 提供标准传感器接口；普通工作站用 Linux 的lm-sensors读取主板上 Super I/O 芯片；有的设备有自己的专用 MIB，需要单独配置。OpenRig 的采集器会把这些不同来源统一成一套内部指标格式，比如cpu.temperature、disk.usage、fan.speed，再按设备 ID 写入时间序列数据库。
数据库层面的设计很务实。小规模部署用 SQLite 就够，OpenRig 会把历史数据按小时、按天做预聚合，这样打开 30 天趋势图时不需要扫描每一条原始记录。如果是几百台设备的大型环境，也可以切换到外部时序数据库，比如 InfluxDB 或者 PostgreSQL。数据格式是开放的，我自己曾经直接读出历史表，写了个小脚本生成月度资源报表，非常方便。
Web 前端做的事情就是定期从服务端 API 拉取最新指标和聚合数据，绘制折线图、热力图和仪表盘。整个链路没有太多神秘的地方，核心价值在于 OpenRig 把这一套从头到尾串好了，不用你再拿几个开源组件手工粘一遍。
2.3 远程电源管理：三种通道的适用场景
远程开机和重启，是 OpenRig 让我使用体验提升最明显的地方。它背后有三条通道，分别对应不同的硬件能力。
Wake-on-LAN（WoL）是最常见也最便宜的方式。原理很简单：目标网卡在系统关机后仍然保持待机状态，会监听并识别特定的魔术包。魔术包的结构是 6 个字节的FF，后跟 16 次重复的目标 MAC 地址。OpenRig 管理端拿到设备的 MAC 地址后，直接向局域网内发出这个包，网卡收到后就会唤醒系统开机。这个方案不需要额外硬件，但缺陷也很明确：只能唤醒软关机状态下的机器，插头被拔掉或者完全断电就无能为力。
IPMI是服务器领域更可靠的方案。服务器主板上的 BMC 管理芯片有自己独立的网络接口，只要 BMC 还在通电，你就可以通过 IPMI 协议执行开机、关机、硬重启，甚至设置下一次启动设备。OpenRig 通过ipmitool这类底层工具和 BMC 通信，支持 lanplus 协议。在我管理的设备中，有三台旧服务器就是靠 IPMI 撑过了好几次远程修复场景。
智能 PDU则是最后一招。当目标机器连 BMC 都没有，网卡也不支持 WoL 时，可以通过带网络管理的电源插座切断/恢复该回路的供电。OpenRig 会调用 PDU 厂商的 HTTP API 实现 socket 级断电重插。这种方式最暴力，但也最通用。
实际使用时，OpenRig 允许给设备同时配置多条电源通道，并设置平台优先级。比如通道宕了，自动尝试下一条，这比手工去机柜按电源键强太多了。
2.4 告警引擎：阈值、持续时间、抑制和恢复通知
告警引擎的配置选项很多，但真正有价值的核心参数只有几个：阈值、持续时间、抑制窗口、恢复通知。
阈值很好理解，CPU 超过 90% 就报。但单独一个阈值很容易误报，因为业务程序瞬时拉高 CPU 太常见了。OpenRig 的告警引擎用"连续 N 个采集周期都超过阈值"来判定，只有当异常持续足够久才真的产生告警。比如采集周期是 30 秒，N 设为 6，那意味着异常持续三分钟以上才会触发。这个机制有效地过滤掉了大量瞬时毛刺。
抑制窗口解决的是告警风暴。一台设备持续异常，如果每分钟都发一条告警，值班手机会被刷爆。OpenRig 默认会把相同主机、相同指标的告警合并，在抑制窗口内只发一次，同时持续更新状态。等指标恢复正常，再发一条恢复通知，整个告警生命周期画上句号。
这些参数全部可以在配置文件中调整，也可以按主机、指标单独覆盖。我最早的版本里，对温度这类严重指标把 N 调小到 2，对磁盘使用率把窗口拉长到一天两次，这样既不会漏掉硬件风险，也不会被低频问题吵得头疼。
3. 从零部署 OpenRig：从第一台设备跑出监控数据的完整过程
3.1 硬件选型：跑 OpenRig 不需要一台"专机"
部署 OpenRig 的服务端不需要高配置。我的运营环境是一台旧的迷你主机，2 核 4GB 内存，30GB 磁盘，跑 Ubuntu 22.04 LTS。数据量不大时，这个配置能同时支撑差不多四五十台设备的监控数据。如果你管理的设备超过一百台，建议把内存加到 8GB，磁盘换成 SSD，并把数据库切到外部时序库。
需要注意的一点是，服务端和设备的网络关系决定了监控能不能收到。如果所有设备都在一个局域网，OpenRig 服务端只需要一个普通网段就能工作。如果有独立的管理网段，尽量让服务端至少有一块网卡接入管理网络。监控数据走管理网而不是业务网，既能减少干扰，也更安全。
3.2 用 Docker Compose 把服务端和界面跑起来
OpenRig 的安装方式很直接，我使用的是 Docker Compose。先创建一个项目目录，把下面的docker-compose.yml写好：
services: openrig-server: image: openrig/server:0.9.2 restart: unless-stopped ports: - "8000:8000" volumes: - ./openrig-data:/var/lib/openrig - ./config.yml:/etc/openrig/config.yml environment: OPENRIG_DB: sqlite:///var/lib/openrig/openrig.db OPENRIG_ADMIN_TOKEN: change-me openrig-web: image: openrig/web:0.9.2 restart: unless-stopped ports: - "3000:3000" environment: OPENRIG_API_ENDPOINT: http://openrig-server:8000在项目目录里执行：
docker compose up -d然后打开http://服务端IP:3000，用配置的管理员 Token 登录。如果页面上能看到服务端健康状态为正常，说明这套骨架已经活过来了。这里有个小经验：OPENRIG_ADMIN_TOKEN一定要在一开始就改成强随机字符串，不要用默认值。OpenRig 的 API 管理着电源控制通道，token 泄露等于别人能重启你所有机器。
3.3 接入第一台设备：用 SNMP 探测建立资产记录
服务端起来之后，第一步不是手动添加设备，而是配置自动发现。我习惯先把扫描网段写进config.yml：
discovery: enabled: true interval: 3600 networks: - "192.168.10.0/24" - "192.168.20.0/24" scan_methods: - icmp - snmp snmp: version: v2c community: public timeout: 3s retries: 2保存后重新加载配置：
docker compose exec openrig-server openrigctl reload然后手动触发一次扫描：
docker compose exec openrig-server openrigctl scan --network 192.168.10.0/24扫描结束后，Web 界面的"资产发现"页面会出现一批新设备。如果是网络设备或服务器，OpenRig 通常已经通过 SNMP 拿到了系统描述、厂商和型号；如果是普通工作站，可能需要手动补一条设备名和分组。选中目标设备，点击"纳入管理"，它就会进入常规监控流程。
第一次接入，我建议先检查一台设备的指标是否真的在涨。比如在目标设备上跑一个压测命令让 CPU 升到 80%，然后回到 OpenRig 的监控页面，看 CPU 曲线是否同步变化。确认这一步，说明采集链路、数据库、前端展示已经全部打通。
3.4 Agent 模式：细粒度指标何时用、怎么配
SNMP 接入满足不了所有场景。比如我想看某台 GPU 服务器的显存温度，或者某个自定义服务进程是否存活，SNMP 标准库里没有这些东西。这时就给目标机器装 OpenRig Agent。
Agent 的优势是能够直接读取本地传感器和系统文件，再用带认证的 Token 上报给服务端。安装命令很轻量，本质上只是一个二进制：
curl -fsSL http://openrig-server:8000/install.sh | bash openrig-agent --server http://192.168.10.20:8000 --token agent-token-xxx如果是 Windows 工作站，也有对应的 Windows 服务版本，注册成系统服务后可以开机自启。Agent 模式下采集的数据颗粒度更细，并且可以实现 OpenRig 服务端反向下发电源控制命令以外的自定义任务。不过我不建议给所有设备都装 Agent，网络设备、BMC 这类本身有 SNMP 的，没必要多装一个进程。
4. 实测排障：权限、跨网段与传感器读数这三个最有代表性的坑
4.1 扫描结果一片红色？先查 SNMP 的 community 与防火墙
我第一次扫描用community: public，结果一堆网络设备扫不出来，界面上全是扫描超时。第一反应是 OpenRig 的扫描器有问题，后来用系统自带的snmpwalk手动探测，才发现问题根本不在 OpenRig。
手动执行：
snmpwalk -v2c -c public 192.168.10.12 .1.3.6.1.2.1.1.1结果显示Timeout: No Response from 192.168.10.12。这说明主机的 UDP 161 端口根本不通。再检查设备配置，发现那台交换机的 SNMP 只监听了管理网段的 IP，而 OpenRig 服务端的地址在不同的网段。把交换机 SNMP 监听地址改成 0.0.0.0，或者放行管理网段到用户网段的 UDP 161，问题立刻解决。
另一类情况是端口通，但返回No Access。大多数设备默认的 community 是public，但也有人把它改成了别的字符串。如果你不确定，可以先用设备厂商的工具确认实际 community 值，再同步到 OpenRig 的配置里。注意，不要指望一台设备上所有 OID 都能用同一个 community 读取，有的网络设备对不同的 OID 树设置了不同的读写权限。OpenRig 扫不到详细指标时，先用snmpwalk把整棵 OID 树拉一遍，就知道到底是谁被卡住了。
4.2 WoL 只在同网段有效：跨网段远程开机的解决路径
OpenRig 面板上配好了 WoL，但点击"开机"后，机器毫无反应。这个问题十有八九出在跨网段。
WoL 的魔术包本质上是链路层广播帧，只能在整个二层广播域内传播。OpenRig 服务端所在的网段和目标机器不在同一个网段时，默认情况下路由器不会转发这种广播，魔术包自然就到不了目标网卡。
解决思路有好几种。最简单的是把 OpenRig 服务端的管理地址放到和所有目标设备相同的网段，但现实中不一定可行。更通用的办法是让路由器支持定向广播，把 WoL 的目标地址设为目标网段的广播地址，比如192.168.20.255。不过很多网络设备默认关闭定向广播，需要在 L3 交换机上显式开启。
如果路由器配置权不在手里，还有一个偏方：在 L3 交换机或者路由器上给目标主机的 IP 添加一条静态 ARP 表项：
ip neigh add 192.168.20.10 lladdr 00:1e:67:c8:ab:31 dev vlan20这样 OpenRig 发送到该 IP 的魔术包会以单播方式被交换机正确处理，目标网卡收到单播帧后同样能唤醒。实测下来，这个方法在 Cisco 和华为交换机上都可行。不过要记住，WoL 只能从 S3 睡眠或 S5 软关机状态唤醒设备，真正断电的设备必须依靠 IPMI 或 PDU。
4.3 温度曲线像心电图：传感器映射与数据平滑
还有一次踩坑是在工作站上。接入 OpenRig 后，温度监控曲线每五分钟跳一次，从 45 度直接蹦到 90 度，然后又回落，整条曲线看着像心电图。下意识觉得是机器散热有问题，跑到现场一看，机器安安静静，实际温度稳定在 50 度左右。
问题出在传感器映射上。Linux 的传感器框架/sys/class/hwmon下会有多个硬件监控芯片，OpenRig 默认采样时可能读到了主板某个空闲传感器，而不是 CPU 核心温度。解决办法是在设备配置里显式指定传感器路径：
sensor_map: "workstation-01": "hwmon2_temp1" "workstation-gpu": "hwmon1_temp1"手工指定之后，曲线立刻正常。另外，OpenRig 还支持对温度这类波动大的指标做平滑处理，比如取连续五次采样的中位数而不是平均值。中位数能去掉明显异常的单点脉冲，平均值则容易被尖刺拉高，导致误报。我用中位数策略后，温度告警的准确率提升了不少。
5. 进阶配置：让 OpenRig 从"监控面板"变成"值班助理"
5.1 用 Webhook 把告警变成自动重启脚本
OpenRig 的 Webhook 是最实用的集成入口。它可以在告警触发、恢复时向任意 HTTP 地址推送一个 JSON payload，我拿这个功能做了一个最简单的自愈流程。
先配置一个 Webhook 目标：
hooks: - name: auto-restart url: http://192.168.10.30:9000/hook/openrig events: - host.alert - host.recovered接收端可以用一段很短的 Python 或 shell 脚本。比如当某台主机失联达到 critical 级别，自动通过 IPMI 执行重启：
#!/usr/bin/env bash payload=$(cat) host=$(echo "$payload" | jq -r '.target') level=$(echo "$payload" | jq -r '.level') metric=$(echo "$payload" | jq -r '.metric') if [ "$metric" = "host.unreachable" ] && [ "$level" = "critical" ]; then curl -s -X POST "$OPENRIG_API/power/restart" \ -H "Authorization: Bearer $OPENRIG_TOKEN" \ -d "{\"host\":\"$host\",\"mode\":\"cold\"}" fi这套逻辑执行前，我建议先加上一个安全护栏：限定只对测试环境机器生效，并且每天只允许自动重启两次。否则脚本本身出了问题，可能会把所有机器轮流重启一遍。自动化替代人工，但自动化也需要自己的熔断机制。
5.2 告警分级与路由：不让值班手机被无关消息刷屏
告警路由是 OpenRig 这段时间帮我看门的重要功能。它把告警分成 info、warning、critical 三个级别，并允许按级别配不同的通知渠道。
routes: - level: critical targets: [sms, push] - level: warning targets: [email] - level: info targets: []我的策略是：只有 critical 级别才会真正打扰人，warning 汇总到邮件，info 干脆不通知。这里的 critical 不只看单一指标数值，而是结合了持续时间和业务影响。比如某台机器 CPU 达到 95% 但只持续了一分钟，我会把级别定为 warning；如果连续五分钟超过 95% 且负载同时飙高，才升级为 critical。OpenRig 支持组合条件和表达式，虽然配置起来比单一阈值复杂，但长远来看非常值。
5.3 和现有监控体系联动：SNMP Trap、Prometheus 接口都有路口
OpenRig 不是一座孤岛。如果你的环境里本来就有 Prometheus，可以在 OpenRig 服务端开启/metrics接口，让 Prometheus 每隔 30 秒拉一次 OpenRig 自身的运行状态。这样统一告警入口不变，OpenRig 自己的健康也能被盯住。
网络设备如果需要主动上报异常事件，可以配置 SNMP Trap 转发。OpenRig 内置了一个轻量 Trap receiver，收到设备发来的 Trap 后，会转成标准的内部告警对象。这个能力对我和交换机打交道很关键，因为很多网络事件是突发性的，靠轮询很难及时发现。
更传统的运维体系则可以直接用 OpenRig 的 API。所有设备和指标都支持通过 API 查询，我在内部写了一个小工具，每天晚上把 OpenRig 的资产数据同步到 CMDB，替代了原来手工维护的 Excel 表格。API 就是开放系统的通用语言，OpenRig 把这一点做得比较透明。
5.4 资产标签与容量报表：从监控数据反推设备淘汰
最后这个用法算是我自己额外挖掘的。OpenRig 允许给设备打标签，比如"机房-A 列""研发测试""2024-采购""即将淘汰"。配合标签筛选和资源趋势报表，我能快速回答三个问题：哪些机器长期 CPU 空闲、哪些机器内存经常不够、哪些机器已经超过五年寿命。
去年年底我就用这个方法整理出一份清单，把八台长期内存满负荷、但 CPU 使用率不超过 10% 的服务器挑了出来。最终结论是，与其给它们逐台加内存，不如把两个批次的工作负载合并到一台内存更大的新机器上，省下了两台旧机器的电费和机位。这些决策靠感觉做不出来，靠 OpenRig 的报表数据却很自然。
6. 我在使用中沉淀下来的几条经验
OpenRig 适合谁？我现在的回答是：适合管着几十台以内物理设备、不想为了监控上个重型平台、又希望有基本自动化和开放接口的人。它不完美，比如在资产数量超过一百台时，SQLite 的性能会开始让人着急；UI 的精细度也不如商业产品。但这些都不影响它在中小规模场景下成为一套非常好用的工具。
部署前做两个小动作，能省很多事。第一，把所有设备的管理网段规划好，尽量让监控走独立 VLAN；第二，提前收集每个设备的 SNMP community、IPMI 账号、网卡 MAC 地址，别等扫描之后才发现根本没有权限。这两个动作做完，接入过程基本可以一路绿灯。
我自己在用的核心功能其实只有三个：资产自动发现、温度异常告警、远程重启。其余的花哨功能，比如自定义报表、Webhook 自愈，都是后期逐步加上去的。工具不是功能越多越好，而是真能在半夜替你少跑一趟机房，那才是它存在的意义。
