As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
REL11-BP06 Envie 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 ocultar problemas subjacentes que precisam ser resolvidos. Implemente eventos e monitoramento apropriados para que você possa detectar padrões de problemas, incluindo aqueles abordados pela autocorreção, e consiga 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, como taxas de erro, latência ou outras métricas críticas de indicadores-chave de desempenho (KPI), para que esses problemas sejam resolvidos o mais rápido possível e o impacto do usuário seja evitado ou minimizado.
Práticas comuns que devem ser evitadas:
-
Enviar muitos alarmes.
-
Enviar alarmes não acionáveis.
-
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 essa melhor prática: as notificações de recuperação alertam as equipes operacionais e comerciais sobre a degradação do serviço, para que possam reagir imediatamente para 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ção para 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 IN ALARM e OK) e detalhes sobre o que o acionou. Em muitos casos, um evento de alarme deve ser detectado e uma notificação por e-mail deve ser enviada. 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 KPI de monitoramento forem estabelecidos, os alertas devem 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 limites mais complexo, considere usar alarmes compostos. Os alarmes compostos usam vários alarmes KPI de monitoramento para criar um alerta com base na lógica operacional de negócios. CloudWatchOs alarmes podem ser configurados para enviar e-mails ou registrar incidentes em sistemas de rastreamento de incidentes de terceiros usando a SNS integração com a Amazon ou a Amazon. EventBridge
Etapas de 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.
-
Os alarmes de infraestrutura indicam quando escalar os recursos. Os alarmes podem ser exibidos visualmente em painéis, enviar alertas pela Amazon SNS ou por e-mail e trabalhar com o Auto Scaling para aumentar ou reduzir os recursos da carga de trabalho.
-
Alarmes estáticos de exemplo 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 Amazon SNS API para enviar notificações e vincular qualquer automação para remediação ou comunicação.
-
Integre o monitoramento do Amazon Health Aware
para permitir a visibilidade do monitoramento de AWS recursos que possam ter degradações. Para cargas de trabalho essenciais para os negócios, essa solução fornece acesso a alertas proativos e em tempo real para AWS serviços.
Recursos
Práticas recomendadas do Well-Architected relacionadas:
Documentos relacionados:
Ferramentas relacionadas:
