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

protocol/exporter: Configuration options MAY be implemented by exporter, SDK, or separate component #3730

Merged
merged 5 commits into from
Oct 30, 2023

Conversation

pellared
Copy link
Member

@pellared pellared commented Oct 20, 2023

Fixes #3721

Why

The Go SIG is working towards stabilizing the OTLP metrics exporter.

The Go SIG would prefer to manage the exporter environment variables through a distinct package: https://pkg.go.dev/go.opentelemetry.io/contrib/exporters/autoexport. This approach is akin to Java Autoconfigure. The rationale behind this decision is as follows:

  1. If users aim to utilize the OTEL_EXPORTER_OTLP_PROTOCOL and OTEL_TRACES_EXPORTER, we aim to support all the values documented in the specification. We want to ensure that users are not prone to encountering runtime errors if a protocol driver hasn't been registered in the code.
  2. Simultaneously, we wish to avoid applications to depend on all exporter implementations defined in the specification.

Currently, it is not clear of such design is in compliance with the specification.

What

Define that configuration options MAY be implemented by exporter, SDK, or separate component.

While this PR may be seen as a breaking change, because of the way how the languages adopted the specification I would say that this is a "clarification" or "adopting to the reality".

Here is how different languages currently implement the OTLP configuration options.

.NET

Configuration options implemented by exporter.
Side note: Per-signal endpoint configuration options are not implemented.

Source code:

C++

Most configuration options implemented by exporter.
However, the *_PROTOCOL env vars are not implemented at all. See: open-telemetry/opentelemetry-cpp#971.

Source code:

Erlang

Configuration options implemented by exporter.

Source code:

Go

Most configuration options implemented by exporter.
However, the *_PROTOCOL env vars are implemented by a separate component (autoexport)

Source code (package docs):

Java

Configuration options implemented by an autoconfigure component.

Source code:

JavaScript

Most configuration options implemented by exporter.
However, the *_PROTOCOL env vars are implemented by a separate component (opentelemetry-sdk-node)

Source code:

PHP

Configuration options implemented by exporter.

Source code:

Python

Most configuration options implemented by exporter.
However, the *_PROTOCOL env vars are implemented by the SDK.

Source code:

Ruby

Most configuration options implemented by exporter.
However, the *_PROTOCOL env vars are implemented by the SDK.

Source code:

Rust

Configuration options implemented by exporter.

Source code:

Swift

Env vars not supported.

Previous work and discussions

@pellared pellared changed the title protocol/exporter: Clarify that the env vars do not need to be implemented directly in the exporter protocol/exporter: Configuration options MAY be implemented by exporter, SDK, or separate component Oct 20, 2023
Copy link
Member

@tigrannajaryan tigrannajaryan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a clarification/guidance, not a breaking change. LGTM.

@carlosalberto
Copy link
Contributor

Let's mention this PR at the maintainers meeting today, and unless we get a complain, let's merge today.

@pellared
Copy link
Member Author

pellared commented Oct 26, 2023

I created #3738 which may supersede this PR.

However, I would prefer to merge this one first. I can remove the changes from this PR as part of #3738. I feel that #3738 may need more time for reviews and refinements.

@carlosalberto carlosalberto merged commit e023ccd into open-telemetry:main Oct 30, 2023
6 checks passed
pellared added a commit to pellared/opentelemetry-specification that referenced this pull request Oct 30, 2023
pellared added a commit to pellared/opentelemetry-specification that referenced this pull request Oct 30, 2023
carlosalberto pushed a commit that referenced this pull request Oct 30, 2023
Editorial

Sorry for my copy-paste error.
carlosalberto pushed a commit that referenced this pull request Nov 7, 2023
@pellared pellared mentioned this pull request Nov 7, 2023
carlosalberto pushed a commit to carlosalberto/opentelemetry-specification that referenced this pull request Oct 31, 2024
…er, SDK, or separate component (open-telemetry#3730)

Fixes
open-telemetry#3721

## Why

The Go SIG is working towards stabilizing the OTLP metrics exporter.

The Go SIG would prefer to manage the exporter environment variables
through a distinct package:
https://pkg.go.dev/go.opentelemetry.io/contrib/exporters/autoexport.
This approach is akin to [Java
Autoconfigure](https://github.com/open-telemetry/opentelemetry-java/tree/main/sdk-extensions/autoconfigure).
The rationale behind this decision is as follows:

1. If users aim to utilize the `OTEL_EXPORTER_OTLP_PROTOCOL` and
`OTEL_TRACES_EXPORTER`, we aim to support all the values documented in
the specification. We want to ensure that users are not prone to
encountering runtime errors if a protocol driver hasn't been registered
in the code.
2. Simultaneously, we wish to avoid applications to depend on all
exporter implementations defined in the specification.

Currently, it is not clear of such design is in compliance with the
specification.

## What

Define that **configuration options MAY be implemented by exporter, SDK,
or separate component**.

While this PR may be seen as a breaking change, because of the way how
the languages adopted the specification I would say that this is a
"clarification" or "adopting to the reality".

Here is how different languages currently implement the OTLP
configuration options.

### .NET

Configuration options implemented by exporter.
Side note: Per-signal endpoint configuration options are not
implemented.

Source code: 
-
https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/src/OpenTelemetry.Exporter.OpenTelemetryProtocol

### C++

Most configuration options implemented by exporter.
However, the `*_PROTOCOL` env vars are not implemented at all. See:
open-telemetry/opentelemetry-cpp#971.

Source code: 
-
https://github.com/open-telemetry/opentelemetry-cpp/tree/main/exporters/otlp

### Erlang

Configuration options implemented by exporter.

Source code:
-
https://github.com/open-telemetry/opentelemetry-erlang/tree/main/apps/opentelemetry_exporter

### Go

Most configuration options implemented by exporter.
However, the `*_PROTOCOL` env vars are implemented by a separate
component (autoexport)

Source code (package docs):
- https://pkg.go.dev/go.opentelemetry.io/contrib/exporters/autoexport
- https://pkg.go.dev/go.opentelemetry.io/otel/exporters/otlp/otlptrace

### Java

Configuration options implemented by an autoconfigure component.

Source code:
-
https://github.com/open-telemetry/opentelemetry-java/tree/main/sdk-extensions/autoconfigure
-
https://github.com/open-telemetry/opentelemetry-java/tree/main/exporters/otlp/all/src/main/java/io/opentelemetry/exporter/otlp

### JavaScript

Most configuration options implemented by exporter.
However, the `*_PROTOCOL` env vars are implemented by a separate
component (opentelemetry-sdk-node)

Source code:
-
https://github.com/open-telemetry/opentelemetry-js/tree/main/experimental/packages/opentelemetry-sdk-node
-
https://github.com/open-telemetry/opentelemetry-js/tree/main/experimental/packages/exporter-trace-otlp-http

### PHP

Configuration options implemented by exporter.

Source code:
-
https://github.com/open-telemetry/opentelemetry-php/tree/main/src/Contrib/Otlp

### Python

Most configuration options implemented by exporter.
However, the `*_PROTOCOL` env vars are implemented by the SDK.

Source code:
-
https://github.com/open-telemetry/opentelemetry-python/blob/main/opentelemetry-sdk/src/opentelemetry/sdk/_configuration/__init__.py
-
https://github.com/open-telemetry/opentelemetry-python/tree/main/exporter

### Ruby

Most configuration options implemented by exporter.
However, the `*_PROTOCOL` env vars are implemented by the SDK.

Source code:
-
https://github.com/open-telemetry/opentelemetry-ruby/blob/main/sdk/lib/opentelemetry/sdk/configurator.rb
-
https://github.com/open-telemetry/opentelemetry-ruby/tree/main/exporter/otlp-http

### Rust

Configuration options implemented by exporter.

Source code:
-
https://github.com/open-telemetry/opentelemetry-rust/tree/main/opentelemetry-otlp

### Swift

Env vars not supported.

### Previous work and discussions

-
open-telemetry#3721
-
open-telemetry#3722
carlosalberto pushed a commit to carlosalberto/opentelemetry-specification that referenced this pull request Oct 31, 2024
Editorial

Sorry for my copy-paste error.
carlosalberto pushed a commit to carlosalberto/opentelemetry-specification that referenced this pull request Oct 31, 2024
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.

Clarify if the OTLP exporter has to support all protocol related env vars