Agent IA pour analyser les alertes DevOps avec MCP

Automatisation de l'analyse des alertes DevOps avec l'IA et le protocole MCP

Les équipes DevOps passent souvent des heures à fouiller dans les alertes provenant de Slack, Grafana et Alertmanager, surtout dans des environnements complexes avec Kubernetes, VictoriaMetrics, Loki et plusieurs clouds. Le tri manuel oblige à garder en tête les détails de plus de 10 environnements, bases de données et piles de monitoring. La solution ? Un agent proof-of-concept (PoC) basé sur n8n, intégré à l'IA via des serveurs MCP (Model Control Protocol), qui fournit le contexte complet des alertes, des commandes prêtes à exécuter et des recommandations actionnables.

L'agent dispose d'un accès en lecture seule à votre infrastructure : vmetrics pour les requêtes PromQL, Loki pour les logs, k8s-mcp pour les ressources Kubernetes, Yandex Cloud Toolkit, ArgoCD-mcp et Alertmanager-mcp. Cela lui permet d'analyser les métriques, les logs, les états des pods et les silences sans aucun risque de modification.

Construction du PoC sur n8n avec les intégrations MCP

Nous avons choisi n8n comme plateforme low-code pour le prototype. Nous avons lancé des serveurs MCP : alertmanager-mcp, vmetrics-mcp, Yandex Toolkit et k8s-mcp. L'IA génère le workflow, adapté à vos environnements (Yandex Cloud, AWS, DigitalOcean).

Les premiers tests avec Gemini ont rencontré des problèmes : silences incorrects et appels MCP excessifs. Le passage à Claude avec un mode de raisonnement étape par étape a corrigé les hallucinations et les boucles. Le prompt final précise l'environnement, la date, les outils et une séquence d'actions stricte.

Éléments clés du prompt :

• Environnement actuel avec cloud_id, folder_id, étiquette de cluster.
• Outils : vmetrics (requêtes instantanées/plage de -30m à maintenant), Loki (-30m/-1h), k8s_mcp (contexte depuis la table), Yandex Cloud Toolkit (Compute/VPC/IAM/YDB/S3 uniquement).
• Alertmanager : get_silences, post_silence (JSON avec matchers, dates ISO), delete_silence.

Protocole standard d'investigation des alertes

L'agent suit un playbook standard :

• vmetrics — métriques (redémarrages, mémoire, CPU, serveurs libres).
• Tableau de données — kubeconfig_context pour K8s.
• k8s_mcp — pods_log (previous=true) ou pods_get.
• argocd_mcp — get_application par étiquettes.
• Loki — uniquement si pas de cause racine dans les logs des pods.

Limites d'appels :

• Pas plus de 2 tentatives par outil.
• Deux réponses vides ? Arrêt.
• Erreur 422 (trop de points) ? Passage à une requête instantanée.
• Conditions d'arrêt : OOMKilled/Killed/Erreur dans les logs, redémarrages >0 avec raison, 5+ appels.

Les étiquettes d'alerte (labelsRaw) sont utilisées telles quelles : project/cluster uniquement si présentes, sans suppositions.

Gestion des commandes et silences

Commandes @bot en anglais ou russe :

• "silence 2h" / "mute pour 4 heures" — post_silence (défaut 2h, matcher par alertname).
• "unsilence" / "unmute" — delete_silences par alertname.
• "reanalyze" — analyse complète.

Workflow de silence :

• get_silences() — vérification des existants.
• Si trouvés — rapport ID/endsAt.
• Sinon — post_silence (startsAt=now, endsAt=+duration, ISO Z).

Format de réponse Slack mrkdwn :

• Sévérité : 🔴/🟡/🟢 (par étiquette, jamais en baisse).
• _Diagnostic :_ cause racine.
• _Ce que j'ai trouvé :_ chiffres (redémarrages | exitCode | limite | log).
• _Prochaines étapes :_ liste numérotée d'actions.

Points clés

• Le protocole MCP donne à l'IA un accès en lecture seule sécurisé à l'infrastructure sans API personnalisées.
• Le mode de raisonnement de Claude évite les boucles et hallucinations avec les outils.
• Des critères d'arrêt stricts minimisent les appels, en ciblant les causes racine (OOM, CrashLoopBackOff).
• L'intégration n8n permet à l'IA de générer des workflows, accélérant le développement.
• Supporte plusieurs clouds et clusters K8s via cartographie de contexte.

— Editorial Team