From b4b48933896e6cd8b4a378239a53668d16a4e825 Mon Sep 17 00:00:00 2001 From: Thore Cimbal Date: Sat, 1 Aug 2026 12:00:00 +0000 Subject: [PATCH] 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 --- hosts/matrix.md | 97 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) diff --git a/hosts/matrix.md b/hosts/matrix.md index 506f988..da9e05d 100644 --- a/hosts/matrix.md +++ b/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