Comportamento de políticas de alerta baseadas em métricas

Este documento descreve como os períodos de alinhamento e as janelas de reteste determinam quando uma condição é atendida, como as políticas de alerta combinam múltiplas condições e como as políticas de alerta substituem 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 alerta baseadas em logs. Para obter informações sobre políticas de alerta baseadas em logs, consulte Monitorando seus logs .

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 alerta foi atendida.

Período de alinhamento

Antes que os dados de séries temporais sejam monitorados por uma política de alerta, eles devem ser regularizados para que a política de alerta tenha dados regularmente espaçados para avaliação. O processo de regularização é chamado de alinhamento .

O alinhamento envolve duas etapas:

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

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

  Para obter 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 avança um minuto e contém as amostras recebidas entre 12h56 e 13h01.

O monitoramento configura um período de alinhamento da seguinte forma:

Google Cloud console

Você configura o período de alinhamento escolhendo um valor para os seguintes campos na página Condições de alerta :

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

Para obter mais informações sobre as funções disponíveis, consulte Aligner na referência da API. Algumas das funções do 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

Você configura o período de alinhamento definindo os campos aggregations.alignmentPeriod e aggregations.perSeriesAligner nas estruturas MetricThreshold e MetricAbsence .

Para obter mais informações sobre as funções disponíveis, consulte Aligner na referência da API. Algumas das funções do 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 alerta, 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 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, o período de alinhamento é de dois minutos e 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:

Cada linha na figura ilustra uma única avaliação da condição. Os dados da série temporal são mostrados. Os pontos no período de alinhamento são mostrados com pontos azuis; 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 start , o valor alinhado é computado 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 cronômetro para a janela de reteste é iniciado.

Janelas de reteste

A condição de uma política de alerta tem uma janela de reteste , que impede que a condição seja atendida devido a uma única medição ou previsão. Por exemplo, suponha que a janela de reteste de uma condição esteja definida para 15 minutos. A seguir, descrevemos o comportamento da condição com base em seu tipo:

• As condições de limite métrico são atendidas quando, para uma única série temporal, cada medição alinhada em um intervalo de 15 minutos viola 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 violará o limite dentro da janela de previsão.

Para políticas com uma condição, um incidente é aberto e notificações são enviadas quando a condição é atendida. Esses incidentes permanecem abertos enquanto a condição continuar a ser atendida.

Google Cloud console

Você configura a janela de novo teste usando o campo Janela de novo teste na etapa Configurar gatilho de alerta .

API

Você configura a janela de novo teste definindo o campo chamado duration nas estruturas MetricThreshold e MetricAbsence .

A figura anterior ilustrou três avaliações de uma condição de limiar métrico. No instante start + 2 minutes , o valor alinhado é maior que o limiar; no entanto, a condição não é atendida porque a janela de reteste está definida para três minutos. A figura a seguir ilustra os resultados para as próximas avaliações da condição:

Mesmo que o valor alinhado seja maior que o limite no tempo 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 tempo start + 5 minutes .

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

Exemplo : esta política de alerta 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,
então abra um incidente 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 do 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 é 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 for maior que dois segundos, então a condição será atendida.

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

Defina a janela de novo teste para ser longa o suficiente para minimizar falsos positivos, mas curta o suficiente para garantir que os incidentes sejam abertos em tempo hábil.

Melhores práticas para definir o período de alinhamento e a janela de reteste

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 o tipo de métrica for amostrado a cada 300 segundos, o período de alinhamento deverá ser de pelo menos 300 segundos. No entanto, se você quiser combinar 5 amostras, defina o período de alinhamento como 5 * 300 segundos ou 1500 segundos.

• O valor máximo do período de alinhamento é de 24 horas menos o atraso de ingestão do tipo de métrica. Por exemplo, se o atraso de 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 reteste para especificar a capacidade de resposta do alerta. Por exemplo, se você definir a janela de reteste como 20 minutos para uma condição de ausência de métrica , não deverá haver dados por 20 minutos antes que a condição seja atendida. Para uma política de alerta mais responsiva, defina a janela de reteste com um valor menor. Para condições de limite de métrica, para ter a política de alerta mais responsiva, defina a janela de reteste como zero. Um único valor alinhado faz com que esses tipos de condições sejam atendidos.

As condições da política de alerta são avaliadas com uma frequência fixa. As escolhas que você faz para o período de alinhamento e a janela de reteste não determinam a frequência com que a condição é avaliada.

Políticas com múltiplas condições

Uma política de alerta pode conter até 6 condições.

Se você estiver usando a API de Monitoramento em Nuvem ou se sua política de alertas tiver várias condições, será necessário especificar quando um incidente será aberto. Para configurar como várias condições são combinadas, siga um destes procedimentos:

Google Cloud console

Você configura as opções do combinador na etapa de gatilho multicondição .

API

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

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

Google Cloud console A política aciona valor	API de monitoramento em nuvem valor combinador	Significado
Qualquer condição é atendida	OR	Um incidente é aberto se qualquer recurso fizer com que qualquer uma das condições seja atendida.
Todas as condições são atendidas mesmo para diferentes recursos para cada condição (padrão)	AND	Um incidente é aberto para cada condição 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 incidente é aberto para cada condição atendida quando todas as condições forem atendidas, somente se o mesmo recurso fizer com que cada condição seja atendida. Esta configuração é a opção de combinação mais rigorosa.
Observação: a política de alertas usa os valores de rótulo para identificar o recurso que causou o atendimento de uma condição. Para que uma política de alertas com este combinador crie incidentes ou gere notificações, o seguinte deve ser verdadeiro: Cada condição deve monitorar o mesmo recurso. Por exemplo, para todas as condições, o tipo de recurso é definido como gce_instance . Os rótulos de recursos monitorados disponíveis após a agregação devem ser os mesmos para todas as condições. Por exemplo, para o recurso gce_instance , os rótulos são project_id , instance_id e zone . Se uma condição for agrupada por zone , todas as condições deverão ser agrupadas por zone . Para obter uma lista de recursos monitorados e seus rótulos, consulte Tipos de recursos monitorados .

Neste 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 esta instrução for avaliada como "true" , a condição será atendida.

Exemplo

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

• A condição denominada 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 é superior a 100 ms/s por 1 minuto.
• A condição denominada 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 é superior a 60% por 1 minuto.

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

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 para um minuto, a condição CPU usage is too high é atendida. Se as condições forem combinadas com "Qualquer condição for atendida" , um incidente 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 incidente não será criado. Essas opções de combinação exigem que ambas as condições sejam atendidas.

Em seguida, suponha que o uso da CPU da VM1 permaneça superior a 100 ms/s e que a utilização da CPU da VM2 exceda 60% por 1 minuto. O resultado é que ambas as condições são atendidas. A seguir, descrevemos o que ocorre com base na combinação das condições:

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

  Se a VM2 causar a condição de CPU usage is too high para ser atendido", isso também resultará na criação de um incidente. Um incidente é criado porque as VM1 e VM2 que causam a condição de CPU usage is too high para ser atendido" são eventos distintos.

• Todas as condições são atendidas, 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 este combinador requer 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 para ser atendido, enquanto a VM2 faz com que Excessive utilization seja atendida.

Dados métricos parciais

Quando os dados de séries temporais param de chegar ou sofrem atrasos, o Monitoring classifica os dados como ausentes . Dados ausentes podem impedir o fechamento de incidentes. Atrasos na chegada de dados de provedores de nuvem terceirizados podem chegar a 30 minutos, sendo atrasos de 5 a 15 minutos os mais comuns. Um atraso prolongado — maior que a janela de reteste — 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. Uma inspeção posterior dos dados de séries temporais pode não revelar esse problema, pois não há evidências de atrasos após a chegada dos dados.

Google Cloud console

Você pode 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ê deseja 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ê deseja que um incidente seja aberto? Por fim, por quanto tempo um incidente deve permanecer aberto após o término da chegada dos dados?

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

• Para configurar como o Monitoramento determina o valor de substituição para dados ausentes, use o campo Avaliação de dados ausentes definido na etapa Acionador de condição . Este campo é desabilitado quando a janela de reteste está definida como Sem reteste .

  A janela de novo teste é o campo chamado duração na API de monitoramento de nuvem.

• Para configurar quanto tempo o Monitoramento aguarda antes de fechar um incidente aberto após o término do recebimento de dados, use o campo Duração do fechamento automático do incidente . Você define a duração do fechamento automático na etapa Notificação . A duração padrão do fechamento automático é de sete dias.

A seguir, descrevemos as diferentes opções para o campo de dados ausente:

Google Cloud console Campo "Avaliação de dados faltantes"	Resumo	Detalhes
Dados ausentes vazios	Incidentes abertos permanecem abertos. Novos incidentes não são abertos.	Para condições 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 estiver aberto e nenhum dado chegar, o temporizador de fechamento automático será iniciado após um atraso de pelo menos 15 minutos. Se o temporizador 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 são tratados como valores que violam a condição da política	Incidentes abertos permanecem abertos. Novos incidentes podem ser abertos.	Para condições 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 estiver aberto e nenhum dado chegar durante o período de fechamento automático mais 24 horas, o incidente será encerrado. Para condições não atendidas, esta 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 pela janela de reteste, a condição será avaliada como atendida. Para uma política de alerta com uma condição, a condição atendida resulta na abertura de um incidente.
Pontos de dados ausentes são tratados como valores que não violam a condição da política	Incidentes abertos são fechados. Novos incidentes não são abertos.	Para 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, 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.

API

Você pode 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ê deseja 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ê deseja que um incidente seja aberto? Por fim, por quanto tempo um incidente deve permanecer aberto após o término da chegada dos dados?

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

• Para configurar como o Monitoramento 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 .

A seguir, descrevemos as diferentes opções para o campo de dados ausente:

API campo evaluationMissingData	Resumo	Detalhes
EVALUATION_MISSING_DATA_UNSPECIFIED	Incidentes abertos permanecem abertos. Novos incidentes não são abertos.	Para condições 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 estiver aberto e nenhum dado chegar, o temporizador de fechamento automático será iniciado após um atraso de pelo menos 15 minutos. Se o temporizador 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	Incidentes abertos permanecem abertos. Novos incidentes podem ser abertos.	Para condições 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 estiver aberto e nenhum dado chegar durante o período de fechamento automático mais 24 horas, o incidente será encerrado. Para condições não atendidas, esta 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 `duração`, a condição será avaliada como atendida. Para uma política de alerta com uma condição, a condição atendida resulta na abertura de um incidente.
EVALUATION_MISSING_DATA_INACTIVE	Incidentes abertos são fechados. Novos incidentes não são abertos.	Para 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, 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.

Você pode minimizar problemas devido à falta de dados executando qualquer um dos seguintes procedimentos:

• Entre em contato com seu provedor de nuvem terceirizado para identificar maneiras de reduzir a latência da coleta de métricas.
• Utilize janelas de reteste mais longas em suas condições. Usar uma janela de reteste mais longa tem a desvantagem de tornar suas políticas de alerta menos responsivas.

• Escolha métricas que tenham um atraso de coleta menor:

  • Monitorar métricas do agente, especialmente quando o agente está sendo executado em instâncias de VM em nuvens de terceiros.
  • Métricas personalizadas, quando você grava seus dados diretamente no Monitoramento.
  • Métricas baseadas em log, se a coleta de entradas de log não for atrasada.

Para obter mais informações, consulte Visão geral do agente de monitoramento , Visão geral de métricas definidas pelo usuário e Métricas baseadas em log .

Quando o monitoramento envia notificações e cria incidentes

O Cloud Monitoring envia uma notificação quando uma série temporal causa o atendimento de uma condição. 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 sua política.

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

Você pode receber várias notificações exclusivas relacionadas a uma política de alerta quando qualquer uma das seguintes situações for verdadeira:

• Uma condição é monitorar múltiplas séries temporais.

• Uma política contém várias condições. Nesse caso, as notificações que você recebe dependem do valor do gatilho multicondição da política de alerta:

  • Todas as condições são atendidas : quando todas as condições são atendidas, para cada série temporal que resulta no atendimento de uma condição, a política de alerta envia uma notificação e cria um incidente.

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

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

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

As políticas de alerta criadas com a API de Monitoramento em Nuvem também notificam você quando a condição é atendida e quando ela deixa de ser atendida. As políticas de alerta criadas com a API de Monitoramento em Nuvem também notificam você quando a condição é atendida e quando ela deixa de ser atendida. Google Cloud O console não envia uma notificação quando a condição deixa de ser atendida, a menos que você tenha habilitado esse comportamento.

Quando o monitoramento não envia notificações ou cria incidentes

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

• A política de alerta está desabilitada.
• A política de alerta está adiada.
• O monitoramento atingiu o limite do número máximo de incidentes abertos.

Políticas de alerta desabilitadas

O monitoramento não cria incidentes nem envia notificações para políticas de alerta desabilitadas. No entanto, o monitoramento continua avaliando as condições de uma política de alerta desabilitada.

Ao habilitar uma política desabilitada, o Monitoramento avalia os valores de todas as condições durante a janela de reteste mais recente. A janela de reteste mais recente pode incluir dados coletados antes, durante e depois da habilitação da política. As condições de uma política desabilitada podem ser atendidas imediatamente após a retomada da política, mesmo com grandes janelas de reteste.

Por exemplo, suponha que você tenha uma política de alertas que monitora um processo específico e que você desabilite essa política. Na semana seguinte, o processo fica inativo e, como a política de alertas está desabilitada, você não é notificado. Se você reiniciar o processo e habilitar a política de alertas imediatamente, o Monitoramento reconhecerá que o processo não está ativo há cinco minutos e abrirá um incidente.

Os incidentes relacionados a uma política de alerta desabilitada permanecem abertos até que a duração do fechamento automático da política expire.

Políticas de alertas adiadas

O monitoramento não envia notificações nem cria incidentes para uma política de alerta que esteja adiada . Recomendamos adiar as políticas de alerta quando você quiser impedir que uma política de alerta envie notificações apenas por curtos intervalos. Por exemplo, antes de realizar a manutenção em uma máquina virtual (VM), você pode criar uma adiamento e adicionar aos critérios de adiamento as políticas de alerta que monitoram a instância.

Ao suspender uma política de alerta, o Monitoring fecha todos os incidentes abertos relacionados à política. O Monitoring pode abrir novos incidentes após o término do período de suspensão. Para obter mais informações, consulte Suspender notificações e alertas .

Limites de notificações e incidentes abertos

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

Para evitar 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 instâncias do Compute Engine, e cada instância faz com que as condições de alerta sejam atendidas. O monitoramento limita o número de incidentes abertos a 1.000. Quaisquer condições restantes atendidas são ignoradas até que alguns dos incidentes abertos para essa política sejam encerrados.

Como resultado desse limite, um único canal de notificação pode receber até 1.000 notificações simultaneamente. Se a sua política de alertas tiver vários canais de notificação, esse limite se aplicará a cada canal de notificação de forma independente.

Observação: se você tiver um incidente aberto para uma política de alerta e a série temporal que acionou o incidente ultrapassar o limite de condição novamente, enquanto o incidente ainda estiver aberto, outro incidente não será aberto. O Cloud Monitoring mantém apenas um incidente aberto para cada série temporal em uma política de alerta.

Latência

Latência refere-se ao atraso entre o momento em que o Monitoramento coleta uma amostra 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 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 Monitoramento não criará um incidente por até 180 segundos após a condição da política de alerta ser avaliada como verdadeira. Para obter mais informações, consulte Latência de dados de métrica .

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

• Atraso na coleta de métricas : o tempo que o monitoramento precisa para coletar valores de métricas. Google Cloud Valores, 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íticas de alerta levam um atraso adicional de até 5 minutos e 30 segundos. Para métricas do AWS CloudWatch, o atraso de visibilidade pode ser de vários minutos. Para verificações de tempo de atividade, esse atraso pode ser em 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ão atendidas somente quando uma condição é verdadeira durante toda a janela de reteste. Por exemplo, uma janela de reteste definida como cinco minutos causa atrasos na notificação de pelo menos cinco minutos a partir da ocorrência inicial do evento.

• Tempo de chegada da notificação : Canais de notificação, como e-mail e SMS, podem apresentar latências de rede ou outras (não relacionadas ao conteúdo entregue), às vezes chegando a minutos. Em alguns canais, como SMS e Slack, não há garantia de que as mensagens sejam entregues.

O que vem a seguir

• Para obter informações sobre como criar uma política de alerta, consulte os seguintes documentos:

  • Criar políticas de alerta de limite de métrica
  • Crie políticas de alerta de ausência de métricas
  • Crie políticas de alerta de valor métrico previsto
  • Crie políticas de alerta usando a API de monitoramento

• Para uma variedade de políticas de alerta, consulte Políticas de exemplo .