做了几年多卡矿场的日常运维最头疼的事其实不是算力上不去而是机器半夜掉线、显存温度飙到 90 度、矿机重启之后没有自动拉起第二天醒来看到算力图表上一个大坑。我一开始用的是一个半开源的监控脚本功能零散告警靠邮件后来实在忍受不了自己动手把整套方案重新整理成了一个开源的矿机管理与监控平台名字就叫openrig。这篇文章不聊虚的直接把项目从需求拆解、架构设计到部署细节、踩坑实录全部摊开给同在做矿场运维、或者想自己搭一套监控系统的朋友一份能直接抄作业的参考。openrig 解决的核心问题可以用一句话概括让一堆分散在不同矿场、不同矿机软件下的 GPU 设备用一套统一的 Agent 采集数据、一套统一的后台做展示和告警并且能在故障时自动恢复。先说说我为什么要重新造这个轮子再讲清楚它的设计逻辑、核心实现最后附上部署过程和我在生产环境里踩过的各种坑。1. 做矿场运维这些年我为什么需要 OpenRig早期我管矿机的方式特别原始手里十几台机器每台装了不同的矿机软件有的是 Claymore有的是 TeamRedMiner 或者 lolMiner。每个软件都有自己的状态页或者本地 JSON API我得一台一台 SSH 上去看算力、温度、风扇转速出了问题还要手动敲命令重启。后来机器规模上去了开始有人用 HiveOS 这类第三方系统确实方便但问题也很明显一是很多数据都走第三方服务器矿场网络环境稍微复杂一点数据上报就不稳定二是平台锁死了矿机侧的配置方式我想对显存功耗做细粒度调整、想接自己的告警渠道都得绕很多弯子。HiveOS 这类平台能力没问题但它是一个商业闭环系统而不是一个我可以随意改造成自己运维体系的组件。所以 openrig 最开始的定义就很明确它是一个开源、可自托管的矿机监控与管理平台核心定位是让运维者把数据主权握在自己手里。你只需要在一台普通 Linux 服务器上部署服务端然后在每台矿机上装一个轻量 Agent矿机的运行状态就会被采集到本地服务端通过网页控制台统一查看。数据存在你自己的数据库里告警走你自己的渠道不依赖任何第三方平台的可用性。几年用下来这套东西对我的价值不只是省了半夜爬起来的次数更重要的是它把矿机状态从一个需要手动确认的事情变成了一组可以长期积累的数据。算力曲线、温度趋势、故障频率都能拿出来做分析甚至能反推某个矿场的供电稳定性。这篇文章所有内容都是基于 openrig 在实际矿场环境中的运行经验整理出来的配置参数和数值都是一线实操得出的不是照着文档搬理论。2. OpenRig 的整体设计与架构思路2.1 为什么选择中心化服务端 轻量 Agent模式矿场监控这个场景网络条件往往非常不理想。矿机可能分布在不同的电费便宜的地方有些矿场出口带宽极小甚至有些节点之间的网络丢包率很高。最开始我考虑过 mesh 式的设计让矿机之间互相发现、互相备份数据听起来很去中心化但实际维护成本极高。矿机是拿来跑算力的不是拿来当分布式存储节点的与其在每台机器上折腾复杂的互备逻辑不如把采集、存储、展示这些活集中到一台专门的服务端上。openrig 最终采用的就是经典的服务端 Agent 架构。每台矿机上运行一个 Agent 进程负责本地采集指标、调取矿机软件状态、执行重启等操作服务端负责接收指标、存储数据、计算告警规则、提供网页 API。这个设计有几个特别实际的好处Agent 极轻量只和本地矿机软件通信不占用多少 CPU 和内存哪怕矿机算力满载也不会受影响。数据只在 Agent 和服务端之间传输网络路径可控出现断网时 Agent 本地会缓存部分状态恢复后再补传不会因为一两次网络抖动就丢一整段监控数据。服务端集中在内网无论是数据库还是告警 Webhook都是我自己的配置不经过第三方中转。这个模式有一点像智能家居的网关 子设备结构子设备只上报自身状态所有联动逻辑都放到网关上来做。改成运维语言就是矿机只负责上报我活着没和按指令干活决策全部收敛到服务端。系统复杂度被限制在可控的范围内这也是它能稳定跑几个月不需要人工干预的根本原因。2.2 技术栈选型与部署形态技术栈的选择直接决定了 Agent 能不能在各种回收显卡、杂牌矿板的机器上顺利跑起来。先说 Agent 端。矿机的主流系统是 Linux有的是 Ubuntu有的是各种精简版的矿工系统还有一个现实情况是很多矿机主板 BIOS 老旧、硬盘又慢Java 和 Python 这类需要解释器或者虚拟机的方案很容易出兼容性问题。所以 Agent 我选了Go 语言来写编译出来是一个完全静态链接的二进制文件扔到机器上就能跑不需要装任何依赖。服务端这边的主框架用的是Gin SQLite存储直接落 SQLite备份就是拷文件。这个选择看着不大高级但是在一套面向单矿场或者几个矿场的系统中SQLite 是完全足够的。服务端部署的时候只跑一个二进制加一个数据文件反向代理一层 Nginx 就对外提供网页访问既不用装 MySQL也不用维护 Redis。等机器数量真的到了几千台、并发写压力上来了再平滑切换成 MySQL 也不迟架构上早就留好了抽象层。前端控制台没有用什么重型框架就是一套带 WebSocket 的网页实时刷新矿机状态。页面不需要炫但刷新要快每台矿机的状态变化要在 2-3 秒内反映出来。这里用的是 WebSocket 推送而不是前端轮询不然几十台矿机每秒刷新一次服务端的压力也会很可观。2.3 核心数据模型是如何设计的监控系统的核心其实是数据模型。openrig 的主表就几张但字段设计上每一处都是踩过坑之后才定下来的。先说worker 表也就是矿机表。除了常规的矿机名、IP、MAC 地址之外我把几样容易被忽略的东西也单独列了出来矿场 ID 和机架 ID。矿机物理位置的数字化。只记一个名字看不出机器在哪一旦矿场停电或者机柜跳闸没有物理位置信息找机器都靠猜。Agent 版本号。生产环境最怕的就是这台机器还是旧版 Agent根本没有新功能。版本号放在 worker 表里打开矿机列表就能一眼看到谁没有更新。矿机软件类型和端口。Claymore、lolMiner、TeamRedMiner它们的本地 API 端口和返回格式各不相同。Agent 在启动的时候从这张表里拿到本机该用哪个采集协议以后换矿机软件只需要在后台改这条记录不需要登到矿机上改配置。再看metrics 表。每一条指标记录包含算力、显存温度、核心温度、风扇转速、功耗、显存频率、核心频率这 7 个字段。为了省空间我没有设计成 EAV 模式一行一个指标而是一行放一整条采样。这样从 CSV 导出、补数据、绘制曲线都要方便得多。采样粒度默认是 30 秒一台机器一天会产生大约 2880 条记录一个几千台机器的矿场一个月数据量也就几十 GB 级别SQLite 完全扛得住。告警规则表和很多监控系统类似但有两个字段是 openrig 特殊的一是告警沉默时间Repeat Interval告警触发后相同规则的再次推送要等待多少分钟默认 30 分钟否则告警风暴能把人烦死二是恢复自动清除标记标记为开启后矿机状态恢复正常服务端会自动把对应的告警标记为已恢复避免一个告警在面板上挂一个星期。2.4 为什么不直接依赖现成商业方案有人可能会问HiveOS 这类平台免费版也能用甚至做得更成熟开源项目到底赢在哪我的体会是监控系统到后期拼的不是面板多好看而是能不能适配自己的运维流程。比如我的告警需要同时推到企业微信、Telegram 和自建邮件网关三个渠道有不同的格式和重试策略比如我有一批机器跑的是特殊矿机软件连官方管理平台都不认。开源项目的好处是这些需求不再需要去和平台方提工单自己改几行代码、加一个 Webhook 就能解决。而且从数据安全的角度看矿场信息其实是相当敏感的数据资产每台机器的算力、运行时长、温度状态会直接反映矿场的规模、布局和运行策略。把这些数据放在第三方平台上等于把底牌交给了别人。自托管方案虽然前期要多花半天时间搭环境但数据完全掌握在自己手里这是一个无法忽视的长期价值。3. 核心功能拆解与实现细节3.1 算力监控的数据采集链路openrig 的算力采集链路是这样的Agent 每隔 30 秒做一次采样先通过 miner API 拿到原始状态再做数据清洗和格式化最后打包成 JSON 通过 HTTP 上报到服务端。这里最关键的一点是miner API 返回的数据格式极其混乱。以常见的几款矿机软件为例Claymore 的本地 API 返回的是文本格式一行是算力一行是温度解析的时候要按|和;切分lolMiner 返回的是 JSON但不同版本的字段名都不一样TeamRedMiner 用的又是另一种结构和命名。我在 Agent 里做了一个适配器层每一种矿机软件对应一个解析器parser 接到数据之后统一输出成 openrig 内部的标准结构。新增一款矿机软件只需要写一个几十行的解析文件然后重新编译 Agent不需要改任何采集框架代码。type MinerMetrics struct { Hashes []float64 json:hashes // 每张卡算力 Temps []float64 json:temps // 显存/核心温度 Fans []float64 json:fans // 风扇转速百分比 Powers []float64 json:powers // 功耗瓦数 GpuClocks []int json:gpu_clocks // 显存频率 MHz CoreClocks []int json:core_clocks// 核心频率 MHz }适配器输出的结构体统一了字段但每张卡的索引顺序必须保持稳定。矿机软件有时会改变 GPU 枚举顺序比如某张卡临时掉了就会被重新枚举。我遇到过一次很隐蔽的问题一台机器有 8 张卡其中 1 张卡接触不良偶尔掉线重启之后系统重新枚举算力数据整体错位某张卡的温度挂到了另一张卡名下。后面我在适配器层加入了序列号匹配机制每张卡启动时读取其 PCI 槽位信息并回报给服务端用硬件标识而不是卡索引来对齐数据这个问题才算根治。3.2 温度、风扇与功耗管理温度监控如果只看一个当前温度数字在大规模矿场里是远远不够的。以一张典型的 N 卡为例开机空载温度可能是 45 度满载挖矿之后核心温度 60 度、显存温度 80 度。但真正危险的不是这个稳态温度而是温度突变。比如某张卡的显存温度从 76 度在 5 分钟内涨到 88 度说明大概率是硅脂老化、风扇坏卡或者机箱风道被堵住了。openrig 的处理方式是在服务端增加了趋势告警不只是看温度绝对值是否超过阈值还看温度的增长速率。这个功能就是围绕温度上升斜率做规则判断温度变化速率 (当前采样温度 - 5分钟前采样温度) / 温差时长 如果速率 2°C/min则触发温升异常告警这个功能一开始被我认为是锦上添花但实际上它帮我提前发现了一次严重的风扇故障。那次一张卡的显存温度在凌晨 3 点突然开始攀升按照固定的 80 度告警阈值至少要 20 分钟才会触发普通告警而趋势告警在温度涨到 74 度的时候就已经把通知发了过来我远程确认风扇转速从 3000 RPM 掉到 800 RPM直接远程降频处理避免了显卡过热烧毁。功耗管理这块openrig 不直接去改显卡功耗墙而是把控制逻辑留给 Agent 的命令通道。服务端管理员可以在控制台给指定的矿机下发一条自定义命令比如nvidia-smi -pl 220这条命令会把功耗限制在 220WAgent 直接在本机执行并返回输出。脱离开具体显卡型号谈功耗管理就是耍流氓openrig 提供的是下发通道真正的参数选择还是得由熟悉硬件的人来决定这样设计既灵活又不会误操作。3.3 故障检测与自动恢复机制矿机故障的形态其实就那么几种矿机软件崩溃退出、挖矿进程假死进程还在但算力掉到 0、操作系统死机、网络断连。openrig 对这几种情况分别做了处理。先看假死。Agent 在本地持续轮询 miner API如果连续 3 次也就是大约 90 秒拿到的是空数据或者 JSON 解析失败就认为矿机软件已经假死。这时候 Agent 会先尝试执行温和恢复结束挖矿进程并重新拉起同时记录一条本地的恢复日志。如果温和恢复后 5 分钟内算力仍没有恢复再执行强硬恢复发送一个服务端 API 触发的远程重启指令直接重启矿机。这个分级恢复机制很有意思。最开始我图省事Agent 检测到问题就直接重启矿机结果发现很多假死其实只是某个 API 请求超时重启一次矿机至少损失 2 分钟算力而且重启本身有概率让系统挂在 BIOS 自检上。后来改成先重启进程不行再重启机器两次恢复之间留了 5 分钟的观察期实际的误重启率降低了一个量级。网络断连的情况则由服务端来兜底。服务端如果连续 5 分钟没有收到某台矿机的心跳会把这个 worker 标记为离线触发离线告警。这里特别注意要把服务端重启导致的集体离线和矿机真实离线区分开。实现上我给服务端加了一个启动时间戳服务端刚启动后的第一次检测不产生告警否则服务端自己重启一次整场矿机一起报离线那动静可就大了。3.4 告警通知渠道的设计告警通知渠道刚开始我只接了一个邮箱实际使用体验很不好。邮件网关在矿场这种网络环境里延迟很高而且手机上没有即时推送半夜人醒来看一眼手机邮件还没到。后来 openrig 的告警模块做成了通道插件化内置了 Webhook、Telegram Bot、邮件、飞书/企业微信机器人等渠道。这个需求也是从实际场景长出来的因为不同矿场的管理人习惯完全不一样有人常年盯企业微信有人只用 Telegram 机器人收消息。一个细节是告警模板的上下文信息。早期我发的告警通知只有一句话worker-12 掉线了收到之后还得再登录后台看是哪台、什么问题。后来把模板改成在通知里带上关键上下文比如矿机名、矿场位置、当前算力、离线持续时间、Agent 最近一次心跳时间。这样人收到告警之后不用开系统就能判断问题是网络还是矿机也方便一线维护人员直接去现场操作。3.5 Web 控制台与权限管理Web 控制台的体验直接影响一个监控系统能不能在日常运维中用起来。openrig 的控制台主要由三个页面组成总览页展示全部矿场的算力总和、在线矿机数量、告警数量以及各矿场算力排行矿机列表页按矿场、机架、状态多级筛选支持对矿机执行重启、更新 Agent、下发命令操作矿机详情页展示单机的所有时间序列曲线和近期事件记录。权限管理看起来不太起眼但是当一个矿场有两三个人共同运维时就变得很关键。我给 openrig 设计了三种角色管理员、操作员、只读观察者。管理员可以修改告警规则和下发任意命令操作员只能对矿机执行重启等有限操作只读观察者只能看数据图表上连重启按钮都不会显示。这个设计源于一次真实事故——有人不小心在后台点了批量重启十几台机器同时下线。从那以后我就把能够重启矿机的操作权限单独收敛了。4. 从零部署 OpenRig 的完整实操过程4.1 服务端安装与初始化服务端部署我推荐用一台独立 Linux 服务器配置不用高2 核 4G 内存带 100G 硬盘就跑得很轻松。openrig 的发布物是一个压缩包里面包含服务端二进制、默认配置文件和前端静态资源目录。解压之后先改配置文件几个关键参数我要重点解释一下[server] listen :8080 data_dir /data/openrig/store sqlite_path /data/openrig/openrig.db sample_interval 30 ; 采样间隔秒数 heartbeat_timeout 300 ; 心跳超时阈值秒数 recover_silence 1800 ; 告警沉默时间秒数其中listen监听端口默认 8080生产环境一般会在前面挂 Nginx 做 HTTPS 和简单认证data_dir是用来存历史指标文件的目录超过 30 天的数据可以按天归档sample_interval决定 Agent 上报频率如果矿机特别多、服务端 IO 压力大可以改成 60 秒代价是曲线采样粒度变粗heartbeat_timeout是判断矿机离线的时间阈值建议 300 秒起步调太低会频繁误报。初始化的时候只需要跑一次命令./openrigd init --admin-user admin --admin-pass your_password ./openrigd serveinit会在 SQLite 里创建好所有表结构并写入初始管理员账号。整个初始化过程不超过 10 秒钟。我见过不少开源项目把初始化做得异常复杂要让用户手动导入 SQL 脚本openrig 这里全部都在代码里完成了目的就是让部署这件事简单到不会劝退人。4.2 Agent 端安装与注册Agent 的安装流程是开放给矿场一线维护人员来做的所以必须足够傻瓜。openrig 的思路是先在一台已经装好的矿机上拿到一份Agent 引导包然后放到其他机器上执行一个安装脚本即可。引导包里已经写好了服务端地址和这台机器要加入的矿场分组。安装脚本的核心逻辑就这么一段#!/bin/bash # install_agent.sh --server https://monitor.example.com --token xxxxx SERVER$1 TOKEN$2 # 写入 Agent 配置文件 cat /etc/openrig/agent.conf EOF server_url ${SERVER} auth_token ${TOKEN} worker_name $(hostname) poll_interval 30 miner_type auto EOF # 注册系统服务 cp openrig-agent /usr/local/bin/ systemctl enable openrig-agent systemctl start openrig-agent这里有一个关键参数是miner_type auto。Agent 启动之后会自动探测本机监听端口如果检测到 3333 端口开着就按 Claymore 协议解析检测到 4444 端口就按 lolMiner 协议解析。这种自动探测机制省掉了手动配置每个矿机软件类型的工作量尤其适合矿场里面机型软件混杂的情况。Agent 启动后每 30 秒上报一次心跳数据服务端收到后会自动把该 worker 注册到对应矿场分组里。这里要特别提醒第一次注册时服务端默认识别的矿机名就是操作系统的 hostname。如果矿场里面有很多主机名重复的机器注册时系统会自动在名字后面追加短哈希避免覆盖记录。所以装 Agent 之前最好先统一规划好各台机器的主机名否则后期改名字会很麻烦。4.3 矿机组Worker Group划分与多矿场管理矿场规模一大如果不做分组矿机列表就是一团乱麻。openrig 支持两级分组矿场 Site和机架 Rack。比如说你有杭州、成都两个矿场每个矿场各有 3 个机架那么矿机的层级关系就是杭州矿场 A 机架 worker-01。这个层级的价值在告警里体现得最明显。当服务端检测到某个机架下超过 70% 的矿机同时离线时它会触发一条机架级离线告警而不是给这几十台机器每台各发一条离线告警。这就是合并告警的逻辑遵循的是金字塔式的告警收敛原则底层的问题归到底层顶层的机房断电、断网永远不应该造成告警风暴。实际运维中机架分组还帮了我一个大忙。有一次某个机架的供电空气开关跳闸机架里 14 台机器全部离线。如果是老系统我的手机在 5 分钟之内会收到 14 条告警openrig 直接把告警收敛成了 1 条杭州矿场-B机架14 台矿机离线同时还帮我对比了相邻机架的状态确认是机架级供电故障而不是矿场整体断电。这个信息对于远程判断故障范围非常重要。4.4 告警规则配置示例告警规则配置在后台管理页里操作规则由五个要素组成指标类型、比较方式、阈值、持续时间、沉默时间。我给出我们矿场实际用的几个标准规则可以直接参考告警名称指标触发条件持续时间沉默时间算力偏离告警总算力低于标称算力 15%3 分钟30 分钟显存高温告警显存温度高于 80°C2 分钟30 分钟温升过快告警显存温度变化速率高于 2°C/min1 分钟60 分钟矿机离线告警心跳心跳超时 5 分钟即时30 分钟机架离线告警矿机存活率低于 30%1 分钟60 分钟这里我要特别讲一下算力偏离告警的持续时间和阈值选择。算力本身是有一个正常波动的比如某台矿机标称 100MH/s实际上在 96 到 104 之间跳动都是正常的PPLNS 模式下单看某一次采样根本没有意义。所以算力告警必须盯持续了多久的偏差而不是一次采样偏差。持续 3 分钟这个值是我在实测中试出来的低于 3 分钟重启矿机软件时的瞬时算力归零也会误触发高于 5 分钟又会让一些本可以快速恢复的卡顿白白损失算力。阈值 15% 同样需要根据矿机的稳定性调整体质好的机器 8% 以下就该报警而双卡主板经常掉驱动的平台20% 也不一定说明有问题。4.5 仪表盘数据解读与日常巡检仪表盘不是装完看一眼就完事的它应该成为每天固定巡检的地图。我自己的巡检习惯分成三个时间尺度每小时扫一眼总览页确认总算力曲线没有台阶式跳水每天上班后看一遍所有矿机列表按算力偏离率排序优先处理最偏离的机器每周导出一次历史指标看各机架风扇转速、温度数据的长周期变化提前判断有没有散热老化的趋势。总览页里有一个算法我花了不少心思实时算力对比。它不是简单地把所有矿机当前算力加总而是按照每台矿机的标称算力基线加权计算出一个动态偏差率。这个偏差率比绝对算力有意义得多因为它统一了不同型号的矿机。偏差率长时间在 1% 以下说明矿场整体状态很好一旦偏差率持续走高即使总算力数字还没明显下跌我也知道系统里已经有新问题在酝酿了。5. 生产环境中的常见问题与排查实录5.1 Agent 频繁掉线是网络还是软件问题这是我在部署初期遇到的最多的一个问题。Agent 总是运行一段时间后就不再上报心跳但是矿机本身算力正常SSH 也能连上。排查了几次之后发现问题出在矿场网络的 MTU 设置上。部分交换机默认 MTU 是 1500而某些矿机内置网卡连接的路径上经过了几层交换和中继出现丢包。这事让我养成了一个习惯任何监控系统出现周期性的心跳中断先把网络链路排一遍再查软件。心跳中断往往呈现出很有规律的周期性比如每 30 秒丢一个包这种特征说明基本不是程序 bug而是某个网络节点的策略或者性能瓶颈。排查手段也简单在服务端记录 Agent 每次上报的网络耗时。openrig 的心跳数据结构里本身就带了一个rtt_ms字段反映从 Agent 发起 HTTP 到服务端响应的时间。如果服务端里大部分心跳的 rtt 都异常偏高网络层面一定有问题。5.2 数据库写入压力与数据缺口一台矿机 30 秒一条数据可能没什么感觉但是几十台矿机同时上报服务的写入压力就不小了。早期我用的是同步写入方式Agent 每上报一次服务端就老老实实往 SQLite 里写一行。后来矿机数量上到 50 台左右偶尔会出现服务端响应变慢、Agent 侧开始积压数据的问题最直接的后果是图表上出现一段数据缺口。解决方式是改成了批量异步写入。Agent 上报的数据先落到服务端内存缓冲区攒够 100 条或者每 10 秒批量刷一次盘二次整理成一次事务写入 SQLite。这个改动让单机支撑的矿机数量翻了几倍而且对数据实时性几乎没有影响毕竟 10 秒的写入延迟在监控场景里完全可以接受。这里我建议部署时直接关注三个指标服务端 CPU 负载、SQLite 写入耗时、Agent 上报响应时间。只要这三项平稳数据库一般不会成为瓶颈。5.3 自动重启误触发的阈值调参经验自动恢复功能是一把双刃剑。有一次我调整了算力告警的阈值结果把自动重启也牵连了进去。现象是某台矿机的算力因为矿池网络波动出现了 2 分钟的短暂下降随后自动恢复到了正常水平但就是这 2 分钟触发了假死判断Agent 直接重启了矿机软件白白损失了几分钟算力。后来我把自动重启的判断逻辑加了两个前置条件算力必须连续下降且完全归零同时 miner API 在 90 秒内没有恢复响应这两个条件同时满足才触发进程重启。只满足其中一个宁愿多观察一轮也不要贸然重启。这个改动看似保守实际效果很好因为它把矿池网络抖动这种外部因素导致的问题和软件卡死这种真实故障区分开了。5.4 告警风暴一次线缆虚接引发的连锁反应一个让我印象深刻的故障案例是这样的机架顶部的交换机电源线虚接导致交换机间歇性断电机架上 10 台矿机的网络时不时的断开重连。由于网络断开的时间非常短大概只有十几秒矿机和服务端之间还没到 5 分钟的心跳超时阈值所以矿机离线告警没有触发。但因为矿机软件和矿池之间同样断断续续各台机器的算力图开始疯狂出现锯齿算力偏离告警一条接一条地发出来我的手机 20 分钟内收了 30 条告警。事后我把这次故障复盘成了两条优化第一告警沉默时间从 30 分钟收缩到 15 分钟同时加了相同矿机同类告警自动折叠的逻辑同一个 worker 在沉默窗口内只保留最新一条告警第二引入了机架级网络健康度指标把同一个机架下所有矿机的 TCP 重传率、ping 延迟平均值聚合起来一旦全机架网络指标整体异常直接触发一条机架级告警避免下面 10 台机器各自报警。5.5 常见问题速查表现象可能原因排查与处理Agent 周期不掉线网络 MTU 问题/交换机策略先检查网络延迟趋势再查交换机端口配置算力图出现数据缺口服务端 SQLite 写入瓶颈确认是否已启用批量异步写入检查磁盘 IO温度曲线突然跳变卡索引对不上检查 PCI 槽位序列号是否匹配重启矿机后是否恢复自动重启误触发告警阈值太灵敏加长持续观察时间或增加API 无响应前置条件告警重复轰炸沉默时间过短调大沉默时间开启同机同类告警折叠服务端重启后集体离线圈离线检测未规避启动窗口确认已启用启动后冷却时间配置6. 使用 OpenRig 几个月的真实体会项目做到这一步最大的收获不是少跑了几趟机房而是让我重新理解了监控系统的本质。监控的价值不在于看到状态而在于缩短发现问题和定位问题的链路。一套好的矿机监控系统应该让运维者从一堆原始数据里快速跳转到故障判断而不是把图表做得密密麻麻然后让人肉眼看。有两点实践经验我想单独拎出来说。第一点是关于告警规则的克制。新手往往倾向于把每个指标都设上告警结果告警一多人就麻木了真正重要的告警反而淹没在噪音里。我的原则是一个指标如果触发告警后你从来没有根据它去采取过行动就把它删掉。规则越少每条规则的可信度越高看到告警时做出的响应动作也越果断。第二点关于 Agent 的更新策略。做开源项目最怕的就是版本不统一各台机器的 Agent 千奇百怪出了问题都没法稳定复现。我后来把 Agent 更新做成了服务端统一下发后台发布新版本后服务端会给所有在线 Agent 推送更新指令Agent 校验完哈希之后自动替换二进制并重启服务。整个更新过程不需要登入任何一台矿机这也成了我把更多机器接入 openrig 管理的底气。如果后续还要扩展我准备了两个方向一是把历史指标导出对接进 Prometheus 生态用 Grafana 做更深度的可视化分析二是增加电费成本核算模块把矿场每台机器的电表读数自动录入按矿机和机架统计单位算力的电费成本。这些功能点其实都来自日常运维中的真实痛点等实现好之后我应该还会有新的经验可以写出来分享。最后分享一个小技巧收尾如果你也是刚开始搭建矿机监控不要一上来就追求把所有功能都配齐先把心跳、算力、温度这三类数据接住跑一个星期稳定了再逐步加自动重启和告警提醒。一个监控系统在投产初期的稳定性比功能全面重要得多。
