[processor/k8sattribute] Optionally add labels and annotations from node as resource attributes in the k8sattributes processor

[jinja2]

Component(s)

processor/k8sattributes

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

Some node labels like the topology or arch type of node, might provide useful insight into telemetry from applications. Being able to filter application performance metrics by the zone the pods are running in, can be useful for application developers to identify degradation in an availability zone due to cloud provider outage for e.g.

Describe the solution you'd like

I'd like to be able to add labels and annotations from the node as additional resource attributes on telemetry processed through the k8s attributes processor.

k8sattributes:
  labels:
    - tag_name: availability_zone
      key: topology.kubernetes.io/zone
      from: node

Describe alternatives you've considered

No response

Additional context

No response

[github-actions]

Pinging code owners:

• processor/k8sattribute: @dmitryax @rmfitzpatrick

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

[jinja2]

/label processor/k8sattributes

[swiatekm]

On one hand, this is genuinely useful.

On the other hand, you can make the same argument for attaching labels and annotations from every single resource type connected to the Pod: Deployments, Jobs, etc. The concern I have is whether we're also open to adding those, because in that case we should probably work out both a generic implementation and a generic way of configuring these.

That's not really a vote against implementing this, if someone wants to, just a thought about the future.

[dmitryax]

I believe this is a valid ask. It'll also allow using a k8s attributes processor for filtering/changing data coming from particular nodes.

This should be implemented in a way that it doesn't introduce any memory overhead if the feature is not being used

On the other hand, you can make the same argument for attaching labels and annotations from every single resource type connected to the Pod: Deployments, Jobs, etc. The concern I have is whether we're also open to adding those, because in that case we should probably work out both a generic implementation and a generic way of configuring these.

It's a valid concern, but I don't think that labels/annotations from job, deployment, daemonset, etc are as useful as node attributes. If there is a need for them, we can consider a generic approach later.

[dmitryax]

@jinja2, let us know if you can work on this

[jinja2]

Thanks @dmitryax @swiatekm-sumo for the feedback. Users tend to have similar set of metadata on pods and their controllers, so I don't think we need to add similar feature objects like deployments, etc. until requested as Dmitrii mentioned. I can work on adding support for node attributes.

[swiatekm]

In terms of implementation, it's worth noting that labels and annotations can change at any time. So we need to treat attributes from Node labels the same way we do Namespaces.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• processor/k8sattributes: @dmitryax @rmfitzpatrick @fatsheep9146

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