Logbuch#netzwerk#dns#monitoring
Der Pi galt als offline — und lief seit 13 Tagen
Von Niclas Hennrich · veröffentlicht · geschehen am
Etwas ist ausgefallen oder kaputtgegangen.
- Uptime des angeblich toten Pi
- 13Tage
- node_-Metriken nach der Anbindung
- 846
Das Symptom: Seit dem ersten Tag des Control Centers stand der Pi „blackbox" — mein Pi-hole samt Unbound — auf critical. Die reservierte Adresse antwortete weder auf Ping noch tauchte sie in der ARP-Tabelle auf. Pi-hole down, Unbound down. Nur einmal, gegen 17:45, ein einzelner grüner Probe-Zyklus, dann wieder rot.
Die Diagnose, alles nur lesend: Erstens hat der Pi gar keine statische
Adresse — das NetworkManager-Profil steht auf DHCP, im gespiegelten /etc
nachgesehen. Zweitens fand sich die Hardware-Adresse des Pi in der
ARP-Tabelle des Routers sehr wohl, nur eben unter einer anderen Adresse aus
dem DHCP-Bereich. Drittens, per SSH dorthin: uptime 13 Tage, die Container
pihole und unbound „Up 13 days (healthy)". Der Pi war nie kaputt. Und
viertens die Ursache: In der DHCP-Konfiguration des Routers gab es
Reservierungen nur noch für zwei andere Geräte. Die für den Pi ist beim
Router- und DHCP-Umbau verloren gegangen, und beim nächsten Lease bekam er
irgendeine Adresse aus dem Pool.
Das erklärt auch, warum es niemandem aufgefallen war: Der Router sprang als DNS ein, und aus Sicht der Clients funktionierte alles.
Die Reparatur: Reservierung per API neu angelegt — mit dem Stolperstein,
dass addHost bei unvollständigem Feldsatz nur {"result":"failed"}
zurückgibt, ohne zu sagen, was fehlt. Nebenbei zwei lokale Records im
Pi-hole korrigiert, die noch auf Adressen aus der Zeit vor dem Umzug zeigten.
Reboot — der Pi kam mit der reservierten Adresse hoch. Und weil ich schon
dabei war: Die Pi-hole-Oberfläche lauscht bei mir nicht auf Port 80, was den
HTTP-Check im Monitoring gleich mit korrigiert hat. Im Dashboard wurde
aus critical ein warning: Es fehlte nur noch node_exporter.
Der Abschluss: node_exporter auf dem Pi nach dem gleichen Muster wie auf
dem Server — network_mode: host, pid: host, Root-FS read-only, dazu
mem_limit: 64m, weil der Pi nur 1 GB RAM hat. 846 node_-Metriken lokal,
Prometheus auf optimus meldet das Target als up. Anders als beim Server war
keine Firewall-Regel nötig: Der Scrape kommt über das LAN, nicht aus einem
lokalen Docker-Bridge-Netz. Damit ist die blackbox-Karte vollständig grün.
Was ich mitnehme: „Host offline" heißt nur „diese Adresse antwortet nicht". Bevor ich Hardware verdächtige, suche ich die Hardware-Adresse in der ARP- oder Lease-Tabelle. Und bei einer Router-Migration gehören alle Reservierungen mit umgezogen — und danach ein Abgleich, ob jedes Gerät wirklich dort sitzt, wo es sitzen soll.
Das kurze Flackern um 17:45 bleibt ungeklärt. Der Pi kann es nicht gewesen sein, seine Oberfläche liegt nicht auf dem damals geprüften Port. Vermutlich hat kurz ein anderes Gerät auf der Adresse geantwortet.