KI-gestützte Alert-Analyse für Kubernetes und CheckMK

Monitoring-Alerts sind großartig. Man wird benachrichtigt, dass etwas nicht stimmt. Aber dann sitzt man da, liest "KubePodCrashLooping" oder "CRIT - CPU load" und fängt an, manuell Logs zu wühlen, Metriken zu checken und kubectl-Befehle zu tippen.

Irgendwann dachte ich mir: Was wäre, wenn eine KI das automatisch macht? Alert kommt rein, Kontext sammeln, Root Cause Analyse durchführen, Ergebnis als Push-Notification aufs Handy. Vor allem Nachts, wenn man gerade erst wach wird, wird die Vor-Analyse schon vorbereitet. Und so entstand der Claude Alert Analyzer.

Was macht das Ding?

Der Claude Alert Analyzer empfängt Monitoring-Alerts per Webhook, sammelt automatisch Diagnose-Daten, schickt alles an die Claude oder OpenRouter API zur Analyse und liefert das Ergebnis als Push-Notification über ntfy.

Alert feuert ==> Webhook ==> Diagnostik sammeln ==> AI API ==> ntfy NotificationCode-Sprache: PHP (php)

Das Projekt besteht aus zwei unabhängigen Analyzern, die sich eine gemeinsame Library teilen: Einer für Kubernetes, einer für CheckMK.

Phase 1: Kubernetes

Angefangen hat alles mit Kubernetes. In meinem k3s Home-Cluster laufen Prometheus und Alertmanager. Alerts landen als Webhook beim k8s-analyzer, der dann automatisch Kontext zusammensucht:

• Prometheus-Metriken, und zwar alert-spezifisch: Bei CrashLoop-Alerts werden Pod-Restart-Details geholt, bei Memory-Alerts die Top-5 Memory-Consumers, bei Disk-Alerts die PVC-Auslastung
• Kubernetes Events, Warnings aus dem betroffenen Namespace
• Pod Status, Phase, Ready-Container, Restarts
• Pod Logs, von nicht-laufenden Pods (Namespace-Allowlist, Secrets werden redacted)

Der Analyzer läuft direkt im Cluster und nutzt die in-cluster Kubernetes-Authentifizierung. Das Container-Image basiert auf scratch und ist rund 13 MB groß.

Phase 2: CheckMK

Nachdem der Kubernetes-Analyzer lief, war der nächste Gedanke naheliegend: Ich nutze auch CheckMK für klassisches Infrastructure-Monitoring. Warum nicht das gleiche Prinzip dort anwenden?

Der checkmk-analyzer hat allerdings einen entscheidenden Twist: Agentic SSH Diagnostics. Claude entscheidet selbstständig, welche Befehle auf dem betroffenen Host ausgeführt werden sollen.

Der Ablauf:

1. Alert kommt rein, Host wird gegen die CheckMK API validiert
2. Host-Metadaten und Service Check Liste werden gesammelt
3. Claude bekommt den Kontext und kann über eine Tool-Use-Schleife SSH-Befehle anfordern
4. Der Analyzer führt die Befehle aus, redacted Secrets, und gibt das Ergebnis zurück
5. Claude analysiert, fordert ggf. weitere Befehle an, bis zu 10 Runden
6. Ergebnis geht als Notification raus

Das Coole daran: Man kann pro Host einen ai_context Custom-Attribute in CheckMK setzen. Beispiel: "Debian 12, Nginx Reverse Proxy. Config unter /etc/nginx/sites-enabled/. Bei Disk-Alerts /var/log/nginx prüfen". Claude nutzt diesen Kontext dann bei der Analyse.

Sicherheit bei SSH

Eine KI, die autonom SSH-Befehle auf Servern ausführt klingt erstmal gruselig. Deshalb war Security hier besonders wichtig:

• Unprivilegierter User: Dem Claude Analyzer reichen zur Analyse standard User Berechtigungen, kein Root
• Command-Denylist: Destruktive Befehle wie rm, chmod, systemctl start/stop werden geblockt. Read-Only systemctl-Subcommands wie status oder show sind erlaubt
• Secret Redaction: Passwörter, API-Keys, PEM-Blöcke und E-Mail-Adressen werden aus dem Output entfernt, bevor Claude sie sieht
• Known-Hosts Validation: Kein Trust-on-first-use, SSH HostKeys werden als Volume gemountet
• Max 10 Runden: Die Tool-Loop ist begrenzt, danach muss Claude eine Zusammenfassung liefern
• Output-Truncation: Maximal 4096 Bytes pro Befehl

Beide Analyzer laufen in Kubernetes / als Container als Non-Root (UID 65534), mit Read-Only Root-Filesystem und alle Linux-Capabilities sind gedroppt. Siehe dazu auch meine beiden K8S Deployments claude-alert-checkmk-analyzer und claude-alert-kubernetes-analyzer.

Warum ntfy?

Die Wahl von ntfy als Notification Kanal war eigentlich keine bewusste Entscheidung. Es passt einfach am besten in meine aktuelle Infrastruktur. Alle meine Notifications landen sowieso schon bei ntfy, sowohl aus Kubernetes über den Alertmanager als auch aus CheckMK über checkmk-ntfy. Da war es nur selbstverständlich, auch die KI-Analysen dorthin zu schicken. Das Tool ist aber soweit vorbereitet, dass weitere Notification Kanäle bei Bedarf hinzugefügt werden können.

Unter der Haube

Falls es jemanden interessiert, hier ein paar technische Details:

• Sprache: Go, statische Binaries, minimale Container-Images
• LLM-Provider: Anthropic und OpenRouter werden automatisch anhand der API-URL erkannt
• Concurrency: 5 Worker ziehen aus einer gemeinsamen Queue (Kapazität 20), Kontext-Gathering läuft parallel
• Cooldown: Alerts werden per Fingerprint dedupliziert (Standard: 5 Minuten). Bei Analyse-Fehlern wird der Cooldown zurückgesetzt, damit Retries funktionieren
• Graceful Shutdown: 30 Sekunden Timeout für laufende Requests, 25 Sekunden Worker-Drain

Deployment

Die Container-Images werden bei jedem Push auf main automatisch über GitHub Actions gebaut und auf GHCR published:

ghcr.io/madic-creates/claude-alert-kubernetes-analyzer:latest
ghcr.io/madic-creates/claude-alert-checkmk-analyzer:latest

Die Konfiguration erfolgt komplett über Umgebungsvariablen. Für den k8s-analyzer braucht man im Wesentlichen den Webhook-Secret, einen AI Provider API-Key und die Prometheus-URL. Für den checkmk-analyzer kommt noch die CheckMK API-Anbindung und der SSH-Key dazu.

Fazit

Der Claude Alert Analyzer nimmt mir (noch) nicht die Arbeit ab, Probleme zu fixen, aber er nimmt mir die initiale Arbeit ab. Statt selbst Logs zu lesen und Metriken zu checken, bekomme ich direkt eine Analyse mit Kontext aufs Handy. Gerade bei Alerts, die nachts oder am Wochenende reinfliegen, spart das enorm Zeit. Und vor allem Nerven.

Das Projekt ist Open Source auf GitHub. Feedback und Contributions sind willkommen.