Zentralisierte Log-Verwaltung mit rsyslog und Logstash 2026

Ziel: Alle Logs von Servern, Containern und Netzwerkgeräten an einem zentralen Punkt sammeln.
Werkzeuge: rsyslog für die zuverlässige Weiterleitung, Logstash für Filterung und Normalisierung.
Übertragung: Immer TCP mit TLS auf Port 6514, niemals unverschlüsseltes UDP im Produktivbetrieb.
Compliance: DSGVO und CNIL verlangen Zugriffsbeschränkung, Zweckbindung und definierte Aufbewahrungsfristen.
Aufwand: Eine Testumgebung mit einem Quellserver ist in unter 60 Minuten einsatzbereit.

Table of Contents

Warum zentralisierte Log-Verwaltung heute unverzichtbar ist

In einer IT-Landschaft mit Dutzenden von Servern, Containern und Netzwerkgeräten reicht es längst nicht mehr aus, Logs lokal auf jeder Maschine zu speichern. Wer bei einem Vorfall stundenlang einzelne Rechner durchsucht, verliert wertvolle Zeit. Die zentralisierte Log-Verwaltung unter Linux mit rsyslog und Logstash löst genau dieses Problem: Alle Ereignisse laufen an einem Ort zusammen, werden strukturiert, durchsuchbar und auswertbar gemacht.

Kurz gesagt :

Zentralisierte Log-Verwaltung sammelt Logs von Servern, Containern und Netzwerkgeräten an einem zentralen Punkt.
rsyslog übernimmt die zuverlässige Weiterleitung, Logstash die Filterung und Normalisierung.
Die Übertragung erfolgt im Produktivbetrieb immer per TCP mit TLS auf Port 6514, niemals unverschlüsseltes UDP.
DSGVO und CNIL verlangen Zugriffsbeschränkung, Zweckbindung und definierte Aufbewahrungsfristen (in Frankreich oft maximal ein Jahr).

Dieser Leitfaden führt Sie Schritt für Schritt durch die Einrichtung – von der Planung über die Installation bis zum Betrieb. Er richtet sich an Administratoren, DevOps-Verantwortliche und IT-Teams in Frankreich, die ihre Infrastruktur überwachen und gleichzeitig die Vorgaben der DSGVO sowie der Empfehlungen der CNIL (Commission Nationale de l’Informatique et des Libertés) einhalten müssen.

Ich habe in den vergangenen Jahren zahlreiche Umgebungen von lokalem Logging auf zentrale Plattformen migriert. Meine Erfahrung: Die technische Umsetzung ist selten das Problem. Die eigentliche Herausforderung liegt in der Planung, der klaren Definition von Verantwortlichkeiten und der konsequenten Absicherung der Übertragungswege.

Die Grundlagen verstehen: Was ist zentralisierte Log-Verwaltung?

Zentralisierte Log-Verwaltung bedeutet, dass Protokolldaten von mehreren Quellen an einen zentralen Sammelpunkt übertragen, dort verarbeitet und gespeichert werden. Bevor Sie installieren, sollten Sie dieses Konzept verinnerlichen, denn es bestimmt jede spätere Architekturentscheidung.

Die Rolle von rsyslog

rsyslog ist der Standard-Syslog-Daemon auf nahezu allen Linux-Distributionen wie Debian, Ubuntu, Red Hat oder AlmaLinux. Er sammelt lokale Logs, filtert sie nach Regeln und kann sie per TCP oder UDP an einen entfernten Server weiterleiten. Seine Stärke liegt in der Effizienz und der breiten Unterstützung des Syslog-Protokolls nach RFC 5424.

Die Rolle von Logstash

Logstash ist eine Pipeline zur Datenverarbeitung aus dem Elastic Stack. Es empfängt Logs, transformiert sie mithilfe von Filtern wie grok, mutate oder date, reichert sie an und leitet sie an ein Ziel wie Elasticsearch weiter. Damit eignet es sich ideal für die strukturierte Auswertung und Suche.

Das Zusammenspiel beider Werkzeuge

In der Praxis ergänzen sich beide: rsyslog übernimmt die zuverlässige Weiterleitung auf Systemebene, Logstash die intelligente Verarbeitung und Normalisierung. So entsteht eine Pipeline, die sowohl robust als auch analysierbar ist. Diese Arbeitsteilung ist der Kern einer skalierbaren Log-Architektur.

Die Infrastruktur planen und vorbereiten

Eine saubere Planung erspart später viel Ärger. Klären Sie vor der Installation die Dimensionierung, die Rollenverteilung und die rechtlichen Rahmenbedingungen.

Anforderungen und Dimensionierung festlegen

Log-Volumen: Schätzen Sie die tägliche Datenmenge in Gigabyte ab, um Speicher und CPU zu dimensionieren.
Aufbewahrungsdauer: Beachten Sie gesetzliche Vorgaben. In Frankreich verlangt die CNIL für bestimmte Verbindungsdaten in der Regel eine Aufbewahrung von maximal einem Jahr.
Netzwerktopologie: Entscheiden Sie, ob Logs über ein internes VLAN oder verschlüsselt über TLS übertragen werden.
Wachstumsprognose: Planen Sie mindestens 30 Prozent Reserve für die nächsten zwei Jahre ein.

Server und Rollen verteilen

Log-Quellen: Alle Server und Anwendungen, die Protokolle erzeugen.
Relay-Server: Optionaler rsyslog-Server, der Logs bündelt.
Verarbeitungsserver: Die Instanz mit Logstash und Elasticsearch.
Visualisierung: Kibana oder ein vergleichbares Dashboard.

Sicherheit und DSGVO-Konformität berücksichtigen

Da Logs personenbezogene Daten enthalten können – IP-Adressen, Benutzernamen, Sitzungsdaten –, gelten die Vorgaben der DSGVO. Dokumentieren Sie die Verarbeitung, beschränken Sie den Zugriff auf autorisierte Personen und pseudonymisieren Sie sensible Felder, wo es möglich ist. In Frankreich sollten Sie zusätzlich die Empfehlungen der CNIL zur Protokollierung beachten.

rsyslog auf den Quellservern konfigurieren

Auf jedem Quellserver richten Sie rsyslog so ein, dass Logs an den zentralen Server gesendet werden. Die Konfiguration ist überschaubar, erfordert aber Sorgfalt bei den Details.

rsyslog installieren und prüfen

Auf Debian und Ubuntu genügt ein kurzer Befehlssatz:

sudo apt update
sudo apt install rsyslog
sudo systemctl enable --now rsyslog

Prüfen Sie den Status anschließend mit systemctl status rsyslog. Läuft der Dienst, können Sie mit der Weiterleitung beginnen.

Die Weiterleitung einrichten

Öffnen Sie die Konfigurationsdatei /etc/rsyslog.d/50-default.conf oder legen Sie eine neue Datei /etc/rsyslog.d/60-remote.conf an. Fügen Sie folgende Zeile hinzu, um alle Logs per TCP an den zentralen Server zu senden:

*.* @@logs.example.fr:514

Das doppelte @@ steht für TCP, ein einfaches @ für UDP. TCP ist wegen der Zuverlässigkeit zu empfehlen. Ich rate grundsätzlich davon ab, im Produktivbetrieb auf UDP zu setzen – der Paketverlust ist real und schwer nachzuweisen.

TLS-Verschlüsselung aktivieren

Für den Produktivbetrieb sollten Sie die Übertragung verschlüsseln. rsyslog unterstützt TLS über die Module gtls oder ossl. Erstellen Sie ein Zertifikat, beispielsweise mit OpenSSL oder einer internen PKI, und verweisen Sie in der Konfiguration auf Zertifikat, Schlüssel und CA-Datei. Als Port empfiehlt sich 6514, um Verwechslungen mit dem unverschlüsselten Standard zu vermeiden.

Dienst neu starten und testen

sudo systemctl restart rsyslog
logger "Testnachricht an den zentralen Server"

Prüfen Sie anschließend auf dem Zielserver, ob die Nachricht angekommen ist. Ein fehlender Eintrag deutet meist auf eine Firewall-Regel oder ein falsches Zertifikat hin.

Den zentralen rsyslog-Server einrichten

Der zentrale Server nimmt die Logs entgegen und schreibt sie in definierte Verzeichnisse. Diese Instanz ist das Rückgrat Ihrer Log-Plattform.

Empfang konfigurieren

Aktivieren Sie in /etc/rsyslog.conf die Module imtcp und gegebenenfalls imudp:

module(load="imtcp")
input(type="imtcp" port="514")

Logs nach Host trennen

Eine bewährte Vorlage legt für jeden Host ein eigenes Verzeichnis an:

$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs
& stop

Damit bleiben die Daten übersichtlich und lassen sich später leichter an Logstash übergeben. Die Struktur nach Hostname und Programmname hat sich in meiner Praxis bewährt.

Rotation und Speicherplatz verwalten

Konfigurieren Sie logrotate für /var/log/remote/, damit die Festplatte nicht überläuft. Planen Sie je nach Volumen eine tägliche oder stündliche Rotation ein. Eine volle Partition auf dem Logserver ist einer der häufigsten Ausfälle, die ich in Audits sehe.

Logstash installieren und die Pipeline aufbauen

Jetzt kommt die Verarbeitungsschicht. Logstash liest die gesammelten Logs, strukturiert sie und übergibt sie an Elasticsearch.

Logstash installieren

Auf Debian und Ubuntu empfiehlt sich das offizielle Elastic-Repository:

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
sudo apt install logstash

Eine Konfigurationsdatei erstellen

Legen Sie /etc/logstash/conf.d/rsyslog.conf an. Eine Pipeline besteht immer aus drei Teilen: Input, Filter, Output.

input { file { path => "/var/log/remote/**/*.log" start_position => "beginning" type => "syslog" }
} filter { grok { match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{SYSLOGHOST:hostname} %{DATA:program}: %{GREEDYDATA:msg}" } } date { match => [ "timestamp", "MMM d HH:mm:ss", "MMM dd HH:mm:ss" ] }
} output { elasticsearch { hosts => ["http://localhost:9200"] index => "logs-%{+YYYY.MM.dd}" }
}

Pipeline testen und starten

Prüfen Sie die Syntax mit:

sudo -u logstash /usr/share/logstash/bin/logstash --config.test_and_exit -f /etc/logstash/conf.d/rsyslog.conf

Starten Sie anschließend den Dienst mit systemctl restart logstash. Achten Sie auf das Logstash-Log unter /var/log/logstash/, um Fehler in den Grok-Mustern frühzeitig zu erkennen.

Elasticsearch und Kibana für Suche und Visualisierung nutzen

Ohne eine Suchoberfläche bleiben die gesammelten Logs schwer nutzbar. Elasticsearch indiziert die Daten, Kibana macht sie sichtbar.

Elasticsearch konfigurieren

Achten Sie auf ausreichend Heap-Speicher in /etc/elasticsearch/jvm.options, mindestens 4 GB für kleine Umgebungen. Legen Sie Index-Lebenszyklen (ILM) an, um alte Daten automatisch zu löschen. Das verhindert unkontrolliertes Wachstum und senkt die Speicherkosten.

Kibana anbinden

Verbinden Sie Kibana mit dem Elasticsearch-Cluster und erstellen Sie ein Index-Pattern wie logs-*. So lassen sich Dashboards für Fehlerraten, Anmeldungen oder Sicherheitsereignisse aufbauen.

Nützliche Auswertungen für den Alltag

Anzahl fehlgeschlagener SSH-Anmeldungen pro Stunde
Top-10 der Fehlermeldungen nach Anwendung
Verteilung der Logs nach Server und Region
Durchschnittliche Antwortzeit von Webdiensten im Tagesverlauf

Den Betrieb absichern und überwachen

Eine zentralisierte Log-Plattform ist selbst kritische Infrastruktur. Sie braucht Überwachung und Absicherung, sonst wird sie zum Einfallstor oder zum blinden Fleck.

Zugriffsrechte einschränken

Setzen Sie Rollen in Elasticsearch (RBAC), sodass nur berechtigte Teams sensible Indizes lesen dürfen. Aktivieren Sie die Authentifizierung mit X-Pack Security oder OpenSearch Security. In französischen Unternehmen mit mehreren Standorten empfiehlt sich eine klare Trennung nach Fachbereichen.

Monitoring der Pipeline

Überwachen Sie mit Werkzeugen wie Prometheus, Grafana oder dem Elastic-Monitoring:

Verzögerungen in der Logstash-Pipeline
Festplattenauslastung auf dem zentralen Server
Fehlerraten bei der Indexierung
Anzahl der Events pro Sekunde im Vergleich zum Vortag

Notfallplan

Definieren Sie, was passiert, wenn der zentrale Server ausfällt. Eine lokale Pufferung auf den Quellservern (rsyslog-Disk-Queue) verhindert Datenverlust. Testen Sie diesen Fall regelmäßig, nicht nur auf dem Papier.

Welche Vor- und Nachteile haben die gängigen Ansätze?

Die Wahl der Architektur bestimmt Kosten, Wartungsaufwand und Skalierbarkeit. Die folgende Übersicht vergleicht typische Varianten, die ich in Projekten evaluiert habe.

Vergleich zentraler Log-Architekturen nach Kosten, Aufwand und Eignung
Ansatz	Einrichtungsaufwand	Monatliche Kosten (Beispiel)	Skalierbarkeit	Empfehlung
rsyslog + Logstash + Elasticsearch (self-hosted)	hoch, 2–5 Tage	ca. 180–450 € für 3 VMs	sehr gut, horizontal erweiterbar	für Teams mit eigener Betriebsexpertise
rsyslog + Graylog	mittel, 1–3 Tage	ca. 120–300 €	gut, bis mittlere Volumen	für kleinere Umgebungen
rsyslog + Fluent Bit + OpenSearch	mittel bis hoch, 2–4 Tage	ca. 150–400 €	sehr gut	für containerlastige Umgebungen
Gehostete Lösung in Frankreich	gering, unter 1 Tag	ab 90 € für 10 GB/Tag	sehr gut, abhängig vom Anbieter	für Teams ohne Betriebsressourcen

Häufige Fehler, die Sie vermeiden sollten

Viele Probleme entstehen durch kleine Nachlässigkeiten. Die folgenden Fehler begegnen mir in der Praxis am häufigsten:

Unverschlüsselte Übertragung: Logs enthalten oft sensible Daten. Ohne TLS gefährden Sie die DSGVO-Konformität.
Fehlende Zeitsynchronisation: Ohne NTP, beispielsweise über einen französischen NTP-Pool oder einen internen Zeitserver, lassen sich Ereignisse nicht korrekt zuordnen.
Keine Rotation: Eine volle Festplatte legt den gesamten Logserver lahm.
Zu offene Filter: Grok-Muster, die zu viel erfassen, blähen die Indizes auf und verlangsamen Suchen.
Fehlende Aufbewahrungsregeln: Ohne ILM wachsen die Daten unbegrenzt und verursachen unnötige Kosten.
Zugriff für alle: Nicht jeder im Unternehmen sollte automatisch alle Logs einsehen dürfen.
Kein Test der Wiederherstellung: Prüfen Sie regelmäßig, ob sich Logs aus Backups rekonstruieren lassen.

Wie gehen Sie mit sehr großen Log-Mengen um?

Bei hohen Volumen stoßen einfache Datei-Inputs an ihre Grenzen. Setzen Sie auf Pufferung mit Kafka oder Redis, Index-Lebenszyklus-Management und gegebenenfalls eine horizontale Skalierung des Elasticsearch-Clusters. Für französische Unternehmen mit hohem Volumen kann auch eine gehostete Lösung in einem Rechenzentrum in Frankreich sinnvoll sein, um Latenz und Datenhoheit zu wahren.

Häufig gestellte Fragen

Was ist der Unterschied zwischen rsyslog und Logstash?

rsyslog ist ein Systemdienst zum Sammeln und Weiterleiten von Logs auf Betriebssystemebene, Logstash eine Verarbeitungspipeline, die Logs filtert, anreichert und an Analyseplattformen weitergibt. In der Praxis ergänzen sie sich ideal.

Brauche ich zwingend Elasticsearch für Logstash?

Nein, Logstash kann Daten auch an Dateien, Kafka, S3 oder andere Ziele senden. Für Suche und Visualisierung ist Elasticsearch oder OpenSearch jedoch die gängigste Wahl.

Welchen Port sollte ich für die Log-Übertragung verwenden?

Standardmäßig wird Port 514 genutzt. Für TLS-Verbindungen empfiehlt sich ein anderer Port, etwa 6514, um Verwechslungen zu vermeiden.

Ist die zentralisierte Log-Verwaltung DSGVO-konform?

Ja, sofern Sie den Zugriff beschränken, die Aufbewahrungsfristen einhalten und personenbezogene Daten nur zweckgebunden verarbeiten. Dokumentieren Sie die Verarbeitung in Ihrem Verzeichnis der Verarbeitungstätigkeiten.

Welche Alternativen gibt es zu rsyslog und Logstash?

Häufig genannte Alternativen sind Fluentd, Fluent Bit, Graylog und Vector. Die Wahl hängt von Ihrem Ökosystem und Ihren Analyseanforderungen ab.

Wie starten Sie konkret?

Die zentralisierte Log-Verwaltung unter Linux mit rsyslog und Logstash ist kein Hexenwerk, sondern eine Frage sauberer Planung und konsequenter Umsetzung. Wer die hier beschriebenen Schritte befolgt – von der Dimensionierung über die TLS-Absicherung bis zur Visualisierung in Kibana – erhält eine belastbare Grundlage für Betrieb, Fehlersuche und Compliance.

Beginnen Sie mit einer kleinen Testumgebung, sammeln Sie erste Erfahrungen und erweitern Sie die Plattform anschließend schrittweise. So wachsen Sie mit Ihren Anforderungen, ohne Ihr Team oder Ihr Budget zu überfordern.

Handlungsaufforderung: Richten Sie noch heute einen Testserver ein und übertragen Sie die Logs einer einzelnen Maschine. Sie werden schnell erkennen, wie viel Zeit und Nerven Ihnen eine zentrale Log-Plattform im Alltag spart.

Für die effektive Verarbeitung der gesammelten Daten ist eine präzise Logstash Konfiguration für Linux Logs unerlässlich.

Die Sicherheit der gesamten Pipeline ist dabei von größter Bedeutung, weshalb man die Logstash Pipeline sicher konfigurieren sollte.

Für die effiziente Erfassung von Logs von vielen Servern ist es ratsam, das Logstash Beats Input Plugin zu konfigurieren.

Anna Berger

IT-Sicherheitsanalystin und Tech-Journalistin

Schon als Kind war ich fasziniert von der Logik hinter Computern und der unendlichen Welt der Daten. Was als spielerische Neugier mit dem Zerlegen alter PCs begann, entwickelte sich schnell zu einer tiefen Leidenschaft für die Informatik. Heute sehe ich es als meine Berufung, komplexe digitale Themen greifbar zu …

Tous les articles de Anna Berger →