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
It'll be very nice for all the client implementations to converge on a set of metrics for support. The benefits of metrics standardization includes enabling of converged monitoring across difference implementations, better debugging support in multi client testnet, and better instrumentations which can lead to more client side optimizations.
At the minimal, we should converge on the naming first, and the set of baseline metrics to implement second. There will be divergences such a language dependent metrics and that is ok. (eg. goroutines for Golang, JVM thread counts of JAVA... etc)
The text was updated successfully, but these errors were encountered:
We have quite a lot of metrics (hundreds?) but I suspect we don't need all of these standardized and I think @terencechain was also expressing this. For reference, these are our "beacon chain" metrics that are most likely to be good standardization targets: https://github.com/sigp/lighthouse/blob/master/beacon_node/beacon_chain/src/metrics.rs. Not all of them are relevant, but perhaps someone might find value in giving them a skim.
I'm not saying we should use the Lighthouse ones, I'm happy to follow suit if someone else already has a set that's more conformant with Prom/Grafana best practices (IIRC, ours diverge at times).
It'll be very nice for all the client implementations to converge on a set of metrics for support. The benefits of metrics standardization includes enabling of converged monitoring across difference implementations, better debugging support in multi client testnet, and better instrumentations which can lead to more client side optimizations.
At the minimal, we should converge on the naming first, and the set of baseline metrics to implement second. There will be divergences such a language dependent metrics and that is ok. (eg. goroutines for Golang, JVM thread counts of JAVA... etc)
The text was updated successfully, but these errors were encountered: