Rapport d'incident : Mauvaise passerelle
Rapport d'incident pour l'interruption du service Logto le 11-01-2024 due à un échec de renouvellement de domaine.
Rapport d'incident pour l'interruption du service Logto le 11-01-2024 due à un échec de renouvellement de domaine.
Le 11-01-2024, les services Logto ont subi une interruption de service avec de nombreuses erreurs 502 Bad Gateway.
logto.app a expiré et le renouvellement n'a pas été complété.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é.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.
logto.app.