-
Notifications
You must be signed in to change notification settings - Fork 894
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
Named Tracers and Meters #264
Named Tracers and Meters #264
Conversation
…ce-oss-contrib/opentelemetry-specification into named-tracers-and-meters
Related:
|
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 agree. Added a few comments/suggestions
New `Meter` instances can be created via a `MeterFactory` and its `getMeter` | ||
method. This method expects two string arguments: | ||
|
||
- `name` (required): This name must identify the instrumentation library (also |
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 it would be good to split this into 2 different strings:
- integration path -
io.opentelemetry.contrib
- instrumented library (component name) -
mongodb
This way we can use the instrumented library name, and get rid of the component
attribute in the Span. No need to have that set for every Span/Metric we create from this Tracer/Meter.
This may be done in a separate PR but want to hear opinions.
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 agree we should do it in separate PR. This PR doesn't tell how this name will be used except to disable certain component's telemetry
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.
Yeah, I think this PR should just implement the OTEP and not go beyond it.
@yurishkuro any more feedback on this PR? beyond #272 all other comments seems to be addressed. We need 1 more sign off here |
In the lack of responses and since the OTEP was already approved for this, merging... Topic starter and two approvers are all from different companies |
* Extended spec with "Named Tracers/Meters" concept. * Implement feedback about wording. * Restore the "runtimes with multiple deployments paragraph" * Update documentation about the "name" argument in Tracer/Meter creation. * Implement PR feedback
This is a proposal to address Resource and Entity data model interactions, including a path forward to address immediate friction and issues in the current resource specification. The proposal includes all links and context needed to justify it, but duplicating a snapshot here: ## Motivation This proposal attempts to focus on the following problems within OpenTelemetry to unblock multiple working groups: - Allowing mutating attributes to participate in Resource ([OTEP 208](open-telemetry/oteps#208)). - Allow Resource to handle entities whose lifetimes don't match the SDK's lifetime ([OTEP 208](open-telemetry/oteps#208)). - Provide support for async resource lookup ([spec#952](open-telemetry#952)). - Fix current Resource merge rules in the specification, which most implementations violate ([oteps#208](open-telemetry/oteps#208), [spec#3382](open-telemetry#3382), [spec#3710](open-telemetry#3710)). - Allow semantic convention resource modeling to progress ([spec#605](open-telemetry#605), [spec#559](open-telemetry#559), etc). --------- Co-authored-by: Tigran Najaryan <[email protected]> Co-authored-by: jack-berg <[email protected]> Co-authored-by: Arve Knudsen <[email protected]> Co-authored-by: David Ashpole <[email protected]>
This is a proposal to address Resource and Entity data model interactions, including a path forward to address immediate friction and issues in the current resource specification. The proposal includes all links and context needed to justify it, but duplicating a snapshot here: ## Motivation This proposal attempts to focus on the following problems within OpenTelemetry to unblock multiple working groups: - Allowing mutating attributes to participate in Resource ([OTEP 208](open-telemetry/oteps#208)). - Allow Resource to handle entities whose lifetimes don't match the SDK's lifetime ([OTEP 208](open-telemetry/oteps#208)). - Provide support for async resource lookup ([spec#952](open-telemetry#952)). - Fix current Resource merge rules in the specification, which most implementations violate ([oteps#208](open-telemetry/oteps#208), [spec#3382](open-telemetry#3382), [spec#3710](open-telemetry#3710)). - Allow semantic convention resource modeling to progress ([spec#605](open-telemetry#605), [spec#559](open-telemetry#559), etc). --------- Co-authored-by: Tigran Najaryan <[email protected]> Co-authored-by: jack-berg <[email protected]> Co-authored-by: Arve Knudsen <[email protected]> Co-authored-by: David Ashpole <[email protected]>
* Extended spec with "Named Tracers/Meters" concept. * Implement feedback about wording. * Restore the "runtimes with multiple deployments paragraph" * Update documentation about the "name" argument in Tracer/Meter creation. * Implement PR feedback
This is a proposal to address Resource and Entity data model interactions, including a path forward to address immediate friction and issues in the current resource specification. The proposal includes all links and context needed to justify it, but duplicating a snapshot here: ## Motivation This proposal attempts to focus on the following problems within OpenTelemetry to unblock multiple working groups: - Allowing mutating attributes to participate in Resource ([OTEP 208](open-telemetry/oteps#208)). - Allow Resource to handle entities whose lifetimes don't match the SDK's lifetime ([OTEP 208](open-telemetry/oteps#208)). - Provide support for async resource lookup ([spec#952](open-telemetry#952)). - Fix current Resource merge rules in the specification, which most implementations violate ([oteps#208](open-telemetry/oteps#208), [spec#3382](open-telemetry#3382), [spec#3710](open-telemetry#3710)). - Allow semantic convention resource modeling to progress ([spec#605](open-telemetry#605), [spec#559](open-telemetry#559), etc). --------- Co-authored-by: Tigran Najaryan <[email protected]> Co-authored-by: jack-berg <[email protected]> Co-authored-by: Arve Knudsen <[email protected]> Co-authored-by: David Ashpole <[email protected]>
Extend the specification regarding Tracer and Meter creation based on the OTEP "Named Tracers And Meters" (https://github.com/open-telemetry/oteps/blob/master/text/0016-named-tracers.md)
Fixes #273