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

Define how providers handle identical creation calls #4146

Closed
wants to merge 20 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,14 +13,21 @@ release.

- Remove restriction that sampler description is immutable.
([#4137](https://github.com/open-telemetry/opentelemetry-specification/pull/4137))
- Define how `TracerProvider` handles identical `Tracer` creation calls.
([#4146](https://github.com/open-telemetry/opentelemetry-specification/pull/4146))

### Metrics

- Clarify prometheus exporter should have `host` and `port` configuration options.
([#4147](https://github.com/open-telemetry/opentelemetry-specification/pull/4147))
- Define how `MeterProvider` handles identical `Meter` creation calls.
([#4146](https://github.com/open-telemetry/opentelemetry-specification/pull/4146))

### Logs

- Define how `LoggerProvider` handles identical `Logger` creation calls.
([#4146](https://github.com/open-telemetry/opentelemetry-specification/pull/4146))

### Events

### Resource
Expand Down
8 changes: 8 additions & 0 deletions specification/logs/sdk.md
Original file line number Diff line number Diff line change
Expand Up @@ -72,6 +72,14 @@ working `Logger` MUST be returned as a fallback rather than returning null or
throwing an exception, its `name` SHOULD keep the original invalid value, and a
message reporting that the specified value is invalid SHOULD be logged.

For each unique set of identifying parameters, the non-identifying
parameters MUST be associated with the `Logger` at least once.
Currently, it is a user error to create `Logger`s with different
non-identifying parameter values (e.g. instrumentation scope attributes) but
the same identifying parameters. The SDK can handle such cases in its preferred
way. However, it MUST be documented that the behavior may change in future
releases, as this is currently an unsupported usage of the API.

**Status**: [Development](../document-status.md) - The `LoggerProvider` MUST
compute the relevant [LoggerConfig](#loggerconfig) using the
configured [LoggerConfigurator](#loggerconfigurator), and create
Expand Down
8 changes: 8 additions & 0 deletions specification/metrics/sdk.md
Original file line number Diff line number Diff line change
Expand Up @@ -128,6 +128,14 @@ working Meter MUST be returned as a fallback rather than returning null or
throwing an exception, its `name` SHOULD keep the original invalid value, and a
message reporting that the specified value is invalid SHOULD be logged.

For each unique set of identifying parameters, the non-identifying
parameters MUST be associated with the `Meter` at least once.
Currently, it is a user error to create `Meter`s with different
non-identifying parameter values (e.g. instrumentation scope attributes) but
the same identifying parameters. The SDK can handle such cases in its preferred
way. However, it MUST be documented that the behavior may change in future
releases, as this is currently an unsupported usage of the API.

When a Schema URL is passed as an argument when creating a `Meter` the emitted
telemetry for that `Meter` MUST be associated with the Schema URL, provided
that the emitted data format is capable of representing such association.
Expand Down
10 changes: 9 additions & 1 deletion specification/trace/sdk.md
Original file line number Diff line number Diff line change
Expand Up @@ -71,6 +71,14 @@ The input provided by the user MUST be used to create
an [`InstrumentationScope`](../glossary.md#instrumentation-scope) instance which
is stored on the created `Tracer`.

For each unique set of identifying parameters, the non-identifying
parameters MUST be associated with the `Tracer` at least once.
Currently, it is a user error to create `Tracer`s with different
non-identifying parameter values (e.g. instrumentation scope attributes) but
the same identifying parameters. The SDK can handle such cases in its preferred
way. However, it MUST be documented that the behavior may change in future
releases, as this is currently an unsupported usage of the API.

**Status**: [Development](../document-status.md) - The `TracerProvider` MUST
compute the relevant [TracerConfig](#tracerconfig) using the
configured [TracerConfigurator](#tracerconfigurator), and create
Expand Down Expand Up @@ -236,7 +244,7 @@ Thus, the SDK specification defines sets of possible requirements for
both the full span API as defined in the
[API-level definition for span's interface](api.md#span-operations) and
additionally must be able to retrieve all information that was added to the span
(as with *readable span*).
(as with _readable span_).

It MUST be possible for functions being called with this
to somehow obtain the same `Span` instance and type
Expand Down
Loading