Is there any plan to increase the instrument name length?

[norisk87]

Is your feature request related to a problem? Please describe.

I checked the history of increasing from 63 to 255.

Could consider the situation of using more than 255 instrument names?

https://github.com/open-telemetry/opentelemetry-java/pull/5697

Describe the solution you'd like

Unlimited, but I wish I could specify the settings.

Describe alternatives you've considered

Thanks to so many people, I'm using good functions well.

We have installed an openelemetry java agent in our service to use openelemetry and opensearchapm.

I got caught in instrument-name limit (255) causing WARN. Is there a plan to change the limit?

Additional context

No response

[jack-berg]

5697 reflected this change in the spec: https://github.com/open-telemetry/opentelemetry-specification/pull/3648

For us to increase it further, there would have to be another increase in the specification.

Any chance you can share details on which instrumentation is producing names longer than 255 characters?

[argon-kr]

oh, this problem is similar to the problem i had. so, I propose adding an automatic package name abbreviation feature to OpenTelemetry Java Instrumentation. This feature would automatically shorten long package names, preventing data loss and enhancing compatibility across all relevant systems. For instance, I have a very lengthy package name like this: storage.elasticsearch.myNewCommonRepository.selectItemIdsByStatusAndFieldsAndValues.common-db-common-host-common-subdomain-db-common-domain.com:12345.calls.max With such long package names, the feature could abbreviate it to something like s.e.m.s.c.max. This abbreviation could be provided as a configurable option, allowing users to enable or disable the feature as they see fit.

[jack-berg]

Its more appropriate to capture the package name in the scope (i.e. meter name, attributes) than in the instrument name. I would be surprised if the @open-telemetry/java-instrumentation-maintainers agreed make this a configurable option.

[breedx-splk]

I would be surprised if the @open-telemetry/java-instrumentation-maintainers agreed make this a configurable option.

Sorry, you mean wouldn't right? Wouldn't be surprised, because it seems useful and not entirely unexpected.

[jack-berg]

No I meant that I would be surprised. Embedding scope level information in an instrument name seems to be an exporter level concern. I.e. an exporter sending data to a backend without the notion of a scope might choose to prefix instrument names with scope name to disambiguate.

[norisk87]

Sorry for reading the comments late because of something else. If I could increase the increase the instrument name length, is there another way to avoid it? If WARN is not a problem, there will be no problem when using it, but if this is a problem with the use of an openelemetry agent, we have to think about how to avoid it.