TL;DR — Kurzzusammenfassung

Vector ist eine Rust-basierte Observability-Pipeline von Datadog. Sammeln Sie Logs und Metriken aus beliebigen Quellen und leiten Sie diese mit VRL weiter.

Vector ist eine hochleistungsfähige Observability-Datenpipeline, geschrieben in Rust und von Datadog gepflegt. Sie sammelt Logs, Metriken und Traces aus beliebigen Quellen, transformiert diese mit VRL (Vector Remap Language) und leitet sie an beliebige Ziele weiter — alles in einer einzigen statisch verlinkten Binärdatei, die nur einen Bruchteil des Speichers verbraucht, den Logstash oder Fluentd benötigen. Dieser Leitfaden behandelt den vollständigen Vector-Stack: Architektur, Installation, Konfiguration, VRL-Transformationen, Deployment-Muster, Zustellungsgarantien und eine Produktionspipeline, die Nginx-Logs sammelt und an Loki und ClickHouse weiterleitet.

Voraussetzungen

  • Linux-Server (Ubuntu 22.04+, Debian 12+, RHEL 9+) oder macOS für lokale Tests.
  • Docker oder Kubernetes-Cluster (optional, für containerbasierte Deployments).
  • Grundkenntnisse der YAML-Konfiguration.
  • Laufende und erreichbare Ziele (Loki, Elasticsearch, ClickHouse, S3 usw.).

Vector-Architektur

Vector verarbeitet Observability-Daten als gerichteten azyklischen Graphen (DAG) von Quellen → Transformationen → Ziele.

  • Quellen — nehmen Daten aus Dateien, Journals, Sockets, HTTP, Kafka, Cloud-APIs auf.
  • Transformationen — parsen, reichern an, filtern, routen, aggregieren oder deduplizieren Ereignisse.
  • Ziele — liefern Daten an Speicher-, Such-, Metriken- und Alarmsysteme.

Vector erreicht seinen Durchsatz durch mehrere Rust-native Designentscheidungen:

  • Zero-Copy-Parsing — Log-Zeilen werden an Ort und Stelle geparst ohne zusätzliche Heap-Allokationen.
  • Adaptive Parallelität — Vector passt automatisch die Anzahl der Anfragen an jedes Ziel per AIMD-Algorithmus an, ohne manuelle Konfiguration.
  • End-to-End-Bestätigungen — Eine Log-Zeile wird erst gelöscht, wenn alle konfigurierten Ziele den Empfang bestätigen.
  • Disk-Puffer — Ereignisse werden auf Disk ausgelagert, wenn die Speicher-Queue voll ist, und überstehen Neustarts.

Installation

apt (Debian/Ubuntu)

curl -1sLf 'https://repositories.timber.io/public/vector/cfg/setup/bash.deb.sh' \
  | sudo -E bash
sudo apt install -y vector
sudo systemctl enable --now vector

yum/dnf (RHEL/Fedora/Rocky)

curl -1sLf 'https://repositories.timber.io/public/vector/cfg/setup/bash.rpm.sh' \
  | sudo -E bash
sudo yum install -y vector
sudo systemctl enable --now vector

Docker

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

Kubernetes DaemonSet via Helm

helm repo add vector https://helm.vector.dev
helm repo update
helm install vector vector/vector \
  --namespace vector \
  --create-namespace \
  --values vector-values.yaml

Homebrew (macOS)

brew tap vectordotdev/brew
brew install vector

Konfiguration

Vector liest vector.yaml (oder vector.toml, vector.json) standardmäßig aus /etc/vector/:

data_dir: /var/lib/vector

sources:
  meine_quelle:
    type: file
    include: ["/var/log/nginx/*.log"]

transforms:
  meine_transformation:
    type: remap
    inputs: ["meine_quelle"]
    source: |
      . = parse_json!(string!(.message))

sinks:
  mein_ziel:
    type: loki
    inputs: ["meine_transformation"]
    endpoint: "http://loki:3100"
    labels:
      job: nginx

Jede Komponente hat einen eindeutigen String-Schlüssel. inputs verbindet die Komponenten miteinander.

Quellen-Referenz

Quelle Type-Schlüssel Beschreibung
Datei-Tailing file Verfolgt Log-Dateien mit Glob-Mustern
systemd-Journal journald Liest aus journald mit Unit-Filtern
Docker-Container docker_logs Sammelt vom Docker-Daemon-Socket
Kubernetes-Pods kubernetes_logs Native k8s-Sammlung mit Pod-Metadaten
Syslog UDP/TCP syslog Empfängt Syslog-Nachrichten RFC 3164 / RFC 5424
HTTP-Server http_server Stellt HTTP-Endpunkt für eingehende Logs bereit
Kafka kafka Konsumiert von einem oder mehreren Kafka-Topics
Host-Metriken host_metrics Sammelt CPU, Speicher, Disk, Netzwerk
Interne Metriken internal_metrics Vectors eigene Durchsatz- und Fehlerzähler

VRL — Vector Remap Language

VRL ist die Transformationssprache im Kern von Vector. Es ist eine statisch typisierte Ausdruckssprache, die auf Geschwindigkeit, Sicherheit und Lesbarkeit ausgelegt ist. Jedes VRL-Programm empfängt ein Ereignis als . (Punkt) und muss das mutierte Ereignis zurückgeben.

JSON parsen

transforms:
  json_parsen:
    type: remap
    inputs: ["nginx_access"]
    source: |
      . = parse_json!(string!(.message))

Das Suffix ! bei einem Funktionsaufruf bedeutet “Ereignis abbrechen, wenn dies fehlschlägt.” Fehlgeschlagene Ereignisse werden zur dropped-Ausgabe der Komponente geleitet.

Syslog parsen

transforms:
  syslog_parsen:
    type: remap
    inputs: ["syslog_eingang"]
    source: |
      parsed = parse_syslog!(.message)
      .severity = parsed.severity
      .facility = parsed.facility
      .appname = parsed.appname
      .message = parsed.message

Bedingte Logik und PII-Schwärzung

source: |
  if .status_code >= 500 {
    .severity = "error"
  } else if .status_code >= 400 {
    .severity = "warn"
  } else {
    .severity = "info"
  }

  .message = redact(.message, filters: [
    { type: "pattern", pattern: r'\b(?:\d[ -]*?){13,16}\b' }
  ])

  del(.interner_trace_id)

Regex-Parsing für Nginx

transforms:
  nginx_parsen:
    type: remap
    inputs: ["nginx_access"]
    source: |
      parsed, err = parse_regex(.message, r'^(?P<remote_addr>\S+) - (?P<user>\S+) \[(?P<time>[^\]]+)\] "(?P<method>\S+) (?P<path>\S+) (?P<protocol>[^"]+)" (?P<status>\d+) (?P<bytes>\d+)')
      if err == null {
        . = merge(., parsed)
        .status = to_int!(.status)
        .bytes = to_int!(.bytes)
        del(.message)
      }

Transformationen-Referenz

Transformation Zweck
remap Vollständige VRL-Transformation — parsen, anreichern, filtern, mutieren
filter Ereignisse verwerfen, die einer VRL-Bedingung nicht entsprechen
route Stream in benannte Bahnen nach Bedingung aufteilen
aggregate Mehrere Ereignisse zu einem kombinieren (Batching, Zeitfenster)
dedupe Doppelte Ereignisse innerhalb eines Zeitfensters verwerfen
sample Einen konfigurierbaren Prozentsatz der Ereignisse behalten
log_to_metric Zähler/Gauges aus Log-Feldern ableiten

Ziele-Referenz

Ziel Type-Schlüssel Anwendungsfall
Loki loki Grafana-Log-Speicher
Elasticsearch / OpenSearch elasticsearch Volltextsuche und Analyse
ClickHouse clickhouse Analytischer Log-Speicher für hohes Volumen
S3 / R2 aws_s3 Langzeitarchivierung
Kafka kafka Weiterveröffentlichung an nachgelagerte Konsumenten
Prometheus Exporter prometheus_exporter Metriken auf /metrics exponieren
Datadog Logs datadog_logs An Datadog-Ingestion senden
Splunk HEC splunk_hec_logs An Splunk HTTP Event Collector senden

Puffer und Zustellungsgarantien

Für die Produktion Disk-Puffer und Bestätigungen aktivieren:

sinks:
  clickhouse_ziel:
    type: clickhouse
    inputs: ["nginx_parsen"]
    endpoint: "http://clickhouse:8123"
    database: logs
    table: nginx_access
    buffer:
      type: disk
      max_size: 268435456
      when_full: block
    acknowledgements:
      enabled: true

Mit acknowledgements.enabled: true wartet Vector auf die Bestätigung des Ziels, bevor die Leseposition in der Quelle vorgerückt wird, was dauerhafte At-least-once-Zustellung garantiert.

Unit-Tests für Transformationen

tests:
  - name: "nginx_parsen verarbeitet 200-Anfrage korrekt"
    inputs:
      - insert_at: nginx_parsen
        type: log
        log_fields:
          message: '127.0.0.1 - - [23/Mar/2026:10:00:00 +0000] "GET /api/health HTTP/1.1" 200 42'
    outputs:
      - extract_from: nginx_parsen
        conditions:
          - type: vrl
            source: |
              assert_eq!(.status, 200)
              assert_eq!(.method, "GET")
vector test /etc/vector/vector.yaml

Vector überwachen

# Echtzeit-Durchsatz pro Komponente
vector top

# Konfiguration ohne Start validieren
vector validate /etc/vector/vector.yaml

Vectors eigene Metriken an Prometheus exponieren:

sources:
  interne_metriken:
    type: internal_metrics
    scrape_interval_secs: 15

sinks:
  prometheus:
    type: prometheus_exporter
    inputs: ["interne_metriken"]
    address: "0.0.0.0:9598"

Vector vs. Alternativen

Merkmal Vector Fluentd Fluent Bit Logstash Filebeat Promtail Grafana Alloy
Sprache Rust Ruby C JVM Go Go Go
Speicher ~20 MB ~200 MB ~1 MB ~512 MB ~50 MB ~30 MB ~60 MB
Durchsatz Sehr hoch Mittel Hoch Mittel Hoch Mittel Hoch
Transformationen VRL Fluentd DSL Lua Ruby/Grok Minimal Stages Alloy DSL
Metriken-Pipeline Ja Plugin Begrenzt Plugin Nein Nein Ja
Disk-Puffer Nativ Plugin Ja Nativ Nativ Nein Ja
Unit-Tests Eingebaut Nein Nein Nein Nein Nein Begrenzt
Kubernetes-nativ Ja Ja Ja Nein Ja Ja Ja

Grenzfälle und häufige Fallstricke

  • VRL ! vs ? — parse_json! bricht das Ereignis bei Fehler ab; parse_json? gibt null zurück. Bewusst wählen.
  • Datei-Positions-Tracking — Vector speichert Offsets in data_dir. Das Löschen dieses Verzeichnisses verursacht eine Re-Ingestion vorhandener Dateien.
  • Loki-Label-Kardinalität — Vermeiden Sie die Verwendung von Feldern mit hoher Kardinalität (Benutzer-IDs) als Loki-Labels.
  • ClickHouse-Datentypen — Definieren Sie das Tabellenschema vor und setzen Sie skip_unknown_fields: true, um Ingestions-Fehler zu vermeiden.

Zusammenfassung

  • Vector ist eine Rust-basierte Observability-Pipeline mit einem DAG-Modell aus Quellen → Transformationen → Zielen.
  • VRL übernimmt das gesamte Parsen, Anreichern, Filtern und Routen in einer sicheren, testbaren Sprache.
  • Deployment-Modi: Agent (pro Host), Aggregator (zentralisiert), Sidecar (Kubernetes-Pod).
  • Disk-Puffer + Bestätigungen bieten dauerhafte At-least-once-Zustellung ohne Datenverlust bei Abstürzen.
  • Unit-Tests in vector.yaml validieren Transformationen vor dem Produktions-Deployment.
  • Vector verwaltet Logs und Metriken in einer einzigen Pipeline und ersetzt gleichzeitig Fluentd, Logstash, Filebeat und Promtail.

Verwandte Artikel