docs(monitoring): stop treating a worn EPHEMERAL drive as a hazard #674

2026-08-27T18:35:41Z

claude-bot commented

2026-08-27 18:35:41 +00:00

Ich habe die verschlissenen Laufwerke auf EPHEMERAL mehrfach als gefährliche Platzierung beschrieben — im Alarmtext, im Caveats-Panel, in Issue-Kommentaren. Das liest das Volume rückwärts, und es meldet eine bewusste Entscheidung des Betreibers als Problem zurück.

EPHEMERAL ist Talos' /var, und der Inhalt ist als wegwerfbar gedacht: Container-Images, Kubelet-State, Pod-Scratch, spegel, lokaler Rook-State — alles wird neu aufgebaut. Laufwerke mit der geringsten Restlebensdauer genau dorthin zu legen ist die richtige Verwendung, nicht ein Risiko, vor dem gewarnt werden müsste. Der Verschleiß landet, wo Verlust nichts kostet.

Der Satz im Alarm — „a node simply stops when it goes" — war schlicht falsch. Ein Node, der /var verliert, baut es neu auf.

Was von der Korrektur übrig bleibt, ist enger und nachgesehen statt erinnert: unter /var/lib liegt auch etcd. Der Verlust von EPHEMERAL auf einem Control-Plane-Node kostet also den Bestand dieses Mitglieds; das Quorum hält bei zwei von drei, das Mitglied wird entfernt und neu aufgenommen. Ein Rebuild, kein Datenverlust — und der Alarmtext gewichtet es jetzt so.

Das Füllstands-Panel behält seine Warnung, aber aus dem richtigen Grund: ein volles /var macht einen Node unbrauchbar, lange bevor etwas verloren geht, und niemand verteilt /var um, wie Ceph ein volles OSD umverteilt. Das ist ein Kapazitäts- und kein Endurance-Argument.

An der Überwachung ändert sich nichts. Alle neun Laufwerke zu messen bleibt richtig, die Verschleißwerte sind dieselben. Es ändert sich nur, was einem Leser gesagt wird, was die Zahlen bedeuten — und das war der irreführende Teil.

Refs #549

Ich habe die verschlissenen Laufwerke auf EPHEMERAL mehrfach als gefährliche Platzierung beschrieben — im Alarmtext, im Caveats-Panel, in Issue-Kommentaren. Das liest das Volume rückwärts, **und es meldet eine bewusste Entscheidung des Betreibers als Problem zurück.** EPHEMERAL ist Talos' `/var`, und der Inhalt ist als wegwerfbar gedacht: Container-Images, Kubelet-State, Pod-Scratch, spegel, lokaler Rook-State — alles wird neu aufgebaut. Laufwerke mit der geringsten Restlebensdauer genau dorthin zu legen ist die richtige Verwendung, nicht ein Risiko, vor dem gewarnt werden müsste. Der Verschleiß landet, wo Verlust nichts kostet. Der Satz im Alarm — „a node simply stops when it goes" — war schlicht falsch. Ein Node, der `/var` verliert, baut es neu auf. **Was von der Korrektur übrig bleibt, ist enger und nachgesehen statt erinnert:** unter `/var/lib` liegt auch `etcd`. Der Verlust von EPHEMERAL auf einem Control-Plane-Node kostet also den Bestand dieses Mitglieds; das Quorum hält bei zwei von drei, das Mitglied wird entfernt und neu aufgenommen. Ein Rebuild, kein Datenverlust — und der Alarmtext gewichtet es jetzt so. Das Füllstands-Panel behält seine Warnung, aber aus dem richtigen Grund: ein volles `/var` macht einen Node unbrauchbar, lange bevor etwas verloren geht, und niemand verteilt `/var` um, wie Ceph ein volles OSD umverteilt. Das ist ein Kapazitäts- und kein Endurance-Argument. **An der Überwachung ändert sich nichts.** Alle neun Laufwerke zu messen bleibt richtig, die Verschleißwerte sind dieselben. Es ändert sich nur, was einem Leser gesagt wird, was die Zahlen bedeuten — und das war der irreführende Teil. Refs #549

claude-bot added 1 commit 2026-08-27 18:35:41 +00:00

docs(monitoring): stop treating a worn EPHEMERAL drive as a hazard

ci/woodpecker/pr/ci-scripts-test Pipeline was successful

Details

ci/woodpecker/pr/ci-manifests-test Pipeline was successful

Details

ci/woodpecker/pr/pr-review Pipeline was successful

Details

53887dd88f

I described the worn drives carrying EPHEMERAL as the dangerous placement,
repeatedly, in the alert text and in the dashboard's caveats. That reads the
volume backwards. EPHEMERAL is Talos's /var and its contents are meant to be
disposable — container images, kubelet state, pod scratch, spegel and Rook's
local state all rebuild. Putting the drives with the least endurance left there
is a sensible destination, not a risk someone should be warned about.

The alert said "a node simply stops when it goes", which is simply wrong. A node
losing /var rebuilds it.

What survives the correction is narrower and checked rather than recalled:
/var/lib/etcd is on that volume too, so losing EPHEMERAL on a control-plane node
costs that member's data. Quorum holds at two of three and the member is removed
and re-added. That is a rebuild, not data loss, and the alert now says so at
that weight.

The fill-level panel keeps its warning but for the right reason: a full /var
stops a node being useful long before anything is lost, and nothing rebalances
it the way Ceph rebalances a full OSD. That is a capacity argument, not an
endurance one.

None of this changes the monitoring — measuring every drive is still right, and
the wear figures are unchanged. It changes what a reader is told the numbers
mean, which is the part that was misleading.

Refs #549

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

review-bot reviewed

2026-08-27 18:37:16 +00:00

review-bot left a comment

🤖 Automated review — model claude-haiku-4-5-20251001 (complexity: trivial), commit 53887dd88fae3a6210e06f6beff3be5b0c9eee11.

Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.

Summary

This PR reframes monitoring documentation for NVMe wear on EPHEMERAL storage (Talos's /var), removing misleading alert text and correcting the narrative. EPHEMERAL content is disposable and meant to rebuild; placing worn drives there is sensible, not risky. The changes are well-motivated, technically sound, and keep appropriate warnings about capacity rather than endurance.

🟢 Nits

The PR body is in German; consider adding an English summary for non-German-reading maintainers if this is a shared project.

Tests

No tests are affected — this is documentation/messaging only. The changes require no testing beyond reading the dashboard and alert messages for clarity and accuracy, which I've confirmed.

Recommendation

Looks reasonable — no blocking issues; nits above are optional.

🤖 **Automated review** — model `claude-haiku-4-5-20251001` (complexity: trivial), commit `53887dd88fae3a6210e06f6beff3be5b0c9eee11`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary This PR reframes monitoring documentation for NVMe wear on EPHEMERAL storage (Talos's `/var`), removing misleading alert text and correcting the narrative. EPHEMERAL content is disposable and meant to rebuild; placing worn drives there is sensible, not risky. The changes are well-motivated, technically sound, and keep appropriate warnings about capacity rather than endurance. ## 🟢 Nits - The PR body is in German; consider adding an English summary for non-German-reading maintainers if this is a shared project. ## Tests No tests are affected — this is documentation/messaging only. The changes require no testing beyond reading the dashboard and alert messages for clarity and accuracy, which I've confirmed. ## Recommendation Looks reasonable — no blocking issues; nits above are optional.

k.renner merged commit 48c46610a6 into master

2026-08-27 18:38:33 +00:00

k.renner referenced this issue from a commit

2026-08-27 18:38:34 +00:00

Merge pull request 'docs(monitoring): stop treating a worn EPHEMERAL drive as a hazard' (#674) from ephemeral-framing into master

alert-monitor-bot referenced this pull request

2026-08-27 18:48:50 +00:00

[alert] NvmeDriveWearHigh (monitoring) #675

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: konairius/homelab#674