Skip to main content

Achieving Kubernetes observability

A Kubernetes environment is a dynamic topology where containers come and go constantly, so simple status checks like "what is the CPU at right now" are not enough to deal with problems. You need observability that can trace "why is this Pod restarting" or "why is this service slow."

This guide explains how to combine Cluster, Pod, and Service layers with WhaTap Kubernetes Monitoring, and which menu to use when.

Four signals of observability​

To understand a Kubernetes environment, you need to look at the following four data types together:

Table | Four signals of observability
SignalRoleWhere to view in WhaTap
MetricResource usage and quantity trendsCluster, Node, and Pod dashboards
TraceInter-service call flow and latency segmentsTransaction trace
LogTime-stamped raw eventsContainer logs
EventK8s native events (Pod restarts, etc.)K8s event stream

A single data type alone rarely reveals the cause. For example, if you see a Pod CPU spike (Metric), you also need to check which request consumed the CPU at that moment (Trace), what the workload was doing (Log), and whether the scheduling changed (Event).

Unified perspective with WhaTap Kubernetes Monitoring​

WhaTap provides a unified view across three layers — Infrastructure (Cluster/Node) → Container (Pod) → Application (Service) — within a single project.

  • Cluster: cluster-wide resource and status summary
  • Node: per-worker-node CPU, memory, network, and disk
  • Pod / Container: per-container resource usage and restart history
  • Service (Application): WAS/app APM integration for trace and error analysis

This way infrastructure administrators and application developers can communicate over the same real-time data.

For details, see Introduction to Kubernetes monitoring.

Past-point analysis​

Trace, Metric, Log, and Event from a past moment (around a deploy or a specific incident) are collected and stored automatically, so you can revisit the situation as it was without reproducing it. You can sit down today and analyze "why did that Pod Evict at 3 AM yesterday."

Observation scenarios​

When a specific service slows down​

  1. Check abnormal response time and error rate on the Service dashboard.
  2. Use Transaction trace to inspect the call stack of a slow request — is the bottleneck a DB call or an external call?
  3. Check the container resources of the corresponding Pod — is CPU or memory exhausted?
  4. Check K8s events in the same time window for Pod restarts or scheduling changes.
  5. If needed, browse error messages in container logs.

When a Pod keeps restarting​

  1. Check the restart count and reason (OOMKilled, CrashLoopBackOff, etc.) in K8s events.
  2. Compare Pod memory usage and application logs from before the restart along the timeline.
  3. Cross-check the upstream Service dashboard for any traffic spikes.

Next steps​

Last updated on