Merging resource attributes (system variables and environment variables)

[alexvanboxel]

In Java environment it makes sense to send some of the resource attributes through the system variables, ... and sone through

ideal to set via system properties (in docker image for example... setting name and version at build time.
service.name=my-app,service.version=1.2

ideal to set via env (example in k8s)
k8s.pod.uid=$(K8S_POD_UID),k8s.pod.name=$(K8S_POD_NAME),k8s.namespace.name=$(K8S_NAMESPACE_NAME)

last time I checked if you set one, the other is completely overridden. Looking at the above example it makes sense to merge bother the system variables and the environment variables. I think the spec doesn't say what the expected behavior is though. What's do you all think?

[jkwatson]

My gut tells me that this should be working already. Do you have an example of how you're setting up the resource auto-detectors that isn't working?

[jkwatson]

So... I guess it depends on what you're trying to do. If you're having the same OTEL_RESOURCE_ATTRIBUTES set via both system props and env vars... yes, that won't work today. Is that what you're trying to do, or is it some other resource auto-detector?

[jkwatson]

At any rate, I think it would be fine to change to code to merge them. If you'd like to create and issue (and maybe even a PR!) for that, I think that would be totally ok.

[anuraaga]

@alexvanboxel Do you mind filing an issue in the spec repo to ask what people think? We should make sure this behavior is consistent across languages. FWIW, I am inclined not to merge - almost all environment variables replace a system property setting, so merge behavior only happens for lists. I think this is inconsistent and hard to explain - environment variables always take precedence over properties is much simpler to explain / reason about.

[alexvanboxel]

I like consistency, but the biggest one I'm struggling with is service.name and service.version. In general, it's backed in stone. We want to freeze them in our build process and then at runtime add the k8s attributes at runtime.

It's all resource attributes, but it's like compile time vs runtime. I'll file an issue.

[trask]

@alexvanboxel ya, it would be nice to have separate env vars for those two, would be worth adding your thoughts to open-telemetry/opentelemetry-specification#709

[jkwatson]

Another approach would be to create your own resource provider that read your own env var/sys props to provide this information. Of course, you could also just write a little bit of startup code in your application to do that as well, without the complication of having a resource provider for it.