[OTEL] rename deployment.environment to deployment.environment.name

[herrBez]

Premise

The semconv 1.27 (released on 2nd August 2024) renamed the semconv field deployment.environment to deployment.environment.name.

Actual Change

In this BREAKING CHANGE commit we adopt the new semantic convention introduced with version 1.27. Read more in the related disscussion:

elastic/opentelemetry#489

Related issues

@theletterf already created PRs to adjust the documentation of the EDOT SDK, but the changes do have effect if we also change the actual component templates.

• Deal with deployment.environment.name vs deployment.environment coherently opentelemetry#489
• Rename attribute elastic-otel-php#309
• Rename attribute elastic-otel-java#887 and semconv correction elastic-otel-java#885
• Rename attribute elastic-otel-node#1171
• Rename attribute elastic-otel-python#427

[axw]

How will this work with older instrumentation that continues to produce deployment.environment? I don't think we can just drop support for the older schema version.

[herrBez]

This is a question for the PM 😅 . I do think that after 1 year and two months it's time to adopt the new naming convention to be semconv compliant. Further, this field is not just a field but it's crucial for the service.environment that is used in the APM application to switch between different environments.

The issue I see is that we have different naming conventions in different part of the documentation/website and external documentations like OpenTelemetry Operator correctly say to use the new one https://github.com/open-telemetry/opentelemetry-operator?tab=readme-ov-file#configure-resource-attributes-with-annotations.

I agree that it's not easy to switch, but it's time to find a coherent solution to avoid compounding this problem with more and more adoption of EDOT.

[axw]

Don't get me wrong, I definitely want to update to the new field too, but we can't just break ingestion like this. We need to be graceful about it, and make sure that existing users are not immediately broken. Ideally we would have a way to alias service.name to either/or field, and phase out the old one over time.

ES|QL Views are coming, which I think may provide a solution for this.

[axw]

@herrBez sounds good, thanks. We can always reopen.

[herrBez]

Yes. I will close the issue. It turns out we deal with this renaming in the elasticapmprocessor but in our default configuration this is only called for the traces and this causes a mismatch between logs and metrics.

I will close the PR for now.