Postmortem: Puerta de enlace incorrecta

Resumen#

El 2024-01-11, los servicios de Logto experimentaron una interrupción del servicio con muchos errores 502 Bad Gateway.

• Hora de inicio: Aproximadamente el 2024-01-11 15:28 UTC
• Hora de resolución: Aproximadamente el 2024-01-12 00:49 UTC
• Duración: Aproximadamente 9 horas
• Servicios afectados: Servicio de autenticación de Logto, servicio de Logto Cloud
• Nivel de impacto: Crítico
• Causa raíz: El dominio logto.app expiró y la renovación no se completó.

Cronología#

• 2024-01-11 15:28 UTC Un usuario reporta un error 502 Bad Gateway al acceder al servicio de autenticación de Logto.
• 2024-01-11 15:42 UTC Más usuarios reportan el mismo problema.
• 2024-01-11 15:50 UTC Nuestros miembros del equipo empiezan a investigar el problema y realizan llamadas telefónicas a otros miembros del equipo. Dado que era tarde en la noche para algunos miembros del equipo, las llamadas telefónicas normales no fueron suficientes para despertarlos.
• 2024-01-12 23:54 UTC Descubrimos que el servicio en la nube está enviando solicitudes al servicio de autenticación, pero la solicitud falló debido al error ERR_TLS_CERT_ALTNAME_INVALID.
• 2024-01-12 00:36 UTC Purgamos la caché de DNS para ver si ayudaba. No lo hizo.
• 2024-01-12 00:38 UTC Reemitimos los certificados TLS para ver si ayudaba. No lo hizo.
• 2024-01-12 00:45 UTC Notamos que el dominio logto.app podría haber expirado. Verificamos el registrador del dominio y descubrimos que no se renovó exitosamente y el dominio había expirado.
• 2024-01-12 00:49 UTC La renovación del dominio se completó. Los servicios están volviendo a la normalidad gradualmente.

Análisis del incidente#

¿Qué sucedió?#

Nuestros dominios generalmente se renuevan automáticamente a través de nuestro registrador de dominios. Sin embargo, en esta instancia, el proceso de renovación falló debido a una posible mala configuración. En consecuencia, el dominio logto.app expiró y los registros de DNS se actualizaron para apuntar a la página de estacionamiento del registrador.

Hasta ahora, el servicio de autenticación permanece operativo, pero la mayoría de las solicitudes no pueden llegar a él. La excepción es el inquilino administrador de Logto, que se enlaza al dominio auth.logto.io y no se ve afectado por la expiración.

Además del servicio de autenticación, también tenemos un servicio en la nube que orquesta los inquilinos de Logto y sirve el Logto Cloud Console (una aplicación de frontend).

Cuando un usuario opera el Cloud Console, la aplicación no llama directamente al servicio de autenticación; en cambio, llama al servicio en la nube para todas las operaciones de gestión.

Para alinearse con la API de gestión de Logto, diseñamos un endpoint de "proxy de API de gestión" para delegar solicitudes al servicio de autenticación. Todo el flujo se ve así:

Dado que el dominio *.logto.app tiene un problema de desajuste de certificado, el servicio en la nube (Node.js) rechaza la solicitud y lanza un error.

Normalmente, los errores de solicitud se capturan para evitar que todo el servicio se bloquee. Sin embargo, dado que el error fue propagado desde el módulo proxy, la lógica de manejo de errores existente no pudo capturarlo, lo que resultó en un bloqueo del servicio.

Aunque cada servicio de Logto tiene al menos tres réplicas, todas las réplicas se bloquearon fácilmente debido al error que ocurría en casi todas las solicitudes del Cloud Console. El mecanismo de recuperación automática toma tiempo para activarse, causando que el servicio no esté disponible por un tiempo.

Esta es la razón por la cual los usuarios están viendo errores 502 Bad Gateway (todas las réplicas se bloquearon). Una vez que el servicio en la nube está activo, nuevas solicitudes y solicitudes de reintento del Cloud Console llegan, y el ciclo de bloqueos continúa.

Cuando el servicio en la nube está inactivo, también impacta al servicio de autenticación en ciertos endpoints, mayormente /api/.well-known/sign-in-exp. Este endpoint se utiliza para obtener la configuración de la experiencia de inicio de sesión, que incluye información del conector que necesita ser obtenida del servicio en la nube.

Resolución#

• Renovar manualmente el dominio.

Lecciones aprendidas#

• Siempre configurar monitoreo para la expiración de dominios o comprarlos por una duración más larga.
• Tener en cuenta que las diferencias horarias pueden causar un retraso en la respuesta a incidentes.
• Asegurar que el monitoreo cubra todos los dominios.
• Tener precaución al interactuar con módulos que pueden lanzar excepciones, asegurando que los errores puedan ser capturados y manejados adecuadamente.

Medidas correctivas y preventivas#

• ✅ Agregar monitoreo mensual para la expiración de dominios, ya sea que la renovación automática esté habilitada.
• ✅ Agregar monitoreo para logto.app.
• ✅ Actualizar la lógica de manejo de errores del servicio en la nube para capturar y manejar adecuadamente los errores del proxy.
• ✅ Implementar alertas más fuertes que puedan despertar al equipo para los incidentes antes de contar con un equipo SRE cubierto en todas las zonas horarias.