Postmortem: Gateway Incorreto

Resumo#

Em 2024-01-11, os serviços Logto experimentaram uma interrupção com muitos erros 502 Gateway Incorreto.

• Início: Cerca de 2024-01-11 15:28 UTC
• Resolução: Cerca de 2024-01-12 00:49 UTC
• Duração: Cerca de 9 horas
• Serviços afetados: Serviço de autenticação Logto, Serviço Logto Cloud
• Nível de impacto: Crítico
• Causa raiz: O domínio logto.app expirou, e a renovação falhou em ser concluída.

Cronologia#

• 2024-01-11 15:28 UTC Relato de erro 502 Gateway Incorreto ao acessar o serviço de autenticação Logto.
• 2024-01-11 15:42 UTC Mais utilizadores relatam o mesmo problema.
• 2024-01-11 15:50 UTC Os nossos membros da equipa começam a investigar o problema e fazem chamadas telefónicas para outros membros. Como era tarde da noite para alguns membros da equipa, as chamadas normais não foram suficientes para os acordar.
• 2024-01-12 23:54 UTC Descobrimos que o serviço na nuvem está a enviar pedidos para o serviço de autenticação, mas o pedido falhou devido a um erro ERR_TLS_CERT_ALTNAME_INVALID.
• 2024-01-12 00:36 UTC Limpámos a cache DNS para ver se ajudava. Não ajudou.
• 2024-01-12 00:38 UTC Reemitimos os certificados TLS para ver se ajudava. Não ajudou.
• 2024-01-12 00:45 UTC Notámos que o domínio logto.app podia ter expirado. Verificámos o registrador do domínio e descobrimos que não foi renovado com sucesso e o domínio estava expirado.
• 2024-01-12 00:49 UTC A renovação do domínio foi concluída. Os serviços estão a voltar ao normal gradualmente.

Análise do Incidente#

O que aconteceu?#

Os nossos domínios são normalmente renovados automaticamente através do nosso registrador de domínios. No entanto, neste caso, o processo de renovação falhou devido a uma potencial configuração errada. Consequentemente, o domínio logto.app expirou e os registos DNS foram atualizados para apontar para a página de estacionamento do registrador.

De momento, o serviço de autenticação continua operacional, mas a maioria dos pedidos não o consegue alcançar. A exceção é o inquilino admin Logto, que está ligado ao domínio auth.logto.io e não foi afetado pela expiração.

Além do serviço de autenticação, também temos um serviço Cloud que orquestra os inquilinos Logto e serve o Logto Cloud Console (uma aplicação frontend).

Quando um utilizador opera no Cloud Console, a aplicação não chama diretamente o serviço de autenticação; em vez disso, chama o serviço Cloud para todas as operações de gestão.

Para alinhar com a API de Gestão Logto, projetámos um ponto final de "proxy de API de Gestão" para delegar pedidos ao serviço de autenticação. O fluxo completo parece assim:

Já que o domínio *.logto.app tem um problema de incompatibilidade de certificado, o serviço Cloud (Node.js) rejeita o pedido e gera um erro.

Normalmente, erros de pedido são capturados para evitar que o serviço inteiro falhe. No entanto, como o erro foi propagado do módulo de proxy, a lógica de manipulação de erros existente não foi capaz de capturá-lo, levando a uma falha no serviço.

Embora cada serviço Logto tenha pelo menos três réplicas, todas as réplicas falharam facilmente devido ao erro ocorrer em quase todos os pedidos do Cloud Console. Leva tempo para o mecanismo de recuperação automática começar, causando a indisponibilidade do serviço por um tempo.

Esta é a razão pela qual os utilizadores estão a ver erros 502 Gateway Incorreto (todas as réplicas falharam). Quando o serviço Cloud volta a estar operacional, novos pedidos do Cloud Console e aqueles em reintento chegam, e o ciclo de falhas continua.

Quando o serviço Cloud está inativo, também afeta o serviço de autenticação para certos pontos finais, principalmente /api/.well-known/sign-in-exp. Este ponto final é usado para buscar a configuração de experiência de início de sessão, que inclui informações de conector que precisam ser buscadas do serviço Cloud.

Resolução#

• Renovar manualmente o domínio.

Lições aprendidas#

• Configurar sempre monitoramento para expiração de domínio ou adquirir por uma duração mais longa.
• Estar ciente de que diferenças de fuso horário podem causar atraso na resposta a incidentes.
• Garantir que o monitoramento cobre todos os domínios.
• Exercitar cautela ao interagir com módulos que podem lançar exceções, garantindo que erros possam ser capturados e tratados adequadamente.

Medidas corretivas e preventivas#

• ✅ Adicionar monitoramento mensal para expiração de domínio, seja renovação automática ativada ou não.
• ✅ Adicionar monitoramento para logto.app.
• ✅ Atualizar a lógica de tratamento de erros do serviço Cloud para capturar e tratar erros de proxy adequadamente.
• ✅ Implementar alertas mais fortes que possam acordar a equipa para incidentes antes de ter uma equipa SRE com cobertura de todos os fusos horários.