RootCause AI — API

Collaborative AI Agents for Root Cause Detection in Network Telemetry

---

Concept

SRE and DevOps teams drown in alert noise. They spend hours manually correlating metrics, logs, and traces across Datadog, Splunk, and Grafana to diagnose a single incident — while the service bleeds.

RootCause AI is an API-first microservice that ingests OpenTelemetry-formatted telemetry data and returns a structured root cause hypothesis in a single HTTP call. Under the hood, multiple specialised AI agents analyse their slice of the signal in parallel, then a consensus layer synthesises their findings into one actionable answer with a confidence score.

The result ships to your existing alerting stack (Slack, PagerDuty, or any webhook) automatically — no dashboard pivoting required.

---

Architecture

Client (Datadog / PagerDuty alert → webhook)
        │
        ▼  POST /v1/ingest  (JWT Bearer)
┌─────────────────────────────────────────────────────┐
│                TelemetryController                  │
│                  (Spring MVC)                       │
└────────────────────┬────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────┐
│                 TelemetryService                    │
│  1. Persist TelemetryEvent (H2 / PostgreSQL + JPA)  │
│  2. Invoke AgentOrchestrator                        │
│  3. Virtual Thread → NotificationService            │
└────────────────────┬────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────┐
│              AgentOrchestrator                      │
│   Executors.newVirtualThreadPerTaskExecutor()        │
│                                                     │
│  ┌─────────────────────┐  ┌──────────────────────┐  │
│  │  MetricsAnomalyAgent│  │   LogPatternAgent    │  │
│  │  (CPU, mem, errors) │  │  (ERROR/FATAL logs)  │  │
│  └──────────┬──────────┘  └──────────┬───────────┘  │
│             │ Resilience4j CB         │ Resilience4j CB
│             ▼                        ▼              │
│         LlmFeignClient (OpenAI-compatible API)      │
│              [heuristic fallback when offline]      │
└────────────────────┬────────────────────────────────┘
                     │ consolidate()
                     ▼
           RootCauseHypothesisRecord
           { rootCause, confidence, severity, evidence }
                     │
                     ▼ (Virtual Thread, fire-and-forget)
          NotificationService  →  Slack / PagerDuty / Generic webhook

Key Design Decisions

Concern	Solution
High concurrency ingest	Virtual Threads (Executors.newVirtualThreadPerTaskExecutor())
LLM resilience	Resilience4j Circuit Breaker per agent + deterministic heuristic fallback
Auth	Stateless JWT (HMAC-SHA256 via jjwt 0.12.x), validated by JwtAuthenticationFilter
Webhook fan-out	Fire-and-forget on a Virtual Thread; failures are logged, not propagated
Data persistence	Spring Data JPA + H2 (default) / PostgreSQL (production)
HTTP client for webhooks	Spring Framework 7 RestClient (synchronous, no Reactor needed)
LLM communication	Spring Cloud OpenFeign 4.2.x with global auth interceptor

---

Endpoints

Authentication

POST /v1/auth/token

Obtain a JWT. No auth required.

Request:

{ "apiKey": "my-tenant-api-key" }

Response 200:

{ "token": "eyJhbGci...", "type": "Bearer" }

---

Telemetry Ingest + Analysis

POST /v1/ingest

Ingests OpenTelemetry-formatted data and returns a root cause hypothesis.

Headers: Authorization: Bearer <jwt>

Request body:

{
  "traceId": "4bf92f3577b34da6a3ce929d0e0e4736",
  "serviceName": "checkout-service",
  "environment": "production",
  "version": "2.4.1",
  "metrics": [
    { "name": "cpu_usage",    "value": 92.5, "unit": "%" },
    { "name": "error_rate",   "value": 8.3,  "unit": "%" },
    { "name": "response_time_ms", "value": 3200, "unit": "ms" }
  ],
  "logs": [
    { "severityText": "ERROR", "severityNumber": 17,
      "body": "DB connection timeout after 30s",  "timestampUnixNano": 1713300000000000000 },
    { "severityText": "FATAL", "severityNumber": 21,
      "body": "CircuitBreaker OPEN on payment-service", "timestampUnixNano": 1713300005000000000 }
  ],
  "spans": [
    { "spanId": "abc123", "operationName": "POST /checkout",
      "status": "ERROR", "startTimeUnixNano": 1713300000000000000, "endTimeUnixNano": 1713300003200000000 }
  ]
}

Response 201 Created:

{
  "hypothesisId": "a3f1c2d4-...",
  "traceId": "4bf92f3577b34da6a3ce929d0e0e4736",
  "serviceName": "checkout-service",
  "rootCause": "Database connection pool exhaustion causing cascading payment-service failures",
  "description": "Multi-agent collaborative analysis results:\n• [MetricsAnomalyAgent] Confidence 78%: ...\n• [LogPatternAgent] Confidence 82%: ...",
  "severity": "HIGH",
  "confidenceScore": 0.80,
  "agentFindings": [ ... ],
  "evidence": [ ... ],
  "analyzedAt": "2026-04-17T10:00:05Z"
}

---

Webhook Management

GET /v1/webhooks — list all configured webhooks

GET /v1/webhooks/{id} — get a specific webhook

POST /v1/webhooks — create a new webhook target

Request body:

{
  "name": "slack-production",
  "url": "https://hooks.slack.com/services/T000/B000/xxxx",
  "type": "SLACK",
  "active": true
}

Response 201:

{ "id": 1, "name": "slack-production", "url": "...", "type": "SLACK", "active": true, "createdAt": "..." }

PUT /v1/webhooks/{id} — update URL / active flag

%%INLINE13%% — remove a webhook (%%INLINE14%%)

---

Configuration Reference

Add any of these to application.yml to override defaults:

# JWT
jwt:
  secret: "your-production-secret-min-32-chars"
  expiration: 86400000        # 24 h in milliseconds

# LLM provider (OpenAI-compatible)
app:
  llm:
    api-url: https://api.openai.com/v1
    api-key:  sk-xxxx
    model:    gpt-4o-mini

# Production database (H2 used automatically when absent)
spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/rootcause
    username: rootcause
    password: secret
  jpa:
    hibernate:
      ddl-auto: validate
    database-platform: org.hibernate.dialect.PostgreSQLDialect

---

How to Run

Prerequisites

• JDK 25
• Maven 3.9+

Quick start (H2 in-memory, no LLM key needed)

cd solutions/2026-04-17-rootcause-ai-api
mvn spring-boot:run

The application starts on http://localhost:8080.

Step-by-step test

# 1. Get a JWT
TOKEN=$(curl -s -X POST http://localhost:8080/v1/auth/token \
  -H "Content-Type: application/json" \
  -d '{"apiKey":"test-tenant"}' | jq -r .token)

# 2. Register a webhook (optional)
curl -s -X POST http://localhost:8080/v1/webhooks \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"test","url":"https://httpbin.org/post","type":"GENERIC","active":true}'

# 3. Ingest telemetry and receive a hypothesis
curl -s -X POST http://localhost:8080/v1/ingest \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "traceId":"trace-001","serviceName":"payment-service","environment":"production",
    "metrics":[{"name":"cpu_usage","value":93.0,"unit":"%","timestampUnixNano":0}],
    "logs":[{"severityText":"ERROR","severityNumber":17,"body":"DB timeout","timestampUnixNano":0}],
    "spans":[]
  }' | jq .

With a real LLM

LLM_KEY=sk-xxxx mvn spring-boot:run \
  -Dspring-boot.run.jvmArguments="-Dapp.llm.api-key=$LLM_KEY"

When app.llm.api-key is set, each agent calls the configured LLM for richer analysis. When it is absent or the circuit is open, agents fall back to deterministic heuristics.

---

Business Analysis

Problem & Market

Alert fatigue costs the average SRE team 3-5 hours per incident in manual correlation time (DORA metrics). For a SaaS company with 99.9% SLA targets, every additional minute of MTTR is a liability.

Value Proposition

RootCause AI targets Series A–B SaaS companies with ≥3 microservices and a dedicated Platform/SRE function. The proposition is simple: reduce MTTR by 60–80% by automating the first-responder correlation step.

Monetization

Tier	Price	Includes
Starter	$299/mo	50k ingest calls, 1 webhook
Growth	$999/mo	500k ingest calls, 10 webhooks, custom LLM model
Enterprise	custom	Unlimited, VPC deploy, SLA

Competitive Moat

• Data flywheel: each hypothesis can be rated by the SRE (correct / incorrect).

Fine-tuning on customer-specific failure patterns creates a defensible moat.

• Integration depth: pre-built exporters for Datadog, Prometheus, and OpenTelemetry

Collector reduce onboarding friction to < 1 hour.

• API-first: no UI to build or maintain; embeds into existing PagerDuty / Opsgenie

runbooks as a single POST call.

---

References

• OpenTelemetry Specification
• JJWT 0.12.x Documentation
• Resilience4j Circuit Breaker
• Spring Cloud OpenFeign
• Spring Framework 7 RestClient
• Virtual Threads — JEP 444
• arxiv cs.AI — latest papers

---

FinOps Analysis para RootCause AI

Resumen Ejecutivo

RootCause AI, una micro-startup que ofrece análisis de causa raíz de incidentes mediante agentes de IA, presenta un modelo de negocio con un margen de beneficio inicial proyectado del 92%. Este alto margen es el resultado de una propuesta de valor B2B premium y un modelo API-first con bajos costos operativos fijos.

Desglose de Costos Mensuales (Estimación Inicial)

• Costos de APIs Externas (LLM - OpenAI gpt-4-turbo): ~$345

* Estimación de uso: ~30 millones de tokens/mes (basado en 10 clientes, 50 análisis/mes/cliente, 3 agentes/análisis, con un promedio de 20k tokens de entrada y 1k de salida por llamada de agente). Costo de Input: 30M tokens ($10/M tokens) = $300 Costo de Output: 1.5M tokens ($30/M tokens) = $45

• Costos de Infraestructura Cloud (AWS Baseline): ~$45

* EC2 (t3.small): ~$25/mes (para la aplicación Spring Boot) * RDS (db.t3.micro PostgreSQL): ~$15/mes * CloudWatch (logs y métricas básicas): ~$5/mes

• Total de Costos Mensuales Estimados: ~$390

Proyección de Ingresos Mensuales

• Modelo de Monetización: API-first SaaS, cobro por análisis de incidente.
• Precio por Análisis: $10 por análisis de causa raíz.
• Volumen Inicial: 10 clientes activos, cada uno generando 50 análisis de incidentes al mes.

Ingreso Mensual Estimado: 10 clientes 50 análisis/cliente * $10/análisis = $5,000

Margen de Beneficio

• Ingresos: $5,000
• Costos: $390
• Beneficio Neto: $4,610

Margen de Beneficio: (($4,610 / $5,000) 100) = 92%

Estrategias de Optimización FinOps

Para mantener este alto margen y escalar de manera eficiente, se recomiendan las siguientes optimizaciones:

1. Optimización del Consumo de LLM (Prioridad Alta):

* Selección Dinámica de Modelos: Implementar un sistema que evalúe la complejidad del incidente o la confianza del análisis inicial para elegir entre %%INLINE19%% (más económico) y %%INLINE20%% (más potente). Usar gpt-4o-mini como opción predeterminada para el 80% de los casos puede reducir drásticamente los costos. Pre-procesamiento Inteligente: Utilizar modelos de lenguaje más pequeños o técnicas de NLP tradicionales para resumir, filtrar o extraer entidades clave de los datos de telemetría antes* de enviarlos al LLM principal. Esto reduce el número de tokens de entrada. * Caché de Hipótesis y Patrones: Desarrollar un sistema de caché para almacenar y reutilizar las hipótesis de causa raíz generadas para patrones de incidentes recurrentes, evitando llamadas innecesarias al LLM. * Ingeniería de Prompts y Compresión: Optimizar continuamente los prompts para ser más concisos y directos, utilizando técnicas de compresión o reformulación para transmitir la misma información con menos tokens. * Batching para Análisis no Críticos: Si existen análisis que no requieren respuesta inmediata, agruparlos y procesarlos en lotes durante horas de menor demanda, lo que podría aprovechar descuentos por volumen o modelos de precios diferentes.

1. Optimización de Infraestructura Cloud (Medio Impacto):

* Migración a Serverless: Reemplazar el EC2 y el RDS por servicios serverless como AWS Lambda para la API y la orquestación, y AWS Aurora Serverless v2 para la base de datos. Esto elimina los costos fijos y escala automáticamente a cero cuando no hay uso. * Monitoreo Detallado de Costos: Implementar herramientas de monitoreo de FinOps (ej. AWS Cost Explorer, CloudWatch Dashboards) con alertas personalizadas para detectar desviaciones en el consumo de LLM y recursos cloud, permitiendo una acción correctiva rápida.

1. Gestión de Clientes y Contratos (Impacto en Ingresos y Costos):

* Límites de Uso por Cliente: Establecer y aplicar límites de tasa (rate limiting) y cuotas de uso de tokens/análisis por cliente. Esto previene el uso excesivo y asegura que los costos de LLM se alineen con los ingresos generados por cada cliente. * Modelos de Precios Basados en Valor: Considerar modelos de precios que escalen con el valor entregado (ej. por reducción de MTTR, por ahorro de horas de SRE), lo que puede justificar el uso de modelos LLM más caros cuando el impacto en el cliente es mayor.