I'm not sure OTEL_SERVICE_NAME should always be injected with inject-sdk

[mikebell90]

Component(s)

No response

Describe the issue you're reporting

I believe I undestand the general motivation, however in cases where the OTEL SDK already sets values internally (such as java, I assume others), or there is long standing business logic emanating it, this basically forces it via 12 factor. Whereas in these cases, it would be nice for the 12 factor to be an override escape hatch but not set by the operator. Currently I don't know of anyway around this.

Again, I agree in a 100% 12 factor world this is fine.

What I'd like

1. Operator doesn't set
2. If user CHOOSES to set OTEL_SERVICE_NAME stack takes as primary, but other wise determines it through its own providers
3. If none of those a sane fallback.

Instead I think the operator is taking this too far.

Yes we could turn off inject-sdk, but we would LIKE the protocol, endpoints, and pod_uid (which we use for join against node exporter, since with some cni, ip doesn't work). And yes we could write our own, or create own "meta" more important override. But it makes me a bit sad as is.

Starting discussion here, so I can be told I'm crazy ;)

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[iblancasa]

If I'm not mistaken, precedence is:

1. Explicit SDK configuration (code)
2. Resource attributes passed to the SDK
3. OTEL_SERVICE_NAME environment variable
4. Default (unknown_service)

So, I guess it should not be a problem. Maybe just for those situations where you are creating a container image hardcoding the OTEL_SERVICE_NAME environment variable.

[mikebell90]

I'll double verify but this didn't appear to be the case. OTEL_SERVICE_NAME sometimes took precedence over app specified or sdk configured. I'll keep open to check this out.