chore(metrics): use geth metrics package and delete local metrics #1422
Conversation
qdm12
force-pushed
the
qdm12/libevm/metrics
branch
2 times, most recently
from
34e9afd to
8c8514c
Compare
qdm12
force-pushed
the
qdm12/libevm/metrics
branch
from
7c08815 to
15866c8
Compare
qdm12
changed the title
qdm12
force-pushed
the
qdm12/libevm/metrics
branch
from
15866c8 to
769d5fc
Compare
- Bring over refactoring and fixes done in ava-labs/libevm#103 - Bring over test refactoring done in ava-labs/libevm#103
Signed-off-by: Quentin McGaw <[email protected]>
Signed-off-by: Quentin McGaw <[email protected]>
- add exported comments - rename `g` to `gatherer` in test - Format copyright as it as ™️ - Remove TODO
|
Working as expected, this is good to go (same as ava-labs/coreth#745), just need reviews 😉 |
Signed-off-by: Quentin McGaw <[email protected]>
qdm12
added
the
DO NOT MERGE
qdm12
removed
the
DO NOT MERGE
| }}, | ||
| }, nil | ||
| default: | ||
| return nil, fmt.Errorf("metric %q: type is not supported: %T", name, metric) |
There was a problem hiding this comment.
this won't cause any unknown geth metric type to break this, right? (e.g a new upstream type in the future)
There was a problem hiding this comment.
Shouldn't it break it? This would show in the CI right, and we should add the type to our switch case and either handle it or explicitly ignore it, I think.
There was a problem hiding this comment.
Yes, it should be ok if this is going to be called with any unknown metric in the first metricFamily() call (i.e right after when we spin up the node). My question is if there is any possibility that any potential unknown upstream metric is registered in the runtime in a more rare case that CI won't immediately catch.
There was a problem hiding this comment.
The only place that gatherer is registered is:
Line 558 in 4f2ea63
Which registers it to avalanchego's multi gatherer and all errors are checked/none-are-discarded.
Maybe it's not covered by tests, but it should definitely show up in e2e tests (and, if not, we would have an error handling problem in avalanchego).
Why this should be merged
Contribution to the libevm effort.
Note there are the same changes for both coreth and subnet-evm, but they should not be part of libevm since these are extra features specific to subnet-evm/coreth, even if they're the same for both.
How this works
Comparing the following:
mastervs corethmaster: subnet-evm is missing the extra file https://github.com/ava-labs/coreth/blob/b6b4dfbc4bfc7f17e4cfe5f3c0fb44944176c884/metrics/init_test.go (which is present in geth as well)mastervs gethv1.13.14: subnet-evm has many deletions, very few minor unneeded changes and the new non-conflicting filemetrics/prometheus/prometheus.goTherefore:
metrics/prometheus/prometheus.gowith theGathererimplementation we usemetrics/prometheus/prometheus_test.gometrics/prometheus/interfaces.goadded for refactoringmetrics.Enabledis set to true inplugin/evm.VM.initializeMetricsNote for the two files refactored (with fixes as well), this was done in some intermediary step in ava-labs/libevm#103, so I decided to bring this over here so it doesn't get trashed.
How this was tested
CI passing
Need to be documented?
No
Need to update RELEASES.md?
Not really, since it should not change anything 🙏