any chance?

Hiya @mrasu, sorry for the delay in replying –

Indeed, we started setting OTEL_RESOURCE_ATTRIBUTES which would break setups such as yours. This wasn't the intention, and I guess there's a few ways we could take to avoid collisions here: we could use a separate/custom env var for our instrumenting since we can make sure both ends look at the same place, or we could check for the env var on the CLI and append our attribute instead of just overwriting.
I'm open to opinions here (cc @milas @jsternberg @krissetto).

In the meantime, for your purposes, you could set your .env such as

MY_CUSTOM_ENV_VAR="service.namespace=opentelemetry-demo"

and your compose file such as

services:
  something:
    image: ubuntu
    command: tail -f /dev/null
    environment:
      OTEL_RESOURCE_ATTRIBUTES: ${MY_CUSTOM_ENV_VAR}

Hm.. right, so;

1. .env (again)
2. compose as CLI plugin, so may inherit env-vars that are set by docker CLI (and docker CLI doesn't use .env, so wouldn't even be aware the user is about to set SOME_ENV_VAR)
3. we don't check if OTEL_RESOURCE_ATTRIBUTES is set already (in either case), and assume it's not set, therefore overwriting any user-set option for OTEL?

Wondering if this one should either detect if it’s already set, or prepend the env-var instead of appending it;

I guess the overall issue to look for is;

• decide how we can best handle OTEL configuration (standard for OTEL is to use env-vars, but for the CLI that's sometimes more tricky, and I know that for some setups, we want to be able to set-up through configuration file(s), which can be depending on the docker context in use.
• but OTEL does allow configuration through env-vars, which means that in an environment where OTEL is already set-up we must be able to "play nice"
• ☝️ which could either mean; don't do anything if we detect anything OTEL-related in env-vars (but the list of OTEL-related env-vars may evolve over time)
• ☝️ or ... merge configs (but this may result in some franken-config 🧟 of defaults we set and those that are set in the environment

Hi there from 2025! 👋

So I am facing this issue when running the opentelemetry-demo docker-compose setup. It declares the OTEL_RESOURCE_ATTRIBUTES via .env and passes it via docker-compose. However, it gets overridden with OTEL_RESOURCE_ATTRIBUTES=docker.cli.cobra.command_path=docker%20compose, losing what I was putting there.

This environment variable is meant to be multi-value (hence is's called ATTRIBUTES, in plural). It allows comma-separating multiple attributes. The demo example here does it too.

So it looks like the way to go forward in @thaJeztah's analysis above is to merge configs. If you only add docker.cli.cobra.command_path (separating with comma if there's already stuff in the env var) attribute, you should be safe. Nothing else should be adding this attribute, and so there should be no franken-configs.

Just experienced this issue myself. I agree with suggestions that result in the end user being able to just set the OTEL_RESOURCE_ATTRIBUTES environment variable as standard according to OTel documentation and not have it overwritten.

I'm going to be looking at this. If I remember the intention correctly, that environment variable was supposed to be merged with an existing one but maybe it's just messed up? That was the reason we originally piggy-backed off this environment variable.

There are two similar issues that are impacting usage of this environment variable.

The first is that we aren't merging an existing variable with one set in the environment. This is pretty easy to fix and I already have some code ready for this, but it doesn't fix this problem.

The other issue is that environment variables clobber anything in the environment file for compose. The issue in this one isn't that we aren't merging an existing environment variable with the injected one. The injected one is creating an OTEL_RESOURCE_ATTRIBUTES value that is overwriting the one in the env file.

We can't really merge these ones without changing the behavior or creating special code to detect this specific environment variable.

Some solutions we can pursue.

1. Merge the existing variable with the one we produce (doesn't fix this but for correctness).
2. Filter docker.cli prefixed keys in OTEL_RESOURCE_ATTRIBUTES out and remove the environment variable if it is now empty.
3. Have docker/cli start setting a DOCKER_CLI_OTEL_RESOURCE_ATTRIBUTES with the intention that this replaces our current usage.
4. Have both docker/cli and plugins read and merge both of these environment variables together.

We can technically get away with just doing 1 and 2 but I think it might be good to just not use this environment variable for this purpose altogether. If we want a simpler but less backwards compatible alternative, we can also just stop populating OTEL_RESOURCE_ATTRIBUTES entirely and skip to DOCKER_CLI_OTEL_RESOURCE_ATTRIBUTES. But, this would require all downstream plugins to update to the latest version of CLI and release in lockstep with the primary CLI so it's simpler in terms of code but more complicated in terms of releasing.