REL11-BP06 Enviar notificações quando os eventos afetarem a disponibilidade
As notificações são enviadas após a detecção de limites violados, mesmo que o evento causado pelo problema tenha sido resolvido automaticamente.
A correção automatizada permite que a workload seja confiável. No entanto, ele também pode obscurecer problemas subjacentes que precisam ser resolvidos. Implemente eventos e monitoramento apropriados para que você possa detectar padrões de problemas, incluindo aqueles abordados pela correção automática, para que você possa resolver problemas de causa-raiz.
Os sistemas resilientes são projetados para que os eventos de degradação sejam comunicados imediatamente às equipes apropriadas. Essas notificações devem ser enviadas por meio de um ou vários canais de comunicação.
Resultado desejado: Os alertas são enviados imediatamente às equipes de operações quando os limites são violados. Esses alertas podem incluir taxas de erro, latência ou outras métricas importantes de indicadores-chave de performance (KPI), permitindo que esses problemas sejam resolvidos o mais rápido possível e o impacto do usuário seja evitado ou minimizado.
Antipadrões comuns:
-
Enviar muitos alarmes.
-
Enviar alarmes que não resultam em ações concretas.
-
Definir limites de alarme muito altos (supersensíveis) ou muito baixos (subsensíveis).
-
Não enviar alarmes para dependências externas.
-
Não considerar falhas cinzentas ao projetar monitoramento e alarmes.
-
Executar a automação da correção, mas sem notificar a equipe apropriada de que a correção era necessária.
Benefícios de estabelecer esta prática recomendada: As notificações de recuperação alertam as equipes operacionais e empresariais sobre as degradações do serviço, para que possam reagir imediatamente a fim de minimizar o tempo médio de detecção (MTTD) e o tempo médio de reparo (MTTR). As notificações de eventos de recuperação também garantem que você não ignore problemas que ocorrem com pouca frequência.
Nível de risco exposto se esta prática recomendada não for estabelecida: Médio. A falha na implementação de mecanismos adequados de monitoramento e notificação de eventos pode resultar em falha na detecção de padrões de problemas, incluindo aqueles resolvidos pela recuperação automática. Uma equipe só será informada da degradação do sistema quando os usuários entrarem em contato com o atendimento ao cliente ou por acaso.
Orientações para a implementação
Ao definir uma estratégia de monitoramento, um alarme acionado é um evento comum. Esse evento provavelmente conteria um identificador para o alarme, o estado do alarme (como EM ALARME ou OK) e detalhes do que o desencadeou. Em muitos casos, deve-se detectar um evento de alarme e enviar uma notificação por e-mail. Este é um exemplo de uma ação em um alarme. A notificação do alarme é fundamental para a observabilidade, pois informa às pessoas certas que há um problema. No entanto, quando a ação sobre eventos amadurece em sua solução de observabilidade, ela pode corrigir automaticamente o problema sem a necessidade de intervenção humana.
Depois que os alarmes de monitoramento de KPI forem estabelecidos, os alertas deverão ser enviados às equipes apropriadas quando os limites forem excedidos. Esses alertas também podem ser usados para acionar processos automatizados que tentarão remediar a degradação.
Para um monitoramento de limite mais complexo, considere alarmes compostos. Eles usam vários alarmes de monitoramento de KPI para criar um alerta com base na lógica operacional de negócios. Os alarmes do CloudWatch podem ser configurados para enviar e-mails ou registrar incidentes em sistemas de rastreamento de incidentes de terceiros usando a integração com o Amazon SNS ou Amazon EventBridge.
Etapas para a implementação
Crie vários tipos de alarme com base na forma como as workloads são monitoradas, por exemplo:
-
Os alarmes de aplicações são usados para detectar quando alguma parte da workload não está funcionando adequadamente.
-
Alarmes de infraestrutura indicam quando escalar os recursos. Os alarmes podem ser exibidos visualmente em painéis, enviar alertas pelo Amazon SNS ou por e-mail e trabalhar com o Auto Scaling para aumentar ou reduzir a escala dos recursos da workload horizontalmente.
-
Simples alarmes estáticos podem ser criados para monitorar quando uma métrica ultrapassa um limite estático durante um número específico de períodos de avaliação.
-
Os alarmes compostos podem representar alarmes complexos de várias origens.
-
Depois que o alarme for criado, crie eventos de notificação apropriados. Você pode invocar diretamente uma API do Amazon SNS para enviar notificações e vincular qualquer automação para correção ou comunicação.
-
integre o Amazon Health Aware
para permitir a visibilidade de monitoramento de recursos da AWS que possam ter degradações. Para workloads essenciais aos negócios, essa solução fornece acesso a alertas proativos e em tempo real para serviços da AWS.
Recursos
Práticas recomendadas relacionadas ao Well-Architected:
Documentos relacionados:
Ferramentas relacionadas:
