Warum ein 200-OK-Health-Check einen vollständigen Serviceausfall verbergen kann
Eine gecachte GET-Anfrage lieferte Erfolg zurück, während der Origin-Server ausgefallen war. Dies führte dazu, dass alle Bestellungen von Käufern stundenlang unbemerkt fehlschlugen.
Automatisch aus dem englischen Original übersetzt.
Ein selbst gehosteter E-Commerce-Dienst schien für den gesamten Abend vollständig funktionsfähig zu sein und lieferte alle fünf Minuten erfolgreiche Statuscodes an das Monitoring-System. In Wirklichkeit war der Backend-Origin-Tunnel bereits Stunden zuvor zusammengebrochen, wodurch jede einzelne Käuferbestellung fehlschlug, während die Frontend-Seite über den Cache weiterhin erreichbar blieb.
Was passiert ist
Der Vorfall begann, als der Origin-Tunnel, der die Edge des Content Delivery Networks (CDN) mit dem Backend-Server verbindet, nicht mehr antwortete. Trotz dieses kritischen Fehlers meldete der automatisierte Health-Check weiterhin, dass der Dienst gesund sei. Der Check führte eine einfache GET-Anfrage auf die käuferseitige Seite aus, die vom CDN aus seinem Cache mit der zuletzt bekannten guten Version des HTML-Codes bedient wurde. Dies führte zu einem 200-OK-Statuscode, der dem Monitoring-System signalisierte, dass alles korrekt funktionierte.
Inzwischen erlebten tatsächliche Nutzer, die versuchten, Einkäufe zu tätigen, einen vollständigen Zusammenbruch. Ihre Browser sendeten POST-Anfragen mit Formulardaten zur Übermittlung von Bestellungen. Im Gegensatz zur statischen HTML-Seite konnten diese dynamischen API-Aufrufe nicht aus dem CDN-Cache bedient werden. Sie wurden direkt an den Origin-Tunnel weitergeleitet, der jedoch tot war. Der Edge-Knoten gab für diese Anfragen eine 1033-Fehlerseite zurück, aber da niemand die benutzerseitigen Fehlerprotokolle aktiv überwachte, blieb der Ausfall beim Operations-Team unbemerkt. Fünf echte Bestellungen aus drei verschiedenen Netzwerken schlugen in diesem Zeitraum fehl, ohne dass Alarme ausgelöst wurden.
Diese Situation entstand durch eine vorherige Korrektur, die ein anderes Problem lösen sollte. Ein früherer Vorfall hatte einen statischen Pfad betroffen, den die Edge unabhängig vom Origin beantwortete, was zu False Positives führte. Das Team korrigierte dies, indem es den Health-Check auf die Käuferseite richtete, die tatsächlich vom Origin abhängt. Allerdings behielten sie die GET-Methode für den Check bei. Während der Pfad korrekt war, war die Methode es nicht, da ein gecachter GET-Check die Lebhaftigkeit der Backend-Verarbeitungslogik nicht überprüft.
Wichtige Details
- Der Health-Check lief alle fünf Minuten und erhielt konsistent eine 200-OK-Antwort vom CDN-Cache.
- Der Origin-Tunnel war mehrere Stunden lang ausgefallen, wodurch alle POST-Anfragen von Käufern mit einem 1033-Fehler fehlschlugen.
- Fünf echte Kaufversuche scheiterten über drei separate Netzwerke hinweg, ohne operative Alarme auszulösen.
- Die vorherige Korrektur änderte das Ziel des Health-Checks auf die Käuferseite, beließ es jedoch fälschlicherweise als GET-Anfrage.
- Eine POST-Anfrage an einen JSON-RPC-Endpunkt hätte den Origin gezwungen zu antworten, wodurch der Ausfall sofort sichtbar geworden wäre.
- Die endgültige Lösung erforderte nur eine einzeilige Änderung, um die Health-Check-Methode von GET auf POST umzustellen.
Hintergrund
Um diesen Fehler zu verstehen, ist es hilfreich, zwischen der Handhabung verschiedener HTTP-Methoden durch CDNs zu unterscheiden. Eine GET-Anfrage ruft Daten ab und ist oft cachebar. CDNs speichern Kopien dieser Antworten an Edge-Standorten nahe bei Nutzern, um Latenz und Last auf dem Origin-Server zu reduzieren. Wenn der Origin ausfällt, kann das CDN diese gecachten Kopien weiterhin bedienen, sodass die Website live erscheint, auch wenn das Backend unerreichbar ist. Dies ist nützlich zum Lesen von Inhalten, aber irreführend für die Überprüfung der Systemgesundheit.
Im Gegensatz dazu werden POST-Anfragen verwendet, um Daten an den Server zu senden, wie z. B. das Absenden eines Formulars oder das Erstellen eines Datensatzes. Diese Anfragen werden im Allgemeinen nicht gecacht, da sie den Zustand der Anwendung ändern. Wenn eine POST-Anfrage eingeht, muss das CDN sie zur Verarbeitung an den Origin-Server weiterleiten. Ist der Origin ausgefallen, schlägt die Anfrage sofort fehl. Daher überprüft ein Health-Check, der GET verwendet, möglicherweise nur die Verfügbarkeit des Caches, während ein POST-Check die Verfügbarkeit der tatsächlichen Anwendungslogik und der Datenbankverbindung überprüft.
Warum es wichtig ist
Für Teams, die ihre eigene Software betreiben, hebt dieser Vorfall eine häufige Falle in der Observability hervor: die Messung des falschen Aspekts. Ein Statuscode ist ein Nachweis über eine spezifische Anfrage, nicht über den gesamten Dienst. Wenn Ihr Health-Check nicht den kritischen Pfad Ihrer Nutzer nachbildet, vermittelt er ein falsches Sicherheitsgefühl. In diesem Fall maß der Check die Resilienz des CDN-Caches statt der Gesundheit des Application-Backends. Diese Unterscheidung ist entscheidend für Self-Hoster, die sich auf automatisiertes Monitoring verlassen, um Ausfälle zu erkennen, bevor Kunden davon betroffen sind.
Die Kosten dieser Fehlkonfiguration waren erheblich in Bezug auf verlorenes Vertrauen und Umsatz. Da das Monitoring-System Erfolg meldete, wurde kein Ingenieur alarmiert, und das Problem bestand über Stunden fort. Die Stille der Logs war trügerisch; die CDN-Logs zeigten erfolgreiche 200-Antworten an und maskierten die 1033-Fehler, die auf den ungecachten Pfaden auftraten. Dies zeigt, dass umfassendes Logging und Alerting die Unterschiede zwischen Edge-Level-Erfolg und Origin-Level-Funktionalität berücksichtigen müssen. Ohne die Abstimmung der Health-Checks auf das Nutzerverhalten riskieren Teams, stille Fehler zu übersehen, die erst dann offensichtlich werden, wenn Kunden sich beschweren.
Was Sie tun können
- Prüfen Sie Ihre Health-Checks daraufhin, ob sie dieselbe HTTP-Methode und denselben Pfad verwenden wie Ihre wichtigsten Nutzeraktionen.
- Ersetzen Sie einfache GET-Checks auf gecachten Seiten durch POST-Anfragen an dynamische Endpunkte, die eine Origin-Verarbeitung erfordern.
- Stellen Sie sicher, dass Ihr Health-Check bestimmte Inhalte im Antwortkörper erwartet, nicht nur einen 200-Statuscode.
- Testen Sie Ihr Monitoring, indem Sie den Origin-Server absichtlich abschalten, um zu sehen, ob der Health-Check den Fehler korrekt meldet.
- Implementieren Sie separate Checks für die CDN-Verfügbarkeit und die Origin-Gesundheit, um zwischen Edge-Caching-Problemen und Backend-Problemen zu unterscheiden.
- Überprüfen Sie Logs sowohl für erfolgreiche als auch für fehlgeschlagene Anfragetypen, um sicherzustellen, dass Ihre Alarme ungecachte, dynamische Interaktionen abdecken.
