Metrics request: highest possible slot

[handelaar2]

The node monitoring site eth2stats.io shows a nice timebased counter of the highest possible slot (slot counter increasing every 12 secs). It would be nice to add this slot-value to the metrics page. This way we can create measurements how far the node's head slot is away from this highest possible value (and how fast the delta is decreasing or increasing).

It seems the value itself is already there, at least in initial-sync. See below screenprint

And maybe the same for Epoch #

[garyschulte]

It looks like the sync block counter is implemented by taking the time since genesis and dividing by seconds per slot. Is that a reliable way to calculate this metric or is there likely to be some accumulated drift?

[rauljordan]

Hi @garyschulte we do have this prometheus metric live in our nodes, it is called beacon_slot here

prysm/beacon-chain/blockchain/metrics.go

Line 13 in 80248cd

beaconSlot = promauto.NewGauge(prometheus.GaugeOpts{

[handelaar2]

@rauljordan Then it is lagging (at least for me). I refreshed my metric page and immediately took a screenshot.
beacon_slot here is 11 slots behind the calculated "seconds since genesis" divided by 12" as shown by eth2stats. For me they are not the same.

[garyschulte]

@rauljordan Then it is lagging (at least for me). I refreshed my metric page and immediately took a screenshot.
beacon_slot here is 11 slots behind the calculated "seconds since genesis" divided by 12" as shown by eth2stats. For me they are not the same.

I noticed the same behavior. I am charting beacon_slot and beacon_head_slot, and head slot does definitely lag for whatever reason. Perhaps whatever code path that is emitting that metric is not being triggered during those periods

[handelaar2]

This (already closed) issue has resolved itself via #4754

It is ok now as can be seen in the screen print.
(I only observed a max of 1 slot behind the "ticker".

Thanks @terencechain

[handelaar2]

Still different things I would say (my_headslot<>others_headslot<>slot_ticker). I guess (it seems) we need to create our own additional value outside the metrics-page to be able to also track the blue "slot_ticker". Confusing (and disappointing).

[prestonvanloon]

@handelaar2 Based on your comments after closing, is this still an issue we should look into?

[rauljordan]

@handelaar2 please let us know if this is still a problem

[handelaar2]

Can only confirm in a few days after the restart of the testnet (don't have a proper beacon running right now)

[handelaar2]

I still see this as an issue.
We are missing a kind of "CurrentSlot" in the metrics as defined in process_block_helpers.go That one is "timebased" (using now() ) .

beacon_head_slot and beacon_slot are not (not sure where they get their values from).

prysm/beacon-chain/blockchain/metrics.go

Line 85 in 2fef9d3

func reportSlotMetrics(currentSlot uint64, headSlot uint64, finalizedCheckpoint *ethpb.Checkpoint) {

_

CurrentSlot (looks pure timebased to me):

prysm/beacon-chain/blockchain/process_block_helpers.go

Line 23 in 1224e75

func (s *Service) CurrentSlot() uint64 {

_

To clarify again what I mean, below screenprint shows this timebased slot number:
the blue value on eth2stats at the top. As also can be seen in the screenprint, both metric "slot values" are lagging (not showing this timebased (theoretical best) slot). So I would like to see a metrics value which says for this example: 3990

[mcdee]

There are two different metrics: the current slot of the chain, which is calculated purely from genesis timestamp and current time, and the current slot of the node, which is equivalent to the node's head slot as above.

There are discussions going on at ethereum/beacon-APIs#25 regarding making this and other information available via a standard API.

[handelaar2]

That is my point Jim, we currently don't have in the metrics that "current slot of the chain" ((now-genesis)/12) as you call it. It is not there. So that is the value I would like to make available to prometheus/grafana (not via the api).

[handelaar2]

Thanks!