Postmortem: Gateway Ruim

Resumo#

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

• Horário de início: Por volta de 2024-01-11 15:28 UTC
• Horário de resolução: Por volta 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: Domínio logto.app expirou e a renovação falhou em completar.

Linha do tempo#

• 2024-01-11 15:28 UTC Usuário relata erro 502 Gateway Ruim ao acessar o serviço de autenticação Logto.
• 2024-01-11 15:42 UTC Mais usuários relatam o mesmo problema.
• 2024-01-11 15:50 UTC Nossos membros da equipe começam a investigar o problema e fazem ligações para outros membros da equipe. Como era tarde da noite para alguns membros, chamadas normais não foram suficientes para acordá-los.
• 2024-01-12 23:54 UTC Descobrimos que o serviço cloud está enviando solicitações para o serviço de autenticação, mas a solicitação falhou devido ao erro ERR_TLS_CERT_ALTNAME_INVALID.
• 2024-01-12 00:36 UTC Limpamos o cache DNS para ver se ajudava. Não ajudou.
• 2024-01-12 00:38 UTC Reemitiu-se os certificados TLS para ver se ajudava. Não ajudou.
• 2024-01-12 00:45 UTC Notamos que o domínio logto.app pode ter expirado. Verificamos o registrador de domínios e descobrimos que não renovou com sucesso e o domínio expirou.
• 2024-01-12 00:49 UTC A renovação do domínio foi concluída. Os serviços estão voltando ao normal gradualmente.

Análise do incidente#

O que aconteceu?#

Nossos domínios são normalmente renovados automaticamente por meio do nosso registrador de domínios. No entanto, nesta instância, o processo de renovação falhou devido a uma potencial configuração incorreta. Consequentemente, o domínio logto.app expirou, e os registros DNS foram atualizados para apontar para a página de estacionamento do registrador.

Até agora, o serviço de autenticação continua operacional, mas a maioria das solicitações não consegue alcançá-lo. A exceção é o tenant admin do Logto, que está vinculado ao domínio auth.logto.io e não é afetado pela expiração.

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

Quando um usuário opera o Cloud Console, o aplicativo não chama diretamente o serviço de autenticação; ao invés disso, ele chama o serviço cloud para todas as operações de gerenciamento.

Para alinhar com a API de Gerenciamento Logto, projetamos um endpoint "proxy da API de Gerenciamento" para delegar solicitações ao serviço de autenticação. O fluxo completo é assim:

Como o domínio *.logto.app tem um problema de incompatibilidade de certificado, o serviço cloud (Node.js) rejeita a solicitação e gera um erro.

Normalmente, os erros de solicitação são capturados para evitar o colapso total do serviço. No entanto, como o erro foi propagado do módulo proxy, a lógica de tratamento de erro existente não foi capaz de capturá-lo, levando a um colapso do serviço.

Apesar de todo serviço Logto ter pelo menos três réplicas, todas as réplicas colapsaram facilmente devido ao erro ocorrer em quase todas as solicitações do Cloud Console. Leva tempo para o mecanismo de auto-recuperação entrar em ação, causando a indisponibilidade do serviço por um tempo.

Essa é a razão pela qual os usuários veem erros 502 Gateway Ruim (todas as réplicas colapsaram). Uma vez que o serviço cloud está ativo, novas solicitações e tentativas de retry do Cloud Console entram, e o ciclo de colapso continua.

Quando o serviço cloud está fora do ar, afeta também o serviço de autenticação em certos endpoints, principalmente /api/.well-known/sign-in-exp. Este endpoint é usado para buscar a configuração de experiência de login, que inclui informações de conectores que precisam ser buscadas no serviço cloud.

Resolução#

• Renovar manualmente o domínio.

Lições aprendidas#

• Sempre configure monitoramento para expiração de domínio ou compre por uma duração mais longa.
• Esteja ciente de que diferenças de fuso horário podem causar atraso na resposta a incidentes.
• Certifique-se de que o monitoramento abrange todos os domínios.
• Tenha cautela ao interagir com módulos que podem lançar exceções, garantindo que os erros possam ser capturados e tratados adequadamente.

Medidas corretivas e preventivas#

• ✅ Adicionar monitoramento mensal para expiração de domínio se a renovação automática estiver ativada.
• ✅ Adicionar monitoramento para logto.app.
• ✅ Atualizar a lógica de tratamento de erros do serviço cloud para capturar e tratar adequadamente os erros de proxy.
• ✅ Implementar alertas mais fortes que possam acordar a equipe para incidentes antes de ter um time de SRE coberto em todos os fusos horários.