You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the event that a miner stalls or misbehaves, we have no insight into why, since we don't have (and shouldn't have) their logs.
To address this, mining nodes could emit a periodic "heartbeat" message with diagnostic information to its event observer endpoint. To make it so that other nodes in the network can see remote miners' heartbeats, we should propagate the heartbeat information via a StackerDB replica, which monitoring software can subscribe to.
One way to do this in an incremental fashion without requiring any new message types or StackerDB replicas would be to simply re-purpose the mock miner proposal slots in the .miners StackerDB to instead propagate heartbeat messages from the running miner. The heartbeat message contents are TBD, but we do know that the miner and relayer threads in the mining node contain the relevant information we'd want to propagate.
The mining node would need to send heartbeat messages on a fixed cadence (so their absence or delay would itself be a notable event), and do so regardless of whether or not the node is currently mining.
The text was updated successfully, but these errors were encountered:
In the event that a miner stalls or misbehaves, we have no insight into why, since we don't have (and shouldn't have) their logs.
To address this, mining nodes could emit a periodic "heartbeat" message with diagnostic information to its event observer endpoint. To make it so that other nodes in the network can see remote miners' heartbeats, we should propagate the heartbeat information via a StackerDB replica, which monitoring software can subscribe to.
One way to do this in an incremental fashion without requiring any new message types or StackerDB replicas would be to simply re-purpose the mock miner proposal slots in the
.miners
StackerDB to instead propagate heartbeat messages from the running miner. The heartbeat message contents are TBD, but we do know that the miner and relayer threads in the mining node contain the relevant information we'd want to propagate.The mining node would need to send heartbeat messages on a fixed cadence (so their absence or delay would itself be a notable event), and do so regardless of whether or not the node is currently mining.
The text was updated successfully, but these errors were encountered: