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
auto-configuration not working #6389
Comments
To give a deeper explanation, by default, if the property "otel.traces.exporter" is not set, otlp is being used I understand that the more specific settings are for granular overrides, but how should I configure metrics to use prometheus by default, traces to not be sent by default and then use the same backend, via "otel.exporter", for both during deployment? |
This behavior is as specified in the specification, and hence is not a bug. (I'll remove the label). I think the way to achieve what you want is to just make sure that you are setting your properties to what you want in all cases, rather than trying to change the specified auto-configuration default to one that gets you into this jam. |
That's what I thought I did, setting the default to none so the deployer can override it if they want, but I don't see a good way to do it? My end goal would be the following;
This looks like it's impossible to do, but if you have a hint as to how I can do this in a way I missed, I'd love to hear it. |
No, what I'm saying is to not try to change the "default", but make sure you set what you want in all cases. By changing the default, you're changing the behavior in ways that won't support what you want. |
But the default is not working and logging errors. I may be stupid, hopefully!, but could you explain to me how to achieve my desired setup;
|
does this approach work for you? open-telemetry/opentelemetry-java-contrib#1276 |
Not really, by setting the default to The only thing I can think of to achieve the thing I want would be to check a couple env vars in our code, to decide if we want to set the default to To be even more precise, I want the following setup to work;
Currently, we're lucky that we only have traces enabled for otlp, as we do the following; private val tracingConfigured = System.getenv("OTEL_EXPORTER_OTLP_TRACES_ENDPOINT").isNullOrBlank().not()
[...]
val properties = mapOf(
"otel.metrics.exporter" to "prometheus",
"otel.exporter.prometheus.port" to "9090",
"otel.logs.exporter" to "none",
)
if (!tracingConfigured) {
logger.info { "tracingEndpoint not set, not sending traces." }
properties + ("otel.traces.exporter" to "none")
} else {
properties
} but as I said, this defeats a part of "autoconfigure" |
I was saying that you could just set all 3 signal-specific env vars always, and not try to coerce a "default" value if some particular env var isn't set. |
So you're saying what I want is not possible, I understand. If that is the desired situation, then I guess this can be closed? |
I believe that what you want is not in the semantics of the auto-configure module, no. If providing default properties won't work for you, then I think you might be out of luck. It doesn't seem (to me) that setting a few extra env vars should be too big a burden for an SRE running operations. |
Describe the bug
I have no
OTEL_EXPORTER_OTLP*_ENDPOINT
variables set, yet after starting up an exporter is created and logs errors;Steps to reproduce
Use the AutoConfiguredOpenTelemetrySdk
What did you expect to see?
Opentelemetry should not do anything when not configured to do so.
What did you see instead?
Opentelemetry tried to send spans somewhere
What version and what artifacts are you using?
Environment
Compiler: openjdk version "17.0.10" 2024-01-16
Additional context
Current workaround is to check various ENV vars for their existence and set
"otel.traces.exporter" to "none"
if not set, but that defeats the purpose of auto-configurationThe text was updated successfully, but these errors were encountered: