Rapport d'incident : Mauvaise passerelle

Résumé#

Le 11-01-2024, les services Logto ont subi une interruption de service avec de nombreuses erreurs 502 Bad Gateway.

• Heure de début : Environ 11-01-2024 15:28 UTC
• Heure de résolution : Environ 12-01-2024 00:49 UTC
• Durée : Environ 9 heures
• Services affectés : Service d'authentification Logto, Service Logto Cloud
• Niveau d'impact : Critique
• Cause principale : Le domaine logto.app a expiré et le renouvellement n'a pas été complété.

Chronologie#

• 11-01-2024 15:28 UTC : Un utilisateur signale une erreur 502 Bad Gateway lors de l'accès au service d'authentification Logto.
• 11-01-2024 15:42 UTC : Plus d'utilisateurs signalent le même problème.
• 11-01-2024 15:50 UTC : Nos membres de l'équipe commencent à enquêter sur le problème et appellent d'autres membres de l'équipe. Comme il était tard dans la nuit pour certains membres de l'équipe, les appels téléphoniques normaux n'étaient pas suffisants pour les réveiller.
• 12-01-2024 23:54 UTC : Nous découvrons que le service cloud envoie des requêtes au service d'authentification, mais la requête a échoué en raison d'une erreur ERR_TLS_CERT_ALTNAME_INVALID.
• 12-01-2024 00:36 UTC : Nous avons purgé le cache DNS pour voir si cela aide. Ce n'était pas le cas.
• 12-01-2024 00:38 UTC : Nous avons réémis les certificats TLS pour voir si cela aide. Ce n'était pas le cas.
• 12-01-2024 00:45 UTC : Nous avons remarqué que le domaine logto.app pouvait avoir expiré. Nous avons vérifié le registraire de domaine et avons découvert qu'il ne s'était pas renouvelé avec succès et que le domaine était expiré.
• 12-01-2024 00:49 UTC : Le renouvellement de domaine a été complété. Les services reprennent progressivement la normale.

Analyse de l'incident#

Que s'est-il passé ?#

Nos domaines sont généralement renouvelés automatiquement par notre registraire de domaine. Cependant, dans ce cas, le processus de renouvellement a échoué en raison d'une éventuelle mauvaise configuration. Par conséquent, le domaine logto.app a expiré et les enregistrements DNS ont été mis à jour pour pointer vers la page de parking du registraire.

Pour l'instant, le service d'authentification reste opérationnel, mais la plupart des requêtes ne peuvent pas l'atteindre. L'exception est le tenant admin de Logto, qui est lié au domaine auth.logto.io et reste non affecté par l'expiration.

En plus du service d'authentification, nous avons également un service Cloud qui orchestre les tenants de Logto et sert la Logto Cloud Console (une application frontend).

Lorsqu'un utilisateur utilise la Cloud Console, l'application n'appelle pas directement le service d'authentification ; elle appelle plutôt le service Cloud pour toutes les opérations de gestion.

Pour s'aligner avec l'API de gestion de Logto, nous avons conçu un point de terminaison "proxy API de gestion" pour déléguer les requêtes au service d'authentification. Le flux complet est le suivant :

Puisque le domaine *.logto.app a un problème de mismatch de certificat, le service Cloud (Node.js) rejette la requête et lance une erreur.

Normalement, les erreurs de requêtes sont interceptées pour éviter que l'ensemble du service ne s'effondre. Cependant, puisque l'erreur provenait du module proxy, la logique de gestion des erreurs existante n'a pas pu l'intercepter, entraînant un plantage du service.

Bien que chaque service Logto ait au moins trois réplicas, tous ont planté facilement en raison de l'erreur survenant dans presque chaque requête de la Cloud Console. Il faut du temps pour que le mécanisme de récupération automatique s'enclenche, ce qui provoque l'indisponibilité du service pendant un certain temps.

C'est la raison pour laquelle les utilisateurs ont vu des erreurs 502 Bad Gateway (tous les réplicas ont planté). Une fois le service Cloud en fonction, de nouvelles requêtes et des requêtes en réessai de la Cloud Console arrivent, et la boucle de crash se poursuit.

Lorsque le service Cloud est hors ligne, il impacte également le service d'authentification pour certains points de terminaison, principalement /api/.well-known/sign-in-exp. Ce point de terminaison est utilisé pour récupérer la configuration de l'expérience de connexion qui comprend des informations de connecteur devant être récupérées depuis le service Cloud.

Résolution#

• Renouveler manuellement le domaine.

Leçon apprise#

• Toujours mettre en place une surveillance pour l'expiration des domaines ou pour un achat de plus longue durée.
• Garder à l'esprit que les différences de fuseaux horaires peuvent entraîner un retard dans la réponse aux incidents.
• S'assurer que la surveillance couvre tous les domaines.
• Faire preuve de prudence en interagissant avec des modules susceptibles de générer des erreurs, en s'assurant que les erreurs peuvent être interceptées et gérées correctement.

Mesures correctives et préventives#

• ✅ Ajouter une surveillance mensuelle pour l'expiration des domaines, que le renouvellement automatique soit activé ou non.
• ✅ Ajouter une surveillance pour logto.app.
• ✅ Mettre à jour la logique de gestion des erreurs du service Cloud pour intercepter et gérer correctement les erreurs du proxy.
• ✅ Mettre en place des alertes plus fortes qui peuvent réveiller l'équipe pour des incidents avant d'avoir une équipe SRE couvrant tous les fuseaux horaires.