Alerting des défaillances d'agents

Idée en 30 secondes

Le failure alerting pour les agents IA envoie un signal précoce quand le système entre en dégradation.

L'objectif n'est pas seulement de "signaler une erreur", mais de montrer à temps ce qui casse: tools, étapes LLM, latence ou health checks.

Sans alertes, l'équipe découvre généralement les problèmes via les utilisateurs, pas via le système.

Problème principal

Les logs et le tracing expliquent bien un incident après coup.

Mais sans alertes, il est difficile de voir le moment où le problème démarre: le timeout rate monte, le synthetic success baisse, la p95 latency augmente. Du coup, il est facile de manquer la transition d'une dégradation locale vers un échec en cascade.

Voyons maintenant comment construire des alertes utiles, sans bruit excessif.

En production, on voit souvent ceci:

• le signal arrive trop tard, quand le SLO est déjà violé;
• les alertes deviennent bruyantes sur des pics temporaires et finissent ignorées;
• un seul problème génère des dizaines de doublons sur différents canaux;
• il n'y a pas de route claire: qui doit réagir et quoi faire en premier.

C'est pour cela qu'il faut concevoir l'alert-layer comme un élément distinct d'observability, pas comme un "webhook en plus".

Comment ça marche

Le failure alerting contient généralement trois niveaux:

• signaux (error_rate, timeout_rate, latency_p95, health_score);
• règles (threshold, window, severity, cooldown);
• routage (on-call, team, playbook, escalation).

Ces niveaux répondent à: quand réagir, qui réagit, et comment agir. Les logs et le tracing servent à passer rapidement de l'alerte à la root cause. En production, une alerte contient en général non seulement la severity, mais aussi owner/team ou playbook_link. Les alert rules doivent refléter des violations SLO, pas des thresholds arbitraires.

Alert noise != reliability. Si les alertes déclenchent souvent et sans priorité, l'équipe commence à les ignorer.

Les alertes apparaissent là où la dégradation est déjà visible dans les métriques, la latence ou les health checks. Les synthetic alerts montrent que le système est "vivant", mais l'utilisateur ne peut plus terminer la tâche.

Métriques de production typiques pour l'alerting

mtta et mttr sont généralement calculés au niveau de la plateforme d'incident (PagerDuty/Opsgenie/journal d'incidents interne), pas directement dans le runtime de l'agent.

Pour garder des alertes utiles, on segmente en général par severity, workflow, release et component.

Important: n'ajoute pas de champs à haute cardinalité (run_id, request_id, user_id) dans les labels, sinon les alert-metrics deviennent vite ingérables.

Comment lire l'alert-layer

Ce qui a déclenché -> pourquoi ça a déclenché -> qui doit faire quoi. Ces trois niveaux doivent toujours être lus ensemble.

Il faut regarder les tendances et la corrélation des signaux, pas une alerte isolée.

Combinaisons de signaux fréquentes:

• timeout_rate en hausse + latency_p95 en hausse -> la dégradation du service impacte déjà les utilisateurs;
• health_score en baisse + synthetic_run_success_rate en baisse -> un workflow critique ne fonctionne plus end-to-end;
• tool_error_rate en hausse + alert_fire_rate en hausse -> un tool instable crée une cascade d'alertes;
• false_positive_rate en hausse + mtta en hausse -> l'équipe perd confiance dans les alertes;
• missed_incident_rate en hausse + error_rate en hausse -> il y a des trous dans les règles d'alerting.

Quand l'utiliser

Un failure alerting complet n'est pas toujours nécessaire.

Pour un prototype simple, une alerte basique sur la chute du service peut suffire.

Mais un alerting systémique devient critique quand:

• le système d'agents est déjà en production;
• il existe des SLO/SLA sur disponibilité, latence ou succès du workflow;
• le système dépend de plusieurs tools et d'APIs externes;
• une réaction on-call est nécessaire sans surveillance manuelle des dashboards.

Exemple d'implémentation

Ci-dessous, une boucle simplifiée d'alert evaluator. L'exemple montre l'approche de base: threshold + window + cooldown + déduplication des événements.

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):
        # NOTE:
        # Cet exemple verifie seulement le dernier point (les spikes peuvent declencher des alertes).
        # En production (Prometheus/Datadog), on verifie souvent
        # que l'anomalie dure suffisamment (par exemple, "for: 5m"),
        # pour eviter des alertes sur des pics courts.
        # Alternative: verifier un depassement soutenu sur toute la fenetre,
        # pas uniquement sur le dernier point.
        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,
        }

En production, les alertes ne doivent généralement pas déclencher sur un seul spike, mais quand le seuil tient pendant toute la fenêtre.

Exemple d'affichage des alert-metrics dans un dashboard réel:

Investigation

Quand une alerte déclenche:

1. vérifier la severity et si ce n'est pas un doublon dans la fenêtre de cooldown;
2. trouver les signaux corrélés dans les métriques (latency, timeout, health);
3. ouvrir les runs problématiques dans le tracing;
4. confirmer la root cause dans les logs et exécuter le playbook.

Erreurs fréquentes

Même avec des alertes en place, elles échouent souvent à cause des erreurs suivantes.

Trop d'alertes sans priorisation

Si toutes les alertes ont la même criticité, l'équipe perd vite confiance.

Pas de cooldown ni de déduplication

Un seul problème produit des dizaines de notifications identiques et complique la réaction on-call.

Pas d'alertes basées sur les synthetic runs

Des alertes uniquement infrastructure ne garantissent pas que le workflow fonctionne réellement. À cause de cela, on peut manquer le chaos multi-agent dès les premiers signaux.

Alertes non reliées à un playbook

Les notifications existent, mais l'équipe ne sait pas quoi faire ensuite. Cela augmente le MTTR pendant un incident.

Labels à haute cardinalité dans les alert-metrics

Ajouter run_id ou request_id dans les labels surcharge rapidement le système de métriques et complique l'analyse.

Auto-vérification

Checklist courte de failure alerting baseline avant release.

FAQ

Q: Quelle différence entre failure alerting et health checks?
A: Les health checks montrent l'état actuel du système, tandis que le failure alerting décide quand et qui notifier pour une réaction rapide.

Q: Quel est le minimum d'alertes pour démarrer?
A: Commence avec timeout_rate, error_rate, latency_p95 et synthetic_run_success_rate.

Q: Comment réduire le bruit des alertes?
A: Ajoute des niveaux de severity, un cooldown, une déduplication, et retire les règles qui génèrent souvent des false positives.

Q: Comment savoir si les alertes couvrent les vrais risques?
A: Vérifie missed_incident_rate après les incidents et mets à jour les règles là où le système a dégradé sans notification.

Pages liées

Pour continuer:

• Health checks d'agents — signaux précoces de dégradation avant incident.
• Métriques d'agents — signaux système pour les alert rules.
• Monitoring de la latence des agents — comment construire des alertes basées sur la latence.
• Tracing d'agent — passer d'une alerte à l'étape problématique.
• Logging d'agents — données pour une analyse root cause rapide.