★ FEATURED ARTICLE 玩自托管的朋友应该都有过这种经历手底下三台机器、五台机器每天都在盯着温度、磁盘、进程看。每次开机第一件事就是开一堆终端SSH到每台机器上去敲命令敲完就忘下次又得重新敲。OpenRig就是为了解决这个局面做的一个开源小工具——它用一套轻量的Web仪表盘把每台主机的实时状态聚合到同一个页面温度、负载、磁盘、内存、在线状态一目了然配好脚本之后还能自己生成监控指标。项目本身很小装起来也就一条命令的事适合家庭实验室玩家、渲染农场管理员、工作室网管以及所有嫌重型监控方案太麻烦的人。这套东西的核心思路很简单被监控的主机上跑一个轻量Agent定时把数据推到服务端服务端负责存储、展示和告警。没有消息队列、没有微服务、没有若干数据库。整个后端是一个单一二进制文件前端是一个不依赖构建工具的简单页面。所以它能跑到树莓派、软路由、老笔记本这种低配设备上也可以管几十台机器。下面我就把整个项目从设计到部署再到我踩过的坑完整写一遍。1. 为什么我会做OpenRig自托管监控的几个痛点1.1 从折腾SSH到想做仪表盘最早我管理三台机器的方式是给每台机器写好一个固定的Shell脚本每天手动跑一遍输出CPU温度、硬盘健康度、内存占用。脚本本身没问题但问题在于看的过程。每次都要一个终端一个终端地连上去明明只是想知道有没有哪台温度偏高却要把所有机器的输出从头到尾扫一遍。等机器数量涨到七八台的时候这个动作基本就变成了负担。我试过很多现成方案。Grafana加Prometheus加node_exporter确实强大数据密度高、可视化也漂亮但配置成本和学习曲线放在那儿光是搞懂promql怎么写就要几天。它更像一个为专业监控场景设计的瑞士军刀而我只想快速回答今天这几台机器是否正常。1.2 我眼中的够用就好OpenRig从一开始就明确了一件事不做全功能监控平台只做一个能让人坚持用下去的轻量系统。我把够用定义成三条标准。第一部署时间控制在五分钟以内。我不希望用户在搭建监控系统这件事上花的时间比监控本身还多。第二资源占用低。目标是一台树莓派上既能跑服务端又能干别的事空闲内存最好不超过100MB。第三扩展要容易。用户不需要理解一套复杂的插件机制只要会写一个能输出JSON的脚本就能把自己关心的任何指标加进去。有些朋友可能觉得这套逻辑太简陋。但说实话对于几台到几十台机器的规模我们需要的不是百分之百的指标覆盖率而是一个可持续运转的观测窗口。当你打开仪表盘发现所有主机都在线、温度曲线平稳、没有告警跳出这就是监控系统最大的价值。2. 整体架构与核心设计取舍2.1 客户端-服务端模型为什么不用无代理方案设计监控系统时第一步是决定数据采集方式。我调研过无代理方案通过SNMP去读设备状态、通过SSH远程执行命令。SNMP在交换机、打印机这类网络设备上是主流选择但对于普通PC和服务器它能拿到的信息太有限CPU使用率、进程列表、传感器温度这些常见指标很多设备根本不提供标准OID。SSH远程执行命令倒是灵活但每次采集都要建立连接、做认证频率高了既慢又容易把被监控机器搞出大量认证日志。所以OpenRig选择了有代理模型。每台被监控主机运行一个Agent进程Agent自己负责采集本机数据然后通过HTTP推送到服务端。这样做有几个实打实的好处端口只需要服务端开一个被监控主机不需要暴露任何入站端口不容易成为攻击面采集频率和采集内容完全由Agent控制动态增加指标也不需要动服务端还有Agent可以离线缓存数据等网络恢复后再补报无代理方案很难实现这一点。2.2 技术选型只选节省运维时间的服务端我选Go来写。核心考量是部署便利性Go编译出来是静态二进制丢到服务器上就能跑连依赖都不用装。对于一台可能还要跑数据库、Web服务器、其他业务的老机器能少一个运行时就是少一个坑。Agent端我只保留一个轻量的C语言实现和一个Python实现Python那边方便用户嵌入自己的采集逻辑C版本则用于低配设备和容器环境。前端没有引入Vue或者React工程因为对于这种以图表展示和列表刷新为主的页面原生JavaScript配合Chart.js已经足够了。少一层构建工具就少一层维护负担升级依赖、修复构建问题这一整套流程在小项目里都是纯成本。数据存储用的是SQLite很多人在这一步会质疑。其实根据我的实测一台机器即使每三十秒上报十条指标一天的数据量也就几十MB。几十台机器、保留三十天SQLite完全扛得住。定期跑一次清理把超过期限的数据删除或者降采样聚合写入和查询都不会有瓶颈。真要到了上万台设备那种量级再考虑换时间序列数据库也不迟OpenRig的数据模型设计也保证了迁移成本不会高。2.3 指标模型像Prometheus但砍掉一半复杂度接入过Prometheus的人都知道labels的概念非常好用但PromQL的查询语法对于普通用户来说门槛不低。OpenRig简化了这套模型每个指标由核心字段主机名、指标名、值、时间戳加一组可选的键值对标签组成。采集端上报数据时已经附带标签服务端存储时原样记录前端通过下拉框筛选特定标签组合。打个比方Prometheus像是一套完整的编程语言而OpenRig只保留了常用的那几个函数按时间范围取平均值、最大值、最新值以及按标签分组聚合。基本覆盖了日常监控的绝大多数需求。采集扩展我设计成了脚本调用形式。Agent定时执行一个或多个外部命令标准输出如果是合法JSON就自动解析为指标数据。例如用户想监控一个目录的大小只需要写一个打印JSON的Shell脚本或Python脚本然后告诉Agent每十分钟跑一次。不用编写插件、不用重新编译、不用重启Agent脚本更新了下次执行自然生效。3. 从零部署OpenRig5分钟跑通最小系统3.1 准备环境和解压部署包部署过程我尽量压到最简。服务端支持两种启动方式任选其一。第一种是Docker方式适合已经装了Docker的环境mkdir -p /opt/openrig/data docker run -d --name openrig-server \ -p 8080:8080 \ -v /opt/openrig/data:/data \ openrig/server:latest第二种是二进制方式适合不想引入容器的情况wget https://example.com/openrig-server-linux-amd64.tar.gz tar xf openrig-server-linux-amd64.tar.gz ./openrig-server --data /opt/openrig/data --bind 0.0.0.0:8080启动之后第一次访问会要求创建管理员账号。这里有个细节默认绑定的是0.0.0.0:8080意味着局域网内所有人都有可能访问这个端口。如果你不想让别人看到你机器的监控数据就一定要在初始化后开启访问密码或者把--bind改成127.0.0.1再在前面挂一层反向代理。注意Docker映射端口时建议只把你需要的端口暴露出去。生产环境里更稳妥的做法是让Docker容器使用host网络或者直接用二进制方式部署这样服务端不需要额外维护NAT映射关系。3.2 在受管主机上注册并上报数据服务端起来之后下一步是把每台被监控主机接入进来。后台有一个添加主机入口会生成一次性注册链接在目标主机上执行curl -fsSL http://10.0.0.2:8080/install.sh | bash -s -- --token 一串一次性Token这条命令会下载Agent、写入systemd服务配置并启动整个过程大约十几秒。你也可以选择纯手动方式在受管主机上安装Agent二进制然后执行openrig-agent --server http://10.0.0.2:8080 --token 一串一次性Token注意这里传的是服务端的内网地址。如果服务端部署在公网且没有配置HTTPS那Token被截获的风险会比较高建议在受控环境下使用。Agent启动后会在后台每三十秒上报一次本机的基础指标CPU使用率、内存占用、磁盘空间、网络流量、整机温度如果系统支持。你可以在服务端页面看到在线状态立即变成在线大约一分钟内仪表盘上开始出现第一波数据。3.3 快速验证数据是否入库如果页面没有出现数据通常需要先确认是不是真的入库了。服务端安装目录下有一个metrics.db的SQLite文件你可以直接查询SELECT hostname, metric, value, ts FROM metrics ORDER BY ts DESC LIMIT 10;能看到最近十条记录说明链路是通的。如果查询不到数据优先检查Agent进程状态和日志systemctl status openrig-agent journalctl -u openrig-agent -f日志里通常直接写了HTTP上报失败的原因最常见的是URL拼错、Token过期或服务端防火墙把8080端口挡了。3.4 仪表盘和告警的基本配置数据进来之后默认的仪表盘就能展示实时数值了。页面下方有主机列表点击任意主机可以看到该主机的全部指标时间曲线。OpenRig的告警规则配置页支持三种逻辑条件指标值超过阈值、指标值低于阈值、主机持续离线。每套规则都可以设置连续多少次才触发这是为了过滤瞬时抖动。一个温度告警的例子指标名cpu_temp条件 90连续次数3通知渠道Webhook当CPU温度连续三次采集都超过90度才会触发告警。如果中间出现一次80度计数会清零重来。这个机制能在很大程度上避免没必要的打扰。4. 我在实际部署中踩过的坑4.1 Linux读取温度信息的权限问题我最初在一台装了新版Ubuntu的NUC上测试Agent报上来的cpu_temp一直是空的。排查了半天发现原因很简单普通用户执行sensors命令时没有权限读取传感器数据Agent默认也不是以root身份运行的。解决办法有几个方案。如果只是想快速验证可以把Agent的systemd单元改成Userroot但我不建议长期这样干毕竟监控进程拥有root权限的本身就属于安全隐患。更好的做法是把传感器读取权限加到用户组sudo usermod -aG openrig openrig-agent-user sudo chmod gr /sys/class/hwmon/hwmon*/temp*_input前一种方案适用于测试环境后一种方案相对安全一些但不同硬件平台的sysfs路径并不一致所以还是要根据实际环境做调整。这类周围都正常、就是没数据的问题最考验排查耐心。4.2 时间不同步导致数据乱序有段时间我的仪表盘上曲线图经常出现时间倒挂和锯齿状跳动看起来像数据错了实际是好几台机器的系统时间都偏移了。Docker容器默认使用的UTC时区不会改变系统时间但如果你在KVM虚拟机或某些轻量云主机上跑宿主机时间不准是完全可能的事。给所有受管主机安装chrony并启用网络时间同步之后这类问题基本绝迹sudo apt install chrony sudo systemctl enable --now chronyd还要顺手检查一下时区。OpenRig展示时间默认用的是浏览器本地时区但如果服务端本身时间是UTC而你在东八区看曲线的时候总会觉得晚八个小时。建议所有主机都统一成UTC时区转换交给页面处理会省心很多。4.3 网络抖动造成告警风暴另一个让我印象深刻的坑是告警风暴。某一天凌晨一台交换机因为固件问题导致整个网段大面积丢包几十台Agent纷纷上报失败离线告警在十分钟内刷了上百条。这种告警对值班的人没有任何帮助反而会让真实的故障被淹没在噪音里。我后来给离线告警加了一个确认时长参数某台主机失联后必须持续超过五分钟才算离线。同时把连续次数机制应用到所有告警规则上。另外还引入了一个简单粗暴的告警收敛策略同一个规则触发的告警在十五分钟内只通知一次除非状态恢复后再次触发。这套组合下来告警量明显下降而真正的故障比如某台主机断电并不会被漏掉。4.4 数据库无限膨胀起初为了图省事原始数据不分时间范围一直存。跑了两个月SQLite文件膨胀到好几个GB查询响应从毫秒级变成秒级整个页面都开始卡。后来我做了分级存储原始数据保留72小时用于出图和短期分析五分钟聚合数据保留三十天用于日常趋势查看小时级聚合数据保留一年用于长期容量规划这个策略对小型自托管场景非常合适。聚合数据是通过一条SQL语句在后端定时任务里完成的粒度丢失也完全可以接受。做监控的人最容易犯的错就是在不了解自己真实需求的情况下把数据全量保存最后被数据本身压垮。5. 常见问题与排查思路速查表下面这个表格是几个高频问题的排查路径基本覆盖了部署初期80%的情况。症状可能原因处理方式Agent启动后立即退出Token无效或已被使用在服务端后台重新生成Token确认Token只使用一次页面显示离线但Agent进程存在Agent上报地址不不能访问在受管主机上执行curl测试服务端地址和端口某些指标在页面上为空采集脚本权限不足检查Agent运行用户是否具备读取对应系统信息的权限曲线正常但数值明显偏高/偏低采集脚本单位换算错误在页面查看该指标的原始值与本地手动执行结果对比告警触发次数非常多阈值设置过小或连续次数为1适当提高阈值并把连续次数改为2-3次访问页面很慢查询范围过大或数据未清理升级到最新版配置好数据保留策略磁盘告警误报监控了临时文件挂载点在采集器配置中排除容器运行时目录升级后历史数据丢失数据目录未正确挂载确认Docker挂载卷和--data参数指向原来的目录排查时记得先看最基础的链路Agent是否运行、上报是否成功、服务端是否入库。大多数人遇到的都是一层简单的配置问题不需要一上来就怀疑代码有Bug。6. 扩展让OpenRig融入你的自动化体系6.1 Webhook把告警推到工作群默认的告警通知只会在服务端界面顶部弹红条真正有运营价值的是把它推到消息群里。OpenRig的告警规则里可以配置Webhook地址触发时 POST 一条固定格式的JSON。我自己的做法是接了一个群机器人的接口晚上温度超过阈值时直接发到值班群里。这个改动只需要在后台填一个URL不需要改代码效果却非常明显。6.2 开放API做联动自动化监控不只是为了看更是为了自动响应。OpenRig的服务端暴露了简单的REST API如果你愿意的话可以自己做一个自动化联动某台主机连续离线超过十分钟就把这台机器的流量调度到其他节点磁盘剩余空间低于某个百分比时自动触发打包清理脚本CPU温度持续过高时把某个高负载进程降级这些联动动作不要放在Agent里Agent的职责就是上报业务逻辑统一放在有API调用能力的调度端。我这边就用了一个cron脚本定时拉取API发现异常再执行外部命令逻辑简单、出错容易定位也不容易影响监控链路本身。6.3 保留数据和跨系统迁移如果你后面想接入更完整的监控体系OpenRig支持把聚合数据以CSV格式导出也允许把原始指标以remote-write方式推到Prometheus。做了这一步之后既保留了轻量仪表盘的日常体验又能让更重的分析任务走专业平台两边数据可以相互验证。我个人建议等数据量确实大到SQLite吃不住的时候再做迁移否则这套轻量方案已经足够让你的机器管理效率提升一大截。最后再分享一个经验别想着一步到位把监控系统设计得无比庞大先让最简单的指示灯亮起来再慢慢加指标、加规则最后你会发现真正让你安心的是那个每晚都能正确报平安的界面。
阅读完成 · 觉得有帮助？
