Skip to main content

Root Cause Analysis

Overview​

OpsWorker identifies the underlying cause of an alert, not just the symptom. By correlating data across multiple Kubernetes resources, the AI distinguishes between surface-level indicators and the actual root cause.

How Root Cause Analysis Works​

Beyond the Alerting Resource​

When a pod crashes, the problem may not be in the pod itself. OpsWorker's topology discovery traces dependencies to find where the issue originates:

AlertSurface SymptomRoot Cause Found By OpsWorker
Pod CrashLoopBackOffPod keeps restartingOOM killed: memory limit 256Mi but app needs 512Mi
Service 503 errorsService returning errorsDeployment selector mismatch: pods not matching service selector after label change
Ingress timeoutIngress health check failingBackend service has 0 healthy endpoints: all pods in ImagePullBackOff
High CPU alertCPU utilization 95%HPA maxReplicas reached: manual scaling or limit increase needed

Correlation Across Resources​

OpsWorker correlates signals from multiple sources:

  • Logs: application errors, stack traces, connection failures
  • Events: Kubernetes events (scheduling, OOM kills, image pulls, probe failures)
  • Configuration: resource limits, selectors, environment variables
  • Topology: how resources are connected (pod, service, ingress chain) and whether each edge is wired correctly

Issue Classification​

Each investigation classifies the issue:

  • Wiring issue (topology edge): a mismatch on the connection between two resources, such as a service selector that no longer matches its pods, or a service port that does not line up with the container's target port. These are detected during topology and configuration validation, where each edge is checked and problem edges are flagged as alert-related. Wiring issues are a first-class root-cause category: a critical alert-related wiring issue routes the investigation straight to the config-remediation path.
  • Configuration issue: misaligned or incorrect resource specs, such as wrong resource limits or missing environment variables
  • Runtime issue: application crash, memory leak, external dependency failure

This classification guides the type of recommendations generated.

Influenced by Memory and Your Context​

Root cause findings and recommendations are not produced in a vacuum. During final analysis, OpsWorker injects relevant cluster-level and organization-level memory (facts it has learned about your environment) and any user-provided context from a manual, free-text investigation. This sharpens findings: a known quirk of your cluster or the problem statement you typed can change which cause is most likely and which fix is recommended.

Confidence Levels​

OpsWorker provides a confidence level with each root cause analysis, indicating how certain the AI is about its findings. Higher confidence comes from:

  • Clear error signals in logs or events
  • Direct correlation between alert and observed behavior
  • Configuration issues that can be definitively identified

What You Get​

Each root cause analysis includes:

  1. Root cause statement: a clear explanation of what went wrong and why
  2. Evidence: the specific data points that support the conclusion (log lines, events, config values)
  3. Affected resources: all resources involved in the issue, not just the alerting one
  4. Confidence level: how certain the analysis is in its findings

Next Steps​