TechniquePratique

Installation et configuration pas à pas

Pour : ingénieurs et SREPrérequis : Avoir lu la leçon 1 du parcours et connaître Docker Compose.

4.1 Docker Compose : la pile complète

Une pile de développement ou de production légère : VictoriaMetrics Single, OTel Collector, vmagent, vmalert, Alertmanager et Grafana.

services:
  victoriametrics:
    image: victoriametrics/victoria-metrics:v1.153.0
    command:
      - '-storageDataPath=/var/lib/victoria-metrics-data'
      - '-retentionPeriod=12M'           # 12 mois (suffixe M majuscule)
      - '-httpListenAddr=:8428'
      - '-opentelemetry.usePrometheusNaming'   # noms Prometheus pour l'OTLP direct (voir 4.2)
    ports: ['8428:8428']
    volumes:
      - vm-data:/var/lib/victoria-metrics-data

  otel-collector:
    image: otel/opentelemetry-collector-contrib:0.161.0
    command: ['--config=/etc/otel-collector-config.yaml']
    volumes:
      - ./otel-collector-config.yaml:/etc/otel-collector-config.yaml
    ports:
      - '4317:4317'   # OTLP gRPC
      - '4318:4318'   # OTLP HTTP
    depends_on: [victoriametrics]

  vmagent:
    image: victoriametrics/vmagent:v1.153.0
    command:
      - '-promscrape.config=/etc/prometheus.yml'
      - '-remoteWrite.url=http://victoriametrics:8428/api/v1/write'
    volumes:
      - ./prometheus.yml:/etc/prometheus.yml

  vmalert:
    image: victoriametrics/vmalert:v1.153.0
    command:
      - '-datasource.url=http://victoriametrics:8428'
      - '-remoteWrite.url=http://victoriametrics:8428/api/v1/write'
      - '-notifier.url=http://alertmanager:9093'
      - '-rule=/etc/alerts/*.yml'
    volumes:
      - ./alerts:/etc/alerts
    ports: ['8880:8880']

  alertmanager:
    image: prom/alertmanager:v0.34.1
    volumes: ['./alertmanager.yml:/etc/alertmanager/alertmanager.yml']
    ports: ['9093:9093']

  grafana:
    image: grafana/grafana:12.4.12
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin   # développement uniquement, à changer
      - GF_PLUGINS_PREINSTALL=victoriametrics-metrics-datasource
    ports: ['3000:3000']

volumes:
  vm-data: {}

Remarques sur ce fichier :

Sans suffixe, -retentionPeriod s’exprime en mois (de 31 jours). La documentation liste les suffixes s, h, d, w, M (mois, en majuscule) et y, par exemple 90d, 12M ou 2y. La forme sans suffixe est acceptée pour des raisons historiques mais le code source de VictoriaMetrics la déclare dépréciée : préférez M. N’écrivez pas m en minuscule pour des mois : il désigne les minutes et VictoriaMetrics le refuse pour cette option. La valeur par défaut est 1M (un mois) et le minimum 1d (ou 24h).
L’option -remoteWrite.url de vmalert sert à stocker dans VictoriaMetrics les résultats des règles d’enregistrement et l’état des alertes.
Le port 8880 de vmalert est publié pour pouvoir utiliser son interface web pendant les labs.
-opentelemetry.usePrometheusNaming ne sert que si des métriques arrivent en OTLP directement sur VictoriaMetrics (voir 4.2). Sans cette option, les noms OTLP sont stockés tels quels.
GF_PLUGINS_PREINSTALL remplace GF_INSTALL_PLUGINS, déprécié depuis Grafana 12.1.
Le mot de passe administrateur Grafana admin n’est acceptable que sur un poste de travail.

4.2 Configuration de l’OTel Collector pour les métriques LLM

receivers:
  otlp:
    protocols:
      grpc: { endpoint: 0.0.0.0:4317 }
      http: { endpoint: 0.0.0.0:4318 }
  prometheus:
    config:
      scrape_configs:
        - job_name: vllm
          scrape_interval: 15s
          static_configs: [{ targets: ['vllm-service:8000'] }]

processors:
  batch: { timeout: 5s, send_batch_size: 512 }
  k8sattributes:
    extract:
      metadata: [k8s.pod.name, k8s.namespace.name, k8s.deployment.name]

connectors:
  spanmetrics:
    histogram:
      explicit:
        buckets: [50ms, 100ms, 200ms, 500ms, 1s, 2s, 5s, 10s]
    dimensions:
      - name: gen_ai.request.model
      - name: gen_ai.provider.name
      - name: rag.index.id
      - name: rag.pipeline.id
      - name: rag.tenant.id

exporters:
  prometheusremotewrite:
    endpoint: http://victoriametrics:8428/api/v1/write
    timeout: 30s
    retry_on_failure: { enabled: true, initial_interval: 5s }

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [k8sattributes, batch]
      exporters: [spanmetrics]          # ajoutez ici l'exportateur de votre backend de traces
    metrics:
      receivers: [otlp, prometheus, spanmetrics]
      processors: [k8sattributes, batch]
      exporters: [prometheusremotewrite]

Points à vérifier :

k8sattributes et RBAC. Dans un cluster Kubernetes, le processeur k8sattributes interroge l’API server. Son compte de service doit disposer d’un ClusterRole autorisant get, list et watch sur les pods et les namespaces, ainsi que sur les replicasets pour résoudre k8s.deployment.name. Hors Kubernetes (Docker Compose sur un poste), retirez-le des pipelines.
Backend de traces. Le pipeline de traces ci-dessus n’alimente que spanmetrics. En pratique, ajoutez aussi un exportateur vers votre backend de traces (Jaeger, Tempo ou un autre point OTLP).
Noms des métriques dérivées. Les noms produits par le connecteur (compteur d’appels, histogramme de durée) dépendent de la version du Collector et de l’option namespace du connecteur. Vérifiez-les dans vmui avant d’écrire vos tableaux de bord.
Exportateur alternatif. Au lieu de prometheusremotewrite, vous pouvez envoyer OTLP directement à VictoriaMetrics avec l’exportateur otlphttp pointant vers http://victoriametrics:8428/opentelemetry. Dans ce cas, lancez VictoriaMetrics (ou le vmagent qui reçoit l’OTLP) avec -opentelemetry.usePrometheusNaming, comme dans le fichier Compose ci-dessus. Sans cette option, VictoriaMetrics stocke les points OTLP sans transformation : pas de suffixe _total ni d’unité, des points dans les noms et les labels et toutes les requêtes *_total et *_bucket de ce guide cessent de fonctionner (documentation OpenTelemetry de VictoriaMetrics).
Dimensions. gen_ai.request.model et gen_ai.provider.name viennent des conventions sémantiques GenAI d’OpenTelemetry, déplacées vers le dépôt semantic-conventions-genai depuis la v1.42 (juin 2026) ; gen_ai.provider.name remplace l’ancien gen_ai.system. Les attributs rag.* sont des conventions applicatives propres à ce guide.

4.3 vmagent : collecte DCGM et points LLM

# prometheus.yml (utilisé par vmagent)
global:
  scrape_interval: 15s
  external_labels:
    cluster: 'prod-llm'
    environment: 'production'

scrape_configs:
  # DCGM exporter : métriques GPU NVIDIA
  - job_name: 'dcgm-exporter'
    scrape_interval: 5s
    kubernetes_sd_configs: [{ role: pod }]
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_label_app]
        regex: dcgm-exporter
        action: keep

  # Serveurs d'inférence vLLM
  - job_name: 'vllm'
    static_configs:
      - targets: ['vllm-llama:8000', 'vllm-mistral:8001']

  # Proxy LiteLLM
  - job_name: 'litellm'
    static_configs: [{ targets: ['litellm-proxy:4000'] }]

Le bloc kubernetes_sd_configs ne fonctionne que si vmagent tourne dans Kubernetes avec les droits nécessaires. Sous Docker Compose, remplacez-le par une entrée static_configs pointant vers le DCGM exporter (port 9400 par défaut).

Révisé le 2 octobre 2026 : images épinglées sur des versions courantes, GF_PLUGINS_PREINSTALL à la place de GF_INSTALL_PLUGINS, gen_ai.provider.name à la place de gen_ai.system, option -opentelemetry.usePrometheusNaming pour l’ingestion OTLP directe, suffixes de rétention alignés sur la documentation.

Marquer comme lue