Fundamentos dos alarmes do CloudWatch

Dois alarmes, mesma madrugada, mesma conta. O primeiro nunca disparou enquanto a fila de pagamentos acumulava por 40 minutos. O segundo disparou 14 vezes entre 02:00 e 03:00 sem que nada estivesse errado. Os dois foram construídos por engenheiros que sabiam exatamente o que CPUUtilization e ApproximateAgeOfOldestMessage significam. Nenhum dos dois sabia como o CloudWatch decide que um alarme mudou de estado.

Essa decisão é onde alarmes se ganham e se perdem. Uma métrica é só uma lista de números, e você já sabe como o CloudWatch guarda esses números. Um alarme é uma pequena máquina de estados em cima dessa lista, e quase toda reclamação sobre alarmes em produção volta para uma de quatro configurações dentro dela.

Do que um alarme é feito

Um alarme de métrica observa uma métrica (ou uma expressão de metric math) e mantém um de três estados. Para decidir qual, ele precisa de resposta para seis perguntas:

Uma sétima configuração, o tratamento de dados faltantes, só importa quando o dado some, e ela ganha uma seção própria mais adiante porque causa mais surpresa que as outras seis juntas.

Aqui está um alarme com valores reais: observe CPUUtilization da instância i-0a1b2c3d4e5f67890, tire a Average de cada período de 60 segundos, chame de ruim o período cuja média passa de 80 e vá para ALARM quando 3 dos últimos 5 períodos foram ruins.

aws cloudwatch put-metric-alarm \
  --alarm-name "checkout-api-cpu-high" \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0a1b2c3d4e5f67890 \
  --statistic Average \
  --period 60 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 5 \
  --datapoints-to-alarm 3 \
  --treat-missing-data missing \
  --alarm-actions arn:aws:sns:eu-west-1:111122223333:ops-critical

Três estados, e a regra que quase todo mundo erra

Um alarme está sempre em exatamente um destes:

• OK: a métrica está dentro do limite.
• ALARM: a métrica está fora do limite.
• INSUFFICIENT_DATA: o alarme acabou de nascer, a métrica não está disponível, ou não há dado suficiente para decidir.

INSUFFICIENT_DATA não é erro. Um alarme novo começa nesse estado por design, e um volume EBS disponível mas não anexado a nenhuma instância para de publicar métricas, o que é um motivo perfeitamente saudável para o alarme dele ficar parado ali.

Agora a regra: um alarme executa suas ações apenas quando muda de estado. Não a cada período. Não a cada minuto. Uma vez, na transição.

Dá vontade de supor que um alarme travado em ALARM continua te chamando, e que telefone quieto significa problema resolvido. Nenhuma das duas coisas é verdade. O alarme mandou uma notificação quando entrou em ALARM e está sentado ali em silêncio desde então. Se o seu processo precisa de lembretes enquanto o incidente está aberto, essa repetição vem da ferramenta de plantão, não do CloudWatch.

Existe exatamente uma exceção, e a prova gosta dela: para ações de Auto Scaling, o alarme continua executando a ação uma vez por minuto enquanto permanecer no novo estado. Isso é deliberado, porque uma política de escalabilidade que disparasse uma vez e ficasse quieta nunca terminaria de escalar um grupo muito sobrecarregado.

Period, Evaluation Periods e Datapoints to Alarm

Essas três configurações são a origem dos alarmes que "nunca dispararam" e dos que "dispararam 14 vezes", então trabalhe com números em vez de definições.

Period é quanto tempo cada ponto de dados cobre. Os valores válidos são 10, 20, 30 ou qualquer múltiplo de 60 segundos.

Evaluation Periods (N) é quantos pontos de dados mais recentes o alarme olha.

Datapoints to Alarm (M) é quantos desses N precisam estar violando para o alarme ir a ALARM. Os pontos violadores não precisam ser consecutivos. Eles só precisam cair dentro da janela dos últimos N.

Quando M é igual a N, você tem um alarme de "períodos consecutivos": todo ponto da janela precisa estar violando. Quando M é menor que N, você tem um alarme M de N, que tolera um respiro saudável no meio de um trecho ruim.

O intervalo de avaliação é simplesmente N vezes o período. Quatro de cinco pontos com período de 1 minuto dão um intervalo de 5 minutos. Três de três com período de 10 minutos dão 30 minutos.

Para qualquer período de um minuto ou mais, o alarme é avaliado a cada minuto, e a janela desliza. Com período de 5 minutos e 1 evaluation period, o fim do minuto 5 avalia os minutos 1 a 5, e o fim do minuto 6 avalia os minutos 2 a 6. Se o período for de 10, 20 ou 30 segundos, o alarme é avaliado a cada 10 segundos.

Duas cotas limitam até onde um alarme consegue olhar para trás. Period vezes Evaluation Periods pode chegar no máximo a 604.800 segundos (sete dias) para alarmes com período de pelo menos uma hora, e no máximo a 86.400 segundos (um dia) para qualquer período menor. E um alarme cuja janela passa de um dia vira um alarme multi-dia, avaliado só uma vez por hora e considerando apenas métricas até a hora atual no minuto :00. Um job que falha às 10:02 não move esse alarme às 10:03; o alarme reage às 11:03.

Dados faltantes: o que o silêncio quer dizer

Todo ponto de dados da janela é uma de três coisas: não violando, violando ou faltante. Os dois primeiros são óbvios. O terceiro é um julgamento que só você pode fazer, porque o CloudWatch não tem como saber se uma métrica que ficou quieta significa "está tudo bem" ou "quem publica isso morreu".

Então você conta para ele, com uma de quatro configurações:

O padrão é missing. Duas exceções valem decorar. Alarmes sobre métricas do namespace AWS/DynamoDB usam ignore como padrão. E a AWS recomenda especificamente missing para alarmes que param, encerram, reiniciam ou recuperam instâncias EC2, porque o reporte de métricas do EC2 pode ser interrompido por instantes numa instância perfeitamente saudável, e você não quer que um buraco no reporte encerre um servidor de produção.

Escolhas concretas: ThrottledRequests do DynamoDB publica um ponto de dados só quando uma requisição é limitada, então notBreaching é o certo. Um alarme que dispara rollback de deploy observa uma métrica que reporta continuamente, então um buraco provavelmente significa que a aplicação parou de responder, e breaching é o certo.

A faixa de avaliação, e por que sua configuração de dados faltantes costuma ser ignorada

Aqui está a parte que faz alarmes se comportarem de um jeito que as configurações não preveem de forma óbvia.

Toda vez que um alarme avalia, o CloudWatch recupera mais pontos de dados que Evaluation Periods. O intervalo de tempo desses pontos extras se chama faixa de avaliação. Para um alarme com 3 evaluation periods, a faixa de avaliação é de 5 pontos de dados.

Depois ele aplica três regras, nesta ordem:

1. Se nenhum ponto da faixa de avaliação está faltando, ele avalia os N mais recentes e ignora os extras.
2. Se alguns faltam mas o total de pontos reais recuperados chega a N, ele avalia os N pontos reais mais recentes, alcançando os extras para trás. Sua configuração de dados faltantes não é usada de jeito nenhum.
3. Só se os pontos reais ainda forem menos que N o CloudWatch preenche os buracos usando a sua configuração, e mesmo aí usa o mínimo possível de pontos substituídos.

Pense num professor corrigindo suas 3 últimas tarefas. Se duas das 3 últimas nunca foram entregues, ele volta à quarta e à quinta tarefa em vez de dar zero nas que faltam. A analogia quebra num ponto: o professor voltaria indefinidamente, enquanto o CloudWatch só alcança até o fim da faixa de avaliação e depois cai para a sua configuração.

É por isso que dois engenheiros podem colocar breaching e notBreaching na mesma métrica intermitente e ver os dois alarmes se comportando de forma idêntica por semanas.

Ainda tem mais uma lógica ali dentro, chamada de prevenção de estado prematuro. Com Datapoints to Alarm em 3, um dado - - - - X (quatro faltando e um violando) não vai direto para ALARM, porque o próximo ponto pode vir saudável. Já um dado - - X - - vai para ALARM mesmo com missing tratado como missing, porque o ponto violador mais antigo disponível é pelo menos tão velho quanto o valor de M e tudo mais novo está violando ou faltando. Não espere prever essas bordas só pela tabela de dados faltantes.

Alarmes de alta resolução

Coloque o período em 10, 20 ou 30 segundos e você criou um alarme de alta resolução, avaliado a cada 10 segundos e cobrado numa tarifa maior que a de um alarme comum.

Use esses períodos apenas para métricas publicadas com storage resolution 1, ou seja, suas próprias métricas personalizadas de alta resolução. Aponte um alarme de 10 segundos para uma métrica de resolução padrão e o CloudWatch continua tentando buscar dado a cada 10 segundos, não encontra nada em cinco de cada seis tentativas e derruba o alarme para INSUFFICIENT_DATA com frequência. Você ganha um alarme não confiável e o preço premium ao mesmo tempo.

Além de um número fixo

Nem toda pergunta tem limite fixo, e o CloudWatch dá dois caminhos para isso.

Alarmes de metric math observam o resultado de uma expressão em vez de uma métrica bruta. O caso clássico é taxa de erro, porque "500 erros" significa coisas completamente diferentes em 600 requisições e em 6 milhões:

{
  "Metrics": [
    { "Id": "errors",   "MetricStat": { "Metric": { "Namespace": "MyService", "MetricName": "ConnectionsFailed" }, "Period": 60, "Stat": "Sum" }, "ReturnData": false },
    { "Id": "attempts", "MetricStat": { "Metric": { "Namespace": "MyService", "MetricName": "ConnectionAttempts" }, "Period": 60, "Stat": "Sum" }, "ReturnData": false },
    { "Id": "error_rate", "Expression": "(errors/attempts)*100", "ReturnData": true, "Label": "Taxa de erro de conexao" }
  ],
  "Threshold": 40,
  "ComparisonOperator": "GreaterThanThreshold",
  "EvaluationPeriods": 3
}

Exatamente um item do array Metrics marca ReturnData como true, e essa é a expressão que o alarme observa.

Alarmes de detecção de anomalias não têm limite fixo nenhum. O CloudWatch treina um modelo de machine learning com até duas semanas de dados passados da métrica, aprendendo os padrões de hora, dia e semana mais a tendência de longo prazo, e produz uma banda de valores esperados. O alarme então dispara quando a métrica sai acima da banda, abaixo dela, ou fora em qualquer direção.

{
  "Metrics": [
    { "Id": "m1", "ReturnData": true, "MetricStat": { "Metric": { "Namespace": "AWS/EC2", "MetricName": "CPUUtilization" }, "Stat": "Average", "Period": 60 } },
    { "Id": "t1", "Expression": "ANOMALY_DETECTION_BAND(m1, 3)" }
  ],
  "ThresholdMetricId": "t1",
  "ComparisonOperator": "LessThanLowerOrGreaterThanUpperThreshold",
  "EvaluationPeriods": 2
}

O 3 é o limiar de detecção de anomalia, e um número maior produz banda mais grossa e menos alertas. Quatro detalhes decidem se essa é a ferramenta certa:

• O modelo é específico de uma métrica e de uma estatística. Um modelo treinado em Average não diz nada sobre Maximum.
• Você pode excluir intervalos de tempo do treino, e é assim que você impede o teste de carga do mês passado de ensinar ao modelo que um pico de 10x é normal.
• Alarmes baseados em modelo de detecção de anomalias não aceitam ações de Auto Scaling.
• Cada alarme de detecção de anomalias é cobrado como três métricas de alarme de resolução padrão (a métrica mais os limites superior e inferior), ou seja, cerca de US$ 0,30 por mês contra US$ 0,10 de um alarme de métrica comum.

A detecção de anomalias vale a pena em métricas com forma diária forte, como contagem de requisições de um app de consumo. É a ferramenta errada para uma métrica em que qualquer valor diferente de zero já é ruim.

Diagnosticar um alarme que não sai de INSUFFICIENT_DATA

Esse é o chamado mais comum sobre alarmes, e a lista de causas é curta:

• O período é menor que a resolução da métrica. O monitoramento básico do EC2 publica a cada 5 minutos, então um período de 60 segundos deixa quatro de cada cinco períodos vazios.
• O conjunto de dimensões nunca foi publicado. Um alarme pode ser criado antes da métrica personalizada existir, e ele fica alegremente em INSUFFICIENT_DATA para sempre se as dimensões não baterem exatamente com o que você publica.
• Foi informada uma Unit que a métrica nunca usa. A AWS recomenda omitir Unit por completo, porque uma divergência produz um alarme travado em vez de um erro.
• O recurso está mesmo ocioso. Volumes EBS desanexados, funções Lambda sem invocação e Auto Scaling groups com zero instâncias param de publicar.

O histórico do alarme fica guardado por 30 dias, e o describe-alarm-history mostra cada transição de estado com o timestamp dela. É a sua primeira parada quando alguém pergunta se um alarme chegou a disparar.

aws cloudwatch describe-alarm-history \
  --alarm-name "checkout-api-cpu-high" \
  --history-item-type StateUpdate \
  --max-records 10

Dicas para a prova

• "O alarme ficou em ALARM mas só recebemos um e-mail" nunca é bug. As ações disparam na mudança de estado. A única ação reexecutada enquanto o estado se mantém é a de Auto Scaling, uma vez por minuto.
• Leia o texto do limite com atenção. "3 períodos consecutivos" significa M igual a N; "3 de 5" significa M igual a 3 e N igual a 5, com os pontos violadores possivelmente espalhados.
• Mapeie as opções de dados faltantes pela natureza da métrica: métrica que só publica em falha aponta para notBreaching; métrica reportada continuamente onde o silêncio é suspeito aponta para breaching; alarmes de stop, terminate, reboot e recover de EC2 apontam para missing, que também é o padrão global.
• Período de 10, 20 ou 30 segundos significa alarme de alta resolução, e ele só funciona em métricas guardadas com resolução de 1 segundo. Questões que citam período abaixo de um minuto junto com uma métrica publicada pela AWS estão descrevendo um alarme quebrado.
• Se a questão diz "nenhum limite fixo funciona, o nível normal muda ao longo do dia", a resposta é detecção de anomalias, e lembre que ela não aciona Auto Scaling.
• Uma janela de alarme maior que um dia é avaliada de hora em hora contra dados até o topo da hora, e o total para em sete dias.

A regra para levar adiante: o estado de um alarme é decidido por uma janela deslizante dos últimos N pontos de dados, e tudo que parece imprevisível em alarmes vem do que o CloudWatch faz quando essa janela tem buracos. Em seguida você vai acompanhar a notificação saindo do alarme e entrando no Amazon SNS, onde um conjunto diferente de falhas silenciosas espera por você.