BUG: Provide valid Sync Status for Nethermind EC
Describe the bug Sync Status for Nethermind EC is invalid.
To Reproduce Steps to reproduce the behavior:
- Setup a fresh node with Nethermind EC
- Select the "Control" Tab
- See invalid values for Nethermind in "Sync Status" Widget
Expected behavior A valid representation of current Nethermind EC Sync Status
Screenshots

Desktop (please complete the following information):
- OS: macOS
- Launcher version: 2.0.0-RC.6
Node (please complete the following information):
- OS: Ubuntu 22.04
- Affected service: Nethermind EC v1.14.3
Additional context
Nethermind EC does not provide data for Prometheus at all to retrieve a valid Sync Status.
The currently tested labels ['nethermind_blocks','nethermind_blocks_sealed'] are wrong.
An option for the future could be to request the Sycn Status via RPC-API (untested) .
There's some more data available of nethermind:
- https://github.com/NethermindEth/nethermind/pull/4887
- https://github.com/NethermindEth/nethermind/issues/4860
- https://github.com/NethermindEth/nethermind/issues/4842
Dear @daverolo:
Currently syncing with snap sync NM+Prysm. Metric you have referenced works.

@daverolo Could you please compare the arguments you have used to run it?
Here are mine:
.\Nethermind.Runner.exe -c mainnet -dd C:/work/ethdata --Metrics.Enabled true --Metrics.ExposePort=9091 --JsonRpc.Enabled true --JsonRpc.Port 8547 --Sync.SnapSync true --JsonRpc.JwtSecretFile C:/ethereum/consensus/jwt.hex
.\beacon-chain-v3.1.2-windows-amd64.exe --mainnet --execution-endpoint=http://localhost:8551/ --jwt-secret=C:/ethereum/consensus/jwt.hex --checkpoint-sync-url=https://beaconstate.info/ --genesis-beacon-api-url=https://beaconstate.info/ --datadir=C:/work/ethdata
with
.\prometheus.exe --config.file=./prometheus.yml --storage.tsdb.path=./prometheus --storage.tsdb.retention=200h --web.enable-lifecycle
and /prometheus.yml:
global:
scrape_interval: 5s
evaluation_interval: 5s
scrape_configs:
- job_name: 'nm'
honor_labels: true
static_configs:
- targets: ['localhost:9091']
fixed with #1018, thanks for your input @OlegJakushkin