AI-Agent zur Analyse von DevOps-Warnungen mit MCP

Automatisierung der Alarm-Analyse in DevOps mit KI und MCP-Protokoll

DevOps-Teams verbringen oft Stunden damit, Alarme aus Slack, Grafana und Alertmanager durchzugehen – besonders in komplexen Setups mit Kubernetes, VictoriaMetrics, Loki und mehreren Clouds. Manuelle Triage bedeutet, Details aus über 10 Umgebungen, Datenbanken und Monitoring-Stacks im Kopf zu behalten. Die Lösung? Ein Proof-of-Concept (PoC)-Agent auf Basis von n8n, integriert mit KI über MCP-Server (Model Control Protocol), der vollständigen Alarmkontext, sofort ausführbare Befehle und handlungsorientierte Empfehlungen liefert.

Der Agent erhält schreibgeschützten Zugriff auf Ihre Infrastruktur: vmetrics für PromQL-Abfragen, Loki für Logs, k8s-mcp für Kubernetes-Ressourcen, Yandex Cloud Toolkit, ArgoCD-mcp und Alertmanager-mcp. So kann er Metriken, Logs, Pod-Status und Stummschaltungen analysieren, ohne Änderungen zu riskieren.

Aufbau des PoC mit n8n und MCP-Integrationen

Wir haben n8n als Low-Code-Workflow-Plattform für den Prototypen gewählt. Wir haben MCP-Server gestartet: alertmanager-mcp, vmetrics-mcp, Yandex Toolkit und k8s-mcp. Die KI generiert den Workflow, angepasst an Ihre Umgebungen (Yandex Cloud, AWS, DigitalOcean).

Frühe Tests mit Gemini stießen auf Probleme: falsche Stummschaltungen und zu viele MCP-Aufrufe. Der Wechsel zu Claude mit schrittweisem Denkmuster behebt Halluzinationen und Schleifen. Der finale Prompt spezifiziert Umgebung, Datum, Tools und eine strenge Abfolge von Schritten.

Wichtige Prompt-Elemente:

• Aktuelle Umgebung mit cloud_id, folder_id, Cluster-Label.
• Tools: vmetrics (Instant/Range-Abfragen von -30m bis now), Loki (-30m/-1h), k8s_mcp (Kontext aus Tabelle), Yandex Cloud Toolkit (nur Compute/VPC/IAM/YDB/S3).
• Alertmanager: get_silences, post_silence (JSON mit matchers, ISO-Daten), delete_silence.

Standardprotokoll für Alarmuntersuchungen

Der Agent folgt einem standardisierten Playbook:

• vmetrics — Metriken (Restarts, Speicher, CPU, freie Server).
• Datentabelle — kubeconfig_context für K8s.
• k8s_mcp — pods_log (previous=true) oder pods_get.
• argocd_mcp — get_application nach Labels.
• Loki — nur wenn keine Ursache in Pod-Logs.

Aufrufbeschränkungen:

• Maximal 2 Wiederholungen pro Tool.
• Zwei leere Antworten? Abbruch.
• 422-Fehler (zu viele Punkte)? Zu Instant-Abfrage wechseln.
• Abbruchbedingungen: OOMKilled/Killed/Fehler in Logs, Restarts >0 mit Grund, 5+ Aufrufe.

Alarm-Labels (labelsRaw) werden exakt so verwendet: project/cluster nur bei Vorhandensein, keine Annahmen.

Umgang mit Befehlen und Stummschaltungen

@bot-Befehle auf Deutsch oder Englisch:

• "stummschalten 2h" / "stummschalten für 4 Stunden" — post_silence (Standard 2h, Matcher nach alertname).
• "stummschaltung aufheben" / "unsilence" — delete_silences nach alertname.
• "neu analysieren" — vollständige Analyse.

Stummschaltungs-Workflow:

• get_silences() — Prüfung bestehender.
• Bei Fund — ID/endsAt melden.
• Sonst — post_silence (startsAt=now, endsAt=+Dauer, ISO Z).

Slack-mrkdwn-Antwortformat:

• Schweregrad: 🔴/🟡/🟢 (nach Label, nie herabstufen).
• _Diagnose:_ Ursache.
• _Gefunden:_ Zahlen (Restarts | exitCode | Limit | Log).
• _Nächste Schritte:_ Nummerierte Aktionsliste.

Wichtige Erkenntnisse

• Das MCP-Protokoll ermöglicht der KI sicheren Lesezugriff auf die Infrastruktur ohne eigene APIs.
• Claudes Denkmuster verhindert Schleifen und Halluzinationen bei Tools.
• Strenge Abbruchkriterien minimieren Aufrufe und fokussieren auf Ursachen (OOM, CrashLoopBackOff).
• n8n-Integration lässt KI Workflows generieren und beschleunigt die Entwicklung.
• Unterstützt mehrere Clouds und K8s-Cluster über Kontext-Mapping.

— Editorial Team