Postmortem: Bad Gateway

Zusammenfassung#

Am 2024-01-11 erlebten die Logto-Dienste einen Dienstausfall mit vielen 502 Bad Gateway-Fehlern.

• Beginn der Störung: Um 2024-01-11 15:28 UTC
• Behebung der Störung: Um 2024-01-12 00:49 UTC
• Dauer: Etwa 9 Stunden
• Betroffene Dienste: Logto Auth-Dienst, Logto Cloud-Dienst
• Auswirkungsniveau: Kritisch
• Grundursache: logto.app-Domain ist abgelaufen, und die Verlängerung konnte nicht abgeschlossen werden.

Zeitachse#

• 2024-01-11 15:28 UTC Benutzer berichten von 502 Bad Gateway-Fehler beim Zugriff auf den Logto Auth-Dienst.
• 2024-01-11 15:42 UTC Mehr Benutzer berichten über das gleiche Problem.
• 2024-01-11 15:50 UTC Unsere Teammitglieder beginnen mit der Untersuchung des Problems und rufen andere Teammitglieder an. Da es für einige Teammitglieder spät in der Nacht war, waren normale Anrufe nicht stark genug, um sie zu wecken.
• 2024-01-12 23:54 UTC Wir stellen fest, dass der Cloud-Dienst Anfragen an den Auth-Dienst sendet, aber die Anfrage aufgrund eines ERR_TLS_CERT_ALTNAME_INVALID-Fehlers nicht erfolgreich ist.
• 2024-01-12 00:36 UTC Wir löschten den DNS-Cache, um zu sehen, ob es hilft. Das tat es nicht.
• 2024-01-12 00:38 UTC Wir stellten die TLS-Zertifikate erneut aus, um zu sehen, ob es hilft. Das tat es nicht.
• 2024-01-12 00:45 UTC Wir bemerkten, dass die logto.app-Domain möglicherweise abgelaufen ist. Wir überprüften den Domain-Registrar und stellten fest, dass sie nicht erfolgreich verlängert wurde und die Domain abgelaufen war.
• 2024-01-12 00:49 UTC Die Domainverlängerung wurde abgeschlossen. Dienste kehren allmählich zur Normalität zurück.

Vorfallanalyse#

Was ist passiert?#

Unsere Domains werden normalerweise automatisch über unseren Domain-Registrar verlängert. In diesem Fall jedoch schlug der Verlängerungsprozess aufgrund einer möglichen Fehlkonfiguration fehl. Folglich lief die logto.app-Domain ab und die DNS-Einträge wurden aktualisiert, um auf die Parkplatzseite des Registrars zu verweisen.

Der Auth-Dienst ist noch in Betrieb, aber die meisten Anfragen können ihn nicht erreichen. Eine Ausnahme ist der Logto-Admin-Mieter, der an die auth.logto.io-Domain gebunden ist und von der Ablaufzeit nicht betroffen ist.

Zusätzlich zum Auth-Dienst haben wir auch einen Cloud-Dienst, der die Logto-Mieter orchestriert und die Logto Cloud-Konsole (eine Frontend-App) bereitstellt.

Wenn ein Benutzer die Cloud-Konsole bedient, ruft die App den Auth-Dienst nicht direkt auf; stattdessen ruft sie den Cloud-Dienst für alle Verwaltungsoperationen auf.

Um dem Logto-Management-API zu entsprechen, haben wir einen "Management-API-Proxy"-Endpunkt entworfen, um Anforderungen an den Auth-Dienst zu delegieren. Der gesamte Ablauf sieht so aus:

Da die *.logto.app-Domain ein Zertifikatsfehlerproblem hat, lehnt der Cloud-Dienst (Node.js) die Anfrage ab und wirft einen Fehler.

Normalerweise werden Anforderungsfehler abgefangen, um zu verhindern, dass der gesamte Dienst abstürzt. Da der Fehler jedoch vom Proxy-Modul weitergegeben wurde, konnte die bestehende Fehlerbehandlungslogik ihn nicht abfangen, was zu einem Dienstabsturz führte.

Obwohl jeder Logto-Dienst mindestens drei Replikate hat, stürzten alle Replikate leicht ab, da der Fehler bei fast jeder Anfrage aus der Cloud-Konsole auftrat. Es dauert, bis der Selbstheilungsmechanismus greift, was den Dienst für eine Weile nicht verfügbar macht.

Das ist der Grund, warum Benutzer 502 Bad Gateway-Fehler sehen (alle Replikate sind abgestürzt). Sobald der Cloud-Dienst wieder verfügbar ist, treffen neue und wiederholte Cloud-Konsolenanfragen ein, und die Absturzschleife geht weiter.

Wenn der Cloud-Dienst ausfällt, hat dies auch Auswirkungen auf den Auth-Dienst für bestimmte Endpunkte, überwiegend /api/.well-known/sign-in-exp. Dieser Endpunkt wird verwendet, um die Anmeldeerfahrungskonfiguration abzurufen, die Connector-Informationen enthält, die vom Cloud-Dienst abgerufen werden müssen.

Lösung#

• Domain manuell verlängen.

Lektion gelernt#

• Immer Überwachung für Domainablauf einrichten oder eine längere Laufzeit kaufen.
• Bewusst sein, dass Zeitzonenunterschiede zu Verzögerungen bei der Reaktion auf Vorfälle führen können.
• Sicherstellen, dass alle Domains überwacht werden.
• Vorsicht walten lassen beim Umgang mit auslöserfähigen Modulen, um sicherzustellen, dass Fehler ordnungsgemäß abgefangen und behandelt werden können.

Korrektur- und Präventivmaßnahmen#

• ✅ Monatliche Überwachung für Domainablauf hinzufügen, unabhängig davon, ob eine automatische Verlängerung aktiviert ist.
• ✅ Überwachung für logto.app hinzufügen.
• ✅ Fehlerbehandlungslogik des Cloud-Dienstes aktualisieren, um Proxy-Fehler ordnungsgemäß zu erfassen und zu behandeln.
• ✅ Stärkere Alarme implementieren, die das Team bei Vorfällen wecken können, bevor ein rund um die Uhr verfügbarer SRE-Team vorhanden ist.