FOMC 与 PCE 前的矿场值班：HiveOS 告警要先做一次减噪

这两天市场的注意力又被宏观事件拉走。FOMC 纪要、PCE 数据、美日央行表态、美伊协议分歧，这些新闻看起来离矿机很远，但对矿场并不远。行情波动一大，币价、矿池收益、矿工切换策略都会跟着变，运维人员也更容易在短时间内频繁看面板、改参数、切矿池。

越是这种时候，HiveOS 面板上的告警越不能乱。

很多矿场平时装好了 HiveOS，能批量看算力、温度、离线状态，就觉得系统已经够用了。真正到行情波动、人员紧张、机器负载变化的时候，问题往往不是没有告警，而是告警太多、太碎、太像噪音。手机一晚上响二十次，最后真正掉线的那一次反而没人第一时间处理。

今天这篇不谈怎么装 HiveOS，也不重复讲批量配置，而是说一个更容易被忽视的事：矿场要在波动周之前，把 HiveOS 告警体系重新梳理一遍。

告警太多，最后等于没有告警

HiveOS 的好处是信息足够集中。矿机是否在线、GPU 温度、风扇转速、算力波动、矿工软件状态、无效份额、重启记录，都能在一个面板里看见。问题也在这里：如果所有异常都用同一个级别推送，运维人员很快就会麻木。

比如一台机器因为网络抖动短暂掉线 30 秒，推一次；某张卡温度从 62℃ 到 70℃，推一次；矿池延迟从 80ms 到 200ms，推一次；算力短时下降 5%，又推一次。看起来系统很勤快，实际上是在消耗人的注意力。

矿场最怕的不是面板没有红点，而是红点没有优先级。真正要命的故障，比如整排机器断网、电源异常、风扇停转、温度连续上冲、矿工进程反复崩溃，应该第一时间被看见；而那些短时波动、低影响异常，更适合进入观察队列。

告警系统如果不分层，到了宏观数据公布前后，行情软件、交易群、矿池通知、HiveOS 推送一起响，运维很容易误判。有人忙着看收益变化，有人忙着调功耗，真正的硬件问题可能就被压在一堆“轻微波动”里。

一个小矿场的夜间误判

前阵子有个小矿场做了一次复盘，规模不大，180 多张 GPU，机器分在两个房间。之前他们在 HiveOS 里开了比较多的提醒：掉线提醒、低算力提醒、高温提醒、矿工重启提醒、无效份额提醒，基本能开的都开了。

问题出在一个凌晨。那天刚好币价波动比较大，矿池端收益显示也有延迟。夜班手机从 12 点开始陆续收到十几条低算力提醒，大部分是单机短时算力低于设定值。值班人员看了几次，发现过几分钟又恢复，就判断为矿池波动，没有逐台处理。

凌晨 3 点左右，其中一个机架的交换机电源接触不稳，导致十几台机器间歇离线。HiveOS 也推了离线提醒，但夹在此前大量低算力提醒中间，值班人员以为还是同一类波动。等早上现场人员到场，才发现这排机器实际掉了接近 4 个小时。

这件事不是 HiveOS 没提醒，而是提醒没有被设计成“让人马上分辨轻重”的样子。

后来他们做了三件事：第一，把短时低算力提醒的触发时间拉长，不再 1 到 2 分钟就推；第二，把整机离线、温度持续过高、矿工连续重启单独设为高优先级；第三，夜间只推高优先级告警，低优先级统一早上看日报。调整之后，手机响的次数少了，但真正需要处理的问题反而更容易被抓住。

HiveOS 里先分三类，不要一把抓

矿场可以先把 HiveOS 告警分成三类，不需要复杂，但必须清楚。

第一类是立即处理类。比如矿机离线超过设定时间、整组机器同时失联、温度持续超过安全阈值、风扇异常、矿工软件连续崩溃、电源或网络导致的集体掉线。这类告警应该走最强提醒，最好不只推给一个人，夜间也不能静音。

第二类是观察跟踪类。比如单机算力短时下降、某张卡温度略高、无效份额短时间增加、矿池延迟波动。这类问题需要记录，但不一定要马上把人叫醒。可以设置更长的触发周期，比如连续 10 分钟、15 分钟仍未恢复，再升级提醒。

第三类是日报复盘类。比如某些机器一天内重启次数偏多、温度长期比同组机器高、算力波动幅度大但没有掉线、某个版本矿工软件报错次数增加。这些更适合白天处理，和清灰、换线、降压、版本调整放在一起看。

HiveOS 本身提供了足够多的状态数据，但矿场要把这些数据变成可执行的告警规则。否则面板越丰富，人越累。

阈值别照搬，先看自己矿场的“正常波动”

很多人设置 HiveOS 告警时喜欢照搬别人的参数，比如温度超过多少就提醒、算力掉多少就提醒、离线多久就提醒。这个方法省事，但不一定适合自己的场地。

不同矿场的“正常波动”差别很大。南方潮湿环境、北方干燥环境、白天高温机房、夜间低温机房、独立宽带、共享网络、老卡、新卡，表现都不一样。你拿别人稳定机房的阈值套在自己这里，可能天天误报；拿别人宽松阈值套在高温机房，又可能漏报。

更稳妥的做法，是先用 3 到 7 天观察自己的基线。看每组机器平时温度大概在什么区间，算力正常波动是多少，矿池延迟的常态范围是多少，哪些机器本来就比同组更热。把这些基线摸清楚，再设告警才有意义。

比如同一批显卡，大多数卡在 58℃ 到 66℃，只有某几张长期 72℃，那就不要简单把 75℃ 当成唯一红线。长期高于同组平均值的机器，哪怕没到绝对高温，也应该被列入巡检名单。HiveOS 面板里这些差异很容易看出来，关键是矿场有没有定期拿来复盘。

波动周更要减少临时改动

宏观数据公布前后，矿工最容易做一件事：临时改配置。看到收益变化，想切币；看到矿池延迟，想换池；看到温度变化，想改功耗；看到群里有人说某版本更稳，又想升级矿工软件。

这些操作本身没有问题，但如果和告警混在一起，很容易制造新的噪音。你刚改了超频参数，HiveOS 推低算力；刚换了矿池，推无效份额；刚升级软件，推矿工重启。到底是市场波动、矿池问题，还是你自己改出来的问题，现场很难判断。

所以波动周更要减少临时改动，或者至少把改动记录清楚。哪一组机器在几点改了什么参数，换了哪个矿池，升级了哪个版本，最好在 HiveOS 的标签、备注或内部工单里留下痕迹。这样告警出现时，运维能马上知道它是不是和刚才的操作有关。

特别是多人管理的矿场，最怕 A 改了参数，B 收到告警，C 去现场排查，三个人信息不一致。HiveOS 能让机器集中管理，但管理动作本身也要集中记录。

手机推送之外，还要有值班路径

很多矿场的告警体系只有一层：HiveOS 推到手机。这个做法适合小规模机器，但机器一多，就不够了。

更合理的方式是给不同告警设置不同值班路径。高优先级告警推给当班人员和负责人；中优先级告警进入群消息或看板；低优先级告警进入次日清单。现场人员、远程运维、老板看到的信息不必完全一样，否则所有人都会被同一批噪音打扰。

另外，告警收到之后要有固定动作。比如离线告警先看是否整组掉线，再看是否单机掉线；整组掉线优先查交换机、路由、电源；单机掉线再看主板、电源、系统状态。高温告警先看风扇转速和环境温度，再决定降功耗还是现场处理。低算力告警先确认矿池端是否同步异常，再判断是否重启矿工。

有路径，告警才不是一句提醒，而是能把人带到下一步。

给 HiveOS 矿场的今日建议

今天如果矿场正在用 HiveOS，可以先做一次轻量整理，不用大动干戈。

先把最近 24 小时的告警翻一遍，看看哪些提醒重复最多、哪些提醒最后证明没有处理价值。把这部分阈值调宽，或者改成连续触发后再推送。

再把真正影响收益和安全的告警单独列出来：整机离线、整组失联、持续高温、风扇异常、矿工连续崩溃。这几类要保证夜间有人能收到，而且收到后知道先查哪里。

最后，宏观数据密集的这几天，尽量少做无记录的批量改动。要切矿池、改超频、换版本，都留一句备注，至少让后面排查的人知道发生过什么。

HiveOS 的价值不只是把机器显示在一个面板里，更重要的是让矿场在信息很乱的时候还能分清轻重。告警少一点、准一点、路径清楚一点，很多停机损失其实可以提前挡住。