Named Tracers and Meters #264
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ce-oss-contrib/opentelemetry-specification into named-tracers-and-meters
z1c0
requested review from
AloisReitbauer,
bogdandrutu,
c24t,
carlosalberto,
iredelmeier,
reyang,
SergeyKanzhelev,
songy23,
tedsuo,
tigrannajaryan and
yurishkuro
as code owners
|
Related:
|
bogdandrutu
reviewed
Sep 27, 2019
bogdandrutu
approved these changes
Sep 27, 2019
yurishkuro
reviewed
Sep 27, 2019
SergeyKanzhelev
approved these changes
Sep 30, 2019
bogdandrutu
reviewed
Oct 1, 2019
| 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 |
This was referenced Oct 3, 2019
This was referenced Jan 8, 2020
SergeyKanzhelev
pushed a commit
to SergeyKanzhelev/opentelemetry-specification
that referenced
this pull request
Feb 18, 2020
* 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
TuckTuckFloof
pushed a commit
to TuckTuckFloof/opentelemetry-specification
that referenced
this pull request
Oct 15, 2020
carlosalberto
pushed a commit
to carlosalberto/opentelemetry-specification
that referenced
this pull request
Oct 21, 2024
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>
carlosalberto
pushed a commit
to carlosalberto/opentelemetry-specification
that referenced
this pull request
Oct 23, 2024
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>
carlosalberto
pushed a commit
to carlosalberto/opentelemetry-specification
that referenced
this pull request
Oct 31, 2024
* 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
carlosalberto
pushed a commit
to carlosalberto/opentelemetry-specification
that referenced
this pull request
Oct 31, 2024
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>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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