Cómo un equipo de SRE redujo un 85% el tiempo de diagnóstico de alertas en Kubernetes

Introducción

En STCLab, un equipo de dos SREs soporta múltiples clusters Amazon EKS en producción con tráfico alto. El stack de observabilidad incluye OpenTelemetry (alimentando Mimir, Loki y Tempo), Prometheus para métricas, Grafana para dashboards y Robusta OSS para enriquecer alertas con logs, enlaces y menciones en Slack. A simple vista, todo parecía funcionar: los datos llegaban, las alertas se disparaban y el equipo recibía notificaciones. Pero el problema no era la ausencia de datos, sino el proceso posterior.

Cada alerta activaba un ritual manual casi idéntico: revisar el pod afectado, consultar Prometheus, bucear en Loki, extraer trazas y intentar correlacionar eventos. Este flujo tomaba entre 15 y 20 minutos por alerta, sin importar si el patrón era conocido (como OOMKilled o ImagePullBackOff) o completamente nuevo. El cuello de botella no era la falta de herramientas, sino la repetitividad del proceso de diagnóstico.

La solución que implementaron no fue reemplazar el modelo de IA, sino estructurar el conocimiento existente en runbooks y luego integrarlos con HolmesGPT (CNCF Sandbox) usando el patrón ReAct. El resultado: redujeron el tiempo de triage de 40 alertas diarias brutas a 12 investigaciones únicas, con un 40% de casos resueltos automáticamente sin intervención humana. El costo operativo por investigación quedó en $0.04, y el tiempo de respuesta bajó a menos de 2 minutos para leer un resumen en Slack.

Qué ocurrió

El equipo identificó que el mayor desperdicio de tiempo no era el diagnóstico en sí, sino la exploración ciega de herramientas. Sin contexto sobre qué datos estaban disponibles en cada namespace, el modelo de IA (HolmesGPT) terminaba:

• Chequeando métricas de Istio en namespaces sin sidecars.
• Consultando Loki donde no había logs centralizados.
• Persiguiendo hipótesis irrelevantes como «escalamiento de proxy» o «mala configuración de puerto» para alertas de handshake de ClickHouse.

En un test controlado con la misma alerta (ClickHouseHandshakeError), el modelo sin runbooks quemó más de 20 pasos antes de encontrar una pista útil, mientras que con runbooks resolvió el patrón en 3 a 4 pasos y usó el resto del presupuesto para validar. La diferencia no era el modelo, sino la capacidad de excluir herramientas irrelevantes.

Los runbooks, implementados como metadatos en Markdown, permitieron:

1. Excluir herramientas dinámicamente: por ejemplo, marcar namespaces sin Istio como «no usar métricas de sidecar».
2. Establecer prioridades: usar kubectl y PromQL en namespaces multi-tenant sin telemetría avanzada.
3. Mapear destinos: replicar la lógica de Robusta para enrutar resultados a los canales de Slack correctos por namespace.

El cambio más crítico fue reducir las llamadas fallidas de 16 a 2 por investigación, liberando recursos de cómputo y acelerando las respuestas.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps e Infraestructura

• Reducción de carga cognitiva: De 20 minutos manuales por alerta a menos de 2 minutos para leer un resumen en Slack.
• Consistencia en entornos multi-tenant: Los runbooks permiten adaptar el diagnóstico a namespaces con diferentes niveles de observabilidad (centralizada, parcial o ausente).
• Costos operativos: Aproximadamente $12 al mes (0.04 USD por investigación) con un pipeline híbrido (self-hosted en staging, API gestionada en producción).
• Escalabilidad: La misma pipeline soporta 40 alertas diarias brutas, que se reducen a 12 investigaciones únicas gracias a la deduplicación por workload.

Para equipos de Cloud

• Integración con EKS y VPC Peering: HolmesGPT puede correlacionar logs entre clusters usando peering, algo crítico en arquitecturas multi-cluster.
• Compatibilidad con herramientas CNCF: La solución usa OpenTelemetry, Prometheus, Loki y Mimir sin cambios en la infraestructura existente.
• Migración de modelos simplificada: El pipeline y los runbooks son independientes del backend. El equipo ya realizó tres swaps de modelos sin tocar la lógica principal.

Para equipos de Seguridad

• Automatización de patrones conocidos: El 40% de las investigaciones se resuelven solas (ej: OOMKilled, ImagePullBackOff), liberando tiempo para análisis de anomalías reales.
• Futuras extensiones con eBPF: La arquitectura está preparada para integrar métricas de red de bajo nivel (retransmisiones TCP, latencia de conexión) mediante Inspektor Gadget (CNCF), mejorando la detección de problemas de red.

Detalles técnicos

Arquitectura del pipeline

La solución se compone de tres capas:

1. Recolección de alertas: Robusta OSS enriquece alertas de Prometheus con logs, enlaces a dashboards y menciones en Slack.
2. Investigación con HolmesGPT:

– Runbooks en Markdown: Archivos con metadatos como:

     ---
     namespace: "api-gateway"
     available_tools: ["kubectl", "promql"]
     excluded_tools: ["loki", "tempo", "istio"]
     slack_channel: "#alerts-api-gateway"
     ---
     

– Ejemplo de herramienta: La función fetch_runbook es llamada al inicio de cada investigación para cargar las reglas de exclusión.

1. Glue code (200 líneas de Python):

– Matching de threads en Slack: Robusta publica la alerta inicial, pero el playbook encuentra el thread correcto y anexa los resultados como respuesta.

– Enrutamiento por namespace: Replica la lógica de Robusta para dirigir resultados al canal de Slack adecuado.

Modelos de IA probados

El equipo evaluó siete modelos, comparando self-hosted (en Spot GPUs con KubeAI) vs. APIs gestionadas (vía VPC endpoints):

Métricas clave

• Tiempo de respuesta:

– Con runbooks: <2 minutos (leer resumen en Slack).

• Eficiencia:

– Alertas brutas: 40 diarias → 12 investigaciones únicas.

• Costo:

• Resolución automática:

Integración con herramientas CNCF

• Prometheus: Métricas de CPU, memoria y fallos de pods.
• Loki: Logs centralizados (cuando están disponibles).
• Tempo: Traces distribuidas (para namespaces con sidecar de Istio).
• OpenTelemetry: Recolección unificada.
• KubeAI: Orquestación de modelos en Spot GPUs (self-hosted).
• Inspektor Gadget: Futura integración de métricas de red (TCP retransmits, latencia) mediante eBPF.

Qué deberían hacer los administradores y equipos técnicos

Si estás evaluando automatizar el diagnóstico de alertas en Kubernetes, seguí estos pasos basados en la experiencia de STCLab:

1. Documentar runbooks antes que elegir modelos

Creá runbooks en Markdown con esta estructura:

---
namespace: "microservicio-x"
available_tools:
  - "kubectl get pods"
  - "promql"
excluded_tools:
  - "loki"  # No hay logs centralizados aquí
  - "istio" # No hay sidecars
slack_channel: "#alertas-microservicio-x"
deduplication_window: "30m"
---

• Usá excluded_tools para evitar llamadas innecesarias.
• Incluí deduplication_window para agrupar alertas por workload.
• Mantené los runbooks versionados en Git (ej: runbooks/namespace-alert-type.md).

2. Probar el patrón ReAct con HolmesGPT

Instalá HolmesGPT en tu cluster (CNCF Sandbox):

# Usando Helm (requiere cluster con cert-manager)
helm repo add holmesgpt https://cncf.github.io/holmesgpt/charts
helm install holmesgpt holmesgpt/holmesgpt \
  --set modelProvider.apiKey="<tu-api-key>" \
  --set tools.prometheus.enabled=true \
  --set tools.kubectl.enabled=true

Configurá los runbooks como herramientas externas:

# values.yaml
tools:
  runbook:
    enabled: true
    config:
      path: "/etc/holmesgpt/runbooks"

3. Implementar deduplicación y enrutamiento en Slack

Escribí un script Python (ej: holmes_router.py) que:

• Escuche alertas de Robusta o Prometheus.
• Consulte el runbook para el namespace/alerta.
• Agrupe alertas por owner (deployment/statefulset).
• Suprima repeticiones por 30 minutos.
• Envíe resultados al canal correcto en Slack (replicando la lógica de Robusta).

Ejemplo mínimo:

import requests
from kubernetes import client, config

def get_owner_from_alert(alert):
    # Extrae el pod/owner de la alerta Prometheus
    return alert["labels"]["owner"]

def should_deduplicate(owner, window_minutes=30):
    # Usa un Redis o DB para tracking
    last_alert = redis.get(f"dedup:{owner}")
    if last_alert and (time.time() - last_alert) < window_minutes*60:
        return True
    return False

# Integración con Robusta (webhook)
@app.route("/robusta-webhook", methods=["POST"])
def handle_robusta_alert():
    alert = request.json
    owner = get_owner_from_alert(alert)
    if should_deduplicate(owner):
        return {"status": "suppressed"}, 200
    # Llamar a HolmesGPT y publicar en Slack

4. Evaluar modelos con un test controlado

Diseñá un experimento reproducible:

1. Seleccioná 3 alertas típicas (ej: OOMKilled, ImagePullBackOff, ClickHouseHandshakeError).
2. Ejecutá cada una 4 veces:

– Sin runbooks.

– Con distintos modelos.

1. Mide:

– Tiempo de respuesta.

– Precisión (¿encontró el root cause correctamente?).

• Con runbooks: ≤5 pasos por investigación.
• Sin runbooks: ≥15 pasos o respuestas vagas.

5. Preparar la infraestructura para migración de modelos

Diseñá el pipeline para que el backend de IA sea intercambiable:

# Configuración del proveedor de modelos (ej: values.yaml)
modelProvider:
  type: "managed"  # o "self-hosted"
  apiKey: "<clave>"
  modelName: "coreano-v1"  # Cambiar esto sin tocar el resto

• Spot GPUs con KubeAI (CNCF).
• Tolerancia a evicciones (usá podDisruptionBudget).
• Cold starts <1 minuto (ajustá el tamaño del modelo a 7B-9B para evitar latencias).

6. Extender con métricas de red (futuro)

Si usás Istio o necesitas visibilidad de bajo nivel, integrá Inspektor Gadget para recolectar:

• TCP retransmits.
• Latencia de conexión.
• Métricas de red de pods.

Ejemplo de métrica para Prometheus:

# Config de Inspektor Gadget
gadget:
  network:
    enabled: true
    metrics:
      - name: "tcp_retransmits_total"
        type: "counter"
      - name: "connection_latency_seconds"
        type: "histogram"

Luego, agregá estas métricas a tus runbooks:

---
namespace: "api-gateway"
available_tools:
  - "kubectl get pods"
  - "promql"
  - "inspektor-gadget"  # Nueva herramienta
---

Conclusión

La experiencia de STCLab demuestra que el mayor cuello de botella en el diagnóstico de alertas con IA no es el modelo, sino la falta de contexto. Los runbooks, implementados como metadatos estructurados, permitieron reducir las llamadas fallidas de 16 a 2 por investigación y acelerar el tiempo de respuesta de 20 minutos a menos de 2.

La clave es:

1. Documentar el conocimiento existente en runbooks antes de invertir en modelos complejos.
2. Excluir herramientas irrelevantes dinámicamente para guiar la investigación.
3. Construir glue code que maneje deduplicación, enrutamiento y matching de threads.
4. Diseñar para migración: el pipeline debe ser agnóstico al backend de IA.

Este enfoque no solo optimiza costos y tiempo, sino que también sienta las bases para integrar métricas más granulares (como eBPF) sin cambiar la arquitectura. Si tu equipo aún invierte horas en triage manual, los runbooks y un sistema como HolmesGPT pueden ser el primer paso hacia una operación más ágil.