Black-Box-Monitoring prüft ein System von außen, so wie ein Nutzer oder Client es sieht, ohne Kenntnis seiner internen Abläufe. Probes senden echte Anfragen, etwa HTTP-Aufrufe, DNS-Abfragen, TCP-Verbindungen oder skriptgesteuerte Nutzerpfade, und prüfen Erreichbarkeit, Korrektheit und Antwortzeit. So werden Symptome erkannt, die Nutzer gerade tatsächlich erleben.
Was ist Black-Box-Monitoring?
Black-Box-Monitoring beobachtet ein System ausschließlich über sein von außen sichtbares Verhalten. Eine Probe sendet eine Anfrage an einen Endpunkt, wartet auf die Antwort und prüft, ob sie ankam, ob sie korrekt war und wie lange sie gedauert hat. Die Probe weiß nicht, welche Services, Datenbanken oder Warteschlangen hinter dem Endpunkt liegen; sie behandelt das System als geschlossene Kiste.
Das Gegenstück ist das White-Box-Monitoring, das auf Telemetrie aus dem Inneren des Systems setzt: Metriken, Logs, Traces und Profile. Das SRE-Buch von Google beschreibt beide als einander ergänzend. Black-Box-Monitoring ist symptomorientiert und beantwortet die Frage „Ist es für Nutzer gerade kaputt?“. White-Box-Monitoring beantwortet „Warum ist es kaputt?“ und kann Probleme aufdecken, bevor sie Nutzer erreichen. Die Unterscheidung gehört zur größeren Debatte Observability vs. Monitoring.
So funktioniert Black-Box-Monitoring
Eine Black-Box-Prüfung besteht meist aus vier Teilen:
- Ein Ziel, etwa eine URL, ein Hostname, IP und Port, ein DNS-Eintrag oder ein TLS-Endpunkt.
- Eine Probe, die nach Zeitplan von einem oder mehreren Standorten aus läuft, zum Beispiel jede Minute aus mehreren Regionen.
- Assertions, die Erfolg definieren: ein HTTP-Statuscode, ein Text im Antwortinhalt, ein gültiges Zertifikat, eine Antwortzeit unter einem Schwellenwert.
- Eine Alarmregel, die bei Fehlschlägen auslöst, typischerweise erst, wenn mehrere aufeinanderfolgende Prüfungen oder mehrere Standorte fehlschlagen, damit nicht jede kurze Netzwerkstörung einen Alarm erzeugt.
Einfache Probes testen eine einzelne Anfrage, etwa einen Health Check-Endpunkt oder einen TCP-Verbindungsaufbau. Skriptgesteuerte Browser-Prüfungen gehen weiter und spielen einen Nutzerpfad nach, zum Beispiel Anmeldung, Suche und Hinzufügen eines Artikels zum Warenkorb. Das wird meist als synthetisches Monitoring bezeichnet.
Black-Box-Monitoring vs. White-Box-Monitoring
| Aspekt | Black-Box | White-Box |
|---|---|---|
| Perspektive | Von außen, wie Nutzer oder Client | Von innen, aus Code und Infrastruktur |
| Daten | Probe-Ergebnisse: Erfolg, Status, Antwortzeit | Metriken, Logs, Traces, Profile |
| Erkennt | Ausfälle, DNS-, TLS-, CDN- und Routing-Probleme | Ursachen, Verschlechterungen, Probleme vor der Nutzerwirkung |
| Blinde Flecken | Warum etwas fehlschlägt; Pfade, die die Probe nicht testet | Fehler außerhalb des instrumentierten Codes, z. B. DNS oder Load Balancer |
Eine zentrale Stärke von Black-Box-Monitoring: Es funktioniert auch dann, wenn Ihre interne Telemetrie ausfällt. Fällt ein Cluster vollständig aus, kommen interne Metriken unter Umständen einfach nicht mehr an, während eine externe Probe den Ausfall eindeutig meldet.
Black-Box-Prüfungen sind zudem der direkteste Weg, das zu messen, was Kunden und Verträge interessiert. Eine Verfügbarkeitszusage in einem SLA wird meist über erfolgreiche Anfragen von außen definiert, und Probe-Ergebnisse liefern dafür einen unabhängigen Nachweis. Gleichzeitig sehen Probes nur die Pfade, die sie testen. Eine Prüfung der Startseite sagt nichts über einen ausgefallenen Zahlungsdienstleister aus. Deshalb brauchen kritische Nutzerpfade eigene Prüfungen, und die Abdeckung der Probes sollte bei jeder neuen Funktion überprüft werden. Planen Sie außerdem Wartungsfenster ein, damit geplante Arbeiten keine Fehlalarme auslösen und Verfügbarkeitsberichte verfälschen.
Beispiel: Prometheus Blackbox Exporter
Der Prometheus Blackbox Exporter ist ein verbreiteter Open-Source-Prober. Ein beispielhaftes Modul, das eine 2xx-Antwort über gültiges TLS verlangt, sieht so aus:
modules:
http_2xx_tls:
prober: http
timeout: 5s
http:
valid_status_codes: [] # Standard: 2xx
fail_if_not_ssl: true
fail_if_body_not_matches_regexp:
- "status.*ok"Der Exporter stellt probe_success und probe_duration_seconds bereit. Ein Alarm kann also auslösen, wenn probe_success mehrere Minuten lang 0 ist. Dieselben Daten können in Berichte zu Uptime und Verfügbarkeit sowie in Warnungen zum Ablauf von Zertifikaten einfließen.
Best Practices
- Von außerhalb des eigenen Netzes prüfen und von mehreren Standorten aus, sonst testen Sie Ihr internes Netz statt des Nutzerpfads.
- Korrektheit prüfen, nicht nur Erreichbarkeit. Eine 200-Antwort mit einer Fehlerseite ist trotzdem ein Ausfall.
- Mehrere Fehlschläge verlangen, bevor alarmiert wird, um Fehlalarme und Alarmmüdigkeit gering zu halten.
- Kritische Nutzerpfade abdecken wie Anmeldung und Checkout, nicht nur die Startseite.
- Jeden Black-Box-Alarm mit White-Box-Daten verbinden, damit die Rufbereitschaft schnell vom Symptom zur Ursache kommt.
Häufige Fehler
- Sich ausschließlich auf Black-Box-Prüfungen zu verlassen, die zeigen, dass etwas kaputt ist, aber nicht warum.
- Einen oberflächlichen Endpunkt zu prüfen, der auch dann OK meldet, wenn die Datenbank nicht erreichbar ist.
- Probes im selben Rechenzentrum wie die Anwendung zu betreiben.
- Schwellenwerte für die Antwortzeit so knapp zu setzen, dass normale Schwankungen im Netz ständig Alarme auslösen.
- Testverkehr zu erzeugen, der Geschäftsauswertungen verfälscht, statt ihn als synthetisch zu kennzeichnen.
Wie Obseria hilft
Obseria führt HTTP-, API- und skriptgesteuerte Browser-Prüfungen im Rahmen des synthetischen Monitorings aus und speichert die Ergebnisse in Obseria Lake neben internen Metriken, Logs und Traces. Fehlgeschlagene Prüfungen können Incidents eröffnen, über Automation Runbooks auslösen und Statusseiten aktualisieren, während die zugehörigen Backend-Traces erklären, was schiefgelaufen ist.
