Logbuch#opnsense#monitoring#prometheus#homeos
„API nicht erreichbar“ — dabei war opnsense_up nie Erreichbarkeit
Von Niclas Hennrich · veröffentlicht · geschehen am
Etwas ist ausgefallen oder kaputtgegangen. Gehört zum Vorhaben HomeOS — Control Center mit drei Säulen.
- Tage mit falscher Warnung
- 3
- Produktversion vor und nach dem Kipppunkt
- identisch
Die Übersicht meldete für die Firewall: „OPNsense-API nicht erreichbar (Exporter-Scrape fehlgeschlagen)." Daneben: Gateways, Interfaces, Firewall-Zähler — alles frisch, alles in Bewegung. Beides zugleich kann nicht stimmen. Also welches stimmt nicht?
Die Metrik. opnsense_up klingt nach „Router antwortet". Tatsächlich
setzt der Exporter sie nur dann auf 1, wenn er die Antwort eines bestimmten
Status-Endpunkts parsen konnte. Nach einem Paket-Update auf der OPNsense —
Produktversion unverändert — hatte sich das Antwortformat dieses einen
Endpunkts leicht geändert. Der Exporter zählte dafür keinen Fehler, loggte
nichts, und alle seine eigenen Diagnosesignale blieben grün. Nur sein
Hauptsignal kippte auf 0, still. Alle anderen Collectors liefen weiter.
Korrelieren ließ sich das nur über einen Serien-Diff: Welche Serien verschwanden zum Kipppunkt, welche blieben? Genau eine fehlte — die aus dem betroffenen Endpunkt. Ein unterschätztes Werkzeug; „vorher/nachher" auf Serienebene ist oft schneller als jedes Log.
Der zweite Fehler war meiner. Die Statusbewertung im Backend hatte für
opnsense_up = 0 einen Early-Return mit dem Text „API nicht erreichbar".
Der Text behauptete eine Ursache, die die Metrik nie hergab. Und der
Early-Return verdeckte drei Tage lang den echten Befund, der dahinter
wartete: Die Firewall stand seit dem 3. September auf „Reboot
ausstehend", dazu lag ein Firmware-Update bereit. Beides Nutzeraktion,
weil Router-Neustart Heimnetz-Downtime heißt — aber man sollte es sehen.
Behoben in zwei Schichten: ein gepatchtes Exporter-Image, bis der Fix
upstream ist (dokumentierte Wartungsschuld), und eine Bewertung, die
opnsense_up als das behandelt, was es ist — ein Parse-Ergebnis — und den
Reboot-Zustand nicht mehr verschluckt.
Was bleibt: Ein Metrikname ist keine Semantik. Warnungstexte gehören an die belegte Bedeutung gebunden, nicht an die plausibelste Interpretation. Der stillste Fehlerzweig ist der gefährlichste. Und Paket-Updates ändern Verhalten auch ohne Versionswechsel.