matrix: MATRIX-05 -- node-exporter CrashLoopBackOff + Cluster-Scrape seit 01:19 tot

Vom neuen Alerting (gitops#32) aufgedeckt, von CFGMON aus diagnostiziert
(kein kubectl dort, also per kube-state-metrics und Remote-Write-Serien).

Zwei getrennte Probleme:
- chronisch: DaemonSet-Pod in CrashLoopBackOff, 4880 Restarts, ~12/h,
  reason=Error ohne OOM, laeuft seit mindestens 30 Tagen. Vermutlich
  Portkonflikt auf 9100 mit dem eigenstaendigen node-exporter (hostNetwork).
  Nicht verifiziert -- Pod-Logs brauchen Hostzugriff.
- akut: der Service-Endpoint auf 49.13.132.245:9100 antwortet seit
  2026-08-01 01:19 UTC nicht mehr, 10.0.0.2:9100 dagegen schon. Kein Reboot
  (77,6 Tage Uptime), faellt ins Fenster der Synapse-Portkorrektur.

Plus Nebenbefund: Job-Label prometheus.scrape.node_exporter existiert auf
CFGMON und MATRIX doppelt, External Label cluster= wuerde das trennen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

hosts/matrix.md

@@ -39,6 +39,103 @@ verifiziert**, ob auf dem Host etwas auf den Namen hört.
 
 ---
 
+## MATRIX-05 — node-exporter-DaemonSet in CrashLoopBackOff, Cluster-Scrape seit 2026-08-01 tot
+
+**Status:** offen — zwei getrennte Probleme, aufgedeckt durch das neue Alerting auf CFGMON
+([gitops#32](https://rohana.axion1337.de/sorb/threadnet-operating), Rollout 2026-08-01)
+
+Von CFGMON aus diagnostiziert, per kube-state-metrics und den remote-geschriebenen Serien.
+**Auf dem Host selbst wurde nichts geprüft** — CFGMON hat kein `kubectl`.
+
+### Teil 1 — der Pod crasht seit Monaten (chronisch)
+
+| Messwert | Stand 2026-08-01 |
+|---|---|
+| Pod `prometheus-node-exporter-4wwn7`, Restarts | **4880**, davon 1970 in 7 Tagen |
+| Vorgängerpod `…-fv7hj`, Zählerstand vor 30 Tagen | 13918 |
+| aktuelle Rate | ~12/h — entspricht dem CrashLoopBackOff-Deckel von 5 min |
+| `last_terminated_reason` | `Error` (Exit ≠ 0, **kein** OOMKill) |
+| `waiting_reason` / `ready` | `CrashLoopBackOff` / `0` |
+
+Das besteht mindestens seit 30 Tagen, also **lange vor** dem Monitoring-Rework und vor dem
+Alerting-Rollout. Neu ist nur die Sichtbarkeit: die Regel `KubePodRestartLoop` kam am
+2026-08-01 dazu. Wie bei Synapse hat das Alerting einen stillen Altfehler aufgedeckt.
+
+**Vermutete Ursache, nicht verifiziert:** Der Pod läuft mit `hostNetwork: true` und will
+Port 9100 auf dem Host binden. Dort hört bereits ein **eigenständiger node-exporter** —
+derselbe, den CFGMON als Job `k3s_host_node` direkt auf `10.0.0.2:9100` scrapt und der
+2706 Metriken sauber ausliefert. Zwei Exporter, ein Port; der Pod bekäme
+`address already in use` und beendete sich sofort, was zu `reason: Error` ohne OOM passt.
+
+Zum Bestätigen auf dem Host:
+
+```
+ss -lntp | grep :9100
+kubectl -n monitoring logs prometheus-node-exporter-4wwn7 --previous | tail -20
+```
+
+### Teil 2 — der Cluster-Scrape ist am 2026-08-01 01:19 UTC ausgefallen (akut)
+
+| Messwert | Stand |
+|---|---|
+| `up`-Mittel 24 h für `prometheus-node-exporter.monitoring.svc.cluster.local:9100` | 98,3 % |
+| Zustandswechsel in 24 h | **1** — einmal runter, nicht zurück |
+| Host-Uptime | 77,6 Tage → **kein Reboot** |
+
+Ein Pod, der 12× pro Stunde stirbt, kann kein Target sein, das zu 98 % up ist. Geantwortet
+hat also nie der Pod, sondern der eigenständige Exporter über die Host-IP. Der Pod hat
+`hostNetwork`, sein Pod-IP ist die öffentliche `49.13.132.245`, dorthin zeigt der
+Service-Endpoint — und dort kommt seit 01:19 nichts mehr.
+
+Von CFGMON aus gemessen:
+
+| Pfad | Ergebnis |
+|---|---|
+| `10.0.0.2:9100` (privat) | offen, 2706 Metriken |
+| `49.13.132.245:9100` (öffentlich) | **keine Antwort** |
+| `49.13.132.245:80` / `:443` | offen — Host lebt |
+
+Ohne Reboot heißt das: in der Nacht wurde die Erreichbarkeit auf 9100 eingeengt. Zwei
+Möglichkeiten, von hier aus nicht unterscheidbar:
+
+1. Der Exporter bindet jetzt `10.0.0.2:9100` statt `0.0.0.0:9100`.
+2. Eine `ufw`-Regel wurde geändert. Die Allow-Liste oben in dieser Datei führt 9100
+   ohnehin nicht auf — die private Zustellung muss also über eine Interface- oder
+   Subnetz-Regel laufen, an der sich etwas geändert haben kann.
+
+Zeitlich fällt das exakt in das Fenster der Synapse-Port-Korrektur derselben Nacht. Wer
+dort die Exposition aufgeräumt hat, hat den Cluster-Scrape-Pfad mitgenommen. Prüfen mit
+`ss -lntp | grep :9100` und `ufw status numbered`.
+
+### Fix — es ist ein node-exporter zu viel
+
+**Weg B (empfohlen):** Den DaemonSet-Exporter abschalten (`nodeExporter.enabled: false` in
+den kube-prometheus-stack-Values) und das Cluster-Alloy statt auf den Service-Namen direkt
+auf `10.0.0.2:9100` zeigen lassen. Beendet den Crashloop und erhält die enge Bindung ans
+private Netz, die in der Nacht vom 2026-08-01 gesetzt wurde.
+
+**Weg A:** Den eigenständigen Exporter stilllegen und dem DaemonSet den Port überlassen.
+Ebenfalls sauber, aber er bindet dann wieder `0.0.0.0` — also auch die öffentliche IP,
+abgesichert nur noch durch `ufw` und die Cloud-Firewall. Das nähme die Einschränkung
+zurück, die gerade erst gesetzt wurde.
+
+### Nebenbefund — Job-Label kollidiert zwischen zwei Hosts
+
+Das Label `prometheus.scrape.node_exporter` existiert zweimal, weil CFGMONs Alloy und das
+Cluster-Alloy ihre Scrape-Komponente gleich benennen:
+
+```
+up=1  instance=node-exporter:9100                               -> CFGMON  (Kernel 6.8.0-136-generic)
+up=0  instance=prometheus-node-exporter.monitoring.svc...:9100  -> MATRIX
+```
+
+Die Serien kollidieren nicht, `instance` trennt sie. Aber jede Abfrage, die nur nach `job`
+filtert, mischt zwei Maschinen — und in Alarmtexten steht dann ein Job-Name, der nicht sagt,
+welcher Host gemeint ist. Ein External Label auf der Remote-Write-Seite dieses Clusters
+(`cluster="matrix"`) würde das sauber trennen.
+
+---
+
 ## Erledigt
 
 ### MATRIX-01 — Klären, ob der Server Mail als `@matrix.axion1337.de` verschickt · erledigt 2026-07-30