sorb/axion1337.chat-gitops
1
0
Fork 0
Code Issues Pull Requests Packages Projects 1 Releases 24 Wiki Activity

[HIGH] Alerting fehlt komplett - nur Observability, keine aktiven Warnungen #32

New Issue
Closed
opened 2026-07-28 14:41:09 +00:00 by sorb · 7 comments
sorb commented 2026-07-28 14:41:09 +00:00
Owner
Copy Link
Copy Source

Alloy/Prometheus/Loki sammeln Metriken/Logs, aber es existiert keine Alertmanager-/Grafana-Alerting-Konfiguration. Der coturn-Crash (88 Tage, 36k+ Restarts) und der matrixRTC-Authorisation-Service OOM-Kill (2026-07-28) wurden beide nur durch zufälliges manuelles Nachschauen entdeckt, nicht durch eine Warnung. Mindestens sinnvoll: CrashLoopBackOff/OOMKilled-Alerts, Certificate-Expiry-Alerts, Disk-Space-Alerts (Single-Node-Cluster!), Pod-Restart-Häufigkeit. Kanal (Matrix-Raum? E-Mail?) noch zu klären.

Alloy/Prometheus/Loki sammeln Metriken/Logs, aber es existiert keine Alertmanager-/Grafana-Alerting-Konfiguration. Der `coturn`-Crash (88 Tage, 36k+ Restarts) und der `matrixRTC`-Authorisation-Service OOM-Kill (2026-07-28) wurden beide nur durch zufälliges manuelles Nachschauen entdeckt, nicht durch eine Warnung. Mindestens sinnvoll: CrashLoopBackOff/OOMKilled-Alerts, Certificate-Expiry-Alerts, Disk-Space-Alerts (Single-Node-Cluster!), Pod-Restart-Häufigkeit. Kanal (Matrix-Raum? E-Mail?) noch zu klären.
sorb added the priority:higharea:security labels 2026-07-28 14:41:09 +00:00
sorb commented 2026-07-31 16:31:06 +00:00
Author
Owner
Copy Link
Copy Source

Implementierung bereit, Deploy ausstehend (2026-08-01, Commit 9594ec8 in
threadnet-operating):

  • Alertmanager (v0.28.1, kein oeffentlicher Port) + Verdrahtung in Prometheus
    (rule_files + alerting-Block)
  • 6 Alert-Regeln fuer die real erlebten Fehlerklassen: TargetDown (coturn-Klasse:
    Dienst tot, keiner merkt es), KubePodRestartLoop (36k-Restarts-Klasse), HostOomKill,
    HostLowMemory, HostHighSwap, HostLowDisk
  • Matrix-Receiver (matrix-alerts.py, Stdlib-only, Machart wie maintenance-notify
    aus #24) -> wartung-Raum; Bot-Token beim Deploy per .env (Vorlage ergaenzt,
    Token via mas-cli manage issue-compatibility-token maintenance-notify)

Syntax: YAML+Python lokal verifiziert; promtool/amtool-Lint noch offen (Docker-Hub-
Pull hing auf dem Mac) - laeuft beim Deploy auf CFGMON in Sekunden, Images liegen dort
(Kommandos im Commit-Text).

Deploy-Checkliste (gemeinsame Session): git pull auf CFGMON -> Lint -> .env um
MATRIX_ALERT_* ergaenzen -> docker compose up -d -> Verifikation: Prometheus-UI
zeigt Regeln/Alertmanager-Target, Testalarm (z.B. node-exporter kurz stoppen ->
TargetDown feuert -> Matrix-Nachricht im wartung-Raum) -> Issue schliessen.

**Implementierung bereit, Deploy ausstehend** (2026-08-01, Commit `9594ec8` in `threadnet-operating`): - **Alertmanager** (v0.28.1, kein oeffentlicher Port) + Verdrahtung in Prometheus (`rule_files` + `alerting`-Block) - **6 Alert-Regeln** fuer die real erlebten Fehlerklassen: TargetDown (coturn-Klasse: Dienst tot, keiner merkt es), KubePodRestartLoop (36k-Restarts-Klasse), HostOomKill, HostLowMemory, HostHighSwap, HostLowDisk - **Matrix-Receiver** (`matrix-alerts.py`, Stdlib-only, Machart wie maintenance-notify aus #24) -> wartung-Raum; Bot-Token beim Deploy per `.env` (Vorlage ergaenzt, Token via `mas-cli manage issue-compatibility-token maintenance-notify`) Syntax: YAML+Python lokal verifiziert; **promtool/amtool-Lint noch offen** (Docker-Hub- Pull hing auf dem Mac) - laeuft beim Deploy auf CFGMON in Sekunden, Images liegen dort (Kommandos im Commit-Text). **Deploy-Checkliste (gemeinsame Session)**: git pull auf CFGMON -> Lint -> `.env` um MATRIX_ALERT_* ergaenzen -> `docker compose up -d` -> Verifikation: Prometheus-UI zeigt Regeln/Alertmanager-Target, Testalarm (z.B. node-exporter kurz stoppen -> TargetDown feuert -> Matrix-Nachricht im wartung-Raum) -> Issue schliessen.
sorb commented 2026-07-31 16:51:56 +00:00
Author
Owner
Copy Link
Copy Source

Nachtrag: Lint doch noch lokal gelaufen (Docker-Pull kam verspaetet durch) - alle drei Checks gruen: promtool check rules (6 Regeln), promtool check config, amtool check-config. Der Lint-Schritt in der Deploy-Checkliste ist damit optional; es bleibt nur noch der eigentliche Deploy + Funktionstest (Testalarm -> Matrix-Nachricht).

Nachtrag: Lint doch noch lokal gelaufen (Docker-Pull kam verspaetet durch) - **alle drei Checks gruen**: `promtool check rules` (6 Regeln), `promtool check config`, `amtool check-config`. Der Lint-Schritt in der Deploy-Checkliste ist damit optional; es bleibt nur noch der eigentliche Deploy + Funktionstest (Testalarm -> Matrix-Nachricht).
sorb commented 2026-07-31 21:26:51 +00:00
Author
Owner
Copy Link
Copy Source

Update 2026-07-31 spätabends — Matrix-Zustellung entschieden und vorbereitet:

Entscheidung (sorb): eigener Bot + eigener Raum statt Wiederverwendung des Maintenance-Bots — Token-Trennung (maintenance-Token liegt auf dem MATRIX-Host, der Alert-Token wird auf CFGMON liegen) und klarer Absender.

  • ✅ Bot-Account @alerts:axion1337.chat angelegt (mas-cli, User-ID 01KYX13S8DKGBC2DRED6AVRVCF)
  • ✅ monitoring/.env.example umgestellt (Commit 682adbd): dokumentiert jetzt Token-Erzeugung für alerts + einmaligen Raum-Join per API; der alte Wartungsraum-Platzhalter ist raus
  • ⬜ (sorb) Alerts-Raum im Operating-Space erstellen, @alerts:axion1337.chat einladen, Raum-ID hier nachtragen
  • ⬜ Deploy auf CFGMON (gemeinsame Session, Checkliste oben): .env mit Raum-ID + frischem Token befüllen, Bot joinen, docker compose up -d, Testalarm

Alle drei Lints (promtool rules, amtool config, Python-Syntax) sind seit dem Vorbereitungs-Commit grün.

**Update 2026-07-31 spätabends — Matrix-Zustellung entschieden und vorbereitet:** Entscheidung (sorb): **eigener Bot + eigener Raum** statt Wiederverwendung des Maintenance-Bots — Token-Trennung (maintenance-Token liegt auf dem MATRIX-Host, der Alert-Token wird auf CFGMON liegen) und klarer Absender. - ✅ Bot-Account **`@alerts:axion1337.chat`** angelegt (mas-cli, User-ID `01KYX13S8DKGBC2DRED6AVRVCF`) - ✅ `monitoring/.env.example` umgestellt (Commit `682adbd`): dokumentiert jetzt Token-Erzeugung für `alerts` + einmaligen Raum-Join per API; der alte Wartungsraum-Platzhalter ist raus - ⬜ (sorb) Alerts-Raum im Operating-Space erstellen, `@alerts:axion1337.chat` einladen, Raum-ID hier nachtragen - ⬜ Deploy auf CFGMON (gemeinsame Session, Checkliste oben): `.env` mit Raum-ID + frischem Token befüllen, Bot joinen, `docker compose up -d`, Testalarm Alle drei Lints (promtool rules, amtool config, Python-Syntax) sind seit dem Vorbereitungs-Commit grün.
sorb commented 2026-07-31 21:43:06 +00:00
Author
Owner
Copy Link
Copy Source

Bot-Setup abgeschlossen (2026-07-31 ~23:30): @alerts:axion1337.chat hat Displayname „Alerts", Avatar, ist dem Alerts-Raum !qavWkXbhLPfGvqtifj:axion1337.chat beigetreten und hat eine Testnachricht zugestellt (Event bestätigt) — Raum, Bot und Token sind damit End-zu-End verifiziert. Raum-ID ist als Default in monitoring/.env.example eingetragen.

Für das Deploy auf CFGMON fehlt nur noch: .env befüllen (Token liegt bereit), docker compose up -d, Testalarm über Alertmanager.

**Bot-Setup abgeschlossen (2026-07-31 ~23:30):** `@alerts:axion1337.chat` hat Displayname „Alerts", Avatar, ist dem Alerts-Raum `!qavWkXbhLPfGvqtifj:axion1337.chat` beigetreten und hat eine Testnachricht zugestellt (Event bestätigt) — Raum, Bot und Token sind damit End-zu-End verifiziert. Raum-ID ist als Default in `monitoring/.env.example` eingetragen. Für das Deploy auf CFGMON fehlt nur noch: `.env` befüllen (Token liegt bereit), `docker compose up -d`, Testalarm über Alertmanager.
sorb commented 2026-08-01 01:57:26 +00:00
Author
Owner
Copy Link
Copy Source

Vor dem Abschluss: das Alerting zeigt gerade auf ein offenes Problem

Der Rollout auf CFGMON ist durch und verifiziert — Alertmanager angebunden, 6 Regeln geladen, Zustellung bis in den Matrix-Raum per Testalarm bestätigt, kein Datenverlust an den Volumes. Auch das Edit-Verhalten aus ea33c3b läuft: Firing-Nachricht wird beim Resolved in-place abgehakt statt neu gepostet.

Ein Nachtrag am Receiver war nötig. Die State-Datei lag unter /tmp im Writable Layer des Containers. Das überlebt docker compose restart, aber kein up -d, das den Container neu baut — also genau jeden Deploy. Damit hätte die Zuordnung im Alltag bei jedem Deploy ausgesetzt und offene Alarme wären über den Fallback als separate Nachricht aufgelöst worden. Behoben in threadnet-operating@dfe04c4: named volume matrix_alerts_data auf /state, Pfad per MATRIX_STATE_FILE. Verifiziert durch Testalarm → --force-recreate (Container-ID 7e013a99d892 → b1f95380dede) → State unverändert vorhanden → Resolved hakt weiterhin die ursprüngliche Nachricht ab.

Wichtiger für diesen Abschluss: Das frisch ausgerollte Alerting hat sofort zwei stille Altfehler aufgedeckt. Einer davon ist noch offen und dokumentiert in #45:

  • prometheus-node-exporter im k3s-Cluster ist in CrashLoopBackOff, 4880 Restarts, ~12/h, seit mindestens 30 Tagen. Vermutlich Portkonflikt auf 9100 mit dem eigenständigen node-exporter (hostNetwork: true).
  • Zusätzlich ist der Cluster-Scrape-Pfad am 2026-08-01 um 01:19 UTC ausgefallen und nicht zurückgekommen — 49.13.132.245:9100 antwortet nicht mehr, 10.0.0.2:9100 schon. Kein Reboot (77,6 Tage Uptime). Das fällt zeitlich in das Fenster der Synapse-Portkorrektur.

Die beiden zugehörigen Alarme sind auf CFGMON bewusst nicht stummgeschaltet und melden sich alle 4 h. Aus meiner Sicht spricht nichts gegen den Abschluss von #32 — die Alerting-Kette selbst funktioniert und hat sich an echten Fällen bewiesen. Der Abschlussbericht sollte aber erwähnen, dass sie aktuell auf #45 zeigt, damit das nicht als Fehlalarm gelesen wird.

Backlog-Kontext: MATRIX-05 und GAME-01 (dort zwei Silences bis 2026-08-04, Firewall-Fix nachgelagert).

### Vor dem Abschluss: das Alerting zeigt gerade auf ein offenes Problem Der Rollout auf CFGMON ist durch und verifiziert — Alertmanager angebunden, 6 Regeln geladen, Zustellung bis in den Matrix-Raum per Testalarm bestätigt, kein Datenverlust an den Volumes. Auch das Edit-Verhalten aus `ea33c3b` läuft: Firing-Nachricht wird beim Resolved in-place abgehakt statt neu gepostet. **Ein Nachtrag am Receiver war nötig.** Die State-Datei lag unter `/tmp` im Writable Layer des Containers. Das überlebt `docker compose restart`, aber kein `up -d`, das den Container neu baut — also genau jeden Deploy. Damit hätte die Zuordnung im Alltag bei jedem Deploy ausgesetzt und offene Alarme wären über den Fallback als separate Nachricht aufgelöst worden. Behoben in `threadnet-operating@dfe04c4`: named volume `matrix_alerts_data` auf `/state`, Pfad per `MATRIX_STATE_FILE`. Verifiziert durch Testalarm → `--force-recreate` (Container-ID `7e013a99d892` → `b1f95380dede`) → State unverändert vorhanden → Resolved hakt weiterhin die ursprüngliche Nachricht ab. **Wichtiger für diesen Abschluss:** Das frisch ausgerollte Alerting hat sofort zwei stille Altfehler aufgedeckt. Einer davon ist noch offen und dokumentiert in #45: - `prometheus-node-exporter` im k3s-Cluster ist in CrashLoopBackOff, **4880 Restarts**, ~12/h, seit mindestens 30 Tagen. Vermutlich Portkonflikt auf 9100 mit dem eigenständigen node-exporter (`hostNetwork: true`). - Zusätzlich ist der Cluster-Scrape-Pfad am 2026-08-01 um 01:19 UTC ausgefallen und nicht zurückgekommen — `49.13.132.245:9100` antwortet nicht mehr, `10.0.0.2:9100` schon. Kein Reboot (77,6 Tage Uptime). Das fällt zeitlich in das Fenster der Synapse-Portkorrektur. Die beiden zugehörigen Alarme sind auf CFGMON **bewusst nicht stummgeschaltet** und melden sich alle 4 h. Aus meiner Sicht spricht nichts gegen den Abschluss von #32 — die Alerting-Kette selbst funktioniert und hat sich an echten Fällen bewiesen. Der Abschlussbericht sollte aber erwähnen, dass sie aktuell auf #45 zeigt, damit das nicht als Fehlalarm gelesen wird. Backlog-Kontext: [MATRIX-05](https://rohana.axion1337.de/sorb/Backlogs/src/branch/main/hosts/matrix.md) und [GAME-01](https://rohana.axion1337.de/sorb/Backlogs/src/branch/main/hosts/game.md) (dort zwei Silences bis 2026-08-04, Firewall-Fix nachgelagert).
sorb commented 2026-08-01 02:01:40 +00:00
Author
Owner
Copy Link
Copy Source

Abschlussbericht — #32 ist erledigt (2026-08-01, ~04:00 lokal):

Was jetzt läuft (alles committet in threadnet-operating, deployt auf CFGMON ohne Datenverlust):

  • Alertmanager v0.28.1 (nicht öffentlich) + 6 Prometheus-Regeln für die real erlebten Fehlerklassen (TargetDown, KubePodRestartLoop, HostOomKill, HostLowMemory, HostHighSwap, HostLowDisk)
  • Matrix-Receiver (Stdlib, State-persistent) → Bot @alerts → dedizierter Alerts-Raum im Operating-Space; ein Alarm = eine Nachricht: Resolved hakt die Firing-Nachricht per Edit ab (durchgestrichen + ✅) statt den Raum zu fluten
  • Verifiziert End-zu-End: synthetischer Testalarm (firing → Matrix → resolved) und ein echter Fall (s. u.)

Das Alerting hat in seiner ersten Nacht drei echte Altfehler aufgedeckt — keine Fehlalarme:

  1. Synapse-Metriken seit 98 Tagen tot: Alloy scrapte Port 9000 statt 9001 — gefixt (gitops b73d887), Alarm hat sich selbst aufgelöst (✅ im Raum). Voller Kreislauf am Realfall bewiesen.
  2. GAME-01 (Pterodactyl-Host unerreichbar): bekanntes Backlog-Item, jetzt aktiv überwacht; bis 04.08. gezielt gesilenced, Eingrenzung im Backlog.
  3. Doppelter node-exporter auf MATRIX (systemd-Dienst vs. hostNetwork-DaemonSet, 4883 Restarts): vollständige Diagnose + Fix-Empfehlung in #45 — die beiden zugehörigen Alarme bleiben bewusst laut, bis #45 umgesetzt ist.

Damit tut das System genau das, wofür es gebaut wurde: Probleme der coturn-Klasse („Dienst tot, keiner merkt es") melden sich jetzt von selbst. Weiterführendes läuft in #45; Dashboard-/Feintuning-Themen bei Bedarf als neue Issues.

**Abschlussbericht — #32 ist erledigt** (2026-08-01, ~04:00 lokal): **Was jetzt läuft** (alles committet in `threadnet-operating`, deployt auf CFGMON ohne Datenverlust): - Alertmanager v0.28.1 (nicht öffentlich) + 6 Prometheus-Regeln für die real erlebten Fehlerklassen (TargetDown, KubePodRestartLoop, HostOomKill, HostLowMemory, HostHighSwap, HostLowDisk) - Matrix-Receiver (Stdlib, State-persistent) → Bot `@alerts` → dedizierter Alerts-Raum im Operating-Space; **ein Alarm = eine Nachricht**: Resolved hakt die Firing-Nachricht per Edit ab (durchgestrichen + ✅) statt den Raum zu fluten - Verifiziert End-zu-End: synthetischer Testalarm (firing → Matrix → resolved) **und** ein echter Fall (s. u.) **Das Alerting hat in seiner ersten Nacht drei echte Altfehler aufgedeckt — keine Fehlalarme:** 1. **Synapse-Metriken seit 98 Tagen tot**: Alloy scrapte Port 9000 statt 9001 — gefixt (gitops `b73d887`), Alarm hat sich selbst aufgelöst (✅ im Raum). Voller Kreislauf am Realfall bewiesen. 2. **GAME-01** (Pterodactyl-Host unerreichbar): bekanntes Backlog-Item, jetzt aktiv überwacht; bis 04.08. gezielt gesilenced, Eingrenzung im Backlog. 3. **Doppelter node-exporter auf MATRIX** (systemd-Dienst vs. hostNetwork-DaemonSet, 4883 Restarts): vollständige Diagnose + Fix-Empfehlung in **#45** — die beiden zugehörigen Alarme bleiben bewusst laut, bis #45 umgesetzt ist. Damit tut das System genau das, wofür es gebaut wurde: Probleme der coturn-Klasse („Dienst tot, keiner merkt es") melden sich jetzt von selbst. Weiterführendes läuft in #45; Dashboard-/Feintuning-Themen bei Bedarf als neue Issues.
sorb closed this issue 2026-08-01 02:01:40 +00:00
sorb commented 2026-08-01 14:26:08 +00:00
Author
Owner
Copy Link
Copy Source

Migriert nach git.lab: axion1337.chat/axion1337.chat-gitops#32 (nur im Lab bzw. via VPN erreichbar — das Lab ist seit 2026-08-01 die Quelle der Wahrheit, siehe gitops#48). Weiterarbeit dort; dieses Gitea-Issue bleibt als Verweis stehen.

**Migriert nach git.lab**: [axion1337.chat/axion1337.chat-gitops#32](https://git.lab/axion1337.chat/axion1337.chat-gitops/-/issues/32) (nur im Lab bzw. via VPN erreichbar — das Lab ist seit 2026-08-01 die Quelle der Wahrheit, siehe gitops#48). Weiterarbeit dort; dieses Gitea-Issue bleibt als Verweis stehen.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area:authentik
Authentik Identity Provider
 area:database
Database and backups
 area:element
Element and UI
 area:infrastructure
K3S and infrastructure
 area:security
Security hardening
 priority:critical
Critical - This week
 priority:high
High - 1-2 weeks
 priority:low
Low - nice to have
 priority:medium
Medium - ~1 month
No labels area:security priority:high
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
sorb (ScrublordMcBad)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sorb/axion1337.chat-gitops#32