Alertes, règles d'enregistrement et SLO

Module 9 : vmalert, règles d’alerte de production

9.1 Jeu de règles complet

En cours de validation en lab

Configuration pas encore exécutée de bout en bout dans un lab : les noms, versions et paramètres peuvent demander des ajustements.

alerts/llm-quality.yml

groups:
  - name: llm_quality
    interval: 1m
    rules:

      # Dérive d'un index RAG
      - alert: RAGIndexDrift
        expr: |
          avg by (index_id, pipeline_id) (
            avg_over_time(rag_retrieval_score_avg[1h])
          ) < 0.70
        for: 15m
        labels: { severity: warning, team: ai-platform }
        annotations:
          summary: 'Dérive de l''index RAG {{ $labels.index_id }}'
          description: |
            Score de recherche moyen = {{ $value | printf "%.2f" }} < seuil 0.70
            depuis 15 min sur le pipeline {{ $labels.pipeline_id }}.
            Action : vérifier les mises à jour de documents sans réindexation.
          runbook_url: 'https://wiki.internal/runbooks/rag-index-drift'

      # Pression de contexte critique
      - alert: RAGContextPressureHigh
        expr: |
          histogram_quantile(0.95,
            sum by (le, pipeline_id) (
              rate(rag_context_pressure_ratio_bucket[10m])
            )
          ) > 0.85
        for: 5m
        labels: { severity: warning, team: ai-platform }
        annotations:
          summary: 'Pression de contexte P95 élevée : {{ $labels.pipeline_id }}'
          description: 'P95 = {{ $value | printf "%.2f" }}. Réduire le prompt système ou agrandir la fenêtre de contexte.'

      # Taux d'erreur LLM élevé
      - alert: LLMHighErrorRate
        expr: |
          sum by (model, provider) (rate(llm_errors_total[5m]))
            /
          sum by (model, provider) (rate(llm_requests_total[5m]))
            > 0.01
        for: 3m
        labels: { severity: critical, team: ai-platform }
        annotations:
          summary: 'Taux d''erreur > 1 % sur {{ $labels.model }} / {{ $labels.provider }}'
          description: 'Taux actuel : {{ $value | humanizePercentage }}. Vérifier la disponibilité du fournisseur.'

      # Dépassement du SLO de latence
      - alert: LLMLatencySLOBreach
        expr: |
          histogram_quantile(0.99,
            sum by (le, model, pipeline_id) (
              rate(llm_request_duration_ms_bucket[5m])
            )
          ) > 5000
        for: 5m
        labels: { severity: critical, team: ai-platform }
        annotations:
          summary: 'SLO de latence P99 dépassé sur {{ $labels.model }}'
          description: 'P99 = {{ $value | printf "%.0f" }} ms > SLO 5000 ms. Pipeline {{ $labels.pipeline_id }}'

      # Saturation de la mémoire GPU
      - alert: GPUMemorySaturation
        expr: DCGM_FI_DEV_FB_USED / (DCGM_FI_DEV_FB_USED + DCGM_FI_DEV_FB_FREE) * 100 > 90
        for: 2m
        labels: { severity: warning, team: mlops }
        annotations:
          summary: 'Mémoire du GPU {{ $labels.gpu }} saturée ({{ $value | printf "%.0f" }} %)'
          description: 'Risque d''OOM. Réduire la taille de lot ou la fenêtre de contexte du modèle.'

      # Budget LLM quotidien (budget de l'exemple : 100 USD par jour, à remplacer par le vôtre).
      # llm_cost_usd_total n'existe que si une grille de prix est fournie (module 6.3).
      - alert: LLMDailyBudgetWarning
        expr: |
          sum by (tenant_id) (
            increase(llm_cost_usd_total[24h])
          ) > 80
        labels: { severity: warning, team: billing }
        annotations:
          summary: 'Budget LLM à 80 % pour le tenant {{ $labels.tenant_id }}'
          description: 'Coût sur 24 h = {{ $value | printf "%.2f" }} USD. Seuil : 100 USD par jour.'

Corrections par rapport à la première version de ce guide

• LLMHighErrorRate : l’expression renvoie un ratio (0,01 pour 1 %), alors que la description de la première version de ce guide l’affichait suivi d’un signe %, comme s’il s’agissait déjà d’un pourcentage. La description utilise désormais humanizePercentage.
• GPUMemorySaturation : la première version de ce guide utilisait DCGM_FI_DEV_FB_TOTAL, qui ne figure généralement pas dans le fichier de compteurs par défaut de dcgm-exporter (vérifiez le vôtre). L’expression ci-dessus s’appuie sur DCGM_FI_DEV_FB_USED et DCGM_FI_DEV_FB_FREE, qui y figurent. Si vous activez le champ total, vous pouvez l’utiliser à la place.

9.2 Routage Alertmanager par équipe

alertmanager.yml

global:
  slack_api_url: 'https://hooks.slack.com/services/REPLACE_ME'

route:
  group_by: ['alertname', 'model', 'pipeline_id']
  group_wait: 30s
  repeat_interval: 12h
  receiver: 'default'
  routes:
    - matchers: ['severity="critical"']
      receiver: pagerduty
    - matchers: ['team="ai-platform"']
      receiver: slack-ai-platform
    - matchers: ['team="billing"']
      receiver: slack-billing

receivers:
  - name: 'default'
    slack_configs:
      - channel: '#llm-ops-alerts'
        title: '{{ .CommonAnnotations.summary }}'
        text: '{{ .CommonAnnotations.description }}'
  - name: 'slack-ai-platform'
    slack_configs:
      - channel: '#ai-platform-alerts'
  - name: 'slack-billing'
    slack_configs:
      - channel: '#billing-alerts'
  - name: 'pagerduty'
    pagerduty_configs:
      - routing_key: 'YOUR_PAGERDUTY_KEY'

Configuration complétée

La première version de ce guide faisait référence aux récepteurs slack-ai-platform et slack-billing sans les déclarer et ne donnait pas d’URL de webhook Slack : Alertmanager refuse de charger un tel fichier. Les deux récepteurs sont déclarés ci-dessus (les noms de canaux sont des exemples) et l’URL du webhook est fixée dans global.slack_api_url. Gardez les secrets hors de Git (utilisez api_url_file ou routing_key_file quand ils existent). Notez qu’une alerte critique s’arrête à la première route correspondante (PagerDuty), sauf si vous ajoutez continue: true.

Module 10 : règles d’enregistrement, pré-agréger les métriques de coût

Les métriques de coût sont interrogées très souvent par les tableaux de bord. Recalculer increase(llm_cost_usd_total[24h]) à chaque rafraîchissement consomme beaucoup de CPU. Les règles d’enregistrement (recording rules) précalculent ces agrégations en tâche de fond : le tableau de bord lit alors une seule série par combinaison de labels au lieu de recalculer l’agrégation sur toutes les séries brutes. Le gain dépend du nombre de séries et de la fenêtre interrogée ; mesurez-le sur votre instance (c’est l’objet du Lab 4).

alerts/recording-rules.yml

groups:
  - name: llm_recording_rules
    interval: 1m
    rules:

      - record: llm:cost_usd:increase1h
        expr: |
          sum by (model, provider, tenant_id) (
            increase(llm_cost_usd_total[1h])
          )

      - record: llm:cost_usd:increase24h
        expr: |
          sum by (model, provider, tenant_id) (
            increase(llm_cost_usd_total[24h])
          )

      - record: llm:error_rate:ratio5m
        expr: |
          sum by (model, provider) (rate(llm_errors_total[5m]))
            /
          sum by (model, provider) (rate(llm_requests_total[5m]))

      - record: llm:request_duration_ms:p99_5m
        expr: |
          histogram_quantile(0.99,
            sum by (le, model, pipeline_id) (
              rate(llm_request_duration_ms_bucket[5m])
            )
          )

      - record: llm:ttft_ms:p95_5m
        expr: |
          histogram_quantile(0.95,
            sum by (le, model) (rate(llm_ttft_ms_bucket[5m]))
          )

      - record: rag:retrieval_score:avg30m
        expr: |
          avg by (index_id, pipeline_id) (
            avg_over_time(rag_retrieval_score_avg[30m])
          )

      - record: rag:context_pressure:p95_10m
        expr: |
          histogram_quantile(0.95,
            sum by (le, pipeline_id) (
              rate(rag_context_pressure_ratio_bucket[10m])
            )
          )

      - record: gpu:memory_utilization:ratio
        expr: DCGM_FI_DEV_FB_USED / (DCGM_FI_DEV_FB_USED + DCGM_FI_DEV_FB_FREE)

Nommage

Les deux premières règles s’appelaient llm:cost_usd:rate1h et rate24h dans la première version de ce guide, alors qu’elles calculent un increase. Elles sont renommées increase1h et increase24h pour respecter la convention niveau:métrique:opération.

Utiliser les règles d’enregistrement dans les alertes et les tableaux de bord

Une fois les règles définies, utilisez les séries enregistrées plutôt que la requête complète. Au lieu de :

histogram_quantile(0.99, sum by (le, model, pipeline_id) (rate(llm_request_duration_ms_bucket[5m])))

utilisez :

llm:request_duration_ms:p99_5m

La requête est beaucoup plus rapide. Le résultat est équivalent, à la résolution de l’intervalle d’évaluation de la règle près (ici une minute) et avec les labels d’agrégation choisis dans la règle.

Module 11 : SLO et SLA pour les charges LLM

Un objectif de niveau de service (Service Level Objective, SLO) traduit une exigence métier en cible mesurable. Pour les LLM, les SLO classiques (disponibilité, latence) restent valables mais ne suffisent pas : ajoutez la qualité et le coût.

11.1 Modèle de SLO LLM en cinq catégories

Catégorie	Indicateur (SLI)	SLO (exemple à adapter)	Fenêtre
Disponibilité	1 - rate(llm_errors_total[5m]) / rate(llm_requests_total[5m])	99,5 %	30 jours
Latence interactive	histogram_quantile(0.95, ...llm_ttft_ms...)	< 1 200 ms	7 jours
Latence batch	histogram_quantile(0.99, ...llm_request_duration_ms...)	< 8 000 ms	30 jours
Qualité de recherche	avg(rag_retrieval_score_avg)	> 0,78	24 h
Consommation par requête	sum(increase(llm_tokens_total[1h])) / sum(increase(llm_requests_total[1h]))	< 2 000 tokens (exemple à adapter)	Mois calendaire
Coût par requête (avec une grille de prix)	sum(increase(llm_cost_usd_total[1h])) / sum(increase(llm_requests_total[1h]))	votre cible, dans la devise de la métrique	Mois calendaire

Tokens d’abord, devise ensuite

Les prix changent vite et varient selon les contrats : ce guide n’en donne pas ; utilisez la grille datée de votre fournisseur. La cible en tokens ne dépend d’aucun tarif et reste valable quand les prix changent. La cible de coût s’exprime dans la même devise que la métrique (USD ici), ou se convertit explicitement avec un taux de change daté : la première version de ce guide l’exprimait en EUR alors que la métrique est en USD.

11.2 Calcul du budget d’erreur

Le budget d’erreur (error budget) est le complément du SLO à 100 %. Pour une disponibilité de 99,5 % sur 30 jours, le budget d’erreur vaut 0,5 %, soit 3 h 36 min d’indisponibilité tolérée par mois.

# Budget d'erreur consommé sur la fenêtre du SLO (en %)
(
  1
  -
  (
    sum(increase(llm_requests_total[30d]))
    -
    sum(increase(llm_errors_total[30d]))
  )
  /
  sum(increase(llm_requests_total[30d]))
) / 0.005 * 100

11.3 Alertes sur le taux de consommation (motif Google SRE)

Alertez quand le budget d’erreur se consomme trop vite (burn rate). Chaque alerte combine une fenêtre longue et une fenêtre courte : la fenêtre longue confirme la tendance, la fenêtre courte fait retomber l’alerte rapidement une fois le problème corrigé.

- alert: LLMFastBurn
  expr: |
    (
      sum(rate(llm_errors_total[1h])) / sum(rate(llm_requests_total[1h]))
    ) > (14.4 * 0.005)
    and
    (
      sum(rate(llm_errors_total[5m])) / sum(rate(llm_requests_total[5m]))
    ) > (14.4 * 0.005)
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: "Consommation du budget d'erreur 14,4 fois la normale (épuisé en 2 jours environ)"

- alert: LLMSlowBurn
  expr: |
    (
      sum(rate(llm_errors_total[6h])) / sum(rate(llm_requests_total[6h]))
    ) > (6 * 0.005)
    and
    (
      sum(rate(llm_errors_total[30m])) / sum(rate(llm_requests_total[30m]))
    ) > (6 * 0.005)
  for: 15m
  labels:
    severity: warning
  annotations:
    summary: "Consommation du budget d'erreur 6 fois la normale (épuisé en 5 jours)"

Correction : seconde fenêtre pour LLMSlowBurn

Dans la première version de ce guide, LLMSlowBurn ne vérifiait qu’une fenêtre de 6 heures. Le motif multi-fenêtres de Google SRE associe la fenêtre de 6 heures à une fenêtre de 30 minutes (un douzième de la fenêtre longue). Sans elle, l’alerte reste active des heures après la fin de l’incident. La seconde condition a été ajoutée.

Révisé le 2 octobre 2026 : prix retirés ; la cible chiffrée de coût par requête est remplacée par une cible en tokens par requête, la cible de coût étant laissée à votre grille de prix.

Marquer comme lue