Sind diese "Sonderwege" denn tatsächlich nötig und nicht nur möglich?
1. Wenn Sie das Lesen der Logs mittels gängiger Unix-Werkzeuge meinen, so sei gesagt, dass es Pipes schon relativ lange gibt und das ist auch kein Teufelszeug. Dadurch kann man die gewohnten zeilenorientierten und textzeichbierenden Verarbeitungs- und Filterwerkzeuge von byte streams verwenden.
Aus rein informationstechnischer Sicht können strukturierte Daten aber abhängig vom konkreten Fall auch enorme Vorteile bei der Suche und Analyse ggü. etwa klassischen zeilenorientierten Formaten aufweisen.
Und falls ein journalctl+Pipe nicht gewünscht ist, so kann man selbst mit systemd (systemd-journald) weiterhin das Log vom Werkzeug der Wahl erstellen lassen. Einfach rsyslogd etc. installieren und die Logs weiterleiten. Da werden ganz klassisch unstrukturierte Textdateien abgelegt, die mit den traditionellen Werkzeugen allein (d.h. ohne ein journalctl+Pipe) untersucht werden können. Problem gelöst.
2. Zur Übertragung von Logs stehen mit systemd-journald mWn mehr Möglichkeiten zur Verfügung als ohne, denn alle bisherigen Methoden sollten auch weiterhin funktionieren - ggf. nach einer Installation des gewünschten Log-Werkzeugs und einer Weiterleitung der Logs an dieses. An welche Methode der Übertragung, die mit systemd-journald nur noch über "Sonderwege" funktioniert, hatten Sie hierbei gedacht? Ist die Installation eines rsyslogd, ggf. samt Konfiguration der Weiterleitung von journald, bereits so ein "Sonderweg"? Und das würde ja nur Neusysteme bzw. Major-Revision-Upgrades betreffen, oder?
3. Mit Analyse von aussen meinen Sie die Analyse mittels eines Zweitsystems? Ist das nicht einfach nur ein spezieller Fall des Lesens der Logs? Man braucht natürlich eine hinreichend aktuelle Version von systemd. Soweit ich weiß, hat sich das Binärformat der Logs von systemd-journald in den letzten Jahren nicht so stark verändert, sodass verschiedene Versionen kompatibel sein müssten.
Außerdem sollte es immer auch noch ein Rescue-System im initramfs mit der selben Version geben. Und wenn selbst das Rescue-System nicht nutzbar ist, hat man gleich noch ganz andere Probleme.
Zudem wäre besteht dieses Problem nach einer erfolgreichen Übertragung der Logs gar nicht. Man analysiere einfach die übertragenen Logs statt der lokalen auf direktem Weg.
4. Was meinen Sie mit Analyse auf defekten Dateisystemen genau? Ein korruptes Dateisystem ist korrupt. Da hilft auch nicht der beste Logger oder die besten Unix-Werkzeuge.
Oder können "less/grep etc pp" korrupte Dateisysteme reparieren und einbinden? Das wäre mir neu und würde für mich an Magie grenzen.
Und welche von diesen Werkzeugen stünden mit systemd-journald nicht mehr zur Verfügung? Welche Wege kann man damit nicht mehr gehen? Welche "Sonderwege" müsste man dort gehen?
Ich halte ein korruptes Dateisystem für ein völlig getrenntes Problem zur Analyse von Logs. Das liegt mindestens ein Schicht tiefer. Das auf den Unterschied von Text-/Binärlogs zu schieben, ist ungerechtfertigt.
Sind diese "Sonderwege" denn tatsächlich nötig und nicht nur möglich?
1. Wenn Sie das Lesen der Logs mittels gängiger Unix-Werkzeuge meinen, so sei gesagt, dass es Pipes schon relativ lange gibt und das ist auch kein Teufelszeug. Dadurch kann man die gewohnten zeilenorientierten und textzeichbierenden Verarbeitungs- und Filterwerkzeuge von byte streams verwenden.
Aus rein informationstechnischer Sicht können strukturierte Daten aber abhängig vom konkreten Fall auch enorme Vorteile bei der Suche und Analyse ggü. etwa klassischen zeilenorientierten Formaten aufweisen.
Und falls ein journalctl+Pipe nicht gewünscht ist, so kann man selbst mit systemd (systemd-journald) weiterhin das Log vom Werkzeug der Wahl erstellen lassen. Einfach rsyslogd etc. installieren und die Logs weiterleiten. Da werden ganz klassisch unstrukturierte Textdateien abgelegt, die mit den traditionellen Werkzeugen allein (d.h. ohne ein journalctl+Pipe) untersucht werden können.
Problem gelöst.
2. Zur Übertragung von Logs stehen mit systemd-journald mWn mehr Möglichkeiten zur Verfügung als ohne, denn alle bisherigen Methoden sollten auch weiterhin funktionieren - ggf. nach einer Installation des gewünschten Log-Werkzeugs und einer Weiterleitung der Logs an dieses.
An welche Methode der Übertragung, die mit systemd-journald nur noch über "Sonderwege" funktioniert, hatten Sie hierbei gedacht? Ist die Installation eines rsyslogd, ggf. samt Konfiguration der Weiterleitung von journald, bereits so ein "Sonderweg"? Und das würde ja nur Neusysteme bzw. Major-Revision-Upgrades betreffen, oder?
3. Mit Analyse von aussen meinen Sie die Analyse mittels eines Zweitsystems? Ist das nicht einfach nur ein spezieller Fall des Lesens der Logs? Man braucht natürlich eine hinreichend aktuelle Version von systemd. Soweit ich weiß, hat sich das Binärformat der Logs von systemd-journald in den letzten Jahren nicht so stark verändert, sodass verschiedene Versionen kompatibel sein müssten.
Außerdem sollte es immer auch noch ein Rescue-System im initramfs mit der selben Version geben. Und wenn selbst das Rescue-System nicht nutzbar ist, hat man gleich noch ganz andere Probleme.
Zudem wäre besteht dieses Problem nach einer erfolgreichen Übertragung der Logs gar nicht. Man analysiere einfach die übertragenen Logs statt der lokalen auf direktem Weg.
4. Was meinen Sie mit Analyse auf defekten Dateisystemen genau? Ein korruptes Dateisystem ist korrupt. Da hilft auch nicht der beste Logger oder die besten Unix-Werkzeuge.
Oder können "less/grep etc pp" korrupte Dateisysteme reparieren und einbinden? Das wäre mir neu und würde für mich an Magie grenzen.
Und welche von diesen Werkzeugen stünden mit systemd-journald nicht mehr zur Verfügung? Welche Wege kann man damit nicht mehr gehen? Welche "Sonderwege" müsste man dort gehen?
Ich halte ein korruptes Dateisystem für ein völlig getrenntes Problem zur Analyse von Logs. Das liegt mindestens ein Schicht tiefer. Das auf den Unterschied von Text-/Binärlogs zu schieben, ist ungerechtfertigt.