When the version changes, it will add a new series, therefore having multiple series, which shouldn't be the case, otherwise we get bad version reports, like this:
At around ~14h (left side), the version did actually change. But as you can see, the old series with the old version kept being announced, creating this confusing graph that looks like that it was running 2 versions simultaneously. At around ~12h (right side of the graph), you see the drop happening because the metrics exporter got restarted.
How to reproduce
Run metrics exporter with a EL
Observe the /metrics endpoint and see that there is only one eth_exe_web3_client_version series.
Deploy a new EL version
Observe the /metrics endpoint and see that there are now two eth_exe_web3_client_version series.
Restart the metrics exporter
Observe the /metrics endpoint and see that there is now just one eth_exe_web3_client_version series.
Possible fixes:
Drop any previously announced eth_exe_web3_client_version metrics whenever the version changes. Note that this problem/solution could also be relevant to other metrics.. E.g. the CL client version.
So the EL version is exposed via the following example series:
When the version changes, it will add a new series, therefore having multiple series, which shouldn't be the case, otherwise we get bad version reports, like this:
At around ~14h (left side), the version did actually change. But as you can see, the old series with the old version kept being announced, creating this confusing graph that looks like that it was running 2 versions simultaneously. At around ~12h (right side of the graph), you see the drop happening because the metrics exporter got restarted.
How to reproduce
eth_exe_web3_client_versionseries.eth_exe_web3_client_versionseries.eth_exe_web3_client_versionseries.Possible fixes:
Drop any previously announced
eth_exe_web3_client_versionmetrics whenever the version changes. Note that this problem/solution could also be relevant to other metrics.. E.g. the CL client version.