Remove resource/k8s processor and use k8sattributes processor for service attributes

[ChrsMark]

This PR removes the resource/k8s processor in honour of the k8sattributes processor that provides native support for the Service attributes.

This change is aligned with the respective Semantic Conventions' guidance: https://opentelemetry.io/docs/specs/semconv/non-normative/k8s-attributes/#service-attributes

This is also aligned with the logic the OpenTelemetry Operator applies:

• https://github.com/open-telemetry/opentelemetry-operator?tab=readme-ov-file#how-servicename-is-calculated
• https://github.com/open-telemetry/opentelemetry-operator?tab=readme-ov-file#how-serviceversion-is-calculated

Potential breaking change

The k8sattributes processor does not override service attributes if those are already set. Hence, this change only affects use-cases that were relying on the enrichment that the resource/k8s does. This should be mainly logs and metrics since the SDKs usually set those attributes on their own.

With this change the service.version calculation is not affected at all. The service.name calculation now gives priority to k8s.{deployment, daemonset, ...}.name before using the k8s.container.name. That's the only possible "breaking" change but should not be really impactful.

This PR requires k8sattributes processor to be at least v0.127.0. v0.127.0 was introduced by #8511 to main and 8.19.x.

[mergify]

This pull request does not have a backport label. Could you fix it @ChrsMark? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-./d./d is the label that automatically backports to the 8./d branch. /d is the digit
• backport-active-all is the label that automatically backports to all active branches.
• backport-active-8 is the label that automatically backports to all active minor branches for the 8 major.
• backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[rogercoll]

LGTM

Do we know if there's been any proposal to remove the original extracted attributes? All matching signals will have two resource attributes with the same value

[ChrsMark]

LGTM

Do we know if there's been any proposal to remove the original extracted attributes? All matching signals will have two resource attributes with the same value

There is no such proposal so far.
The fact that service.* attributes are derived from other existing attributes does not necessarily mean that original attributes should be deleted, right?

[swiatekm]

Are we sure this doesn't affect any of the content for K8s Otel Observability?

[ChrsMark]

Ah @rogercoll did you mean the ones extracted at https://github.com/elastic/elastic-agent/blob/main/deploy/helm/edot-collector/kube-stack/values.yaml#L120C1-L126C26? I think we can remove them as well since they were deleted anyways in resource/k8s processor. I will fix that.

[gizas]

I dont see a problem as long as service.version and service.name are populated. Reading the old issues (1, 2) we just want to mimic what Agent had in order to support the inventory page. Only side effect from this change is that we might have diffrent names/versions because we change slightly the logic but is ok I think.

To be on safe side, can you please add the https://opentelemetry.io/docs/specs/semconv/non-normative/k8s-attributes/#service-attributes on the changelog in order our users to have access to the logic? Maybe also explain the fields in the description.

I agree, we can delete app.label.name and app.label.version

[elastic-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarQube

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: ccb1781

History

• 💛 Build #22898 was flaky 5e35b85
• 💔 Build #22882 failed 48f4ccb

cc @ChrsMark