Postmortem: Bad Gateway

Riassunto#

Il 2024-01-11, i servizi Logto hanno riscontrato un'interruzione del servizio con molti errori 502 Bad Gateway.

• Ora di inizio: Circa il 2024-01-11 15:28 UTC
• Ora di risoluzione: Circa il 2024-01-12 00:49 UTC
• Durata: Circa 9 ore
• Servizi interessati: Servizio di autenticazione Logto, Servizio Logto Cloud
• Livello di impatto: Critico
• Causa principale: Il dominio logto.app è scaduto e il rinnovo non è stato completato.

Cronologia#

• 2024-01-11 15:28 UTC Utente segnala errore 502 Bad Gateway quando accede al servizio di autenticazione Logto.
• 2024-01-11 15:42 UTC Più utenti segnalano lo stesso problema.
• 2024-01-11 15:50 UTC I nostri membri del team iniziano a indagare sul problema e fanno telefonate ad altri membri del team. Poiché era tardi la notte per alcuni membri del team, le telefonate normali non erano abbastanza forti da svegliarli.
• 2024-01-12 23:54 UTC Scopriamo che il servizio cloud sta inviando richieste al servizio di autenticazione, ma la richiesta ha fallito a causa dell'errore ERR_TLS_CERT_ALTNAME_INVALID.
• 2024-01-12 00:36 UTC Abbiamo svuotato la cache DNS per vedere se aiuta. Non ha aiutato.
• 2024-01-12 00:38 UTC Abbiamo rilasciato nuovamente i certificati TLS per vedere se aiuta. Non ha aiutato.
• 2024-01-12 00:45 UTC Abbiamo notato che il dominio logto.app potrebbe essere scaduto. Abbiamo controllato il registrar del dominio e abbiamo scoperto che non è stato rinnovato con successo e il dominio era scaduto.
• 2024-01-12 00:49 UTC Il rinnovo del dominio è completato. I servizi stanno tornando gradualmente alla normalità.

Analisi dell'incidente#

Cosa è successo?#

I nostri domini vengono solitamente rinnovati automaticamente attraverso il nostro registrar di domini. Tuttavia, in questo caso, il processo di rinnovo è fallito a causa di una possibile configurazione errata. Di conseguenza, il dominio logto.app è scaduto e i record DNS sono stati aggiornati per puntare alla pagina di parcheggio del registrar.

Al momento, il servizio di autenticazione rimane operativo, ma la maggior parte delle richieste non può raggiungerlo. L'eccezione è il tenant amministrativo di Logto, che si lega al dominio auth.logto.io e non è influenzato dalla scadenza.

Oltre al servizio di autenticazione, abbiamo anche un Servizio Cloud che orchestra i tenant Logto e fornisce il Logto Cloud Console (una app frontend).

Quando un utente opera nel Cloud Console, l'app non chiama direttamente il servizio di autenticazione; invece, chiama il Servizio Cloud per tutte le operazioni di gestione.

Per allinearci con l'API di gestione di Logto, abbiamo progettato un endpoint "proxy dell'API di gestione" per delegare le richieste al servizio di autenticazione. L'intero flusso appare così:

Poiché il dominio *.logto.app ha un problema di mancata corrispondenza del certificato, il Servizio Cloud (Node.js) rifiuta la richiesta e genera un errore.

Normalmente, gli errori di richiesta vengono catturati per evitare che l'intero servizio vada in crash. Tuttavia, poiché l'errore è stato propagato dal modulo proxy, la logica di gestione degli errori esistente non è stata in grado di catturarlo, portando a un crash del servizio.

Sebbene ogni servizio Logto abbia almeno tre repliche, tutte le repliche sono andate facilmente in crash a causa dell'errore che si verificava in quasi tutte le richieste dal Cloud Console. Il meccanismo di ripristino automatico richiede tempo per attivarsi, causando l'indisponibilità del servizio per un po'.

Questo è il motivo per cui gli utenti vedono errori 502 Bad Gateway (tutte le repliche sono andate in crash). Una volta che il servizio Cloud è attivo, entrano nuove richieste dal Cloud Console e riprovano, e il ciclo di crash continua.

Quando il Servizio Cloud è giù, ha anche un impatto sul servizio di autenticazione per determinati endpoint, principalmente /api/.well-known/sign-in-exp. Questo endpoint viene utilizzato per recuperare la configurazione dell'esperienza di accesso che include le informazioni sul connettore che devono essere recuperate dal Servizio Cloud.

Risoluzione#

• Rinnovare manualmente il dominio.

Lezione appresa#

• Impostare sempre il monitoraggio per la scadenza del dominio o acquistare per una durata più lunga.
• Essere consapevoli che le differenze di fuso orario possono causare ritardi nella risposta agli incidenti.
• Assicurarsi che il monitoraggio copra tutti i domini.
• Prestare attenzione quando si interagisce con moduli lanciabili, assicurandosi che gli errori possano essere catturati e gestiti correttamente.

Misure correttive e preventive#

• ✅ Aggiungere il monitoraggio mensile per la scadenza del dominio, indipendentemente dal fatto che il rinnovo automatico sia abilitato.
• ✅ Aggiungere il monitoraggio per logto.app.
• ✅ Aggiornare la logica di gestione degli errori del Servizio Cloud per catturare e gestire correttamente gli errori del proxy.
• ✅ Implementare avvisi più forti che possano svegliare il team per gli incidenti prima di avere un team SRE coperto su tutti i fusi orari.