From f537d9c817df48e63e4fba78e365dcbf77d40acf Mon Sep 17 00:00:00 2001 From: Thore Cimbal Date: Fri, 14 Aug 2026 12:00:00 +0000 Subject: [PATCH] =?UTF-8?q?docs(issues):=20#0030=20=E2=80=94=20alerting=20?= =?UTF-8?q?chain=20complete=20and=20verified=20end=20to=20end?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Records the deployed state: fallback expressions, directory mounts (which proved themselves on the very next rollout, where a SIGHUP reload was genuinely enough), and alertmanager now scraped so delivery failures are visible. Also notes the README correction — delivery had not been muted since gitops#51, and docs saying otherwise would have made a missing alert look expected. Left open deliberately: TrivyScanStale has the same missing-series gap but no natural equivalent to kube_cronjob_created, so it needs a decision rather than a reflex; and phase A/B of the restore drill still needs a throwaway environment. Co-Authored-By: Claude Opus 4.8 --- ...estore-ist-nie-geprobt-sicherungen-sind.md | 31 +++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/docs/issues/0030-der-restore-ist-nie-geprobt-sicherungen-sind.md b/docs/issues/0030-der-restore-ist-nie-geprobt-sicherungen-sind.md index bd0e6d3..19fa1a0 100644 --- a/docs/issues/0030-der-restore-ist-nie-geprobt-sicherungen-sind.md +++ b/docs/issues/0030-der-restore-ist-nie-geprobt-sicherungen-sind.md @@ -274,3 +274,34 @@ sind in der README benannt. ⚠️ **Deploy offen:** `4cb9bfb` ist gepusht, aber noch nicht auf CFGMON aktiv — die Mount-Änderung greift erst, wenn die Container neu erstellt werden (`docker compose up -d` genügt hier, da sich die Service-Definition ändert). + +## Endstand Überwachung 2026-08-15 — Kette durchgängig, verifiziert + +Drei Commits in `threadnet-operating`, alle live und im Betrieb gegengeprüft: + +| Commit | Was | Nachweis | +|---|---|---| +| `e0808ba` | Regel-Ausdrücke mit Fallback (`max by` über `… or kube_cronjob_created`) + `BackupCronJobMissing` | 4 Regeln `health=ok`, Fallback liefert Serien statt Leere | +| `4cb9bfb` | Prometheus/Alertmanager mounten Config-**Verzeichnis** statt Einzeldateien | md5 Host↔Container identisch; beim **nächsten** Rollout genügte erstmals ein echter SIGHUP-Reload — der Fix hat sich sofort bewährt | +| `e9c13dc` | `operating_alertmanager`-Scrape + `AlertDeliveryFailing`; veraltete README-Passage korrigiert | `up{job="operating_alertmanager"}=1`, 14 Regeln `health=ok`, 80 Serien `alertmanager_notifications_failed_total` (alle 0) | + +**Damit ist die Alarmkette lückenlos beobachtet:** Metrik vorhanden (Fallback) → Regel +evaluiert (`health=ok`) → Zustellung sichtbar (`AlertDeliveryFailing`) → Scrape-Ausfall +gedeckt (`TargetDown`). `AlertDeliveryFailing` kann selbst nicht an fehlender Serie +scheitern: der Zähler existiert ab dem ersten Scrape. + +**Nebenkorrektur:** Die README behauptete weiterhin, die Alarm-Zustellung sei per +`room="security"`-Null-Receiver stummgeschaltet. Diese Route existiert seit gitops#51 +nicht mehr — Alarme **werden** zugestellt, auch die neuen Backup-Regeln (kein `room`-Label +→ Default-Route auf den `matrix`-Receiver). Eine Doku, die fälschlich „ist stummgeschaltet" +sagt, hätte ein ausbleibendes Signal als bekannt-und-erwartet erscheinen lassen. + +### Offen (bewusst nicht reflexhaft gelöst) + +- **`TrivyScanStale`** hat dieselbe Lücke wie ursprünglich `RestoreDrillStale`: ein Image, + das **nie** erfolgreich gescannt wurde, hat keine Serie, an der `time() - …` hängen + könnte, und bleibt still. Anders als dort gibt es **kein natürliches Pendant zu + `kube_cronjob_created`** — es bräuchte eine Soll-Liste der erwarteten Images. Das ist eine + Entscheidung, kein Handgriff; gehört fachlich zu #0025/CVE-Pipeline. +- **Phase A/B des Restore-Verfahrens** (Wiederanlauf auf leerem Host, Synapse-Medien) — + unverändert offen, braucht eine Wegwerf-Umgebung.