Add opt-in option for k8sattributes to enrich well-known Kubernetes labels

[smithclay]

Component(s)

processor/k8sattributes

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

Per the proposed recommendation in open-telemetry/semantic-conventions#349, the kubernetes attribute processor should, in an opt-in basis, automatically enrich telemetry using Kubernetes well-known labels by mapping them to OpenTelemety resource attributes like service.name and service.version.

This helps end users uniformly adopt OpenTelemetry semantic conventions in Kubernetes environments and map pod metrics, traces, and logs to Kubernetes workloads identified by well-known labels like app.kubernetes.io/name.

Describe the solution you'd like

An opt-in configuration option, something like:

  k8sattributes:
    extract:
      wellKnownLabels: true

Which would functionally be equivalent to:

  k8sattributes:
    extract:
      labels:
          - tag_name: service.name
            key: app.kubernetes.io/name
            from: pod
          - tag_name: service.version
            key: app.kubernetes.io/version
            from: pod

Describe alternatives you've considered

This can be achieved right now through more verbose configuration, but it presumes the end-user is familiar with k8s conventions and otel conventions.

Additional context

see also open-telemetry/semantic-conventions#236

[github-actions]

Pinging code owners:

• processor/k8sattributes: @dmitryax @rmfitzpatrick @fatsheep9146 @TylerHelmuth

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[TylerHelmuth]

Since the equivalent statement can be written using the existing configuration and this is more about easy-of-use, I think this would be a good addition to the kubernetesAttributes preset in the collector helm chart.

[smithclay]

I'm a fan of adding to the kubernetesAttributes preset in the collector helm chart. Think this solves for the ease-of-use without needed to update the processor, but seems helpful for new users to explicitly mention the chart as a resource for recommended defaults, etc in the godocs/readme.

[TylerHelmuth]

Adding more examples/use cases to the README is a good idea.

[smithclay]

Closing in favor of open-telemetry/opentelemetry-helm-charts#905