Add a namespaced tag (`executor.name`) to `ExecutorServiceMetrics` to avoid collisions with generic `name` tag

[evg-tso]

Please describe the feature request.
ExecutorServiceMetrics (and TimedExecutor, TimedExecutorService, TimedScheduledExecutorService) all use "name" as the tag key for identifying the executor pool.
From here:

this.tags = Tags.concat(tags, "name", executorServiceName);

I'd like Micrometer to also emit a more specific tag like executor.name or pool.name alongside the existing name tag.

Rationale
name is a very generic tag key. In our setup we use Micrometer for executor metrics but bridge them to OpenTelemetry via the micrometer-1.5 instrumentation library and export through an OTEL Collector. Somewhere along that pipeline, a name attribute gets injected with different semantics (maybe by one of the collector's processors or resource detectors), and it collides with Micrometer's name tag on the executor metrics. This makes it hard to query by pool name without adding custom relabeling workarounds.

OpenTelemetry's naming guidelines recommend namespacing attributes to avoid exactly this. A tag like executor.name would be specific enough to not clash with anything.

The existing name tag should stay for backward compatibility. The new one would just be an additional, unambiguous alternative.

Additional context
None.

[shakuzen]

Thanks for opening the issue and providing all the details. We could do something like that, but then everyone pays the (small) cost of duplicating the tag when not everyone needs it. An alternative you could consider without any changes to Micrometer is using a MeterFilter to do this for your applications that need it.

OpenTelemetry's naming guidelines recommend namespacing attributes to avoid exactly this. A tag like executor.name would be specific enough to not clash with anything.

The ExecutorServiceMetrics predates OpenTelemetry, and those guidelines are for OpenTelemetry semantic conventions. As far as I'm aware, there isn't a semantic convention that covers the metrics ExecutorServiceMetrics provides - perhaps there should be. If there were one, we could use a MeterConvention to make it more customizable, as we've done for other things where there is a stable OpenTelemetry semantic convention.

Somewhere along that pipeline, a name attribute gets injected with different semantics (maybe by one of the collector's processors or resource detectors), and it collides with Micrometer's name tag on the executor metrics.

It's probably worth tracking down what it is and questioning why it isn't following the OpenTelemetry semantic convention guidelines. Injecting a name tag on (presumably) every meter is much more potential to cause issues than a not very specifically named tag on a small group of meters.

We can consider this request, but it would help to understand the users that are affected and if it can't easily be fixed on the side that's injecting the name attribute that clashes. Would you be able to investigate that? Or if you can provide a minimal reproducer, we might be able to investigate.

[evg-tso]

Thanks for the detailed response! 🙏

A few thoughts:

then everyone pays the (small) cost of duplicating the tag when not everyone needs it

The cardinality wouldn't increase since executor.name would always carry the same value as name. The only cost is a few extra bytes per data point for the additional key+value pair.
If there's a discussion for a v2 of the library, maybe this could be a good segue into a deprecation process.

An alternative you could consider without any changes to Micrometer is using a MeterFilter to do this for your applications that need it.

That works for a single service, but we have 10s of services across separate repos. So we'd either copy-paste the same filter everywhere, or create an internal shared library to wrap this. Both work, but it feels like solving upstream what could be a small change in Micrometer.

As far as I'm aware, there isn't a semantic convention that covers the metrics ExecutorServiceMetrics provides - perhaps there should be.

The reason I'm using Micrometer for executor metrics and bridging via the micrometer-1.5 instrumentation library is because OTEL doesn't have semantic conventions for executor services or thread pools.
There's no OTEL-native way to get these metrics today. So the bridging path is really my only option.
And in that path, a generic name tag is asking for trouble.

It's probably worth tracking down what it is and questioning why it isn't following the OpenTelemetry semantic convention guidelines. Injecting a name tag on (presumably) every meter is much more potential to cause issues than a not very specifically named tag on a small group of meters.

I'll try to track that down.
But I think regardless of what's happening on my side, name with no namespace is going to keep causing collisions as more people bridge Micrometer into OTEL pipelines.

Separately, I also opened a comment on #1680 requesting an executor.type tag. If there's appetite for richer tags on executor metrics, maybe these could be addressed together.