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.

Sign up for GitHub

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

Jump to bottom

Autoconfigure SHOULD append /v1/(traces|metrics) to OTEL_EXPORTER_OTLP_ENDPOINT #3650

Closed
Oberon00 opened this issue Sep 22, 2021 · 3 comments · Fixed by #3666
Closed

Autoconfigure SHOULD append /v1/(traces|metrics) to OTEL_EXPORTER_OTLP_ENDPOINT #3650

Oberon00 opened this issue Sep 22, 2021 · 3 comments · Fixed by #3666
Assignees
@jack-berg
Labels
autoconfiguration issues related to the autoconfiguration module Feature Request Suggest an idea for this project

Comments

@Oberon00
Copy link
Member

Oberon00 commented Sep 22, 2021 •
edited
Loading

See the description of "Endpoint (OTLP/HTTP)" at https://github.com/open-telemetry/opentelemetry-specification/blob/v1.6.1/specification/protocol/exporter.md#configuration-options:

When using OTEL_EXPORTER_OTLP_ENDPOINT, exporters SHOULD follow the collector convention of appending the version and signal to the path (e.g. v1/traces or v1/metrics), if not present already.

Note this does not apply to the signal-specific envvars.

This is actually an important SHOULD, because otherwise OTEL_EXPORTER_OTLP_ENDPOINT cannot sensibly be used because metrics and traces would be sent to the same URL.

Not sure about the "if not present already" part though, that seems like a spec defect, because configuring a URL ending with /v1/traces as endpoint for all signals would mean that metrics are also sent to /v1/traces, which makes no sense at all. Will file a spec issue.

EDIT: I should mention that I was made aware of this issue by @rypdal. Thank you!
@Oberon00 Oberon00 added Feature Request Suggest an idea for this project autoconfiguration issues related to the autoconfiguration module labels Sep 22, 2021
@jack-berg
Copy link
Member

Good catch! I'm happy to fix this.

@jack-berg jack-berg mentioned this issue Sep 23, 2021
Closed
@rypdal
Copy link

rypdal commented Sep 23, 2021

Thanks to @Oberon00 for discussion of the issue and specification. It applies to opentelemetry-dotnet as well. I'm going to fix it in a scope of this PR: open-telemetry/opentelemetry-dotnet#2316

@rypdal rypdal mentioned this issue Sep 23, 2021
Merged
3 tasks
@jack-berg jack-berg mentioned this issue Sep 27, 2021
Merged
@Oberon00 Oberon00 mentioned this issue Sep 28, 2021
Merged
@Oberon00
Copy link
Member Author

I created open-telemetry/opentelemetry-specification#1975 to clarify the spec.

tigrannajaryan pushed a commit to open-telemetry/opentelemetry-specification that referenced this issue Oct 4, 2021
@Oberon00
Clarify OTEL_EXPORTER_OTLP_ENDPOINT envvar for OTLP/HTTP. (#1975)
2d72f95 
The current wording of the OTLP endpoint config was confusing, especially the "if not present already" wording. Instead, clarify that we must always append when using the envvar for all signals (it was already clearly specified that the per-signal vars do not get the path appended).

This came up in open-telemetry/opentelemetry-java#3650 and again at open-telemetry/opentelemetry-java#3666 (comment).

Also make it a MUST (not SHOULD) since this kind of thing would be extremely annoying to have differences per-language in. Also, without appending, the variable cannot be used to configure more than one signal which would defeat its sole purpose.
tigrannajaryan pushed a commit to tigrannajaryan/opentelemetry-proto that referenced this issue Apr 20, 2023
@Oberon00 @tigrannajaryan
Clarify OTEL_EXPORTER_OTLP_ENDPOINT envvar for OTLP/HTTP. (#1975)
911ff13 
The current wording of the OTLP endpoint config was confusing, especially the "if not present already" wording. Instead, clarify that we must always append when using the envvar for all signals (it was already clearly specified that the per-signal vars do not get the path appended).

This came up in open-telemetry/opentelemetry-java#3650 and again at open-telemetry/opentelemetry-java#3666 (comment).

Also make it a MUST (not SHOULD) since this kind of thing would be extremely annoying to have differences per-language in. Also, without appending, the variable cannot be used to configure more than one signal which would defeat its sole purpose.
joaopgrassi pushed a commit to dynatrace-oss-contrib/semantic-conventions that referenced this issue Mar 21, 2024
@Oberon00
Clarify OTEL_EXPORTER_OTLP_ENDPOINT envvar for OTLP/HTTP. (open-telem…
3ed1bcc 
…etry#1975)

The current wording of the OTLP endpoint config was confusing, especially the "if not present already" wording. Instead, clarify that we must always append when using the envvar for all signals (it was already clearly specified that the per-signal vars do not get the path appended).

This came up in open-telemetry/opentelemetry-java#3650 and again at open-telemetry/opentelemetry-java#3666 (comment).

Also make it a MUST (not SHOULD) since this kind of thing would be extremely annoying to have differences per-language in. Also, without appending, the variable cannot be used to configure more than one signal which would defeat its sole purpose.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jack-berg jack-berg

Labels
autoconfiguration issues related to the autoconfiguration module Feature Request Suggest an idea for this project
Projects
None yet
Milestone
No milestone
3 participants
@Oberon00 @jack-berg @rypdal