When an application team reports that a service is slow, and a platform team confirms that the cluster is healthy, both statements can be true at the same time. The application team is describing response times observed in the code. The platform team is describing node, pod, and resource level conditions. Neither statement is incorrect. They are simply describing different layers of the same system, using different data.
This is not primarily a matter of tooling. It is a difference in vocabulary, and it is one of the more common patterns in organizations running Kubernetes at scale.
Two Teams, Two Vocabularies
Platform and SRE teams generally work in the vocabulary of infrastructure, using terms such as nodes, pods, replicas, restarts, resource limits, and scheduling events. This vocabulary is built around reliability and capacity, and it is necessary for operating a cluster.
Application teams generally work in a different vocabulary, using terms such as transactions, exceptions, database queries, method level latency, and downstream dependency calls. This vocabulary is built around correctness and user facing performance.
Both are necessary. Neither is sufficient on its own to explain a given incident. When an issue spans both layers, as most production issues do, each team is naturally debugging from a different model of the system, and the two models do not always meet at the same point.
A pod restart, from a platform team's perspective, may simply be Kubernetes replacing an unhealthy container to preserve availability. From an application team's perspective, that same restart may have removed the stack trace needed to diagnose a memory leak. Neither team has done anything incorrectly. The two views of the event simply reflect different vantage points at the same moment.
How This Shows Up in Practice
This pattern does not usually appear as a single obvious event. It tends to appear as a set of recurring, familiar moments.
- Incident calls that begin with scope determination. Initial time is spent establishing whether the issue is infrastructure related or application related before root cause investigation begins.
- Escalations that move back and forth between teams. Platform teams confirm the cluster is operating normally and hand the issue to application teams; application teams confirm the code is functioning as expected and hand it back.
- Postmortems built from two separate timelines, one from cluster events and one from application logs, that are reconciled manually after the fact rather than existing as a single account during the incident itself.
These patterns reflect two teams working from different data sets with no common reference connecting them, rather than any shortfall in either team's effort.
What a Shared Reference Point Looks Like
Bringing these views together does not require either team to take on the other's responsibilities. It calls for a shared artifact that both teams can refer to during an incident, one that reflects both the infrastructure and application layers at once.
Distributed tracing serves this purpose well. A trace that follows a single request across services, containers, and databases is useful to an application engineer investigating a slow method, and it is equally useful to a platform engineer trying to determine whether that latency correlates with a scheduling event, node level resource pressure, or a recent deployment. The same artifact can answer both questions.
Dependency mapping serves a similar function at a structural level. When a platform team can see which services are actually calling which services in production, rather than relying on what an architecture diagram indicates should be happening, a common point of discussion during incidents is settled before the incident call begins.
The intent is not to replace infrastructure dashboards or application logs, but to provide a transaction level view that sits between them, one that both platform and application teams can reference and interpret consistently.
Establishing This as a Practice
Shared visibility is not established simply by deploying a tracing tool somewhere in the stack. It becomes a shared language only when both teams use it consistently as one. This generally depends on a few practices.
- Referencing traces during the incident. When distributed traces are reviewed as the incident unfolds, they become part of how the incident is actually resolved.
- Enabling self-service trace access. When retrieving a trace does not depend on another team's involvement, it stays useful during time sensitive investigation.
- Reviewing dependency maps regularly. Teams that periodically review actual service dependencies tend to spend less time during an incident establishing which services call which.
- Building instrumentation into deployment. When APM instrumentation is templated into deployment patterns, new services inherit consistent visibility by default rather than requiring it to be configured individually.
Where This Leads
Kubernetes gave platform teams a consistent way to operate infrastructure at scale. Extending that same consistency to how platform and application teams observe that infrastructure together, as a single view rather than two views reconciled afterward, is the next step for many organizations operating at that scale. Much of this comes down to how APM gets set up inside a Kubernetes cluster in the first place, since that groundwork determines whether tracing and instrumentation end up as a shared reference point or as something each team reaches for separately.
If your teams are still struggling to reconcile two conflicting perspectives on the same incident, try using the 30-day free trial of ManageEngine OpManager Nexus to view from a unified perspective.
