Comportamentos de políticas de alertas baseadas em métricas

As políticas de alertas baseadas em métricas no Cloud Monitoring permitem monitorar dados de séries temporais, criar alertas e enviar notificações. Você controla quando as políticas de alertas criam alertas e enviam notificações configurando períodos de alinhamento, janelas de novo teste e regras de várias condições. Entender como as políticas de alertas lidam com dados ausentes, limites para alertas e notificações e atrasos de notificação ajuda a minimizar falsos positivos e ajustar a capacidade de resposta dos alertas.

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

Períodos de alinhamento e janelas de reteste

O Cloud Monitoring avalia o período de alinhamento e a janela de novo teste ao determinar se a condição de uma política de alertas foi atendida.

Período de alinhamento

Antes que os dados de série temporal sejam monitorados por uma política de alertas, eles precisam ser regularizados para que a política tenha dados regularmente espaçados para avaliar. O processo de regularização é chamado de alinhamento.

O alinhamento envolve duas etapas:

  • Dividir a série temporal em intervalos regulares, um procedimento que também é chamado de bucketing de dados. O intervalo é o período de alinhamento.

  • Calcular um único valor para os pontos no período de alinhamento. Você escolhe como esse ponto único é calculado. É possível somar todos os valores, calcular a média deles ou usar o valor máximo. A função que combina os pontos de dados é chamada de alinhador. O resultado da combinação é chamado de valor alinhado.

    Para mais informações sobre alinhamento, consulte Alinhamento: regularização dentro da série.

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.

O Monitoring configura um período de alinhamento da seguinte maneira:

Console do Google Cloud

Para configurar o período de alinhamento, escolha um valor para os seguintes campos na página Condições de alerta:

  • Janela contínua: especifica o período a ser avaliado.
  • Função de janela contínua: especifica a função matemática a ser executada na janela de pontos de dados.

Para mais informações sobre as funções disponíveis, consulte Aligner na referência da API. Algumas das funções de alinhador alinham os dados e os convertem de um tipo de métrica para outro. Para uma explicação detalhada, consulte Tipos, tipos e conversões.

API

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

Para mais informações sobre as funções disponíveis, consulte Aligner na referência da API. Algumas das funções de alinhador alinham os dados e os convertem de um tipo de métrica para outro. Para uma explicação detalhada, consulte Tipos, tipos e conversões.

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 está 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. Além disso, suponha que a condição seja atendida 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. Neste exemplo, a janela de novo teste, descrita na próxima seção, é de três minutos. A figura a seguir ilustra várias avaliações sequenciais da condição:

Figura que ilustra o efeito do período de alinhamento na janela/duração do reteste.

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. Os pontos mais antigos são pretos. Cada linha mostra o valor alinhado e se ele é 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 é dois. Na terceira avaliação, a soma é três e, como esse valor é maior que o limite, um timer para a janela de novo teste é iniciado.

Teste as janelas novamente

A condição de uma política de alertas tem uma janela de novo teste, que impede que a condição seja atendida devido a uma única medição ou previsão. Por exemplo, suponha que a janela de novo teste de uma condição esteja definida 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 atendidas 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 atendidas quando nenhum dado chega para uma série temporal em um intervalo de 15 minutos.
  • As condições de previsão são atendidas quando todas as previsões produzidas durante uma janela de 15 minutos preveem que a série temporal vai violar o limite dentro da janela de previsão.

Para políticas com uma condição, um alerta é aberto e as notificações são enviadas quando a condição é atendida. Esses alertas permanecem abertos enquanto a condição continua sendo atendida.

Console do Google Cloud

Para configurar a janela de novo teste, use o campo Janela de novo teste na etapa Configurar acionador de alerta.

API

Para configurar a janela de novo teste, defina o campo chamado duration nas estruturas MetricThreshold e MetricAbsence.

A figura anterior ilustrou 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 é atendida porque a janela de novo teste está definida como três minutos. A figura a seguir ilustra os resultados das próximas avaliações da condição:

Figura que ilustra o efeito da janela de reteste.

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

Uma condição redefine a janela de novo teste sempre que uma medição ou previsão não satisfaz a condição. Portanto, defina uma janela de reteste longa o suficiente para minimizar falsos positivos, mas curta o suficiente para verificar se os alertas são abertos em tempo hábil. 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 novo teste 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 alerta e envie um e-mail para sua equipe de suporte.

A sequência a seguir ilustra como a janela de novo teste 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, então a condição redefine a janela de novo teste.

  4. Nos próximos cinco minutos consecutivos, a latência HTTP é maior que dois segundos, então a condição é atendida.

    Como a política de alertas tem uma condição, o Monitoring envia notificações quando ela é atendida.

Práticas recomendadas para definir o período de alinhamento e a janela de novo teste

Para configurar uma política de alertas que avalie de forma confiável sem falsos alertas, configure o período de alinhamento e a janela de reteste com base no seu caso de uso.

Definir o período de alinhamento

O período de alinhamento determina quantas amostras o alinhador combina em uma medição agregada. Ao definir o período de alinhamento, considere o intervalo de amostragem da métrica e o atraso de ingestão:

  • Período mínimo de alinhamento: o período de alinhamento precisa ser de pelo menos 60 segundos (1 minuto) e precisa ser um múltiplo inteiro de 60 segundos. Para garantir que cada janela de alinhamento capture dados representativos, defina o período de alinhamento como pelo menos o intervalo de amostragem da métrica, arredondado para um múltiplo de 60 segundos. Por exemplo, para uma métrica que coleta amostras a cada 30 segundos, defina o período de alinhamento como pelo menos 60 segundos.

  • Atraso de ingestão: os dados de métricas passam por latência de coleta e ingestão antes de chegar ao Monitoring. Ao avaliar políticas de alertas, o Monitoring muda os tempos de avaliação para o passado para considerar o atraso de ingestão esperado de cada métrica, normalmente pelo menos 60 segundos, com atrasos mais curtos para métricas como verificações de tempo de atividade e atrasos mais longos para métricas de latência mais alta, como métricas de nuvem de terceiros ou baseadas em registros definidas pelo usuário. No entanto, se uma métrica externa ou de terceiros tiver uma latência de ingestão variável que exceda o atraso integrado, escolha um período de alinhamento amplo o suficiente para capturar vários intervalos de amostragem, de modo que as amostras atrasadas não produzam janelas de alinhamento vazias.

  • Período máximo de alinhamento: para condições de limite de métrica, o período de alinhamento pode ser de no máximo 25 horas. Para condições de ausência de métrica, a soma do período de alinhamento e da janela de novo teste não pode exceder 25 horas. Se você precisar avaliar tendências históricas em janelas de lookback de mais de 25 horas (até 2 anos), use o PromQL. As regras de alerta do PromQL que analisam um período maior que 25 horas exigem que a janela de reteste (duration) seja zero, não oferecem suporte a métricas personalizadas ou com base em registros e aplicam intervalos de avaliação mínimos que aumentam com a duração do período de análise:

    • De 25 horas e 10 minutos a 8 dias: 5 minutos
    • De 8 a 16 dias: 1 hora
    • De 16 a 32 dias: 2 horas
    • De 32 a 93 dias: 6 horas
    • De 93 dias a 2 anos: 12 horas

    Para mais informações, consulte Usar o PromQL para criar políticas de alertas.

Definir a janela de novo teste

A janela de novo teste (duration) especifica por quanto tempo uma série temporal precisa violar continuamente o limite da condição antes que o Monitoring abra um alerta:

  • Capacidade de resposta: para condições de limite de métrica, definir a janela de novo teste como zero (exibida no console do Google Cloud como Sem novo teste) faz com que um alerta seja aberto quando uma única medição alinhada viola o limite. Para condições de ausência de métrica, os dados precisam estar ausentes durante toda a janela de reteste antes que a condição seja atendida.

  • Evite alertas falsos: para evitar alertas falsos causados por picos temporários, jitter de avaliação ou variação na coleta de métricas, defina a janela de novo teste como pelo menos 180 segundos (3 minutos). Definir a janela de novo teste como zero abre um alerta em um único ponto anômalo.

As condições da política de alertas são avaliadas em uma frequência fixa, exceto quando você usa o PromQL. Para o PromQL, a frequência de avaliação pode variar de acordo com a duração de lookback da consulta.

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 sua política de alertas tiver várias condições, especifique quando um alerta será aberto. Para configurar como várias condições são combinadas, siga um destes procedimentos:

Console do Google Cloud

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

API

Configure 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:

Google Cloud console
Valor dos acionadores de política		 Valor do combinador
da API Cloud Monitoring		 Significado
Qualquer condição é atendida OR Um alerta 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 alerta é aberto para cada condição que é atendida quando todas as condições são atendidas, 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 alerta é aberto para cada condição que é atendida quando todas as condições são atendidas, somente 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 atendida significa que a configuração da condição é avaliada como verdadeira. 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 contém 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 da CPU de qualquer instância é maior que 60% por 1 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 por um minuto, a condição CPU usage is too high é atendida. Se as condições forem combinadas com Qualquer condição for atendida, um alerta será criado porque uma condição foi atendida. Se as condições forem combinadas com Todas as condições forem atendidas ou Todas as condições forem atendidas, mesmo para recursos diferentes para cada condição, um alerta não será criado. Essas escolhas do combinador exigem que as duas condições sejam atendidas.

Em seguida, suponha que o uso da CPU de vm1 permaneça maior que 100 ms/s e que o uso da CPU de 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 alerta é 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 alerta. Um alerta é 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, mesmo para recursos diferentes em cada condição: um alerta é criado porque as duas condições são atendidas.

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

Dados de métricas parciais

Quando os dados de série temporal param de chegar ou quando os dados estão atrasados, o Monitoring os classifica como ausentes. A falta de dados pode impedir o encerramento dos alertas. Os atrasos na chegada de dados de provedores de nuvem de terceiros podem ser de até 30 minutos, sendo que os atrasos de 5 a 15 minutos são os mais comuns. Um atraso longo, maior que a janela de novo teste, pode fazer com que as condições entrem em um estado "desconhecido". Quando os dados finalmente chegarem, 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 alerta está aberto e uma medição esperada não chega, você quer que o Monitoring deixe o alerta aberto ou o feche imediatamente? Da mesma forma, quando os dados param de chegar e nenhum alerta está aberto, você quer que um alerta seja aberto? Por fim, por quanto tempo um alerta deve permanecer aberto depois que os dados param de chegar?

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ê define na etapa Acionador de condição. Esse campo fica desativado quando a janela de novo teste está definida como Sem novo teste.

    A janela de novo teste é o campo chamado "duration" na API Cloud Monitoring.

  • Para configurar quanto tempo o Monitoring espera antes de fechar um alerta aberto depois que os dados param de chegar, use o campo Duração do fechamento automático do alerta. 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:

Google Cloud console
Campo "Avaliação de dados ausentes"		 Resumo Detalhes
Dados ausentes: vazio Os alertas abertos permanecem abertos.
Novos Alertas do Notícias 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 alerta estiver aberto para essa condição, ele vai continuar aberto. Quando um alerta está aberto e nenhum dado chega, o timer de fechamento automático é iniciado após um atraso de pelo menos 15 minutos. Se o timer expirar, o alerta 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.
Pontos de dados ausentes tratados como valores que violam a condição da política Os alertas abertos permanecem abertos.
Novos alertas podem ser abertos.

Para condições que são atendidas, a condição continua sendo atendida quando os dados param de chegar. Se um alerta estiver aberto para essa condição, ele vai continuar aberto. Quando um alerta está aberto e nenhum dado chega durante o período de fechamento automático mais 24 horas, o alerta é 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 tempo especificado pela janela de novo teste, a condição será avaliada como atendida. Em uma política de alertas com uma condição, o cumprimento da condição resulta na abertura de um alerta.
Pontos de dados ausentes tratados como valores que não violam a condição da política Os alertas abertos são fechados.
Novos Alertas do Notícias 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 alerta estiver aberto para essa condição, ele 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.

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 alerta está aberto e uma medição esperada não chega, você quer que o Monitoring deixe o alerta aberto ou o feche imediatamente? Da mesma forma, quando os dados param de chegar e nenhum alerta está aberto, você quer que um alerta seja aberto? Por fim, por quanto tempo um alerta deve permanecer aberto depois que os dados param de chegar?

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 espera antes de fechar um alerta 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:

CampoevaluationMissingData da API
 Resumo Detalhes
EVALUATION_MISSING_DATA_UNSPECIFIED Os alertas abertos permanecem abertos.
Novos alertas 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 alerta estiver aberto para essa condição, ele vai continuar aberto. Quando um alerta é aberto e nenhum dado chega, o timer de fechamento automático é iniciado após um atraso de pelo menos 15 minutos. Se o timer expirar, o alerta 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.
EVALUATION_MISSING_DATA_ACTIVE Os alertas abertos permanecem abertos.
Novos alertas podem ser abertos.

Para condições que são atendidas, a condição continua sendo atendida quando os dados param de chegar. Se um alerta estiver aberto para essa condição, ele vai continuar aberto. Quando um alerta está aberto e nenhum dado chega durante o período de fechamento automático mais 24 horas, o alerta é 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 tempo especificado pelo campo "duration", a condição será avaliada como atendida. Em uma política de alertas com uma condição, o cumprimento da condição resulta na abertura de um alerta.
EVALUATION_MISSING_DATA_INACTIVE Os alertas abertos são fechados.
Novos alertas 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 alerta estiver aberto para essa condição, ele 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.

Avaliação de dados ausentes em ciclos de vida de cargas de trabalho

Nas condições de limite de métrica e da linguagem de consulta do Monitoring, é possível configurar como o Monitoring avalia os dados ausentes quando série temporal param de gerar relatórios. Para configurar a avaliação de dados ausentes, a condição precisa ter uma janela de novo teste diferente de zero (duration). As condições do PromQL não são compatíveis com as configurações de avaliação de dados ausentes. Em vez disso, o Monitoring fecha um alerta aberto do PromQL depois que os dados ficam ausentes por dois intervalos de avaliação mais um período de carência.

Quando uma condição avalia dados ausentes com a configuração padrão Dados ausentes vazios (EVALUATION_MISSING_DATA_NO_OP ou EVALUATION_MISSING_DATA_UNSPECIFIED), um alerta que já foi aberto permanece aberto quando os dados de métricas param de chegar. Por exemplo, se um job ou contêiner temporário tiver um pico sustentado que abra um alerta e, em seguida, a carga de trabalho for encerrada, o alerta permanecerá aberto até que a duração do fechamento automático (padrão de sete dias) expire, porque nenhum ponto de dados subsequente chega para demonstrar que a métrica se recuperou abaixo do limite.

Para alinhar o comportamento da política de alertas com o ciclo de vida do aplicativo, selecione uma configuração de avaliação de dados ausentes e uma duração de fechamento automático com base nos seguintes tipos de carga de trabalho:

Tipo de carga de trabalho Configuração recomendada para dados ausentes Duração recomendada para fechamento automático Comportamento e lógica do ciclo de vida
Daemons e infraestrutura contínuos
(VMs do Compute Engine, instâncias do Cloud SQL, nós do GKE)		 Dados ausentes vazios (EVALUATION_MISSING_DATA_NO_OP) ou Valores que violam a condição (EVALUATION_MISSING_DATA_ACTIVE) Padrão (7 dias) ou 24 horas A infraestrutura contínua precisa emitir telemetria de métricas sem interrupção. Se a telemetria for interrompida enquanto um alerta estiver aberto, manter o alerta aberto garante que as partições de rede, as falhas de VM ou as falhas de daemon recebam atenção do operador em vez de serem fechadas automaticamente.
Cargas de trabalho temporárias e serviços de escalonamento automático
(pods do GKE, jobs e revisões do Cloud Run, Cloud Tasks, workers do Batch)		 Valores que não violam a condição (EVALUATION_MISSING_DATA_INACTIVE) De 30 minutos a 2 horas Os pods temporários e os contêineres sem servidor são encerrados ou reduzidos a zero depois de concluir o trabalho. Definir os dados ausentes como inativos garante que, quando um contêiner temporário desaparecer, a condição pare de ser avaliada como violada e o alerta seja fechado. Reduzir a duração do fechamento automático evita que incidentes temporários permaneçam por dias.
Cargas de trabalho periódicas e programadas
(consultas em lote diárias, cron jobs por hora, análises de dias do calendário)		 Valores que não violam a condição (EVALUATION_MISSING_DATA_INACTIVE) De 30 minutos a 2 horas As cargas de trabalho em lote periódicas informam métricas apenas durante execuções ativas. Como a duração do fechamento automático é medida a partir do momento em que a telemetria para de chegar, o uso de EVALUATION_MISSING_DATA_INACTIVE e uma duração de fechamento automático reduzida (pelo menos 30 minutos) evita que os alertas de execução única persistam nos dias do calendário.

Para minimizar problemas causados por dados ausentes, faça o seguinte:

  • Entre em contato com seu provedor de nuvem terceirizado para identificar maneiras de reduzir a latência de coleta de métricas.
  • Use janelas de reteste mais longas nas suas condições. Usar uma janela de reteste 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 Monitoring.
    • Métricas com base em registros, se a coleta de entradas de registro não estiver atrasada.

Para mais informações, consulte Visão geral do Agente de Operações, Visão geral das métricas definidas pelo usuário e Métricas com base em registros.

Quando o Monitoring envia notificações e cria alertas

O Cloud Monitoring envia uma notificação quando uma série temporal faz com que uma condição seja atendida. A notificação é enviada para todos os canais de notificação. Não é possível restringir uma notificação a um canal específico ou a um subconjunto dos canais da política.

Se você configurar notificações repetidas, a mesma notificação será reenviada para canais de notificação específicos da sua política de alertas.

Você poderá receber várias notificações exclusivas relacionadas a uma política de alertas quando qualquer 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. Nesse caso, as notificações recebidas dependem do valor do acionador de várias condições da política de alertas:

    • 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 atendida, a política de alertas envia uma notificação e cria um alerta.

      Não é possível configurar o Cloud Monitoring para criar apenas um alerta e enviar apenas uma notificação quando a política de alertas contiver várias condições.

    • Qualquer condição é atendida: a política de alertas envia uma notificação quando uma série temporal faz com que a condição seja atendida.

    Para mais informações, consulte Políticas com várias condições.

As políticas de alertas criadas com a API Cloud Monitoring também notificam você quando a condição é atendida e quando ela deixa de ser atendida. As políticas de alertas criadas usando o console do Google Cloud não enviam uma notificação quando a condição deixa de ser atendida, a menos que você tenha ativado esse comportamento.

Quando o Monitoring não envia notificações nem cria alertas

Nas seguintes situações, o Monitoring não cria alertas nem envia notificações quando as condições de uma política de alertas são atendidas:

  • A política de alertas está desativada.
  • A política de alertas é adiada.
  • O Monitoring atingiu o limite máximo de alertas abertos.

Políticas de alertas desativadas

O Monitoring não cria alertas nem envia notificações para políticas de alertas desativadas. No entanto, o Monitoring continua avaliando as condições de uma política de alertas desativada.

Quando você ativa uma política desativada, o Monitoring avalia os valores de todas as condições na janela de novo teste mais recente. A janela de reteste mais recente pode incluir dados coletados antes, durante e depois que a política foi ativada. As condições de uma política desativada podem ser atendidas imediatamente após a retomada da política, mesmo com grandes janelas de novo teste.

Por exemplo, suponha que você tenha uma política de alertas que monitora um processo específico e que você a desative. Na semana seguinte, o processo falha e, como a política de alertas está desativada, você não recebe uma notificação. Se você reiniciar o processo e ativar a política de alertas imediatamente, o Monitoring vai reconhecer que o processo não esteve ativo nos últimos cinco minutos e vai abrir um alerta.

Os alertas relacionados a uma política de alertas desativada permanecem abertos até que a duração do encerramento automático da política expire.

Políticas de alertas suspensas

O Monitoring não envia notificações nem cria alertas para uma política de alertas que está suspensa. Recomendamos adiar as políticas de alertas quando você quiser impedir que uma política de alertas envie notificações apenas por intervalos curtos. Por exemplo, antes de realizar a manutenção em uma máquina virtual (VM), é possível criar uma suspensão temporária e adicionar aos critérios de suspensão temporária as políticas de alertas que monitoram a instância.

Quando você adia uma política de alertas, o Monitoring fecha todos os alertas abertos relacionados à política. O Monitoring pode abrir novos alertas após o término do adiamento. Para mais informações, consulte Adiar notificações e alertas.

Limites de notificações e alertas abertos

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

Para evitar a sobrecarga do sistema, o número de alertas que uma única política pode abrir simultaneamente é limitado a 1.000.

Por exemplo, considere uma política que se aplica a 2.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 alertas abertos a 1.000. As condições restantes que forem atendidas serão ignoradas até que alguns dos alertas abertos para essa política sejam encerrados.

Como resultado desse limite, um único canal de notificação pode receber até 1.000 notificações de uma só vez. Se a política de alertas tiver vários canais de notificação, esse limite será aplicado a cada canal de forma independente.

Latência

Latência se refere ao atraso entre o momento em que o Monitoring coleta uma métrica e o momento em que o ponto de dados da métrica se torna visível como dados de série temporal. A latência afeta o momento em que as notificações são enviadas. Por exemplo, se uma métrica monitorada tiver uma latência de até 180 segundos, o Monitoring não vai criar um alerta por até 180 segundos depois que a condição da política de alertas for avaliada como verdadeira. Para mais informações, consulte Latência de dados de métricas.

Os seguintes eventos e configurações contribuem para a latência:

  • Atraso na coleta de métricas: o tempo que o Monitoring precisa para coletar valores de métricas. Para valores 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 da política de alertas levam um atraso adicional de até 5 minutos e 30 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, pode ser uma média de dois minutos (a partir do final da janela de novo teste).

  • Janela de reteste: a janela configurada para a condição. As condições só são atendidas quando uma condição é verdadeira durante toda a janela de reteste. Por exemplo, uma configuração de janela de novo teste de cinco minutos causa atrasos na notificação de pelo menos cinco minutos a partir do momento em que o evento ocorre pela primeira vez.

  • Tempo para a notificação chegar: os canais de notificação, como e-mail e SMS, podem apresentar latências de rede ou outras latências (não relacionadas ao que está sendo entregue), às vezes se aproximando de minutos. Em alguns canais, como SMS e Slack, não há garantia de que as mensagens serão entregues.

A seguir