Code change:
expectContinue(t, w, w.doProbe(ctx), msg) expectResult(t, w, results.Success, msg) } <del> func TestGetPodLabelName(t *testing.T) { testCases := []struct { name   string pod    *v1.Pod result string }{ { name: "Static pod", pod: &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: "kube-controller-manager-k8s-master-21385161-0", }, }, result: "kube-controller-manager-k8s-master-21385161-0", }, { name: "Deployment pod", pod: &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name:         "coredns-845757d86-ccqpf", GenerateName: "coredns-845757d86-", Labels: map[string]string{ apps.DefaultDeploymentUniqueLabelKey: "845757d86", }, }, }, result: "coredns", }, { name: "ReplicaSet pod", pod: &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name:         "kube-proxy-2gmqn", GenerateName: "kube-proxy-", }, }, result: "kube-proxy", }, } for _, test := range testCases { ret := getPodLabelName(test.pod) if ret != test.result { t.Errorf("Expected %s, got %s", test.result, ret) } } } </del>

Related discussion:
text: The metric used to report acutal pod in the label , but now I see the podname prefix only. The full pod name in the label, so I can trace the metric to the failing pod. Check raw api and verify the actual pod name with uids. <details</detailsAzure AKS <details</detailsNo response No response No response_
/sig node
/triage accepted /priority important-soon /cc As discussed this is a change in functionaloty that wasn't highlighted in release notes. Need to decide on what do do with it. I understand it's a change of functionality. what is the side effect of this for you? Does the label without last part not informational enough?
I've been using the metric in my custom grafana dashboard that shows CPU, RAM, IO usage of pods with graph of increases in probes. If the apps are stable, the probe graph looks steadily. I can see if some irregularities in system metrics are influencing probes of respective pod. Also, if readiness probe is failing, the pod is removed from service, but is not restarted so I must have knowledge of pods with failing readiness probes. I attach the screenshot of my graph. ! So I'd welcome the possibility to pair the probes with exact pod and thank you for looking into it.
are we thinking that this resulted in an undesirable change? Spologies for being a bit late to reply, I'm returning from a brief paternity leave staycation.
This issue is labeled with but has not been updated in over 90 days, and should be re-triaged. Important-soon issues must be staffed and worked on either currently, or very soon, ideally in time for the next release. You can: Confirm that this issue is still relevant with (org members only) Deprioritize it with or Close this issue with For more details on the triage process, see /remove-triage accepted
Well this is awkward... I still believe the actual behavior does not respect the intended idea...
This issue makes it hard to link probe metrics with right pods. The value of pod label in and are also inconsistent with how it is used in other kubelet metrics, see: vs Definitely a bug, regression since 1.25.
I can't get anyone to look at the fix/revert: you may have better luck
/milestone v1.28
discussion in
You've pushed it through, congrats!