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

Neste documento, descrevemos como o período de alinhamento e as configurações de duração determinam quando uma condição é atendida, como as políticas de alertas combinam várias condições e como as políticas de alertas substituem 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

O período de alinhamento é um intervalo de retrospectiva de um ponto específico no tempo. O aligner é 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 usando os menus Janela contínua e Função de janela contínua que fazem parte da caixa de diálogo Nova condição.

Para mais informações sobre as funções disponíveis, consulte Aligner na referência da API. Algumas das funções de alinhamento 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 os campos 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 alinhamento 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 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. 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. 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, enquanto os mais antigos são pretos. Cada linha exibe o valor alinhado e se esse valor é maior que o limite de dois. Para a linha 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 será dois. 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 a duração ou a janela de duração para evitar que uma condição seja atendida 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 a descrição do 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 cada previsão produzida durante uma janela de 15 minutos prevê que a série temporal vai violar o limite dentro da janela de previsão.

Para políticas com uma condição, um incidente é aberto e uma notificação é enviada quando a condição é atendida. Esses incidentes permanecem abertos enquanto a condição é atendida.

Console do Google Cloud

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

API

Para configurar a janela de duração, defina o campo 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 duração está definida como três minutos. A figura a seguir ilustra os resultados para as 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 será atendida até que o valor alinhado seja maior que o limite por três minutos. Esse evento ocorre no horário start + 5 minutes.

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

Exemplo: esta 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 um 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, de modo que 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 é atendida.

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

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.

Práticas recomendadas para definir o período de alinhamento e a janela de duração

O período de alinhamento determina quantas amostras são combinadas com o alinhador:

  • O valor mínimo do período de alinhamento para um tipo de métrica é o período de amostragem desse tipo de métrica. Por exemplo, se a amostragem do tipo de métrica for feita a cada 300 segundos, o período de alinhamento precisará ser de pelo menos 300 segundos. No entanto, se você quiser combinar cinco amostras, defina o período de alinhamento como 5 * 300 segundos ou 1.500 segundos.

  • O valor máximo do período de alinhamento é de 24 horas a menos do atraso de ingestão do tipo de métrica. Por exemplo, se o atraso na ingestão de uma métrica for de 6 horas, o valor máximo do período de alinhamento será de 18 horas.

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 poderá haver dados por 20 minutos antes que a condição seja atendida. Para uma política de alertas mais responsiva, defina a duração com um valor menor. Para condições de limite de métrica, para ter a política de alertas mais responsiva, defina a duração como zero. Um único valor alinhado faz com que esses tipos de condições sejam atendidos.

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 com que frequência 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 será aberto. Para configurar como várias condições são combinadas, siga um destes procedimentos:

Console do Google Cloud

As opções do combinador são configuradas 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:

Console do Google Cloud
Valor de acionadores 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 é aberto se cada condição for 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 at 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 esta 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 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 por 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 de 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 a 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 a vm1 e a 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 estão atrasados, o Monitoring os classifica como ausentes. A falta de dados pode impedir o fechamento de incidentes. Os atrasos nos dados que chegam 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 do que a janela de duração, pode fazer com que as condições entrem em um estado "desconhecido". Quando os dados finalmente chegarem, o Monitoring poderá 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 o feche imediatamente? Da mesma forma, quando os dados param de chegar e nenhum incidente está aberto, você quer que um incidente seja aberto? Por fim, por 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 que você definiu na etapa Acionador de condição. Esse campo é desativado quando a janela de novo teste é definida como Sem novo teste.

  • Para configurar quanto tempo o Monitoring aguarda antes de fechar um incidente aberto após a chegada dos dados, use o campo Duração do fechamento automático do incidente. Defina a duração do fechamento automático na etapa Notificação. A duração padrão do fechamento automático é 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.
Novos incidentes não são abertos.

Para as condições que são atendidas, a condição continua a ser 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, o timer de fechamento automático é iniciado após um atraso de pelo menos 15 minutos. Se o timer expirar, o incidente 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.
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.

Para as condições que são atendidas, a condição continua a ser 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 durante o 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 prazo especificado pela janela de novo teste, a condição será avaliada como atendida. Para uma política de alertas com uma condição, o cumprimento da condição 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 são fechados.
Novos incidentes não são abertos.

Para as 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 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 o feche imediatamente? Da mesma forma, quando os dados param de chegar e nenhum incidente está aberto, você quer que um incidente seja aberto? Por fim, por 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 evaluationMissingData da estrutura MetricThreshold. Este campo é ignorado quando o campo duration é zero.

  • Para configurar quanto tempo o Monitoring espera antes de fechar um incidente aberto após os dados deixarem 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 as condições que são atendidas, a condição continua a ser 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, o timer de fechamento automático é iniciado após um atraso de pelo menos 15 minutos. Se o timer expirar, o incidente 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.
EVALUATION_MISSING_DATA_ACTIVE Os incidentes abertos permanecem abertos.
Novos incidentes podem ser abertos.

Para as condições que são atendidas, a condição continua a ser 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 durante o 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 tempo especificado pelo campo "duration", a condição será avaliada como atendida. Para uma política de alertas com uma condição, o cumprimento da condição resulta na abertura de um incidente.
EVALUATION_MISSING_DATA_INACTIVE Os incidentes abertos são fechados.
Novos incidentes não são abertos.

Para as 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 a não ser atendida quando os dados param de chegar.

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

  • 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 maior 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 dados diretamente no Monitoring.
    • Métricas com base em registros, se a coleta de entradas de registro não for 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 impedir que o Monitoring crie incidentes e envie notificações para uma política de alertas, crie um adiamento e inclua essa política nos critérios de adiamento. Quando o adiamento está ativo, a política de alertas 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, incidentes podem ser criados e notificações podem ser enviadas. Nesta seção, descrevemos os limites do número de incidentes abertos por política e quando você pode 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 fazer com que ela abra incidentes para cada recurso. Um incidente é aberto para cada série temporal que resulta no cumprimento de uma condição.

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, pense em 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 incidentes abertos a 1.000. Todas as condições restantes que forem atendidas serão ignoradas até que alguns dos incidentes abertos para essa política sejam fechados.

Número de notificações por política

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, o Monitoring envia uma notificação e cria um incidente para cada série temporal que resulta no cumprimento de uma condição. Por exemplo, suponha que você tenha uma política com duas condições e cada condição esteja monitorando uma série temporal. Quando todas as condições forem atendidas, você vai receber duas notificações e verá dois incidentes.

    • Qualquer condição é atendida: a política de alertas envia uma notificação sempre que uma condição é atendida. Por exemplo, suponha que você tenha uma política com duas condições e cada condição esteja monitorando uma série temporal. Suponha que a primeira condição seja atendida. 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 atendida, 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 deixa de ser atendida. Por padrão, as políticas de alertas criadas com o console do Google Cloud notificam você quando um incidente é aberto. Elas não notificam você quando um incidente é encerrado. É possível ativar as notificações de interdição de incidentes.

Notificações para políticas de alertas desativadas

Quando você desativa uma política de alertas, ela continua avaliando 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 condições de uma política desativada podem ser atendidas imediatamente após a retomada da política, mesmo com grandes janelas de duração.

Por exemplo, suponha que você tenha uma política de alertas que monitore um processo específico e que desative essa política. Na semana seguinte, o processo é interrompido, e você não recebe uma notificação porque a política de alertas foi desativada. Se você reiniciar o processo e ativar a política de alertas imediatamente, o Monitoring reconhecerá que o processo não está funcionando nos últimos cinco minutos e abrirá um incidente.

Ao desativar uma política de alertas, os incidentes abertos permanecem abertos até que a duração do fechamento automático expire. Quando você adia uma política de alertas, todos os incidentes abertos relacionados a ela são fechados. Mas, quando o adiamento terminar, novos incidentes poderão ser abertos. Para mais informações, consulte Adiar notificações e alertas.

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

Quando você quiser evitar que uma política de alertas envie notificações por intervalos curtos, recomendamos criar um adiamento em vez de desativar a política de alertas. Por exemplo, antes de executar 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 é atendida e essa política atende aos critérios de um adiamento ativo, nenhum incidente é criado e nenhuma notificação é enviada. Quando o adiamento expirar, a política de alertas poderá criar incidentes e enviar notificações.

Enviar notificações repetidas

Para lembrar os destinatários da notificação de incidentes abertos e reconhecidos, configure notificações repetidas. Esse recurso é útil para políticas de alertas que monitoram recursos críticos que, quando esgotados, podem causar falha em um serviço. Por exemplo, é possível configurar notificações repetidas para uma política de alertas que monitore a quantidade de espaço livre em disco.

Por padrão, uma política de alertas envia uma notificação para cada canal de notificação quando um incidente é aberto. No entanto, é possível alterar o comportamento padrão e configurar uma política de alertas para reenviar notificações a todos ou alguns dos canais de notificação de políticas de alertas. Essas notificações repetidas são enviadas para incidentes com um status "Aberto" ou "Reconhecido". O intervalo dessas notificações precisa ser de pelo menos 30 minutos e não mais do que 24 horas, expresso em segundos.

Console do Google Cloud

Não é possível configurar notificações repetidas no console do Google Cloud. Use a API ou Google Cloud CLI.

API

Adicione pelo menos um objeto NotificationChannelStrategy ao objeto AlertStrategy. Um objeto NotificationChannelStrategy tem dois campos:

  • renotifyInterval: o tempo, em segundos, entre notificações repetidas.

    É possível alterar o valor do campo renotifyInterval a qualquer momento. Se um incidente relacionado à política de alertas estiver aberto ao alterar o intervalo, a política enviará outra notificação sobre o incidente e, em seguida, reiniciará o período de intervalo.

  • notificationChannelNames: uma matriz de nomes de recursos de canais de notificação, que são strings no formato de projects/PROJECT_ID/notificationChannels/CHANNEL_ID. Esses canais de notificação recebem as notificações repetidas nos intervalos definidos pelo valor renotifyInterval.

    O ID do canal do nome do recurso é um valor numérico. Para informações sobre como recuperar o ID do canal, consulte Listar canais de notificação em um projeto.

O exemplo JSON a seguir mostra uma estratégia de alertas configurada para enviar notificações repetidas a cada 1.800 segundos (30 minutos) para o canal de notificação listado:

  "alertStrategy": {
    "notificationChannelStrategy": [
      {
        "notificationChannelNames": [
          "projects/PROJECT_ID/notificationChannels/CHANNEL_ID"
        ],
        "renotifyInterval": "1800s"
      }
    ]
  }

Para mais informações sobre como criar políticas de alertas com a API, consulte Criar políticas de alertas por API.

Para interromper as notificações repetidas por um período, desative ou crie um adiamento para a política de alertas. Para interromper completamente as notificações repetidas, edite a política de alertas usando a API e remova o objeto NotificationChannelStrategy.

Latência

Latência refere-se ao atraso entre o momento em que o Monitoring faz a amostragem de 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 envio das notificações. Por exemplo, se uma métrica monitorada tiver uma latência de até 180 segundos, o Monitoring não criará um incidente por até 180 segundos após a condição da política de alertas ser avaliada como verdadeira. Para mais informações, consulte Latência dos dados de métricas.

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

  • Atraso na coleta de métricas: o tempo que o Monitoring precisa para coletar valores de métricas. 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 da política 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, pode ser uma média de dois minutos (a partir do final da janela de duração).

  • Janela de duração: a janela configurada para a condição. As condições são atendidas apenas 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 outras latências (não relacionadas 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