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
Making the validator monitor track block proposals would help us raise alerts if there has been a missed proposal by a local/monitored validator. This has been requested several times and makes a lot of sense, especially now we have builders as an additional failure point.
Implementation
Considering this briefly, I think we could track missed proposals in two ways:
Add a new ValidatorMonitor::process_head_state method which works similar to the previous method, but only takes states which were elected as the head (rather than all states).
The issue with (1) would be that relatively weight-less, obscure heads may trigger a rather alarming "missed block" alert.
A downside both approaches is that it would only register a missed block once a subsequent block has been imported. I'm not hugely concerned with this since we should already be raising CRIT logs whenever a block production fails. The edge-case here would be a failure in block propagation, which presently raises no logs. All this considered, we'd likely be registering the proposal failure within 12-24s and given the relatively infrequent nature of block proposal I'm comfortable with this slight delay.
The text was updated successfully, but these errors were encountered:
Description
Making the validator monitor track block proposals would help us raise alerts if there has been a missed proposal by a local/monitored validator. This has been requested several times and makes a lot of sense, especially now we have builders as an additional failure point.
Implementation
Considering this briefly, I think we could track missed proposals in two ways:
latest_block_roots
for skip slots.ValidatorMonitor::process_head_state
method which works similar to the previous method, but only takes states which were elected as the head (rather than all states).The issue with (1) would be that relatively weight-less, obscure heads may trigger a rather alarming "missed block" alert.
A downside both approaches is that it would only register a missed block once a subsequent block has been imported. I'm not hugely concerned with this since we should already be raising CRIT logs whenever a block production fails. The edge-case here would be a failure in block propagation, which presently raises no logs. All this considered, we'd likely be registering the proposal failure within 12-24s and given the relatively infrequent nature of block proposal I'm comfortable with this slight delay.
The text was updated successfully, but these errors were encountered: