Requêtes MetricsQL et tableaux de bord Grafana

Module 7 : MetricsQL, les requêtes essentielles

7.1 Fonctionnalités MetricsQL utiles à l’observabilité LLM

MetricsQL est largement compatible avec PromQL : la plupart des requêtes PromQL s’exécutent sans modification. Quelques extensions sont particulièrement utiles ici :

Fonctionnalité	Usage pour les charges LLM
rate() et increase() sans extrapolation	Totaux de coût plus proches des valeurs réelles sur des compteurs peu alimentés
Fenêtre d’analyse facultative (rate(x) utilise automatiquement le pas)	Requêtes de tableau de bord plus simples
median_over_time, quantile_over_time	Statistiques robustes sur les scores et les nombres de tokens
rollup_candlestick	Ouverture, plus haut, plus bas, clôture d’une série (par exemple les scores RAG)
outliers_mad	Repère les séries qui s’écartent du groupe (par exemple un modèle parmi d’autres)
Modèles WITH	Réutiliser des sous-expressions dans les requêtes longues

7.2 Requêtes de coût et de tokens

Coût LLM horaire par modèle (USD) :

sum by (model, provider) (increase(llm_cost_usd_total[1h]))

Projection du coût quotidien (extrapolée à partir des 30 dernières minutes) :

sum by (model) (rate(llm_cost_usd_total[30m])) * 86400

Les 10 tenants les plus coûteux (dernières 24 heures) :

topk(10, sum by (tenant_id) (increase(llm_cost_usd_total[24h])))

Ratio tokens de sortie sur tokens d’entrée (repérer les requêtes atypiques) :

sum(rate(llm_tokens_total{type='output'}[5m]))
  /
sum(rate(llm_tokens_total{type='input'}[5m]))

7.3 Requêtes de qualité RAG

Anomalie du score de recherche : détecter la dérive d’un index

Correction : anomaly_score n’est pas une fonction MetricsQL

La première version de ce guide utilisait une requête de la forme anomaly_score(avg by (index_id) (rag_retrieval_score_avg), '7d'). Cette fonction n’existe pas dans MetricsQL. anomaly_score est une métrique écrite dans VictoriaMetrics par vmanomaly, le composant de détection d’anomalies de l’offre Enterprise ; on l’interroge ensuite comme n’importe quelle série (par exemple anomaly_score{for="rag_retrieval_score"} > 1, selon la configuration de vmanomaly). Avec la version open source, calculez un z-score par rapport à une référence de 7 jours, comme ci-dessous.

Z-score du score de recherche par rapport à une référence de 7 jours (résolution horaire) :

(
  avg by (index_id) (rag_retrieval_score_avg)
  - avg_over_time(avg by (index_id) (rag_retrieval_score_avg)[7d:1h])
)
/
stddev_over_time(avg by (index_id) (rag_retrieval_score_avg)[7d:1h])

Une valeur proche de 0 signifie « comme d’habitude ». Une valeur fortement négative (par exemple inférieure à -3, à calibrer sur votre historique) signale une baisse de la qualité de recherche. Deux limites : la référence exige sept jours d’historique et un écart type proche de zéro (score très stable) rend le ratio instable. La fonction MetricsQL outliers_mad est un outil complémentaire quand vous voulez comparer les index entre eux plutôt qu’à leur propre passé.

Pression de contexte P95 par pipeline :

histogram_quantile(0.95,
  sum by (le, pipeline_id) (
    rate(rag_context_pressure_ratio_bucket[10m])
  )
)

Chunks abandonnés pour 100 requêtes :

sum by (pipeline_id) (rate(rag_chunks_dropped_total[5m]))
  /
sum by (pipeline_id) (rate(llm_requests_total[5m]))
  * 100

Ce que mesure ce ratio

La première version de ce guide intitulait cette requête « requêtes avec chunks abandonnés (%) ». Le numérateur compte des chunks et le dénominateur des requêtes : le résultat est donc le nombre de chunks abandonnés pour 100 requêtes. Pour obtenir un vrai pourcentage de requêtes touchées, comptez les requêtes concernées dans un compteur dédié.

7.4 Requêtes de performance et de latence

Latence de bout en bout P99 par modèle :

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

TTFT P95, délai avant le premier token (time to first token, critique en streaming) :

histogram_quantile(0.95,
  sum by (le, model) (rate(llm_ttft_ms_bucket[5m]))
)

Efficacité énergétique GPU, tokens de sortie par joule :

sum(rate(llm_tokens_total{type='output'}[5m]))
  /
sum(DCGM_FI_DEV_POWER_USAGE)

Correction : tokens par watt

La première version de ce guide divisait un sum by (model) de tokens par avg by (model) (DCGM_FI_DEV_POWER_USAGE). Les séries du DCGM exporter ne portent pas de label model au sens LLM (leur label modelName désigne le modèle de GPU) : la division ne trouvait aucune correspondance. La requête ci-dessus calcule un ratio global. Pour l’obtenir par modèle LLM, rattachez d’abord le modèle aux séries GPU, par exemple par une jointure sur pod ou namespace avec une métrique qui associe pods et modèles. Notez aussi l’unité : des tokens par seconde divisés par des watts donnent des tokens par joule.

Module 8 : tableaux de bord Grafana, structure et panneaux

Un tableau de bord LLM type s’organise en quatre rangées fonctionnelles qui reprennent les quatre dimensions de la taxonomie : vue d’ensemble du service (trafic, latence, erreurs), qualité RAG, coûts et tokens, infrastructure GPU.

8.1 Configuration de la source de données

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.

# Source de données provisionnée (grafana/provisioning/datasources/vm.yaml)
apiVersion: 1
datasources:
  - name: VictoriaMetrics
    type: victoriametrics-metrics-datasource
    url: http://victoriametrics:8428
    access: proxy
    isDefault: true
    jsonData:
      timeInterval: '15s'

8.2 Variables de modèle

# Variable 'model' : liste des modèles actifs
label_values(llm_requests_total, model)

# Variable 'provider'
label_values(llm_requests_total{model=~'$model'}, provider)

# Variable 'pipeline_id'
label_values(rag_retrieval_score_avg, pipeline_id)

8.3 Types de panneaux recommandés par métrique

Métrique	Type de panneau	Options clés
Requêtes par minute (SLA)	Stat + sparkline	Vert au-dessus de 0, orange si dérive de plus de 20 %
Latence P99	Stat + seuil	Seuils absolus selon le SLO contractuel
Taux d’erreur	Stat + seuil	Rouge au-dessus de 1 %, orange au-dessus de 0,5 %
Score de recherche sur 7 jours	Série temporelle	Courbe du score, seuil à 0,70, z-score en seconde requête
Pression de contexte P95	Série temporelle + seuil	Zone rouge au-dessus de 0,85
Coût cumulé par modèle	Série temporelle en aires empilées	Une couleur par modèle, unité USD
Distribution des tokens	Carte de chaleur ou histogramme	Fait ressortir les requêtes anormalement longues
Utilisation GPU	Jauge + seuil	Orange à 80 %, rouge à 95 %
File d’attente vLLM	Série temporelle	Alerte au-delà de 10 requêtes en attente
Z-score du score de recherche	Série temporelle	Seuil à calibrer (par exemple -3), ou anomaly_score si vous utilisez vmanomaly

Marquer comme lue