opentelemetry-collector-contrib: [processor/k8sattributes] k8s.deployment.name attribute can be set to a wrong value

k8s.deployment.name attribute value is taken from the pod name using regexp. This is not a robust approach. In some scenarios it can set the attribute to a wrong value. For example a Stateful Set called sts-test will create a pod called sts-test-1, telemetry from that pod will get the attribute k8s.deployment.name: sts which is incorrect, k8s.deployment.name should not be set for such pod.

There are two ways to solve the problem:

  1. Make the regexp more strict. This will lower chances for getting a wrong attribute, but it’s impossible to completely eliminate the chances with the regexp approach

  2. Use the k8s API to fetch an owner of the pod, check if it’s replicaset controlled by a deployment, then set the correct value for k8s.deplyment.name attribute. This is a robust approach, but we need to make sure it doesn’t introduce a significant computational overhead and load on k8s API.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 1
  • Comments: 15 (15 by maintainers)

Most upvoted comments

@fatsheep9146 will you work on trying the Option 2?

No problem, I will start working on this. @dmitryax

But the judgements above are all basic on logic, I think to ensure the judgements we should first implements option 2 and test it in some test environment to see the real overhead change?

Yes we can start with option 1. Then can evaluate option 2 with addition of k8s.deployment.uid attribute.

But the judgements above are all basic on logic, I think to ensure the judgements we should first implements option 2 and test it in some test environment to see the real overhead change?

Yes we can start with option 1. Then can evaluate option 2 with addition of k8s.deployment.uid attribute.

I agree ❤️ , I will do the same thing with CronJobs

@fatsheep9146 Option 1 looks good to me. And we are fetching the replicaset name from the owners already