Comportamento das políticas de alertas baseadas em métricas

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Neste documento, descrevemos como as configurações de período de alinhamento e duração determinam quando uma condição é acionada, como as políticas de alertas combinam várias condições e como elas substituem os pontos de dados ausentes. Também descreve o número máximo de incidentes abertos para uma política, o número de notificações por incidente e o que causa atrasos nas 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 lookback de um determinado momento. O alinhador é a função que combina os pontos no intervalo de lookback em um valor alinhado. 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.

Console do Google Cloud

Configure os campos de alinhamento com os menus Janela contínua e Função de janela contínua que fazem parte da caixa de diálogo Nova condição.

API

Para configurar os campos de alinhamento, defina os campos aggregations.alignmentPeriod e aggregations.perSeriesAligner nas estruturas MetricThreshold e MetricAbsence.

Para ilustrar o efeito do período de alinhamento em uma condição em uma política de alertas, considere uma condição de limite de métrica que monitora 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 o alinhador esteja definido como sum. Além disso, suponha que a condição seja acionada quando o valor alinhado da série temporal for maior que dois por pelo menos três minutos e 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 mostrados 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 rotulada como start, o valor alinhado é calculado como um, 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 como esse valor é maior que o limite, um timer para a duração é iniciado.

Janela de duração

Use duration ou janela de duração para evitar que uma condição seja acionada devido a uma única medição ou previsão. Por exemplo, suponha que o campo de duração de uma condição esteja definido como 15 minutos. Veja a seguir o comportamento da condição com base no tipo:

  • As condições de limite de métrica são acionadas quando, para uma única série temporal, todas as medições alinhadas em um intervalo de 15 minutos violam o limite.
  • As condições de ausência de métrica são acionadas quando nenhum dado chega para uma série temporal em um intervalo de 15 minutos.
  • As condições de previsão são acionadas quando cada previsão produzida durante uma janela de 15 minutos prevê que a série temporal vai violar o limite dentro da janela.

No caso de políticas com uma condição, um incidente é aberto e as notificações são enviadas quando a condição é acionada. Esses incidentes permanecem abertos enquanto a condição continua sendo atendida.

Console do Google Cloud

Configure a janela de duração usando o campo Janela de teste novamente na etapa Configurar acionador.

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 de uma condição de limite de métrica. No momento start + 2 minutes, o valor alinhado é maior que o limite. No entanto, a condição não é acionada 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 de start + 2 minutes, a condição não será acionada até que o valor alinhado seja maior que o limite por três minutos. Esse evento ocorre às start + 5 minutes.

Uma condição redefine a janela de duração sempre que uma medição ou previsão não atende à condição. Esse comportamento é ilustrado no exemplo a seguir:

Exemplo: essa política de alertas contém uma condição de limite de métrica que especifica uma janela de duração de cinco minutos.

Se a latência da 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 o e-mail para sua 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, então a condição é acionada.

    Como a política tem uma condição, um incidente é aberto e as notificações são enviadas quando a condição é 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

Sempre defina o período de alinhamento, que determina quantas amostras são combinadas com o alinhador, para ser pelo menos igual ao período de amostragem. Para combinar cinco amostras, defina o período de alinhamento como cinco vezes maior que o de amostragem.

Use a janela de duração para especificar a capacidade de resposta do alerta. Por exemplo, se você definir a janela de duração como 20 minutos para uma condição de ausência de métrica, não haverá dados por 20 minutos antes que a condição seja acionada. Se você quiser um alerta mais responsivo, defina a duração como um valor menor. Para que as condições de limite de métrica tenham o alerta mais responsivo, defina a duração como zero. Um único valor alinhado faz com que esses tipos de condições sejam acionados.

As condições da política de alertas são avaliadas em uma frequência fixa. As escolhas 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.

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:

Console do Google Cloud

Você configura as opções do combinador na etapa Gatilho de várias condições.

API

Você configura as opções do combinador com o campo combiner da estrutura AlertPolicy.

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

Console do Google Cloud
Valor da política		 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 será aberto se cada condição for atendida, mesmo se um recurso diferente fizer 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 da 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 de 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 as operações vm1 e vm2 que atendem à condição CPU usage is too high são eventos diferentes.

  • 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 os dados são atrasados, o Monitoring classifica eles como ausentes. Isso pode fazer com que as políticas não sejam alertadas e os incidentes não sejam encerrados. Os atrasos de dados que chegam de provedores de nuvem de terceiros podem chegar a 30 minutos, com o intervalo mais comum: de 5 a 15 minutos. 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 finalmente 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.

Console do Google Cloud

É possível configurar a forma 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 não há nenhum incidente aberto, você quer que um incidente seja aberto? Por quanto tempo um incidente deve permanecer aberto após a interrupção 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 que você definiu na etapa Condição acionador. Este campo é desativado quando a janela de novo 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 sete dias.

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

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

Quando as condições são atendidas, ela continua sendo atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele permanecerá aberto. Quando um incidente é 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.

No caso de condições não atendidas, ela continua não sendo atendida quando os dados param de chegar.
Os pontos de dados ausentes são tratados como valores que violam a condição da política Os incidentes abertos permanecem abertos.
É possível abrir novos incidentes.

Quando as condições são atendidas, ela continua sendo atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele permanecerá aberto. Quando um incidente é aberto e nenhum dado chega à duração do 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 uma 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, a condição atendida resulta na abertura de um incidente.
Os pontos de dados ausentes são tratados como valores que não violam a condição da política Os incidentes abertos estão fechados.
Os novos incidentes não são abertos.

No caso de condições atendidas, ela deixa de ser atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele será fechado.

No caso de condições não atendidas, ela continua não sendo atendida quando os dados param de chegar.

API

É possível configurar a forma 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 não há nenhum incidente aberto, você quer que um incidente seja aberto? Por quanto tempo um incidente deve permanecer aberto após a interrupção 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 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 da API
evaluationMissingData		 Resumo Detalhes
EVALUATION_MISSING_DATA_UNSPECIFIED Os incidentes abertos permanecem abertos.
Os novos incidentes não são abertos.

Quando as condições são atendidas, ela continua sendo atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele permanecerá aberto. Quando um incidente é 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.

No caso de condições não atendidas, ela 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.

Quando as condições são atendidas, ela continua sendo atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele permanecerá aberto. Quando um incidente é aberto e nenhum dado chega durante o 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 uma metric-absence condition. Se os dados não chegarem no horário especificado pelo campo "duration", a condição será avaliada como atendida. Para uma política de alertas com uma condição, a condição atendida resulta na abertura de um incidente.
EVALUATION_MISSING_DATA_INACTIVE Os incidentes abertos estão fechados.
Os novos incidentes não são abertos.

No caso de condições atendidas, ela deixa de ser atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele será fechado.

No caso de condições não atendidas, ela continua não sendo atendida quando os dados param de chegar.

Minimize os problemas devido à ausência de dados de uma destas maneiras:

  • Entre em contato com seu provedor de nuvem de terceiros 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 fazer com que suas políticas de alertas sejam 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, Visão geral das métricas definidas pelo usuário e Métricas com base em registros.

Notificações e incidentes por política

Para evitar que o Monitoring crie incidentes e envie notificações para uma política de alertas, uma opção é desativar a política. Uma alternativa é criar um adiamento e incluir a política nos critérios. Quando o adiamento está ativo, a política não cria incidentes nem envia notificações.

Quando as políticas são ativadas e não correspondem aos critérios de um adiamento ativo, os incidentes podem ser criados e as notificações podem ser enviadas. Esta seção descreve os limites do número de incidentes abertos por política e quando é possível ver várias notificações do 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 do sistema, o número de incidentes que uma única política pode abrir simultaneamente é limitado a 1.000.

Por exemplo, considere uma política que se aplica a 2.000 ou 20.000 instâncias do Compute Engine, e que cada uma faça com que as condições de alerta sejam atendidas. O monitoramento limita o número de incidentes abertos a 1.000. Todas as condições restantes 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 acionada. Você pode 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 acionadas, para cada série temporal que resulta em um acionamento de condição, 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 monitore uma série temporal. Quando todas as condições forem acionadas, você receberá duas notificações e verá dois incidentes.

    • Qualquer condição é atendida: a política envia uma notificação sempre que uma condição é acionada. Por exemplo, suponha que você tenha uma política com duas condições e cada condição monitore uma série temporal. Suponha que a primeira condição seja acionada. Isso faz com que um incidente seja aberto e uma notificação seja enviada. Se o incidente ainda estiver aberto quando uma medição subsequente fizer com que a segunda condição seja acionada, outra notificação será enviada.

As políticas de alertas criadas usando a API Cloud Monitoring notificam você quando a condição é acionada e quando a condição deixa de ser atendida. Por padrão, as políticas de alertas criadas usando o console do Google Cloud notificam você quando um incidente é aberto. Você não será notificado quando um incidente for encerrado. Você pode ativar as notificações quando o incidente for encerrado.

Notificações de políticas de alertas desativadas

Quando você desativa uma política de alertas, ela continua a avaliar as condições. No entanto, os incidentes não são criados e as notificações não são enviadas.

Quando você ativa uma política desativada, o Monitoring examina os valores de todas as condições na janela de duração mais recente. A duração mais recente pode incluir dados coletados antes, durante e depois da ativação da política. As políticas podem ser acionadas imediatamente após a retomada, mesmo com janelas de longa duração.

Por exemplo, suponha que você tenha uma política de alertas que monitora um processo específico e desativa essa política. Na semana seguinte, o processo é encerrado e, como a política é desativada, você não recebe uma notificação. Se você reiniciar o processo e ativar a política de alertas imediatamente, o Monitoring reconhecerá que o processo não está ativo há cinco minutos e abrirá um incidente.

Para fechar problemas abertos depois de desativar uma política de alertas, silencie os incidentes correspondentes. Para informações sobre esse processo, consulte Como silenciar incidentes.

Notificações de políticas que correspondem aos critérios de um adiamento ativo

Se você quiser impedir que uma política de alertas envie notificações por intervalos curtos, recomendamos criar um adiamento em vez de desativá-la. Por exemplo, antes de realizar a manutenção em uma máquina virtual (VM), é possível criar um adiamento e adicionar aos critérios de adiamento as políticas de alertas que monitoram a instância.

Quando uma condição de uma política de alertas é acionada e essa política corresponde aos critérios de um adiamento ativo, nenhum incidente é criado e nenhuma notificação é enviada. Quando o adiamento expira, a política pode criar incidentes e enviar notificações.

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 os valores do Google Cloud, a maioria das métricas não fica visível por 60 segundos após a coleta. No entanto, o atraso depende da métrica. Os cálculos de política de alertas levam um atraso adicional de 60 a 90 segundos. Para as métricas do AWS CloudWatch, o atraso de visibilidade pode ser de vários minutos. Para verificações de tempo de atividade, isso 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 ao longo da 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