Zweiter Nachtrag: ZED überwacht die Gesundheit meines Pools, nicht seinen Bauchumfang

🌐 Auch auf: English · Français · Español

Ein kurzer Nachtrag, direkte Folge des Snapshot-Beitrags. Mit den täglichen Snapshots ist etwas auf diesem NAS eingezogen, das es vorher nicht gab: etwas, das von selbst wächst, leise, für immer, ohne dass es jemand verlangt hätte. Also habe ich nachgesehen, was mir eigentlich Bescheid sagt, wenn der Pool vollläuft. Die Antwort war leicht peinlich.

Table of Contents

🔍 ZED hat zu vielem eine Meinung, nur nicht hierzu

ZED läuft. ZED ist konfiguriert. Genau das habe ich im letzten Nachtrag repariert, und die Reparatur hält:

$ systemctl is-active zed
active

$ grep ZED_EMAIL_ADDR /etc/zfs/zed.d/zed.rc
ZED_EMAIL_ADDR="you@example.com"

Das Problem ist, wofür ZED da ist. ZED reagiert auf Ereignisse – eine Platte fällt aus, Prüfsummenfehler, ein Scrub ist fertig, ein vdev wird degraded. Dinge, die zu einem bestimmten Zeitpunkt passieren und ein klares Vorher und Nachher haben. Ein Pool, der langsam vollläuft, ist nichts davon. Es gibt kein Ereignis. Kein einzelner Schreibvorgang überschreitet eine Grenze, die ZFS für meldenswert hält. Die Belegung kriecht einfach nach oben, und ZED sagt – völlig korrekt, ganz nach eigenem Design – überhaupt nichts. Letztes Mal gab es den Alarm, er hat nur niemanden erreicht. Diesmal gibt es gar keinen Alarm.

🧊 Warum „lösch halt was“ nicht mehr der Notausgang ist, der es mal war

Unter ext4 ist eine volle Platte lästig. Unter ZFS ist es schlimmer, aus zwei Gründen, die sich gegenseitig verstärken. Erstens bricht die Schreibleistung spürbar ein, sobald du über etwa 80 % bist – der Allocator muss sich mehr anstrengen, um zusammenhängenden Platz zu finden, und das merkt man. Zweitens, und daran scheitern viele: Löschen kann auf einem komplett vollen Pool fehlschlagen, weil Löschen selbst ein Schreibvorgang ist. Eine Datei zu entfernen heißt, Metadaten zu aktualisieren, und Copy-on-Write heißt: Metadaten aktualisieren bedeutet, einen Block zu allozieren. Keine freien Blöcke, kein Löschen. Und jetzt noch Snapshots obendrauf. Wie im Snapshot-Beitrag beschrieben, gibt das Löschen einer Datei, auf die ein Snapshot noch verweist, exakt gar nichts frei:

storage/demo   USED: 200M   REFER: 128K

REFER ist das, was im Live-Verzeichnis liegt: praktisch nichts. USED ist das, was das Dataset tatsächlich belegt, weil ein Snapshot die Blöcke festhält. Der instinktive Rettungsversuch – Platz schaffen, indem man Zeug löscht – bringt auf einem Dataset mit Snapshots also gar nichts und läuft auf einem wirklich vollen Pool womöglich nicht einmal durch. Eine Kombination, die man lieber nicht live entdeckt.

🛠️ Fünf Zeilen und ein Timer

Der Check selbst ist unspektakulär, und genau darum geht es:

#!/bin/bash
# /usr/local/sbin/zfs-capacity-check.sh
set -euo pipefail
WARN="${1:-80}"

RECIPIENT="$(grep -hE '^ZED_EMAIL_ADDR=' /etc/zfs/zed.d/zed.rc 2>/dev/null 
\
    | head -1 | cut -d= -f2- | tr -d '"' | xargs)"
[ -n "$RECIPIENT" ] || exit 0

problems=""
while read -r pool cap; do
    num="${cap%\%}"
    [ "$num" -ge "$WARN" ] || continue
    problems="${problems}Pool '${pool}' is ${cap} full (threshold: ${WARN}%).
"
done < <(zpool list -H -o name,capacity)

[ -n "$problems" ] || exit 0
# ... assemble report, pipe into mail ...

Zwei kleine Entscheidungen, die eine Erwähnung wert sind. Der Empfänger wird aus zed.rc gelesen statt hartkodiert. Es gibt auf dieser Kiste bereits genau eine Stelle, an der konfiguriert ist, „wer Bescheid bekommt, wenn der Speicher Ärger macht“, und eine zweite hinzuzufügen ist der sichere Weg dahin, dass die beiden in sechs Monaten still auseinanderlaufen. Und die Mail sagt nicht nur „Pool ist voll“. Sie listet die größten Snapshots auf, denn auf einer ZFS-Kiste mit automatischen Snapshots ist das mit überwältigender Mehrheit die Antwort auf „Wo ist mein Platz hin?“ – und die Nachricht, die um 3 Uhr nachts eintrudelt, sollte die Antwort enthalten, nicht nur die Frage. Der Timer ist genauso gebaut wie die Snapshot-Timer: täglich, Persistent=true, zufällige Verzögerung.

✅ Das Ding testen, das mich warnen soll

Der letzte Nachtrag endete mit einer Komponente, deren einziger Job das Alarmschlagen war und die still versagt hat. In dieselbe Falle tappe ich nicht zweimal. Statt also einem Check zu vertrauen, der bei einem Pool mit 49 % korrekt „alles in Ordnung“ meldet, habe ich die Schwelle so weit gesenkt, bis er auslösen musste:

$ /usr/local/sbin/zfs-capacity-check.sh 40
$ tail -2 /var/log/msmtp.log
Sep 02 21:19:09 host=smtp.strato.de ... recipients=you@example.com
                smtpstatus=250 exitcode=EX_OK
Sep 11 14:47:14 host=smtp.strato.de ... recipients=you@example.com
                mailsize=861 smtpstatus=250 exitcode=EX_OK

Mail angenommen, 250, EX_OK. Die ganze Kette funktioniert: Skript, mail, msmtp, Strato, zugestellt. Und schau dir die Zeile darüber an. 2. September – das ist die ZED-Testnachricht aus dem vorigen Nachtrag, direkt im selben Log. Zwei Alarmwege, neun Tage auseinander, beide auf dieselbe Art geprüft, aus demselben Grund.

Die Moral von der Geschicht‘

Ein Monitoring-Tool erzählt dir von den Ausfällen, die sich seine Entwickler vorstellen konnten. ZED stellt sich sterbende Platten vor, und darin ist es hervorragend. Es stellt sich nicht vor, wie dein Pool über achtzehn Monate gemächlich vollläuft, denn das ist kein Ereignis – es ist die Abwesenheit eines Ereignisses. Und das ist das Unangenehme an Monitoring ganz allgemein: Was es abdeckt, entscheidet derjenige, der es geschrieben hat, und was es nicht abdeckt, erzeugt exakt dieselbe Ausgabe wie „alles in Ordnung“. Stille. Es lohnt sich, ab und zu zu fragen, was dein Monitoring dir prinzipbedingt gar nicht sagen kann. Nicht, was es zu melden versäumt – sondern wofür es nie gebaut wurde.