信号

每种监控类型都有一个或多个信号。一个信号检查一个条件，例如缺失的 FTSO commit，或低于您设定阈值的积分余额。在监控编辑器的 3. 信号部分，您可以开启或关闭每个信号、开关其恢复通知，并修改其参数。“恢复默认设置”会还原标准值。

信号属于不同的信号组，例如 FTSO、FDC 或余额。信号组对路由很重要，因为您可以把某个信号组发送给与其他信号不同的接收者；参见接收者与路由。

下方参考中的每个信号都回答四个问题：检查什么、为什么重要、常见原因，以及您可以怎么做。在应用中点击信号旁的信息图标时，也会显示相同的文字。

几乎所有信号默认都是开启的，并会发送恢复通知。例外情况在下方参考中有标注。提供商监控的“监控可用性”信号始终开启，无法关闭，因为它会在监控本身无法进行时通知您。

部分提供商信号带有“连续轮次”参数。它可以避免单次迟到或缺失的提交在夜里把您吵醒。默认值为 2。

默认值为 2 时的示例：

• 轮次 1000：缺少 commit。连续第一轮，暂不发出警报。
• 轮次 1001：再次缺少 commit。连续第二轮，发出警报。
• 轮次 1002：commit 按时到达。如果恢复通知已开启，则发送恢复通知。

如果轮次 1001 正常，则什么都不会发送。警报处于活动状态期间，后续的异常轮次不会再次发送该警报；每个事件只收到一条警报，而不是每轮一条。如果您想知道每一次缺失，请将该值设为 1。

恢复通知告诉您状态已恢复正常。它会发送给与警报相同的接收者。如果您只关心问题，可以按信号关闭恢复通知。

冷却时间是每个监控单独的设置，名为“提醒之间的最短间隔”。它会在该时间内屏蔽同一事件的重复警报，但绝不会屏蔽其他事件，例如恢复通知。详细说明见消息与免打扰时段。

当 Watchdog 无法读取某个值时，例如因为数据源延迟，它不会把这种情况视为正常。没有证据的轮次会打断连续的异常轮次，但绝不会触发恢复通知。对于提供商监控，当分析器数据超过 10 分钟未更新时，“监控可用性”信号会通知您；在此期间，该监控的其他提供商警报会暂停，而不是靠猜测判断。

1. 打开您的监控项，在该监控上选择“编辑”。
2. 打开 3. 信号部分，展开您要修改的信号组。
3. 开关信号或其恢复通知，或修改参数。如果某个值超出范围，该部分会显示“请检查本节的值。”，在您修正之前无法保存。
4. 保存。修改从下一次检查开始生效。

所选监控目标及阈值的事件。

余额变动

配置的钱包余额变动超过阈值时通知。

• 检查什么？将余额与上次观测比较，指定方向的绝对变化达到阈值时告警；首次观测建立基线。
• 为什么重要？余额变化可能表示你想跟踪的转入或转出。
• 常见原因：观测之间发生了转账、gas 费用或其他余额变化。
• 可以怎么做？将观测金额与近期钱包交易及配置代币对照。
• 信号已启用：开启

所选监控目标及阈值的事件。

价格波动

配置的喂价波动超过阈值时通知。

• 检查什么？将当前 USD feed 价格与窗口内最早有效点比较；达到百分比阈值时每窗口最多告警一次，达到双倍阈值为严重。
• 为什么重要？观测到的大幅价格变化可能值得关注。
• 常见原因：当前喂价与所选窗口内较早有效价格不同。
• 可以怎么做？比较时间戳和价格，检查窗口及百分比设置。
• 信号已启用：开启

所选监控目标及阈值的事件。

提供商状态

提供商被取消注册或失去资格时通知。

• 检查什么？建立基线后报告注册或资格丧失及恢复；数据集中缺失的提供者视为未注册且无资格。
• 为什么重要？未注册或不符合资格的提供商，在该奖励周期内无法为委托者获得奖励。
• 常见原因：错过了注册，或未满足某项最低条件且没有剩余 pass。
• 可以怎么做？在 Flare Systems Explorer 中检查提供商的最低条件和 passes，以及当前周期的注册情况。
• 信号已启用：开启
• 发送恢复通知：开启

所选监控目标及阈值的事件。

Credits 余额不足

你的 Credits 余额低于配置的阈值时通知。

• 检查什么？钱包 credit 余额严格低于阈值时告警；恢复包括等于阈值。
• 为什么重要？信用余额不足可能影响消耗信用的服务。
• 常见原因：信用支出或调整可能使余额低于所选阈值。
• 可以怎么做？检查信用余额及近期记录，再按需调整阈值或补充。
• 信号已启用：开启
• 发送恢复通知：开启

所选监控目标及阈值的事件。

奖励签名

通知尚未完成、逾期或错过的在线率和奖励签名。

• 检查什么？检查刚结束周期缺失的 uptime 和 reward 签名；周期结束或首次观测奖励数据发布两小时后提示，十二小时后提醒；投票已结束且未签名则严重。
• 为什么重要？所需提供者签名可能待提交，或已错过结束的投票。
• 常见原因：身份地址未出现在 Uptime 或奖励数据的观测签名者集合中。
• 可以怎么做？检查配置身份的周期、投票状态及签名流程。
• 信号已启用：开启
• 发送恢复通知：开启

FTSO 投票轮次中的 commit、reveal 和签名参与。

FTSO 提交

连续轮次缺少提交或提交过晚。

• 检查什么？检查连续投票轮次中缺失或迟到的 FTSO commit。
• 为什么重要？没有有效的 commit，你的数值就不会计入该投票轮次，因此会失去该轮接近中位数的奖励。错过的轮次也会影响锚定 feed 最低条件的达标情况（每个奖励周期中，80% 的轮次须在中位数的 0.5% 范围内）。
• 常见原因：FTSO 客户端或 Flare System Client 已停止或正在重启、C-chain 索引器落后于链头、RPC 问题，或提交地址的原生代币余额不足。
• 可以怎么做？检查系统客户端是否每轮都记录“Submitter submit1 successfully sent tx”，索引器是否已同步至链头，以及提交地址是否有足够资金。
• 信号已启用：开启
• 发送恢复通知：开启
• 连续轮次：默认值 2 (1–20)。 连续异常投票轮数；2 会忽略单次故障。缺少证据会重置连续计数，但不证明恢复。

FTSO 揭示

连续轮次缺少揭示，或揭示过早、过晚。

• 检查什么？检查连续投票轮次中缺失、过早或迟到的 FTSO reveal。
• 为什么重要？有 commit 却没有匹配的 reveal 会受到处罚：你的数值将被排除，该轮奖励会减少或取消。缺少 reveal 也会使你的随机数无法参与该轮。
• 常见原因：客户端在 commit 与 reveal 之间重启，reveal（submit2）发送过晚，或提交地址的资金已耗尽。
• 可以怎么做？检查所报告轮次的 submit2 交易、日志中 commit 与 reveal 的时间间隔，以及客户端是否在两者之间重启。
• 信号已启用：开启
• 发送恢复通知：开启
• 连续轮次：默认值 2 (1–20)。 连续异常投票轮数；2 会忽略单次故障。缺少证据会重置连续计数，但不证明恢复。

FTSO 签名

连续轮次缺少签名或签名过早。

• 检查什么？检查连续轮次中缺失或过早的 FTSO 签名；错过宽限期由另一信号检查。
• 为什么重要？只有及时到达且针对已最终确认的 Merkle root 的签名才能获得签名奖励。缺少签名会失去这部分奖励，也无法帮助该轮完成最终确认。
• 常见原因：签名步骤（submitSignatures）失败或延迟、无法计算 Merkle root，或签名提交地址资金不足。
• 可以怎么做？在系统客户端日志中查找“Submitter submitSignatures successfully sent tx”，并检查签名提交地址的余额。
• 信号已启用：开启
• 发送恢复通知：开启
• 连续轮次：默认值 2 (1–20)。 连续异常投票轮数；2 会忽略单次故障。缺少证据会重置连续计数，但不证明恢复。

FDC bitvote、签名及与共识请求的一致性。

FDC 位投票

连续轮次缺少位投票，或位投票过早、过晚。

• 检查什么？检查连续投票轮次中缺失、过早或迟到的 FDC bitvote。
• 为什么重要？没有及时的 bitvote，就无法参与该轮的 FDC 共识。FDC 最低条件要求每个奖励周期中成功参与 60% 的投票轮次。
• 常见原因：FDC 客户端或验证器不可用、证明数据源（例如 BTC、DOGE 或 XRP 节点）未同步，或 bitvote 在选择阶段之外发送（该阶段为轮次开始后的 90–135 秒）。
• 可以怎么做？检查 FDC 客户端日志、每个验证器的 /health 端点，以及 bitvote 交易是否在选择阶段内上链。
• 信号已启用：开启
• 发送恢复通知：开启
• 连续轮次：默认值 2 (1–20)。 连续异常投票轮数；2 会忽略单次故障。缺少证据会重置连续计数，但不证明恢复。

FDC 签名

连续轮次缺少签名或签名过早。

• 检查什么？检查连续投票轮次中缺失或过早的 FDC 签名。
• 为什么重要？只有提交正确的 Merkle root 才算参与 FDC。没有你的签名，该轮就不计入 60% 的要求，你也会失去该轮签名奖励。
• 常见原因：无法构建或签署 FDC Merkle root、验证器数据不完整，或签名提交地址资金不足。
• 可以怎么做？检查 FDC 客户端和验证器健康状态，以及所报告轮次的 submitSignatures 交易。
• 信号已启用：开启
• 发送恢复通知：开启
• 连续轮次：默认值 2 (1–20)。 连续异常投票轮数；2 会忽略单次故障。缺少证据会重置连续计数，但不证明恢复。

意外的 FDC submit1

检测到 FDC submit1。

• 检查什么？提交数据可用时报告观测到的 FDC submit1。
• 为什么重要？FDC 中该提交阶段异常，应检查配置。
• 常见原因：提交进程可能使用了错误的协议或提交方法。
• 可以怎么做？检查所报交易及提交进程协议配置。
• 信号已启用：开启
• 发送恢复通知：开启

未确认的共识请求

连续多轮存在未确认的共识请求时发送一条汇总警告。

• 检查什么？检查连续投票轮次中是否存在未确认的共识请求，并发出汇总告警。
• 为什么重要？共识已确认但你未确认的请求，通常意味着你的验证器无法检查它们。缺少这些数据，你通常无法构建和签署共识 Merkle root，该轮也就不计入你的参与。
• 常见原因：某条链的验证器已停止或落后，或其数据源（例如 BTC、DOGE 或 XRP 节点）未同步。
• 可以怎么做？确定未确认请求所属的链或证明类型，并检查相应验证器的健康状态与同步进度。
• 信号已启用：开启
• 发送恢复通知：开启
• 连续轮次：默认值 2 (1–20)。 连续异常投票轮数；2 会忽略单次故障。缺少证据会重置连续计数，但不证明恢复。

FDC 位投票长度

位投票长度与已验证的唯一请求数量不一致。

• 检查什么？检查 FDC bitvote 长度是否与已验证的唯一请求数匹配。
• 为什么重要？长度错误的 bitvote 无法与该轮请求匹配，因此既不计入共识，也不计入你的 FDC 参与。
• 常见原因：FDC 客户端看到的请求集合与链上不同，例如由于索引器延迟，或升级后出现客户端版本问题。
• 可以怎么做？检查 C-chain 索引器是否已同步至链头、FDC 客户端是否运行当前版本，然后比较日志中的请求数量。
• 信号已启用：开启
• 发送恢复通知：开启

reveal 不匹配、签名者错误或错过签名宽限期的证据。

揭示违规

提交与揭示不匹配，立即发出严重警报。

• 检查什么？已验证的 FTSO commit/reveal 不匹配会立即触发严重告警。
• 为什么重要？与 commit 不匹配的 reveal 会受到处罚：该轮奖励会减少或取消，处罚甚至可能使某个奖励周期的可领取奖励变为负数。
• 常见原因：commit 与 reveal 使用了不同的数据，通常发生在重启之后；也可能是两个运行中的实例使用相同地址提交。
• 可以怎么做？确保只有一个客户端为你的地址提交，并检查所报告轮次前后的日志。
• 信号已启用：开启
• 发送恢复通知：开启

签名者不匹配

签名与签名策略地址不匹配。

• 检查什么？检查 FTSO 或 FDC 签名者是否与 signing policy 地址不匹配。
• 为什么重要？使用错误密钥生成的签名不会计入你的权重。你会失去签名奖励，该签名也无法帮助该轮完成最终确认。
• 常见原因：客户端使用的签名密钥不对应实体已注册的 signing policy 地址，例如更换密钥后未同步配置，或配置中使用了错误密钥。
• 可以怎么做？将所报告交易的签名者与身份已注册的 signing policy 地址进行比较，并更正配置中的签名密钥。
• 信号已启用：开启
• 发送恢复通知：开启

错过签名宽限期

签名错过奖励宽限期。

• 检查什么？检查 FTSO 或 FDC 签名是否错过奖励宽限期。
• 为什么重要？签名开始后 10 秒宽限期内的签名始终获得奖励。之后的签名只有在最终确认之前到达才计入，而最终确认通常很快就会发生。
• 常见原因：RPC 或索引器缓慢、主机繁忙，或签名提交地址上有排队的交易。
• 可以怎么做？在日志中比较签名开始时间与你的签名交易时间，并检查 RPC 响应时间和主机负载。
• 信号已启用：开启
• 发送恢复通知：开启

FDC 揭示违规

位投票涵盖共识，但缺少有效签名。

• 检查什么？报告分析器的 FDC reveal offence：bitvote 覆盖共识，但缺少有效签名。
• 为什么重要？当你的 bitvote 覆盖共识时，你应当签署由此产生的 Merkle root。分析器会将缺少有效签名视为 FDC 违规，处罚可能减少你的周期奖励。
• 常见原因：FDC 签名步骤在 bitvote 之后失败，通常是因为缺少验证器响应，无法构建 Merkle 树。
• 可以怎么做？检查所报告轮次的 FDC 客户端和验证器健康状态，以及 submitSignatures 交易。
• 信号已启用：开启
• 发送恢复通知：开启

受监控提交阶段中的失败交易。

交易失败

某个提交阶段失败。

• 检查什么？报告五个受监控提交阶段中的失败交易。
• 为什么重要？被回退的提交仍会消耗 gas，但数据不会被记录，因此该轮的这一阶段会被视为错过。
• 常见原因：两个客户端使用同一地址造成 nonce 冲突、gas 不足、发送地址未注册当前周期，或协议升级后合约回退。
• 可以怎么做？在浏览器中打开所报告交易，查看回退原因，并确保每个提交地址仅由一个客户端使用。
• 信号已启用：开启
• 发送恢复通知：开启

相对于签名权重及经过区块的 Fast Updates 活动。

Fast Updates 不活跃

不活跃在统计上极不可能时报警。默认关闭区块数量警告。

• 检查什么？根据签名权重和经过的区块数，将无 Fast Updates 的模型概率与阈值比较。可选区块警告使用奖励周期区块数的 1%。
• 为什么重要？Fast Updates（区块延迟级 feed）属于最低条件：每个奖励周期至少应提交预期更新的 80%，除非你的权重低于总权重的 0.2%。
• 常见原因：Fast Updates 客户端已停止、其账户的 gas 资金已耗尽（“insufficient funds”），或抽签密钥未注册。
• 可以怎么做？检查 Fast Updates 客户端日志及所有 Fast Updates 账户的余额。权重较低时，两次被选中之间出现较长间隔是正常的。
• 信号已启用：开启
• 发送恢复通知：开启
• 概率阈值：默认值 1E-7 (1E-15–0.1)。 概率阈值越小，越需要强统计证据才能判定 Fast Updates 不活跃。
• 启用区块数量警告：默认值 关闭。 无更新区块达到奖励周期区块数 1% 时也警告；默认关闭。

下一周期注册与当前 signing policy 成员资格。

下一奖励周期注册

超过设定延迟仍未注册时仅提醒一次。

• 检查什么？检查注册开放并经过设定延迟后，下一奖励周期注册是否仍缺失。
• 为什么重要？错过某个奖励周期的注册，意味着整个周期都无法参与，也没有 FSP 奖励，同时你的 passes 会清零。
• 常见原因：系统客户端在 30 分钟注册窗口内未运行、注册交易失败，或实体的某个地址资金不足。
• 可以怎么做？在系统客户端日志中查找“Voter … registered for epoch …”，并确保客户端在整个注册窗口内运行；只有在该窗口内才能注册。
• 信号已启用：开启
• 发送恢复通知：开启
• 延迟分钟数：默认值 15 (1–1,440)。 注册开放后等待这些分钟，再对缺失注册告警。

签名策略成员资格

该身份不在当前签名策略中。

• 检查什么？检查身份是否不在当前 signing policy 中。
• 为什么重要？只有处于有效 signing policy 中的实体，才能在当前奖励周期提交、签名并获得奖励。
• 常见原因：错过了该周期的注册，或注册未成功。
• 可以怎么做？已无法加入当前周期。确保下一次注册成功，并检查上次注册窗口的日志。
• 信号已启用：开启
• 发送恢复通知：开启

用于交易的提供者运行地址原生余额。

运行余额不足

每小时检查提交、签名及签名策略地址的原生代币余额。

• 检查什么？将运行地址的缓存原生余额与警告及严重阈值比较；读取失败不能证明恢复。
• 为什么重要？原生余额不足可能导致操作交易无法支付 gas。
• 常见原因：Gas 支出或转出可能降低了操作地址余额。
• 可以怎么做？补充余额前检查低余额地址及近期交易。
• 信号已启用：开启
• 发送恢复通知：开启
• 警告阈值 (FLR/SGB)：默认值 25 (0.001–1,000,000)。 可读取原生余额严格低于该金额时警告。
• 严重阈值 (FLR/SGB)：默认值 5 (0–1,000,000)。 低余额低于该金额时升级为严重；不得超过警告阈值。

监控数据的可用性与新鲜度。

监控可用性

始终开启。分析器或结果过期时暂停提供商警报。

• 检查什么？始终检查分析器健康；缺失、失败或超过十分钟的运行或轮次数据会暂停提供者评估。
• 为什么重要？过期监控无法可靠评估提供者状态。
• 常见原因：分析器可能停止、失败或无法获取完整轮次。
• 可以怎么做？检查分析器状态、上次运行和索引轮次时效。
• 信号已启用：始终开启
• 发送恢复通知：开启

观测的 FTSO 和 FDC 预警，与官方 Minimal Conditions 判定分开。

Anchor 预警

观测命中率低于窗口阈值；不代表官方资格认定。

• 检查什么？样本足够且新鲜时检查窗口内 FTSO 锚定 feed 命中率；签名权重为零时不适用。
• 为什么重要？官方要求：每个奖励周期中，锚定 feed 的估值须在 80% 的投票轮次内处于中位数的 0.5% 范围内。此窗口是早期指标，并非官方结果。
• 常见原因：参与不足、连接中断或观测不完整可能降低测量值。
• 可以怎么做？排查提供者或验证者前，先检查窗口、样本数和数据新鲜度。
• 信号已启用：开启
• 发送恢复通知：开启
• 低于此值时警告 (%)：默认值 80% (1%–100%)。 新鲜观测足够后，低于该百分比即警告；恢复需高出两百分点，上限 100%。
• 时间窗口：默认值 2 小时。 选择小时观测窗口；这不是完整奖励周期评估。
• 最少观测次数：默认值 40 (10–240)。 评估百分比前至少需要这些观测。

FDC 预警

观测参与率低于窗口阈值。不计入无共识的轮次。

• 检查什么？样本足够且新鲜时检查共识轮次中的 FDC 参与率；无共识轮次及零签名权重不适用。
• 为什么重要？官方要求：每个奖励周期中，FDC 须成功参与 60% 的投票轮次（提交正确的 Merkle root）。这里设置的阈值可以更早发出警告。
• 常见原因：参与不足、连接中断或观测不完整可能降低测量值。
• 可以怎么做？排查提供者或验证者前，先检查窗口、样本数和数据新鲜度。
• 信号已启用：开启
• 发送恢复通知：开启
• 低于此值时警告 (%)：默认值 80% (1%–100%)。 新鲜观测足够后，低于该百分比即警告；恢复需高出两百分点，上限 100%。
• 时间窗口：默认值 2 小时。 选择小时观测窗口；这不是完整奖励周期评估。
• 最少观测次数：默认值 40 (10–240)。 评估百分比前至少需要这些观测。

观测的 P-chain 连接与已注册 NodeID 的验证者成员状态。

验证节点连接状态

多个 P 链视角；在并行验证完成前默认关闭警告。

• 检查什么？检查多个 P-chain 视角观测的验证者连接率，而非官方 Uptime。默认关闭。
• 为什么重要？质押要求每个奖励周期的总在线率达到 80%。这里是观测到的连接信号，并非官方在线率。
• 常见原因：参与不足、连接中断或观测不完整可能降低测量值。
• 可以怎么做？排查提供者或验证者前，先检查窗口、样本数和数据新鲜度。
• 信号已启用：关闭
• 发送恢复通知：开启
• 低于此值时警告 (%)：默认值 80% (1%–100%)。 新鲜观测足够后，低于该百分比即警告；恢复需高出两百分点，上限 100%。
• 时间窗口：默认值 2 小时。 选择小时观测窗口；这不是完整奖励周期评估。
• 最少观测次数：默认值 40 (10–240)。 评估百分比前至少需要这些观测。

验证节点未列出

没有已注册的 NodeID 是当前验证节点。请检查质押是否缺失或已到期。无 NodeID 时不适用。

• 检查什么？仅当所有已知注册 NodeID 均确认不在当前验证者集合中时告警；无 NodeID 或未知结果不证明缺失。
• 为什么重要？不是活跃验证者的节点无法获得质押奖励，而质押最低条件要求每个奖励周期的总在线率达到 80%。
• 常见原因：验证者的质押期已结束、节点从未被加入验证者集合，或与实体关联的 NodeID 已更改。
• 可以怎么做？检查节点的质押结束时间，必要时续期，并确认与你的身份关联的 NodeID。
• 信号已启用：开启
• 发送恢复通知：开启

按周期分组的提供者地址个人未领取奖励。

未领取的个人奖励

每个周期汇总经证明验证的可领取 DIRECT/FEE 奖励。不计入委托人奖励池。

• 检查什么？每个奖励周期对超过最低金额的个人 direct 和 fee 未领取奖励提醒一次；金额不高于阈值时恢复。
• 为什么重要？FSP 奖励在 25 个奖励周期后过期（约三个月）；届时未领取的直接奖励和费用奖励将会丢失。
• 常见原因：奖励已可领取，或领取尚未反映在缓存快照中。
• 可以怎么做？在奖励视图中检查周期、金额及领取状态。
• 信号已启用：开启
• 发送恢复通知：开启
• 最低金额 (FLR/SGB)：默认值 1 (0–1,000,000,000)。 仅个人未领取奖励严格超过该原生代币金额时告警。