Skip to content
AutoObserve
Design Partner

RUNTIME EVIDENCE

Kubernetes Map workload identity and runtime topology.

Kubernetes exposes where production work runs — pods, services, namespaces and deployments. AutoObserve maps that runtime context onto telemetry so investigations start with topology, not guesswork.

Evidence
Pods · Services · Deployments
Source
Kubernetes API
Enables
Runtime topology
Status
GA
See the evidence received ↓View architecture →

Read Kubernetes deployment docs →

Kubernetes cluster

  • Pods
  • Services
  • Namespaces

  1. AutoObserve

  2. Runtime topology

  3. Identity

  4. Correlation

  5. Investigation

WHY THIS INTEGRATION MATTERS

Telemetry without runtime context is incomplete.

Metrics and logs tell you something happened. Kubernetes tells you where — which pod, service and namespace carried the failure. AutoObserve connects both.

  • Runtime topology

    Map services to the pods and namespaces that run them during an incident window.

  • Workload identity

    Resolve checkout-api to the deployment and replica set that changed.

  • Blast-radius reasoning

    Understand which neighbouring workloads share nodes, namespaces or labels.

  • Deployment context

    Connect rollout events to latency spikes without manual kubectl correlation.

EVIDENCE RECEIVED

Pods, services, deployments and namespaces

Kubernetes metadata becomes runtime evidence — linked to telemetry identity so investigations know where production work runs.

  • Pods
  • Services
  • Deployments
  • Namespaces

  1. Discover

    Watch cluster workloads and map services to running pods.

  2. Identity

    Attach namespace, deployment and pod metadata to telemetry.

  3. Topology

    Build runtime graph for blast-radius and dependency reasoning.

  4. Investigate

    Start incidents with pod/service context already resolved.

HOW AUTOOBSERVE USES THIS EVIDENCE

Runtime metadata becomes investigation context.

Kubernetes does not replace telemetry — it grounds it. AutoObserve links API metadata to metrics, logs and traces inside one production model.

Provides

  1. Pods
  2. Services
  3. Deployments
  4. Namespaces

AutoObserve creates

  1. Runtime topology
  2. Workload identity
  3. Blast-radius context
  4. Change correlation

Kubernetes is where production runs. AutoObserve is how you understand it.

FIT INTO YOUR CLUSTER

Connect Kubernetes without replacing your observability stack.

AutoObserve reads cluster metadata alongside telemetry you already collect — in-cluster, multi-cluster or via Helm.

AutoObserve agent watches the API server from inside the cluster.

  1. Kubernetes cluster

  2. AutoObserve agent

  3. AutoObserve

QUICK START

Connect Kubernetes runtime evidence

Deploy AutoObserve into your cluster and confirm workload metadata resolves for services you already instrument.

  1. Deploy AutoObserve

    Install via Helm or Kubernetes manifest into the cluster you want to observe.

    Kubernetes deployment guide →

  2. Connect telemetry

    Ensure OpenTelemetry or your Collector exports to AutoObserve — runtime metadata enriches existing signals.

    Connect OpenTelemetry →

  3. Verify topology

    Confirm checkout-api and peer services appear with pod and namespace context in production evidence.

    Architecture overview →

WHAT SUCCESS LOOKS LIKE

Runtime context resolved. Topology ready for investigation.

Success means services map to pods and namespaces — not merely that an agent is running.

  • Services discovered

    checkout-api and dependencies appear in the runtime graph.

  • Pods mapped

    Active pods link to the service handling production traffic.

  • Namespaces resolved

    Production and staging workloads separate cleanly in context.

  • Deployments tracked

    Rollout events align with investigation time windows.

REAL INCIDENT

Same checkout spike — runtime topology in focus.

The canonical checkout-api degradation, with pod, service and namespace context highlighted — where the failure ran, not just that latency rose.

  1. Metric

    14:31:00

    Checkout latency +184%

Walk through the evidence chain · 1/6

Evidence step 1 of 6

TROUBLESHOOTING

Common Kubernetes metadata failures

  • Problem

    Pods not appearing in topology

    Likely cause

    Agent lacks permission to list pods in target namespaces.

    Resolution

    Verify RBAC grants for pod/service/deployment list and watch across observed namespaces.

    Verify

    checkout-api pods appear in runtime context within one sync window.

  • Problem

    Stale deployment version in context

    Likely cause

    Metadata sync lag after rollout or cached workload state.

    Resolution

    Confirm agent health and widen investigation window to include rollout time.

    Verify

    Deployment version matches the active ReplicaSet during the incident.

  • Problem

    Services missing namespace labels

    Likely cause

    Multi-namespace scope not configured on the cluster connector.

    Resolution

    Include all production namespaces in the connector scope.

    Verify

    Namespace appears on service identity for checkout-api.

PRODUCTION INTELLIGENCE

How Kubernetes contributes to production understanding

Each metadata class enables a distinct runtime investigation capability.

EvidenceEnables
PodsWorkload location
ServicesTraffic endpoints
DeploymentsRollout correlation
NamespacesEnvironment separation

DESIGN PARTNERS

Validate this evidence source with your production stack.

Design partners connect real evidence sources and validate investigation workflows before GA — with direct engineering access.

Become a Design PartnerRead Kubernetes deployment docsBecome a Design Partner