Open Source Zentraler Logging-Server mit Systemd-Journal-Remote auf Debian und Ubuntu Linux
Dieser Blogbeitrag beschreibt, wie man Logs auf Servern mit systemd-basierten Linux-Distributionen mit systemd-journal-remote zentralisiert
Dieser Blogbeitrag beschreibt, wie man Logs auf Servern mit systemd-basierten Linux-Distributionen mit systemd-journal-remote zentralisiert
Dieser Blogpost wurde von einer Maschine aus dem Englischen übersetzt. Die Originalversion finden Sie hier: Open Source Centralized Logging Server with Systemd-Journal-Remote on Debian and Ubuntu Linux
Bitte kontaktieren Sie uns , wenn etwas nicht klar beschrieben ist, nicht funktioniert, falsch erscheint oder wenn Sie Unterstützung benötigen.
Dieser Blogbeitrag beschreibt, wie Sie systemd-journal-remote installieren und konfigurieren, um Logs von bis zu hunderten von Client-Servern an eine zentrale Log-Aggregationsmaschine zu streamen. Er wurde so konzipiert, dass er für Linux-Administratoren mit wenig Linux-Erfahrung leicht zu befolgen ist. Alle Befehle und Konfigurationsdateien, die zum Einrichten dieses Dienstes erforderlich sind, werden detailliert erklärt und können kopiert werden. Er wurde für Debian 13 und Ubuntu 24.04 geschrieben und getestet, sollte aber mit jeder anderen Linux-Distribution funktionieren, die systemd verwendet.
Ein zentralisierter Logfile-Server ist ein System, das darauf ausgelegt ist, Logdaten aus mehreren Quellen an einem einzigen Ort zu aggregieren, zu speichern und zu analysieren, um die Überwachung und Verwaltung zu erleichtern.
Mit dem Umstieg aktueller Linux-Distributionen auf systemd als Init-System und System-Manager werden Log-Nachrichten nun in einem effizienten systemd-Journal-Dateiformat gespeichert.
Standardmäßig werden diese Journal-Logs direkt auf jedem Server an einem Ort wie “/var/log/journal/8GYiL51Rgi2n5IyNFGqoGiBwaqQ4WRV0/system.journal” gespeichert, wobei “8GYiL51Rgi2n5IyNFGqoGiBwaqQ4WRV0” die in “/etc/machine-id” festgelegte Maschinenkennung ist.
Dies funktioniert gut für ein einzelnes System. Wenn Sie jedoch mit einer größeren Anzahl von Servern oder Cloud-Instanzen arbeiten, benötigen Sie eine bessere Lösung zur zentralen Verwaltung all dieser Logfiles.
Die zentrale Verwaltung von Logfiles vieler Server hat auch den Vorteil, dass Logs, sobald sie an den zentralen Server gesendet wurden, von einem Angreifer nicht mehr geändert werden können - ein Angreifer könnte die Logs, die auf dem Client gespeichert sind, ändern, aber Sie könnten sie mit dem Server vergleichen und die Änderung würde auftauchen. Dies erhöht die Sicherheit Ihrer Infrastruktur insgesamt.
Interessanter Fakt: Wir hatten einmal einen solchen Vorfall bei einem Kunden, bei dem ein Dritter eine Änderung an seinen Servern vornahm und es vermasselte, und dann versuchte, seine Spuren zu verwischen, indem er Logzeilen löschte. Unsere Berater konnten dies feststellen, indem sie die Logs auf dem (Client-)Server mit denen verglichen, die an den zentralen Log-Server gesendet wurden.
Eine zentralisierte Log-Management-Lösung hilft bei diesen Problemen. Sie konsolidiert alle individuellen Journals der Client-Server in einem einzigen Journal auf dem zentralen Log-Server, das mit Identifikatoren wie dem Hostnamen des Clients oder dem Hostnamen plus dem Namen eines Dienstes oder von Diensten durchsucht werden kann.
Hier sind einige gute Gründe für die Einrichtung eines zentralisierten Logging-Systems:
Sie können dem zentralen Log-Server mehr Speicherplatz zuweisen, um Logs länger als auf den Clients zu speichern.
Angreifer werden oft versuchen, Logfiles zu löschen - indem Sie die Logzeilen an den zentralen Server streamen, können sie vom Angreifer nicht mehr gelöscht werden.
Die Analyse von Logs wird zum Kinderspiel, wenn Sie Daten von mehreren Systemen an einem Ort querverweisen können.
Für Systemadministratoren vereinfacht es den Zugriff auf Logs über alle Systeme hinweg, von denen einige sie möglicherweise aufgrund von Sicherheitsrichtlinien nicht direkt zugreifen können.
Um einen Open-Source-Log-Server zu erstellen, werden wir Komponenten von systemd , nämlich systemd-journal-remote , nutzen, um alle Logs von verschiedenen Debian- und Ubuntu-Linux-Hosts an einen zentralen Log-Collector-Server zu streamen.
Systemd-Journal-Remote folgt der Unix-Philosophie eine Sache tun und sie gut machen - es streamt nur die Logfiles von Linux-Servern an einen zentralen Log-Server, sonst nichts. Zusätzlich dazu bietet systemd den journalctl CLI-Befehl , der zum Abfragen und Durchsuchen von systemd-Journal-Dateien verwendet werden kann, die alle Logs in einem effizienten Format speichern.
Auf dem zentralen Log-Server können Sie zusätzlich Graylog oder ein anderes Log-Analyse-Tool installieren, um die Logs der Client-Hosts zu untersuchen. Graylog bringt auch Log-Aggregations-Tools mit, aber diese sind weder so leichtgewichtig noch so effizient beim Übertragen und Speichern von Logfiles wie das Linux-Standard-systemd-journal-remote. Daher empfehlen wir, systemd-journal-remote zu verwenden, um die Logs an den zentralen Server zu streamen, und dann Graylog zu verwenden, um sie mit einer grafischen Benutzeroberfläche zu analysieren.
Obwohl es möglich ist, die Kommandozeilenschnittstelle “journalctl” zu verwenden, um die Logfiles aller Client-Hosts im Detail zu inspizieren und sie zu durchsuchen, ist systemd-journal weder dafür entwickelt noch dafür gedacht, ein vollwertiges Log-Analyse-Tool wie Graylog oder ähnliches zu ersetzen.
Wir denken, dass die Verwendung von systemd-journal-remote zum Sammeln und Zentralisieren von Logfiles auf Linux ein sehr guter Ansatz ist, da es die systemd-Technologie nutzt, die bereits mit der Linux-Distribution geliefert wird. Es ist sehr wenig zusätzlicher Code, der auf dem System läuft, es ist sehr stabil (wir verwenden diese Lösung seit zwei Jahren vor dem Zeitpunkt dieses Schreibens), besonders während Ausfällen des Netzwerks oder des zentralen Log-Servers, und es ist die Standardlösung zum Zentralisieren von Logfiles in systemd-basierten Linux-Distributionen.
Am Ende TODO dieses Blogbeitrags werden wir Ihnen die häufigsten Beispiele für die Verwendung von “journalctl” zur Durchsuchung der Logfiles der Log-Client-Server bereitstellen. Wir empfehlen jedoch, eine grafische Log-Analyse-Lösung auf dem zentralen Logserver zu installieren, wie Graylog oder ähnliches. Dies macht das Durchsuchen und Alarmieren bei Logs viel einfacher als die etwas schwer zu merkenden “journalctl”-Befehle.
Um einen zentralisierten Log-Management-Server mit systemd-journal-remote effektiv einzurichten, werden wir die zuvor erwähnten Ansible-Tasks in Bash-Befehle übersetzen. Dieser Ansatz ermöglicht es Ihnen, Ihren Server manuell einzurichten und bietet ein praktisches Verständnis für jeden Schritt.
Beginnen wir mit der Installation des systemd-journal-remote apt-Pakets:
apt install systemd-journal-remote
Nach der Installation richten Sie die korrekten Berechtigungen für das Verzeichnis ein, in dem Remote-Logs gespeichert werden:
mkdir -p /var/log/journal/remote/
chown systemd-journal-remote:systemd-journal-remote /var/log/journal/remote/
chmod 0750 /var/log/journal/remote/
Als nächstes konfigurieren wir systemd-journal-remote, indem wir die erforderlichen Konfigurationsdateien erstellen:
cat << EOF > /etc/systemd/journal-remote.conf
[Remote]
Seal=true
SplitMode=none
EOF
Setzen Sie den korrekten Besitzer, die Gruppe und die Berechtigungen für die Datei:
chown systemd-journal-remote:systemd-journal-remote /etc/systemd/journal-remote.conf
chmod 0640 /etc/systemd/journal-remote.conf
Und für die systemd-Service-Konfiguration /etc/systemd/system/systemd-journal-remote.service:
cat << EOF > /etc/systemd/system/systemd-journal-remote.service
[Unit]
Description=Journal Remote Sink Service
Documentation=man:systemd-journal-remote(8) man:journal-remote.conf(5)
Requires=systemd-journal-remote.socket
[Service]
ExecStart=/lib/systemd/systemd-journal-remote --listen-http=-3 --output=/var/log/journal/remote/all.journal
LockPersonality=yes
LogsDirectory=journal/remote
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
PrivateDevices=yes
PrivateNetwork=yes
PrivateTmp=yes
ProtectProc=invisible
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectSystem=strict
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
SystemCallArchitectures=native
User=systemd-journal-remote
WatchdogSec=3min
# If there are many split up journal files we need a lot of fds to access them
# all in parallel.
LimitNOFILE=524288
[Install]
Also=systemd-journal-remote.socket
EOF
Setzen Sie den korrekten Besitzer, die Gruppe und die Berechtigungen für die Datei:
chown root:root /etc/systemd/system/systemd-journal-remote.service
chmod 0644 /etc/systemd/system/systemd-journal-remote.service
Und aktivieren Sie den systemd-Service:
systemctl daemon-reload
systemctl enable systemd-journal-remote.service
systemctl start systemd-journal-remote.service
systemctl status systemd-journal-remote.service
● systemd-journal-remote.service - Journal Remote Sink Service
Loaded: loaded (/etc/systemd/system/systemd-journal-remote.service; indirect; preset: disabled)
Active: active (running) since Sun 2024-03-24 17:50:31 UTC; 25s ago
TriggeredBy: ● systemd-journal-remote.socket
Docs: man:systemd-journal-remote(8)
man:journal-remote.conf(5)
Main PID: 1638 (systemd-journal)
Status: "Processing requests..."
Tasks: 1 (limit: 4531)
Memory: 5.6M
CPU: 63ms
CGroup: /system.slice/systemd-journal-remote.service
└─1638 /lib/systemd/systemd-journal-remote --listen-http=-3 --output=/var/log/journal/remote/all.journal
Mar 24 17:50:31 central-log-server systemd[1]: Started systemd-journal-remote.service - Journal Remote Sink Service.
Mar 24 17:50:31 central-log-server systemd-journal-remote[1638]: microhttpd: MHD_OPTION_EXTERNAL_LOGGER is not the first option specified for the daemon. Some messages may be printed by the standard MHD logger.
Um eine effiziente Speicherverwaltung aufrechtzuerhalten und zu verhindern, dass Ihr Log-Verzeichnis übermäßig überfüllt wird, richten wir einen systemd-Timer ein, um regelmäßig Logs zu löschen, die älter als 90 Tage sind.
Erstellen Sie zunächst eine systemd-Service-Datei, die den auszuführenden Befehl angibt. Dieser Service startet nicht automatisch, sondern wird durch einen systemd-Timer ausgelöst. Diese Service-Datei definiert einen einfachen Service, der beim Start den Befehl zum Suchen und Löschen von Logs, die älter als 90 Tage sind, in /var/log/journal/remote ausführt.
cat << EOF > /etc/systemd/system/delete-old-logs.service
[Unit]
Description=Delete old systemd logs
[Service]
Type=oneshot
ExecStart=/usr/bin/find /var/log/journal/remote -mtime +90 -delete
EOF
Um den korrekten Benutzer, die Gruppe und die Berechtigungen für die Datei zu definieren:
chown root:root /etc/systemd/system/delete-old-logs.service
chmod 0644 /etc/systemd/system/delete-old-logs.service
Erstellen Sie als nächstes einen systemd-Timer, der so eingestellt ist, dass er den delete-old-logs.service täglich auslöst. Die Option Persistent=true stellt sicher, dass, wenn der Timer verpasst wurde (z.B. der zentrale Log-Server wurde ausgeschaltet), er beim nächsten Booten ausgelöst wird.
cat << EOF > /etc/systemd/system/delete-old-logs.timer
[Unit]
Description=Timer for deleting old systemd logs
[Timer]
OnCalendar=daily
Persistent=true
[Install]
WantedBy=timers.target
EOF
Um den korrekten Benutzer, die Gruppe und die Berechtigungen für die Datei zu definieren:
chown root:root /etc/systemd/system/delete-old-logs.timer
chmod 0644 /etc/systemd/system/delete-old-logs.timer
Um den Timer zu aktivieren und zu starten, führen Sie die folgenden Befehle aus. Diese Befehle stellen sicher, dass der Timer aktiv ist und basierend auf dem definierten Zeitplan startet, wodurch der Service automatisch ausgelöst wird, um täglich alte Logs zu löschen.
systemctl enable delete-old-logs.timer
systemctl start delete-old-logs.timer
Sie können den Status Ihres Timers überprüfen, indem Sie Folgendes ausführen:
systemctl list-timers delete-old-logs.timer
NEXT LEFT LAST PASSED UNIT ACTIVATES
Mon 2024-03-25 00:00:00 UTC 6h left - - delete-old-logs.timer delete-old-logs.service
1 timers listed.
Pass --all to see loaded but inactive timers, too.
Der nächste Schritt besteht darin, alle Client-Server so zu konfigurieren, dass sie ihre Journals an den zentralen Log-Server senden.
Wir werden die Clients so konfigurieren, dass sie ihre Logs sowohl an den zentralen Server streamen als auch lokal speichern, wie wir es bereits von Einzelserver-Setups gewohnt sind.
Beachten Sie, dass wenn das Netzwerk zum zentralen Log-Server unterbrochen wird, oder der zentrale Log-Server ausgefallen ist, oder die Festplatte auf dem zentralen Log-Server voll ist, die Clients das Streamen ihrer Logs unterbrechen und alles auf einmal streamen, wenn der zentrale Log-Server wieder verfügbar wird. Auf diese Weise stellt systemd-journal-remote sicher, dass Logs während vorübergehender Unterbrechungen nicht verloren gehen.
Zunächst stellen wir sicher, dass die notwendigen Tools auf dem Client-System installiert sind. Das systemd-journal-remote-Paket enthält den systemd-journal-upload-Service, der für das Senden von Logs an den zentralisierten Server verantwortlich ist.
apt install systemd-journal-remote
Richten Sie nun die Konfiguration für den systemd-journal-upload-Service ein. Dies beinhaltet die Angabe der URL Ihres zentralisierten Logging-Servers. Sie ersetzen die Platzhalter durch die IP-Adresse und Portnummer Ihres Servers.
Erstellen Sie /etc/systemd/journal-upload.conf mit folgendem Inhalt, wobei Sie systemd_journal_remote_server_ip durch die tatsächliche IP Ihres zentralen Log-Servers ersetzen.
Bitte beachten Sie, dass dieses Setup keine TLS-Verschlüsselung mit SSL-Zertifikaten konfiguriert (beachten Sie das http:// in der nächsten Konfigurationsdatei), die optional für systemd-journal-remote verfügbar ist. Wir haben dies weggelassen, weil wir glauben, dass alle Server in einer beliebigen Infrastruktur immer Teil eines privaten verschlüsselten VPN-Mesh-Netzwerks sein sollten, wie zum Beispiel ein Wireguard-Mesh-Netzwerk , über das solcher Verkehr geleitet wird - neben Backup- und Monitoring-Verkehr sowie jedem anderen intern verwendeten Verkehr. Sie können jedoch systemd-journald-remote so konfigurieren, dass es httpS:// verwendet, wenn Sie planen, die Logdaten über Netzwerke zu senden, die nicht Ende-zu-Ende verschlüsselt sind. Bitte beziehen Sie sich auf die systemd-journal-remote.conf-Manualseite oder, wenn Sie zu 100% sicher sein möchten, dass es professionell und sicher konfiguriert ist, nehmen Sie Kontakt mit unseren Linux-Beratern auf , damit diese die erforderlichen Konfigurationen für Sie einrichten.
cat << EOF > /etc/systemd/journal-upload.conf
[Upload]
URL=http://your_central_logserver_ip:19532
EOF
Setzen Sie den korrekten Benutzer, die Gruppe und die Berechtigungen für die Datei:
chown root:root /etc/systemd/journal-upload.conf
chmod 0644 /etc/systemd/journal-upload.conf
Definieren Sie abschließend die Datei systemd-journal-upload.service. Dies umfasst verschiedene Sicherheits- und Betriebseinstellungen zur Optimierung des Log-Uploads.
Erstellen Sie /etc/systemd/system/systemd-journal-upload.service mit folgendem Inhalt:
cat << EOF > /etc/systemd/system/systemd-journal-upload.service
[Unit]
Description=Journal Remote Upload Service
Documentation=man:systemd-journal-upload(8)
Wants=network-online.target
After=network-online.target
[Service]
ExecStartPre=/bin/sleep 10
Restart=on-failure
DynamicUser=yes
ExecStart=/lib/systemd/systemd-journal-upload --save-state
LockPersonality=yes
MemoryDenyWriteExecute=yes
PrivateDevices=yes
ProtectProc=invisible
ProtectControlGroups=yes
ProtectHome=yes
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
RestrictNamespaces=yes
RestrictRealtime=yes
StateDirectory=systemd/journal-upload
SupplementaryGroups=systemd-journal
SystemCallArchitectures=native
User=systemd-journal-upload
WatchdogSec=3min
[Install]
WantedBy=multi-user.target
EOF
Setzen Sie den korrekten Benutzer, die Gruppe und die Berechtigungen für die Datei:
chown root:root /etc/systemd/system/systemd-journal-upload.service
chmod 0644 /etc/systemd/system/systemd-journal-upload.service
Nach der Konfiguration aktivieren und starten Sie den systemd-journal-upload-Service:
systemctl daemon-reload
systemctl enable systemd-journal-upload
Created symlink /etc/systemd/system/multi-user.target.wants/systemd-journal-upload.service → /etc/systemd/system/systemd-journal-upload.service.
systemctl start systemd-journal-upload
systemctl status systemd-journal-upload
● systemd-journal-upload.service - Journal Remote Upload Service
Loaded: loaded (/etc/systemd/system/systemd-journal-upload.service; enabled; preset: disabled)
Active: active (running) since Sun 2024-03-24 18:19:46 UTC; 45s ago
Docs: man:systemd-journal-upload(8)
Process: 1700 ExecStartPre=/bin/sleep 10 (code=exited, status=0/SUCCESS)
Main PID: 1701 (systemd-journal)
Status: "Processing input..."
Tasks: 1 (limit: 4531)
Memory: 2.8M
CPU: 130ms
CGroup: /system.slice/systemd-journal-upload.service
└─1701 /lib/systemd/systemd-journal-upload --save-state
Mar 24 18:19:35 central-log-client systemd[1]: Starting systemd-journal-upload.service - Journal Remote Upload Service...
Mar 24 18:19:46 central-log-client systemd[1]: Started systemd-journal-upload.service - Journal Remote Upload Service.
Um zu überprüfen, ob alles funktioniert, öffnen Sie ein Terminal auf dem Server und beginnen Sie mit der Anzeige der Logs des Clients im Follow-Modus:
journalctl --file /var/log/journal/remote/all.journal -n 0 -f
Loggen Sie nun etwas auf dem Client:
systemd-cat --identifier="administrator" echo "this is a test string"
Es sollte auf dem Server erscheinen:
journalctl --file /var/log/journal/remote/all.journal -n 0 -f
Mar 24 18:27:00 central-log-client administrator[1886073]: this is a test string
Für praktische Beispiele zum Durchsuchen der Logs von den Client-Servern lesen Sie bitte das Blunix Manual , das beispielhafte journalctl-Befehle dokumentiert, wie man dies macht.
Wie bereits erwähnt, empfehlen wir, ein Tool wie Graylog auf dem zentralen Log-Server zu installieren, um dies grafisch durchzuführen und Alarme für protokollierte Fehler einzurichten.
Suchen Sie
Linux Notfallunterstützung,
Linux-Beratung für Projekte,
Linux Managed Hosting,
Qubes OS Beratung und Support oder
Online- und Vor-Ort-Schulungen?