-
Notifications
You must be signed in to change notification settings - Fork 888
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
Change default OTLP endpoint to use http:// scheme #2014
Change default OTLP endpoint to use http:// scheme #2014
Conversation
See this comment: #1895 (comment) |
Co-authored-by: Nikita Salnikov-Tarnovski <gnikem@gmail.com>
Note, I considered adding some explicit language like "Default values are chosen to provide an out-of-the-box experience for sidecar usage" but left it out. Let me know if something like that makes sense / could be helpful. |
The point of this PR was to get more clarity to help with #1895 since it's smaller scope, a merge or not merge on this would clear up the path to your PR either way. |
I think it is not necessary because the sidecar is not the only deployment configuration when this is suitable. For example http to localhost is also the correct default for apps deployed on a VM/physical host with a local Collector installed as an agent. I think it is a reasonable approach to make sure the default values are consistent around the assumption that there is a Collector running on the localhost. However I believe it is important to ensure it is not easy to accidentally send insecurely to a non-local host. If we accept this PR the defaults will be:
When the destination is not the localhost (i.e. sending directly to a backend or to an intermediary Collector on a different host) then at least the If instead they decide to use grpc to send to a non-local host, then they will have to specify at least So, it looks good to me. |
Thanks, definitely - I've generally meant both container and non-container uses of localhost when using the term sidecar. One reason is probably because in Java land the word agent as a daemon concept causes some grief vs javaagent so avoid it ;) But we're on the same page I think. |
open-telemetry/opentelemetry-specification#2014 changed the default scheme for the OTLP endpoint from `https` to `http`. This updates our default.
* fix: Default scheme for OTLP endpoint open-telemetry/opentelemetry-specification#2014 changed the default scheme for the OTLP endpoint from `https` to `http`. This updates our default. * fix tests * fix stubs
Changes
Changes the default scheme for OTLP exporters to http:// because the default host is
localhost
.With the additional language that SDKs may choose a different default, actually it stops being a breaking change to update this default. I argue that the current default has no use case - it is extremely rare to use TLS with a localhost connection. This prevents the defaults to provide an out-of-the-box experience for any practical situation. It is a better experience if they can provide an OOB experience for something at least. Or otherwise I don't think we would want to have any defaults at all.
While this still seemed relatively harmless, I'm finding that it can cause difficulty in reasoning out other changes, such as in #1895. All the variables should be defined with some target experience in mind - currently there isn't, but the use of
localhost
seems to strongly indicate a target of sidecar.