# Correlating Kubernetes with Application Telemetry

**URL:** <https://discuss.kubernetes.io/t/correlating-kubernetes-with-application-telemetry/35221>\
**Category:** General Discussions\
**Tags:** observability\
**Created:** [September 14, 2026, 11:19pm UTC](https://discuss.kubernetes.io/t/correlating-kubernetes-with-application-telemetry/35221 "2026-09-14T23:19:49Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ruchir\_Jha](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/ruchir_jha/32/18448_2.png) [@Ruchir\_Jha](https://discuss.kubernetes.io/u/Ruchir_Jha)\
**Post date:** [September 14, 2026, 11:19pm UTC](https://discuss.kubernetes.io/t/correlating-kubernetes-with-application-telemetry/35221/1 "2026-09-14T23:19:49Z")

</div>

Curious how people handle this in practice.

Say I’m looking at a latency spike in my observability tool and grouping it by `k8s.deployment.name`. One deployment is clearly the outlier.

At that point I usually want to know what was happening underneath it: which pods were running, whether one restarted, whether there was a rollout, what nodes those pods were on, whether a ConfigMap changed, what Kubernetes events fired, etc.

The annoying part is that most of that information exists, but I end up leaving the chart and reconstructing the context manually with `kubectl`, the Kubernetes dashboard, events, and logs.

**How are people doing this today?** Do you have something that preserves the relationship between application telemetry and the Kubernetes objects behind it, or is jumping between tools basically the normal workflow?