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

QuelleType-SchlüsselBeschreibung
Datei-TailingfileVerfolgt Log-Dateien mit Glob-Mustern
systemd-JournaljournaldLiest aus journald mit Unit-Filtern
Docker-Containerdocker_logsSammelt vom Docker-Daemon-Socket
Kubernetes-Podskubernetes_logsNative k8s-Sammlung mit Pod-Metadaten
Syslog UDP/TCPsyslogEmpfängt Syslog-Nachrichten RFC 3164 / RFC 5424
HTTP-Serverhttp_serverStellt HTTP-Endpunkt für eingehende Logs bereit
KafkakafkaKonsumiert von einem oder mehreren Kafka-Topics
Host-Metrikenhost_metricsSammelt CPU, Speicher, Disk, Netzwerk
Interne Metrikeninternal_metricsVectors 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

TransformationZweck
remapVollständige VRL-Transformation — parsen, anreichern, filtern, mutieren
filterEreignisse verwerfen, die einer VRL-Bedingung nicht entsprechen
routeStream in benannte Bahnen nach Bedingung aufteilen
aggregateMehrere Ereignisse zu einem kombinieren (Batching, Zeitfenster)
dedupeDoppelte Ereignisse innerhalb eines Zeitfensters verwerfen
sampleEinen konfigurierbaren Prozentsatz der Ereignisse behalten
log_to_metricZähler/Gauges aus Log-Feldern ableiten

Ziele-Referenz

ZielType-SchlüsselAnwendungsfall
LokilokiGrafana-Log-Speicher
Elasticsearch / OpenSearchelasticsearchVolltextsuche und Analyse
ClickHouseclickhouseAnalytischer Log-Speicher für hohes Volumen
S3 / R2aws_s3Langzeitarchivierung
KafkakafkaWeiterveröffentlichung an nachgelagerte Konsumenten
Prometheus Exporterprometheus_exporterMetriken auf /metrics exponieren
Datadog Logsdatadog_logsAn Datadog-Ingestion senden
Splunk HECsplunk_hec_logsAn 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

MerkmalVectorFluentdFluent BitLogstashFilebeatPromtailGrafana Alloy
SpracheRustRubyCJVMGoGoGo
Speicher~20 MB~200 MB~1 MB~512 MB~50 MB~30 MB~60 MB
DurchsatzSehr hochMittelHochMittelHochMittelHoch
TransformationenVRLFluentd DSLLuaRuby/GrokMinimalStagesAlloy DSL
Metriken-PipelineJaPluginBegrenztPluginNeinNeinJa
Disk-PufferNativPluginJaNativNativNeinJa
Unit-TestsEingebautNeinNeinNeinNeinNeinBegrenzt
Kubernetes-nativJaJaJaNeinJaJaJa

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