Exploitation : rétention, sécurité, migration et FAQ

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.

Module 12 : optimisation, rétention et réglages

12.1 Politique de rétention par type de métrique

Toutes les métriques LLM ne méritent pas la même rétention. Le tableau donne des durées recommandées ; la dernière colonne indique comment les mettre en œuvre.

Type de métrique	Rétention recommandée	Justification	Mise en œuvre
Métriques de coût en USD	exemple : 2 à 3 ans, à fixer selon vos obligations	Audit comptable, SLA contractuels	Instance « longue » (-retentionPeriod=3y) ou filtre Enterprise
Scores de qualité RAG	6 à 12 mois	Détection de dérive à long terme	Instance « moyenne » (-retentionPeriod=12M) ou filtre Enterprise
Latence et débit	3 à 6 mois	Tendances de performance	Instance « courte » (-retentionPeriod=6M) ou filtre Enterprise
Métriques GPU	1 à 3 mois	Planification de capacité	Instance « courte » ou filtre Enterprise
Traces OTel	7 à 30 jours	Débogage, pas d’audit à long terme	Durée de vie (TTL) du backend de traces (Jaeger, Tempo), hors VictoriaMetrics

Correction : la rétention est globale à une instance

La première version de ce guide donnait une valeur de -retentionPeriod différente sur chaque ligne, comme si la rétention se réglait par métrique. Dans VictoriaMetrics open source, -retentionPeriod est global à une instance (à chaque vmstorage en mode Cluster). Pour conserver des métriques pendant des durées différentes, deux options :

1. Open source : faire tourner plusieurs instances (ou, en mode Cluster, des groupes de vmstorage dédiés), chacune avec son propre -retentionPeriod et y router les séries avec vmagent (un -remoteWrite.url par cible, filtré par -remoteWrite.urlRelabelConfig).
2. Enterprise : utiliser -retentionFilter sur une instance unique, par exemple -retentionFilter='{__name__=~"DCGM_.*"}:90d'.

Attention aussi à la syntaxe : sans suffixe, la valeur est en mois de 31 jours (-retentionPeriod=12 signifie 12 mois), une forme que le code source déclare dépréciée. La documentation liste les suffixes s, h, d, w, M (mois, en majuscule) et y. Écrivez -retentionPeriod=24M ou 2y, jamais 24m en minuscule : m désigne les minutes et VictoriaMetrics le refuse pour cette option. La valeur par défaut est 1M et le minimum 1d (voir la section Retention de la documentation).

Exemple de routage open source vers deux instances avec vmagent :

vmagent-prod \
  -promscrape.config=/etc/prometheus.yml \
  -remoteWrite.url=http://vm-long:8428/api/v1/write \
  -remoteWrite.urlRelabelConfig=/etc/vmagent/keep-cost.yml \
  -remoteWrite.url=http://vm-short:8428/api/v1/write \
  -remoteWrite.urlRelabelConfig=/etc/vmagent/drop-cost.yml

# /etc/vmagent/keep-cost.yml : seules les séries de coût et de tokens vont vers vm-long
- action: keep
  source_labels: [__name__]
  regex: 'llm_cost_usd_total|llm_tokens_total|llm:cost_usd:.*'

# /etc/vmagent/drop-cost.yml : tout le reste va vers vm-short
- action: drop
  source_labels: [__name__]
  regex: 'llm_cost_usd_total|llm_tokens_total|llm:cost_usd:.*'

Grafana a alors besoin d’une source de données par instance, ou d’une couche vmauth devant elles si vous voulez un point d’entrée unique.

12.2 Optimiser la cardinalité

• N’étiquetez jamais par trace_id, request_id ou session_id : la cardinalité devient illimitée.
• Réservez tenant_id aux métriques de coût (pas aux métriques de latence ni de tokens).
• Regroupez les modèles proches sous un label model_family si plus de 20 versions sont actives.
• Utilisez des intervalles d’histogramme adaptés aux tokens : [10, 100, 500, 1000, 4096, 16384, 65536].

# Statistiques de cardinalité par l'API :
#   http://victoriametrics:8428/api/v1/status/tsdb
# (également dans vmui, « Cardinality explorer »)

# Les 10 métriques ayant le plus de séries (coûteux sur une grosse instance)
topk(10, count by (__name__) ({__name__!=""}))

12.3 Options de réglage de VictoriaMetrics pour la production LLM

Commencez avec les valeurs par défaut et ne modifiez une option qu’après avoir constaté un besoin (requêtes refusées, lots rejetés, pression mémoire).

# -loggerFormat=json : journaux structurés, plus simples à exploiter dans une pile de journaux
victoria-metrics-prod \
  -storageDataPath=/var/lib/vm-data \
  -retentionPeriod=12M \
  -httpListenAddr=:8428 \
  -loggerFormat=json

Les options suivantes sont souvent présentées comme des réglages, mais leurs valeurs usuelles sont déjà les valeurs par défaut (liste des options de VictoriaMetrics v1.153.0) :

Option	Valeur par défaut	Quand la modifier
-maxInsertRequestSize	33 554 432 octets (32 MiB)	Si des lots de remote write sont refusés comme trop gros
-search.maxQueryLen	16 384 octets	Si des requêtes MetricsQL très longues sont refusées
-search.maxSamplesPerQuery	1 000 000 000	Si des requêtes d’audit sur de longues fenêtres atteignent la limite
-memory.allowedPercent	60	Si les caches manquent de place ou si le cache de pages du système est trop réduit
-loggerLevel	INFO	Pour réduire ou augmenter le volume de journaux

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

La première version de ce guide présentait ces options comme des réglages de production, avec leurs valeurs par défaut (et -maxInsertRequestSize=32MB, qui, en unités décimales, est légèrement inférieur au défaut de 32 MiB). Elle plaçait aussi des commentaires après les barres obliques inverses de continuation (\ # commentaire) : dans un shell, cela casse la continuation et les options suivantes sont ignorées sans message. Consultez -help pour votre version.

Module 13 : sécurité, air-gap et conformité

13.1 Authentification et contrôle d’accès

• VictoriaMetrics n’offre qu’une authentification basique globale (-httpAuth.username, -httpAuth.password) et des clés par point d’accès. Pour un contrôle d’accès par utilisateur, placez vmauth (open source) ou un proxy inverse devant.
• vmauth permet un routage par utilisateur : lecture seule pour Grafana, écriture seule pour l’OTel Collector, administration pour l’exploitation.
• Dans Kubernetes, une NetworkPolicy restreint l’accès aux ports de VictoriaMetrics aux seuls composants autorisés.

# configuration vmauth
users:
  - username: grafana
    password: '%{GRAFANA_PASSWORD}'
    url_map:
      - src_paths:
          - '/api/v1/query'
          - '/api/v1/query_range'
          - '/api/v1/series'
          - '/api/v1/labels'
          - '/api/v1/label/.+/values'
        url_prefix: 'http://victoriametrics:8428'

  - username: otel-collector
    password: '%{OTEL_PASSWORD}'
    url_map:
      - src_paths:
          - '/api/v1/write'
          - '/opentelemetry/.+'
        url_prefix: 'http://victoriametrics:8428'

Correction : restreindre les chemins dans vmauth

La première version de ce guide listait plusieurs URL complètes sous url_prefix pour limiter chaque utilisateur à certains points d’accès. Dans vmauth, une liste sous url_prefix signifie répartition de charge entre backends, pas filtrage des chemins : l’utilisateur Grafana aurait pu atteindre n’importe quel point d’accès. La restriction par chemin se fait avec url_map et src_paths, comme ci-dessus. Grafana a aussi besoin des points d’accès des séries et des labels pour ses variables. Dans les fichiers de configuration VictoriaMetrics, les variables d’environnement s’écrivent %{VAR}, pas ${VAR}.

13.2 Checklist de conformité pour les métriques LLM

Point de conformité	Mise en œuvre recommandée
Données personnelles dans les métriques	Ne jamais mettre le contenu des requêtes utilisateur dans des labels. Identifiants opaques uniquement.
Audit des coûts	Rétention alignée sur vos obligations comptables et contractuelles pour llm_cost_usd_total. Export CSV mensuel.
Chiffrement en transit	TLS sur tous les points d’accès VictoriaMetrics en production (vmauth ou proxy inverse).
Isolation multi-tenant	vmauth pour segmenter les accès par tenant, équipes et RBAC Grafana.
Sauvegarde	vmbackup incrémental vers un stockage compatible S3 (MinIO en air-gap).
Accès aux tableaux de bord	Grafana avec SSO (LDAP, OIDC). Lecture seule pour les équipes métier.

Base réglementaire

La première version de ce guide intitulait la ligne d’audit des coûts « RGPD/NIS2 ». Ni le RGPD ni NIS2 n’imposent de durée de conservation pour des métriques de coût LLM : la durée découle de vos obligations comptables, fiscales et contractuelles. Le RGPD s’applique en revanche à la première ligne (données personnelles dans les labels).

Module 14 : migrer depuis Prometheus

VictoriaMetrics peut remplacer Prometheus comme backend de stockage et de requête dans la plupart des cas. La migration ci-dessous se déroule en cinq étapes ; elle est conçue pour éviter toute interruption de service et toute perte de données, à condition de vérifier chaque étape.

14.1 Inventaire préalable

• Recensez toutes les sources Prometheus actuelles (cibles collectées, remote write).
• Mesurez la cardinalité actuelle : promtool tsdb analyze /var/lib/prometheus/data/.
• Recensez tous les tableaux de bord Grafana qui pointent vers Prometheus.
• Recensez toutes les règles Prometheus (alerte et enregistrement).
• Repérez les requêtes qui reposent sur un comportement PromQL que MetricsQL traite différemment (voir 14.4).

14.2 Stratégie de double écriture (pour éviter l’interruption)

Pendant deux à quatre semaines, écrivez les métriques à la fois dans Prometheus et dans VictoriaMetrics. Vous comparez ainsi les deux backends sans risque.

# prometheus.yml : ajouter un remote_write vers VictoriaMetrics
remote_write:
  - url: http://victoriametrics:8428/api/v1/write
    queue_config:
      capacity: 10000
      max_shards: 30
      max_samples_per_send: 5000
      batch_send_deadline: 5s

14.3 Import de l’historique Prometheus

Pour conserver l’historique, utilisez vmctl (ses options prennent un double tiret). --vm-concurrency vaut 2 par défaut ; laissez --vm-batch-size à sa valeur par défaut (200 000 échantillons) sauf besoin mesuré :

# Import depuis un instantané Prometheus
vmctl prometheus \
  --prom-snapshot=/var/lib/prometheus/snapshots/20260101T000000Z-abc \
  --vm-addr=http://victoriametrics:8428 \
  --vm-concurrency=8

# Vérifier dans vmui :
# http://victoriametrics:8428/vmui/?g0.expr=count(up)

14.4 Migration des tableaux de bord Grafana

Deux options selon la taille du parc de tableaux de bord :

• Option simple : changer l’URL de la source de données Prometheus existante. La plupart des tableaux de bord continuent de fonctionner, puisque MetricsQL accepte la syntaxe PromQL.
• Option recommandée : ajouter une nouvelle source VictoriaMetrics (plugin natif), migrer les tableaux de bord un par un, puis supprimer la source Prometheus à la fin de la double écriture.

MetricsQL n’est pas strictement un sur-ensemble

MetricsQL est rétrocompatible avec la syntaxe PromQL, mais certains résultats diffèrent par construction : rate() et increase() n’extrapolent pas et tiennent compte du dernier échantillon avant la fenêtre, si bien qu’increase() renvoie des valeurs plus exactes (souvent entières) que dans Prometheus. Comparez les panneaux et les alertes clés pendant la phase de double écriture avant de basculer.

14.5 Bascule finale et gains à mesurer

Avant de couper Prometheus, mesurez les mêmes indicateurs sur les deux backends pendant la double écriture, avec la même rétention et les mêmes requêtes :

Indicateur	Comment le mesurer
RAM utilisée	Mémoire résidente des processus (process_resident_memory_bytes) sur une semaine représentative de votre charge
Disque pour une même rétention	Taille du répertoire de données, extrapolée à la rétention cible
Latence de requête P99	Temps de réponse des panneaux Grafana et des règles les plus lourdes
Séries actives	/api/v1/status/tsdb côté VictoriaMetrics, promtool tsdb analyze côté Prometheus
Coût d’infrastructure mensuel	Machines, disques et stockage objet des deux options, à périmètre égal

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

La première version de ce guide donnait ici des gains chiffrés (RAM, disque, latence, cardinalité, coût) tirés d’un unique scénario, sans mesure reproductible ni source. Ils ont été retirés : seuls vos propres chiffres, mesurés pendant la double écriture, peuvent justifier la bascule.

À titre d’illustration, une migration de quatre instances Prometheus fédérées vers un cluster VictoriaMetrics peut se planifier sur six semaines environ, dont quatre en double écriture.

Module 15 : scénarios illustratifs

Scénarios illustratifs, pas des cas réels

Les trois architectures ci-dessous sont des scénarios construits pour illustrer des choix de cardinalité, de rétention et d’alerte. Ce ne sont ni des cas clients ni des retours d’expérience ; tous les chiffres sont des hypothèses ou des estimations données à titre d’illustration.

Scénario 1 : chatbot de support RAG interne (entreprise de taille moyenne)

Contexte : assistant de support de niveau 1 fondé sur Mistral 7B hébergé en interne, indexation hebdomadaire d’environ 12 000 documents de wiki, environ 600 requêtes par jour.

Pile de métriques :

• VictoriaMetrics Single (1 VM, 4 vCPU, 8 Go de RAM, 250 Go de SSD) ;
• OTel Collector en sidecar de l’API LLM ;
• Grafana OSS, un tableau de bord, un utilisateur en lecture seule pour la direction ;
• vmalert avec quatre règles, sortie par webhook Microsoft Teams.

Cardinalité estimée (ordre de grandeur) :

Hypothèses : un seul modèle et un seul fournisseur, deux pipelines (questions de support et recherche documentaire), huit index, les labels définis en leçon 03.

Métrique	Cardinalité	Calcul
llm_request_duration_ms	24 séries	labels model, provider, pipeline_id (pas de label de statut) : 1 x 1 x 2 = 2 combinaisons ; par combinaison, 10 intervalles (9 bornes plus +Inf) et les séries _sum et _count, soit 12 ; 2 x 12 = 24
rag_retrieval_score_avg	8 séries	une par index_id, chaque index servant un seul pipeline avec une seule stratégie
llm_tokens_total	2 séries	1 modèle x 1 fournisseur x 2 types (input, output)
DCGM_FI_DEV_GPU_UTIL	2 séries	une par GPU, 2 GPU L4
Sous-total des métriques listées	36 séries	24 + 8 + 2 + 2

Avec les autres métriques de la leçon 03 et les exportateurs d’infrastructure (DCGM, système), le total reste de l’ordre de quelques centaines à quelques milliers de séries actives, très en deçà des limites du mode Single.

Points à retenir :

• Avec quelques centaines à quelques milliers de séries et quelques centaines de requêtes par jour, le mode Single suffit largement.
• Les règles d’enregistrement allègent les panneaux de coût, dont les fenêtres d’agrégation s’allongent au fil du mois.
• Dans ce scénario, l’alerte la plus pertinente est RAGIndexDrift, à surveiller après chaque réindexation.

Scénario 2 : plateforme LLM multi-tenant (SaaS B2B, une quarantaine de clients)

Contexte : plateforme d’agents conversationnels proposée à une quarantaine d’entreprises, mêlant OpenAI, Anthropic et un modèle Llama 3 70B interne sur 8 GPU H100.

Pile de métriques :

• VictoriaMetrics Cluster (3 vmstorage, 2 vminsert, 2 vmselect) ;
• un vmagent par région (EU-West, US-East) ;
• Grafana avec équipes et RBAC par tenant ;
• vmalert : 14 règles au total, pas 14 par client. Cinq d’entre elles (budget et qualité, les métriques qui portent tenant_id dans ce scénario) regroupent leur expression par tenant_id, comme la règle de budget de la leçon 5 : chacune est écrite une seule fois et produit une alerte distincte pour chaque tenant concerné.

Décision clé : les labels critiques

tenant_id n’est conservé que sur les métriques de coût et de qualité. Les métriques de latence et d’erreur sont agrégées par environnement (prod, staging) et par modèle. Dans ce scénario, la cardinalité des métriques de latence et d’erreur ne dépend plus du nombre de tenants : elle est divisée par un facteur qui peut aller jusqu’à ce nombre, une quarantaine ici.

Rétention	Métriques	Justification
3 ans	llm_cost_usd_total, llm_tokens_total	Facturation, audit comptable
12 mois	rag_retrieval_score_avg, hallucination_rate	Détection de dérive de qualité à long terme
3 mois	DCGM_*, vllm:*, latence brute	Planification de capacité à court terme
7 jours	*_debug, *_temp	Investigation d’incidents

Cette rétention par paliers exige plusieurs groupes de stockage ou le -retentionFilter Enterprise (voir 12.1).

Scénario 3 : pipeline d’évaluation par lots (équipe R&D)

Contexte : une équipe ML évalue chaque semaine 12 variantes de prompt sur 5 modèles candidats, 50 000 prompts par exécution, avec export des traces LLM vers un outil dédié de traçage et d’évaluation.

Architecture :

• VictoriaMetrics Single en mode push (vmagent reçoit les lots par remote write) ;
• pas de Grafana : tableaux de bord générés en Python (Plotly) après chaque exécution ;
• métadonnées d’exécution (run_id, prompt_template_id, model_version) portées par une métrique d’information (voir ci-dessous) ;
• rétention courte (90 jours), export quotidien vers un entrepôt de données pour l’analyse à long terme.

Anti-motif à éviter

Ne poussez jamais run_id directement comme label sur des métriques temps réel. Utilisez une métrique d’information llm_run_metadata{run_id, prompt_template_id} = 1 et joignez-la avec group_left() dans MetricsQL.

Module 16 : FAQ et dépannage

Q1. vmalert ne se déclenche pas, même avec une métrique évidente. Vérifiez trois choses. (1) La règle est-elle chargée ? Appelez http://vmalert:8880/-/reload, puis http://vmalert:8880/api/v1/rules. (2) La requête renvoie-t-elle des séries ? Testez-la dans vmui. (3) Le for: est-il trop long ? Une alerte avec for: 30m attend 30 minutes.

Q2. La cardinalité explose après l’ajout d’un nouveau service. Appelez http://victoriametrics:8428/api/v1/status/tsdb pour identifier les labels dominants. Souvent, un label trace_id ou request_id a fui. Correction rapide : une règle labeldrop dans vmagent (-remoteWrite.relabelConfig).

Q3. Mes règles d’enregistrement ne se mettent pas à jour.

Correction

La première version de ce guide affirmait que vmalert recharge les règles toutes les 60 secondes par défaut. C’est inexact : les règles sont rechargées sur réception de SIGHUP ou sur une requête GET vers /-/reload et le rechargement périodique n’a lieu que si -configCheckInterval est défini.

Forcez le rechargement avec curl http://vmalert:8880/-/reload (requête GET), puis cherchez les erreurs de chargement de règles dans les journaux.

Q4. Quelle différence entre vmagent et vmauth ? vmagent collecte les cibles et envoie les données par remote write (le côté collecte de Prometheus). vmauth est un proxy inverse avec authentification et routage par utilisateur ou par tenant (utile en multi-tenant et en air-gap).

Q5. Comment savoir quand passer en mode Cluster ? La documentation de l’éditeur recommande le mode Single sous environ un million de points ingérés par seconde et invite à réfléchir à deux fois avant de passer au Cluster. Surveillez donc d’abord le débit d’ingestion, puis la saturation de l’hôte malgré un dimensionnement vertical : RAM, CPU, latence des requêtes, disque. Les seuils d’alerte sur ces ressources sont à fixer selon votre contexte (à titre indicatif, une RAM durablement au-delà de 70 % ou des requêtes P99 de plusieurs secondes) ; ce ne sont pas des seuils de l’éditeur. Un besoin de haute disponibilité native ou de multi-tenant est l’autre raison de passer au Cluster.

Q6. Mes histogrammes calculent mal le P99. Vérifiez les intervalles : si le P99 réel dépasse le dernier intervalle fini, le résultat est plafonné à cet intervalle. Pour les LLM, prévoyez des intervalles jusqu’à 30 secondes : [50, 100, 250, 500, 1000, 2500, 5000, 10000, 30000] en millisecondes (ou [.05, .1, .25, .5, 1, 2.5, 5, 10, 30] si votre histogramme est en secondes).

Q7. Je perds des échantillons en remote write depuis Prometheus. Ajustez queue_config dans prometheus.yml : capacity, max_shards, max_samples_per_send. Surveillez prometheus_remote_storage_samples_dropped_total (ou prometheus_remote_storage_samples_failed_total, selon la version) ; s’il n’est pas nul, augmentez max_shards.

Q8. Comment exporter mes données vers une plateforme tierce ? VictoriaMetrics expose /api/v1/export (JSON, une ligne par série). Pour un export continu, configurez vmagent avec deux -remoteWrite.url, l’un vers VictoriaMetrics, l’autre vers le tiers. Attention au coût : chaque échantillon est aussi facturé par le tiers.

Q9. Des labels contenant des caractères non ASCII posent problème. VictoriaMetrics prend en charge l’UTF-8, mais certains outils affichent ou échappent mal ces valeurs. Préférez des valeurs ASCII pour les labels métier (par exemple tenant_id sous forme de slug).

Q10. Mon tableau de bord met 10 secondes à charger après l’ajout d’une variable. Chaque variable Grafana est une requête exécutée au rafraîchissement. Solutions : (1) ne rafraîchir la variable qu’au chargement du tableau de bord, (2) pré-agréger avec une règle d’enregistrement, (3) limiter les options (expression régulière, tri, limite).

Q11. Un GPU disparaît des métriques du DCGM exporter. Le DCGM exporter s’appuie sur NVML, qui peut perdre la liste des GPU si le pilote plante. Vérifiez nvidia-smi sur le nœud, puis redémarrez dcgm-exporter et nvidia-persistenced. Pour le détecter, alertez sur absent(DCGM_FI_DEV_GPU_UTIL{node='X'}) (adaptez le label à votre réétiquetage).

Q12. Comment versionner mes règles vmalert ?

Correction

La première version de ce guide recommandait promtool check rules. promtool ne comprend pas les extensions MetricsQL. Validez avec vmalert -rule=... -dryRun et écrivez des tests unitaires avec vmalert-tool unittest.

Stockez les fichiers YAML dans Git, déployez avec ArgoCD ou Flux ; vmalert les lit depuis un volume. Validez chaque demande de fusion avec les commandes ci-dessus.

Q13. rate() ou increase() pour les coûts ? rate(llm_cost_usd_total[5m]) renvoie des USD par seconde. increase(llm_cost_usd_total[1h]) renvoie l’augmentation totale sur une heure, en USD. Pour afficher un coût horaire, préférez increase ; pour une projection, préférez rate.

Q14. Mes alertes arrivent en double sur Slack. Vérifiez group_by, group_wait et group_interval dans Alertmanager. Pour les LLM, group_by: ['alertname', 'model'] regroupe les alertes par modèle et repeat_interval: 4h limite les répétitions.

Q15. Sauvegarde à un instant donné : quelle stratégie ? vmbackup vers un stockage compatible S3 (MinIO en air-gap), instantanés incrémentaux quotidiens, conservation des sauvegardes pendant 30 jours et test de restauration mensuel obligatoire. Les sauvegardes étant incrémentales, leur coût de stockage reste une fraction du volume des données vivantes.

Marquer comme lue