Skip to content

Define default value for OpenTelemetry Trace Exporter in auto-configuration #41841

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

Closed
ThomasVitale opened this issue Aug 13, 2024 · 4 comments
Closed
Labels
status: declined A suggestion or change that we don't feel we should currently apply

Comments

@ThomasVitale
Copy link

🎁 Enhancement

Context
Spring Boot application using OpenTelemetry for both metrics and traces.

Problem
The auto-configuration for Micrometer OTLP (providing support for OpenTelemetry Metrics) sets the exporter endpoint to http://localhost:4318/v1/metrics, in line with the common developer experience when running a Spring Boot application with the default configuration. However, the auto-configuration for the OpenTelemetry SDK (used for providing support for OpenTelemetry Traces) doesn't set any default value for the exporter endpoint. It used to be set to http://localhost:4318/v1/traces, but it was removed in 214f060 to allow using gRPC instead of HTTP. This behaviour is not the one I would expect from a Spring Boot auto-configuration and is also inconsistent with the Metrics auto-configuration.

Suggestion
It would be nice to bring back the default value for the OpenTelemetry Trace Exporter and find another way to allow replacing the HTTP exporter with a gRPC exporter, at least until #41213 is solved.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Aug 13, 2024
@wilkinsona
Copy link
Member

Thanks for the suggestion but I don't think we can do anything here. The suggestion you've made would be a (small) breaking change so the earliest that it could be made is in 3.4.x. #41213 is currently scheduled for that release so it would seem to be preferable to tackle that rather than having the churn of making the change proposed here and the change that would be needed for #41213 shortly thereafter. Have I misunderstood what you're proposing?

@wilkinsona wilkinsona added the status: waiting-for-feedback We need additional information before we can continue label Aug 13, 2024
@ThomasVitale
Copy link
Author

ThomasVitale commented Aug 13, 2024

Thanks for the quick answer. If #41213 is still scheduled for 3.4.x, then I agree that it wouldn't make sense to make the separate change suggested in this issue, and instead address it as part of the other task. I might have misunderstood the state of #41213 after it got put on hold.

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Aug 13, 2024
@wilkinsona
Copy link
Member

Even if #41213 slips to 3.5.x, I wouldn't want the default to change in 3.4.x and then change again in 3.5.x. It's been as it is now since 3.2.x. Thanks for the suggestion but I think it's better overall that we leave the default as it currently is.

@wilkinsona wilkinsona closed this as not planned Won't fix, can't repro, duplicate, stale Aug 13, 2024
@wilkinsona wilkinsona added status: declined A suggestion or change that we don't feel we should currently apply and removed status: waiting-for-triage An issue we've not yet triaged status: feedback-provided Feedback has been provided labels Aug 13, 2024
@ThomasVitale
Copy link
Author

Understood, thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

No branches or pull requests

3 participants