-
Notifications
You must be signed in to change notification settings - Fork 849
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 scope attribute setter on MeterBuilder, TracerBuilder, LogEmitterBuilder #4711
Conversation
* @return this | ||
* @since 1.18.0 | ||
*/ | ||
default MeterBuilder setAttributes(Attributes attributes) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can also make the argument the name should be setInstrumentationAttributes
. The two setters currently don't align in this regard (setSchemaUrl
and setInstrumentationVersion
). I omitted "instrumentation" because it doesn't add any clarity - would have to be setScopeAttributes
to improve clarify, which doesn't align with the existing naming pattern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
setStaticAttributes
? setFixedAttributes
? If we want to stay with setAttributes
(and I'm not opposed necessarily), we should add more clarifying javadoc about what they will be used for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
setCommonAttributes
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The setters on these builders are all defining properties for scope, but scopes are an implementation detail that don't appear the SDK makes them available to exporters via SpanData, MetricData, LogData.
From the perspective of an API user, these properties just combine to define a unique tracer / meter / logger. I.e. if you specify a different name, version, schemaUrl, or attributes, you should expect to get a different instance.
I think setAttributes
is probably most correct, but all of these javadoc could use clarification that distinct name, version, schemaUrl, attribute combinations return unique instances.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've tried to improve the javadoc overall in LoggerBuilder, TracerBuilder, and MeterBuilder. Going to mark this as resolved but please reopen needed 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry to reopen after all this time. I really don't like this method name, as-is. I would greatly prefer setScopeAttributes
, but even that seems quite arcane.
In addition, the javadoc here doesn't explain at all what these attributes are for, or why one might want to assign them to a meter or tracer when they are created.
I hate to open up the bike-shedding, but we're going to have to explain this method to people if we don't make it crystal clear from the name + javadoc what this is for (honestly...not having followed the spec discussion about this, I don't know myself what the point of these attributes is).
api/all/src/main/java/io/opentelemetry/api/trace/TracerBuilder.java
Outdated
Show resolved
Hide resolved
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
Now that open-telemetry/opentelemetry-specification#2789 was merged, should the |
@mateuszrzeszutek addressing that has been on my todo list! It minimally needs to be reflected in the However, I think we can keep |
@@ -36,14 +38,16 @@ public ComponentRegistry(Function<InstrumentationScopeInfo, V> factory) { | |||
* any, otherwise creates a new instance and associates it with the given scope. | |||
*/ | |||
public V get(InstrumentationScopeInfo instrumentationScopeInfo) { | |||
ScopeKey scopeKey = toScopeKey(instrumentationScopeInfo); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note, the identity of Logger, Meter, Tracer is no longer strictly equal to InstrumentationScopeInfo identity because of this spec PR.
Codecov ReportBase: 90.92% // Head: 90.93% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #4711 +/- ##
=========================================
Coverage 90.92% 90.93%
- Complexity 4816 4821 +5
=========================================
Files 545 547 +2
Lines 14382 14391 +9
Branches 1382 1382
=========================================
+ Hits 13077 13086 +9
- Misses 898 899 +1
+ Partials 407 406 -1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
…y-java into builder-scope-attributes
api/all/src/main/java/io/opentelemetry/api/metrics/MeterBuilder.java
Outdated
Show resolved
Hide resolved
api/all/src/main/java/io/opentelemetry/api/trace/TracerBuilder.java
Outdated
Show resolved
Hide resolved
api/logs/src/main/java/io/opentelemetry/api/logs/LoggerBuilder.java
Outdated
Show resolved
Hide resolved
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
…y-java into builder-scope-attributes
@jkwatson can you take a look when you have a chance? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need a better name for this method and better documentation about what this new use of attributes is for.
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
We had discussed during the SIG meeting that perhaps what we need is a |
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
@jkwatson I think we should close this until users ask for it. Adding a |
Sounds fine to me. Just thinking out loud here, but could we create a Scope interface in the API that is additionally implemented by InstrumentationScopeInfo? Or would that not add much value? |
I don't think it would add much value because the consumers of these are totally different. The caller of the API is an instrumentation author, and the consumer of scope in the SDK is probably someone writing an exporter. Would want something to keep the two implementations in sync with each other, but hard for it to not feel awkward. |
Related to #4695.