-
Notifications
You must be signed in to change notification settings - Fork 100
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
Remove _total from duplicate untyped Sums before export #678
Conversation
unit test would be useful here |
added a unit test |
Codecov Report
@@ Coverage Diff @@
## main #678 +/- ##
==========================================
- Coverage 69.01% 68.79% -0.23%
==========================================
Files 36 36
Lines 4651 4679 +28
==========================================
+ Hits 3210 3219 +9
- Misses 1288 1308 +20
+ Partials 153 152 -1
... and 1 file with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
One thing we will have to think about going forward is that we won't have access to the "unknown" flag from a counter. The "unknown" flag will be gauge-specific. That will make our current approach of looking at labels in the naming function no longer work. We don't need to solve that here, but worth noting |
fyi @ridwanmsharif: if you see double-exported metrics with |
@damemi it looks like this removes |
Fixes #677
updates GMP exporter's custom
GetMetricName()
to remove_total
from Sums which have the double-export untyped-metric attribute, iftotal
was not present in the original metric name (before being normalized by OTel's prometheus.BuildPromCompliantName() function).We need this because the extra untyped Sum metric is added at the ExtraMetrics extension point, which is before name normalization happens for the individual metric types.
Alternatively, the extra metric could be added after name normalization (ie, copy the normalized Gauge metric name to a new Sum after this line in gaugePointToTimeSeries). But that would require refactoring to add a new extension point, which is not worth the effort with a long term upstream plan in the works. The current method takes advantage of existing metric handling for Gauges+Sums as well, such as cumulative normalization.