Neste documento, descrevemos como o período de alinhamento e as configurações de duração determinam quando uma condição é atendida, como as políticas de alertas combinam várias condições e como as políticas de alertas substituem pontos de dados ausentes. Também descreve o número máximo de incidentes abertos de uma política, o número de notificações por incidente e o que causa atrasos nas notificações.
Este conteúdo não se aplica a políticas de alertas baseadas em registros. Para informações sobre políticas de alertas com base em registros, consulte Como monitorar seus registros.
Configurações de período de alinhamento e duração
O período de alinhamento e a janela de duração são dois campos que você define ao especificar uma condição para uma política de alertas. Nesta seção, veremos uma breve ilustração do significado desses campos.
Período de alinhamento
O período de alinhamento é um intervalo de retrospectiva de um ponto específico no tempo. O aligner é a função que combina os pontos no intervalo de lookback em um valor alinhado. Por exemplo, quando o período de alinhamento é de cinco minutos, às 13h, o período de alinhamento contém as amostras recebidas entre 12h55 e 13h. Às 13h01, o período de alinhamento desliza um minuto e contém as amostras recebidas entre 12h56 e 13h01.
Console do Google Cloud
Configure os campos de alinhamento usando os menus Janela contínua e Função de janela contínua que fazem parte da caixa de diálogo Nova condição.
Para mais informações sobre as funções disponíveis, consulte Aligner na referência da API. Algumas das funções de alinhamento alinham os dados e os convertem de um tipo de métrica para outro. Para uma explicação
detalhada, consulte Tipos, tipos e conversões.
API
Para configurar os campos de alinhamento, defina os
campos aggregations.alignmentPeriod e aggregations.perSeriesAligner
nas estruturas MetricThreshold e
MetricAbsence.
Para mais informações sobre as funções disponíveis, consulte Aligner na referência da API. Algumas das funções de alinhamento alinham os dados e os convertem de um tipo de métrica para outro. Para uma explicação
detalhada, consulte Tipos, tipos e conversões.
Para ilustrar o efeito do período de alinhamento em uma condição em uma política de alertas, considere uma condição de limite de métrica que esteja monitorando uma métrica com um período de amostragem de um minuto. Suponha que o período de alinhamento esteja definido como cinco minutos e que
o alinhador esteja definido como sum. Além disso, suponha que a condição seja atendida quando o valor alinhado da série temporal for maior que dois por pelo menos três minutos e que a condição seja avaliada a cada minuto.
A figura a seguir ilustra várias avaliações sequenciais da
condição:
Cada linha na figura ilustra uma única avaliação da condição. Os
dados das séries temporais são exibidos. Os pontos no período de alinhamento são mostrados com
pontos azuis, enquanto os mais antigos são pretos. Cada linha exibe o valor alinhado e se esse valor é maior que o limite de dois. Para a linha start, o valor alinhado é calculado como um, que é menor que o limite.
Na próxima avaliação, a soma das amostras no período de alinhamento será dois.
Na terceira avaliação, a soma é três e, como esse valor é maior que o limite, um timer para a duração é iniciado.
Janela de duração
Use a duração ou a janela de duração para evitar que uma condição seja atendida devido a uma única medição ou previsão. Por exemplo, suponha que o campo de duração de uma condição esteja definido como 15 minutos. Veja a seguir a descrição do comportamento da condição com base no tipo:
- As condições de limite de métrica são atendidas quando, para uma única série temporal, todas as medições alinhadas em um intervalo de 15 minutos violam o limite.
- As condições de ausência de métrica são atendidas quando nenhum dado chega para uma série temporal em um intervalo de 15 minutos.
- As condições de previsão são atendidas quando cada previsão produzida durante uma janela de 15 minutos prevê que a série temporal vai violar o limite dentro da janela de previsão.
Para políticas com uma condição, um incidente é aberto e uma notificação é enviada quando a condição é atendida. Esses incidentes permanecem abertos enquanto a condição é atendida.
Console do Google Cloud
Configure a janela de duração usando o campo Janela de novo teste na etapa Configurar gatilho.
API
Para configurar a janela de duração, defina o campo
duration nas estruturas MetricThreshold e
MetricAbsence.
A figura anterior ilustrou três avaliações de uma condição de limite de métrica. No momento start + 2 minutes, o valor alinhado é maior que o limite. No entanto, a condição não é atendida porque a janela de duração está definida como três minutos. A figura a seguir ilustra os resultados para as próximas avaliações da condição:
Mesmo que o valor alinhado seja maior que o limite no
momento start + 2 minutes, a condição não será atendida até que o valor alinhado
seja maior que o limite por três minutos. Esse evento ocorre no horário
start + 5 minutes.
Uma condição redefine a janela de duração sempre que uma medição ou previsão não a satisfaz. Esse comportamento é ilustrado no exemplo a seguir:
Exemplo: esta política de alertas contém uma condição de limite de métrica que especifica uma janela de duração de cinco minutos.
Se a latência da resposta HTTP for maior que dois segundos
e se a latência for maior que o limite por cinco minutos,
abra um incidente e envie um e-mail para sua equipe de suporte.A sequência a seguir ilustra como a janela de duração afeta a avaliação da condição:
- A latência HTTP é 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, de modo que a condição redefine a janela de duração.
Nos próximos cinco minutos consecutivos, a latência HTTP é maior que dois segundos, então a condição é atendida.
Como a política de alertas tem uma condição, o Monitoring envia notificações quando ela é atendida.
A janela de duração precisa ser longa o suficiente para minimizar os falsos positivos, mas curta o suficiente para garantir que os incidentes sejam abertos na hora certa.
Práticas recomendadas para definir o período de alinhamento e a janela de duração
O período de alinhamento determina quantas amostras são combinadas com o alinhador:
O valor mínimo do período de alinhamento para um tipo de métrica é o período de amostragem desse tipo de métrica. Por exemplo, se a amostragem do tipo de métrica for feita a cada 300 segundos, o período de alinhamento precisará ser de pelo menos 300 segundos. No entanto, se você quiser combinar cinco amostras, defina o período de alinhamento como 5 * 300 segundos ou 1.500 segundos.
O valor máximo do período de alinhamento é de 24 horas a menos do atraso de ingestão do tipo de métrica. Por exemplo, se o atraso na ingestão de uma métrica for de 6 horas, o valor máximo do período de alinhamento será de 18 horas.
Use a janela de duração para especificar a capacidade de resposta do alerta. Por exemplo, se você definir a janela de duração como 20 minutos para uma condição de ausência de métrica, não poderá haver dados por 20 minutos antes que a condição seja atendida. Para uma política de alertas mais responsiva, defina a duração com um valor menor. Para condições de limite de métrica, para ter a política de alertas mais responsiva, defina a duração como zero. Um único valor alinhado faz com que esses tipos de condições sejam atendidos.
As condições da política de alertas são avaliadas em uma frequência fixa. As escolhas feitas para o período de alinhamento e a janela de duração não determinam com que frequência a condição é avaliada.
Políticas com várias condições
Uma política de alertas pode conter até seis condições.
Se você estiver usando a API Cloud Monitoring ou se a política de alertas tiver várias condições, especifique quando um incidente será aberto. Para configurar como várias condições são combinadas, siga um destes procedimentos:
Console do Google Cloud
As opções do combinador são configuradas na etapa Gatilho de várias condições.
API
Configure as opções do combinador com o campo combiner da
estrutura AlertPolicy.
Esta tabela lista as configurações no console do Google Cloud, o valor equivalente na API Cloud Monitoring e uma descrição de cada configuração:
| Console do Google Cloud Valor de acionadores da política |
Valor do combinador da API Cloud Monitoring |
Significado |
|---|---|---|
| Qualquer condição é atendida | OR |
Um incidente será aberto se algum recurso fizer com que qualquer uma das condições seja atendida. |
| Todas as condições são atendidas mesmo para recursos diferentes para cada condição (padrão) |
AND |
Um incidente é aberto se cada condição for atendida, mesmo que um recurso diferente faça com que elas sejam atendidas. |
| Todas as condições são atendidas | AND_WITH_MATCHING_RESOURCE |
Um incidente será aberto se o mesmo recurso fizer com que cada condição seja atendida. Essa configuração é a opção de combinação mais rigorosa. |
Nesse contexto, o termo at significa que a configuração da condição é avaliada como true. Por exemplo, se a configuração for Any time series is greater than 10 for 5 minutes, quando esta instrução for avaliada como true, a condição será atendida.
Exemplo
Considere um projeto do Google Cloud que contenha duas instâncias de VM, vm1 e vm2. Além disso, suponha que você crie uma política de alertas com duas condições:
- A condição chamada
CPU usage is too 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 por um minuto, a condição
CPU usage is too high é atendida. Se as
condições forem combinadas com Qualquer condição é atendida, um incidente
será criado porque uma condição foi atendida. Se as condições forem combinadas com
Todas as condições são atendidas ou
Todas as condições são atendidas até mesmo para recursos diferentes para cada condição,
um incidente não será criado. Essas escolhas do combinador exigem que as duas
condições sejam atendidas.
Em seguida, suponha que o uso da CPU de vm1 permaneça maior que 100 ms/s e que a utilização da CPU da vm2 exceda 60% por um minuto. O resultado é que as duas condições são atendidas. Veja a seguir o que ocorre com base na forma como as condições são combinadas:
Qualquer condição é atendida: um incidente é criado quando um recurso faz com que uma condição seja atendida. Neste exemplo, vm2 faz com que a condição
Excessive 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 a vm1 e a vm2 que fazem 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 da série temporal param de chegar ou estão atrasados, o Monitoring os classifica como ausentes. A falta de dados pode impedir o fechamento de incidentes. Os atrasos nos dados que chegam de provedores de nuvem de terceiros podem ser de até 30 minutos, sendo que os atrasos de 5 a 15 minutos são os mais comuns. Um atraso longo, maior do que a janela de duração, pode fazer com que as condições entrem em um estado "desconhecido". Quando os dados finalmente chegarem, o Monitoring poderá ter perdido parte do histórico recente das condições. A inspeção posterior dos dados de séries temporais pode não revelar esse problema porque não há evidências de atrasos depois que os dados chegam.
Console do Google Cloud
É possível configurar como o Monitoring avalia uma condição de limite de métrica quando os dados param de chegar. Por exemplo, quando um incidente está aberto e uma medição esperada não chega, você quer que o Monitoring deixe o incidente aberto ou o feche imediatamente? Da mesma forma, quando os dados param de chegar e nenhum incidente está aberto, você quer que um incidente seja aberto? Por fim, por quanto tempo um incidente deve permanecer aberto após a chegada dos dados?
Há dois campos configuráveis que especificam como o Monitoring avalia as condições de limite de métrica quando os dados param de chegar:
Para configurar como o Monitoring determina o valor de substituição para dados ausentes, use o campo Avaliação de dados ausentes que você definiu na etapa Acionador de condição. Esse campo é desativado quando a janela de novo teste é definida como Sem novo teste.
Para configurar quanto tempo o Monitoring aguarda antes de fechar um incidente aberto após a chegada dos dados, use o campo Duração do fechamento automático do incidente. Defina a duração do fechamento automático na etapa Notificação. A duração padrão do fechamento automático é sete dias.
Veja a seguir as diferentes opções para o campo de dados ausentes:
| Console do Google Cloud Campo "Avaliação de dados ausentes" |
Resumo | Detalhes |
|---|---|---|
| Dados ausentes vazios | Os incidentes abertos permanecem abertos. Novos incidentes não são abertos. |
Para as condições que são atendidas, a condição continua a ser atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele permanecerá aberto. Quando um incidente está aberto e nenhum dado chega, o timer de fechamento automático é iniciado após um atraso de pelo menos 15 minutos. Se o timer expirar, o incidente será encerrado. Para condições que não são atendidas, a condição continua a não ser atendida quando os dados param de chegar. |
| Pontos de dados ausentes tratados como valores que violam a condição da política | Os incidentes abertos permanecem abertos. Novos incidentes podem ser abertos. |
Para as condições que são atendidas, a condição continua a ser atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele permanecerá aberto. Quando um incidente está aberto e nenhum dado chega durante o fechamento automático mais 24 horas, o incidente é encerrado. Para condições que não são atendidas, essa configuração faz com que a condição de limite de métrica se comporte como uma |
| Pontos de dados ausentes, tratados como valores que não violam a condição da política | Os incidentes abertos são fechados. Novos incidentes não são abertos. |
Para as condições que são atendidas, a condição deixa de ser atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele será encerrado. Para condições que não são atendidas, a condição continua a não ser atendida quando os dados param de chegar. |
API
É possível configurar como o Monitoring avalia uma condição de limite de métrica quando os dados param de chegar. Por exemplo, quando um incidente está aberto e uma medição esperada não chega, você quer que o Monitoring deixe o incidente aberto ou o feche imediatamente? Da mesma forma, quando os dados param de chegar e nenhum incidente está aberto, você quer que um incidente seja aberto? Por fim, por quanto tempo um incidente deve permanecer aberto após a chegada dos dados?
Há dois campos configuráveis que especificam como o Monitoring avalia as condições de limite de métrica quando os dados param de chegar:
Para configurar como o Monitoring determina o valor de substituição para dados ausentes, use o campo
evaluationMissingDatada estruturaMetricThreshold. Este campo é ignorado quando o campodurationé zero.Para configurar quanto tempo o Monitoring espera antes de fechar um incidente aberto após os dados deixarem de chegar, use o campo
autoClosena estruturaAlertStrategy.
Veja a seguir as diferentes opções para o campo de dados ausentes:
Campo evaluationMissingData
da API |
Resumo | Detalhes |
|---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED |
Os incidentes abertos permanecem abertos. Novos incidentes não são abertos. |
Para as condições que são atendidas, a condição continua a ser atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele permanecerá aberto. Quando um incidente está aberto e nenhum dado chega, o timer de fechamento automático é iniciado após um atraso de pelo menos 15 minutos. Se o timer expirar, o incidente será encerrado. Para condições que não são atendidas, a condição continua a não ser atendida quando os dados param de chegar. |
EVALUATION_MISSING_DATA_ACTIVE |
Os incidentes abertos permanecem abertos. Novos incidentes podem ser abertos. |
Para as condições que são atendidas, a condição continua a ser atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele permanecerá aberto. Quando um incidente está aberto e nenhum dado chega durante o fechamento automático mais 24 horas, o incidente é encerrado. Para condições que não são atendidas, essa configuração faz com que a condição de limite de métrica se comporte como uma |
EVALUATION_MISSING_DATA_INACTIVE |
Os incidentes abertos são fechados. Novos incidentes não são abertos. |
Para as condições que são atendidas, a condição deixa de ser atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele será encerrado. Para condições que não são atendidas, a condição continua a não ser atendida quando os dados param de chegar. |
Para minimizar os problemas devido à ausência de dados, você pode fazer o seguinte:
- Entre em contato com seu provedor de nuvem terceirizado para identificar maneiras de reduzir a latência da coleta de métricas.
- Use janelas de duração mais longas nas condições. Usar uma janela de duração maior tem a desvantagem de tornar as políticas de alertas menos responsivas.
Escolha métricas com menor atraso de coleta:
- Métricas do agente do Monitoring, especialmente quando o agente está sendo executado em instâncias de VM em nuvens de terceiros.
- Métricas personalizadas, quando você grava dados diretamente no Monitoring.
- Métricas com base em registros, se a coleta de entradas de registro não for atrasada.
Para mais informações, consulte Visão geral do agente do Monitoring, Visão geral das métricas definidas pelo usuário e Métricas com base em registros.
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 a todos os canais. Não é possível restringir uma notificação a um canal específico ou a um subconjunto de canais da sua política.
Se você configurar notificações repetidas, a mesma notificação será reenviada a 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 uma das seguintes condições for verdadeira:
Uma condição está monitorando várias séries temporais.
Uma política contém várias condições. Nesse caso, as notificações recebidas dependem do valor do acionador de várias condições da política de alertas:
Todas as condições são atendidas: quando todas as condições são atendidas, para cada série temporal que resulta 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 contém várias condições.
Qualquer condição é atendida: a política de alertas envia uma notificação quando uma série temporal faz com que a condição seja atendida.
Para mais informações, consulte Políticas com várias condições.
As políticas de alertas criadas com a API Cloud Monitoring também notificam você quando a condição é atendida e quando a condição deixa de ser atendida. As políticas de alertas criadas com o console do Google Cloud não enviam uma notificação quando a condição deixa de ser atendida, a menos que você tenha ativado esse comportamento.
Quando o Monitoring não envia notificações nem cria 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 foi adiada.
- O monitoramento atingiu o limite do número 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 avaliando as condições dessa 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 duração mais recente. A duração mais recente pode incluir dados coletados antes, durante e depois da ativação da política. As condições de uma política desativada podem ser atendidas imediatamente após a retomada da política, mesmo com grandes janelas de duração.
Por exemplo, suponha que você tenha uma política de alertas que monitore um processo específico e que desative essa política. Na semana seguinte, o processo é interrompido, e você não recebe uma notificação porque a política de alertas foi desativada. Se você reiniciar o processo e ativar a política de alertas imediatamente, o Monitoring reconhecerá que o processo não está funcionando nos últimos cinco minutos e abrirá um incidente.
Os incidentes relacionados a uma política de alertas desativada permanecem abertos até que a duração do fechamento automático da política expire.
Políticas de alertas adiados
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 impedir que uma política de alertas envie notificações apenas por intervalos curtos. Por exemplo, antes de executar a manutenção em uma máquina virtual (VM), crie um adiamento e adicione aos critérios de adiamento as políticas de alertas que monitoram a instância.
Quando você adia uma política de alertas, o Monitoring fecha todos os incidentes abertos relacionados à política. O Monitoring 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, pense em uma política que se aplica a 2.000 instâncias do Compute Engine, e cada instância faz com que as condições de alerta sejam atendidas. O Monitoring limita o número de incidentes abertos a 1.000. Todas as condições restantes que forem atendidas serão ignoradas até que alguns dos incidentes abertos para essa política sejam fechados.
Como resultado desse limite, um único canal de notificação pode receber até 1.000 notificações por vez. Se a política de alertas tiver vários canais de notificação, esse limite se aplicará a cada canal de forma 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 se torna visível como dados de série temporal. A latência afeta o envio das notificações. Por exemplo, se uma métrica monitorada tiver uma latência de até 180 segundos, o Monitoring não criará um incidente por até 180 segundos depois que a condição da política de alertas for avaliada como verdadeira. Para mais informações, consulte Latência dos dados de métricas.
Os eventos e as configurações a seguir contribuem para a latência:
Atraso na coleta de métricas: o tempo que o Monitoring precisa para coletar valores de métricas. Para os valores do Google Cloud, a maioria das métricas não fica visível por 60 segundos após a coleta. No entanto, o atraso depende da métrica. Os cálculos da política de alertas têm um atraso adicional de 60 a 90 segundos. Para as métricas do AWS CloudWatch, o atraso de visibilidade pode ser de vários minutos. Para verificações de tempo de atividade, pode ser uma média de dois minutos (a partir do final da janela de duração).
Janela de duração: a janela configurada para a condição. As condições são atendidas apenas quando uma condição é verdadeira ao longo da janela de duração. Por exemplo, uma configuração de janela de duração de cinco minutos causa atrasos na notificação de pelo menos cinco minutos a partir da primeira ocorrência do evento.
Tempo para a chegada da notificação: os canais de notificação, como e-mail e SMS, podem enfrentar latências de rede ou outras latências (não relacionadas ao que está sendo entregue), às vezes na ordem dos minutos. Em alguns canais, como SMS e Slack, não há garantia de que as mensagens serão entregues.
A seguir
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.