Add OTEL_SERVICE_VERSION

[carlosalberto]

Similarly to OTEL_SERVICE_NAME, I was wondering if we could add this one as well (for context, we at Lightstep leverage this and currently have to use our own custom env var).

I do remember a conversation back in the day (I think @bogdandrutu and @Oberon00 chimed in) when it came to what made OTEL_SERVICE_NAME special, and its siblings not (service namespace, service version). Happy to discuss!

[MikeGoldsmith]

Raising this again, we (Honeycomb) also utilise this field and would like to see it as a formal environment variable in the spec.

[pellared]

Related to https://github.com/open-telemetry/opentelemetry-specification/issues/3025

We could allow setting resource attributes usingfollowing pattern OTEL_RESOURCE_[KEY]=[value] where the "KEY" would have to be transformed by making it lowercase and replacing _ with .. A similar pattern is used in OTel Java Automatic Instrumentation for disabling instrumentations: https://opentelemetry.io/docs/instrumentation/java/automatic/agent-config/#suppressing-specific-agent-instrumentation. OTEL_SERVICE_NAME could have higher priority than OTEL_RESOURCE_SERVICE_NAME.

[tedsuo]

If we do anything with dynamic env var names, it should align with what we're doing in the config SIG.

[RassK]

I wouldn't rush also with specific environment names, otherwise there will be 3 different ways and 3 different priorities for the same thing.

[carlosalberto]

So we already have the very related OTEL_SERVICE_VERSION env var, so I don't find this to be a problem, specially given this would be a small change. I agree on not rushing this though, as this would directly impact the core Spec. So let's take our time discussing it if people are interested.

[naseemkullah]

So we already have the very related OTEL_SERVICE_VERSION env var, so I don't find this to be a problem, specially given this would be a small change.

I take it you mean OTEL_SERVICE_NAME - since this issue is about the lack of OTEL_SERVICE_VERSION

I agree on not rushing this though, as this would directly impact the core Spec. So let's take our time discussing it if people are interested.

I am interested, 💯 we should have this, what's there to discuss? its in fact weird to have support to configure the svc name via env var but not the service version.

every lang can just take what they do with OTEL_SERVICE_NAME and repeat the pattern with OTEL_SERVICE_VERSION, bingo bango done

[trask]

hi @naseemkullah!

check out https://github.com/open-telemetry/opentelemetry-specification/issues/2891#issuecomment-1289241503

and see https://github.com/open-telemetry/opentelemetry-specification/issues/3752 for concrete reasons why we don't want to introduce any new env vars at this point

you will be able to set service.version (and any other) resource attribute in the new file-based configuration, e.g. https://github.com/open-telemetry/opentelemetry-configuration/blob/9c6803ab9e6a2f3c764fa8cda01cccee7dee746c/examples/kitchen-sink.yaml#L408-L416

[austinlparker]

We're gonna close this because at this point we do not wish to introduce any new environment variables, and the forthcoming config work will render the issue moot (as you will be able to set the value there, as seen in @trask's comment)