opentelemetry.io
opentelemetry.io copied to clipboard
open-telemetry
Documentation of default exporters
open-telemetry/opentelemetry-specification#943 introduced the environment variable OTEL_EXPORTER to the SDK spec which is used for configuring the exporter. It defines otlp as the default value for this environment variable in specification/sdk-environment-variables.md.
This means that, without any further configuration, the SDK will set up the OTLP exporter and attempt exporting to localhost:55680 (i.e., the default defined in specification/protocol/exporter.md), right?
I find it a bit surprising that this default setup is not documented anywhere else but stated in the environment variable definition.
Should we document this more prominently elsewhere or can we expect users to find the env var definition and check that one to determine the default behavior?
Was this actually the intent? I think at least explicitly setting some environment variable should be required.
I'm not entirely sure if this variable should only have an effect when exporting is set up explicitly by the application but without specifying which exporter to use when setting up the TracerProvider, or if it should already do something by itself. In case of the latter, I would also find it surprising that by not specifying anything, a default pipeline including an exporter is set up. I could not tell from the PR reviews if this was the intention since that was not explicitly addressed there. We should clarify this in the spec. From the related issue open-telemetry/opentelemetry-specification#710 it sounds like this env var was mainly but not exclusively intended for auto instrumentation agents.
cc @trask
Is support for it optional? Or is it recommended to implement this in a contrib or otherwise external package? In order to implement this as specified the otlp, jaeger, zipkin, and prometheus exporters would need to be included as dependencies.
Yeah, good point about needing to include all of the exporters in order to implement this.
Makes sense for it to be optional.
Even in Java auto-instrumentation, we only plan to support this in our (default) -all distribution (which already includes all of those exporters).
@trask Could you also clarify the intention which seems unclear as per the comments above, please? I think we should document this a bit more precisely.
hey @arminru, the intention is to provide end users of Java auto-instrumentation with a way to select which exporter they want to use: https://github.com/open-telemetry/opentelemetry-java-instrumentation#exporters
I agree that implementing OTEL_EXPORTER env var support should be optional.
@trask So for that intention, it seems you would not need a default for the environment variable in the SDK, but rather you would set that default value in the agent if no override was provided?
Yup, we don't even need the SDK to support OTEL_EXPORTER at all (while we get most of our env var support from the SDK, we implement this OTEL_EXPORTER behavior entirely in the Java agent currently).
We just wanted the env var spec'd so that we would have consistency with any other auto-instrumentation or language SDK where this env var also makes sense.
As the specification is now, I believe SDKs themselves are required to support OTEL_EXPORTER (which I think makes sense, apart from the implicit default).
I'm not sure that SDKs should be required to support OTEL_EXPORTER due to the concern raised above:
In order to implement this as specified the otlp, jaeger, zipkin, and prometheus exporters would need to be included as dependencies
cc: @jkwatson
I think this is fine as an optional env var, and in java, it's fine just being supported in the agent.
@open-telemetry/technical-committee Not sure why this is after-ga? It seems like a quite important clarification that we are missing here. Should be at least allowed-for-ga IMHO.
Hello! We just added this recently in Python, and I agree this behavior should probably hopefully changed, or at least documented. This choice has already resulted in confusion for users.
In Python, we have a ConsoleExporter that I think is better default behavior: without any further configuration, the app will just print to stdout.
I see that the spec today doesn't include a requirement for an exporter that just writes to stdout, and there is no such option included in the OTEL_EXPORTER envvar.
How do people feel about either of these changes:
- add a ConsoleExporter specification into the spec
- modify the default to ConsoleExporter
My main concern with a default that assumes otlp is that people who are really new just want a small, concise example.
I think OTLP should be the default exporter. Printing to console is a very awkward & inefficient way - data will be mixed with logs, and require additional log scraping to actually show up in the tools/backends.
Hello, As a new user I was trying the auto-instrumentation python example , it initially threw me an error related to invalid credentials. It took some further digging to understand that setting an env variable OTEL_EXPORTER_OTLP_SPAN_INSECURE=True solves the problem. it did solve the first issue but I couldn't get an idea initially as nothing was getting printed in the console. probably as @toumorokoshi suggested, having a ConsoleSpanExporter helps to understand how the trace information looks especially for new users.
I think OTLP should be the default exporter. Printing to console is a very awkward & inefficient way - data will be mixed with logs, and require additional log scraping to actually show up in the tools/backends.
I think to clarify, I'm not advocating that a user runs their production application logging traces. I was more saying someone playing around with opentelemetry would find it much easier if the default was Console logging (can see their output).
I understand, but I think prod behavior should be the default, not the debugging behavior.
I think OTLP should be the default exporter.
+1. Also set the default destination to localhost and assuming the user has a local Otel Collector running as an agent then application to Agent connection will work automatically out-of-the box (Collector's default config is to accept OTLP on localhost).
I understand, but I think prod behavior should be the default, not the debugging behavior.
+1 to this too.
However, to help first time users we can print a helpful hint in the logs if we fail to send via OTLP. The hint can describe how to configure OTLP (or other exporters) correctly.
From a security perspective, it seems unwise to send any data over the network by default. Even if it's just localhost, there may be some port forwarding or there might actually be a collector running that forwards the data somewhere else. It would be good if at least some explicit setting is required from the user to indicate they actually want to export tracing data.
I assume it is user's responsibility to ensure that their development environment does not accidentally send data to an unexpected remote destination.
Perhaps open-telemetry/opentelemetry-specification#1193 is related; regarding the boundaries between SDK and auto-instrumentation.
