Postmortem: Slechte Gateway
Incidentrapport voor de Logto-service uitval op 2024-01-11 vanwege domeinnaamvernieuwing die mislukt is.
Incidentrapport voor de Logto-service uitval op 2024-01-11 vanwege domeinnaamvernieuwing die mislukt is.
Op 2024-01-11 ervoeren Logto-diensten een service-uitval met veel 502 Slechte Gateway-fouten.
logto.app domein verlopen, en de vernieuwing is niet voltooid.logto.app domein was verlopen. We controleerden de domeinregistrar en ontdekten dat het zich niet met succes vernieuwde en het domein was verlopen.Onze domeinen worden normaal automatisch vernieuwd via onze domeinregistrar. In dit geval mislukte het vernieuwing proces echter door een mogelijke verkeerde configuratie. Hierdoor is het logto.app domein verlopen en zijn de DNS records bijgewerkt om naar de parkeerpagina van de registrar te wijzen.
Op dit moment blijft de authenticatiedienst operationeel, maar de meeste verzoeken kunnen het niet bereiken. De uitzondering is de Logto beheer huurders, die aan het auth.logto.io domein zijn gekoppeld en niet door het verlopen worden beïnvloed.
Naast de authenticatiedienst hebben we ook een Clouddienst die de Logto huurders orkestreert en de Logto Cloud Console (een frontend app) bedient.
Wanneer een gebruiker de Cloud Console gebruikt, roept de app niet rechtstreeks de authenticatiedienst aan; in plaats daarvan roept het de Clouddienst aan voor alle beheershandelingen.
Om aan te sluiten bij de Logto Management API, hebben we een "Management API proxy"-endpoint ontworpen om verzoeken door te sturen naar de authenticatiedienst. De volledige flow ziet er zo uit:
Omdat het *.logto.app domein een certificaat mismatchprobleem heeft, wijst de Clouddienst (Node.js) het verzoek af en werpt een fout op.
Normaal gesproken worden verzoekfouten opgevangen om te voorkomen dat de hele dienst crasht. Maar omdat de fout werd doorgegeven vanuit de proxymodule, kon de bestaande foutafhandelingslogica deze niet opvangen, wat leidde tot een crash van de dienst.
Hoewel elke Logto-dienst minstens drie replica's heeft, crashten alle replica's gemakkelijk vanwege de fout die in bijna elk verzoek van de Cloud Console voorkwam. Het kost tijd voor het auto-herstelmechanisme om in werking te treden, waardoor de dienst enige tijd niet beschikbaar was.
Dit is de reden waarom gebruikers 502 Slechte Gateway fouten zien (alle replica's crashten). Zodra de Clouddienst weer omhoog is, komen nieuwe en opnieuw proberende Cloud Console verzoeken binnen, en de crashlus gaat verder.
Wanneer de Clouddienst niet beschikbaar is, beïnvloedt dit ook de authenticatiedienst voor bepaalde eindpunten, meestal /api/.well-known/sign-in-exp. Dit eindpunt wordt gebruikt om de sign-in ervaring configuratie op te halen, inclusief connectorinformatie die van de Clouddienst moet worden opgehaald.
logto.app.