Fehler-Alerting für KI-Agenten

Idee in 30 Sekunden

Failure alerting für KI-Agenten liefert ein frühes Signal, wenn das System in eine Degradation läuft.

Das Ziel ist nicht nur, "über einen Fehler zu informieren", sondern rechtzeitig zu zeigen, was genau bricht: Tools, LLM-Schritte, Latenz oder Health Checks.

Ohne Alerts erfährt das Team meistens von Problemen durch Nutzer, nicht durch das System.

Das Hauptproblem

Logs und Tracing erklären Incidents gut im Nachhinein.

Ohne Alerts ist es aber schwer, den Moment zu erkennen, in dem ein Problem erst beginnt: timeout rate steigt, synthetic success fällt, p95 latency wächst. Dadurch wird der Übergang von lokaler Degradation zu kaskadierendem Ausfall leicht übersehen.

Als Nächstes schauen wir, wie man Alerts so baut, dass sie nützlich sind und nicht nur Lärm erzeugen.

In Production sieht das oft so aus:

• Signal kommt zu spät, wenn SLO bereits verletzt ist;
• Alerts rauschen bei temporären Spikes und werden dann ignoriert;
• ein Problem erzeugt Dutzende Duplikate über mehrere Kanäle;
• es gibt keinen klaren Pfad: wer reagieren soll und was zuerst zu tun ist.

Deshalb sollte der Alert-Layer als eigenes Element von Observability entworfen werden, nicht als "zusätzlicher Webhook".

So funktioniert es

Failure alerting besteht typischerweise aus drei Ebenen:

• Signale (error_rate, timeout_rate, latency_p95, health_score);
• Regeln (threshold, window, severity, cooldown);
• Routing (on-call, team, playbook, escalation).

Diese Ebenen beantworten: wann reagieren, wer reagiert, und wie handeln. Logs und Tracing sind nötig, um schnell vom Alert zur root cause zu kommen. In Production enthält ein Alert meist nicht nur severity, sondern auch owner/team oder playbook_link. Alert-Regeln sollten SLO-Verletzungen abbilden, nicht beliebige thresholds.

Alert noise != reliability. Wenn Alerts oft und ohne Priorisierung feuern, beginnt das Team sie zu ignorieren.

Alerts erscheinen dort, wo Degradation bereits in Metriken, Latenz oder Health Checks sichtbar ist. Synthetic alerts zeigen, dass das System zwar "lebt", der Nutzer die Aufgabe aber nicht mehr abschließen kann.

Typische Production-Metriken für Alerting

mtta und mttr werden typischerweise auf Incident-Plattform-Ebene berechnet (PagerDuty/Opsgenie/eigenes incident log), nicht direkt im Runtime-Code des Agenten.

Damit Alerts nützlich bleiben, segmentiert man sie üblicherweise nach severity, workflow, release und component.

Wichtig: keine high-cardinality Felder (run_id, request_id, user_id) in Labels aufnehmen, sonst werden Alert-Metriken schnell unbeherrschbar.

Wie man den Alert-Layer liest

Was hat ausgelöst -> warum hat es ausgelöst -> wer muss was tun. Diese drei Ebenen sollte man immer zusammen lesen.

Wichtig ist, auf Trends und Signalkorrelation zu schauen, nicht auf einen isolierten Alert.

Typische Signalkombinationen:

• timeout_rate hoch + latency_p95 hoch -> Service-Degradation wirkt sich bereits auf Nutzer aus;
• health_score runter + synthetic_run_success_rate runter -> kritischer workflow funktioniert end-to-end nicht mehr;
• tool_error_rate hoch + alert_fire_rate hoch -> instabiles Tool erzeugt eine Alert-Kaskade;
• false_positive_rate hoch + mtta hoch -> Team verliert Vertrauen in Alerts;
• missed_incident_rate hoch + error_rate hoch -> es gibt Lücken in den Alerting-Regeln.

Wann verwenden

Vollständiges failure alerting ist nicht immer nötig.

Für einen einfachen Prototyp reicht manchmal ein Basis-Alert auf Service-Down.

Systematisches Alerting wird aber kritisch, wenn:

• das Agent-System bereits in Production läuft;
• es SLO/SLA für Verfügbarkeit, Latenz oder workflow-Erfolg gibt;
• das System von mehreren Tools und externen APIs abhängt;
• eine On-Call-Reaktion ohne manuelles Dashboard-Monitoring nötig ist.

Implementierungsbeispiel

Unten ist ein vereinfachter alert-evaluator Loop. Das Beispiel zeigt einen Basisansatz: threshold + window + cooldown + Ereignis-Deduplizierung.

import time
from collections import defaultdict, deque

ALERT_RULES = {
    "high_timeout_rate": {
        "threshold": 0.05,
        "window_sec": 300,
        "severity": "high",
        "cooldown_sec": 600,
    },
    "latency_p95_regression": {
        "threshold": 2500,  # ms
        "window_sec": 300,
        "severity": "medium",
        "cooldown_sec": 600,
    },
    "synthetic_run_failed": {
        "threshold": 1,
        "window_sec": 120,
        "severity": "critical",
        "cooldown_sec": 300,
    },
}


class AlertEngine:
    def __init__(self):
        self.series = defaultdict(deque)  # metric_name -> [(ts, value), ...]
        self.last_fired_at = {}  # rule_name -> ts

    def ingest(self, metric_name, value, ts=None):
        ts = ts or time.time()
        self.series[metric_name].append((ts, value))

    def evaluate(self, ts=None):
        ts = ts or time.time()
        fired = []

        for rule_name, rule in ALERT_RULES.items():
            if self._in_cooldown(rule_name, ts, rule["cooldown_sec"]):
                continue

            if rule_name == "high_timeout_rate":
                value = self._latest_in_window("timeout_rate", ts, rule["window_sec"])
                if value is not None and value >= rule["threshold"]:
                    fired.append(self._build_alert(rule_name, value, rule, ts))

            if rule_name == "latency_p95_regression":
                value = self._latest_in_window("run_latency_p95_ms", ts, rule["window_sec"])
                if value is not None and value >= rule["threshold"]:
                    fired.append(self._build_alert(rule_name, value, rule, ts))

            if rule_name == "synthetic_run_failed":
                value = self._latest_in_window("synthetic_run_failed", ts, rule["window_sec"])
                if value is not None and value >= rule["threshold"]:
                    fired.append(self._build_alert(rule_name, value, rule, ts))

        return fired

    def _latest_in_window(self, metric_name, now_ts, window_sec):
        # HINWEIS:
        # Dieses Beispiel prüft nur den letzten Datenpunkt (Spikes können Alerts auslösen).
        # In Production (Prometheus/Datadog) prüft man üblicherweise,
        # ob die Anomalie über eine gewisse Dauer anhält (z. B. "for: 5m"),
        # um Alerts bei kurzen Spikes zu vermeiden.
        # Alternative: sustained breach über das ganze window prüfen,
        # nicht nur den letzten Punkt.
        points = self.series[metric_name]
        while points and now_ts - points[0][0] > window_sec:
            points.popleft()
        return points[-1][1] if points else None

    def _sustained_breach(self, metric_name, now_ts, window_sec, threshold):
        points = self.series[metric_name]
        while points and now_ts - points[0][0] > window_sec:
            points.popleft()
        return points and all(v >= threshold for _, v in points)

    def _in_cooldown(self, rule_name, now_ts, cooldown_sec):
        last_ts = self.last_fired_at.get(rule_name)
        return last_ts is not None and now_ts - last_ts < cooldown_sec

    def _build_alert(self, rule_name, value, rule, now_ts):
        self.last_fired_at[rule_name] = now_ts
        return {
            "rule": rule_name,
            "severity": rule["severity"],
            "value": value,
            "timestamp": now_ts,
        }

In Production feuert ein Alert in der Regel nicht bei einem einzelnen Spike, sondern wenn der Schwellenwert im ganzen window gehalten wird.

So können Alert-Metriken in einem realen Dashboard aussehen:

Investigation

Wenn ein Alert feuert:

1. severity pruefen und ob es ein Duplikat im cooldown window ist;
2. korrelierte Signale in den Metriken finden (latency, timeout, health);
3. problematische runs im Tracing öffnen;
4. root cause in Logs bestätigen und Playbook starten.

Typische Fehler

Selbst wenn Alerts vorhanden sind, funktionieren sie oft nicht wie erwartet wegen typischer Fehler.

Zu viele Alerts ohne Priorisierung

Wenn alle Alerts gleich kritisch sind, verliert das Team schnell das Vertrauen.

Kein cooldown und keine Deduplizierung

Ein Problem erzeugt Dutzende identische Benachrichtigungen und erschwert die On-Call-Reaktion.

Keine synthetic-basierten Alerts

Alerts nur auf Infrastruktur-Metriken garantieren nicht, dass der workflow wirklich funktioniert. Dadurch kann frühes Multi-Agent-Chaos übersehen werden.

Alerts sind nicht mit einem Playbook verknüpft

Benachrichtigungen sind da, aber das Team weiß nicht, was als Nächstes zu tun ist. Das erhöht MTTR während eines Incidents.

High-cardinality Labels in Alert-Metriken

run_id oder request_id in Labels überlasten das Metriksystem schnell und erschweren die Analyse.

Selbstcheck

Unten ist eine kurze Checkliste für baseline failure alerting vor dem Release.

FAQ

Q: Worin unterscheidet sich failure alerting von health checks?
A: Health checks zeigen den aktuellen Systemzustand, während failure alerting festlegt, wann und wen man für eine rechtzeitige Reaktion benachrichtigt.

Q: Welches minimale Alert-Set braucht man zum Start?
A: Starte mit timeout_rate, error_rate, latency_p95 und synthetic_run_success_rate.

Q: Wie reduziert man Alert-Rauschen?
A: Füge severity-Level, cooldown und Deduplizierung hinzu und entferne Regeln mit häufigen false positives.

Q: Wie erkennt man, ob Alerts reale Risiken abdecken?
A: Prüfe missed_incident_rate nach Incidents und aktualisiere Regeln dort, wo das System ohne Benachrichtigung degradiert ist.

Verwandte Seiten

Weiter zum Thema:

• Agent Health Checks — frühe Degradationssignale vor dem Incident.
• Agent-Metriken — Systemsignale für Alert-Regeln.
• Agent-Latenz-Monitoring — wie man latency-basierte Alerts baut.
• Agent-Tracing — wie man vom Alert zum problematischen Schritt geht.
• Agent-Logging — Daten für schnelle Root-Cause-Analyse.