Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(metrics): use geth metrics package and delete local metrics #1422

Open
wants to merge 21 commits into
base: master
Choose a base branch
from

Conversation

qdm12
Copy link
Collaborator

@qdm12 qdm12 commented Jan 13, 2025

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:

Therefore:

  • file kept and refactored metrics/prometheus/prometheus.go with the Gatherer implementation we use
  • file kept and refactored metrics/prometheus/prometheus_test.go
  • new file metrics/prometheus/interfaces.go added for refactoring
  • geth global variable metrics.Enabled is set to true in plugin/evm.VM.initializeMetrics

Note 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 🙏

Comment on lines 190 to 191
default:
return nil, fmt.Errorf("metric type is not supported: %T", metric)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took the liberty to change this to return an error (instead of silently ignoring it) on an unsupported type to prevent in the future to define new types and forget to add the implementation in the switch here.

@qdm12 qdm12 marked this pull request as ready for review January 13, 2025 16:08
@qdm12 qdm12 requested review from ceyonur, darioush and a team as code owners January 13, 2025 16:08
@qdm12 qdm12 force-pushed the qdm12/libevm/metrics branch from 7c08815 to 15866c8 Compare January 15, 2025 11:15
@qdm12 qdm12 requested a review from darioush January 15, 2025 11:40
darioush
darioush previously approved these changes Jan 23, 2025
@qdm12 qdm12 changed the title chore(metrics): use libevm metrics package and delete local metrics chore(metrics): use geth metrics package and delete local metrics Jan 27, 2025
@qdm12 qdm12 force-pushed the qdm12/libevm/metrics branch from 15866c8 to 769d5fc Compare January 27, 2025 12:50
maru-ava
maru-ava previously approved these changes Jan 27, 2025
Copy link

@maru-ava maru-ava left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! The subnet dashboard is now populated with metrics for the load test e2e job:

A random PR doesn't show any metrics on the subnets dashboard for the same job:

@qdm12
Copy link
Collaborator Author

qdm12 commented Jan 28, 2025

A random PR doesn't show any metrics on the subnets dashboard for the same job:

Ah, let me check if I can revert it to no-metric, and open another PR (based off this one I suppose) to enable metrics.
Since this PR is not meant to change anything and should be pure maintenance / code movement.

@qdm12 qdm12 dismissed stale reviews from maru-ava and darioush via a4eaf83 February 7, 2025 14:34
@qdm12
Copy link
Collaborator Author

qdm12 commented Feb 10, 2025

Working as expected, this is good to go (same as ava-labs/coreth#745), just need reviews 😉

@qdm12 qdm12 enabled auto-merge (squash) February 10, 2025 07:50
@qdm12 qdm12 requested review from darioush and maru-ava February 10, 2025 07:50
maru-ava
maru-ava previously approved these changes Feb 10, 2025
darioush
darioush previously approved these changes Feb 11, 2025
Copy link
Collaborator

@darioush darioush left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some optional suggestions

@qdm12 qdm12 dismissed stale reviews from darioush and maru-ava via e389c7f February 17, 2025 13:02
@qdm12 qdm12 requested a review from ceyonur February 17, 2025 14:47
darioush
darioush previously approved these changes Feb 18, 2025
@qdm12 qdm12 added the DO NOT MERGE This PR is not meant to be merged in its current state label Feb 20, 2025
// - a non-test file imports the testutils package
func TestMustNotImport(t *testing.T) {
prodOnly := false
checkNotImporting(t, "../", prodOnly, "testutils should only be used outside plugin/evm")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we have such limitation? Does that mean we can't use this pkg in plugin/evm test files?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See this comment. TLDR:

  • this testutils package is only to limit diffs in geth code
  • (subjective) we should prefer to copy paste test helping utilities, to reduce package dependencies and possible cycle import issues

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should limit this pkg like that. if we nee such a pkg it should be in internal if possible and under a different pkg than plugin/evm. I think it should be sufficient to check this is not imported in any prod code, no?

I'm fine with copy pasting WithMetrics if we feel like it's best not to import metrics here.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thinking again, having a testutils package actually indicates this should be not called from prod code. So not sure if there is any point to strict that down too much.

@qdm12 qdm12 removed the DO NOT MERGE This PR is not meant to be merged in its current state label Feb 24, 2025
@qdm12 qdm12 requested a review from ceyonur February 24, 2025 15:45
metrics.NilGauge, metrics.NilGaugeFloat64, metrics.NilGaugeInfo,
metrics.NilHealthcheck, metrics.NilHistogram, metrics.NilMeter,
metrics.NilResettingTimer, metrics.NilSample, metrics.NilTimer:
return nil, fmt.Errorf("%w: %q metric is nil", errMetricSkip, name)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we're going to skip this, can't we just return nil err?

}},
}, nil
default:
return nil, fmt.Errorf("metric %q: type is not supported: %T", name, metric)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this won't cause any unknown geth metric type to break this, right? (e.g a new upstream type in the future)

// - a non-test file imports the testutils package
func TestMustNotImport(t *testing.T) {
prodOnly := false
checkNotImporting(t, "../", prodOnly, "testutils should only be used outside plugin/evm")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should limit this pkg like that. if we nee such a pkg it should be in internal if possible and under a different pkg than plugin/evm. I think it should be sufficient to check this is not imported in any prod code, no?

I'm fine with copy pasting WithMetrics if we feel like it's best not to import metrics here.

// - a non-test file imports the testutils package
func TestMustNotImport(t *testing.T) {
prodOnly := false
checkNotImporting(t, "../", prodOnly, "testutils should only be used outside plugin/evm")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thinking again, having a testutils package actually indicates this should be not called from prod code. So not sure if there is any point to strict that down too much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants