Obduktion: Dålig Gateway

Sammanfattning#

Den 2024-01-11 upplevde Logto tjänster ett avbrott med många 502 Bad Gateway fel.

• Starttid: Runt 2024-01-11 15:28 UTC
• Rättad tid: Runt 2024-01-12 00:49 UTC
• Varaktighet: Cirka 9 timmar
• Påverkade tjänster: Logto auth service, Logto Cloud service
• Påverkan nivå: Kritisk
• Grundorsak: logto.app domän löpte ut, och förnyelsen misslyckades.

Tidslinje#

• 2024-01-11 15:28 UTC Användare rapporterar 502 Bad Gateway fel vid åtkomst till Logto auth service.
• 2024-01-11 15:42 UTC Fler användare rapporterar samma problem.
• 2024-01-11 15:50 UTC Våra teammedlemmar börjar undersöka problemet och ringer andra teammedlemmar. Eftersom det var sent på kvällen för vissa teammedlemmar, var vanliga telefonsamtal inte tillräckligt starka för att väcka dem.
• 2024-01-12 23:54 UTC Vi upptäcker att molntjänsten skickar förfrågningar till auth-tjänsten, men förfrågningen misslyckades på grund av ERR_TLS_CERT_ALTNAME_INVALID fel.
• 2024-01-12 00:36 UTC Vi rensade DNS-cache för att se om det hjälper. Det gjorde det inte.
• 2024-01-12 00:38 UTC Vi utfärdade om TLS-certifikaten för att se om det hjälper. Det gjorde det inte.
• 2024-01-12 00:45 UTC Vi märkte att logto.app domän kan ha löpt ut. Vi kontrollerade domänregistratorn och upptäckte att den inte förnyades framgångsrikt och domänen hade löpt ut.
• 2024-01-12 00:49 UTC Domänförnyelsen slutfördes. Tjänster hämtar sig tillbaka till det normala gradvis.

Incidentanalys#

Vad hände?#

Våra domäner förnyas vanligtvis automatiskt genom vår domänregistrator. Men i detta fall, misslyckades förnyelseprocessen på grund av en möjlig felkonfiguration. Följaktligen löpte logto.app domän ut och DNS-posterna uppdaterades för att peka på registratorns parkeringsplats.

För närvarande är auth-tjänsten fortfarande operativ, men de flesta förfrågningar kan inte nå den. Undantaget är Logto admin-tenant som binder till auth.logto.io domänen och påverkas inte av utgången.

Utöver auth-tjänsten har vi också en molntjänst som orkestrerar Logto-tenanterna och tjänar Logto Cloud Console (en frontend-app).

När en användare arbetar med Cloud Console ringer appen inte direkt auth-tjänsten; istället kallar den molntjänsten för alla hanteringsoperationer.

För att anpassa sig till Logto Management API designade vi en "Management API proxy" slutpunkt för att delegera förfrågningar till auth-tjänsten. Hela flödet ser ut så här:

Eftersom *.logto.app domänen har ett certifikatmatchningsproblem, avvisar molntjänsten (Node.js) förfrågan och kastar ett fel.

Normalt fångas förfrågningsfel för att förhindra att hela tjänsten kraschar. Men eftersom felet propagerades från proxymodulen kunde den befintliga felhanteringslogiken inte fånga det, vilket ledde till en tjänstkrasch.

Även om varje Logto tjänst har minst tre repliker, kraschade alla repliker lätt på grund av felet uppstod i nästan varje förfrågan från Cloud Console. Det tar tid för den automatiska återhämtningsmekanismen att slå ihjäl, vilket gör att tjänsten blir otillgänglig ett tag.

Detta är anledningen till att användare ser 502 Bad Gateway fel (alla repliker kraschade). När molntjänsten är uppe kommer nya och återförsökande Cloud Console förfrågningar in och kraschslingan fortsätter.

När molntjänsten är nere påverkar det också auth-tjänsten för vissa slutpunkter, mest /api/.well-known/sign-in-exp. Denna slutpunkt används för att hämta inloggningskonfigurationen som inkluderar kontaktinformation som behöver hämtas från molntjänsten.

Upplösning#

• Förnya domänen manuellt.

Lärdomar#

• Sätt alltid upp övervakning för domänutgång eller köp för en längre period.
• Var medveten om att tidsskillnader kan orsaka förseningar i incidentrespons.
• Se till att övervakningen täcker alla domäner.
• Utöva försiktighet vid interaktion med slängda moduler, se till att fel kan fångas och hanteras korrekt.

Korrigerande och förebyggande åtgärder#

• ✅ Lägg till månatlig övervakning för domänutgång oavsett om automatisk förnyelse är aktiverad.
• ✅ Lägg till övervakning för logto.app.
• ✅ Uppdatera molntjänstens felhanteringslogik för att fånga och hantera proxyfel korrekt.
• ✅ Implementera starkare larm som kan väcka teamet för incidenter innan man har ett SRE-team som täcker alla tidszoner.