Skip to main content

Data Processing

Overview​

All data processing happens in OpsWorker's cloud, not in your cluster. The in-cluster agent only collects raw data; analysis is performed by the investigation engine.

From Alert to Investigation​

Before processing begins, an inbound alert travels through the ingestion path:

  1. The webhook reaches API Gateway (Bearer auth) and is placed on an SQS queue.
  2. The Alert Normalizer Lambda converts the alert to a common format and writes it to the per-organization alerts-{org} DynamoDB table.
  3. The Invocation Lambda evaluates each normalized alert against the organization's AlertRules. Filtering happens inside this Lambda; there is no separate "rule engine" component.
  4. Alerts that match a rule trigger the Strands agent graph, which runs the processing pipeline below.

Processing Pipeline​

1. Field Extraction​

  • Deterministic (regex-based): Field extraction is fully rule-based. It parses alert labels and annotations for fields such as namespace, pod, and severity. No LLM is involved in this step.
  • Amazon Nova is used elsewhere in the pipeline for fast routing and summarization, not for field extraction.

2. Topology Construction​

  • Builds a dependency graph from discovered resources
  • Breadth-first traversal: Pod → Service → Ingress, Pod → Deployment → ReplicaSet
  • Identifies which resources may contain the root cause

3. Configuration Validation​

Automated checks on resource configurations:

CheckDescription
Reference integrityDo service selectors match pod labels?
Contract matchingDo service ports align with container ports?
Fitness checksAre resource limits reasonable for the workload?

4. Issue Classification​

Categorizes the problem:

  • Configuration issue: Mismatched selectors, incorrect limits, missing env vars
  • Runtime issue: Application crash, memory leak, external dependency failure

5. Root Cause Analysis​

Multi-model AI analyzes all data:

  • Correlates signals across logs, events, and configurations
  • Identifies the underlying cause (not just the symptom)
  • Assesses confidence level based on evidence strength

6. Recommendation Generation​

Produces:

  • Root cause statement with supporting evidence
  • Immediate actions with specific kubectl commands
  • Preventive measures for long-term fixes

Multi-Model Strategy​

OpsWorker uses different AI models optimized for each stage:

StageModel TypeOptimization
Routing & summarizationFast (Amazon Nova on AWS Bedrock)Speed: classify and condense in low latency
Analysis & recommendationsReasoning (Claude on AWS Bedrock)Depth: complex correlation and root cause identification

Models run on AWS Bedrock; the direct Anthropic API is also supported. OpsWorker does not use Azure OpenAI or bring-your-own / OpenAI-compatible models.

Next Steps​