# Automatización del análisis de alertas en DevOps con IA y protocolo MCP
Los equipos de DevOps suelen pasar horas revisando alertas de Slack, Grafana y Alertmanager, especialmente en entornos complejos con Kubernetes, VictoriaMetrics, Loki y múltiples nubes. El triaje manual implica memorizar detalles de más de 10 entornos, bases de datos y pilas de monitoreo. ¿La solución? Un agente proof-of-concept (PoC) basado en n8n, integrado con IA mediante servidores MCP (Model Control Protocol), que proporciona contexto completo de la alerta, comandos listos para ejecutar y recomendaciones accionables.
El agente obtiene acceso de solo lectura a tu infraestructura: vmetrics para consultas PromQL, Loki para logs, k8s-mcp para recursos de Kubernetes, Yandex Cloud Toolkit, ArgoCD-mcp y Alertmanager-mcp. Esto le permite analizar métricas, logs, estados de pods y silencios sin riesgo de realizar cambios.
Construyendo el PoC en n8n con integraciones MCP
Elegimos n8n como plataforma de flujos low-code para el prototipo. Levantamos servidores MCP: alertmanager-mcp, vmetrics-mcp, Yandex Toolkit y k8s-mcp. La IA genera el flujo, adaptado a tus entornos (Yandex Cloud, AWS, DigitalOcean).
Pruebas iniciales con Gemini tuvieron problemas: silencios incorrectos y llamadas excesivas a MCP. Cambiar a Claude con modo de pensamiento paso a paso eliminó alucinaciones y bucles. El prompt final especifica el entorno, fecha, herramientas y una secuencia estricta de acciones.
Elementos clave del prompt:
- Entorno actual con cloud_id, folder_id, etiqueta del clúster.
- Herramientas: vmetrics (consultas instantáneas/rango de -30m a ahora), Loki (-30m/-1h), k8s_mcp (contexto de tabla), Yandex Cloud Toolkit (solo Compute/VPC/IAM/YDB/S3).
- Alertmanager: get_silences, post_silence (JSON con matchers, fechas ISO), delete_silence.
Protocolo estándar de investigación de alertas
El agente sigue un playbook estándar:
- vmetrics — métricas (reinicios, memoria, CPU, servidores libres).
- Tabla de datos — kubeconfig_context para K8s.
- k8s_mcp — pods_log (previous=true) o pods_get.
- argocd_mcp — get_application por etiquetas.
- Loki — solo si no hay causa raíz en logs de pods.
Límites de llamadas:
- No más de 2 reintentos por herramienta.
- ¿Dos respuestas vacías? Para.
- Error 422 (demasiados puntos)? Cambia a consulta instantánea.
- Condiciones de parada: OOMKilled/Killed/Error en logs, reinicios >0 con motivo, 5+ llamadas.
Las etiquetas de alerta (labelsRaw) se usan tal como se proporcionan: project/cluster solo si están presentes, sin suposiciones.
Manejo de comandos y silencios
Comandos @bot en inglés o ruso:
- "silence 2h" / "silenciar 4 horas" — post_silence (por defecto 2h, matcher por alertname).
- "unsilence" / "reactivar" — delete_silences por alertname.
- "reanalyze" — análisis completo.
Flujo de silencio:
- get_silences() — verifica existentes.
- Si hay — reporta ID/endsAt.
- Si no — post_silence (startsAt=ahora, endsAt=+duración, ISO Z).
Formato de respuesta Slack mrkdwn:
- Gravedad: 🔴/🟡/🟢 (por etiqueta, nunca rebajar).
- _Diagnóstico:_ causa raíz.
- _Lo que encontré:_ números (reinicios | exitCode | límite | log).
- _Pasos siguientes:_ lista numerada de acciones.
Lecciones clave
- El protocolo MCP da a la IA acceso seguro de solo lectura a la infraestructura sin APIs personalizadas.
- El modo de pensamiento de Claude evita bucles y alucinaciones con herramientas.
- Criterios estrictos de parada minimizan llamadas, enfocándose en causas raíz (OOM, CrashLoopBackOff).
- La integración con n8n permite que la IA genere flujos, acelerando el desarrollo.
- Soporta múltiples nubes y clústeres K8s vía mapeo de contexto.
— Editorial Team
Aún no hay comentarios.