Vector : pipeline d'observabilité haute performance

Vector collecte, transforme et route vos logs et métriques avec un seul binaire écrit en Rust. Ce guide s'adresse aux profils intermédiaires à avancés qui veulent remplacer un empilement d'agents (Fluentd, Logstash, Promtail) par un pipeline unifié et rapide. Vous installerez Vector 0.56.0 par paquet signé, écrirez vos premières transformations en VRL (Vector Remap Language), validerez un pipeline complet en local, puis verrez comment le déployer sur Kubernetes en mode agent et agrégateur.

Ce que vous allez apprendre

• Installer Vector par paquet .deb/.rpm vérifiable ou par conteneur épinglé.
• Structurer une configuration en sources, transforms et sinks.
• Transformer vos événements avec le langage VRL (parsing, filtrage, masquage).
• Router logs et métriques vers Loki, Prometheus ou Elasticsearch.
• Valider un pipeline avant de le mettre en production.
• Déployer Vector sur Kubernetes en agent (DaemonSet) et agrégateur.

Pourquoi Vector ?

Vector se positionne comme l'alternative moderne à Fluentd et Logstash. Là où ces outils reposent sur Ruby ou la JVM, Vector est un binaire Rust compilé, sans runtime à installer, avec une empreinte mémoire faible et un débit élevé. Il gère logs et métriques dans la même pipeline, ce qui évite de faire cohabiter deux agents distincts sur chaque machine.

Caractéristique	Vector	Fluentd	Logstash
Langage	Rust	Ruby	Java (JVM)
Empreinte mémoire	faible (~50 Mo)	moyenne (~100 Mo)	élevée (~500 Mo)
Logs + métriques	natif	plugins	natif
Transformation	VRL	filtres Ruby	Grok/Ruby
Runtime requis	aucun	Ruby	JVM

Glissez pour voir

VRL : Vector Remap Language

VRL est le langage de transformation de Vector. Il est compilé et type-safe : une erreur de type ou une fonction inexistante est détectée à la validation, avant le démarrage. Il remplace les expressions regex fragiles par une syntaxe explicite et prévisible.

Architecture : sources, transforms, sinks

Vector fonctionne en mode agent (installé sur chaque machine, il collecte localement) ou agrégateur (il centralise les flux de plusieurs agents avant de les router). Dans les deux cas, la configuration s'articule autour de trois étages que les données traversent de gauche à droite.

Étage	Rôle	Composants typiques
Sources	Point d'entrée des données	file, journald, kubernetes_logs, prometheus_scrape, syslog, http_server, demo_logs
Transforms	Traitement et enrichissement	remap (VRL), filter, dedupe, sample, reduce, aggregate
Sinks	Destination de sortie	loki, prometheus_remote_write, elasticsearch, kafka, aws_s3, console

Glissez pour voir

Chaque composant porte un nom unique. Les transforms et les sinks déclarent leurs inputs, c'est-à-dire les composants dont ils consomment les événements. C'est ce graphe de dépendances qui définit le trajet des données, pas l'ordre d'écriture dans le fichier.

Installation

Vector se distribue en paquets signés pour Debian/Ubuntu et RHEL, en conteneur et via un chart Helm. Épinglez toujours la version : ici 0.56.0, la dernière stable publiée le 3 juin 2026.

Debian / Ubuntu

Téléchargez le paquet .deb officiel épinglé, puis installez-le avec apt qui vérifie l'intégrité de l'archive :

VECTOR_VERSION=0.56.0
curl -fsSL -o /tmp/vector.deb \
  "https://github.com/vectordotdev/vector/releases/download/v${VECTOR_VERSION}/vector_${VECTOR_VERSION}-1_amd64.deb"
sudo apt install -y /tmp/vector.deb
vector --version

La sortie doit afficher vector 0.56.0. Vector installe aussi une unité systemd (vector.service) qui lit /etc/vector/vector.yaml.

RHEL / Rocky

Récupérez le paquet .rpm épinglé. dnf vérifie la signature du paquet avant de l'installer :

VECTOR_VERSION=0.56.0
curl -fsSL -o /tmp/vector.rpm \
  "https://github.com/vectordotdev/vector/releases/download/v${VECTOR_VERSION}/vector-${VECTOR_VERSION}-1.x86_64.rpm"
sudo dnf install -y /tmp/vector.rpm
vector --version

Vérifier l'empreinte avant d'installer

Vector publie un fichier vector-0.56.0-SHA256SUMS à côté de chaque release. Pour valider l'archive avant installation : téléchargez-le, puis sha256sum -c --ignore-missing vector-0.56.0-SHA256SUMS. La sortie doit indiquer OK en face du paquet.

Docker

L'image officielle est épinglée par tag de version. Le variant alpine est le plus léger :

docker run -d \
  --name vector \
  -v "$(pwd)/vector.yaml:/etc/vector/vector.yaml:ro" \
  -v /var/log:/var/log:ro \
  timberio/vector:0.56.0-alpine

Kubernetes (Helm)

Le chart officiel déploie Vector en agent ou en agrégateur. Épinglez la version du chart avec --version :

helm repo add vector https://helm.vector.dev
helm repo update

helm install vector vector/vector \
  --namespace vector \
  --create-namespace \
  --version 0.44.0 \
  -f values.yaml

Votre premier pipeline

Avant de brancher Vector sur une infrastructure réelle, testez-le hors ligne avec la source demo_logs, qui génère des événements synthétiques. Vous validez ainsi la mécanique source → transform → sink sans dépendre d'une machine à instrumenter.

1. Écrire la configuration dans un fichier vector.yaml. La source produit des lignes syslog, la transform ajoute deux champs, le sink les affiche en JSON :

   vector.yaml

   sources:
     demo:
       type: demo_logs
       format: syslog
       interval: 0.3
   
   transforms:
     enrich:
       type: remap
       inputs:
         - demo
       source: |
         .env = "lab"
         .processed_by = "vector"
   
   sinks:
     out:
       type: console
       inputs:
         - enrich
       encoding:
         codec: json

2. Valider la configuration avant de lancer quoi que ce soit. Vector compile le VRL et vérifie chaque composant :

   vector validate vector.yaml

   La sortie doit se terminer par Validated, avec une coche devant Component configuration et Health check "out". Une erreur de VRL est signalée ici, pas au démarrage.

3. Lancer le pipeline et observer les événements enrichis défiler en console :

   vector --config vector.yaml

   Chaque ligne affichée contient vos deux champs ajoutés :

   {"env":"lab","host":"localhost","message":"<34>1 2026-07-06T08:15:17.179Z testbench.com kernel_keith 3751 ID618 - Pretty pretty pretty good","processed_by":"vector","service":"vector","source_type":"demo_logs","timestamp":"2026-07-06T08:15:17.179Z"}

   La présence de "env":"lab" et "processed_by":"vector" confirme que la transform s'applique bien à chaque événement. Coupez avec Ctrl+C.

Le réflexe validate

Prenez l'habitude de lancer vector validate dans votre pipeline CI avant tout déploiement. Comme le VRL est compilé, la validation attrape les erreurs de syntaxe et de type sans avoir à démarrer l'agent en production.

Configuration réelle : des logs vers Loki

Une fois la mécanique comprise, voici une configuration proche de la production : deux sources (fichiers applicatifs et journald), une transform qui parse le JSON et enrichit, un sink Loki.

vector.yaml

sources:
  app_logs:
    type: file
    include:
      - /var/log/app/*.log

  journald:
    type: journald
    current_boot_only: true

transforms:
  parse_json:
    type: remap
    inputs:
      - app_logs
    source: |
      . = parse_json!(.message)
      .timestamp = now()

  enrich:
    type: remap
    inputs:
      - parse_json
      - journald
    source: |
      .labels.env = "production"
      .labels.host = get_hostname!()

sinks:
  loki:
    type: loki
    inputs:
      - enrich
    endpoint: http://loki:3100
    labels:
      env: "{{ labels.env }}"
      host: "{{ labels.host }}"
      app: "{{ .app_name }}"
    encoding:
      codec: json

Le point de vigilance côté Loki est la cardinalité des labels : n'exposez en label que des valeurs à faible variété (env, host, app). Mettre un identifiant de requête ou un timestamp en label ferait exploser le nombre de flux et dégraderait Loki.

VRL : transformer les événements

VRL est le cœur de Vector. C'est là que vous parsez, filtrez, enrichissez et masquez. Le langage est compilé : une fonction avec ! (comme parse_json!) échoue à la validation si son résultat n'est pas géré, ce qui vous force à traiter les cas d'erreur.

Syntaxe de base

# Assigner une valeur
.new_field = "value"

# Parser du JSON (le ! échoue à la compilation si non géré)
. = parse_json!(.message)

# Conditions
if .status >= 500 {
  .level = "error"
} else {
  .level = "info"
}

# Supprimer un champ
del(.password)

# Renommer en récupérant la valeur supprimée
.source = del(.src)

Fonctions courantes

Fonction	Description	Exemple
parse_json!	Parse une chaîne JSON	. = parse_json!(.message)
parse_syslog!	Parse une ligne syslog	. = parse_syslog!(.message)
to_string	Convertit en chaîne	.count = to_string(.count)
contains	Teste une sous-chaîne	if contains(.path, "/api")
replace	Remplace un motif	.msg = replace(.msg, "secret", "[REDACTED]")
get_hostname!	Nom d'hôte de la machine	.host = get_hostname!()
now	Timestamp courant	.timestamp = now()

Glissez pour voir

Masquer les données sensibles

Le masquage des données sensibles au plus près de la collecte évite qu'un secret parte dans votre système de logs. VRL le fait en quelques lignes :

# Masquer les emails avec une regex
.message = replace(.message, r'\b[\w.]+@[\w.]+\.\w+\b', "[EMAIL]")

# Masquer un en-tête d'autorisation s'il existe
if exists(.headers.authorization) {
  .headers.authorization = "[REDACTED]"
}

# Supprimer purement les champs interdits
del(.password)
del(.credit_card)

Sources et sinks courants

Au-delà des fichiers, Vector expose des sources adaptées à chaque contexte. En environnement conteneurisé, kubernetes_logs lit directement les logs des pods ; prometheus_scrape récupère des métriques ; http_server reçoit des événements poussés par une application.

sources:
  kubernetes_logs:
    type: kubernetes_logs
    auto_partial_merge: true
    exclude_paths_glob_patterns:
      - "**/kube-system/**"

  prometheus_metrics:
    type: prometheus_scrape
    endpoints:
      - http://localhost:9090/metrics
    scrape_interval_secs: 15

  http_logs:
    type: http_server
    address: 0.0.0.0:8080
    encoding: json

Côté sinks, la destination dépend de la nature des données. Les logs partent vers Loki ou Elasticsearch, les métriques vers Prometheus en remote_write.

sinks:
  loki:
    type: loki
    inputs:
      - enrich
    endpoint: http://loki:3100
    labels:
      app: "{{ .app }}"
      env: "{{ .env }}"
    encoding:
      codec: json

  prometheus:
    type: prometheus_remote_write
    inputs:
      - metrics
    endpoint: http://prometheus:9090/api/v1/write

  elasticsearch:
    type: elasticsearch
    inputs:
      - enrich
    endpoints:
      - http://elasticsearch:9200
    index: "logs-%Y-%m-%d"
    auth:
      strategy: basic
      user: elastic
      password: "${ES_PASSWORD}"

Déploiement Kubernetes

Sur Kubernetes, le motif classique combine deux rôles. Les agents tournent en DaemonSet (un par nœud) et collectent les logs des pods. Ils envoient tout à un agrégateur central, seul point qui parle aux backends. Cela concentre la logique de routage et limite le nombre de connexions vers Loki ou Elasticsearch.

values-agent.yaml

role: Agent

customConfig:
  sources:
    kubernetes_logs:
      type: kubernetes_logs

  transforms:
    parse_logs:
      type: remap
      inputs:
        - kubernetes_logs
      source: |
        .cluster = "production"

  sinks:
    to_aggregator:
      type: vector
      inputs:
        - parse_logs
      address: vector-aggregator:6000

L'agrégateur reçoit le flux des agents via la source vector et le route vers le backend final :

values-aggregator.yaml

role: Aggregator

customConfig:
  sources:
    vector_agents:
      type: vector
      address: 0.0.0.0:6000

  sinks:
    loki:
      type: loki
      inputs:
        - vector_agents
      endpoint: http://loki:3100
      labels:
        namespace: "{{ kubernetes.pod_namespace }}"
        pod: "{{ kubernetes.pod_name }}"

Superviser Vector lui-même

Un collecteur qui perd des événements en silence est pire que pas de collecteur. Vector expose ses propres métriques au format Prometheus via la source interne internal_metrics, à scraper comme n'importe quelle cible.

api:
  enabled: true
  address: 0.0.0.0:8686
  playground: true

sources:
  internal_metrics:
    type: internal_metrics

sinks:
  prometheus_exporter:
    type: prometheus_exporter
    inputs:
      - internal_metrics
    address: 0.0.0.0:9598

Métrique	Ce qu'elle indique
vector_events_in_total	Événements reçus par les sources
vector_events_out_total	Événements émis par les sinks
vector_buffer_events	Événements en attente dans les buffers
vector_component_errors_total	Erreurs par composant

Glissez pour voir

Surveillez surtout l'écart entre events_in et events_out et la hausse de component_errors_total : ce sont les signes qu'un sink est trop lent ou qu'une transform échoue.

Bonnes pratiques

Ces réflexes évitent les pièges les plus fréquents en production :

• Transformer en VRL, pas en regex ad hoc éparpillées : le code reste lisible et validable.
• Activer les buffers disque sur les sinks critiques pour absorber une panne temporaire du backend sans perdre d'événements.
• Limiter la cardinalité des labels envoyés à Loki : uniquement des valeurs à faible variété.
• Séparer agents et agrégateur dès que le volume grossit, pour centraliser le routage.
• Superviser Vector avec ses métriques internes, sinon les pertes passent inaperçues.

Dépannage

Symptôme	Cause probable	Solution
events dropped	Buffer plein, sink lent	Augmenter le buffer ou accélérer le sink
Mémoire élevée	Trop de transforms ou gros buffers	Simplifier la pipeline, borner les buffers
Erreur VRL au démarrage	Syntaxe ou type incorrect	vector validate et corriger avant déploiement
Aucune sortie	Sink mal configuré ou inputs erroné	Vérifier le graphe inputs et la connexion au sink

Glissez pour voir

Les trois commandes à connaître pour diagnostiquer :

# Valider la configuration (compile le VRL)
vector validate /etc/vector/vector.yaml

# Lancer en local pour observer le flux
vector --config /etc/vector/vector.yaml

# Activer les logs détaillés
VECTOR_LOG=debug vector --config /etc/vector/vector.yaml

À retenir

• Rust, un seul binaire : pas de runtime Ruby ou JVM à maintenir.
• VRL compilé : les erreurs de transformation sont attrapées à la validation, pas en production.
• Pipeline unifié : logs et métriques dans le même outil.
• Deux modes : agent léger sur chaque nœud, agrégateur pour centraliser.
• vector validate : le réflexe à intégrer en CI avant tout déploiement.
• Superviser Vector avec internal_metrics pour détecter les pertes.

FAQ : questions fréquentes

Qu'est-ce que Vector et à quoi sert-il ?

Vector est un pipeline d'observabilité open source écrit en Rust, développé par Datadog. Il collecte, transforme et route logs et métriques dans un seul binaire, sans runtime Ruby ni JVM. Il remplace un empilement d'agents comme Fluentd, Logstash ou Promtail.

Qu'est-ce que le langage VRL de Vector ?

VRL (Vector Remap Language) est le langage de transformation de Vector. Compilé et type-safe, il parse, filtre, enrichit et masque les événements. Ses erreurs sont détectées à la validation, avant le démarrage, ce qui évite les regex fragiles.

Comment installer Vector sans script pipe-to-shell ?

Téléchargez le paquet .deb ou .rpm officiel épinglé depuis les releases GitHub, puis installez-le avec apt ou dnf, qui vérifient l'intégrité. Un fichier SHA256SUMS permet de valider l'archive avant installation. Le conteneur timberio/vector doit être épinglé par tag de version.

Vector ou Fluentd, lequel choisir ?

Vector est écrit en Rust, sans runtime, avec une faible empreinte mémoire et gère nativement logs et métriques. Fluentd repose sur Ruby et bénéficie d'un très large écosystème de plugins. Vector convient aux pipelines modernes unifiés, Fluentd aux intégrations déjà couvertes par un plugin.

Comment valider une configuration Vector avant la mise en production ?

La commande vector validate compile le VRL et vérifie chaque composant sans démarrer l'agent. Elle détecte les erreurs de syntaxe et de type. Intégrée en CI, elle évite de déployer une configuration cassée. La sortie doit se terminer par Validated.

Prochaines étapes

Fluent Bit L'agent de collecte ultra-léger, complémentaire de Vector en périphérie.

Fluentd L'agrégateur historique de logs, à comparer avec le mode agrégateur de Vector.

Grafana Loki La destination naturelle de vos logs Vector, indexée par labels.

Prometheus Le backend de métriques ciblé par le sink prometheus_remote_write.

×

📖 Voir la documentation →