service.name: replace app.kubernetes.io/component to app.kubernetes.io/name

[tetianakravchenko]

container with name: prometheus-server - has a service.name : prometheus - that is set from pod label app.kubernetes.io/name:

kubectl describe pod prometheus-server-server-64ddbf6c85-r7tk5 | grep "Labels:" -a5
...
Labels:           app.kubernetes.io/component=server
                  app.kubernetes.io/instance=prometheus-server
                  app.kubernetes.io/managed-by=Helm
                  app.kubernetes.io/name=prometheus
                  app.kubernetes.io/part-of=prometheus
                  app.kubernetes.io/version=v2.54.1

[tetianakravchenko]

@ChrsMark for some reason here was used app.kubernetes.io/component for service.name - it was introduced in the original version of the manifest, maybe you remember reasoning for that? or it was a mistake and it should be app.kubernetes.io/name ?

[ChrsMark]

If I remember correctly it was an assumption borrowed from OTel demo: https://github.com/open-telemetry/opentelemetry-helm-charts/blob/3a6fff3f065dafcdcf7041885c5d0d1bf61a1167/charts/opentelemetry-demo/values.yaml#L4-L14.

I'm not sure if that's coming from a spec definition or something so I think it's not a hard rule. However, whatever we choose we should ensure that it's the way forward. See open-telemetry/semantic-conventions#236

@rogercoll do you have maybe more context on this?

[tetianakravchenko]

thanks!
by those changes I am replicating ingest pipeline we use for logs - https://github.com/elastic/integrations/blob/main/packages/kubernetes/data_stream/container_logs/elasticsearch/ingest_pipeline/default.yml

and it seems to align with the candidates in open-telemetry/semantic-conventions#236

[ChrsMark]

My only concern is that OTel demo uses the app.kubernetes.io/component which might bring issues in signal correlation. I wonder if we could propose this as a change to OTel demo.

[gizas]

Can we have both labels?

[rogercoll]

My only concern is that OTel demo uses the app.kubernetes.io/component which might bring issues in signal correlation. I wonder if we could propose this as a change to OTel demo.

Good catch! I agree with you both, the OTel demo should be using app.kubernetes.io/name instead of the current app.kubernetes.io/component. At least based on the definition of this well-known attributes: https://kubernetes.io/docs/reference/labels-annotations-taints/ and SemConv.

Just created this issue upstream to track the changes: open-telemetry/opentelemetry-helm-charts#1383

[rogercoll]

LGTM, we will just need to be aware that with the otel-demo deployment the correlation will fail until we don't update the https://github.com/elastic/opentelemetry-demo/blob/main/kubernetes/elastic-helm/deployment.yaml#L6

[rogercoll]

My only concern is that OTel demo uses the app.kubernetes.io/component which might bring issues in signal correlation. I wonder if we could propose this as a change to OTel demo.

Good catch! I agree with you both, the OTel demo should be using app.kubernetes.io/name instead of the current app.kubernetes.io/component. At least based on the definition of this well-known attributes: https://kubernetes.io/docs/reference/labels-annotations-taints/ and SemConv.

Just created this issue upstream to track the changes: open-telemetry/opentelemetry-helm-charts#1383