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á.
# Detecção de falhas com CloudWatch alarmes compostos
Nas CloudWatch métricas, cada conjunto de dimensões é uma métrica exclusiva, e você pode criar um CloudWatch alarme para cada uma. Em seguida, você pode criar [alarmes CloudWatch compostos da Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) para agregar essas métricas.
Para detectar com precisão o impacto, os exemplos deste paper usarão duas estruturas de CloudWatch alarme diferentes para cada dimensão configurada para ativar o alarme. Cada alarme usará um **período** de um minuto, o que significa que a métrica é avaliada uma vez por minuto. A primeira abordagem usará três pontos de dados de violação consecutivos, definindo os **Períodos de Avaliação** e os **Pontos de Dados para Alarme** como três, o que significa impacto por um total de três minutos. A segunda abordagem usará um “M de N” quando quaisquer 3 pontos de dados em uma janela de cinco minutos forem violados, definindo os **Períodos de Avaliação** como cinco e os **Pontos de Dados para Alarme** como três. Isso permite a detecção de um sinal constante, bem como um que flutua em um curto espaço de tempo. As durações e o número de pontos de dados contidos aqui são uma sugestão. Use valores que façam sentido para suas workloads.
## Detectar impacto em uma única Zona de Disponibilidade
Usando essa estrutura, considere uma workload que usa `Controller`, `Action`, `InstanceId`, `AZ-ID` e `Region` como dimensões. A workload tem dois controladores, Products e Home, e uma ação por controlador, List e Index, respectivamente. Ela opera em três Zonas de Disponibilidade na Região `us-east-1`. Você criaria dois alarmes de disponibilidade para cada combinação de `Controller` e `Action` em cada Zona de Disponibilidade, bem como dois alarmes de latência para cada um. Em seguida, você pode optar por criar um alarme composto para verificar a disponibilidade de cada combinação de `Controller` e `Action`. Por fim, você cria um alarme composto que agrega todos os alarmes de disponibilidade da Zona de Disponibilidade. Isso é mostrado na figura a seguir para uma única Zona de disponibilidade, `use1-az1`, usando o alarme composto opcional para cada combinação de `Controller` e `Action` (alarmes semelhantes também existiriam para as Zonas de disponibilidade `use1-az2` e `use1-az3`, mas não são mostrados para simplificar).
Você também construiria uma estrutura de alarme semelhante para latência, mostrada na figura a seguir.
Para o restante das figuras desta seção, somente os alarmes compostos `az1-availability` e `az1-latency` serão mostrados no nível superior. Esses alarmes, `az1-availability` e `az1-latency`, dirão se a disponibilidade ficar abaixo ou se a latência ultrapassar os limites definidos em uma Zona de Disponibilidade específica, em qualquer parte da sua workload. Você também pode considerar a medição do throughput para detectar o impacto que impede que sua workload em uma única Zona de disponibilidade receba trabalho. Também é possível integrar alarmes produzidos a partir das métricas emitidas por seus canários nesses alarmes compostos. Dessa forma, se o lado do servidor ou o lado do cliente perceberem impactos na disponibilidade ou na latência, o alarme criará um alerta.
## Confira se o impacto não é regional
Outro conjunto de alarmes compostos pode ser usado para garantir que somente um evento isolado da Zona de Disponibilidade ative o alarme. Para isso acontecer, um alarme composto da Zona de Disponibilidade é colocado no estado `ALARM` enquanto os alarmes compostos das outras Zonas de Disponibilidade são colocados no estado `OK`. Isso resultará em um alarme composto por Zona de Disponibilidade usada. Um exemplo é mostrado na figura a seguir (lembre-se de que há alarmes de latência e disponibilidade em `use1-az2` e `use1-az3`, `az2-latency`, `az2-availability`, `az3-latency` e `az3-availability`, que não estão ilustrados para simplificar).
## Garanta que o impacto não seja causado por uma única instância
Uma única instância (ou uma pequena porcentagem de sua frota geral) pode causar um impacto desproporcional nas métricas de disponibilidade e latência, o que pode fazer com que toda a Zona de Disponibilidade pareça estar afetada, quando na verdade não está. É mais rápido e eficaz remover uma única instância problemática do que evacuar uma Zona de disponibilidade.
As instâncias e os contêineres geralmente são tratados como recursos efêmeros, frequentemente substituídos por serviços como [AWS Auto Scaling](https://aws.amazon.com/autoscaling/). É difícil criar um novo CloudWatch alarme toda vez que uma nova instância é criada (mas certamente é possível usando ganchos de [ciclo de vida [da Amazon EventBridge](https://docs.aws.amazon.com/autoscaling/ec2/userguide/cloud-watch-events.html) ou do Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)). Em vez disso, você pode usar o [CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) para identificar a quantidade de colaboradores nas métricas de disponibilidade e latência.
Como exemplo, para um aplicativo HTTP web, você pode criar uma regra para identificar os principais colaboradores para 5xx HTTP respostas em cada zona de disponibilidade. Isso identificará quais instâncias estão contribuindo para uma queda na disponibilidade (nossa métrica de disponibilidade definida acima é determinada pela presença de erros 5xx). Usando o exemplo de EMF log, crie uma regra usando uma chave de`InstanceId`. Em seguida, filtre o log usando o campo `HttpResponseCode`. Este exemplo é uma regra para a Zona de Disponibilidade `use1-az1`.
```
{
"AggregateOn": "Count",
"Contribution": {
"Filters": [
{
"Match": "$.InstanceId",
"IsPresent": true
},
{
"Match": "$.HttpStatusCode",
"IsPresent": true
},
{
"Match": "$.HttpStatusCode",
"GreaterThan": 499
},
{
"Match": "$.HttpStatusCode",
"LessThan": 600
},
{
"Match": "$.AZ-ID",
"In": ["use1-az1"]
},
],
"Keys": [
"$.InstanceId"
]
},
"LogFormat": "JSON",
"LogGroupNames": [
"/loggroupname"
],
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
}
}
```
CloudWatch alarmes também podem ser criados com base nessas regras. Você pode criar alarmes com base nas regras do Contributor Insights usando [matemática de métrica](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) e a função `INSIGHT_RULE_METRIC` com a métrica `UniqueContributors`. Você também pode criar regras adicionais do Contributor Insights com CloudWatch alarmes para métricas como latência ou contagens de erros, além de alarmes de disponibilidade. Esses alarmes podem ser usados com os alarmes compostos de para impacto em uma Zona de Disponibilidade isolada, de forma a garantir que instâncias únicas não ativem o alarme. A métrica da regra de insights para `use1-az1` pode ser assim:
```
INSIGHT_RULE_METRIC("5xx-errors-use1-az1", "UniqueContributors")
```
Você pode definir um alarme quando essa métrica ultrapassar um limite; neste exemplo, dois. Ele é ativado quando os colaboradores exclusivos das respostas 5xx ultrapassam esse limite, indicando que o impacto está vindo de mais de duas instâncias. O motivo para esse alarme usar uma comparação “maior que” em vez de “menor que” é para garantir que um valor zero para colaboradores exclusivos não acione o alarme. Isso indica que o impacto *não* vem de uma única instância. Ajuste esse limite para sua workload individual. Indicamos que esse número seja 5% ou mais do total de recursos na Zona de Disponibilidade. Mais de 5% dos seus recursos sendo afetados mostra significância estatística, considerando um tamanho amostral suficiente.
## Juntando tudo isso
A figura a seguir mostra a estrutura de alarme composto completa para uma única Zona de Disponibilidade:
O alarme composto final, `use1-az1-isolated-impact`, é ativado quando o alarme composto que indica o impacto isolado na Zona de Disponibilidade devido à latência ou disponibilidade, `use1-az1-aggregate-alarm`, estiver no estado `ALARM` e quando o alarme baseado na regra do Contributor Insights para a mesma ZD, `not-single-instance-use1-az1`, também estiver em estado `ALARM` (o que significa que o impacto é mais do que uma única instância). Você criaria essa pilha de alarmes para cada Zona de Disponibilidade usada pela workload.
Você pode anexar um alerta do [Amazon Simple Notification Service](https://aws.amazon.com/sns/) (AmazonSNS) a esse alarme final. Todos os alarmes anteriores são configurados sem uma ação. O alerta pode notificar um operador por e-mail para que ele de início a uma investigação manual. Ele também pode iniciar a automação para evacuar a Zona de Disponibilidade. No entanto, cuidado ao criar automações para responder a esses alertas. Após uma evacuação de Zona de Disponibilidade, o resultado deve ser a mitigação das taxas de erro crescentes e a volta do alarme a um estado `OK`. Se o impacto ocorrer em outra Zona de disponibilidade, é possível que a automação evacue uma segunda ou terceira Zona de disponibilidade, potencialmente removendo toda a capacidade disponível da workload. A automação deve verificar se uma evacuação já foi realizada antes de realizar qualquer ação. Você também pode precisar escalar recursos em outras Zonas de Disponibilidade antes que a evacuação seja bem-sucedida.
Ao adicionar novos controladores ou ações ao seu aplicativo MVC web, a um novo microsserviço ou, em geral, a qualquer funcionalidade adicional que você queira monitorar separadamente, você só precisa modificar alguns alarmes nessa configuração. Você criará novos alarmes de disponibilidade e latência para essa nova funcionalidade e, em seguida, os adicionará aos alarmes compostos de disponibilidade e latência adequados da Zona de Disponibilidade, `az1-latency` e `az1-availability` no exemplo que estamos usando aqui. Os alarmes compostos restantes permanecem estáticos após serem configurados. Isso torna a integração de novas funcionalidades um processo mais simples.