Kleiner großer Überblick über die Loggingszene
Seit systemd gibt es auch journald.
Genauso so, wie man seitdem systemd mit systemctl befehligt, juckt, pardon: guckt, man Systemlogs jetzt mit journalctl an.
Ein generelles Mistverständnis®™ ist, dass viele glauben, dieses "Journal" wäre tatsächlich ein seit systemd komplett neues Systemlogprogramm. Dem ist nicht so.
Es gibt schon immer mindestens zwei "Systemlogger" auf einem Linuxsystem. (Also jedenfalls, seit Logger Standard wurden; in ganz grauer Vorzeit kannte man solche Kontrollmechanismen gar nicht.)
Im Hintergrund arbeiten normalerweise zwei Logger. Einer für den Kernel, eine für das "Userland". Auch heute muss das nicht zwingend journald sein. Tatsächlich war es bei openSUSE in der Einführungszeit von systemd immr noch rsyslogd, der das Logging übernahm und der auch heute noch in vielen Unices und Linuces für das Loggen zuständig ist. Dieses probate ausgereifte Tool kann weit über 1 Millionen Logevents pro Sekunde verarbeiten. Is schon ma ne Hausnummer.
Bei openSUSE haben wir ja jetzt journald. Beide bedienen sich übrigens eines präzise definierten Protokolls, nämlich des Syslogprotokolls. Und das ist so sauber (mit kleinen Sicherheitschwächen) definiert, dass man auf JEDEM Linuxsystem ALLE Logevents auch über das Netzwerk zu irgendeinem andern Linuxlogger senden kann, statt sie in lokale Dateien zu speichern.
Egal. Unter openSUSE haben wir es heute im wesentlichen mit zwei Programmen zu tun, wenn wir vom Loggen reden.
Einmal die Kernel Logmeldungen und dann die "anderen".
Was ist der Unterschied zwischen Kernel-Logmeldungen und "normalen" Log-Meldungen?
Jede CPU kann "Betriebsfehler" melden und tut das auch ständig. Diese Meldungen betreffen natürlich die CPU selbst, aber auch ALLE sich direkt auf diesem Board befindlichen Geräte. Dort verbaute USB Teile zählen nur sehr bedingt dazu. Aber USB ist eh eine komplett andere Welt. Es ist nicht einmal sicher, ob ein USB- Hub wirklich zum eigentliche Board gehört. Egal. PCI gehört auf jeden Fall dazu. (Und an einen PCI Hub sind alle virtuellen, oder physisch vorhandenen USB-Hubs angebunden -sei es direkt, oder indirekt.)
Die Meldungen der CPU -und somit des Kernels- haben einen Namen. Da es Fehlerzustände im Prozessor und auf dem Motherboard sind, tragen sie den einleuchtenden Namen "Machine Check Exception". Das mcelog ist die moderne Art die Kernellogmeldungen in das gesamte Systemlog zu schreiben. Wir erinnern uns: Das Loggen einer Linuxkiste besteht aus zwei Teilen!
Auf einem modernen openSUSE System läuft IMMER ein mcelog. Ein schlichtes ps ax -o pid,cmd | grep mcelog zeigt das. Und man mcelog erklärt es.
Wer mit mcelog wirklich arbeiten mag, was man wirklich kann, lese auf der Website von mcelog weiter.
Natürlich werden alle Logmeldungen zusammengewürfelt. Es würde anders auch wenig Sinn machen - ist es doch das Ziel in egal welcher Konfiguration ein konsistentes, komplettes Log aller Aktivitäten gleich welcher Natur forensisch sicher zu erhalten. Egal auf welcher Kiste.
Und was sind jetzt die "normalen" Log-Meldungen?
Ganz einfach: alle anderen.
Du kannst als normale Userin selbstverständlich auch in das Systemlog schreiben. Jederzeit. Ein schlichtes logger scheiße, das geht ja! schreibt in das Systemlog genau diesen Satz. Prüfe das, indem du als normaler User in eine Konsole diesen Unsinn eingibst. Wenn du damit fertig bist, gib einfach journalctl -r ein. Et voilà!
-r bewirkt die reverse Ausgabe der Meldungen - wohl die nützlichste und am häufigsten verwendete Option.
Damals, wie heute unter systemd wurden alle Meldungen in das Verzeichniss /var/log geschrieben. Also fast alle. Und das nicht einmal immer. Dass Meldungen dort gespeichert werden, ist lediglich eine Konvention. Nichts und niemand diktiert eine solche Notwendigkeit. Aber es ist natürlich sinnvoll, sich an an solche Konventionen zu halten.
Die Wirklichkeit ist natürlich auch beim Linuxloggen wesentlich komplexer. Und alles kann man konfigurieren, wie man lustig ist. Selbstverständlich kann man auch die Logs einer Maschine auf einem anderen via Netzwerk schreiben. (Ab openSUSE 15 gibt es sogar ein Paket namens systemd-journal-remote, das diese Möglichkeit leicht verwaltbar macht. Für ältere Versionen muss man etwas mehr rumbasteln und einen "alten" Logdienst noch zusätzlich einbinden)
Auch die Rechte sind beim Loggen ein wichtiger Aspekt. Schließlich prallen da Systemdienste, Serverprogramme und Usergeschwätz aufeinander.