eth/protocols, metrics: use resetting histograms for rare packets #22586
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR "fixes" the previous histograms by resetting them upon each pull/push.
The same way as with timers, the metrics library assumes that there's a constant stream of events we monitor. If a metric gets updated very rarely (e.g. eth/64 header request), the chart will be skewed because the metric will report the same value over and over and over ad infinitum (decaying ever so slowly to 0).
This PR uses @nonsense's resetting idea, just for histograms to reset them on retrieval.
The diff is visible on the screenshot below. The code was updated to this PR in the middle on the displayed run.