Comportamento das políticas de alertas com base 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 e duração do 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 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

As condições nas políticas de alertas comparam os valores alinhados com os limites. O período de alinhamento é um intervalo de lookback de um ponto específico no tempo. 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 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 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 denominada 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 será dois. 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 a duração ou a janela de duração para evitar que uma condição seja atendida devido a uma única medição. Por exemplo, quando a duração de uma condição de limite de métrica é de cinco minutos, a condição é atendida somente quando cada medição alinhada em um intervalo de cinco minutos viola o limite. Se uma política tiver uma condição, um incidente será aberto e as notificações serão enviadas quando a condição for atendida.

Console do Google Cloud

Para configurar a janela de duração, use o campo Retest window na etapa Configure trigger.

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 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 horário 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. É essa medição que é comparada ao 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: esta política de alertas contém uma condição 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 um e-mail para a 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 será maior que dois segundos.
  3. Na próxima medição, a latência será inferior a dois segundos. Portanto, a condição redefinirá 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.

    Como a política tem uma condição, quando ela é atendida, um incidente é aberto e as notificações são enviadas.

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 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.

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:

Console do Google Cloud

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

API

Você configura 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
A política aciona o valor
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 que um recurso diferente faça com que essas condições 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 o uso 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 1 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 resulta na criação de um incidente. Um incidente é criado porque vm1 e vm2 que 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 os dados são atrasados, o Monitoring os classifica como ausentes. Os dados ausentes podem resultar em políticas não alertas e incidentes não fechados. Os atrasos nos dados que chegam de provedores de nuvem de terceiros podem ser de até 30 minutos, com o atraso 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 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 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 feche-o imediatamente? Da mesma forma, quando os dados param de chegar e nenhum incidente é aberto, você quer que um incidente seja aberto? Por quanto tempo um incidente permanecerá aberto depois que os dados chegarem?

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 gatilho. Esse campo é desativado quando a janela de novo teste é definida como Não testar novamente.

  • 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 é sete dias.

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

Console do Google Cloud
"Ausência de campo de dados para avaliação
Resumo Detalhes
Dados ausentes vazios Os incidentes abertos permanecem abertos.
Novos incidentes não são abertos.

Nas condições 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 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 a não ser 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.
Novos incidentes podem ser abertos.

Nas condições 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 está aberto e nenhum dado é recebido durante o fechamento automático mais 24 horas, ele é encerrado.

Para condições que não são atendidas, essa configuração faz com que a condição do 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, a condição que é atendida resulta na abertura de um incidente.

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.

Nas condições 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 a não ser 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 feche-o imediatamente? Da mesma forma, quando os dados param de chegar e nenhum incidente é aberto, você quer que um incidente seja aberto? Por quanto tempo um incidente permanecerá aberto depois que os dados chegarem?

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 de API
evaluationMissingData
Resumo Detalhes
EVALUATION_MISSING_DATA_UNSPECIFIED Os incidentes abertos permanecem abertos.
Novos incidentes não são abertos.

Nas condições 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 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 a não ser atendida quando os dados param de chegar.

EVALUATION_MISSING_DATA_ACTIVE Os incidentes abertos permanecem abertos.
Novos incidentes podem ser abertos.

Nas condições 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 está aberto e nenhum dado é recebido durante o fechamento automático mais 24 horas, ele é encerrado.

Para condições que não são atendidas, essa configuração faz com que a condição do limite de métrica se comporte como um 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 que é atendida resulta na abertura de um incidente.

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

Nas condições 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 a não ser atendida quando os dados param de chegar.

É possível minimizar problemas devido à ausência de dados seguindo um destes procedimentos:

  • 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

Para impedir 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 dele. Quando o adiamento está ativo, a política não cria incidentes nem envia notificações.

Quando as políticas estã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. 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 dessa política sejam fechados.

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 for acionada, você receberá duas notificações e verá 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 notificam você quando a condição é atendida e quando ela é interrompida. Por padrão, as políticas de alertas criadas usando o console do Google Cloud notificam você 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

Quando você desativa uma política de alertas, a política continua a avaliar as condições dela. 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 diminui, e como a política é desativada, você não é notificado. Se você reiniciar o processo e ativar a política de alertas imediatamente, o Monitoring reconhecerá que o processo não está ativo nos últimos cinco minutos e abre 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 Isolamento de 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 desativar a política. 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 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 de políticas de alertas têm 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 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 do primeiro 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