RousselTMLEARNING

Observabilité

Transformer avec VRL et tester ses pipelines Vector

Le langage VRL (Vector Remap Language) : analyse de logs (JSON, regex, syslog), gestion des erreurs, enrichissement, masquage, routage, conversion de logs en métriques, et tests unitaires de configuration.

1. Les bases de VRL #

Un langage sûr et rapide.

Syntaxe #

# Le point (.) est l'événement courant
.service = "boutique"
.status = to_int!(.status)                      # « ! » : erreur fatale si la conversion échoue

# Gestion explicite des erreurs
parsed, err = parse_json(.message)
if err == null {
  . = merge(., parsed)
  del(.message)
} else {
  .parse_error = err
}

# Conditions
if .status >= 500 { .severity = "error" } else if .status >= 400 { .severity = "warning" } else { .severity = "info" }
À savoir : VRL est vérifié à la compilation : une fonction qui peut échouer doit être traitée (! ou affectation de l'erreur). Une configuration qui démarre ne plantera pas sur un événement inattendu.

2. Recettes #

Les transformations courantes.

Analyser un log nginx #

parsed = parse_regex!(.message, r'^(?P<ip>\S+) \S+ \S+ \[(?P<ts>[^\]]+)\] "(?P<method>\S+) (?P<path>\S+) \S+" (?P<status>\d+) (?P<bytes>\d+)')
. = merge(., parsed)
.status = to_int!(.status)
.bytes = to_int!(.bytes)
.timestamp = parse_timestamp!(.ts, "%d/%b/%Y:%H:%M:%S %z")
del(.ts)

Masquer des données personnelles #

.message = redact(.message, filters: [r'\b[\w.+-]+@[\w-]+\.[\w.]+\b', "us_social_security_number"])
.client_ip = ip_cidr_contains!("10.0.0.0/8", .ip) ? "interne" : "externe"
del(.authorization)
Bonne Pratique : Masquez au plus près de la source : un e-mail qui atteint Elasticsearch ou Loki se retrouve dans les sauvegardes et les index pour toute la durée de rétention.

Router et produire des métriques #

transforms:
  aiguillage:
    type: route
    inputs: [parse]
    route:
      securite: .source == "auth"
      lent: .duration_ms > 1000
  requetes_metriques:
    type: log_to_metric
    inputs: [parse]
    metrics:
      - type: counter
        field: status
        name: http_requests_total
        tags: { status: "{{ status }}", method: "{{ method }}" }
sinks:
  prom:
    type: prometheus_exporter
    inputs: [requetes_metriques]
    address: 0.0.0.0:9598

3. Tests unitaires #

Une configuration testée comme du code.

vector test #

tests:
  - name: analyse nginx
    inputs:
      - insert_at: parse
        type: log
        log_fields:
          message: '10.0.0.1 - - [19/Oct/2026:10:00:00 +0200] "GET /panier HTTP/1.1" 502 120'
    outputs:
      - extract_from: parse
        conditions:
          - type: vrl
            source: |
              assert_eq!(.status, 502)
              assert_eq!(.path, "/panier")
vector test vector.yaml
Bonne Pratique : Ajoutez vector validate et vector test à la CI du dépôt de configuration : une regex cassée ne part plus en production.

Articles liés

Collecteurs de logs légers : Fluent Bit, Vector et les autres

Pourquoi un collecteur de logs, ce qui distingue les agents légers (Fluent Bit, Vector) des collecteurs histo…

Fluent Bit : pipeline, configuration et plugins essentiels

Les concepts de Fluent Bit (inputs, parsers, filters, tags et match, buffer, outputs), la configuration YAML,…

Fluent Bit sur Kubernetes : DaemonSet, multiline, tampon et supervision

Déployer Fluent Bit sur Kubernetes avec Helm, enrichir avec le filtre kubernetes, gérer les logs multilignes,…

Pour aller plus loin