挖矿监控与告警：如何在几分钟内而不是一整天后发现停机

矿场停机几乎从来都不会显得很戏剧化。灯不会灭,也不会冒烟。只是在某个时刻,部分设备停止提交share,而你要到第二天早上才会发现,因为收益比昨天少了。这时候钱已经损失了,而且无法挽回:网络不会为你追溯重新计算份额。

下面我们分析为什么矿池仪表盘不适合当作告警系统,哪些指标能提前预警故障,以及如何用手头已有的工具搭建一套简单的告警。

一小时停机的代价是多少

按任何收益计算器都在用的公式来算:

\`\`\`

每日BTC = (算力 × 86400) / (难度 × 2^32) × 3.125

\`\`\`

这里86400是一天的秒数,2^32来自难度的定义,而3.125 BTC是当前的区块补贴(数据取自我们2026年9月8日的网络快照)。

代入难度127.45万亿(mempool.space,2026年9月8日)和汇率78,349美元:

算力	日收益	一小时停机成本	一天停机成本
100 TH/s	3.86 $	0.161 $	3.86 $
1 PH/s	38.6 $	1.61 $	38.6 $
10 PH/s	386 $	16.1 $	386 $

该计算为毛收益,未扣除矿池手续费和电费,也未计入交易手续费(据mempool.space在2026年9月8日的数据,在4320个区块的窗口内,交易手续费为区块奖励增加了0.66%,量级上几乎不改变结论)。

再往下就是简单的算术。凌晨一点发生故障,下午一点才发现。十二个小时,矿场算力10 PH/s:大约损失193美元,这些钱永远不会出现在收益里。如果每月发生一次这样的巧合,一年下来即便设备完全正常运转,你也要损失超过两千美元。

为什么矿池仪表盘不能替代监控

简单来说:矿池显示的不是你设备的状态,而是到达矿池的share流的状态。从断线到仪表盘状态更新之间会有几十分钟的延迟,因为矿池必须把真正的故障和普通的网络中断区分开。AntPool对此有官方规定:矿机在20分钟没有提交share后状态变为Inactive,而只有在静默24小时后才会变为Invalid(AntPool support, Worker Management)。

二十分钟按10 PH/s算已经是5.4美元,而这还是最好的情况:矿机整体掉线,状态也确实发生了变化。如果机器还在工作,但产出减半,状态依然是绿色的,矿池什么都不会告诉你。

还有第二个原因。矿池仪表盘上的算力不是测量值,而是根据平均窗口内接受的share数量做出的估算。每个矿池的窗口长度不同,文档中也不总是写明。窗口越短,曲线波动越大;窗口越长,对真实下降的反应就越滞后。

其他矿池的延迟和阈值请以其自身文档为准:我们只找到AntPool有官方确认的数字,不能把它套用到其他矿池上。

三个观察层级

可以在三个地方进行观察,每个地方看到的都是全局的一部分。

层级	能看到什么	看不到什么	典型延迟
矿机本身(网页界面、本地API)	板卡和芯片温度、风扇转速、各算力板的本地算力、被拒绝的share、重启情况、芯片故障	路由器之外与矿池的连接是否中断、share是否被计入	数秒
网络与电力(路由器、UPS、场地传感器)	网络中断、断电、场地内温湿度	具体某台设备内部发生了什么	数秒
矿池统计(仪表盘、账户API)	被接受的share、有效算力、矿机状态、收益结算	问题的原因和硬件状态	从几分钟到几十分钟不等,参见上面的AntPool示例

没有哪个层级是自给自足的。矿机会诚实地报告过热,但如果你的运营商切断了到矿池的路由,它不会知道。矿池能看到share消失,但存在延迟且不会说明原因。电力传感器会立即触发,但分不清是设备被关掉还是卡死了。

最低限度的工作配置是第一层和第三层:本地数据用来查原因,矿池数据用来确认工作确实被结算了。

哪些指标能提前预警故障

直接回答是:被拒绝share的比例、本地算力与矿池算力之间的持续偏差、芯片温度以及重启计数器。这四个数字会在设备完全停机之前先发生变化,给你留出在停机彻底发生前介入的时间。

拒绝率(reject rate)。拒绝比例上升几乎总是网络问题:丢包、路由器过载、到矿池服务器的路由不佳。不要看别人文章里的标准,而要看自己设备在平静一周内的数据:每一套设备加运营商的组合,标准都不一样。
本地算力与矿池算力之间的差距。下面有单独一节讲这个,因为这里最容易引起不必要的恐慌。
芯片温度和风扇转速。积灰的散热片会让温度逐渐升高。设备会先自己悄悄降频,收益在不知不觉中减少,然后才会进入保护状态。这个悄然退化的阶段,正好可以用温度阈值很好地捕捉到。
正常运行时间计数器。如果设备的运行时间经常被重置,说明你有矿池不会告诉你的重启事件:重启之间share照常提交、状态一直绿色,但总产出却更低。
正常工作的算力板数量。三板机中掉线一块板,意味着在仪表盘上矿机完全"存活"的情况下,收益却少了三分之一。

为什么矿池显示的数值总是低于矿机自身

直接回答是:矿机显示的是自己计算出来的哈希尝试速度,而矿池显示的是根据接受到的share反推出来的估计值。后者是统计量,因此会有波动,而且平均来说会更低:一部分工作量花在了被拒绝和延迟到达的share上,还有一部分在窗口取整时被损失了。

实际经验法则很简单。几个百分点、在一天之内上下波动的偏差,属于正常的抽样方差,不是故障。真正的信号看起来不一样:矿池算力持续下降并且停在低位,而本地算力却没有变化。这种情况说明设备在正常计算,但结果没有到达矿池,或者没有被计入。

对你自己这套设备而言,多大的偏差算正常,没人能替你回答。收集自己在平静一周内的数据,算出矿池算力与本地算力的平均比值,以它为基准。下面提到的所有阈值也应该这样确定。

如何在不用第三方服务的情况下搭建告警

你需要一台能24小时运行、能发HTTP请求的设备:家用小型服务器、能跑脚本的路由器,或者一台旧笔记本电脑。接下来是两个数据来源。

矿机这一侧。ASIC的网页界面会提供当前算力、温度、风扇转速、运行时间、算力板状态和拒绝计数。很多固件还通过本地API或管理socket提供机器可读的同样数据。具体地址和格式因厂商和固件版本而异,请查阅你所用型号的文档。

矿池这一侧。部分矿池提供账户API,可以通过个人中心的密钥获取矿机算力和状态。是否提供API、格式以及请求限制各矿池不同,需要在对应矿池的文档中核实:这里没有统一标准,我们也没有验证过我们报告中未提及范围之外的接口。

脚本逻辑其实只需要十来行:每分钟轮询矿机一次,每隔几分钟轮询矿池一次,把数值与阈值比较,一旦超标就发消息给即时通讯工具或邮箱。另外别忘了反向情况:如果脚本本身超过半小时没有响应,说明是脚本挂了,不是矿场出了问题。一个沉默的监控是最糟糕的监控,因为它会给人一种"一切都在掌控中"的错觉。

阈值该设多少才不会被误报淹没

直接回答是:不要依据单次测量,而要依据连续多次测量。寻找share本身就是一个随机过程,即使矿场完全正常,曲线也会出现短暂的波谷。阈值应该要求异常持续若干个轮询间隔,否则你每小时都会收到告警,很快就会不再看它们。

一个实用的方案是这样的:

矿机完全静默。本地轮询连续两次没有响应。这已经不是方差问题了,应该立即处理。
算力下降。数值低于你的正常水平,并且连续若干次测量都保持在低位。具体低多少、连续几次,根据自己平静一周的历史数据来定。
温度。阈值取自你所用型号厂商的文档,把告警设在保护性关机触发温度之下留有余量的位置,以便有时间反应。
被拒绝的share。与自己平时的基准水平比较,而不是与网上某个绝对数字比较。
矿池沉默。有用,但要记住延迟:AntPool的官方Inactive状态也要20分钟后才出现。这类告警总会比本地告警来得晚。

还有一条规则:每条告警触发后都应该有一段静默期。否则凌晨三点的一次故障,到早上就会变成四十条一模一样的消息,你要花时间清理通知,而不是处理矿场问题。

另外要单独想清楚,触发的那一刻该做什么。如果矿场不在你家,一个无法远程处理的告警只会毁掉你的一整晚。这就牵涉到备用矿池的话题:有些故障根本不是硬件损坏,而是矿池那一侧或到矿池路由上的问题,自动切换就能解决,不需要出门。关于设置备用地址的问题我们另有专门文章。

一个晚上就能完成的清单

用上面的公式算出你自己一小时停机的成本。一个数字就能让后面所有的折腾变得有意义。
收集基准线:平静的一天内的本地算力、矿池算力、温度、拒绝比例。
确认你的固件是否提供机器可读的数据,并记下地址。
查阅你所用矿池的文档,确认是否有账户API以及有什么限制。
写一个脚本,每分钟轮询一次矿机,把结果写入文件或简单的数据库。
设置四条告警:无响应、算力下降、温度、拒绝率上升。
为每条告警加上触发后的静默期,并加入对监控脚本本身沉默的防护。
做一次真实测试:从一台设备上拔掉网线,记录消息多久后到达。
如果矿机设置里还没有备用矿池地址,现在就填上。
一周后,根据积累的数据重新审视阈值。第一次设置的阈值几乎从来都不是准的。

第八条是最常被跳过的一步,但它是唯一能证明整套系统真的在起作用的一步。