Split OTEL_EXPORTER to OTEL_TRACE_EXPORTER and OTEL_METRICS_EXPORTER #1318
Conversation
| @@ -77,9 +77,9 @@ See [OpenTelemetry Protocol Exporter Configuration Options](./protocol/exporter. | |||
|
|
|||
| | Name | Description | Default | | |||
| | ------------- | ---------------------------------------------------------------------------- | ------- | | |||
| | OTEL_EXPORTER | Exporter to be used, can be a comma-separated list to use multiple exporters | "otlp" | | |||
| | OTEL_EXPORTERS | Exporters to be used as a comma separated list | "otlp" | | |||
There was a problem hiding this comment.
It seems a bit annoying that we support exporting to two different exporters at the same time, but not two differently configured exporters of the same kind (e.g. zipkin + jaeger works, but not two different jaeger URLs). But this is a edge case anyway, because contrary to propators, you should usually only have a single exporter. Maybe that was the reason for the name?
There was a problem hiding this comment.
It seems to already be common to specify two exporters, one for trace and one for metrics (e.g., otlp_span and prometheus). Should we have two variables for each and drop the ability to set a list for either of them to simplify things? We also get the win of not having the otlp_span and otlp_metrics variables.
I agree it's extremely rare to want to set two exporters for the same signal, and it would still be possible programmatically if really needed.
There was a problem hiding this comment.
I like the idea of having two variables OTEL_SPAN/TRACE_EXPORTER and OTEL_METRIC_EXPORTER 👍
I think this could also make implementation simpler. For example right now, probably you might have one place that searches the metric exporter and another place that searches the span exporter, and if there is an unknown exporter you might not even be able to warn the user because it might just be an exporter for another signal.
There was a problem hiding this comment.
It was definitely an annoyance I preferred not to deal with :)
There was a problem hiding this comment.
Anyone else that likes signal-specific exporters, please thumbs up and after a couple more votes I'll rework the PR.
There was a problem hiding this comment.
Went ahead and split them up. Wondering if it means others should be e.g., OTEL_TRACE_EXPORTER_JAEGER_AGENT_HOST
anuraaga
changed the title
|
@open-telemetry/specs-approvers Please review. This is a small yet important change, that I'd like to have a lot of eyes on it ;) |
| We define environment variables for setting a single exporter per signal. SDKs SHOULD provide a means to | ||
| set multiple exporters for a signal programmatically. |
There was a problem hiding this comment.
I am confused. First it says setting "a single exporter". Then it says set "multiple exporters". Is it "single" or "multiple"?
There was a problem hiding this comment.
The difference is whether it's an environment variable or programmatically. Not sure how to reword it to be less confusing but let me know if you have an idea :) Or if this point isn't helpful (doc is about env variables) I can delete it too.
There was a problem hiding this comment.
not helpful here - SDK API requirements should be in one place.
…ification into exporter-
…ification into exporter-
Co-authored-by: Francis Bogsanyi <francis.bogsanyi@shopify.com>
Fixes #1309
Fixes #1313
Changes
Splits
OTEL_EXPORTERinto two variables that only accept a single value. This makes the syntax of the variable consistent with others (singular name, singular value) and removes some corner cases in configuration caused by the previous list (multiple jaeger exporters accept different format for endpoint, push / pull metrics exporters can't be enabled at the same time, inconsistency in not having a way of enabling multiple exporters of a same type).