Keep an eye on your validator
Once your validator has been activated, you can set up validator monitoring together with a dashboard to keep track of its performance.
Another way of keeping track is using an online service such as beaconcha.in: Mainnet or Holesky.
Both online services and dashboards allow setting up alerts for when the validator is offline.
Troubleshooting
Make sure your validator is attached
On startup, you should see a log message that reads Local validator attached
.
This has a pubkey
field which should be the public key of your validator.
Keep track of your syncing progress
To keep track of your sync progress, pay attention to the Slot start
messages in your logs:
INF 2022-06-16 13:23:11.008+02:00 Slot start
topics="beacnde"
slot=4046214
epoch=126444
sync="00h37m (99.38%) 11.0476slots/s (DDQQDDDPDD:4021215)"
peers=55
head=5d59aba3:4021234
finalized=125661:82616f78
delay=8ms245us608ns
Where:
slot
is the current time on the beacon chain, measured in "slots"epoch
shows the current epoch: each epoch has 32 slots, and each validator performs one attestation per epochpeers
tells you how many peers you're currently connected to: depending on the number of attached validators, you may need anywhere from 10 to 60 peers connectedsync
tells you if your client is synced and can perform duties, or how long it will take to get there/opt
means that the node is optimistically synced: it is waiting for the execution client to finish syncing- in the case of trusted node sync it may also show
backfill
in which case duties are being performed but more bandwidth than usual is being used to download historical blocks head
tells you the most recent block you've synced to so far (5d59aba3
is the first part of the block hash,4021234
is the slot number)finalized
tells you the most recent finalized epoch you've synced to so far (125661
is the epoch,82616f78
is the checkpoint hash)
The string of letters -- what we call the sync worker map
(in the above case represented by DDQQDDDPDD
) represents the peers you are syncing from, where:
s - sleeping (idle),
w - waiting for a peer from PeerPool,
R - requesting blocks from peer
D - downloading blocks from peer
Q - queued/waiting for ancestor blocks
P - processing/verifying blocks
U - updating peer's status information
Tip
You can also use you calls outlined in the REST API page to retrieve similar information.