Alertes provisionnées et charge de test réelle

Un tableau de bord ne réveille personne. La nuit où le quota Vertex AI d'Ondine a été atteint, l'assistant a renvoyé « assistant indisponible » à 30 % des clients pendant quatre heures ; le tableau de bord le montrait parfaitement, et personne ne le regardait. Il faut des alertes, peu nombreuses, chacune liée à une action. Et il faut les avoir vues se déclencher au moins une fois avant de leur faire confiance.

Le mécanisme : requête, seuil, durée

Une règle d'alerte gérée par Grafana évalue une requête à intervalle fixe (ici chaque minute), compare le résultat à un seuil, et ne passe en alerte que si la condition tient pendant une durée minimale (for) :

stateDiagram-v2
  [*] --> Normal
  Normal --> Pending: "condition vraie"
  Pending --> Normal: "condition fausse avant la fin de for"
  Pending --> Firing: "condition vraie pendant for"
  Firing --> Normal: "condition fausse"
  Normal --> Normal: "aucune donnée (noDataState: OK)"

Trois règles, chacune liée à une décision :

Le for filtre les pics isolés : deux minutes d'erreurs pour la première, dix minutes de dépense pour la troisième, car un pic de coût de cinq minutes ne justifie pas de réveiller quelqu'un.

La mise en œuvre

1. Les règles, en YAML versionné

      - uid: llm-taux-erreur
        title: "Taux d'erreur du modèle supérieur à 5 %"
        condition: C
        for: 2m
        noDataState: OK          # pas de trafic = pas d'erreur
        execErrState: Error
        labels: { severity: critique, equipe: support-ia }
        annotations:
          summary: "{{ humanizePercentage $values.A.Value }} des appels au modèle échouent (5 dernières minutes)"
        data:
          - refId: A
            datasourceUid: prometheus
            relativeTimeRange: { from: 600, to: 0 }
            model:
              refId: A
              instant: true
              expr: >-
                sum(rate(gen_ai_client_operation_duration_seconds_count{service_name="assistant-support",error_type!=""}[5m]))
                / sum(rate(gen_ai_client_operation_duration_seconds_count{service_name="assistant-support"}[5m]))
          - refId: C
            datasourceUid: __expr__
            model: { refId: C, type: threshold, expression: A,
                     conditions: [{ evaluator: { type: gt, params: [0.05] } }] }

A est la requête, C le seuil appliqué à A. noDataState: OK est un choix explicite : la nuit, sans trafic, la division vaut « pas de donnée », et le défaut de Grafana (NoData) déclencherait une notification chaque nuit. Ce choix a un revers, traité plus bas. Les règles provisionnées portent la mention Provisioned dans l'interface et ne s'y modifient pas : la source de vérité est le fichier.

Le test unitaire test_regles_d_alerte vérifie que chaque règle a la structure A puis C et ne cite que des métriques réellement émises.

2. Une charge de test qui ressemble au trafic

POIDS = [1 / (rang + 1) for rang in range(len(QUESTIONS))]  # loi de Zipf : quelques questions dominent

async def lancer(base, requetes, concurrence, agent, graine=7) -> dict:
    sem = asyncio.Semaphore(concurrence)
    ...
    async with httpx.AsyncClient() as client:
        await asyncio.gather(*(une(client, i) for i in range(requetes)))
    return {"requetes": requetes, "ok": ok, "erreurs": requetes - ok, "cache": caches,
            "p50_s": ..., "p95_s": ...}

Seize questions réelles du support, tirées selon une loi de Zipf : la première est posée deux fois plus souvent que la deuxième, trois fois plus que la troisième. C'est le profil habituel d'un support client, et c'est ce qui rend un cache rentable. La concurrence est bornée par un sémaphore : on simule 4 conseillers simultanés, pas une attaque.

3. Voir l'alerte se déclencher, sans clé

make demo-alerte   # FAUX_MODELE=1 TAUX_ERREUR_FAUX=0.3 E2E_REQUETES=1500 CACHE_TTL_S=0

Le faux modèle échoue en 503 sur 30 % des appels pendant un peu plus de cinq minutes, cache désactivé pour que chaque requête atteigne le modèle. Aucun appel payant.

Résultat obtenu

make demo-alerte le 2026-10-16 :

Charge (faux modèle) : {'requetes': 1500, 'ok': 1052, 'erreurs': 448, 'cache': 0, 'p50_s': 0.669, 'p95_s': 1.462}
Prometheus : {'appels_modele': 1500.0, 'tokens_entree': 73382.0, 'tokens_sortie': 54786.0, 'cout_usd': 0.15898,
              'taux_cache': 0.0, 'p95_modele_s': 1.854488, 'invocations_adk': 0.0}
Grafana : tableau « Assistant IA : latence, tokens, coût, erreurs » (13 panneaux), 3 règles d'alerte
OK en 316 s

Le coût de 0,159 USD est fictif (tokens simulés, prix réels) : il montre que la chaîne de calcul fonctionne aussi avec le faux modèle. État des règles lu par l'API de Grafana juste après :

Taux d'erreur du modèle supérieur à 5 %       firing    ['Alerting']
Latence p95 du modèle supérieure à 8 s        inactive  ['Normal']
Dépense projetée supérieure à 2 USD par heure inactive  ['Normal']

Capture réelle du 2026-10-16 : la règle provisionnée est passée à « Firing » ; la courbe du taux d'erreur tient autour de 0,3, six fois le seuil.

Les deux autres règles sont restées normales, ce qui est la bonne réponse : la latence p95 du faux modèle (1,9 s) est sous 8 s, et la dépense projetée (0,9 USD/h d'après le tableau de bord) sous 2 USD/h.

Ce qui casse en production

Dans ce lab, aucun point de contact n'est configuré : l'alerte se déclenche et reste visible dans Grafana, sans notification. C'est l'étape à ajouter avant tout usage réel.

La règle de décision

Une alerte n'existe que si quelqu'un sait quoi faire quand elle sonne : écrivez l'action dans l'annotation description. Préférez des alertes sur des ratios et des percentiles, filtrées par une durée for, à des seuils sur des valeurs brutes. Gardez-en peu : trois règles qui sonnent à raison valent mieux que vingt que l'astreinte a appris à ignorer. Déclenchez chaque nouvelle règle volontairement au moins une fois, comme make demo-alerte, avant de la considérer comme active.

Pratique

Exercice. Ajoutez une quatrième règle : « Aucune requête reçue depuis 10 minutes entre 8 h et 20 h », pour couvrir le revers de noDataState: OK.

      - uid: assistant-sans-trafic
        title: "Aucune requête reçue depuis 10 minutes en heures ouvrées"
        condition: C
        for: 10m
        noDataState: Alerting    # ici, l'absence de donnée EST le problème
        execErrState: Error
        labels: { severity: critique, equipe: support-ia }
        data:
          - refId: A
            datasourceUid: prometheus
            relativeTimeRange: { from: 600, to: 0 }
            model:
              refId: A
              instant: true
              expr: >-
                ((sum(rate(http_server_request_duration_seconds_count{service_name="assistant-support"}[10m])) or vector(0)) == bool 0
                and on() (hour() >= 6 and hour() < 18)) or vector(0)
          - refId: C
            datasourceUid: __expr__
            model: { refId: C, type: threshold, expression: A,
                     conditions: [{ evaluator: { type: gt, params: [0] } }] }

• Je sais écrire une règle d'alerte Grafana provisionnée (requête, seuil, for, noDataState).
• Je sais justifier chaque alerte par une action de l'astreinte.
• Je sais générer une charge réaliste et déclencher une alerte volontairement.
• Je sais pourquoi une alerte sans point de contact ne prévient personne.