Thema: journald
-
journald-Weiterleitung und zentrale Log-Sammlung: ForwardToSyslog, systemd-journal-upload/-remote und Rate Limits
journald kann seine Einträge mit ForwardToSyslog= an einen lokalen Syslog-Daemon übergeben oder per systemd-journal-upload direkt über HTTPS an einen systemd-journal-remote-Listener senden, der eigene Journal-Dateien schreibt. Beide Wege unterliegen dem journald-eigenen Rate Limiting pro Dienst: Nach Überschreiten des Burst-Schwellwerts verwirft es überzählige Meldungen und protokolliert nur deren Anzahl.
-
Wo Betriebssysteme ihre Logs ablegen und wie sich jedes davon abfragen lässt
Ein Agent, der einen Dienst analysiert, muss wissen, welches Subsystem das Log enthält, bevor er es lesen kann. Diese Referenz nennt Log-Speicher und Abfragebefehl für Linux (journald/rsyslog), das Unified Log von macOS, das Windows Event Log, den Error Report von AIX und die syslog-Dateien von FreeBSD.
-
Volle Linux-Festplatte analysieren: df, du, gelöschte, aber noch geöffnete Dateien und das Journal
Ein Dateisystem kann bei Speicherplatz oder bei Inodes voll sein, und Platz, den eine gelöschte, aber noch geöffnete Datei belegt, taucht in du nicht auf. Diese Methodik geht die Prüfungen der Reihe nach durch (df -h, df -i, du -x, lsof +L1, journald-Vacuuming), bevor irgendetwas gelöscht wird.
-
systemd-Journal mit journalctl abfragen: Unit, Boot, Priorität, Zeitraum und JSON-Ausgabe
Mit journalctl lässt sich das systemd-Journal nach Unit, Boot, Priorität und Zeitraum filtern und maschinenlesbar ausgeben, aber nur, wenn das Journal über Neustarts hinweg persistent gespeichert wird. Die Methodik behandelt präzise Abfragen, persistente Speicherung und die Grössenbegrenzungen in journald.conf.
Maschinenlesbar: JSON