Comportamento das políticas de alertas com base em métricas

Este documento descreve como as configurações de período e alinhamento de alinhamento determinam quando uma condição é acionada, como as políticas de alertas combinam várias condições e como as políticas de alertas substituem os pontos de dados ausentes. Também descreve o número máximo de incidentes abertos de uma política, o número de notificações por incidente e o que causa o atraso de notificações.

Este conteúdo não se aplica a políticas de alertas baseadas em registros. Para informações sobre políticas de alertas baseadas em registros, consulte Como monitorar seus registros.

Configurações de período de alinhamento e duração

O período de alinhamento e a janela de duração são dois campos que você define ao especificar uma condição para uma política de alertas. Nesta seção, veremos uma breve ilustração do significado desses campos.

Período de alinhamento

O período de alinhamento é um intervalo de retrospectiva de um ponto específico no tempo. Por exemplo, quando o período de alinhamento é de cinco minutos, às 13h, o período de alinhamento contém as amostras recebidas entre 12h55 e 13h. Às 13h01, o período de alinhamento desliza um minuto e contém as amostras recebidas entre 12h56 e 13h01.

Para ilustrar o efeito do período de alinhamento em uma condição na política de alertas, considere uma condição que esteja monitorando uma métrica com um período de amostragem de um minuto. Suponha que o período de alinhamento esteja definido como cinco minutos e que o alinhador esteja definido como sum. Quando o valor alinhado da série temporal é maior que dois por pelo menos três minutos, a condição é descrita como met ou active. Neste exemplo, suponha que a condição seja avaliada a cada minuto.

A figura a seguir ilustra várias avaliações sequenciais da condição:

Figura ilustrando o efeito do período de alinhamento.

Cada linha na figura ilustra uma única avaliação da condição. Os dados das séries temporais são exibidos. Os pontos no período de alinhamento são exibidos com pontos azuis, todos os pontos mais antigos são pretos. Cada linha exibe o valor alinhado e se esse valor é maior que o limite de dois. Para a linha marcada como start, o valor alinhado é calculado como um, o que é menor que o limite. Na próxima avaliação, a soma das amostras no período de alinhamento é duas. Na terceira avaliação, a soma é três e maior que o limite. O avaliador de condição também inicia o timer da janela de duração.

Janela de duração

Use duration ou window da duração, para evitar que uma condição seja atendida devido a uma única medição. No Console do Google Cloud, use os seguintes campos para configurar a duração:

Interface legada

Para configurar a janela de duração, use o campo Para do painel Configuração da política de alertas.

Interface na prévia

Configure a janela de duração usando o campo Testar janela novamente na etapa Configurar gatilho.

API

Para configurar a janela de duração, defina o campo duration nas estruturas MetricThreshold e MetricAbsence.

A figura anterior ilustra três avaliações da condição. No momento start + 2 minutes, o valor alinhado é maior que o limite. No entanto, a condição não é atendida porque a janela de duração está definida como três minutos. A figura a seguir ilustra os resultados das próximas avaliações da condição:

Figura ilustrando o efeito da janela de duração.

Mesmo que o valor alinhado seja maior que o limite no momento start + 2 minutes, a condição não é atendida até que o valor alinhado seja maior que o limite por três minutos. Isso ocorre no momento start + 5 minutes.

Para maior clareza, o exemplo anterior omitiu a possibilidade de combinar os pontos de dados alinhados de várias séries temporais em uma única medição. É a comparação entre a medição e o limite para determinar se a condição é atendida.

Uma condição redefine sua janela de duração sempre que uma medida não satisfaz a condição. Esse comportamento é ilustrado no seguinte exemplo:

Exemplo: essa política especifica uma janela de duração de cinco minutos.

Se a latência de resposta HTTP for maior que dois segundos
e se a latência for maior que o limite por cinco minutos,
abra um incidente e envie um e-mail à equipe de suporte.

A sequência a seguir ilustra como a janela de duração afeta a avaliação da condição:

  1. A latência HTTP é inferior a dois segundos.
  2. Nos próximos três minutos consecutivos, a latência HTTP é maior que dois segundos.
  3. Na próxima medição, a latência é inferior a dois segundos. Portanto, a condição redefine a janela de duração.
  4. Nos próximos cinco minutos consecutivos, a latência HTTP é maior que dois segundos. Portanto, a condição é atendida e a política é acionada.

A janela de duração precisa ser longa o suficiente para minimizar os falsos positivos, mas curta o suficiente para garantir que os incidentes sejam abertos na hora certa.

Selecione o período de alinhamento e a janela de duração.

As condições da política de alertas são avaliadas em uma frequência fixa. As opções feitas para o período de alinhamento e a janela de duração não determinam a frequência com que a condição é avaliada.

A figura anterior ilustra que o período de alinhamento determina quantas amostras de dados são combinadas com o alinhador. Para combinar muitas amostras, escolha um período longo. Para restringir o intervalo a apenas uma amostra, escolha um período curto. Por outro lado, a janela de duração especifica por quanto tempo os valores alinhados precisam ser maiores que o limite antes que a condição seja atendida. Para permitir que a condição seja atendida quando um único valor alinhado for maior que o limite, defina a janela de duração como zero.

Políticas com várias condições

Uma política de alertas pode conter até seis condições.

Se você estiver usando a API Cloud Monitoring ou se a política de alertas tiver várias condições, especifique quando um incidente é aberto. Para configurar como várias condições são combinadas, siga um destes procedimentos:

Interface legada

Configure as opções do combinador no campo Acionadores de política.

Interface na prévia

Configure opções do combinador na etapa Gatilho de várias condições.

API

Configure opções do combinador com o campo combiner da estrutura AlertPolicy.

Esta tabela lista as configurações no Console do Cloud, o valor equivalente na API Cloud Monitoring e uma descrição de cada configuração:

Console do Cloud
Valor da política aciona
Valor do combinador
da API Cloud Monitoring
Significado
Qualquer condição é atendida OR Um incidente será aberto se algum recurso fizer com que qualquer uma das condições seja atendida.
Todas as condições são atendidas
mesmo para recursos
diferentes para cada condição

(padrão)
AND Um incidente é aberto quando cada condição é atendida, mesmo que um recurso diferente faça com que elas sejam atendidas.
Todas as condições são atendidas AND_WITH_MATCHING_RESOURCE Um incidente será aberto se o mesmo recurso fizer com que cada condição seja atendida. Essa configuração é a opção de combinação mais rigorosa.

Nesse contexto, o termo met significa que a configuração da condição é avaliada como true. Por exemplo, se a configuração for Any time series is greater than 10 for 5 minutes, quando essa instrução for avaliada como true, a condição será atendida.

Exemplo

Considere um projeto do Google Cloud que contenha duas instâncias de VM, vm1 e vm2. Além disso, suponha que você crie uma política de alertas com duas condições:

  • A condição chamada CPU usage is too high monitora o uso da CPU das instâncias. Essa condição é atendida quando o uso de CPU de qualquer instância é maior que 100 ms/s por 1 minuto.
  • A condição chamada Excessive utilization monitora a utilização da CPU das instâncias. Essa condição é atendida quando a utilização da CPU de qualquer instância é maior que 60% por um minuto.

Inicialmente, suponha que ambas as condições sejam avaliadas como false.

Em seguida, suponha que o uso da CPU da vm1 exceda 100 ms/s por 1 minuto. Como o uso da CPU é maior que o limite de um minuto, a condição CPU usage is too high é atendida. Se as condições forem combinadas com Qualquer condição é atendida, um incidente será criado porque uma condição foi atendida. Se as condições forem combinadas com Todas as condições são atendidas ou Todas as condições são atendidas até mesmo para recursos diferentes para cada condição, um incidente não será criado. Essas escolhas do combinador exigem que as duas condições sejam atendidas.

Em seguida, suponha que o uso da CPU da vm1 permaneça maior que 100 ms/s e que a utilização da CPU da vm2 exceda 60% por um minuto. O resultado é que as duas condições são atendidas. Veja a seguir o que ocorre com base na forma como as condições são combinadas:

  • Qualquer condição é atendida: um incidente é criado quando um recurso faz com que uma condição seja atendida. Neste exemplo, vm2 faz com que a condição Excessive utilization seja atendida.

    Se vm2 fizer com que a condição CPU usage is too high seja atendida, isso também resultará na criação de um incidente. Um incidente é criado porque vm1 e vm2 fazem com que a condição CPU usage is too high seja atendida são eventos distintos.

  • Todas as condições são atendidas até mesmo para recursos diferentes para cada condição: um incidente é criado porque ambas as condições são atendidas.

  • Todas as condições são atendidas: um incidente não é criado porque esse combinador exige que o mesmo recurso faça com que todas as condições sejam atendidas. Neste exemplo, nenhum incidente é criado porque a vm1 faz com que CPU usage is too high seja atendido, enquanto a vm2 faz com que Excessive utilization seja atendido.

Dados de métricas parciais

Quando os dados da série temporal param de chegar ou quando são atrasados, o Monitoring os classifica como ausentes. A ausência de dados pode resultar em políticas que não são alertas e os incidentes não são encerrados. Os atrasos nos dados que chegam de provedores de nuvem de terceiros podem chegar a 30 minutos, com o intervalo de 5 a 15 minutos sendo o mais comum. Um atraso longo, maior do que a janela de duração, pode fazer com que as condições entrem em um estado "desconhecido". Quando os dados chegam, o Monitoring pode ter perdido parte do histórico recente das condições. A inspeção posterior dos dados de séries temporais pode não revelar esse problema porque não há evidências de atrasos depois que os dados chegam.

Interface legada

É possível configurar o tempo que o Monitoring aguarda para fechar incidentes abertos quando os dados deixam de chegar. No entanto, não é possível configurar como o Monitoring escolhe os valores de substituição para dados ausentes.

Para configurar quanto tempo o Monitoring aguarda antes de fechar um incidente aberto depois que os dados param de chegar, use o campo Duração do fechamento automático de incidentes. Defina a duração do fechamento automático na etapa Notificação. A duração padrão de fechamento automático é de 7 dias.

Interface na prévia

É possível configurar como o Monitoring avalia uma condição de limite de métrica quando os dados param de chegar. Por exemplo, quando um incidente está aberto e uma medição esperada não chega, você quer que o Monitoring deixe o incidente aberto ou o feche imediatamente? Da mesma forma, quando os dados param de chegar e nenhum incidente é aberto, você quer que ele seja aberto? Por fim, quanto tempo um incidente deve permanecer aberto após a chegada dos dados?

Há dois campos configuráveis que especificam como o Monitoring avalia as condições de limite de métrica quando os dados param de chegar:

  • Para configurar como o Monitoring determina o valor de substituição para dados ausentes, use o campo Avaliação de dados ausentes definido na etapa Acionador de condição. Esse campo fica desativado quando a janela de teste está definida como Sem novo teste.

  • Para configurar quanto tempo o Monitoring aguarda antes de fechar um incidente aberto depois que os dados param de chegar, use o campo Duração do fechamento automático de incidentes. Defina a duração do fechamento automático na etapa Notificação. A duração padrão de fechamento automático é de 7 dias.

Veja a seguir as diferentes opções para o campo de dados ausentes:

Console do Cloud
"Avaliação de dados ausentes"
Resumo Detalhes
Dados ausentes vazios Os incidentes abertos permanecem abertos.
Novos incidentes não são abertos.

Para condições que são atendidas, a condição continua sendo atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele permanecerá aberto. Quando um incidente está aberto e nenhum dado é recebido, o timer de fechamento automático é iniciado após um atraso de pelo menos 15 minutos. Se o timer expirar, o incidente será fechado.

Para condições que não são atendidas, a condição continua não sendo atendida quando os dados param de chegar.

Pontos de dados ausentes tratados como valores que violam a condição da política Os incidentes abertos permanecem abertos.
É possível abrir novos incidentes.

Para condições que são atendidas, a condição continua sendo atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele permanecerá aberto. Quando um incidente está aberto e nenhum dado chega ao período de fechamento automático mais 24 horas, o incidente é encerrado.

Para condições que não são atendidas, essa configuração faz com que a condição de limite de métrica se comporte como um metric-absence condition. Se os dados não chegarem no horário especificado pela janela de novo teste, a condição será avaliada como atendida. Para uma política de alertas com uma condição, ela é atendida e um incidente é aberto.

Pontos de dados ausentes tratados como valores que não violam a condição da política Os incidentes abertos estão fechados.
Novos incidentes não são abertos.

Para condições que são atendidas, a condição deixa de ser atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele será encerrado.

Para condições que não são atendidas, a condição continua não sendo atendida quando os dados param de chegar.

API

É possível configurar como o Monitoring avalia uma condição de limite de métrica quando os dados param de chegar. Por exemplo, quando um incidente está aberto e uma medição esperada não chega, você quer que o Monitoring deixe o incidente aberto ou o feche imediatamente? Da mesma forma, quando os dados param de chegar e nenhum incidente é aberto, você quer que ele seja aberto? Por fim, quanto tempo um incidente deve permanecer aberto após a chegada dos dados?

Há dois campos configuráveis que especificam como o Monitoring avalia as condições de limite de métrica quando os dados param de chegar:

  • Para configurar como o Monitoring determina o valor de substituição de dados ausentes, use o campo evaluationMissingData da estrutura MetricThreshold. Este campo é ignorado quando o campo duration é zero.

  • Para configurar quanto tempo o Monitoring aguarda antes de fechar um incidente aberto depois que os dados param de chegar, use o campo autoClose na estrutura AlertStrategy.

Veja a seguir as diferentes opções para o campo de dados ausentes:

Campo evaluationMissingData da API
Resumo Detalhes
EVALUATION_MISSING_DATA_UNSPECIFIED Os incidentes abertos permanecem abertos.
Novos incidentes não são abertos.

Para condições que são atendidas, a condição continua sendo atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele permanecerá aberto. Quando um incidente está aberto e nenhum dado é recebido, o timer de fechamento automático é iniciado após um atraso de pelo menos 15 minutos. Se o timer expirar, o incidente será fechado.

Para condições que não são atendidas, a condição continua não sendo atendida quando os dados param de chegar.

EVALUATION_MISSING_DATA_ACTIVE Os incidentes abertos permanecem abertos.
É possível abrir novos incidentes.

Para condições que são atendidas, a condição continua sendo atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele permanecerá aberto. Quando um incidente está aberto e nenhum dado chega à duração do fechamento automático mais 24 horas, o incidente é fechado.

Para condições que não são atendidas, essa configuração faz com que a condição de limite de métrica se comporte como um metric-absence condition. Se os dados não chegarem no horário especificado pelo campo "duração", a condição será avaliada como atendida. Para uma política de alertas com uma condição, ela é atendida e um incidente é aberto.

EVALUATION_MISSING_DATA_INACTIVE Os incidentes abertos estão fechados.
Novos incidentes não são abertos.

Para condições que são atendidas, a condição deixa de ser atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele será encerrado.

Para condições que não são atendidas, a condição continua não sendo atendida quando os dados param de chegar.

Para minimizar os problemas devido à ausência de dados, você pode:

  • Entre em contato com seu provedor de nuvem terceirizado para identificar maneiras de reduzir a latência da coleta de métricas.
  • Use janelas de duração mais longas nas condições. Usar uma janela de duração mais longa tem a desvantagem de tornar as políticas de alertas menos responsivas.
  • Escolha métricas com menor atraso de coleta:

    • Métricas do agente do Monitoring, especialmente quando o agente está sendo executado em instâncias de VM em nuvens de terceiros.
    • Métricas personalizadas, quando você grava os dados diretamente no Cloud Monitoring.
    • Métricas com base em registros, se a coleta de registros não estiver atrasada.

Para mais informações, consulte Visão geral do agente do Monitoring, Como usar métricas personalizadas e Métricas com base em registros.

Notificações e incidentes por política

Quando uma política de alertas é desativada, nenhum incidente é criado para a política e nenhuma notificação é enviada.

Quando uma política de alertas é ativada, os incidentes podem ser criados e as notificações podem ser enviadas. Nesta seção, descrevemos os limites do número de incidentes abertos por política e quando é possível ver várias notificações para o mesmo incidente.

Número de incidentes abertos por política

Uma política de alertas pode ser aplicada a muitos recursos, e um problema que afeta todos os recursos pode acionar a política e abrir incidentes para cada recurso. Um incidente é aberto para cada série temporal que resulta em uma condição atendida.

Para evitar a sobrecarga no sistema, o número de incidentes que uma única política pode abrir simultaneamente é limitado a 5.000.

Por exemplo, considere uma política que se aplica a 2.000 (ou 20.000) instâncias do Compute Engine, e cada instância faz com que as condições de alerta sejam atendidas. O Monitoring limita o número de incidentes abertos a 5.000. Todas as condições restantes que forem atendidas serão ignoradas até que alguns dos incidentes abertos para essa política sejam encerrados.

Número de notificações por incidente

Por padrão, uma notificação é enviada quando uma série temporal faz com que uma condição seja atendida. Você poderá receber várias notificações quando uma das seguintes condições for verdadeira:

  • Uma condição está monitorando várias séries temporais.

  • Uma política contém várias condições:

    • Todas as condições são atendidas: quando todas as condições são atendidas, para cada série temporal que resulta em uma condição ser atendida, a política envia uma notificação e cria um incidente. Por exemplo, suponha que você tenha uma política com duas condições e cada condição esteja monitorando uma série temporal. Quando essa política é acionada, você recebe duas notificações e vê dois incidentes.

    • Qualquer condição é atendida: a política envia uma notificação sempre que uma nova combinação de condições é atendida. Por exemplo, suponha que a condição A seja atendida, que um incidente seja aberto e que uma notificação seja enviada. Se o incidente ainda estiver aberto quando uma medição subsequente atender à Condição A e à Condição B, outra notificação será enviada.

As políticas de alertas criadas com a API Cloud Monitoring avisam quando a condição é atendida e quando ela deixa de ser atendida. Por padrão, as políticas de alertas criadas usando o Console do Google Cloud avisam quando um incidente é aberto. Eles não notificam você quando um incidente é encerrado. Você pode ativar as notificações no fechamento de incidentes.

Notificações de políticas de alertas desativadas

É possível interromper e reiniciar temporariamente as políticas de alertas ao desativá-las e ativá-las. Por exemplo, antes de executar a manutenção em uma máquina virtual (VM), é possível desativar as políticas de alertas que monitoram a instância.

Desativar uma política de alertas impede que ela acione ou feche incidentes, mas não impede que o Cloud Monitoring avalie as condições da política e grave os resultados. Para fechar problemas abertos após desativar uma política de alertas, silencie os incidentes correspondentes. Para informações sobre esse processo, consulte Como silenciar incidentes.

Quando uma política desativada é reativada, o Monitoring examina os valores de todas as condições na janela de duração mais recente, que pode incluir dados coletados antes, durante e depois do intervalo pausado. As políticas podem ser acionadas imediatamente após serem retomadas mesmo com grandes janelas de duração.

Por exemplo, suponha que um processo monitorado fique inativo por 20 minutos para manutenção. Se você reiniciar o processo e reativar imediatamente a política de alertas, o Monitoring reconhecerá que o processo não está ativo há cinco minutos e abre um incidente.

Latência da notificação

A latência de notificação é o atraso a partir do momento em que um problema se inicia pela primeira vez até o momento em que uma política é acionada.

Os eventos e as configurações a seguir contribuem para a latência geral da notificação:

  • Atraso de coleta de métrica: o tempo que o Cloud Monitoring precisa para coletar valores de métrica. Para valores do Google Cloud, a maioria das métricas não é visível por 60 segundos após a coleta. No entanto, o atraso depende da métrica. Os cálculos da política de alertas têm um atraso adicional de 60 a 90 segundos. Para métricas do AWS CloudWatch, o atraso da visibilidade pode ser de vários minutos. Para verificações de tempo de atividade, pode ser uma média de dois minutos (a partir do fim da janela de duração).

  • Janela de duração: a janela configurada para a condição. As condições só são atendidas quando uma condição é verdadeira durante toda a janela de duração. Por exemplo, uma configuração de janela de duração de cinco minutos causa atrasos na notificação de pelo menos cinco minutos a partir da primeira ocorrência do evento.

  • Tempo para a chegada da notificação: os canais de notificação, como e-mail e SMS, podem enfrentar latências de rede ou de outros tipos não relacionados ao que está sendo entregue, às vezes na ordem dos minutos. Em alguns canais, como SMS e Slack, não há garantia de que as mensagens serão entregues.

A seguir