NetGuardian AI — Technical Explainer

Collaborative AI Agents and Critics for Fault Detection and Root-Cause Analysis in Network Telemetry

---

1. Concept

Modern SRE and DevOps teams are drowning in telemetry data. A typical microservices platform emits hundreds of thousands of log lines, metric data-points, and distributed traces every minute. When something breaks, engineers must manually sift through this noise to find the root cause — a process that is slow, error-prone, and requires scarce expertise.

NetGuardian AI solves this with a two-pass Agent-Critic AI pipeline:

Pass	Role	Job
Agent	Anomaly Detector	Ingests raw telemetry, detects patterns, proposes an initial root-cause hypothesis
Critic	Quality Reviewer	Validates the Agent's hypothesis against contextual data and refines the analysis

This "debate" approach produces higher-quality, more defensible root-cause reports than a single LLM pass — directly reducing MTTR and SLA breaches.

---

2. Architecture

┌────────────────────────────────────────────────────────────────────┐
│                        NetGuardian AI API                          │
│                                                                    │
│  ┌──────────────┐   ┌────────────────────────────────────────┐    │
│  │  Auth API    │   │           Telemetry Ingestion           │    │
│  │ POST /token  │   │         POST /telemetry/ingest          │    │
│  └──────┬───────┘   └──────────────────┬───────────────────  ┘    │
│         │ JWT                          │ 202 Accepted              │
│         ▼                              ▼                           │
│  ┌──────────────┐   ┌────────────────────────────────────────┐    │
│  │ Spring Sec 7 │   │        TelemetryService.ingest()        │    │
│  │ JWT Filter   │   │   [save TelemetryData to H2/Postgres]   │    │
│  └──────────────┘   └──────────────────┬───────────────────  ┘    │
│                                         │ Virtual Thread           │
│                                         ▼                          │
│                      ┌──────────────────────────────────────┐     │
│                      │  AnalysisOrchestratorService          │     │
│                      │  ┌──────────────────────────────┐    │     │
│                      │  │  Pass 1: AgentService         │    │     │
│                      │  │  LLM prompt → hypothesis      │    │     │
│                      │  │  @CircuitBreaker (Resilience4j)│   │     │
│                      │  └──────────────┬───────────────┘    │     │
│                      │                 │ AgentHypothesisDto  │     │
│                      │  ┌──────────────▼───────────────┐    │     │
│                      │  │  Pass 2: CriticService        │    │     │
│                      │  │  Contextual data + LLM review │    │     │
│                      │  │  @CircuitBreaker (Resilience4j)│   │     │
│                      │  └──────────────┬───────────────┘    │     │
│                      │                 │ CriticAnalysisDto   │     │
│                      │  ┌──────────────▼───────────────┐    │     │
│                      │  │  Persist Incident entity      │    │     │
│                      │  │  Mark telemetry as processed  │    │     │
│                      │  └──────────────┬───────────────┘    │     │
│                      │                 │                     │     │
│                      │  ┌──────────────▼───────────────┐    │     │
│                      │  │  WebhookNotificationService   │    │     │
│                      │  │  Slack / PagerDuty / Custom   │    │     │
│                      │  └──────────────────────────────┘    │     │
│                      └──────────────────────────────────────┘     │
│                                                                    │
│  ┌──────────────────────────────────────────────────────────────┐ │
│  │  Incident Dashboard API                                       │ │
│  │  GET /incidents  GET /incidents/{id}  GET /incidents/summary  │ │
│  │  PATCH /incidents/{id}/status                                 │ │
│  └──────────────────────────────────────────────────────────────┘ │
│                                                                    │
│  ┌────────────────────────────────────────┐                       │
│  │  Webhook Config API                    │                       │
│  │  POST/GET/PUT/DELETE /webhooks         │                       │
│  └────────────────────────────────────────┘                       │
└────────────────────────────────────────────────────────────────────┘
         │                              │
         ▼                              ▼
   LLM API (OpenFeign)           H2 / PostgreSQL
   (OpenAI / Ollama / vLLM)      (JPA / Hibernate)

Key design decisions

Decision	Choice	Rationale
Threading model	Java 25 Virtual Threads	Each HTTP request and each analysis run on a VT — maximises throughput for I/O-bound LLM calls
AI pipeline	Agent + Critic (2-pass LLM)	Higher accuracy than single-pass; models the adversarial review process used by expert SRE teams
Resilience	Resilience4j Circuit Breaker	Graceful degradation to heuristic analysis when the LLM is unavailable
LLM integration	OpenFeign client	Swappable: point netguardian.llm.url at OpenAI, Azure OpenAI, Ollama, vLLM, or LM Studio
Auth	JWT (JJWT 0.12) + Spring Security 7	Stateless, scalable, API-first auth
Jackson	3.x (tools.jackson.*)	Spring Boot 4's default — faster, immutable-by-default, full Records support

---

3. API Endpoints

Authentication

Method	Path	Auth	Description
%%INLINE2%%	%%INLINE3%%	None	Exchange credentials for a JWT token

Example:

curl -X POST http://localhost:8080/api/v1/auth/token \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"netguardian2024"}'

Response:

{
  "token": "eyJhbGciOiJIUzI1NiJ9...",
  "expiresIn": 86400,
  "tokenType": "Bearer"
}

---

Telemetry Ingestion

Method	Path	Auth	Description
%%INLINE4%%	%%INLINE5%%	JWT	Ingest a telemetry event; triggers async AI analysis

Example (log event):

curl -X POST http://localhost:8080/api/v1/telemetry/ingest \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "source":    "orders-api-prod",
    "timestamp": "2026-04-10T14:30:00Z",
    "dataType":  "log",
    "payload":   "ERROR Connection refused to downstream service payments-api:8080 after 3 retries"
  }'

Response (202 Accepted):

{
  "telemetryId": 42,
  "ingestedAt": "2026-04-10T14:30:01.123Z",
  "message": "Telemetry event accepted. AI analysis running asynchronously — poll GET /api/v1/incidents for results."
}

---

Incident Dashboard

Method	Path	Auth	Description
%%INLINE6%%	%%INLINE7%%	JWT	List incidents (paginated, newest first)
%%INLINE8%%	%%INLINE9%%	JWT	Filter by severity
%%INLINE10%%	%%INLINE11%%	JWT	Severity count breakdown
%%INLINE12%%	%%INLINE13%%	JWT	Full incident detail with AI report
%%INLINE14%%	%%INLINE15%%	JWT	Update lifecycle status

Example incident response:

{
  "id": 7,
  "summary": "Cascading failure in payments-api caused by database connection pool exhaustion",
  "severity": "CRITICAL",
  "status": "OPEN",
  "agentHypothesis": "Connection pool exhaustion in payments-api is causing downstream service failures...",
  "criticAnalysis": "Validated. Root cause: DB pool size (10) is insufficient for current load (350 req/s)...",
  "rootCauseReport": "The payments-api database connection pool is exhausted...\n\nRecommendations:\n1. Increase pool size...",
  "confidenceScore": 0.91,
  "detectedAt": "2026-04-10T14:30:03.456Z",
  "resolvedAt": null,
  "telemetryDataId": 42
}

---

Webhook Configuration

Method	Path	Auth	Description
%%INLINE16%%	%%INLINE17%%	JWT	List all webhook configurations
%%INLINE18%%	%%INLINE19%%	JWT	Create a new webhook target
%%INLINE20%%	%%INLINE21%%	JWT	Update an existing webhook
%%INLINE22%%	%%INLINE23%%	JWT	Delete a webhook configuration

Create a Slack webhook:

curl -X POST http://localhost:8080/api/v1/webhooks \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "SRE On-Call Slack",
    "url": "https://hooks.slack.com/services/T.../B.../xxx",
    "platform": "slack",
    "minSeverity": "HIGH",
    "active": true
  }'

---

4. Business Analysis

Problem → Solution fit

Problem	NetGuardian AI Solution
SRE teams spend 60–80% of incident time on root-cause investigation	Automated Agent-Critic pipeline produces root-cause reports in seconds
Single-model AI analysis is unreliable; models hallucinate	Two-pass Agent-Critic approach cross-validates hypotheses
Alert fatigue from noisy monitoring tools	Severity scoring and smart thresholds reduce noise
LLM dependency creates fragility	Resilience4j circuit breaker falls back to heuristic analysis
Slow MTTR increases SLA breach risk and revenue loss	Automated analysis + instant webhook alerts cut response time

Market positioning

• Target buyers: CTOs, VP Engineering, SRE leads in scale-ups and enterprises running Kubernetes microservices
• Pricing angle: API-first SaaS — charge per telemetry event analyzed (e.g., $0.001/event) or per seat for the dashboard
• Competitive moat: The Agent-Critic "debate" architecture produces demonstrably more accurate root-cause reports than single-pass AIOps tools (Dynatrace AI, Datadog Watchdog)

Key metrics to track

• MTTR reduction — primary value metric for buyers
• Accuracy rate — Critic validation rate (validated=true %)
• Ingestion throughput — events/second (virtual threads enable high concurrency)
• Circuit breaker trigger rate — health proxy for LLM dependency

---

5. References

Source	Description
arXiv 2404.00319	"Large Language Models for Fault Localization" — foundational paper for the Agent-Critic approach
Spring Boot 4.0.x Docs	Spring Boot 4 reference
Java 25 Virtual Threads	JEP 444 — Virtual Threads
Resilience4j Docs	Circuit Breaker patterns
JJWT 0.12 Migration	JJWT 0.12.x API changes
OpenTelemetry HTTP Exporter	Compatible telemetry source format

---

6. How to Run

Prerequisites

• Java 25
• Maven 3.9+
• (Optional) An OpenAI-compatible LLM endpoint for live AI analysis

Quick start (H2 in-memory database, heuristic fallback)

cd solutions/2026-04-10-netguardian-ai-api

# Build and run
mvn spring-boot:run

# Server starts on http://localhost:8080

With a real LLM (Ollama example)

# Start Ollama with llama3
ollama run llama3

# Run with LLM URL configured
mvn spring-boot:run \
  -Dspring-boot.run.arguments="--netguardian.llm.url=http://localhost:11434"

With PostgreSQL (production-like)

mvn spring-boot:run \
  -Dspring-boot.run.arguments="\
    --spring.datasource.url=jdbc:postgresql://localhost:5432/netguardian \
    --spring.datasource.username=netguardian \
    --spring.datasource.password=secret \
    --spring.jpa.hibernate.ddl-auto=update"

End-to-end test flow

# 1. Get a JWT
TOKEN=$(curl -s -X POST http://localhost:8080/api/v1/auth/token \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"netguardian2024"}' \
  | grep -o '"token":"[^"]*"' | cut -d'"' -f4)

# 2. Ingest a simulated error log
curl -X POST http://localhost:8080/api/v1/telemetry/ingest \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "source": "checkout-service",
    "timestamp": "2026-04-10T14:30:00Z",
    "dataType": "log",
    "payload": "CRITICAL: Database connection pool exhausted. Active=50 Idle=0 MaxPool=50. All threads waiting. Upstream timeouts increasing."
  }'

# 3. Wait ~2 seconds for async analysis, then retrieve the incident
curl http://localhost:8080/api/v1/incidents \
  -H "Authorization: Bearer $TOKEN"

# 4. Configure a Slack webhook alert
curl -X POST http://localhost:8080/api/v1/webhooks \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "SRE Slack",
    "url": "https://hooks.slack.com/services/YOUR/WEBHOOK/URL",
    "platform": "slack",
    "minSeverity": "HIGH",
    "active": true
  }'

Environment variables

Variable	Default	Description
%%INLINE24%%	%%INLINE25%%	LLM API base URL
netguardian.jwt.secret	(built-in default)	JWT signing secret — change in production
%%INLINE27%%	%%INLINE28%%	Token validity (24 h)
spring.datasource.url	H2 in-memory	Database URL

---

Built with Spring Boot 4.0.4 · Java 25 · Jackson 3.x · Spring Security 7 · Resilience4j 2.2 · JJWT 0.12

---

FinOps Analysis: NetGuardian AI

1. Estimación de Costos Operativos Mensuales

Uso de Tokens LLM:

Basado en un MVP inicial con 10 clientes y un promedio de 200 incidentes/análisis por cliente al mes, totalizando 2000 incidentes/análisis mensuales. Cada análisis se estima que consume una media de 15,000 tokens de entrada y 2,000 tokens de salida (considerando la complejidad de la telemetría y el análisis Agente-Crítico).

• Agente (GPT-4o): Se estima que el Agente procesa la mayor parte del input inicial.

- Input: 2000 incidentes * 10,000 tokens/incidente = 20,000,000 tokens. - Output: 2000 incidentes * 1,000 tokens/incidente = 2,000,000 tokens.

• Crítico (GPT-4 Turbo): El Crítico requiere mayor precisión y razonamiento avanzado.

- Input: 2000 incidentes * 5,000 tokens/incidente = 10,000,000 tokens. - Output: 2000 incidentes * 1,000 tokens/incidente = 2,000,000 tokens.

Estimación Total de Tokens:

• Input Total: 30,000,000 tokens (30M)
• Output Total: 4,000,000 tokens (4M)
• Total Estimado: ~34 millones de tokens/mes.

Desglose de Costos Mensuales:

1. Costos de LLM (OpenAI):

- GPT-4o (Agente): - Input: 20M tokens * ($5 / 1M tokens) = $100 - Output: 2M tokens * ($15 / 1M tokens) = $30 - Subtotal Agente: $130 - GPT-4 Turbo (Crítico): - Input: 10M tokens * ($10 / 1M tokens) = $100 - Output: 2M tokens * ($30 / 1M tokens) = $60 - Subtotal Crítico: $160 - Costo Total LLM: $290/mes

1. Costos de Infraestructura Cloud (AWS Baseline para Spring Boot):

- Servidor de Aplicaciones (Spring Boot): Una instancia EC2 t3.small (2 vCPU, 2GB RAM) con EBS para el SO y aplicación. (~$25/mes) - Base de Datos (PostgreSQL): Una instancia RDS db.t3.micro (1 vCPU, 1GB RAM) para persistencia de incidentes y telemetría. (~$15/mes) - Almacenamiento y Redes: EBS adicional para logs, S3 para backups/artefactos, y transferencia de datos básica. (~$10/mes) - Monitoreo y Logging: Servicios básicos como CloudWatch/CloudTrail. (~$5/mes) - Costo Total Cloud: $55/mes

Costo Operativo Mensual Total Estimado: $290 (LLM) + $55 (Cloud) = $345/mes

2. Estimación de Ingresos Mensuales

Considerando un modelo API-first SaaS para el MVP, con un precio de suscripción mensual para empresas medianas.

• Modelo de Monetización: Suscripción mensual por cliente con límites de uso (ej., número de incidentes/análisis).
• Pricing Estimado: $150/cliente/mes para el plan básico MVP.
• Clientes Iniciales: 10 clientes.
• Ingreso Mensual Estimado: 10 clientes * $150/cliente = $1500/mes

3. Cálculo del Margen de Beneficio

• Ingreso Mensual: $1500
• Costos Mensuales: $345
• Beneficio Bruto: $1500 - $345 = $1155
• Margen de Beneficio: (($1500 - $345) / $1500) 100 = ($1155 / $1500) 100 = 77%

4. Optimización de Costos (FinOps)

El margen de beneficio del 77% es saludable para un MVP, pero la dependencia de los LLM y la escalabilidad futura requieren una estrategia FinOps proactiva. Las principales áreas de optimización incluyen:

1. Optimización de Prompts y Modelos LLM:

* Reducción de Tokens: Refinar prompts para ser más concisos y directos, utilizando técnicas de ingeniería de prompts para extraer la máxima información con el mínimo de tokens. Considerar el uso de resúmenes de telemetría antes de enviar al LLM. * Tiering de Modelos: Utilizar modelos más económicos (ej. %%INLINE32%% o modelos open-source fine-tuneados) para tareas del Agente menos críticas o para el pre-análisis. Reservar modelos más caros como %%INLINE33%% solo para la fase de Crítico donde la precisión es primordial. * Caching Inteligente: Implementar un sistema de caché de respuestas LLM para consultas o patrones de incidentes recurrentes, evitando llamadas repetidas a la API de OpenAI.

1. Gestión Eficiente de la Infraestructura Cloud:

* Auto-escalado: Configurar grupos de auto-escalado para la instancia de Spring Boot para ajustar dinámicamente los recursos a la demanda, escalando hacia abajo durante períodos de baja actividad y reduciendo los costos de computación. * Instancias Reservadas (RI) / Savings Plans: Una vez que la carga base sea predecible, adquirir RIs o Savings Plans para EC2 y RDS puede generar ahorros significativos a largo plazo. * Rightsizing: Monitorear el uso de CPU y memoria para asegurar que las instancias de EC2 y RDS estén correctamente dimensionadas, evitando el sobreaprovisionamiento de recursos.

1. Optimización del Procesamiento de Datos:

* Filtrado en el Edge: Implementar lógica de filtrado y agregación de telemetría lo más cerca posible de la fuente (o en la capa de ingesta) para reducir el volumen de datos que llegan al sistema de análisis y, por ende, a los LLM. * Procesamiento por Lotes: Para incidentes o análisis que no requieren respuesta en tiempo real, agrupar las solicitudes al LLM en lotes puede ser más eficiente en términos de costos y rendimiento de la API.

1. Monitoreo y Alertas de Costos:

* Dashboards de FinOps: Crear dashboards personalizados en herramientas como AWS Cost Explorer o Cloud Billing para visualizar los gastos por servicio, por cliente o por función (Agente vs. Crítico), permitiendo una rápida identificación de anomalías. * Alertas de Presupuesto: Configurar alertas automáticas cuando los gastos se acerquen a los umbrales predefinidos, especialmente para los costos de LLM que pueden escalar rápidamente.