Zum Inhalt springen
labkompass

Logbuch#netzwerk#dns#monitoring

Der Pi galt als offline — und lief seit 13 Tagen

Von Niclas Hennrich · veröffentlicht · geschehen am


ProblemBehoben

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.

Daraus entstanden