Streaming von Logs und Dateien in Echtzeit verarbeiten

1. Warum Streaming von Logs in Echtzeit entscheidend ist

Das Streaming von Logs in Echtzeit ist der Unterschied zwischen reaktiver und proaktiver Systemüberwachung. Wenn ein Webserver plötzlich hunderte 500-Fehler pro Minute produziert, entscheidet die Reaktionszeit darüber, ob ein Incident sich auf Minuten oder Stunden erstreckt. Klassische Monitoring-Werkzeuge mit Pull-Intervallen von 30 Sekunden oder länger versagen hier – die Lösung liegt direkt in Bash, mit Werkzeugen, die auf jedem Linux-System verfügbar sind.

Der Kernmechanismus beim Streaming von Logs ist denkbar einfach: Ein Prozess liest kontinuierlich neue Zeilen aus einer Datei oder einem Dateideskriptor und leitet sie durch eine Verarbeitungspipeline. Was komplex wird, sind die Randfälle: Log-Rotation, die den Datei-Inode ändert; mehrere parallele Log-Quellen, die aggregiert werden müssen; Pufferung in Pipes, die Latenzen einführt; und Ressourcenverschwendung durch busy-waiting. Diese Abschnitte decken alle diese Aspekte systematisch ab.

Bash ist für das Streaming von Logs in Echtzeit nicht nur ausreichend, sondern oft die pragmatischste Wahl: keine zusätzlichen Abhängigkeiten, keine laufenden Dienste, direkter Zugriff auf Systemressourcen. Wer die Werkzeuge beherrscht, kann in wenigen Zeilen ein Alerting-System aufbauen, das in einer CI-Pipeline oder auf einem dedizierten Monitoring-Host gleichermaßen funktioniert.

2. tail -f und tail --follow: Grundlagen und Fallstricke

tail -f ist das bekannteste Werkzeug für das Streaming von Logs. Es öffnet eine Datei und gibt neue Zeilen aus, sobald sie geschrieben werden. Der Unterschied zwischen -f (follow by file descriptor) und --follow=name (follow by filename) ist entscheidend bei Log-Rotation: -f folgt dem ursprünglichen Dateideskriptor, auch wenn die Datei umbenannt wird – nach einer Rotation zeigt tail -f dann auf die alte, geleerte Datei und erhält keine neuen Einträge mehr. --follow=name löst den Dateinamen bei jeder Prüfung neu auf und folgt der neuen Datei nach einer Rotation.

Ein weiterer Fallstrick beim Streaming von Logs mit tail: Die Option -F (Großbuchstabe) ist ein Alias für --follow=name --retry und versucht die Datei automatisch neu zu öffnen, wenn sie nicht mehr existiert oder eine Berechtigungsverweigerung auftritt. In Produktionsumgebungen mit regelmäßiger Log-Rotation ist tail -F die robustere Wahl. Kombiniert mit --pid=PID beendet sich tail automatisch, wenn der überwachte Prozess stirbt – das verhindert verwaiste Tail-Prozesse in Überwachungsskripten.

#!/usr/bin/env bash
# log-stream.sh — Real-time log streaming with automatic rotation handling
set -euo pipefail

LOG_FILE="${1:-/var/log/nginx/error.log}"
ALERT_PATTERN="${2:-ERROR|CRITICAL|emerg}"
ALERT_CMD="${3:-/usr/local/bin/send-alert.sh}"

# -F: follow by name + retry — survives log rotation
# --line-buffered: flush each line immediately, no blocking buffering
tail -F --line-buffered "$LOG_FILE" | \
  grep --line-buffered -E "$ALERT_PATTERN" | \
  while IFS= read -r line; do
    ts="$(date '+%Y-%m-%dT%H:%M:%S')"
    echo "[$ts] ALERT: $line" >&2
    # Fire alert command asynchronously — do not block the stream
    "$ALERT_CMD" "$line" &
  done

# Cleanup dangling background alert processes on exit
trap 'wait' EXIT

Das Flag --line-buffered ist beim Streaming von Logs durch Pipes unverzichtbar. Ohne es puffert grep seine Ausgabe in 4-KB-Blöcken, was zu Latenzspitzen im Echtzeit-Alert führt. Dasselbe gilt für awk und sed in Pipelines: Immer --line-buffered bei grep und stdbuf -oL bei anderen Werkzeugen einsetzen, um Pufferung zu erzwingen. Die Echtzeit im Streaming von Logs ist nur so gut wie die schwächste Pufferungseinstellung in der Kette.

3. while read: Zeilen aus Streams sicher verarbeiten

Das Muster while IFS= read -r line; do ... done ist das fundamentale Bash-Konstrukt für das Streaming von Logs zeilenweise. IFS= (leeres IFS) verhindert, dass führende und nachfolgende Leerzeichen abgeschnitten werden. -r verhindert, dass Backslash-Sequenzen interpretiert werden. Ohne diese beiden Optionen gehen Einrückungen, IP-Adressen mit bestimmten Mustern oder Pfade mit Backslash korrumpiert aus der Verarbeitung hervor.

Ein häufiges Problem beim Streaming von Logs mit while read ist der Verlust des Exit-Codes aus einer Pipe: In cmd | while read läuft die while-Schleife in einer Subshell. Variablen, die in der Schleife gesetzt werden, sind nach der Pipe unsichtbar. Das Bash-Muster dafür: Process Substitution statt Pipe: while IFS= read -r line; do ...; done < <(cmd) – die Schleife läuft im aktuellen Shell-Kontext, Variablen sind nach der Schleife sichtbar, und der Exit-Code von cmd kann mit ${PIPESTATUS[0]} ausgewertet werden.

#!/usr/bin/env bash
# stream-counter.sh — Count error classes from a log stream in real-time
set -euo pipefail

declare -A error_counts
declare -i total=0
declare -i last_report=0
REPORT_INTERVAL=60  # seconds

report_stats() {
  echo "--- Stats at $(date '+%H:%M:%S') ---"
  for key in "${!error_counts[@]}"; do
    printf "  %-20s %d\n" "$key" "${error_counts[$key]}"
  done
  echo "  Total: $total"
}

trap report_stats EXIT

# Process substitution keeps the while loop in the current shell context
# — variables are accessible after the loop ends
while IFS= read -r line; do
  total+=1

  # Extract severity level from structured log (e.g. "[ERROR]", "[WARN]")
  if [[ "$line" =~ \[([A-Z]+)\] ]]; then
    level="${BASH_REMATCH[1]}"
    error_counts["$level"]=$(( ${error_counts["$level"]:-0} + 1 ))
  fi

  # Periodic reporting without blocking the stream
  now=$(date +%s)
  if (( now - last_report >= REPORT_INTERVAL )); then
    report_stats
    last_report=$now
  fi
done < <(tail -F --line-buffered /var/log/app/application.log)

4. inotifywait: Dateisystem-Events als Stream-Quelle

inotifywait aus dem Paket inotify-tools bietet eine Alternative zu tail -f für das Streaming von Logs: statt den Dateiinhalt zu lesen, überwacht es Kernel-Events auf Datei- und Verzeichnisebene. Das ermöglicht, auf das Erstellen neuer Dateien in einem Verzeichnis zu reagieren, auf Berechtigungsänderungen zu alertieren oder einen vollständigen Verarbeitungsworkflow zu starten, sobald eine Datei vollständig geschrieben wurde. Polling entfällt vollständig – inotifywait blockiert, bis ein Kernel-Event eintrifft.

Der Modus --monitor bei inotifywait ist der entscheidende für dauerhaftes Streaming von Logs: ohne --monitor beendet sich inotifywait nach dem ersten Event. Mit --monitor läuft es dauerhaft und gibt jeden Event als eine Zeile aus. Das Format --format '%w%f %e %T' liefert Pfad, Event-Typ und Zeitstempel in strukturierter Form, die direkt mit while read verarbeitet werden kann. Für das Streaming von Logs in Log-Verzeichnissen empfiehlt sich der Event-Typ CLOSE_WRITE, der anzeigt, dass eine Datei vollständig geschrieben wurde, statt MODIFY, das bei jedem Schreibvorgang feuert.

#!/usr/bin/env bash
# dir-watcher.sh — Process new log files as soon as they are fully written
set -euo pipefail

WATCH_DIR="${1:-/var/log/uploads}"
PROCESS_CMD="${2:-/usr/local/bin/process-log.sh}"

if ! command -v inotifywait &>/dev/null; then
  echo "[ERROR] inotify-tools not installed: apt install inotify-tools" >&2
  exit 1
fi

echo "[INFO] Watching $WATCH_DIR for new complete files..."

# --monitor: run continuously (not one-shot)
# CLOSE_WRITE: file was written and closed — safe to process
# --format: structured output for reliable parsing
while IFS=' ' read -r filepath event _ts; do
  [[ -f "$filepath" ]] || continue
  echo "[INFO] Processing $filepath (event: $event)"
  # Run processing in background — do not block the event loop
  "$PROCESS_CMD" "$filepath" &
done < <(
  inotifywait --monitor --quiet \
    --event CLOSE_WRITE \
    --format '%w%f %e %T' \
    --timefmt '%Y-%m-%dT%H:%M:%S' \
    "$WATCH_DIR"
)

wait  # drain background jobs on exit

5. Echtzeit-Alerting: Muster erkennen und sofort reagieren

Echtzeit-Alerting beim Streaming von Logs bedeutet mehr als einfaches Matching mit grep. Produktionsrelevante Alarme erfordern Schwellenwerte (mehr als N Fehler in M Sekunden), Deduplizierung (nicht bei jedem einzelnen Fehler alarmieren, wenn hunderte gleichzeitig auftreten) und Cooldown-Perioden (kein zweiter Alert, solange der erste noch aktiv ist). Bash ist mit assoziativen Arrays und Arithmetik vollständig in der Lage, diese Logik zu implementieren – ohne externe Abhängigkeiten.

Das Kernmuster für Threshold-Alerting beim Streaming von Logs: Ein gleitender Zähler zählt Events in einem Zeitfenster. Sobald der Zähler einen Schwellenwert überschreitet, löst er den Alert aus und setzt einen Cooldown-Timer. Neue Events inkrementieren den Zähler weiter, lösen aber keinen zweiten Alert aus, bis der Cooldown abgelaufen ist. Der Zähler wird zurückgesetzt, wenn das Zeitfenster ohne neuen Event abläuft. Diese Logik ist in 20 Zeilen Bash implementierbar und behandelt die häufigsten Alerting-Anforderungen in Produktionssystemen ohne Overhead.

6. Log-Aggregation: mehrere Quellen zusammenführen

Beim Streaming von Logs aus mehreren Quellen gleichzeitig ist die Aggregation die zentrale Herausforderung. Das einfachste Muster: mehrere tail -F-Prozesse in einer gemeinsamen Pipe zusammenführen. tail -F /var/log/app1.log /var/log/app2.log folgt mehreren Dateien gleichzeitig und prefixiert jede Zeile mit dem Dateinamen. Das funktioniert für eine handvoll Dateien, skaliert aber nicht auf Dutzende von Quellen, weil tail für jede Datei einen File-Descriptor offen hält und Limits greifen können.

Für größere Log-Aggregation beim Streaming von Logs ist das Named-Pipe-Muster die sauberere Lösung: Jede Log-Quelle schreibt über eine eigene Subshell in eine gemeinsame Named Pipe (FIFO). Ein einziger Leseprozess liest aus der FIFO und verarbeitet den aggregierten Stream. Named Pipes lösen das Problem, dass mehrere Schreibprozesse in eine reguläre Datei schreiben und sich gegenseitig überschreiben – Schreiboperationen in eine FIFO sind atomar bis zur Puffergröße (PIPE_BUF, typisch 4096 Bytes), was für einzelne Log-Zeilen ausreicht.

#!/usr/bin/env bash
# aggregate-logs.sh — Merge multiple log streams into one annotated stream
set -euo pipefail

FIFO="/tmp/log-aggregator-$$"
declare -a TAIL_PIDS=()

cleanup() {
  for pid in "${TAIL_PIDS[@]:-}"; do
    kill "$pid" 2>/dev/null || true
  done
  rm -f "$FIFO"
}
trap cleanup EXIT

mkfifo "$FIFO"

# Start one tail per source, each prefixing its lines with the source name
for logfile in /var/log/nginx/error.log /var/log/app/application.log /var/log/mysql/error.log; do
  source_name="$(basename "${logfile%.log}")"
  # Each tail writes to the shared FIFO
  tail -F --line-buffered "$logfile" \
    | sed --unbuffered "s/^/[$source_name] /" \
    > "$FIFO" &
  TAIL_PIDS+=($!)
done

# Single reader processes the merged stream
while IFS= read -r line; do
  ts="$(date '+%Y-%m-%dT%H:%M:%S')"
  echo "$ts $line"
  # Route to alert if CRITICAL found
  if [[ "$line" =~ CRITICAL|emerg|panic ]]; then
    logger -t log-aggregator -p user.crit "$line"
  fi
done < "$FIFO"

7. Log-Rotation und Stream-Kontinuität sicherstellen

Log-Rotation ist der häufigste Grund, warum Streaming von Logs mit tail -f (ohne -F) nach einer Weile still wird. Logrotate benennt die aktuelle Datei um und erstellt eine neue – der Dateideskriptor von tail -f zeigt weiterhin auf die alte, umbenannte Datei und empfängt keine neuen Einträge. tail -F erkennt das: Es prüft regelmäßig, ob der Dateiname auf eine andere Inode zeigt, und öffnet in diesem Fall die neue Datei neu. Die Prüffrequenz ist standardmäßig 1 Sekunde, anpassbar mit --sleep-interval.

Für das Streaming von Logs mit inotifywait ist Log-Rotation transparenter, weil Inode-Ebene überwacht wird. Beim Event MOVED_TO im Verzeichnis signalisiert das Betriebssystem, dass eine neue Datei angelegt wurde – der Watchprozess öffnet sie sofort. Eine robuste Strategie für produktive Stream-Kontinuität ist das regelmäßige Neustarten des Tail-Prozesses mit Positionsmerker: Der letzte verarbeitete Byte-Offset wird in einer Datei gespeichert, und beim Neustart liest tail -c +OFFSET die neue Datei ab dieser Position. Das garantiert keine verlorenen Zeilen auch über Rotationsgrenzen hinweg.

8. Performance und Backpressure in langen Pipelines

Beim Streaming von Logs mit hohem Durchsatz sind Pufferung und Backpressure kritische Themen. Wenn die Verarbeitung in der while read-Schleife langsamer ist als das Log-Schreiben, füllt sich der Pipe-Puffer. Linux-Pipes haben standardmäßig 64 KB Puffergröße. Sobald der Puffer voll ist, blockiert der Schreibprozess – in diesem Fall tail – und das System gerät in einen Stau. Für hochfrequente Log-Streams muss die Verarbeitung schnell genug sein oder der Stream muss gezielt gedrosselt werden.

Das Muster für schnelles Streaming von Logs ohne Stau: Schwere Verarbeitungsschritte asynchron auslagern. Die while read-Schleife schreibt jede Zeile in eine schnelle Queue (eine weitere FIFO oder ein einfaches Ringpuffer-Skript), und ein separater Worker-Prozess liest aus der Queue und führt die eigentliche Verarbeitung durch. So kann die Lese-Schleife immer schnell bleiben, während die Verarbeitung im eigenen Tempo läuft. Ein weiterer Trick: grep --line-buffered früh in der Pipeline einsetzen, um irrelevante Zeilen auszufiltern, bevor aufwendige Parsing-Operationen ausgeführt werden.

9. Streaming-Ansätze im direkten Vergleich

Für das Streaming von Logs in verschiedenen Szenarien gibt es unterschiedlich gut geeignete Werkzeuge. Die Wahl hängt von Log-Rotation, Anzahl der Quellen, Echtzeit-Anforderungen und verfügbaren Paketen ab.

Die Kombination aus tail -F für einzelne Dateien, Named FIFOs für Aggregation und inotifywait für Verzeichnis-Überwachung deckt nahezu alle Anforderungen beim Streaming von Logs ab. Wichtig: In Systemen mit sehr hohem Log-Durchsatz (>10 MB/s) stoßen reine Bash-Lösungen an ihre Grenzen – hier sind spezialisierte Tools wie Vector, Fluent Bit oder Promtail sinnvoller. Für die meisten Produktionssysteme mit moderatem Log-Volumen ist Bash jedoch vollständig ausreichend und hat den Vorteil, keine zusätzlichen Laufzeitabhängigkeiten einzuführen.

10. Zusammenfassung

Das Streaming von Logs in Echtzeit mit Bash ist ein mächtiges Werkzeug, das keine externen Abhängigkeiten benötigt. tail -F ist gegenüber tail -f für den Produktionseinsatz immer vorzuziehen, da es Log-Rotation überlebt. while IFS= read -r line; do ... done < <(cmd) hält Variablen im aktuellen Shell-Kontext und ermöglicht Zustandshaltung über den Stream. inotifywait --monitor ist die Wahl für Event-gesteuerte Verarbeitung neuer Dateien ohne Polling. Named FIFOs lösen die Aggregation aus mehreren Log-Quellen. Pufferung in Pipes muss mit --line-buffered und stdbuf -oL kontrolliert werden.

Die kritischste Eigenschaft beim Streaming von Logs ist Robustheit gegenüber Randfällen: Log-Rotation, Backpressure bei Hochlast, verwaiste Prozesse bei Fehlern. Mit trap cleanup EXIT, sorgfältiger PID-Verwaltung und explizitem wait am Skriptende lassen sich diese Randfälle systematisch abdecken. Das Ergebnis ist ein Alerting-System, das auch nach Tagen im Dauerbetrieb korrekt arbeitet.

11. FAQ: Streaming von Logs und Dateien in Echtzeit verarbeiten