Este documento descreve como os períodos de alinhamento e as janelas de novo teste determinam quando uma condição é atendida, como as políticas de alerta combinam várias condições e como elas substituem 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 baseadas em registros, consulte Como monitorar seus registros.
Períodos de alinhamento e janelas de novo 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 dados espaçados regularmente para avaliação. O processo de regularização é chamado de alinhamento.
O alinhamento envolve duas etapas:
Dividir a série temporal em intervalos de tempo regulares, também chamados de agrupamento dos dados. O intervalo é o período de alinhamento.
Calcular um único valor para os pontos no período de alinhamento. Você escolhe como esse ponto único é calculado. É possível somar todos os valores ou calcular a média deles, ou usar o valor 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 o alinhamento, consulte Alinhamento: regularização em 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 desliza um minuto e contém as amostras recebidas entre 12h56 e 13h01.
O monitoramento configura um período de alinhamento da seguinte maneira:
Google Cloud console
Para configurar o período de alinhamento, selecione um valor para os seguintes campos na página Condições de alerta:
- Janela móvel: especifica o período a ser avaliado.
- Função de janela de rolagem: especifica a função matemática a ser realizada 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 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 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.
Neste exemplo, o período de alinhamento é de dois minutos, e a janela de novo teste,
que é 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 das séries temporais são exibidos. Os pontos no período de alinhamento são mostrados com
pontos azuis. Os pontos mais antigos são pretos. Cada linha mostra 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 será 2.
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.
Janelas de novo teste
A condição de uma política de alertas tem uma janela de nova tentativa, que impede que a condição seja atendida devido a uma única medição ou previsão. Por exemplo, suponha que a janela de nova tentativa de uma condição esteja definida como 15 minutos. Confira a seguir o comportamento da condição com base no tipo:
- As condições de limite de métrica são atendidas quando, em 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 preveem 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 as notificações são enviadas quando a condição é atendida. Esses incidentes permanecem abertos enquanto a condição continua sendo atendida.
Google Cloud console
Para configurar a janela de nova tentativa, use o campo Janela de nova tentativa na etapa Configurar gatilho do alerta.
API
Para configurar a janela de nova tentativa, defina o campo chamado
duration nas estruturas MetricThreshold e
MetricAbsence.
A figura anterior ilustra três avaliações de uma condição de limite de métrica. Às
start + 2 minutes, o valor alinhado é maior que o limite.
No entanto, a condição não foi atendida porque a janela de novo teste foi 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 às
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 a seguir:
Exemplo: esta política de alertas contém uma condição de limite de métrica que especifica uma janela de nova avaliação de cinco minutos.
Se a latência de resposta HTTP for maior que dois segundos,
e se a latência tiver uma duração maior que 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 novo teste 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 será maior que dois segundos.
- Na próxima medição, a latência é menor que dois segundos, de modo que a condição redefine a janela de nova tentativa.
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 a condição é atendida.
Defina a janela de nova tentativa para ser longa o suficiente para minimizar 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 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 de um tipo de métrica é o período de amostragem desse tipo. Por exemplo, se o tipo de métrica for amostrado 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 menos o atraso de transferência do tipo de métrica. Por exemplo, se o atraso de transferência 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 nova tentativa 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 como um valor menor. Para condições de limite de métrica, defina a janela de nova tentativa como zero e tenha a política de alertas mais responsiva. 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 que você faz 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 é aberto. Para configurar como várias condições são combinadas, siga um destes procedimentos:
Google Cloud console
Configure as opções do combinador na etapa Gatilho de várias condições.
API
Você configura 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:
| Google Cloud console Ativação de políticas |
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 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 um 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.
Agora, suponha que o uso da CPU da vm1 continue a ultrapassar 100 ms/s e que a utilização da CPU da 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, 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 de série temporal param de chegar ou são atrasados, o monitoramento os classifica como ausentes. Dados ausentes podem impedir o fechamento de incidentes. Os atrasos nos dados que chegam de fornecedores de nuvem de terceiros podem atingir 30 minutos, sendo os 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.
Google Cloud console
É 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 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 monitoramento determina o valor de substituição para dados ausentes, use o campo Avaliação de dados ausentes que você definiu na etapa Acionar condição. Esse campo é desativado quando a janela de nova tentativa é definida como Sem nova tentativa.
A janela de nova tentativa é o campo chamado "duração" na API Cloud Monitoring.
Para configurar o tempo de espera do Monitoring antes de fechar um incidente aberto depois que os dados param de chegar, use o campo Duração do fechamento automático de incidentes. Defina a duração do fechamento automático na etapa Notificação. A duração padrão do fechamento automático é de sete dias.
Confira a seguir as diferentes opções para o campo de dados ausente:
| Google Cloud console Campo "Avaliação de dados ausentes" |
Resumo | Detalhes |
|---|---|---|
| Dados ausentes | Os incidentes abertos permanecem abertos. Os novos incidentes não são abertos. |
Para condições atendidas, a condição continua sendo atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele vai permanecer aberto. Quando um incidente está aberto e nenhum dado chega, o timer de fechamento automático começa 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 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 | Os incidentes abertos permanecem abertos. Novos incidentes podem ser abertos. |
Para condições atendidas, a condição continua sendo atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele vai permanecer aberto. Quando um incidente está aberto e nenhum dado chega durante a duração do fechamento automático mais 24 horas, ele é fechado. 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 são encerrados. Os novos incidentes não são abertos. |
Para 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á fechado. Para condições que não são atendidas, a condição 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 de chegar e nenhum incidente está aberto, você quer que um incidente seja aberto? Por fim, 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 monitoramento determina o valor de substituição para dados ausentes, use o campo
evaluationMissingDatada estruturaMetricThreshold. Esse campo é ignorado quando o campodurationé zero.Para configurar por quanto tempo o Monitoring vai esperar antes de fechar um incidente aberto depois que os dados pararem de chegar, use o campo
autoClosena estruturaAlertStrategy.
Confira a seguir as diferentes opções para o campo de dados ausente:
Campo evaluationMissingData da API |
Resumo | Detalhes |
|---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED |
Os incidentes abertos permanecem abertos. Os novos incidentes não são abertos. |
Para condições atendidas, a condição continua sendo atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele vai permanecer aberto. Quando um incidente está aberto e nenhum dado chega, o timer de fechamento automático começa 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 não sendo atendida quando os dados param de chegar. |
EVALUATION_MISSING_DATA_ACTIVE |
Os incidentes abertos permanecem abertos. Novos incidentes podem ser abertos. |
Para condições atendidas, a condição continua sendo atendida quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele vai permanecer aberto. Quando um incidente está aberto e nenhum dado chega durante a duração do fechamento automático mais 24 horas, ele é fechado. 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 são encerrados. Os novos incidentes não são abertos. |
Para 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á fechado. Para condições que não são atendidas, a condição continua não sendo atendida quando os dados param de chegar. |
Para minimizar problemas devido a dados ausentes, faça 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 nova tentativa mais longas nas condições. Usar uma janela de nova tentativa 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 os dados diretamente no Monitoring.
- Métricas com base em registros, se a coleta de entradas de registro não estiver 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 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á enviada novamente para canais de notificação específicos da sua política de alertas.
Você pode 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 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 em uma condição atendida, 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 ela é interrompida. As políticas de alerta criadas usando o console 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 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 alertas são atendidas:
- A política de alertas está desativada.
- A política de alertas foi adiada.
- O monitoramento atingiu o limite máximo de incidentes abertos.
Políticas de alertas desativadas
O monitoramento não cria incidentes nem envia notificações para políticas de alerta desativadas. No entanto, o Monitoring continua avaliando 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 nova avaliação mais recente. A janela de nova análise 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, mesmo com janelas de nova tentativa grandes.
Por exemplo, suponha que você tenha uma política de alertas que monitora um processo específico e que você desative essa política. Na semana seguinte, o processo é interrompido, e, como a política de alertas está desativada, você não recebe uma notificação. Se você reiniciar o processo e ativar a política de alertas imediatamente, o Monitoring vai reconhecer que o processo não estava ativo nos últimos cinco minutos e vai abrir um incidente.
Os incidentes relacionados a uma política de alertas desativada permanecem abertos até que o período de fechamento automático da política expire.
Políticas de alertas adiadas
O Monitoring não envia notificações nem cria incidentes para uma política de alertas adiada. Recomendamos adiar as políticas de alerta quando você quiser impedir que uma política de alertas envie notificações por intervalos curtos. Por exemplo, antes de realizar a manutenção em uma máquina virtual (VM), você pode 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 após 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 a política de alertas abra incidentes para cada recurso. Um incidente é aberto para cada série temporal que resulta em uma condição atendida.
Para evitar a sobrecarga no 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. Qualquer condição restante atendida será ignorada até que alguns dos incidentes abertos para essa política sejam resolvidos.
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 será aplicado a cada canal de notificação de forma independente.
Latência
Latência se refere ao atraso entre o momento em que o Monitoring coleta uma métrica e o momento em que o ponto de dados da métrica fica visível como dados de série temporal. A latência afeta o envio de notificações. Por exemplo, se uma métrica monitorada tiver uma latência de até 180 segundos, o monitoramento não vai criar um incidente até 180 segundos depois que a condição da política de alertas for avaliada como verdadeira. Para saber mais, consulte Latência dos dados de métrica.
Os eventos e as configurações a seguir contribuem para a latência:
Atraso de coleta de métrica: o tempo que o Monitoring precisa para coletar valores de métrica. 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. As computações da política de alerta levam um atraso adicional de 60 a 90 segundos. Para as métricas do AWS CloudWatch, o atraso na visibilidade pode ser de vários minutos. Para verificações de tempo de atividade, essa pode ser uma média de dois minutos (a partir do final da janela de novo teste).
Janela de novo teste: a janela configurada para a condição. As condições só são atendidas quando uma condição é verdadeira durante a janela de reteste. Por exemplo, uma janela de nova tentativa de 5 minutos causa atrasos na notificação de pelo menos 5 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 de outros tipos não relacionados 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 saber 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.