node-exporter-DaemonSet in CrashLoopBackOff (4880 Restarts) + Cluster-Scrape seit 2026-08-01 tot #45
Assignees
sorb (ScrublordMcBad)
Clear assignees
sorb (ScrublordMcBad)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: sorb/axion1337.chat-gitops#45
Reference in New Issue
Block a user
Aufgedeckt durch das Alerting aus #32, unmittelbar nach dessen Rollout auf CFGMON (2026-08-01). Es sind zwei getrennte Probleme, von denen nur das zweite neu ist.
Diagnostiziert von CFGMON aus, per kube-state-metrics und den remote-geschriebenen Serien — auf dem Host selbst wurde nichts geprüft, dort steht kein
kubectlzur Verfügung. Vollständiger Befund im Backlog: MATRIX-05.1. Der Pod crasht seit Monaten (chronisch, nicht neu)
prometheus-node-exporter-4wwn7, Restarts…-fv7hj, Zählerstand vor 30 Tagenlast_terminated_reasonError(Exit ≠ 0, kein OOMKill)waiting_reason/readyCrashLoopBackOff/0Das besteht mindestens seit 30 Tagen. Neu ist nicht das Problem, sondern seine Sichtbarkeit — die Regel
KubePodRestartLoopkam erst mit #32 dazu. Wie beim Synapse-Port hat das Alerting damit einen stillen Altfehler aufgedeckt.Vermutete Ursache, nicht verifiziert: Der Pod läuft mit
hostNetwork: trueund will Port 9100 auf dem Host binden. Dort hört bereits ein eigenständiger node-exporter — derselbe, den CFGMON als Jobk3s_host_nodedirekt auf10.0.0.2:9100scrapt und der 2706 Metriken sauber ausliefert. Zwei Exporter, ein Port; der Pod bekämeaddress already in useund beendete sich sofort, was zureason: Errorohne OOM passt.Zum Bestätigen auf dem Host:
2. Der Cluster-Scrape ist am 2026-08-01 um 01:19 UTC ausgefallen (akut)
up-Mittel 24 h fürprometheus-node-exporter.monitoring.svc.cluster.local:9100Ein 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 öffentliche49.13.132.245, dorthin zeigt der Service-Endpoint — und dort kommt seit 01:19 nichts mehr.Von CFGMON aus gemessen:
10.0.0.2:9100(privat)49.13.132.245:9100(öffentlich)49.13.132.245:80/:443Ohne Reboot heißt das: die Erreichbarkeit auf 9100 wurde in der Nacht eingeengt. Zwei Möglichkeiten, von außen nicht unterscheidbar:
10.0.0.2:9100statt0.0.0.0:9100.ufw-Regel wurde geändert — die dokumentierte Allow-Liste führt 9100 ohnehin nicht auf, die private Zustellung muss also über eine Interface- oder Subnetz-Regel laufen.Das fällt zeitlich exakt in das Fenster der Synapse-Portkorrektur derselben Nacht. Prüfen mit
ss -lntp | grep :9100undufw status numbered.Fix — es ist ein node-exporter zu viel
Weg B (Vorschlag): Den DaemonSet-Exporter abschalten (
nodeExporter.enabled: falsein den kube-prometheus-stack-Values) und das Cluster-Alloy statt auf den Service-Namen direkt auf10.0.0.2:9100zeigen lassen. Beendet den Crashloop und erhält die enge Bindung ans private Netz, die gerade erst 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 durchufwund die Cloud-Firewall. Das nähme die Einschränkung zurück.Nebenbefund — Job-Label kollidiert zwischen zwei Hosts
Das Label
prometheus.scrape.node_exporterexistiert zweimal, weil CFGMONs Alloy und das Cluster-Alloy ihre Scrape-Komponente gleich benennen:Die Serien kollidieren nicht,
instancetrennt sie. Aber jede Abfrage, die nur nachjobfiltert, 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 trennen.Die beiden zugehörigen Alarme (
KubePodRestartLoopundTargetDown) sind auf CFGMON bewusst nicht stummgeschaltet — sie zeigen auf ein offenes Problem und melden sich mitrepeat_interval: 4halle vier Stunden, bis der doppelte node-exporter aufgelöst ist.Host-Prüfung durchgeführt (2026-08-01 ~03:55, per SSH auf MATRIX) — die Portkonflikt-These ist bestätigt, die Firewall-These widerlegt:
listen tcp 0.0.0.0:9100: bind: address already in use; den Port hält der systemd-Dienstprometheus-node-exporter(PID 1036). Der DaemonSet-Pod (hostNetwork: true, 4883 Restarts) kann nie binden → doppelter Exporter, deckt sich mit MATRIX-05.user.rules/user6.rulesmtime 29.04., keine 9100-Regel für extern (nurAnywhere ALLOW 10.0.0.0/16). Es ist heute Nacht keine Regel „mitgewandert".49.13.132.245:9100war extern nie freigegeben; der 200er vom Host selbst läuft über Loopback. Der reale CFGMON-Pfad10.0.0.2:9100(privates Netz) antwortet unverändert.-m comment "monitoring/prometheus-node-exporter:metrics has no endpoints" -j REJECTfür die ClusterIP gesetzt. Vorher zeigte der Endpoint des hostNetwork-Pods (Pod-IP = Host-IP) in dessen „Ready"-Momenten auf den gesunden systemd-Exporter — der Service lieferte also nur zufällig über den Port-Konkurrenten des eigenen Pods. Seit der Endpoint dauerhaft NotReady ist, rejected kube-proxy. Kausalzusammenhang mit den Alloy-Restarts (01:14/01:20 UTC) bleibt unbewiesen; der Grundfehler ist Monate alt.Fix-Empfehlung (Weg A): k8s-DaemonSet + Service
prometheus-node-exporterentfernen und den Alloy-Scrape darauf streichen — der systemd-Exporter auf dem Host ist die etablierte Quelle (CFGMON scrapt ihn direkt via 10.0.0.2) und das DaemonSet liefert exakt dieselben Host-Metriken doppelt. Das beendet Crashloop, beide Alarme und die Metrik-Doppelung in einem Schritt. Weg B (systemd-Dienst weg, DaemonSet behalten) würde den CFGMON-Scrape-Pfad brechen und mehr umbauen als nötig.Erledigt (2026-08-01 ~05:15): Fix deployt und beidseitig bestätigt.
93ee6a3(Weg A): node-exporter-HelmRelease + Alloy-Scrape entfernt, Flux hat gepruned — DaemonSet/Service/Pod restlos weg (der Pod stand zuletzt bei 4886 Restarts).increase(...[1h])erst das Stunden-Fenster leeren muss) und sind per Edit abgehakt.10.0.0.2:9100, verifiziert).Damit sind alle drei vom neuen Alerting (#32) aufgedeckten Altfehler abgearbeitet: Synapse-Port ✅, node-exporter ✅, GAME-01 eingegrenzt + gesilenced bis 04.08.
Migriert nach git.lab: axion1337.chat/axion1337.chat-gitops#44 (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.