HTTP 200 bedeutet nicht, dass die Anwendung funktioniert. Was sollte das Monitoring wirklich überprüfen?

1. alle paar Minuten wird eine HTTP-Anfrage gesendet,
2. der Server antwortet,
3. das System überprüft den HTTP-Statuscode,
4. wenn es 200 OK erhält, gilt die Website als verfügbar.

Das Problem dabei:

HTTP 200 bedeutet lediglich, dass der Server eine HTTP-Antwort mit dem Statuscode 200 zurückgegeben hat. Es bedeutet nicht, dass die Anwendung tatsächlich korrekt funktioniert.

Ein Onlineshop kann 200 OK zurückgeben, obwohl sich kein Produkt in den Warenkorb legen lässt.

Das Kundenportal kann verfügbar sein, während die Anmeldung mit einem Fehler endet.

Eine Website kann sich öffnen, während ihre API 15 Sekunden für eine Antwort benötigt.

Der Checkout kann angezeigt werden, obwohl jeder Zahlungsversuch mit einem Fehler endet.

Ein Monitoring, das ausschließlich ein grünes „UP“ anzeigt, kann in all diesen Fällen davon ausgehen, dass alles funktioniert.

Uptime und die korrekte Funktion einer Anwendung sind zwei verschiedene Dinge

Nehmen wir an, wir überwachen:

https://example.com

Das System führt folgende Anfrage aus:

GET /

Der Server antwortet:

HTTP/1.1 200 OK

Aus Sicht eines einfachen Uptime-Monitors ist alles in Ordnung.

Ein Benutzer verwendet eine Website jedoch nicht, indem er ihren HTTP-Statuscode überprüft.

Ein Benutzer:

• öffnet die Website,
• klickt,
• sucht,
• meldet sich an,
• sendet Formulare,
• legt Produkte in den Warenkorb,
• führt Zahlungen durch,
• nutzt die API.

Deshalb ist die Frage:

„Antwortet der Server?“

nur die erste Ebene des Monitorings.

Eine wesentlich wichtigere Frage lautet:

„Kann der Benutzer tatsächlich das tun, wofür er auf die Website gekommen ist?“

Fall 1: Die Website gibt 200 zurück, zeigt aber eine Fehlermeldung an

Stellen wir uns eine Anwendung vor, bei der ein Problem mit der Datenbank aufgetreten ist.

Das Backend fängt die Ausnahme ab und rendert eine eigene Fehlerseite, anstatt HTTP 500 zurückzugeben.

Die Antwort kann so aussehen:

HTTP/1.1 200 OK
Content-Type: text/html

und ihr Inhalt:

<h1>Something went wrong</h1>
<p>Please try again later.</p>

Für den Benutzer funktioniert die Anwendung nicht.

Für einen einfachen Monitor:

200 OK

also ist alles in Ordnung.

Deshalb sollte sich gutes HTTP-Monitoring nicht ausschließlich auf den Statuscode der Antwort beschränken.

In bestimmten Fällen lohnt es sich, auch den Inhalt der Antwort zu überprüfen.

Zum Beispiel kann geprüft werden, ob die Seite ein bestimmtes Element oder einen Text enthält, der für eine korrekt geladene Anwendung charakteristisch ist.

Fall 2: Die Homepage funktioniert, der Checkout nicht

Dies ist eines der wichtigsten Probleme beim Monitoring von Onlineshops.

Der Monitor überprüft:

GET /

und erhält:

200 OK

Währenddessen funktioniert:

/cart

aber:

/checkout

endet mit einem Fehler.

Oder noch schlimmer: Auch der Checkout gibt 200 zurück, aber das JavaScript für die Auswahl der Zahlungsmethode funktioniert nicht mehr.

Aus Sicht der Infrastruktur ist der Onlineshop verfügbar.

Aus geschäftlicher Sicht kann der Onlineshop praktisch außer Betrieb sein.

Wenn ein Benutzer nicht bezahlen kann, ist es nur von geringer Bedeutung, dass die Startseite funktioniert.

Deshalb sollte das Monitoring die wichtigsten Geschäftsprozesse und nicht nur die Homepage abdecken.

Bei einem Onlineshop können dies sein:

• die Startseite,
• die Produktseite,
• die Suche,
• der Warenkorb,
• der Checkout,
• Zahlungsendpoints,
• APIs für Lagerbestände.

Bei einer SaaS-Anwendung:

• Anmeldung,
• Registrierung,
• Dashboard,
• die wichtigste Funktion der Anwendung,
• API,
• Queues oder geplante Aufgaben.

Fall 3: Die Anwendung funktioniert, ist aber so langsam, dass sie praktisch nicht nutzbar ist

Ein weiteres Problem entsteht, wenn die Antwort so aussieht:

HTTP 200
Response time: 12.8 s

Funktioniert die Anwendung?

Technisch gesehen ja.

Wird der Benutzer sie als korrekt funktionierend wahrnehmen?

Nicht unbedingt.

Das Monitoring sollte deshalb nicht nur die Verfügbarkeit, sondern auch die Antwortzeit analysieren.

Dabei sollte man einzelne Spitzen nicht überbewerten.

Wenn die typische Antwortzeit 300 ms beträgt und eine einzelne Anfrage 900 ms dauert, muss das noch keinen Ausfall bedeuten.

Wenn die Antwortzeiten in den letzten 20 Minuten jedoch folgendermaßen gestiegen sind:

300 ms → 450 ms → 800 ms → 1.4 s → 2.8 s

ist das ein wesentlich interessanteres Signal.

Die Anwendung funktioniert noch, aber ihr Zustand verschlechtert sich deutlich.

Das ist häufig der beste Zeitpunkt zu reagieren – bevor es zu einem vollständigen Ausfall kommt.

Fall 4: Das Frontend funktioniert, die API nicht

Moderne Anwendungen bestehen häufig aus mehreren unabhängigen Komponenten.

Zum Beispiel:

Frontend
   ↓
API
   ↓
Database
   ↓
Redis
   ↓
Queue
   ↓
External services

Das bloße Öffnen des Frontends muss nicht alle diese Abhängigkeiten einbeziehen.

Eine Next.js-Anwendung kann eine Seite korrekt rendern, während die Backend-API Fehler zurückgibt.

Ebenso kann sich das Administrationspanel öffnen, obwohl die Queue keine Aufgaben mehr verarbeitet.

Deshalb liefert das Monitoring nur einer öffentlichen URL kein vollständiges Bild vom Zustand der Anwendung.

Fall 5: Fehler treten nur bei einem Teil der Benutzer auf

Noch schwieriger sind partielle Ausfälle.

Ein Problem kann beispielsweise nur auftreten:

• auf mobilen Geräten,
• in einem bestimmten Browser,
• bei Benutzern aus einem bestimmten Land,
• nach der Anmeldung,
• bei einer bestimmten Zahlungsmethode,
• bei einem einzelnen API-Endpoint.

Aus Sicht eines gewöhnlichen Uptime-Monitors kann die Anwendung die ganze Zeit vollständig fehlerfrei erscheinen.

Das zeigt, warum externes Monitoring mit Fehlermonitoring innerhalb der Anwendung kombiniert werden sollte.

Uptime- und Fehlermonitoring beantworten unterschiedliche Fragen

Uptime-Monitoring beantwortet vor allem die Frage:

„Ist der Dienst von außen erreichbar?“

Fehlermonitoring beantwortet dagegen die Frage:

„Treten während des Betriebs der Anwendung Fehler auf?“

Das sind zwei unterschiedliche Perspektiven.

Nehmen wir an, eine Anwendung hat innerhalb einer Stunde:

100.000 Anfragen

verarbeitet und 2 % davon endeten mit einem Anwendungsfehler.

Das ergibt:

2.000 fehlerhafte Anfragen

Gleichzeitig konnte die Homepage bei jeder Überprüfung durch den Monitor Folgendes zurückgeben:

200 OK

Uptime:

100 %

Das bedeutet jedoch nicht, dass die Anwendung ohne Probleme funktioniert hat.

Monitoring sollte mehrere Ebenen abdecken

Anstatt mit einem einzigen Indikator die Frage „Funktioniert alles?“ beantworten zu wollen, ist es besser, mehrere unabhängige Ebenen zu überwachen.

Ebene 1: Verfügbarkeit

Antwortet der Server?

Unter anderem überprüfen wir:

• HTTP-Statuscode,
• Timeout,
• DNS-Probleme,
• Verbindungsprobleme,
• Weiterleitungen.

Ebene 2: Antwortzeit

Wie schnell antwortet die Anwendung?

Relevant ist nicht nur der aktuelle Wert, sondern auch seine Veränderung im Laufe der Zeit.

Eine plötzliche Verschlechterung der Performance kann das erste Anzeichen eines Problems sein.

Ebene 3: SSL-Zertifikat

Ist das Zertifikat:

• gültig,
• noch nicht abgelaufen,
• auch in einigen Tagen noch gültig?

Ein Ausfall aufgrund eines SSL-Zertifikats ist besonders unnötig, da sich das Problem normalerweise lange erkennen lässt, bevor es tatsächlich zu einem Ausfall kommt.

Ebene 4: Inhalt der Antwort

Hat der Server das zurückgegeben, was wir erwarten?

Der Statuscode 200 allein reicht möglicherweise nicht aus.

Ebene 5: Anwendungsfehler

Erzeugt das Backend Ausnahmen?

Unter anderem lohnt es sich, Folgendes zu überwachen:

• Fehlertyp,
• Stack Trace,
• Endpoint,
• Umgebung,
• Anwendungsversion,
• Zeitpunkt des ersten und letzten Auftretens,
• Häufigkeit des Auftretens.

Ebene 6: Website-Performance

Eine Anwendung kann auf HTTP-Ebene schnell antworten und trotzdem im Browser langsam sein.

Deshalb lohnt es sich, auch die Frontend-Performance und die Core Web Vitals zu überwachen.

Ebene 7: Geschäftsprozess

Die höchste Ebene des Monitorings beantwortet die Frage:

„Kann der Benutzer tatsächlich die wichtigste Aktion ausführen?“

Bei einem Onlineshop ist das der Kauf.

Bei einer SaaS-Anwendung können es die Anmeldung und die Ausführung der wichtigsten Funktion sein.

Bei einer Website zur Leadgenerierung ist es das Absenden eines Formulars.

Die gefährlichsten Ausfälle bedeuten nicht immer vollständigen Downtime

Ein vollständiger Ausfall ist paradoxerweise leicht zu erkennen.

Wenn der Server nicht mehr korrekt antwortet und beispielsweise Folgendes zurückgibt:

502 Bad Gateway

erkennt das Monitoring das Problem schnell.

Wesentlich schwieriger sind Ausfälle nach dem Muster:

Die Website funktioniert, aber etwas Wichtiges funktioniert nicht mehr.

Genau solche Probleme können viele Stunden lang unbemerkt bleiben.

Der Onlineshop funktioniert, nimmt aber keine Bestellungen an.

Das Formular funktioniert optisch, sendet aber keine Nachrichten.

Die Anwendung funktioniert, aber ein Teil der Benutzer kann sich nicht anmelden.

Die API funktioniert, aber ein kritischer Endpoint gibt Fehler zurück.

Deshalb sollte ein effektives Monitoring den gesamten Zustand einer Anwendung nicht auf eine einzige grüne oder rote Anzeige reduzieren.

Was bedeutet also „Die Anwendung funktioniert“?

Darauf gibt es keine universelle Antwort.

Eine gut überwachte Anwendung sollte gleichzeitig aus mehreren Perspektiven betrachtet werden:

• ob sie antwortet,
• ob sie schnell genug antwortet,
• ob sie die richtigen Inhalte zurückgibt,
• ob sie nicht ungewöhnlich viele Fehler erzeugt,
• ob ihr Zertifikat gültig ist,
• ob das Frontend eine gute Performance bietet,
• ob die wichtigsten Geschäftsfunktionen verfügbar sind.

Erst die Kombination dieser Informationen liefert ein realistisches Bild vom Zustand der Anwendung.

HTTP 200 ist ein wichtiges Signal. Aber es ist nur eines von vielen.