Natural language query por todo el observability stack

Qué hace la automatización

El agente de IA funciona como punto de entrada único a todo el stack de observability. El ingeniero escribe una pregunta en Slack, un chat web o mediante CLI — el agente analiza la intención, accede a las fuentes necesarias a través de conectores MCP, recopila los datos y devuelve la respuesta con enlaces directos a dashboards y líneas de log.

Escenarios concretos

1. Diagnóstico de incidente. «¿Qué cambió en los últimos 30 minutos?» — el agente recopila deploy events, alert history, métricas anómalas y devuelve una respuesta cronológica.
2. Búsqueda de la causa raíz. «¿Por qué aumentaron los errores 500 en checkout-service?» — el agente busca en error logs, los relaciona con commits recientes y muestra el trace con el span más largo.
3. Contexto para on-call. «¿Qué está ardiendo ahora?» — el agente agrega los incidentes abiertos, el SLO burn rate y los últimos releases.
4. Informes para stakeholders. «Recopile el estado para el sync semanal» — el agente elabora un borrador con SLO, uptime, incidentes y métricas clave.
5. Onboarding de ingeniero. «¿Cómo está organizado el payment-flow?» — el agente explica a partir del código, docs y traces.

Característica: el agente no solo agrega datos, sino que los relaciona de forma contextual. Una consulta sobre checkout extrae automáticamente las métricas, los logs y los últimos commits del servicio correspondiente.

Qué NO hace la automatización

Es importante establecer los límites desde el principio:

• No reemplaza a los ingenieros de guardia. El agente ofrece hipótesis, las decisiones las toma una persona.
• No resuelve incidentes. El agente no ejecuta runbooks ni realiza deploys — solo lee.
• No reemplaza el alerting. PagerDuty, Opsgenie, Sentry siguen funcionando como antes.
• No ofrece respuestas 100% precisas. Las alucinaciones son posibles — el agente siempre devuelve las fuentes para su verificación.
• No migra el stack. Todas las herramientas existentes permanecen en su lugar, el agente trabaja sobre ellas.

Variantes típicas de configuración

Solo / equipo de 1–5 personas. Configuración mínima: conectar 2–3 fuentes clave — habitualmente logs, monitorización y git. El agente responde en un único canal de Slack o mediante CLI. Para un equipo pequeño se amortiza por el ahorro de tiempo del fundador-ingeniero que se encarga de todo a la vez. La configuración lleva un fin de semana, sin un modelo de roles complejo. Es suficiente con un modelo de lenguaje a través de API y un índice RAG sencillo. Limitación: si hay más de cinco fuentes, sin structured routing comienzan las alucinaciones. En este nivel es más fácil mantener el foco en un único clúster y un único tipo de incidente.

SMB / equipo de 6–30 personas. Agente de observability completo: 5–8 fuentes (logs, metrics, traces, errors, git, CI/CD, incident management, docs). Agent router por tipo de solicitud, servidores MCP independientes para cada fuente. Respuestas en Slack con etiquetado por equipos (backend, frontend, data). Se añade audit log y role-based access para prod vs staging. En este nivel cobra sentido el fine-tuning de prompt templates según la especificidad del stack. El ahorro típico es de horas semanales por equipo gracias a la eliminación del hunt-and-peck entre consolas.

Enterprise / equipo de 30+ personas. Arquitectura multi-agente: agentes especializados para Kubernetes, database, security, networking. El router central determina a qué agente dirigir la solicitud. Integración con el catálogo interno de servicios, filtros de compliance (PII, secrets), tenant independiente por equipo. Se necesita un grupo de soporte dedicado (2–3 ingenieros) y un presupuesto significativo en tokens de LLM. El ROI no es tanto el ahorro de tiempo como la reducción del MTTR en incidentes críticos y la aceleración del onboarding de nuevos equipos en una estructura grande.

Cómo funciona

Técnicamente, la automatización es una composición de cuatro capas.

1. Interfaz — Bot de Slack, chat web o CLI. El ingeniero escribe la pregunta en lenguaje natural.
2. Enrutador de solicitudes — El orquestador LLM determina qué fuentes se necesitan para la respuesta, qué filtros aplicar y si se requiere follow-up.
3. Conectores MCP a fuentes de datos — Un conector independiente para cada herramienta: logs, metrics, traces, errors, git, docs.
4. Sintetizador de respuesta — El LLM recopila datos de las fuentes, explica las relaciones y devuelve la respuesta con referencias a los datos originales.

Flow paso a paso

Para la pregunta típica «¿por qué la latencia del checkout aumentó después de las 14:07?» el agente realiza lo siguiente:

1. Parsea la intención: se trata de un root cause analysis para un servicio específico y una ventana de tiempo concreta.
2. Determina las fuentes necesarias: metrics (latency), logs (error patterns), deploy history (qué cambió), traces (qué span es lento).
3. Formula solicitudes paralelas a través de los conectores MCP hacia cada fuente.
4. Recopila los resultados, encuentra intersecciones — por ejemplo, deploy a las 14:06 → aumento de latency en p95 checkout-service → error DB timeout en los logs → trace muestra un query lento en new feature flag.
5. Genera una respuesta coherente: hipótesis + evidencias + referencias + propuesta del siguiente paso.

Todo el ciclo lleva segundos en lugar de minutos de hunt-and-peck manual.

El rol del LLM

el modelo de lenguaje es el componente clave. Sus puntos fuertes para esta tarea:

• El contexto largo permite analizar simultáneamente extractos de más de 5 fuentes sin sobrecarga.
• Buen manejo de tool use — los conectores MCP se invocan a través de tool calls estructuradas sin parsear texto libre.
• Capacidad de chain-of-thought reasoning para correlaciones complejas entre métricas y eventos.
• Manejo cuidadoso de las referencias — el agente devuelve las fuentes en lugar de inventarlas.

Conectores MCP

Model Context Protocol (MCP) — el estándar para conectar LLM a fuentes externas. Para el escenario de observability, el conjunto típico de conectores:

• logs-mcp — Lee el agregador de logs (Loki, Elastic, CloudWatch Logs).
• metrics-mcp — PromQL/Prometheus y/o Grafana API.
• traces-mcp — Tempo, Jaeger o backend compatible con OpenTelemetry.
• errors-mcp — Sentry, Rollbar, Honeybadger.
• git-mcp — Historiales de commits y deploy events.
• docs-mcp — Runbooks internos, Notion, Confluence.

Cada conector es un proceso independiente con acceso read-only y su propio rate limit.

Enfoques alternativos

El análisis manual funciona mientras el equipo es pequeño y el stack es sencillo. Cuando hay más de tres fuentes y más de cinco ingenieros, cada incidente se convierte en una búsqueda de contexto. Las soluciones no-code de los vendors funcionan bien dentro de su propio ecosistema, pero conectan mal fuentes diferentes — y el stack de observability real suele estar compuesto por varias herramientas de distintos proveedores. La automatización de IA en MCP funciona sobre lo que ya existe y no requiere migrar a un solo vendor-stack. El inconveniente: se necesita experiencia interna para la configuración y el monitoreo de la calidad de las respuestas.

Seguridad y compliance

Los datos de observability frecuentemente contienen información sensible: PII en los logs, tokens, URLs internas. Tres requisitos básicos para el setup:

1. Acceso read-only. El agente no debe tener permisos para modificar datos ni para ejecutar runbooks. Solo lectura a través de API-tokens con scopes mínimos.
2. Filtrado a nivel del conector. Redacción de PII y enmascaramiento de secrets antes de que los datos lleguen al contexto del LLM.
3. Audit log. Todas las solicitudes y respuestas se registran — para el análisis de incidentes y para compliance (SOC 2, GDPR, HIPAA según sea necesario).

Si el equipo trabaja con datos personales de usuarios, utilice un proveedor LLM con política de zero retention (el modelo de IA a través de Anthropic API lo admite) o inferencia self-hosted para los contornos sensibles.

Qué se necesita de antemano

Antes de lanzar el agente, prepare la infraestructura y el equipo.

Requisitos técnicos previos

1. Lista de fuentes de observability. Qué herramientas se utilizan: Grafana, Datadog, Sentry, CloudWatch, Prometheus, u otras. Mínimo dos fuentes — de lo contrario, el agente se convierte en un envoltorio sobre una sola API.
2. Tokens de API con read-only scope. Un token separado para cada fuente. Sin permisos de escritura, sin privilegios de admin.
3. Conectores MCP. Ya sea los prediseñados (los hay para las herramientas más populares), o escribir los propios — uno o dos días de trabajo por herramienta.
4. Proveedor de LLM. LLM a través de Anthropic API — un valor por defecto funcional gracias al contexto largo y al tool use de calidad.
5. Canal de acceso. Slack, Microsoft Teams, chat web o CLI — donde el equipo hará las preguntas. Slack — la opción habitual.
6. Sandbox en pre-prod. Probar solicitudes y respuestas durante dos semanas antes de dar acceso a todo el equipo.

Roles y responsabilidades

• DevOps / SRE lead — configura los conectores MCP, valida los accesos.
• Tech lead — define los tipos de preguntas, recopila feedback sobre la calidad de las respuestas.
• Security — revisa la configuración de compliance, los filtros de PII, el audit log.
• Product engineer — adapta los prompt templates a las particularidades del equipo.

Posibles escollos

• Alucinaciones sin fuentes. Si no se configura la entrega obligatoria de enlaces a los datos de origen, el agente comienza a inventar cifras y events. Fix: exigir en el system prompt mostrar la fuente de cada hecho, rechazar respuestas sin referencias.
• Sobrecarga de contexto. Si se envía al LLM todo el log de la última hora, el contexto se satura y las respuestas se degradan. Fix: filtrado a nivel de conector, solo los fragmentos relevantes llegan al LLM.
• Correlaciones fantasma. El agente puede encontrar una «relación» entre dos eventos aleatorios. Fix: solicitar explícitamente hipótesis, no afirmaciones, añadir confidence score, validar con un conjunto de solicitudes de regresión.
• Secretos en el contexto. Las claves de API, tokens, passwords de los logs llegan al prompt del LLM. Fix: filtros regex en el conector + política de zero retention en el proveedor de LLM + rotación de claves comprometidas en caso de fuga.
• Deriva de calidad. Al cabo de un mes, las fuentes cambian, los esquemas de logs evolucionan — las respuestas se degradan sin errores visibles. Fix: revisión semanal de una muestra de 10–20 solicitudes, pruebas de regresión en escenarios típicos, alerta ante la caída del confidence.