Named Tracers and Meters#264
Conversation
…ce-oss-contrib/opentelemetry-specification into named-tracers-and-meters
|
Related:
|
SergeyKanzhelev
left a comment
There was a problem hiding this comment.
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.
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.
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.
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 <4194920+tigrannajaryan@users.noreply.github.com> Co-authored-by: jack-berg <34418638+jack-berg@users.noreply.github.com> Co-authored-by: Arve Knudsen <arve.knudsen@gmail.com> Co-authored-by: David Ashpole <dashpole@google.com>
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 <4194920+tigrannajaryan@users.noreply.github.com> Co-authored-by: jack-berg <34418638+jack-berg@users.noreply.github.com> Co-authored-by: Arve Knudsen <arve.knudsen@gmail.com> Co-authored-by: David Ashpole <dashpole@google.com>
* 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 <4194920+tigrannajaryan@users.noreply.github.com> Co-authored-by: jack-berg <34418638+jack-berg@users.noreply.github.com> Co-authored-by: Arve Knudsen <arve.knudsen@gmail.com> Co-authored-by: David Ashpole <dashpole@google.com>
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