Configurar como os alarmes do CloudWatch tratam dados ausentes

Às vezes, nem todos os pontos de dados esperados para uma métrica são relatados ao CloudWatch. Por exemplo, isso pode ocorrer quando uma conexão é perdida, um servidor é desativado, ou quando uma métrica informa apenas dados de forma intermitente por padrão.

O CloudWatch permite que você especifique como tratar pontos de dados ausentes ao avaliar um alarme. Isso pode ajudar a configurar seu alarme para passar ao estado ALARM quando for apropriado para o tipo de dados que está sendo monitorado. Você pode evitar falsos positivos quando os dados ausentes não indicam um problema.

Assim como cada alarme está sempre em um dos três estados, cada ponto de dados específico relatado do CloudWatch se insere em uma destas três categorias:

• Não violar (dentro do limite)

• Violar (violando o limite)

• Ausente

Para cada alarme, é possível especificar o CloudWatch para tratar pontos de dados ausentes como qualquer uma destas opções:

• notBreaching: os pontos de dados ausentes são tratados como "bons" e dentro do limite

• breaching: os pontos de dados ausentes são tratados como “ruins” e violando o limite

• ignore: o estado do alarme atual é mantido

• missing: se todos os pontos de dados no intervalo de avaliação do alarme estiverem ausentes, o alarme passará para INSUFFICIENT_DATA.

A melhor opção depende do tipo de métrica e da finalidade do alarme. Por exemplo, se você estiver criando um alarme de reversão de aplicações usando uma métrica que relata dados continuamente, pode desejar tratar os pontos de dados ausentes como uma violação, pois isso pode indicar que há algo de errado. No entanto, para uma métrica que gera pontos de dados somente quando ocorre um erro, como ThrottledRequests no Amazon DynamoDB, é possível tratar dados ausentes como notBreaching. O comportamento padrão é missing.

Importante

Os alarmes configurados nas métricas do Amazon EC2 podem entrar temporariamente no estado INSUFFICIENT_DATA se houver pontos de dados de métricas ausentes. Isso é raro, mas pode acontecer quando o relatório de métricas é interrompido, mesmo quando a instância do Amazon EC2 está íntegra. Para os alarmes nas métricas do Amazon EC2 que estão configurados para executar ações de interrupção, encerramento, reinicialização ou recuperação, recomendamos configurar esses alarmes para tratar os dados ausentes como missing e para que esses alarmes sejam acionados somente quando estiverem no estado ALARM.

Escolher a melhor opção para seu alarme evita alterações desnecessárias e enganosas e também indica com mais precisão a integridade do seu sistema.

Importante

Os alarmes que avaliam as métricas no namespace AWS/DynamoDB ignoram por padrão os dados ausentes. É possível substituir isso se escolher uma opção diferente para como o alarme deve tratar os dados ausentes. Quando uma métrica AWS/DynamoDB tem dados ausentes, os alarmes que avaliam essa métrica permanecem no estado em que estiverem na ocasião.

Como o estado do alarme é avaliado quando há dados ausentes

Sempre que um alarme avalia se é necessário alterar o estado, o CloudWatch tenta recuperar um maior número de pontos de dados do que o número especificado em Evaluation Periods (Períodos de avaliação). O número exato de pontos de dados que ele tenta recuperar depende do tamanho do período de alarme e se ele é baseado em uma métrica com resolução padrão ou alta. O período de pontos de dados que ele tenta recuperar é o intervalo de avaliação.

Assim que o CloudWatch recupera esses pontos de dados, ocorre o seguinte:

• Se não houver pontos de dados ausentes no intervalo de avaliação, o CloudWatch avaliará o alarme com base nos pontos de dados mais recentes coletados. O número de pontos de dados avaliados é igual ao valor de Evaluation Periods (Períodos de avaliação) do alarme. Os pontos de dados excedentes mais antigos no intervalo de avaliação não são necessários e são ignorados.

• Se alguns pontos de dados no intervalo de avaliação estiverem ausentes, mas o total de pontos de dados recuperados corretamente for igual ou maior que os Evaluation Periods (Períodos de avaliação) do alarme, o CloudWatch avaliará o estado do alarme com base nos pontos de dados reais mais recentes que foram recuperados corretamente, inclusive os pontos de dados excedentes necessários mais antigos no período de avaliação. Nesse caso, o valor que você define para como tratar dados ausentes não é necessário e é ignorado.

• Se alguns pontos de dados no intervalo de avaliação estiverem ausentes e o número de pontos de dados reais que foram recuperados for menor do que o número de Evaluation Periods (Períodos de avaliação) do alarme, o CloudWatch preencherá os pontos de dados ausentes com o resultado especificado sobre como tratar dados ausentes e avaliará o alarme. Contudo, todos os pontos de dados reais no intervalo de avaliação serão incluídos na avaliação. O CloudWatch usa pontos de dados ausentes o mínimo possível.

nota

Um caso específico desse comportamento é que os alarmes do CloudWatch podem reavaliar repetidamente o último conjunto de pontos de dados por um período depois que o fluxo da métrica é interrompido. Essa reavaliação pode fazer com que o estado do alarme mude e as ações sejam executadas novamente, se ele tiver sido alterado imediatamente antes do fluxo de métrica ser interrompido. Para atenuar esse comportamento, use períodos mais curtos.

As tabelas a seguir ilustram exemplos do comportamento de avaliação de alarme. Na primeira tabela, Datapoints to Alarm (Pontos de dados para alarme) e Evaluation Periods (Períodos de avaliação) são 3. O CloudWatch recupera os cinco pontos de dados mais recentes ao avaliar o alarme, caso algum dos três pontos de dados mais recentes esteja ausente. O intervalo de avaliação do alarme é 5.

A coluna 1 exibe os cinco pontos de dados mais recentes, pois o intervalo de avaliação é 5. Esses pontos de dados são exibidos com o ponto de dados mais recente à direita, em que 0 é um ponto de dados de não violação, X é um ponto de dados violação e - é um ponto de dados ausente.

A coluna 2 mostra quantos dos 3 pontos de dados necessários estão ausentes. Embora os 5 pontos de dados mais recentes sejam avaliados, apenas 3 (a configuração para Evaluation Periods (Períodos de avaliação)) são necessárias para avaliar o estado do alarme. O número de pontos de dados na coluna 2 é o número de pontos de dados que devem ser "preenchidos", usando a configuração de como dados ausentes estão sendo tratados.

Nas colunas de 3 a 6, os cabeçalhos de coluna são os valores possíveis para tratar dados ausentes. As linhas dessas colunas mostram o estado do alarme definido para cada uma dessas possíveis formas de tratar dados ausentes.

Pontos de dados	Número de pontos de dados que deverão ser preenchidos	AUSENTE	IGNORE	VIOLAÇÃO	NÃO VIOLAÇÃO
0 - X - X	0	OK	OK	OK	OK
- - - - 0	2	OK	OK	OK	OK
- - - - -	3	INSUFFICIENT_DATA	Reter estado atual	ALARM	OK
0 X X - X	0	ALARM	ALARM	ALARM	ALARM
- - X - -	2	ALARM	Reter estado atual	ALARM	OK

Na segunda linha da tabela anterior, o alarme permanece em OK mesmo que os dados ausentes sejam tratados como violação, porque um ponto de dados existente não está violando o limite, e isso é avaliado junto com dois pontos de dados ausentes que são tratados como violação. Na próxima vez em que esse alarme for avaliado, se os dados ainda estiverem ausentes, ele passará para ALARM, pois esse ponto de dados de não violação não estará mais no intervalo de avaliação.

A terceira linha, onde todos os cinco pontos de dados mais recentes estão ausentes, ilustra como as várias configurações para tratar dados ausentes afetam o estado do alarme. Se os pontos de dados ausentes forem considerados de violação, o alarme entrará no estado ALARM; caso forem considerados de não violação, o alarme entrará no estado OK. Se os pontos de dados ausentes forem ignorados, o alarme reterá o estado atual que tinha antes dos pontos de dados ausentes. E se os pontos de dados ausentes são apenas considerados ausentes, então o alarme não tem dados reais recentes suficientes para fazer uma avaliação e passa para INSUFFICIENT_DATA.

Na quarta linha, o alarme passa para o estado ALARM em todos os casos porque os três pontos de dados mais recentes estão em violação, e tanto os Evaluation Periods (Períodos de avaliação) como os Datapoints to Alarm (Pontos de Dados para Alarme) do alarme são ambos definidos como 3. Nesse caso, o ponto de dados que falta é ignorado, e a configuração para como avaliar dados que estão faltando não é necessária, pois há 3 pontos de dados reais para avaliar.

A linha 5 representa um caso especial de avaliação de alarme chamado estado de alarme prematuro. Para obter mais informações, consulte Evitar transições prematuras para o estado do alarme.

Na próxima tabela, o Period (Período) é novamente definido como 5 minutos, e Datapoints to Alarm (Pontos de dados para alarme) é somente 2, enquanto Evaluation Periods (Períodos de avaliação) é 3. Esse é um alarme 2 de 3, M de N.

O intervalo de avaliação é 5. Esse é o número máximo de pontos de dados recentes que são recuperados e podem ser usados caso alguns pontos de dados estejam ausentes.

Pontos de dados	Número de pontos de dados ausentes	AUSENTE	IGNORE	VIOLAÇÃO	NÃO VIOLAÇÃO
0 - X - X	0	ALARM	ALARM	ALARM	ALARM
0 0 X 0 X	0	ALARM	ALARM	ALARM	ALARM
0 - X - -	1	OK	OK	ALARM	OK
- - - - 0	2	OK	OK	ALARM	OK
- - - - X	2	ALARM	Reter estado atual	ALARM	OK

Nas linhas 1 e 2, o alarme sempre passa para o estado ALARM porque dois dos três pontos de dados mais recentes estão em violação. Na linha 2, os dois pontos de dados mais antigos no intervalo de avaliação não são necessários porque nenhum dos três pontos de dados mais recentes está ausente. Portanto, esses dois pontos de dados mais antigos são ignorados.

Nas linhas 3 e 4, o alarme só passará para o estado ALARM se os dados ausentes forem tratados como violação, e nesse caso os dois pontos de dados ausentes mais recentes serão tratados como violação. Na linha 4, esses dois pontos de dados ausentes que são tratados como violação fornecem os dois pontos de dados de violação necessários para acionar o estado ALARM.

A linha 5 representa um caso especial de avaliação de alarme chamado estado de alarme prematuro. Para obter mais informações, consulte a seção a seguir:

Evitar transições prematuras para o estado do alarme

A avaliação de alarmes do CloudWatch inclui lógica para tentar evitar alarmes falsos, nos quais o alarme entra no estado ALARM prematuramente quando os dados são intermitentes. O exemplo da linha 5 nas tabelas da seção anterior ilustra essa lógica. Nessas linhas e nos exemplos a seguir, os Evaluation Periods (Períodos de avaliação) são 3, e o intervalo de avaliação é de 5 pontos de dados. Os Datapoints to Alarm (Pontos de dados para alarme) são 3, exceto para o exemplo M de N, em que os Datapoints to Alarm são 2.

Suponha que os dados mais recentes de um alarme sejam - - - - X, com quatro pontos de dados ausentes e um ponto de dados de violação como ponto de dados mais recente. Como o próximo ponto de dados pode não ser violado, o alarme não entra imediatamente no estado ALARM quando os dados são - - - - X ou - - - X - e Datapoints to Alarm (Pontos de dados para alarme) são 3. Desta forma, evitam-se os falsos positivos quando o próximo ponto de dados for de não violação e faz com que os dados sejam - - - X O ou - - X - O.

Porém, se os últimos pontos de dados forem - - X - -, o alarme entra no estado ALARM mesmo se os pontos de dados ausentes forem tratados como ausentes. Isso ocorre porque os alarmes são projetados para sempre entrar no estado ALARM quando o ponto de dados de violação mais antigo disponível durante o número de pontos de dados dos Evaluation Periods (Períodos de avaliação) é pelo menos tão antigo quanto o valor dos Datapoints to Alarm (Pontos de dados para alarme) e todos os outros pontos de dados mais recentes estão em violação ou ausentes. Neste caso, o alarme entra no estado ALARM mesmo que o número total de pontos de dados disponíveis seja inferior a M Datapoints to Alarm (Pontos de dados para alarme).

Essa lógica de alarme também se aplica a alarmes M de N. Se o ponto de dados em violação mais antigo durante o intervalo de avaliação for pelo menos tão antigo quanto o valor de Datapoints to Alarm (Pontos de dados para alarme), e todos os pontos de dados mais recentes estiverem em violação ou ausentes, o alarme entrará no estado ALARM para qualquer valor de M Datapoints to Alarm (Pontos de dados para alarme).

Dados ausentes nos alarmes do CloudWatch Metrics Insights

Alarmes baseados em consultas do Metrics Insights que se agregam em uma única série temporal

Os cenários de dados ausentes e seus efeitos na avaliação dos alarmes são os mesmos de um alarme de métrica padrão em termos do tratamento configurado de dados perdidos. Consulte , Configurar como os alarmes do CloudWatch tratam dados ausentes.

Alarmes baseados em consultas do Metrics Insights que produzem várias séries temporais

Os cenários de dados ausentes para os alarmes do Metrics Insights ocorrem quando:

• Pontos de dados individuais dentro de uma série temporal não estão presentes.

• Uma ou mais séries temporais desaparecem ao avaliar várias séries temporais.

• Nenhuma série temporal é recuperada pela consulta.

Os cenários de dados ausentes afetam a avaliação do alarme da maneira a seguir:

• Para a avaliação de uma série temporal, o tratamento de dados ausentes é aplicado a pontos de dados individuais dentro da série temporal. Por exemplo, se 3 pontos de dados fossem consultados para a série temporal, mas somente 1 fosse recebido, 2 pontos de dados seguiriam a configuração de dados ausentes configurada.

• Se uma série temporal não for mais recuperada pela consulta, ela sofrerá transição para OK, não importando o tratamento de dados ausentes. As ações de alarme associadas à transição OK no nível do colaborador são executadas, e StateReason especifica que o colaborador mencionado acima não foi encontrado com a mensagem “Nenhum dado foi retornado para este colaborador”. O estado do alarme dependerá do estado dos outros contribuidores que forem recuperados pela consulta.

• No nível do alarme, se a consulta retornar um resultado vazio (sem nenhuma série temporal), o alarme sofrerá transição para INSUFFICIENT_DATA, não importando o tratamento de dados ausentes definido.