So verhindern Sie, dass die Home-Assistant-Protokolle die Systemfestplatte füllen

Verhindern Sie, dass Home-Assistant-Logs die Festplatte füllen, indem Sie zuerst die genau wachsende Datei identifizieren, das wiederkehrende Ereignis beheben und die Aufbewahrung auf der Ebene konfigurieren, der das jeweilige Log gehört.

Auf einem kleinen Heimserver können Home-Assistant-Core-Logs, Docker-Logs, Supervisor- oder Add-on-Logs und das Journal des Hosts denselben Systemdatenträger belasten, wobei jeweils andere Maßnahmen erforderlich sind. Messen Sie das Wachstum über ein kurzes, kontrolliertes Zeitfenster, bewahren Sie genügend Belege auf, um den Verursacher zu identifizieren, verwenden Sie umkehrbare Begrenzungen und stoppen Sie nicht erforderliche Schreibvorgänge, wenn der verbleibende Speicherplatz für einen sicheren Neustart oder ein Backup zu gering ist.

Identifizieren, welches Log Speicherplatz verbraucht

Notieren Sie zunächst den insgesamt freien Speicherplatz und listen Sie dann die größten Dateien und Verzeichnisse auf dem betroffenen Dateisystem auf, ohne etwas zu löschen. Vergleichen Sie die Größen nach fünf bis zehn Minuten erneut, während Home Assistant normal läuft. Die Datei, deren Größe sich verändert, ist aussagekräftiger als eine statische Liste alter großer Dateien.

Fälle mit Home Assistant zeigen, dass die Speichererschöpfung aus verschiedenen Ebenen stammen kann, einschließlich System-Logs und nicht nur der Recorder-Datenbank. In einer gelösten Diskussion wurde das Wachstum auf das systemd-Journal zurückgeführt. Die erste Unterscheidung lautet daher welches Verzeichnis weiter wächst, nicht ob Home Assistant beschäftigt wirkt.

Wenn ein Core-Log wächst, untersuchen Sie die wiederholte Komponente und Nachricht. Wenn Docker-JSON-Logs wachsen, prüfen Sie den Log-Treiber des Containers. Wenn das Journal wächst, untersuchen Sie den Dienst, der die Meldungen ausgibt. Ist der freie Speicherplatz bereits kritisch knapp, stoppen Sie den lautesten nicht erforderlichen Container oder Home Assistant selbst, bevor weitere Schreibvorgänge die Wiederherstellung erschweren.

Beheben Sie wiederholte Fehler, bevor Sie die Sichtbarkeit reduzieren

Zählen Sie die vorherrschende Nachricht und gleichen Sie ihre Zeitstempel mit einem Gerät, einer Integration, einer Automation, einem Add-on oder einem Netzwerkereignis ab. Eine tausendfach wiederholte Warnung hat in der Regel mehr präventiven Nutzen als Dutzende voneinander unabhängige Einträge. Speichern Sie vor Änderungen ein kurzes Beispiel mit Version und Auslöser.

Ein Problem im Home-Assistant-Core dokumentierte einen Tradfri-Fehler, der ein Log auf über 10 GB anwachsen ließ und den Systemdatenträger füllte. Dies ist ein versionsabhängiges Beispiel dafür, dass eine Integration ein Log überfluten kann. Es spricht dafür, den Verursacher zu isolieren, nicht automatisch anzunehmen, dass Tradfri oder die Rotation immer die Ursache ist.

Deaktivieren Sie die Debug-Protokollierung, sobald die Aufzeichnung abgeschlossen ist, und laden Sie nur die bestätigte laute Integration neu oder deaktivieren Sie sie. Wiederholen Sie anschließend den ursprünglichen Auslöser. Wenn die Nachrichtenrate stark zurückgeht, reparieren Sie diese Integration oder ihre Abhängigkeit. Falls dies nicht geschieht, stellen Sie die Einstellung wieder her und wenden Sie sich dem nächsten verifizierten Verursacher zu, statt alle Warnungen zu unterdrücken.

Konfigurieren Sie die Aufbewahrung auf der Ebene, der das Log gehört

Legen Sie separate begrenzte Richtlinien für das Journal des Hosts, den Docker-Log-Treiber, den Reverse-Proxy und andere Add-ons fest. Eine Logger-Stufe des Cores begrenzt nicht den Speicher des systemd-Journals, und eine Docker-Größenoption rotiert keine Datei, die direkt in ein eingebundenes Konfigurationsverzeichnis geschrieben wird.

Wählen Sie Grenzen, die genügend Verlauf für den Zeitraum zwischen den Prüfungen aufbewahren und gleichzeitig Platz für Backups, Updates, Datenbankarbeiten und die Wiederherstellung lassen. Der zugehörige ZimaSpace-Artikel über freien Speicherplatz in Home Assistant erklärt, warum das Aufbrauchen der letzten Reserve Vorgänge beeinträchtigen kann, die vorübergehend zusätzlichen Speicherplatz benötigen.

Dokumentieren Sie jede Richtlinie in der Konfiguration, die eine Neuerstellung übersteht. Starten Sie nur den betroffenen Dienst neu oder erstellen Sie ihn neu, bestätigen Sie, dass die Einstellung aktiv ist, und halten Sie den vorherigen Wert für ein Zurücksetzen bereit. Verwenden Sie keine regelmäßig geplante pauschale Löschung als Ersatz für die Suche nach einem ungewöhnlichen Verursacher.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Überprüfen Sie, dass das Wachstum unter dem ursprünglichen Auslöser begrenzt bleibt

Reproduzieren Sie das Ereignis, das die Flut verursacht hat, etwa wenn ein Gerät offline geht, eine Integration wiederholt versucht, ein Backup läuft oder ein Netzwerkausfall auftritt. Verfolgen Sie die Größe derselben Datei, die Nachrichtenrate, den freien Speicherplatz, den Zustand des Dienstes und die Reaktion der Automation länger als über das vorherige Wachstumszeitfenster.

Ein erfolgreiches Ergebnis zeigt einen stabilen oder rotierenden Log-Footprint, den Erhalt der erforderlichen Diagnoseinformationen, normale Verlaufsschreibvorgänge und ausreichend freien Speicherplatz für das nächste Backup und Update. Starten Sie den Host einmal neu und wiederholen Sie den Auslöser, damit die Begrenzungen auch nach der Neuerstellung des Dienstes überprüft sind.

Setzen Sie eine Änderung der Aufbewahrung zurück, wenn dadurch die für die Diagnose eines anhaltenden Fehlers erforderlichen Belege entfernt werden. Eskalieren Sie den Fall mit der wiederholten Nachricht, der ausgebenden Komponente, der Version, der Wachstumsrate und dem Speicherpfad, wenn sich das Log weiter vergrößert, nachdem die bestätigte Quelle isoliert wurde. Stoppen Sie die Schreibvorgänge erneut, wenn sich der Datenträger der vollständigen Auslastung nähert.