Neste documento, descrevemos como os períodos de alinhamento e as janelas de novo teste determinam quando uma condição é atendida, como as políticas de alertas combinam várias condições e como as políticas de alertas substituem os pontos de dados ausentes. Ele 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 alertas baseadas em registros. Para informações sobre políticas de alertas com base em registros, consulte Como monitorar seus registros.
Períodos de alinhamento e novas janelas de teste
O Cloud Monitoring avalia o período de alinhamento e a janela de novo teste ao determinar se a condição de uma política de alertas foi atendida.
Período de alinhamento
Antes que os dados de séries temporais sejam monitorados por uma política de alertas, eles precisam ser regularizados para que a política de alertas tenha regularmente os dados espaçados para avaliação. O processo de regularização é chamado de alignment.
O alinhamento envolve duas etapas:
Dividir a série temporal em intervalos de tempo regulares, também chamado de agrupamento de dados por classes. O intervalo é o período de alinhamento.
Calcular 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 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 inclui as amostras recebidas entre 12h55 e 13h. Às 13h01, o período de alinhamento desliza um minuto e contém as amostras recebidas entre 12h56 e 13h01.
O Monitoring configura um período de alinhamento da seguinte maneira:
Console do Google Cloud
Configure 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 contínua: especifica a função matemática a ser executada na janela de pontos de dados.
Para mais informações sobre as funções disponíveis, consulte Aligner na Referência da API. Algumas das funções de alinhamento 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
Para configurar o período de alinhamento, defina os campos aggregations.alignmentPeriod e aggregations.perSeriesAligner nas estruturas MetricThreshold e MetricAbsence.
Para mais informações sobre as funções disponíveis, consulte Aligner na Referência da API. Algumas das funções de alinhamento 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 alertas, considere uma condição de limite de métrica que esteja monitorando uma métrica com um período de amostragem de um minuto. Suponha que o período de alinhamento esteja definido como cinco minutos e que
o alinhador esteja definido como sum. Além disso, suponha que a condição seja atendida quando o valor alinhado da série temporal for maior que dois por pelo menos três minutos e que a condição é avaliada a cada minuto.
Neste exemplo, o período de alinhamento é de dois minutos e a janela de novo teste,
que é descrita na próxima seção, tem 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 das séries temporais são exibidos. Os pontos no período de alinhamento são mostrados
com pontos azuis, e 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 é calculado como 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 timer para a janela de novo teste é iniciado.
Testar janelas novamente
A condição de uma política de alertas tem uma janela de novo teste, que impede que a condição seja atendida devido a uma única medição ou previsão. Por exemplo, suponha que a janela de novo teste de uma condição esteja definida como 15 minutos. Veja a seguir o comportamento da condição com base no tipo:
- As condições de limite de métrica são atendidas quando, para uma única série temporal, todas as medições alinhadas em um intervalo de 15 minutos violam o limite.
- As condições de ausência de métrica são atendidas quando nenhum dado chega para uma série temporal em um intervalo de 15 minutos.
- As condições de previsão são atendidas quando todas as previsões produzidas durante uma janela de 15 minutos prevem que a série temporal vai violar o limite dentro da janela de previsão.
No caso das 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 continua sendo atendida.
Console do Google Cloud
Para configurar a janela de novo teste, use o campo Janela de novo teste na etapa Configurar gatilho de alerta.
API
Para configurar a janela de novo teste, defina o campo chamado
duration nas estruturas MetricThreshold e
MetricAbsence.
A figura anterior ilustrou três avaliações de uma condição de limite de métrica. No
momento start + 2 minutes, o valor alinhado é maior que o limite.
No entanto, a condição não é atendida porque a janela de novo teste está definida como
três minutos. A figura a seguir ilustra os resultados das próximas avaliações da condição:
Mesmo que o valor alinhado seja maior que o limite no
momento start + 2 minutes, a condição não será atendida até que o valor alinhado
seja maior que o limite por três minutos. Esse evento ocorre no horário
start + 5 minutes.
Uma condição redefine a janela de novo teste sempre que uma medição ou previsão não satisfaz a condição. Esse comportamento é ilustrado no exemplo abaixo:
Exemplo: essa política de alertas contém uma condição de limite de métrica que especifica uma janela de novo teste de cinco minutos.
Se a latência da resposta HTTP for maior que dois segundos
e se a latência for maior que o limite por cinco minutos,
abra um incidente e envie um e-mail para a 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 HTTP for inferior a dois segundos.
- Nos próximos três minutos consecutivos, a latência HTTP é maior que dois segundos.
- Na próxima medição, a latência é inferior a dois segundos, portanto, a condição redefine a janela de novo teste.
Nos próximos cinco minutos consecutivos, a latência HTTP é maior que dois segundos, portanto, a condição é atendida.
Como a política de alertas tem uma condição, o Monitoring 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.
Práticas recomendadas para definir o período de alinhamento e a janela de novo teste
O período de alinhamento determina quantas amostras são combinadas com o alinhador:
O valor mínimo do período de alinhamento para um tipo de métrica é o período de amostragem desse tipo de métrica. Por exemplo, se a amostragem do tipo de métrica é feita a cada 300 segundos, o período de alinhamento precisa ser de pelo menos 300 segundos. No entanto, se você quiser combinar cinco amostras, defina o período de alinhamento como 5 * 300 segundos ou 1.500 segundos.
O valor máximo do período de alinhamento é 24 horas menos o atraso de processamento 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 novo teste para especificar a capacidade de resposta do alerta. Por exemplo, se você definir a janela de novo teste como 20 minutos para uma condição de ausência de métrica, não poderá haver dados por 20 minutos antes que a condição seja atendida. Para uma política de alertas mais responsiva, defina a janela de novo teste com um valor menor. Para condições de limite de métrica, para ter a política de alertas mais responsiva, defina a janela de novo teste como zero. Um único valor alinhado faz com que esses tipos de condições sejam atendidos.
As condições da política de alertas são avaliadas em uma frequência fixa. As escolhas feitas para o período de alinhamento e a janela de novo teste não determinam a frequência com que a condição é avaliada.
Políticas com várias condições
Uma política de alertas pode conter até seis condições.
Se você estiver usando a API Cloud Monitoring ou se a política de alertas tiver várias condições, especifique quando um incidente será aberto. Para configurar como várias condições são combinadas, siga um destes procedimentos:
Console do Google Cloud
Configure as opções do combinador na etapa Gatilho de várias condições.
API
As opções do combinador são configuradas com o campo combiner da
estrutura AlertPolicy.
Esta tabela lista as configurações no console do Google Cloud, o valor equivalente na API Cloud Monitoring e uma descrição de cada configuração:
| Console do Google Cloud Valor dos acionadores de política |
Valor do combinador da API Cloud Monitoring |
Significado |
|---|---|---|
| Qualquer condição é atendida | OR |
Um incidente será aberto se algum recurso fizer com que qualquer uma das condições seja atendida. |
| Todas as condições são atendidas mesmo para recursos diferentes para cada condição (padrão) |
AND |
Um incidente será aberto se cada condição for atendida, mesmo que um recurso diferente faça com que essas condições sejam atendidas. |
| Todas as condições são atendidas | AND_WITH_MATCHING_RESOURCE |
Um incidente será aberto se o mesmo recurso fizer com que cada condição seja atendida. Essa configuração é a opção de combinação mais rigorosa. |
Nesse contexto, o termo met significa que a configuração da condição é avaliada como true. Por exemplo, se a configuração for Any time series is greater than 10 for 5 minutes, quando essa instrução for avaliada como true, a condição será atendida.
Exemplo
Considere um projeto do Google Cloud que contenha duas instâncias de VM, vm1 e vm2. Além disso, suponha que você crie uma política de alertas com duas condições:
- A condição chamada
CPU usage is too highmonitora o uso da CPU das instâncias. Essa condição é atendida quando o uso da CPU de qualquer instância é maior que 100 ms/s por 1 minuto. - A condição chamada
Excessive utilizationmonitora a utilização da CPU das instâncias. Essa condição é atendida quando a utilização da CPU de qualquer instância é maior que 60% por um minuto.
Inicialmente, suponha que ambas as condições sejam avaliadas como false.
Em seguida, suponha que o uso da CPU da vm1 exceda 100 ms/s por 1 minuto. Como o uso da CPU é maior que o limite de um minuto, a condição CPU usage is too high é atendida. Se as
condições forem combinadas com Qualquer condição é atendida, um incidente
será criado porque uma condição foi atendida. Se as condições forem combinadas com
Todas as condições são atendidas ou
Todas as condições são atendidas até mesmo para recursos diferentes para cada condição,
um incidente não será criado. Essas escolhas do combinador exigem que as duas
condições sejam atendidas.
Em seguida, suponha que o uso da CPU de vm1 permaneça maior que 100 ms/s e que o uso de CPU de vm2 exceda 60% por 1 minuto. O resultado é que as duas condições são atendidas. Veja a seguir o que ocorre com base na forma como as condições são combinadas:
Qualquer condição é atendida: um incidente é criado quando um recurso faz com que uma condição seja atendida. Neste exemplo, vm2 faz com que a condição
Excessive utilizationseja atendida.Se a vm2 fizer com que a condição
CPU usage is too highseja atendida, isso também resultará na criação de um incidente. Um incidente é criado porque vm1 e vm2, fazendo com que a condiçãoCPU usage is too highseja atendida, são eventos distintos.Todas as condições são atendidas até mesmo para recursos diferentes para cada condição: um incidente é criado porque ambas as condições são atendidas.
Todas as condições são atendidas: um incidente não é criado porque esse combinador exige que o mesmo recurso faça com que todas as condições sejam atendidas. Neste exemplo, nenhum incidente é criado porque a vm1 faz com que
CPU usage is too highseja atendido, enquanto a vm2 faz com queExcessive utilizationseja atendido.
Dados de métricas parciais
Quando os dados de série temporal param de chegar ou estão atrasados, o Monitoring os classifica como ausentes. A falta de dados pode impedir o fechamento de incidentes. Os atrasos nos dados que chegam de provedores de nuvem de terceiros podem chegar a 30 minutos, sendo os atrasos de 5 a 15 minutos os mais comuns. Um atraso longo, maior do que a janela de novo teste, pode fazer com que as condições entrem em um estado "desconhecido". Quando os dados finalmente chegam, o Monitoring pode ter perdido parte do histórico recente das condições. A inspeção posterior dos dados de séries temporais pode não revelar esse problema porque não há evidências de atrasos depois que os dados chegam.
Console do Google Cloud
É possível configurar como o Monitoring avalia uma condição de limite de métrica quando os dados param de chegar. Por exemplo, quando um incidente está aberto e uma medição esperada não chega, você quer que o Monitoring deixe o incidente aberto ou o feche imediatamente? Da mesma forma, quando os dados param e nenhum incidente é aberto, você quer que um incidente seja aberto? Por último, por quanto tempo um incidente deve permanecer aberto depois que os dados param de chegar?
Há dois campos configuráveis que especificam como o Monitoring avalia as condições de limite de métrica quando os dados param de chegar:
Para configurar como o Monitoring determina o valor de substituição dos dados ausentes, use o campo Avaliação de dados ausentes definido na etapa Acionador de condição. Esse campo é desativado quando a janela de novo teste está definida como Sem novo teste.
A janela de novo teste é o campo chamado "duração" na API Cloud Monitoring.
Para configurar o tempo que o Monitoring espera antes de fechar um incidente aberto depois que os dados param de chegar, use o campo Duração do fechamento automático de incidentes. Você define a duração do fechamento automático na etapa Notificação. A duração padrão do fechamento automático é sete dias.
Confira a seguir as diferentes opções para o campo de dados ausentes:
| Console do Google Cloud Campo "Avaliação de dados ausentes" |
Resumo | Detalhes |
|---|---|---|
| Dados ausentes vazios | Incidentes abertos permanecem abertos. Novos incidentes não são abertos. |
A condição continua sendo atendida quando os dados param de chegar. Se um incidente está aberto para essa condição, ele permanece aberto. Quando um incidente está aberto e nenhum dado é recebido, o timer de fechamento automático é iniciado após um atraso de pelo menos 15 minutos. Se o timer expirar, o incidente será encerrado. Caso contrário, ela continua não sendo atendida quando os dados param de chegar. |
| Pontos de dados ausentes tratados como valores que violam a condição da política | Incidentes abertos permanecem abertos. Novos incidentes podem ser abertos. |
A condição continua sendo atendida quando os dados param de chegar. Se um incidente está aberto para essa condição, ele permanece aberto. Quando um incidente está aberto e nenhum dado chega no período de fechamento automático mais 24 horas, ele é encerrado. Para condições que não são atendidas, essa configuração faz com que a condição de limite de métrica se comporte como um |
| Pontos de dados ausentes tratados como valores que não violam a condição da política | Os incidentes abertos foram fechados. Novos incidentes não são abertos. |
Para as condições atendidas, a condição deixa de ser atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele será encerrado. Caso contrário, ela continua não sendo atendida quando os dados param de chegar. |
API
É possível configurar como o Monitoring avalia uma condição de limite de métrica quando os dados param de chegar. Por exemplo, quando um incidente está aberto e uma medição esperada não chega, você quer que o Monitoring deixe o incidente aberto ou o feche imediatamente? Da mesma forma, quando os dados param e nenhum incidente é aberto, você quer que um incidente seja aberto? Por último, por quanto tempo um incidente deve permanecer aberto depois que os dados param de chegar?
Há dois campos configuráveis que especificam como o Monitoring avalia as condições de limite de métrica quando os dados param de chegar:
Para configurar como o Monitoring determina o valor de substituição para dados ausentes, use o campo
evaluationMissingDatada estruturaMetricThreshold. Este campo é ignorado quando o campodurationé zero.Para configurar quanto tempo o Monitoring espera antes de fechar um incidente aberto depois que os dados param de chegar, use o campo
autoClosena estruturaAlertStrategy.
Confira a seguir as diferentes opções para o campo de dados ausentes:
Campo evaluationMissingData da API |
Resumo | Detalhes |
|---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED |
Incidentes abertos permanecem abertos. Novos incidentes não são abertos. |
A condição continua sendo atendida quando os dados param de chegar. Se um incidente está aberto para essa condição, ele permanece aberto. Quando um incidente está aberto e nenhum dado é recebido, o timer de fechamento automático é iniciado após um atraso de pelo menos 15 minutos. Se o timer expirar, o incidente será encerrado. Caso contrário, ela continua não sendo atendida quando os dados param de chegar. |
EVALUATION_MISSING_DATA_ACTIVE |
Incidentes abertos permanecem abertos. Novos incidentes podem ser abertos. |
A condição continua sendo atendida quando os dados param de chegar. Se um incidente está aberto para essa condição, ele permanece aberto. Quando um incidente está aberto e nenhum dado chega durante o fechamento automático mais 24 horas, o incidente é encerrado. Para condições que não são atendidas, essa configuração faz com que a condição de limite de métrica se comporte como um |
EVALUATION_MISSING_DATA_INACTIVE |
Os incidentes abertos foram fechados. Novos incidentes não são abertos. |
Para as condições atendidas, a condição deixa de ser atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele será encerrado. Caso contrário, ela continua não sendo atendida quando os dados param de chegar. |
Realize uma das seguintes ações para minimizar os problemas causados pela ausência de dados:
- Entre em contato com seu provedor de nuvem de terceiros para identificar maneiras de reduzir a latência da coleta de métricas.
- Use janelas mais longas para testar novamente nas suas condições. Usar uma janela de novo teste mais longa tem a desvantagem de tornar as políticas de alertas menos responsivas.
Escolha métricas com menor atraso de coleta:
- Métricas do agente do Monitoring, especialmente quando o agente está sendo executado em instâncias de VM em nuvens de terceiros.
- Métricas personalizadas, quando você grava dados diretamente no Monitoring.
- métricas com base em registros, se a coleta de entradas de registro não atrasar.
Para mais informações, consulte Visão geral do agente do Monitoring, Visão geral das métricas definidas pelo usuário e métricas com base em registros.
Quando o Monitoring envia notificações e cria incidentes
O Cloud Monitoring envia uma notificação quando uma série temporal faz com que uma condição seja atendida. A notificação é enviada para todos os canais de notificação. Não é possível restringir uma notificação a um canal específico ou a um subconjunto de canais da 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ê poderá receber várias notificações exclusivas relacionadas a uma política de alertas quando alguma das seguintes condições for verdadeira:
Uma condição está monitorando várias séries temporais.
Uma política contém várias condições. Nesse caso, as notificações que você recebe dependem do valor do acionador de várias condições da política de alertas:
Todas as condições são atendidas: quando todas as condições são atendidas, para cada série temporal que resulta no cumprimento de uma condição, a política de alertas 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 alertas tiver várias condições.
Qualquer condição é atendida: a política de alertas envia uma notificação quando uma série temporal faz com que a condição seja atendida.
Para mais informações, consulte Políticas com várias condições.
As políticas de alertas criadas usando a API Cloud Monitoring também notificam você quando a condição é atendida e quando a condição deixa de ser. As políticas de alertas criadas com o uso do console do Google Cloud não enviam uma notificação quando a condição deixa de ser atendida, a menos que você tenha ativado esse comportamento.
Quando o Monitoring não envia notificações nem cria incidentes
Nas situações a seguir, o Monitoring não cria incidentes nem envia notificações quando as condições de uma política de alertas são atendidas:
- A política de alertas está desativada.
- A política de alertas é adiada.
- O monitoramento atingiu o limite máximo de incidentes abertos.
Políticas de alertas desativadas
O Monitoring não envia incidentes de criação nem notificações para políticas de alertas desativadas. No entanto, o Monitoring continua a avaliar as condições de uma política de alertas desativada.
Quando você ativa uma política desativada, o Monitoring avalia os valores de todas as condições na janela de novo teste mais recente. A janela de novo teste mais recente pode incluir dados coletados antes, durante e depois da política ser ativada. As condições de uma política desativada podem ser atendidas imediatamente após a retomada dela, mesmo com grandes janelas de novo teste.
Por exemplo, suponha que você tenha uma política de alertas que monitore um processo específico e que você desative essa política. Na semana seguinte, o processo fica inativo e, como a política de alertas está desativada, você não recebe a notificação. Se você reiniciar o processo e ativar a política de alertas imediatamente, o Monitoring reconhecerá que o processo não esteve ativo nos últimos cinco minutos e abrirá um incidente.
Os incidentes relacionados a uma política de alertas desativada permanecem abertos até o fim do período de fechamento automático dela.
Políticas de alertas adiadas
O Monitoring não envia notificações nem cria incidentes para uma política de alertas adiada. Recomendamos adiar políticas de alertas quando quiser evitar que uma política de alertas envie notificações por apenas intervalos curtos. Por exemplo, antes de realizar a manutenção em uma máquina virtual (VM), é possível criar um adiamento e adicionar aos critérios de adiamento as políticas de alerta que monitoram a instância.
Quando você adia uma política de alertas, o Monitoring fecha todos os incidentes abertos relacionados a ela. O monitoramento pode abrir novos incidentes depois que o adiamento expirar. Para mais informações, consulte Adiar notificações e alertas.
Limites de notificações e incidentes abertos
Uma política de alertas pode ser aplicada a muitos recursos, e um problema que afeta todos os recursos pode fazer com que ela abra incidentes para cada recurso. Um incidente é aberto para cada série temporal que resulta no cumprimento de uma condição.
Para evitar a sobrecarga do sistema, o número de incidentes que uma única política pode abrir simultaneamente é limitado a 1.000.
Por exemplo, considere uma política que se aplique a 2.000 instâncias do Compute Engine e cada instância faça com que as condições de alerta sejam atendidas. O monitoramento limita o número de incidentes abertos a 1.000. Todas as condições restantes atendidas são ignoradas até que alguns dos incidentes abertos dessa política sejam fechados.
Como resultado desse limite, um único canal de notificação pode receber até 1.000 notificações de uma só vez. Se a política de alertas tiver vários canais de notificação, esse limite será aplicado a cada canal de notificação de maneira independente.
Latência
Latência refere-se ao atraso entre o momento em que o Monitoring faz a amostragem de uma métrica e o momento em que o ponto de dados da métrica fica visível como dados da série temporal. 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 Monitoring não criará um incidente por até 180 segundos após a condição da política de alertas ser avaliada como verdadeira. Para mais informações, consulte Latência dos dados de métrica.
Os seguintes eventos e configurações contribuem para a latência:
Atraso de coleta de métricas: o tempo que o Monitoring precisa para coletar valores de métricas. Para os valores do Google Cloud, a maioria das métricas não fica visível por 60 segundos após a coleta. No entanto, o atraso depende da métrica. Os cálculos de política de alertas levam um atraso adicional de 60 a 90 segundos. Para as métricas do AWS CloudWatch, o atraso de visibilidade pode ser de vários minutos. Para verificações de tempo de atividade, pode ser uma média de dois minutos (a partir do fim da janela de novo teste).
Janela de novo teste: a janela configurada para a condição. As condições só serão atendidas quando uma condição for verdadeira em toda a janela de novo teste. Por exemplo, uma configuração de janela de novo teste de cinco minutos causa atrasos na notificação de pelo menos cinco minutos a partir da primeira ocorrência do evento.
Tempo para a chegada da notificação: os canais de notificação, como e-mail e SMS, podem enfrentar latências de rede ou outras latências (não relacionadas ao que está sendo entregue), às vezes na ordem dos minutos. Em alguns canais, como SMS e Slack, não há garantia de que as mensagens serão entregues.
A seguir
Para informações sobre como criar uma política de alertas, consulte os seguintes documentos:
Para ver uma variedade de políticas de alertas, consulte Políticas de amostra.