Protokolle: das Einzige, was wächst, ohne dass es jemand beschlossen hat

Das meiste, was deine Platte füllt, hast du hinzugefügt: virtuelle Maschinen, Sicherungen, Installationsabbilder. Jedes davon war eine Entscheidung.

Protokolle sind anders. Sie wachsen, weil das System läuft. Niemand hat je gesagt "diese Datei soll größer werden".

Das Wachstum ist langsam, aber unbegrenzt

Eine Protokolldatei wächst vielleicht um ein paar Kilobyte am Tag. Das fällt monatelang nicht auf. Ein Jahr später ist sie immer noch klein.

Doch sie hat keine Obergrenze. Und Wachstum ohne Obergrenze wird, wie langsam auch immer, zum Problem, wenn du lange genug wartest.

Der Multiplikator, den niemand erwartet: ein Fehler beschleunigt das Schreiben

Das ist der eigentliche Punkt des Artikels.

Ein gesundes System schreibt wenig. Meldet eine Prüfung bei jedem Lauf einen Fehler, fällt bei jedem Lauf eine Zeile in dieselbe Datei. Bei einem Auftrag, der alle fünfzehn Minuten läuft, sind das sechsundneunzig Zeilen am Tag, und es hört nicht auf.

Das Protokoll wächst also am schnellsten genau dann, wenn du am wenigsten hinsehen kannst: während ein Ausfall läuft.

Und die schlimmste Fassung davon

Ein Problem tritt auf, die Protokolle beschleunigen, die Platte läuft voll. Die volle Platte verursacht neue Probleme. Die neuen Probleme erzeugen mehr Protokolle.

Ab da wird es schwerer, den ursprünglichen Fehler zu finden, denn die meisten Fehler auf deinem Bildschirm sind nicht die Folge des ersten Problems, sondern der vollen Platte.

Die Regel: alles, was schreibt, braucht eine Obergrenze

"Wir räumen später auf" ist kein Plan. Gebraucht wird eine mechanische Grenze, die läuft, ohne dass jemand sich erinnern muss.

Diese Regel gilt nicht nur für Systemprotokolle: sie gilt für jede Datei, die von deinen Diensten, von geplanten Aufträgen und von Sammlern erzeugt wird.

Zwei Fehler beim Einrichten der Rotation

Erstens: die Regel bricht an einer Datei, die es nicht gibt. Manche Dateien entstehen erst, wenn die zugehörige Funktion genutzt wird. Die Regel muss so geschrieben sein, dass sie bei fehlender Datei keinen Fehler wirft; sonst bringt eine nie genutzte Funktion die gesamte Rotation zum Erliegen.

Zweitens: die falsche Rotationsmethode. Die Datei umzubenennen und dem schreibenden Dienst ein "wieder öffnen" zu signalisieren ist die übliche Methode, funktioniert aber nur, wenn es einen langlebigen Dienst gibt. Ist der Schreiber ein kurzlebiger Auftrag, der jedes Mal öffnet und schließt, gibt es niemanden zu signalisieren; dann ist es richtig, den Inhalt zu kopieren und die Datei an Ort und Stelle zu leeren.

Beides sind stille Fehler: die Regel steht, die Datei wächst weiter, und niemand merkt, dass die Regel nicht wirkt.

Und die Frage der bereits installierten Maschine

Schreibst du eine Rotationsregel nur ins Installationsskript, erreicht sie Maschinen, die vor der Regel installiert wurden, nie. Diese Maschinen laufen jahrelang ohne sie.

Richtig ist, die Regel bei jedem Start zu schreiben: so bekommen ältere Installationen sie, wenn sie auf eine neue Version wechseln.

Was Atlas tut

Dieser ganze Artikel stammt aus Atlas' eigener Messung, deshalb muss er ehrlich erzählt werden.

Atlas läuft auf der Maschine der Kundschaft mit Rootrechten und schreibt in mehrere Protokolldateien: die Wächterzusammenfassung alle fünfzehn Minuten, die Ausgabe geplanter Aktualisierungen bei jedem Lauf, den eigenen Selbstaktualisierungseintrag. Es wurde gemessen, und keine davon wurde rotiert, denn die Installation schrieb nirgends eine Rotationsregel. Auf einer laufenden Maschine hatte das Wächterprotokoll in zweiunddreißig Tagen einhundertachtzig Kilobyte erreicht, und es gab keinen Mechanismus, es zu verkleinern.

Die Zahl wirkt klein, und an jenem Tag war sie kein Problem. Ein Problem war, dass das Wachstum unbegrenzt war, dazu die oben beschriebene Beschleunigung. Die Protokolle geplanter Aktualisierungen fangen bei jedem Lauf die gesamte Ausgabe des Paketverwalters ein, was pro Lauf in die Megabyte gehen kann.

Nun wird die Regel geschrieben, und beide obigen Fallen sind bewusst behandelt: fehlende Dateien werden geduldet, und die Rotation nutzt die Methode kopieren und dann leeren, weil die Schreiber kurzlebige Prozesse aus einem geplanten Auftrag sind.

Und die Regel wird beim Start geschrieben, nicht im Installationsskript. Der Grund ist genau die obige Frage: damit auch früher installierte Maschinen die Regel bekommen, wenn sie auf eine neue Version wechseln.