Uptime

假设一台机器在 23 小时内满足了我们的运行条件，而整个观察期为 24 小时。在这个自拟例子中，uptime 约为 95.83 %。如果把维护的一小时从观察期排除，百分比就会改变，尽管机器实际做的事情没变。因此，例外规则必须公开。美国国家标准与技术研究院（NIST）将可用性与能够使用服务或信息联系起来，并没有提供统一的挖矿百分比。应先定义服务和时间，再评价数字。 [1]

Hashrate 是每秒进行的挖矿尝试次数。Braiins 在 2026 年的说明中区分 Worker System Uptime 和 Worker Hashing Uptime。前者统计设备是否响应，后者统计 hashrate 大于零的时间段。因此，即使计算停止，也可能打开控制页面。反过来，有少量计算也不代表达到厂家标称性能。这两种读数应该结合看：一个反映可访问性，一个反映工作，但都不能独自解释整个结果。 [2]

Braiins Manager 在没有必要数据时使用 Unknown。Agent Offline 表示负责收集和传送数据的代理服务没有响应。这本身不能证明挖矿停止：可能只是监控故障，而机器仍在工作。同样，也不能自动把这段空白算成正常运行。应把未知时段单独列出，或者明确说明它如何进入计算。否则，相同的数据缺口可能在不同面板上造成相反印象。 [3]

Mining Pool 汇集矿工的工作，并按自己的规则分配奖励。设备不会提交每次尝试，而是提交符合矿池较容易目标的部分结果，称为 shares。Braiins Pool 据此估计有效 hashrate。短时间内，找到 shares 的随机性和连接质量都会影响这个数。矿池读数较低，不能直接换算成同比例的停机。应先比较相同时间段，再检查矿池是否收到并接受了工作。 [4]

在 Braiins Pool 的监控中，Offline 表示未检测到 hashrate，并不是直接检测机器网络是否可达。文档说明，每 5 分钟记录一次快照；从 OK 变成 Low，需要连续两个期间低于设置的阈值。Disabled 则表示监控关闭，而不是挖矿停止。因此，红色或灰色标签只是调查起点，不是完整诊断。另一个工具即使使用相同名称，也可能有不同定义。 [5]

Braiins Manager 面板文档规定每 5 分钟刷新数据，但按时间排列的测量数据（时间序列）有 20 分钟延迟。刷新屏幕的时刻，不等于所显示事件的时刻。排查警报时，图表最后一点可能还没反映我们的处理或当前状态。下结论前，应检查事件时间、时区和数据点距今多久。这些间隔属于所引用的文档，并非所有监控工具的共同特性。 [6]

Curtailment 是有意限制运行，例如因为电价高，或电网提出要求。Braiins 解释了为什么此时较低的 hashing uptime 不一定意味着技术故障。报告应区分计划限制、维护和意外故障。它们都可能减少计算时间，却需要不同决策。更高的 uptime 也不能单独证明利润更高：电价、性能和被接受的工作同样重要，而不仅是开机时数。 [2]

Worker 是矿池用来记录工作的名称。Braiins Pool 提醒，多台设备共用名称时会被合并监控，不能只凭合计值诊断每一台。这个例子对两台机器采用相同的观察期。每台机器的权重，就是它的标称 hashrate 占两台合计值的比例。在我们的例子中，两台机器分别为 100 TH/s 和 200 TH/s，即每秒万亿次尝试的数量，uptime 分别为 100 % 和 50 %。简单平均为 75 %，按标称 hashrate 加权则为 66.67 %。性能更强的机器停机，权重更大。这个平均值仍不测量被接受的 shares，只是换一种方式汇总运行时间。因此必须说明采用的权重。 [5]