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

Named Tracers and Meters #264

Conversation

z1c0
Copy link
Contributor

@z1c0 z1c0 commented Sep 27, 2019

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

@Oberon00
Copy link
Member

Related:

specification/api-metrics.md Outdated Show resolved Hide resolved
specification/api-tracing.md Show resolved Hide resolved
specification/api-tracing.md Show resolved Hide resolved
Copy link
Member

@SergeyKanzhelev SergeyKanzhelev left a 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
Copy link
Member

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.

Copy link
Member

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

Copy link
Member

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.

@SergeyKanzhelev
Copy link
Member

@yurishkuro any more feedback on this PR? beyond #272 all other comments seems to be addressed. We need 1 more sign off here

@SergeyKanzhelev
Copy link
Member

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

@SergeyKanzhelev SergeyKanzhelev merged commit 18358d7 into open-telemetry:master Oct 3, 2019
@z1c0 z1c0 deleted the named-tracers-and-meters branch October 3, 2019 06:04
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 <[email protected]>
Co-authored-by: jack-berg <[email protected]>
Co-authored-by: Arve Knudsen <[email protected]>
Co-authored-by: David Ashpole <[email protected]>
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 <[email protected]>
Co-authored-by: jack-berg <[email protected]>
Co-authored-by: Arve Knudsen <[email protected]>
Co-authored-by: David Ashpole <[email protected]>
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 <[email protected]>
Co-authored-by: jack-berg <[email protected]>
Co-authored-by: Arve Knudsen <[email protected]>
Co-authored-by: David Ashpole <[email protected]>
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.

Integrate "Named Tracers and Meters" OTEP
5 participants