In der Nacht ist etwas passiert: wo die Aufzeichnung tatsächlich liegt
Eine Meldung sagt Ihnen, dass etwas passiert ist. Ein Protokoll sagt Ihnen, warum. Der Haken: Die Aufzeichnung, die Sie am dringendsten brauchen, umfasst genau die Minute, in der die Maschine starb, und bei einer Standardinstallation fehlt ausgerechnet die am ehesten.
AtlasPVE ·
Dieser Eintrag beantwortet
- proxmox log nach absturz
- proxmox logdateien speicherort
- proxmox task log speicherort
- proxmox syslog speicherort
- proxmox logs after crash
Die Maschine hat in der Nacht neu gestartet, und niemand hat sie darum gebeten. Alles läuft wieder, nichts ist offensichtlich kaputt, und der einzige ehrliche Satz lautet: es ist etwas passiert.
Überwachung hat drei Aufzeichnungen, und sie beantworten drei verschiedene Fragen. Eine Meldung sagt, dass etwas passiert ist. Eine Metrik sagt, welche Form es hatte. Ein Protokoll sagt, warum. Dieser Text handelt von der dritten, und von der unbequemen Tatsache, dass ausgerechnet das Protokoll über die interessante Minute am ehesten fehlt.
Die erste Frage ist kleiner, als man denkt
Vor allen Hardwaretheorien stellen Sie die billigste verfügbare Frage: wurde sie heruntergefahren, oder ist sie gestorben?
Eine einzige Zeile beantwortet das. Ein sauberes Herunterfahren hinterlässt am Ende des vorherigen Systemstarts eine Signatur: Der Protokolldienst hält fest, dass er zum Beenden aufgefordert wurde, und hält dann fest, dass er beendet ist. Eine Maschine, der der Strom wegbleibt, hinterlässt gar kein Ende. Die Aufzeichnung bricht mitten in gewöhnlicher Aktivität ab.
Diese eine Unterscheidung halbiert die ganze Untersuchung. Ein sauberes Ende heißt, dass etwas den Neustart beschlossen hat, also suchen Sie den Auftraggeber: ein Update, ein Watchdog, ein geplanter Job, ein Mensch. Kein Ende heißt, die Maschine wurde unterbrochen, also schauen Sie auf Strom, Wärme, Speicher und den Datenträger darunter.
Aber nur, wenn der vorherige Start überhaupt noch existiert
Hier liegt die Falle. Das Journal bewahrt Verlauf nur dann dauerhaft auf, wenn ein bestimmtes Verzeichnis auf der Platte existiert. Fehlt es, lebt das Journal im Arbeitsspeicher, und jeder Neustart löscht genau die Beweise, wegen derer Sie gekommen sind. Es gibt keinen Fehler und keine Warnung; Sie fragen nach dem vorherigen Start und bekommen zur Antwort, dass es keinen gibt.
Das prüft man besser an einem ruhigen Nachmittag als an dem Morgen, an dem man es braucht. Es ist ein Verzeichnis, und es entscheidet darüber, ob Sie eine Aufzeichnung haben oder nur glauben, eine zu haben.
Es ist außerdem dieselbe Form wie eine Falle, die zweimal benannt werden sollte: ein Aufzeichner, der das Schicksal des Aufgezeichneten teilt. Die Kurve, die Sie am dringendsten wollen, ist die, die in dem Moment aufhörte geschrieben zu werden, als es interessant wurde; und das Protokoll, das Sie am dringendsten wollen, gehört zu dem Start, den es nicht mehr gibt.
Die Datei, die das halbe Internet Ihnen empfiehlt, ist vielleicht nicht da
Auf einer aktuellen Installation gemessen, Proxmox VE 9.2.6 auf Debian 13.6: Der klassische Systemprotokolldienst ist nicht installiert, und /var/log/syslog existiert nicht.
Das wiegt schwerer, als es klingt. Ein großer Teil der Ratschläge zur Fehlersuche aus den letzten fünfzehn Jahren beginnt mit "schauen Sie in /var/log/syslog". Auf einer aktuellen Maschine liefert dieser Befehl nichts, und für jemanden unter Druck liest sich das Ergebnis als *ich habe keine Protokolle* statt als *ich schaue an der falschen Stelle*. Die Systemaufzeichnung ist heute das Journal, und man öffnet es nicht in einem Editor, man fragt es ab.
Proxmox führt eine zweite Aufzeichnung, und die beantwortet eine andere Frage
Getrennt vom Systemjournal führt Proxmox VE ein eigenes Aufgabenprotokoll. Jeder über die Weboberfläche oder die API gestartete Vorgang wird zu einer Aufgabe mit Kennung, Startzeit, Endzeit und Endstatus, und neben den einzelnen Aufgabendateien liegt eine Indexdatei. Auf einem einzelnen Laborhost enthielt dieser Index 283 Zeilen, dahinter rund 960 Aufgabendateien.
Die beiden Aufzeichnungen sind in Verschiedenem gut. Das Journal ist gut in "was tat das System". Das Aufgabenprotokoll ist gut in "wer hat was verlangt, und wurde es fertig". Wenn eine virtuelle Maschine einen Snapshot hat, an dessen Erstellung sich niemand erinnert, oder eine Änderung ohne Urheber auftaucht, antwortet das Aufgabenprotokoll meist schneller als das Journal, denn es ist eine Liste von Absichten und kein Strom von Ereignissen.
Legen Sie die Obergrenze fest, bevor Sie den Verlauf brauchen
Standardmäßig wird die Grenze des Journals als Anteil des Dateisystems ausgedrückt und nicht als Zeitspanne. Auf dem oben gemessenen Host war keine ausdrückliche Grenze gesetzt, und das Journal war auf etwa 276 MB gewachsen.
Zwei Zahlen sollte man vorher kennen: wie viel Platz das Journal belegen darf, und wie weit zurück das auf dieser Maschine tatsächlich reicht. Die Reihenfolge zählt, und es ist dieselbe wie bei Metriken. Entscheiden Sie, wie weit zurück Sie sehen müssen, und wählen Sie dann die Einstellung, die so weit reicht. Die Antwort mitten im Vorfall zu erfahren heißt zu erfahren, dass sie "nicht weit genug" lautet.
Was Atlas tut und was nicht
Atlas ersetzt das Journal nicht und versucht nicht, Ihre Protokolle für Sie zu lesen. Es gibt hier keine Protokollsuche, und etwas anderes zu behaupten würde Ihnen einen schlechten Morgen bereiten.
Was Atlas trägt, ist die erste Hälfte: Die Tageszusammenfassung meldet einen ungeplanten Neustart als Tatsache, mit Maschine und Uhrzeit, damit die Frage überhaupt gestellt wird. Das Lesen bleibt Ihre Aufgabe, und die Antwort wohnt weiterhin im Journal.
Genau darum geht es. Die schlimmste Version der letzten Nacht ist nicht der Neustart, den Sie mit der falschen Datei untersucht haben. Es ist der Neustart, den niemand bemerkt hat, denn eine Aufzeichnung, die nie jemand öffnet, beantwortet gar nichts.
Quellen
Die eigene Dokumentation von Proxmox. Auf Englisch, und sie hat in dieser Sache das letzte Wort.