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

Add attributes advice API (just DoubleCounter for now) #5677

Merged
merged 4 commits into from
Aug 16, 2023

Conversation

mateuszrzeszutek
Copy link
Member

Implements open-telemetry/opentelemetry-specification#3546

I only added implementation for the DoubleCounter in this PR; I'll extend it to all other instruments in the following PR if this one is accepted.

@mateuszrzeszutek mateuszrzeszutek requested a review from a team August 3, 2023 15:52
@codecov
Copy link

codecov bot commented Aug 3, 2023

Codecov Report

Patch coverage: 94.23% and project coverage change: +0.02% 🎉

Comparison is base (ea7b761) 91.25% compared to head (16fc3d4) 91.28%.

Additional details and impacted files
@@             Coverage Diff              @@
##               main    #5677      +/-   ##
============================================
+ Coverage     91.25%   91.28%   +0.02%     
- Complexity     5032     5042      +10     
============================================
  Files           556      558       +2     
  Lines         14861    14890      +29     
  Branches       1389     1392       +3     
============================================
+ Hits          13562    13592      +30     
+ Misses          896      894       -2     
- Partials        403      404       +1     
Files Changed Coverage Δ
...ncubator/metrics/ExtendedDoubleCounterBuilder.java 0.00% <0.00%> (ø)
...ntelemetry/sdk/metrics/SdkDoubleUpDownCounter.java 100.00% <ø> (ø)
...opentelemetry/sdk/metrics/SdkLongGaugeBuilder.java 100.00% <ø> (ø)
...emetry/sdk/metrics/internal/descriptor/Advice.java 84.61% <81.81%> (-15.39%) ⬇️
...lemetry/sdk/metrics/AbstractInstrumentBuilder.java 100.00% <100.00%> (ø)
...io/opentelemetry/sdk/metrics/SdkDoubleCounter.java 100.00% <100.00%> (ø)
.../opentelemetry/sdk/metrics/SdkDoubleHistogram.java 100.00% <100.00%> (ø)
...io/opentelemetry/sdk/metrics/SdkLongHistogram.java 100.00% <100.00%> (ø)
...trics/internal/view/AdviceAttributesProcessor.java 100.00% <100.00%> (ø)
...emetry/sdk/metrics/internal/view/ViewRegistry.java 97.97% <100.00%> (+0.20%) ⬆️

... and 2 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@breedx-splk breedx-splk 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 to me.

Copy link
Member

@jack-berg jack-berg 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, just one small edge case to think about in ViewRegistry

}

@Test
void counterWithAdvice() {
Copy link
Member

Choose a reason for hiding this comment

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

Hey so I made a comment over in the spec which states:

Just so we're clear, my interpretation is that because advice is non-identifying, two histograms with the same identity and different advices will result in 1 metric stream. And thus we have to pick one set of advice to apply to the resulting metric stream, which should naturally be the first we see.

But that isn't the case as implemented today (and also not for the histogram bucket advice). You can demonstrate this by creating another counter with the same name, and with no advice, and seeing that there are two metrics produced instead of just one:

    DoubleCounter counter2 = meterProvider.get("meter").counterBuilder("counter").ofDoubles().build();
    counter2.add(1, ATTRIBUTES);

The issue stems from MetricStorageRegistry#register(MetricStorage), a tricky little piece of code responsible for evaluating whether a newly registered instrument should get a new storage (and thus a new metric stream at collection) or should send its measurements to an existing storage (and thus merge with an existing metric stream at collection).

The problem is that we use MetricDescriptor.equals(..) to determine if an existing storage matches, but that is a pretty strict equality, checking equality of name, description, view, InstrumentDescriptor (including name, description, unit, type, value type, and advice), and aggregation name.

And I believe there's a bug where if a instrument matches except the case of the name, we produce two metric streams, instead of one like I thought we did. See spec issue #3626.

I think this is probably fine for this PR. I need to go back and fix MetricStorageRegistry#register in a more general capacity.

Copy link
Member

Choose a reason for hiding this comment

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

Opened #5683 to discuss.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I 100% agree advice should be non-identifying.

I think this is probably fine for this PR. I need to go back and fix MetricStorageRegistry#register in a more general capacity.

👍

Copy link
Member

Choose a reason for hiding this comment

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

Solved in #5701.

@mateuszrzeszutek
Copy link
Member Author

@jack-berg Is this ready to merge?

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.

3 participants