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:
- A latência do HTTP é inferior a dois segundos.
- Nos próximos três minutos consecutivos, a latência HTTP será maior que dois segundos.
- Na próxima medição, a latência é inferior a dois segundos, então a condição redefine a janela de novo teste.
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. |
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 deCPU 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 queExcessive 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 |
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 estruturaMetricThreshold
. Este campo é ignorado quando o campoduration
é 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 estruturaAlertStrategy
.
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 |
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.
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:
Para uma variedade de políticas de alerta, consulte Políticas de exemplo .
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 reteste usando o campo Janela de reteste na etapa de gatilho de alerta de configuração .
API
Você configura a janela de reteste, 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 momento em que start + 2 minutes
, o valor alinhado é maior que o limite; No entanto, a condição não é atendida porque a janela de reteste é definida como três minutos. A figura a seguir ilustra os resultados para as próximas avaliações da condição:
Embora o valor alinhado seja maior que o limite no tempo start + 2 minutes
, a condição não é 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 cada vez que uma medição ou previsão não satisfaz a condição. Este comportamento é ilustrado no exemplo a seguir:
Exemplo : esta política de alerta contém uma condição de limiar métrico que especifica uma janela de reteste de cinco minutos.
Se a latência da resposta http for superior a dois segundos,
E se a latência for maior que o limite por cinco minutos,
Em seguida, abra um incidente e envie um e -mail para sua equipe de suporte.A sequência a seguir ilustra como a janela de reteste afeta a avaliação da condição:
- A latência HTTP é inferior a dois segundos.
- Nos três minutos seguintes, a latência do HTTP é superior a dois segundos.
- Na próxima medição, a latência é inferior a dois segundos; portanto, a condição redefine a janela de reteste.
Nos próximos cinco minutos consecutivos, a latência do HTTP é superior a dois segundos; portanto, a condição é 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 reteste para ser longa o suficiente para minimizar os falsos positivos, mas curto 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 métrico é o período de amostragem desse tipo métrico. Por exemplo, se o tipo métrico for amostrado a cada 300 segundos, o período de alinhamento deve ser de pelo menos 300 segundos. No entanto, se você deseja 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 é 24 horas menos o atraso de ingestão do tipo métrico. Por exemplo, se o atraso de ingestão para uma métrica for de 6 horas, o valor máximo do período de alinhamento for de 18 horas.
Use a janela Restest para especificar a capacidade de resposta do alerta. Por exemplo, se você definir a janela de reteste para 20 minutos para uma condição de ausência métrica , não deve haver dados por 20 minutos antes que a condição seja atendida. Para uma política de alerta mais responsiva, defina a janela de teste como um valor menor. Para condições de limiar métrico, para ter a política de alerta mais responsiva, defina a janela de reteste para 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 em uma frequência fixa. As escolhas que você faz para o período de alinhamento e a janela de reteste não determinam com que frequência a condição é avaliada.
Políticas com várias condições
Uma política de alerta pode conter até 6 condições.
Se você estiver usando a API de monitoramento da nuvem ou se sua política de alerta tiver várias condições, você deverá especificar quando um incidente será aberto. Para configurar como várias condições são combinadas, faça um dos seguintes:
Google Cloud console
Você configura as opções de combinador na etapa de gatilho de várias condições .
API
Você configura as opções de 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 da nuvem e uma descrição de cada configuração:
Google Cloud console A política desencadeia valor | API de monitoramento em nuvem Valor do combinador | Significado |
---|---|---|
Qualquer condição é atendida | OR | Um incidente é aberto se algum recurso fizer com que alguma das condições seja atendida. |
Todas as condições são atendidas mesmo para diferente Recursos para cada condição (padrão) | AND | Um incidente é 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 incidente é aberto para cada condição que é atendida quando todas as condições são atendidas, apenas se o mesmo recurso fizer com que cada condição seja atendida. Essa configuração é a escolha de combinação mais rigorosa. |
Nesse contexto, o termo Met 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
, então quando essa instrução é avaliada como verdadeira , a condição é atendida.
Exemplo
Considere um Google Cloud Projeto que contém duas instâncias da VM, VM1 e VM2. Além disso, suponha que você crie uma política de alerta com 2 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 100ms/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 avaliem como falsas .
Em seguida, suponha que o uso da CPU do VM1 exceda 100ms/s por 1 minuto. Como o uso da CPU é maior que o limite por um minuto, a condição CPU usage is too high
. Se as condições forem combinadas com qualquer condição , um incidente será criado porque uma condição é 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 combinador exigem que ambas as condições sejam atendidas.
Em seguida, suponha que o uso da CPU de VM1 permaneça maior que 100ms/se a utilização da CPU de VM2 excede 60% por 1 minuto. O resultado é que ambas as condições são atendidas. A seguir, descreve o que ocorre com base em 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, o VM2 faz com que a
Excessive utilization
da condição seja atendida.Se o VM2 causar a condição que
CPU usage is too high
para ser atendido, isso também resulta em um incidente que está sendo criado. Um incidente é criado porque VM1 e VM2 causando a condição queCPU 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 esse combinador exige que o mesmo recurso faça com que todas as condições sejam atendidas. Neste exemplo, nenhum incidente é criado porque o VM1 faz com que
CPU usage is too high
para ser atendido, enquanto o VM2 faz com queExcessive utilization
seja atendida.
Dados métricos parciais
Quando os dados da série temporal pararem de chegar ou quando os dados são atrasados, o monitoramento classifica os dados como faltando . Os dados ausentes podem impedir o fechamento de incidentes. Os atrasos nos dados que chegam de provedores de nuvem de terceiros podem chegar a 30 minutos, com atrasos de 5 a 15 minutos sendo os mais comuns. Um longo atraso - mais que a janela de teste - pode causar condições para entrar em um estado "desconhecido". Quando os dados finalmente chegam, o monitoramento pode ter perdido parte da história 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 quando os dados chegarem.
Google Cloud console
Você pode configurar como o monitoramento avalia uma condição de limiar métrico quando os dados pararem de chegar. Por exemplo, quando um incidente está aberto e uma medição esperada não chega, você deseja que o monitoramento deixe o incidente em aberto ou feche -o imediatamente? Da mesma forma, quando os dados para de chegar e nenhum incidente está aberto, você deseja que um incidente seja aberto? Por fim, quanto tempo um incidente deve permanecer aberto depois que os dados pararem de chegar?
Existem dois campos configuráveis que especificam como o monitoramento avalia as condições de limiar métrico quando os dados para de chegar:
Para configurar como o monitoramento determina o valor de reposição para os dados ausentes, use a avaliação do campo de dados ausentes que você define na etapa do acionador da condição . Este campo está desativado quando a janela de reteste é definida como nenhum reteste .
A janela de reteste é o campo chamado duração na API de monitoramento de nuvem.
Para configurar quanto tempo o monitoramento espera antes de fechar um incidente aberto após a entrada de dados, use o campo de duração da autoclose de incidentes . Você define a duração de close automático na etapa de notificação . A duração padrão de fechamento automático é de sete dias.
A seguir, descreve as diferentes opções para o campo de dados ausentes:
Google Cloud console Campo "Avaliação de dados ausentes" | Resumo | Detalhes |
---|---|---|
Dados ausentes vazios | Os 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 para de chegar. Se um incidente estiver aberto para essa condição, o incidente permanece aberto. Quando um incidente está aberto e nenhum dado chega, o cronômetro de fechamento automático começa após um atraso de pelo menos 15 minutos. Se o timer expirar, o incidente será fechado. Para condições que não são atendidas, a condição continua a não ser atendida quando os dados pararem de chegar. |
Pontos de dados ausentes tratados como valores que violam a condição de política | Os incidentes abertos permanecem abertos. Novos incidentes podem ser abertos. | Para condições atendidas, a condição continua a ser atendida quando os dados para de chegar. Se um incidente estiver aberto para essa condição, o incidente permanece aberto. Quando um incidente está aberto e nenhum dado chega para a duração de close automático mais 24 horas, o incidente está fechado. Para condições que não são atendidas, essa configuração faz com que a condição de limiar métrico se comporte como uma |
Pontos de dados ausentes tratados como valores que não violam a condição de política | Incidentes abertos estão fechados. Novos incidentes não são abertos. | Para condições que são atendidas, a condição deixa de ser atendida quando os dados para 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 pararem de chegar. |
API
Você pode configurar como o monitoramento avalia uma condição de limiar métrico quando os dados pararem de chegar. Por exemplo, quando um incidente está aberto e uma medição esperada não chega, você deseja que o monitoramento deixe o incidente em aberto ou feche -o imediatamente? Da mesma forma, quando os dados para de chegar e nenhum incidente está aberto, você deseja que um incidente seja aberto? Por fim, quanto tempo um incidente deve permanecer aberto depois que os dados pararem de chegar?
Existem dois campos configuráveis que especificam como o monitoramento avalia as condições de limiar métrico quando os dados para de chegar:
Para configurar como o monitoramento determina o valor de reposição para os dados ausentes, use o campo
evaluationMissingData
da estrutura doMetricThreshold
. Este campo é ignorado quando o campoduration
é zero.Para configurar quanto tempo o monitoramento espera antes de fechar um incidente aberto após a parada de dados, use o campo
autoClose
na estruturaAlertStrategy
.
A seguir, descreve as diferentes opções para o campo de dados ausentes:
API Campo evaluationMissingData | Resumo | Detalhes |
---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED | Os 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 para de chegar. Se um incidente estiver aberto para essa condição, o incidente permanece aberto. Quando um incidente está aberto e nenhum dado chega, o cronômetro de fechamento automático começa após um atraso de pelo menos 15 minutos. Se o timer expirar, o incidente será fechado. Para condições que não são atendidas, a condição continua a não ser atendida quando os dados pararem de chegar. |
EVALUATION_MISSING_DATA_ACTIVE | Os incidentes abertos permanecem abertos. Novos incidentes podem ser abertos. | Para condições atendidas, a condição continua a ser atendida quando os dados para de chegar. Se um incidente estiver aberto para essa condição, o incidente permanece aberto. Quando um incidente está aberto e nenhum dado chega para a duração de close automático mais 24 horas, o incidente está fechado. Para condições que não são atendidas, essa configuração faz com que a condição de limiar métrico se comporte como uma |
EVALUATION_MISSING_DATA_INACTIVE | Incidentes abertos estão fechados. Novos incidentes não são abertos. | Para condições que são atendidas, a condição deixa de ser atendida quando os dados para 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 pararem de chegar. |
Você pode minimizar os problemas devido à falta de dados fazendo qualquer um dos seguintes:
- Entre em contato com seu provedor de nuvem de terceiros para identificar maneiras de reduzir a latência de coleta métrica.
- Use janelas de reteste mais longas em suas condições. O uso de 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 mais baixo da coleção:
- Métricas de monitoramento do agente, especialmente quando o agente está sendo executado em instâncias da VM em nuvens de terceiros.
- Métricas personalizadas, quando você escreve seus dados diretamente para o monitoramento.
- Métricas baseadas em log, se a coleta de entradas de log não for adiada.
Para obter mais informações, consulte Visão geral do agente de monitoramento , visão geral das métricas definidas pelo usuário e métricas baseadas em log .
Quando o monitoramento envia notificações e cria incidentes
O monitoramento da nuvem envia uma notificação quando uma série temporal faz com que uma condição seja atendida. A notificação é enviada a todos os canais de notificação. Você não pode 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á enviada novamente para canais de notificação específicos para sua política de alerta.
Você pode receber várias notificações exclusivas relacionadas a uma política de alerta quando qualquer um dos seguintes é verdadeiro:
Uma condição está monitorando várias 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 de várias condições 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 em uma condição atendida, a política de alerta envia uma notificação e cria um incidente.
Você não pode configurar o monitoramento da nuvem 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 usando a API de monitoramento da nuvem também o notificam quando a condição é atendida e quando a condição deixa de ser atendida. Alertar as políticas criadas usando o Google Cloud O console não envia uma notificação quando a condição deixa de ser atendida, a menos que você tenha ativado esse comportamento.
Quando o monitoramento não envia notificações ou cria incidentes
Nas situações a seguir, o monitoramento não cria incidentes ou envia notificações quando as condições de uma política de alerta são atendidas:
- A política de alerta está desativada.
- A política de alerta é cochilada.
- O monitoramento atingiu o limite para o número máximo de incidentes abertos.
Políticas de alerta para desabilitar
O monitoramento não envia incidentes de criação ou envio notificações para políticas de alerta para deficientes. No entanto, o monitoramento continua a avaliar as condições de alerta de desativação.
Quando você habilita uma política de desativação, o monitoramento avalia os valores de todas as condições na janela mais recente de reteste . A janela de reteste mais recente pode incluir dados obtidos antes, durante e após a política foram ativados. As condições de uma política de desativação podem ser atendidas imediatamente após retomar a política, mesmo com grandes janelas de teste.
Por exemplo, suponha que você tenha uma política de alerta que monitore um processo específico e que você desative esta política. Na semana seguinte, o processo diminui e, como a política de alerta está desativada, você não é notificado. Se você reiniciar o processo e ativar a política de alerta imediatamente, o Monitoring reconhecerá que o processo não está pronto nos últimos cinco minutos e abre um incidente.
Os incidentes relacionados a uma política de alerta de desativação permanecem abertos até que a duração de close automática da política expire.
Políticas de alerta de cochilas
O monitoramento não envia notificações ou cria incidentes para uma política de alerta que é cochilada . Recomendamos as políticas de alerta de cochilo quando você deseja impedir que uma política de alerta envie notificações por apenas intervalos curtos. Por exemplo, antes de executar a manutenção em uma máquina virtual (VM), você pode criar uma soneca e adicionar aos critérios de soneca as políticas de alerta que monitoram a instância.
Quando você cena uma política de alerta, o monitoramento fecha todos os incidentes abertos relacionados à política. O monitoramento pode abrir novos incidentes após o expiração da soneca. Para obter informações, consulte Notificações e alertas de soneca .
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 causar a política de alerta para abrir incidentes para cada recurso. Um incidente é aberto para cada série temporal que resulta em uma condição que está sendo atendida.
Para evitar a sobrecarga do sistema, o número de incidentes que uma única política pode abrir simultaneamente é limitada a 1.000.
Por exemplo, considere uma política que se aplica a 2000 instâncias de computação do mecanismo 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 fechem.
Como resultado desse limite, um único canal de notificação pode receber até 1.000 notificações ao mesmo tempo. Se sua política de alerta possui vários canais de notificação, esse limite se aplicará a cada canal de notificação de forma independente.
Latência
A latência refere -se ao atraso entre o monitoramento da amostra de uma métrica e quando o ponto de dados métrico se torna visível como dados de séries temporais. A latência afeta quando 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 avaliação da condição de política de alerta para true. Para obter mais informações, consulte Latência dos dados métricos .
Os seguintes eventos e configurações contribuem para a latência:
Atraso na coleta métrica : o monitoramento de tempo precisa coletar valores métricos. Para Google Cloud Valores, a maioria das métricas não é visível por 60 segundos após a coleta; No entanto, o atraso depende da métrica. Os cálculos de alerta de políticas de políticas exigem um atraso adicional de até 5 minutos e 30 segundos. Para as métricas do AWS CloudWatch, o atraso da visibilidade pode levar vários minutos. Para verificações de tempo de atividade, isso pode ser uma média de dois minutos (a partir do final da janela de retest).
Janela de teste : a janela configurada para a condição. As condições são atendidas apenas quando uma condição é verdadeira em toda a janela de reteste. Por exemplo, uma configuração da janela de reteste de cinco minutos causa atrasos na notificação de pelo menos cinco minutos a partir de quando o evento ocorre pela primeira vez.
Hora da chegada da notificação : canais de notificação, como email e SMS, podem experimentar 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 sejam entregues.
O que vem a seguir
Para obter informações sobre como criar uma política de alerta, consulte os seguintes documentos:
Para uma variedade de políticas de alerta, consulte Políticas de amostra .
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 várias condições e como as políticas de alerta substituem os pontos de dados ausentes. Também descreve o número máximo de incidentes abertos para uma política, o número de notificações por incidente e o que causa atrasos na notificação.
Esse conteúdo não se aplica a políticas de alerta baseadas em log. Para obter informações sobre as políticas de alerta baseadas em log, consulte Monitorando seus logs .
Períodos de alinhamento e janelas de teste
O monitoramento da nuvem avalia o período de alinhamento e a janela de 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 monitoradas por uma política de alerta, eles devem ser regularizados para que a política de alerta tenha dados regularmente espaçados para avaliar. O processo de regularização é chamado de alinhamento .
O alinhamento envolve duas etapas:
Dividindo a série temporal em intervalos de tempo regulares, também chamados de bucketing dos dados. O intervalo é o período de alinhamento .
Computando um único valor para os pontos no período de alinhamento. Você escolhe como esse ponto único é calculado; Você pode somar todos os valores ou calcular sua média ou usar o máximo. A função que combina os pontos de dados é chamada de alinhador . O resultado da combinação é o valor chamado alinhado .
Para obter mais informações sobre o alinhamento, consulte Alinhamento: regularização na série .
Por exemplo, quando o período de alinhamento é de cinco minutos, às 13:00, o período de alinhamento contém as amostras recebidas entre 12:55 e 13:00. Às 13:01, o período de alinhamento desliza um minuto e contém as amostras recebidas entre 12:56 e 13:01.
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 rolante : especifica o intervalo de tempo para avaliar.
- Função da janela rolante : especifica a função matemática a ser executada na janela dos pontos de dados.
Para obter mais informações sobre as funções disponíveis, consulte Aligner
na referência da API. Alguns dos alinhadores funcionam alinham os dados e os convertem de um tipo ou tipo de métrica para outro. Para uma explicação detalhada, consulte Tipos, tipos e conversões .
API
MetricThreshold
configura MetricAbsence
período de alinhamento definindo as aggregations.alignmentPeriod
aggregations.perSeriesAligner
Para obter mais informações sobre as funções disponíveis, consulte Aligner
na referência da API. Alguns dos alinhadores funcionam alinham os dados e os convertem de um tipo ou 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 limiar métrico que esteja monitorando uma métrica com um período de amostragem de um minuto. Suponha que o período de alinhamento seja definido como cinco minutos e que o alinhador esteja definido para sum
. Além disso, suponha que a condição seja atendida quando o valor alinhado da série temporal é 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 reteste, descrita na próxima seção, é de três minutos. A figura a seguir ilustra várias avaliações seqüenciais da condição:
Cada linha da 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; Pontos mais antigos são pretos. Cada linha exibe o valor alinhado e se esse valor é maior que o limite de dois. Para o start
da linha, o valor alinhado se calcula a um, que é menor que o limite. Na próxima avaliação, a soma das amostras no período de alinhamento é duas. Na terceira avaliação, a soma é três e, como esse valor é maior que o limite, um cronômetro para a janela de reteste é iniciado.
Janelas de teste novamente
A condição de uma política de alerta possui uma janela de 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 reteste de uma condição seja definida como 15 minutos. A seguir, descreve o comportamento da condição com base em seu tipo:
- As condições de limiar métrico são atendidas quando, para uma única série temporal, toda medição alinhada em um intervalo de 15 minutos viola o limiar.
- As condições de ausência 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 prevêem 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 as notificações são enviadas quando a condição é atendida. Esses incidentes permanecem abertos enquanto a condição continua a ser atendida.
Google Cloud console
Você configura a janela de reteste usando o campo Janela de reteste na etapa de gatilho de alerta de configuração .
API
Você configura a janela de reteste, 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 momento em que start + 2 minutes
, o valor alinhado é maior que o limite; No entanto, a condição não é atendida porque a janela de reteste é definida como três minutos. A figura a seguir ilustra os resultados para as próximas avaliações da condição:
Embora o valor alinhado seja maior que o limite no tempo start + 2 minutes
, a condição não é 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 cada vez que uma medição ou previsão não satisfaz a condição. Este comportamento é ilustrado no exemplo a seguir:
Exemplo : esta política de alerta contém uma condição de limiar métrico que especifica uma janela de reteste de cinco minutos.
Se a latência da resposta http for superior a dois segundos,
E se a latência for maior que o limite por cinco minutos,
Em seguida, abra um incidente e envie um e -mail para sua equipe de suporte.A sequência a seguir ilustra como a janela de reteste afeta a avaliação da condição:
- A latência HTTP é inferior a dois segundos.
- Nos três minutos seguintes, a latência do HTTP é superior a dois segundos.
- Na próxima medição, a latência é inferior a dois segundos; portanto, a condição redefine a janela de reteste.
Nos próximos cinco minutos consecutivos, a latência do HTTP é superior a dois segundos; portanto, a condição é 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 reteste para ser longa o suficiente para minimizar os falsos positivos, mas curto 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 métrico é o período de amostragem desse tipo métrico. Por exemplo, se o tipo métrico for amostrado a cada 300 segundos, o período de alinhamento deve ser de pelo menos 300 segundos. No entanto, se você deseja 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 é 24 horas menos o atraso de ingestão do tipo métrico. Por exemplo, se o atraso de ingestão para uma métrica for de 6 horas, o valor máximo do período de alinhamento for de 18 horas.
Use a janela Restest para especificar a capacidade de resposta do alerta. Por exemplo, se você definir a janela de reteste para 20 minutos para uma condição de ausência métrica , não deve haver dados por 20 minutos antes que a condição seja atendida. Para uma política de alerta mais responsiva, defina a janela de teste como um valor menor. Para condições de limiar métrico, para ter a política de alerta mais responsiva, defina a janela de reteste para 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 em uma frequência fixa. As escolhas que você faz para o período de alinhamento e a janela de reteste não determinam com que frequência a condição é avaliada.
Políticas com várias condições
Uma política de alerta pode conter até 6 condições.
Se você estiver usando a API de monitoramento da nuvem ou se sua política de alerta tiver várias condições, você deverá especificar quando um incidente será aberto. Para configurar como várias condições são combinadas, faça um dos seguintes:
Google Cloud console
Você configura as opções de combinador na etapa de gatilho de várias condições .
API
Você configura as opções de 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 da nuvem e uma descrição de cada configuração:
Google Cloud console A política desencadeia valor | API de monitoramento em nuvem Valor do combinador | Significado |
---|---|---|
Qualquer condição é atendida | OR | Um incidente é aberto se algum recurso fizer com que alguma das condições seja atendida. |
Todas as condições são atendidas mesmo para diferente Recursos para cada condição (padrão) | AND | Um incidente é 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 incidente é aberto para cada condição que é atendida quando todas as condições são atendidas, apenas se o mesmo recurso fizer com que cada condição seja atendida. Essa configuração é a escolha de combinação mais rigorosa. |
In this context, the term met means that the condition's configuration evaluates to true . For example, if the configuration is Any time series is greater than 10 for 5 minutes
, then when this statement evaluates to true , the condition is met.
Exemplo
Considere um Google Cloud project that contains two VM instances, vm1 and vm2. Also, assume that you create an alerting policy with 2 conditions:
- The condition named
CPU usage is too high
monitors the CPU usage of the instances. This condition is met when the CPU usage of any instance is greater than 100ms/s for 1 minute. - The condition named
Excessive utilization
monitors the CPU utilization of the instances. This condition is met when the CPU utilization of any instance is greater than 60% for 1 minute.
Initially, assume that both conditions evaluate to false .
Next, assume that the CPU usage of vm1 exceeds 100ms/s for 1 minute. Because the CPU usage is greater than the threshold for one minute, the condition CPU usage is too high
is met. If the conditions are combined with Any condition is met , then an incident is created because a condition is met. If the conditions are combined with All conditions are met or All conditions are met even for different resources for each condition , then an incident isn't created. These combiner choices require that both conditions be met.
Next, assume that the CPU usage of vm1 remains greater than 100ms/s and that the CPU utilization of vm2 exceeds 60% for 1 minute. The result is that both conditions are met. The following describes what occurs based on how the conditions are combined:
Any condition is met : An incident is created when a resource causes a condition to be met. In this example, vm2 causes the condition
Excessive utilization
to be met.If vm2 causes the condition
CPU usage is too high
to be met, then that also results in an incident being created. An incident is created because vm1 and vm2 causing the conditionCPU usage is too high
to be met are distinct events.All conditions are met even for different resources for each condition : An incident is created because both conditions are met.
All conditions are met : An incident isn't created because this combiner requires that the same resource cause all conditions to be met. In this example, no incident is created because vm1 causes
CPU usage is too high
to be met while vm2 causesExcessive utilization
to be met.
Partial metric data
When time series data stops arriving or when data is delayed, Monitoring classifies the data as missing . Missing data can prevent incidents from closing. Delays in data arriving from third-party cloud providers can be as high as 30 minutes, with 5-15 minute delays being the most common. A lengthy delay—longer than the retest window—can cause conditions to enter an "unknown" state. When the data finally arrives, Monitoring might have lost some of the recent history of the conditions. Later inspection of the time-series data might not reveal this problem because there is no evidence of delays once the data arrives.
Google Cloud console
You can configure how Monitoring evaluates a metric-threshold condition when data stops arriving. For example, when an incident is open and an expected measurement doesn't arrive, do you want Monitoring to leave the incident open or to close it immediately? Similarly, when data stops arriving and no incident is open, do you want an incident to be opened? Lastly, how long should an incident stay open after data stops arriving?
There are two configurable fields that specify how Monitoring evaluates metric-threshold conditions when data stops arriving:
To configure how Monitoring determines the replacement value for missing data, use the Evaluation of missing data field which you set in the Condition trigger step. This field is disabled when the retest window is set to No retest .
The retest window is the field called duration in the Cloud Monitoring API.
To configure how long Monitoring waits before closing an open incident after data stops arriving, use the Incident autoclose duration field. You set the auto-close duration in the Notification step. The default auto-close duration is seven days.
The following describes the different options for the missing data field:
Google Cloud console "Evaluation of missing data" field | Resumo | Detalhes |
---|---|---|
Missing data empty | Open incidents stay open. New incidents aren't opened. | For conditions that are met, the condition continues to be met when data stops arriving. If an incident is open for this condition, then the incident stays open. When an incident is open and no data arrives, the auto-close timer starts after a delay of at least 15 minutes. If the timer expires, then the incident is closed. For conditions that aren't met, the condition continues to not be met when data stops arriving. |
Missing data points treated as values that violate the policy condition | Open incidents stay open. New incidents can be opened. | For conditions that are met, the condition continues to be met when data stops arriving. If an incident is open for this condition, then the incident stays open. When an incident is open and no data arrives for the auto-close duration plus 24 hours, the incident is closed. For conditions that aren't met, this setting causes the metric-threshold condition to behave like a |
Missing data points treated as values that don't violate the policy condition | Open incidents are closed. New incidents aren't opened. | For conditions that are met, the condition stops being met when data stops arriving. If an incident is open for this condition, then the incident is closed. For conditions that aren't met, the condition continues to not be met when data stops arriving. |
API
You can configure how Monitoring evaluates a metric-threshold condition when data stops arriving. For example, when an incident is open and an expected measurement doesn't arrive, do you want Monitoring to leave the incident open or to close it immediately? Similarly, when data stops arriving and no incident is open, do you want an incident to be opened? Lastly, how long should an incident stay open after data stops arriving?
There are two configurable fields that specify how Monitoring evaluates metric-threshold conditions when data stops arriving:
To configure how Monitoring determines the replacement value for missing data, use the
evaluationMissingData
field of theMetricThreshold
structure. This field is ignored when theduration
field is zero.To configure how long Monitoring waits before closing an open incident after data stops arriving, use the
autoClose
field in theAlertStrategy
structure.
The following describes the different options for the missing data field:
APIevaluationMissingData field | Resumo | Detalhes |
---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED | Open incidents stay open. New incidents aren't opened. | For conditions that are met, the condition continues to be met when data stops arriving. If an incident is open for this condition, then the incident stays open. When an incident is open and no data arrives, the auto-close timer starts after a delay of at least 15 minutes. If the timer expires, then the incident is closed. For conditions that aren't met, the condition continues to not be met when data stops arriving. |
EVALUATION_MISSING_DATA_ACTIVE | Open incidents stay open. New incidents can be opened. | For conditions that are met, the condition continues to be met when data stops arriving. If an incident is open for this condition, then the incident stays open. When an incident is open and no data arrives for the auto-close duration plus 24 hours, the incident is closed. For conditions that aren't met, this setting causes the metric-threshold condition to behave like a |
EVALUATION_MISSING_DATA_INACTIVE | Open incidents are closed. New incidents aren't opened. | For conditions that are met, the condition stops being met when data stops arriving. If an incident is open for this condition, then the incident is closed. For conditions that aren't met, the condition continues to not be met when data stops arriving. |
You can minimize problems due to missing data by doing any of the following:
- Contact your third-party cloud provider to identify ways to reduce metric collection latency.
- Use longer retest windows in your conditions. Using a longer retest window window has the disadvantage of making your alerting policies less responsive.
Choose metrics that have a lower collection delay:
- Monitoring agent metrics, especially when the agent is running on VM instances in third-party clouds.
- Custom metrics, when you write their data directly to Monitoring.
- Log-based metrics, if collection of log entries isn't delayed.
For more information, see Monitoring agent overview , User-defined metrics overview , and log-based metrics .
When Monitoring sends notifications and creates incidents
Cloud Monitoring sends a notification when a time series causes a condition to be met. The notification is sent to all notification channels. You can't restrict a notification to a specific channel or to a subset of your policy's channels.
If you configure repeated notifications , then the same notification is re-sent to specific notification channels for your alerting policy.
You might receive multiple unique notifications related to one alerting policy when any of the following are true:
A condition is monitoring multiple time series.
A policy contains multiple conditions. In this case, the notifications you receive depend on the value of the alerting policy's multi-condition trigger:
All conditions are met : When all conditions are met, for each time series that results in a condition being met, the alerting policy sends a notification and creates an incident.
You can't configure Cloud Monitoring to create only one incident and send only one notification when the alerting policy contains multiple conditions.
Any condition is met : The alerting policy sends a notification when a time series causes the condition to be met.
For more information, see Policies with multiple conditions .
Alerting policies created by using the Cloud Monitoring API also notify you when the condition is met and when the condition stops being met. Alerting policies created by using the Google Cloud console don't send a notification when the condition stops being met unless you've enabled that behavior.
When Monitoring doesn't send notifications or create incidents
In the following situations, Monitoring doesn't create incidents or send notifications when the conditions of an alerting policy are met:
- The alerting policy is disabled.
- The alerting policy is snoozed.
- Monitoring has reached the limit for the maximum number of open incidents.
Disabled alerting policies
Monitoring doesn't send create incidents or send notifications for disabled alerting policies. However, Monitoring continues to evaluate a disabled alerting policy's conditions.
When you enable a disabled policy, Monitoring evaluates the values of all conditions over the most recent retest window . The most recent retest window might include data taken before, during, and after the policy was enabled. The conditions of a disabled policy can be met immediately after resuming the policy, even with large retest windows.
For example, suppose you have an alerting policy that monitors a specific process and that you disable this policy. The following week, the process goes down, and because the alerting policy is disabled you aren't notified. If you restart the process and enable the alerting policy immediately, then Monitoring recognizes that the process hasn't been up for the last five minutes and opens an incident.
The incidents related to a disabled alerting policy remain open until the policy's auto-close duration expires.
Snoozed alerting policies
Monitoring doesn't send notifications or create incidents for an alerting policy that is snoozed . We recommend snoozing alerting policies when you want to prevent an alerting policy from sending notifications for only short intervals. For example, before you perform maintenance on a virtual machine (VM), you might create a snooze and add to the snooze criteria the alerting policies that monitor the instance.
When you snooze an alerting policy, Monitoring closes all open incidents related to the policy. Monitoring can open new incidents after the snooze expires. For information, see Snooze notifications and alerts .
Limits of notifications and open incidents
An alerting policy can apply to many resources, and a problem affecting all resources can cause the alerting policy to open incidents for each resource. An incident is opened for each time series that results in a condition being met.
To prevent overloading the system, the number of incidents that a single policy can open simultaneously is limited to 1,000.
For example, consider a policy that applies to 2000 Compute Engine instances, and each instance causes the alerting conditions to be met. Monitoring limits the number of open incidents to 1,000. Any remaining conditions that are met are ignored until some of the open incidents for that policy close.
As a result of this limit, a single notification channel can receive up to 1,000 notifications at one time. If your alerting policy has multiple notification channels, then this limit applies to each notification channel independently.
Latência
Latency refers to the delay between when Monitoring samples a metric and when the metric data point becomes visible as time series data. The latency affects when notifications are sent. For example, if a monitored metric has a latency of up to 180 seconds, then Monitoring won't create an incident for up to 180 seconds after the alerting policy condition evaluates to true. For more information, see Latency of metric data .
The following events and settings contribute to the latency:
Google Cloud values, most metrics aren't visible for 60 seconds after collection; however, the delay is dependent upon the metric. Alerting policy computations take an additional delay of up to 5 minutes and 30 seconds. For AWS CloudWatch metrics, the visibility delay can be several minutes. For uptime checks, this can be an average of two minutes (from the end of the retest window).
Retest window : The window configured for the condition. Conditions are only met when a condition is true throughout the retest window. For example, a retest window setting of five minutes causes delays in the notification of at least five minutes from when the event first occurs.
Time for notification to arrive : Notification channels, such as email and SMS, may experience network or other latencies (unrelated to what's being delivered), sometimes approaching minutes. On some channels—such as SMS and Slack—there is no guarantee that the messages are delivered.
O que vem a seguir
For information about how to create an alerting policy, see the following documents:
For an assortment of alerting policies, see Sample policies .
This document describes how alignment periods and retest windows determine when a condition is met, how alerting policies combine multiple conditions, and how alerting policies replace missing data points. It also describes the maximum number of open incidents for a policy, the number of notifications per incident, and what causes notification delays.
This content does not apply to log-based alerting policies. For information about log-based alerting policies, see Monitoring your logs .
Alignment periods and retest windows
Cloud Monitoring evaluates the alignment period and retest window when determining whether the condition of an alerting policy has been met.
Alignment period
Before time-series data is monitored by an alerting policy, it must be regularized so that the alerting policy has regularly spaced data to evaluate. The regularization process is called alignment .
Alignment involves two steps:
Dividing the time series into regular time intervals, also called bucketing the data. The interval is the alignment period .
Computing a single value for the points in the alignment period. You choose how that single point is computed; you might sum all the values, or compute their average, or use the maximum. The function that combines the data points is called the aligner . The result of the combination is the called the aligned value .
For more information about alignment, see Alignment: within-series regularization .
For example, when the alignment period is five minutes, at 1:00 PM, the alignment period contains the samples received between 12:55 PM and 1:00 PM. At 1:01 PM, the alignment period slides one minute and contains the samples received between 12:56 PM and 1:01 PM.
Monitoring configures an alignment period as follows:
Google Cloud console
You configure the alignment period by choosing a value for the following fields on the Alert conditions page:
- Rolling window : Specifies the range of time to evaluate.
- Rolling window function : Specifies the mathematical function to perform on the window of data points.
For more information about available functions, see Aligner
in the API reference. Some of the aligner functions both align the data and convert it from one metric kind or type to another. For a detailed explanation, see Kinds, types, and conversions .
API
You configure the alignment period by setting the aggregations.alignmentPeriod
and aggregations.perSeriesAligner
fields in the MetricThreshold
and MetricAbsence
structures.
For more information about available functions, see Aligner
in the API reference. Some of the aligner functions both align the data and convert it from one metric kind or type to another. For a detailed explanation, see Kinds, types, and conversions .
To illustrate the effect of the alignment period on a condition in an alerting policy, consider a metric-threshold condition that is monitoring a metric with a sampling period of one minute. Assume that the alignment period is set to five minutes and that the aligner is set to sum
. Also, assume that the condition is met when the aligned value of the time series is greater than two for at least three minutes, and that the condition is evaluated every minute. In this example, the alignment period is two minutes, and the retest window, which is described in the next section, is three minutes. The following figure illustrates several sequential evaluations of the condition:
Each row in the figure illustrates a single evaluation of the condition. The time series data is shown. The points in the alignment period are shown with blue dots; older dots are black. Each row displays the aligned value and whether this value is greater than the threshold of two. For the row labeled start
, the aligned value computes to one, which is less than the threshold. At the next evaluation, the sum of the samples in the alignment period is two. On the third evaluation, the sum is three, and because this value is greater than the threshold, a timer for the retest window is started.
Retest windows
The condition of an alerting policy has a retest window , which prevents the condition from being met due to a single measurement or forecast. For example, assume that the retest window of a condition is set to 15 minutes. The following describes the behavior of the condition based on its type:
- Metric-threshold conditions are met when, for a single time series, every aligned measurement in a 15-minute interval violates the threshold.
- Metric-absence conditions are met when no data arrives for a time series in a 15-minute interval.
- Forecast conditions are met when every forecast produced during a 15-minute window predicts that the time series will violate the threshold within the forecast window.
For policies with one condition, an incident is opened and notifications are sent when the condition is met. These incidents stay open while the the condition continues to be met.
Google Cloud console
You configure the retest window by using the Retest window field in the Configure alert trigger step.
API
You configure the retest window by setting the field called duration
in the MetricThreshold
and MetricAbsence
structures.
The previous figure illustrated three evaluations of a metric-threshold condition. At the time start + 2 minutes
, the aligned value is greater than the threshold; however, the condition isn't met because the retest window is set to three minutes. The following figure illustrates the results for the next evaluations of the condition:
Even though the aligned value is greater than the threshold at time start + 2 minutes
, the condition isn't met until the aligned value is greater than the threshold for three minutes. That event occurs at time start + 5 minutes
.
A condition resets its retest window each time a measurement or forecast doesn't satisfy the condition. This behavior is illustrated in the following example:
Example : This alerting policy contains one metric-threshold condition that specifies a five-minute retest window.
If HTTP response latency is greater than two seconds,
and if the latency is greater than the threshold for five minutes,
then open an incident and email your support team.The following sequence illustrates how the retest window affects the evaluation of the condition:
- The HTTP latency is less than two seconds.
- For the next three consecutive minutes, HTTP latency is greater than two seconds.
- In the next measurement, the latency is less than two seconds, so the condition resets the retest window.
For the next five consecutive minutes, HTTP latency is greater than two seconds, so the condition is met.
Because the alerting policy has one condition, Monitoring sends notifications when the condition is met.
Set the retest window to be long enough to minimize false positives, but short enough to ensure that incidents are opened in a timely manner.
Best practices for setting the alignment period and retest window
The alignment period determines how many samples are combined with the aligner:
The minimum value of the alignment period for a metric type is the sampling period of that metric type. For example, if the metric type is sampled every 300 seconds, then the alignment period should be at least 300 seconds. However, if you want to combine 5 samples, then set the alignment period to 5 * 300 sec or 1500 seconds.
The maximum value of the alignment period is 24 hours less the ingestion delay of the metric type. For example, if the ingestion delay for a metric is 6 hours, then the maximum value of the alignment period is 18 hours.
Use the retest window to specify the responsiveness of the alert. For example, if you set the retest window to 20 minutes for a metric-absence condition , then there must be no data for 20 minutes before the condition is met. For a more responsive alerting policy, set the retest window to a smaller value. For metric-threshold conditions, to have the most responsive alerting policy, set the retest window to zero. A single aligned value causes these types of conditions to be met.
Alerting policy conditions are evaluated at a fixed frequency. The choices that you make for the alignment period and the retest window don't determine how often the condition is evaluated.
Policies with multiple conditions
An alerting policy can contain up to 6 conditions.
If you are using the Cloud Monitoring API or if your alerting policy has multiple conditions, then you must specify when an incident is opened. To configure how multiple conditions are combined, do one of the following:
Google Cloud console
You configure combiner options in the Multi-condition trigger step.
API
You configure combiner options with the combiner
field of the AlertPolicy
structure.
This table lists the settings in the Google Cloud console, the equivalent value in the Cloud Monitoring API, and a description of each setting:
Google Cloud console Policy triggers value | API de monitoramento em nuvem combiner value | Significado |
---|---|---|
Any condition is met | OR | An incident is opened if any resource causes any of the conditions to be met. |
All conditions are met even for different resources for each condition (padrão) | AND | An incident is opened for each condition that is met when all conditions are met, even if a different resource causes those conditions to be met. |
All conditions are met | AND_WITH_MATCHING_RESOURCE | An incident is opened for each condition that is met when all conditions are met, only if the same resource causes each condition to be met. This setting is the most stringent combining choice. |
In this context, the term met means that the condition's configuration evaluates to true . For example, if the configuration is Any time series is greater than 10 for 5 minutes
, then when this statement evaluates to true , the condition is met.
Exemplo
Considere um Google Cloud project that contains two VM instances, vm1 and vm2. Also, assume that you create an alerting policy with 2 conditions:
- The condition named
CPU usage is too high
monitors the CPU usage of the instances. This condition is met when the CPU usage of any instance is greater than 100ms/s for 1 minute. - The condition named
Excessive utilization
monitors the CPU utilization of the instances. This condition is met when the CPU utilization of any instance is greater than 60% for 1 minute.
Initially, assume that both conditions evaluate to false .
Next, assume that the CPU usage of vm1 exceeds 100ms/s for 1 minute. Because the CPU usage is greater than the threshold for one minute, the condition CPU usage is too high
is met. If the conditions are combined with Any condition is met , then an incident is created because a condition is met. If the conditions are combined with All conditions are met or All conditions are met even for different resources for each condition , then an incident isn't created. These combiner choices require that both conditions be met.
Next, assume that the CPU usage of vm1 remains greater than 100ms/s and that the CPU utilization of vm2 exceeds 60% for 1 minute. The result is that both conditions are met. The following describes what occurs based on how the conditions are combined:
Any condition is met : An incident is created when a resource causes a condition to be met. In this example, vm2 causes the condition
Excessive utilization
to be met.If vm2 causes the condition
CPU usage is too high
to be met, then that also results in an incident being created. An incident is created because vm1 and vm2 causing the conditionCPU usage is too high
to be met are distinct events.All conditions are met even for different resources for each condition : An incident is created because both conditions are met.
All conditions are met : An incident isn't created because this combiner requires that the same resource cause all conditions to be met. In this example, no incident is created because vm1 causes
CPU usage is too high
to be met while vm2 causesExcessive utilization
to be met.
Partial metric data
When time series data stops arriving or when data is delayed, Monitoring classifies the data as missing . Missing data can prevent incidents from closing. Delays in data arriving from third-party cloud providers can be as high as 30 minutes, with 5-15 minute delays being the most common. A lengthy delay—longer than the retest window—can cause conditions to enter an "unknown" state. When the data finally arrives, Monitoring might have lost some of the recent history of the conditions. Later inspection of the time-series data might not reveal this problem because there is no evidence of delays once the data arrives.
Google Cloud console
You can configure how Monitoring evaluates a metric-threshold condition when data stops arriving. For example, when an incident is open and an expected measurement doesn't arrive, do you want Monitoring to leave the incident open or to close it immediately? Similarly, when data stops arriving and no incident is open, do you want an incident to be opened? Lastly, how long should an incident stay open after data stops arriving?
There are two configurable fields that specify how Monitoring evaluates metric-threshold conditions when data stops arriving:
To configure how Monitoring determines the replacement value for missing data, use the Evaluation of missing data field which you set in the Condition trigger step. This field is disabled when the retest window is set to No retest .
The retest window is the field called duration in the Cloud Monitoring API.
To configure how long Monitoring waits before closing an open incident after data stops arriving, use the Incident autoclose duration field. You set the auto-close duration in the Notification step. The default auto-close duration is seven days.
The following describes the different options for the missing data field:
Google Cloud console "Evaluation of missing data" field | Resumo | Detalhes |
---|---|---|
Missing data empty | Open incidents stay open. New incidents aren't opened. | For conditions that are met, the condition continues to be met when data stops arriving. If an incident is open for this condition, then the incident stays open. When an incident is open and no data arrives, the auto-close timer starts after a delay of at least 15 minutes. If the timer expires, then the incident is closed. For conditions that aren't met, the condition continues to not be met when data stops arriving. |
Missing data points treated as values that violate the policy condition | Open incidents stay open. New incidents can be opened. | For conditions that are met, the condition continues to be met when data stops arriving. If an incident is open for this condition, then the incident stays open. When an incident is open and no data arrives for the auto-close duration plus 24 hours, the incident is closed. For conditions that aren't met, this setting causes the metric-threshold condition to behave like a |
Missing data points treated as values that don't violate the policy condition | Open incidents are closed. New incidents aren't opened. | For conditions that are met, the condition stops being met when data stops arriving. If an incident is open for this condition, then the incident is closed. For conditions that aren't met, the condition continues to not be met when data stops arriving. |
API
You can configure how Monitoring evaluates a metric-threshold condition when data stops arriving. For example, when an incident is open and an expected measurement doesn't arrive, do you want Monitoring to leave the incident open or to close it immediately? Similarly, when data stops arriving and no incident is open, do you want an incident to be opened? Lastly, how long should an incident stay open after data stops arriving?
There are two configurable fields that specify how Monitoring evaluates metric-threshold conditions when data stops arriving:
To configure how Monitoring determines the replacement value for missing data, use the
evaluationMissingData
field of theMetricThreshold
structure. This field is ignored when theduration
field is zero.To configure how long Monitoring waits before closing an open incident after data stops arriving, use the
autoClose
field in theAlertStrategy
structure.
The following describes the different options for the missing data field:
APIevaluationMissingData field | Resumo | Detalhes |
---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED | Open incidents stay open. New incidents aren't opened. | For conditions that are met, the condition continues to be met when data stops arriving. If an incident is open for this condition, then the incident stays open. When an incident is open and no data arrives, the auto-close timer starts after a delay of at least 15 minutes. If the timer expires, then the incident is closed. For conditions that aren't met, the condition continues to not be met when data stops arriving. |
EVALUATION_MISSING_DATA_ACTIVE | Open incidents stay open. New incidents can be opened. | For conditions that are met, the condition continues to be met when data stops arriving. If an incident is open for this condition, then the incident stays open. When an incident is open and no data arrives for the auto-close duration plus 24 hours, the incident is closed. For conditions that aren't met, this setting causes the metric-threshold condition to behave like a |
EVALUATION_MISSING_DATA_INACTIVE | Open incidents are closed. New incidents aren't opened. | For conditions that are met, the condition stops being met when data stops arriving. If an incident is open for this condition, then the incident is closed. For conditions that aren't met, the condition continues to not be met when data stops arriving. |
You can minimize problems due to missing data by doing any of the following:
- Contact your third-party cloud provider to identify ways to reduce metric collection latency.
- Use longer retest windows in your conditions. Using a longer retest window window has the disadvantage of making your alerting policies less responsive.
Choose metrics that have a lower collection delay:
- Monitoring agent metrics, especially when the agent is running on VM instances in third-party clouds.
- Custom metrics, when you write their data directly to Monitoring.
- Log-based metrics, if collection of log entries isn't delayed.
For more information, see Monitoring agent overview , User-defined metrics overview , and log-based metrics .
When Monitoring sends notifications and creates incidents
Cloud Monitoring sends a notification when a time series causes a condition to be met. The notification is sent to all notification channels. You can't restrict a notification to a specific channel or to a subset of your policy's channels.
If you configure repeated notifications , then the same notification is re-sent to specific notification channels for your alerting policy.
You might receive multiple unique notifications related to one alerting policy when any of the following are true:
A condition is monitoring multiple time series.
A policy contains multiple conditions. In this case, the notifications you receive depend on the value of the alerting policy's multi-condition trigger:
All conditions are met : When all conditions are met, for each time series that results in a condition being met, the alerting policy sends a notification and creates an incident.
You can't configure Cloud Monitoring to create only one incident and send only one notification when the alerting policy contains multiple conditions.
Any condition is met : The alerting policy sends a notification when a time series causes the condition to be met.
For more information, see Policies with multiple conditions .
Alerting policies created by using the Cloud Monitoring API also notify you when the condition is met and when the condition stops being met. Alerting policies created by using the Google Cloud console don't send a notification when the condition stops being met unless you've enabled that behavior.
When Monitoring doesn't send notifications or create incidents
In the following situations, Monitoring doesn't create incidents or send notifications when the conditions of an alerting policy are met:
- The alerting policy is disabled.
- The alerting policy is snoozed.
- Monitoring has reached the limit for the maximum number of open incidents.
Disabled alerting policies
Monitoring doesn't send create incidents or send notifications for disabled alerting policies. However, Monitoring continues to evaluate a disabled alerting policy's conditions.
When you enable a disabled policy, Monitoring evaluates the values of all conditions over the most recent retest window . The most recent retest window might include data taken before, during, and after the policy was enabled. The conditions of a disabled policy can be met immediately after resuming the policy, even with large retest windows.
For example, suppose you have an alerting policy that monitors a specific process and that you disable this policy. The following week, the process goes down, and because the alerting policy is disabled you aren't notified. If you restart the process and enable the alerting policy immediately, then Monitoring recognizes that the process hasn't been up for the last five minutes and opens an incident.
The incidents related to a disabled alerting policy remain open until the policy's auto-close duration expires.
Snoozed alerting policies
Monitoring doesn't send notifications or create incidents for an alerting policy that is snoozed . We recommend snoozing alerting policies when you want to prevent an alerting policy from sending notifications for only short intervals. For example, before you perform maintenance on a virtual machine (VM), you might create a snooze and add to the snooze criteria the alerting policies that monitor the instance.
When you snooze an alerting policy, Monitoring closes all open incidents related to the policy. Monitoring can open new incidents after the snooze expires. For information, see Snooze notifications and alerts .
Limits of notifications and open incidents
An alerting policy can apply to many resources, and a problem affecting all resources can cause the alerting policy to open incidents for each resource. An incident is opened for each time series that results in a condition being met.
To prevent overloading the system, the number of incidents that a single policy can open simultaneously is limited to 1,000.
For example, consider a policy that applies to 2000 Compute Engine instances, and each instance causes the alerting conditions to be met. Monitoring limits the number of open incidents to 1,000. Any remaining conditions that are met are ignored until some of the open incidents for that policy close.
As a result of this limit, a single notification channel can receive up to 1,000 notifications at one time. If your alerting policy has multiple notification channels, then this limit applies to each notification channel independently.
Latência
Latency refers to the delay between when Monitoring samples a metric and when the metric data point becomes visible as time series data. The latency affects when notifications are sent. For example, if a monitored metric has a latency of up to 180 seconds, then Monitoring won't create an incident for up to 180 seconds after the alerting policy condition evaluates to true. For more information, see Latency of metric data .
The following events and settings contribute to the latency:
Google Cloud values, most metrics aren't visible for 60 seconds after collection; however, the delay is dependent upon the metric. Alerting policy computations take an additional delay of up to 5 minutes and 30 seconds. For AWS CloudWatch metrics, the visibility delay can be several minutes. For uptime checks, this can be an average of two minutes (from the end of the retest window).
Retest window : The window configured for the condition. Conditions are only met when a condition is true throughout the retest window. For example, a retest window setting of five minutes causes delays in the notification of at least five minutes from when the event first occurs.
Time for notification to arrive : Notification channels, such as email and SMS, may experience network or other latencies (unrelated to what's being delivered), sometimes approaching minutes. On some channels—such as SMS and Slack—there is no guarantee that the messages are delivered.
O que vem a seguir
For information about how to create an alerting policy, see the following documents:
For an assortment of alerting policies, see Sample policies .