Este documento descreve como os períodos de alinhamento e os intervalos 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 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 baseadas 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 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 chamado de agrupamento por classes os 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. você pode somar todos os valores ou calcular a média ou usar o máximo. Função que combina os pontos dos dados. é chamado 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 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:
Console do Google Cloud
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. Um pouco do alinhador
as duas funções alinham os dados
e a converter 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 o
Campos aggregations.alignmentPeriod e aggregations.perSeriesAligner
no elemento 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 um modelo de
use uma condição de limite de métrica que seja
monitorar 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 está 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,
descrito 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. 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 identificada
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 do 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 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 novo teste de uma condição esteja definida como 15 minutos. A seguir, descrevemos o comportamento da condição com base na type
- 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 cada previsão produz durante uma janela de 15 minutos prevê 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 as notificações são enviada 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 o acionador de alertas.
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. No
horário 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 para o próximo
avaliações da condição:
Embora o valor alinhado seja maior que o limite em
start + 2 minutes, a condição não é atendida até que o valor alinhado
for maior do que o limite para 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 estimativa é feita. não satisfaz a condição. Esse comportamento é ilustrado a seguir exemplo:
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 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 é inferior a dois segundos, redefine a janela de novo teste.
Nos próximos cinco minutos consecutivos, a latência HTTP é maior do que dois segundos, para que a condição seja 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 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 a cada 300 segundos, o período de alinhamento deve 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 na ingestão de uma métrica for 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 para 20 minutos por um condição de ausência de métrica então não deve haver dados por 20 minutos antes de a condição ser 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, defina a janela de nova tentativa como zero para ter 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 opções que que você faz para o período de alinhamento e a janela de novo teste não determina 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 é 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
Você configura as opções do combinador com o campo combiner da
estrutura AlertPolicy.
Esta tabela lista as configurações do console do Google Cloud, o equivalente na API Cloud Monitoring e uma descrição de cada configuração:
| Valor de acionamento da política do console do Google Cloud |
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. Para
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. Esta 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. Devido ao
o uso da CPU for maior que o limite por um minuto, a condição
CPU usage is too high é atendido. 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, 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 têm atraso, O Monitoring classifica os dados como ausentes. Dados ausentes podem impedir o fechamento de incidentes. Atrasos nos dados que chegam de provedores de nuvem de terceiros pode levar até 30 minutos, sendo que atrasos de 5 a 15 minutos são os mais comuns. Um longo atraso, maior do que a janela de novo teste, pode fazer com que as condições entrem em um "desconhecido" estado. Quando os dados 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 é aberto, e uma estimativa não chegar, você quer que o Monitoring deixe o incidente abri-lo ou fechá-lo imediatamente? Da mesma forma, quando os dados param de chegar e nenhum incidente está aberto, você quer que um incidente seja aberto? Por último, 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 definido na etapa Acionar condição. Esse campo é desativado quando a janela de nova tentativa é definida como Sem nova tentativa.
A janela de novo teste é 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. Você define a duração do fechamento automático no 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:
| Console do Google Cloud Campo "Avaliação de dados ausentes" |
Resumo | Detalhes |
|---|---|---|
| Dados ausentes vazios | 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 houver um incidente aberto para essa condição, o incidente permanece 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 | Incidentes abertos permanecem abertos. Novos incidentes podem ser abertos. |
Quando as condições são atendidas, a condição continua a ser quando os dados param de chegar. Se um incidente estiver aberto para essa condição, ele vai permanecer aberto. Quando um incidente é aberto e nenhum dado chega para a duração do fechamento automático mais 24 horas, o incidente é encerrado. Para condições que não são atendidas, essa configuração faz com que o
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 foram 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 param de chegar. Se houver um incidente aberto para essa condição, o incidente é encerrado. Caso as condições não sejam atendidas, a condição continua a não ser atendida quando os dados pararem 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 Monitoring determina o valor de substituição para dados ausentes, use o método
evaluationMissingDatada estruturaMetricThreshold. Esse 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 ausente:
| API Campo evaluationMissingData |
Resumo | Detalhes |
|---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED |
Os incidentes abertos permanecem abertos. Os novos incidentes não são abertos. |
Quando as condições são atendidas, a condição continua a ser 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. Caso as condições não sejam 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 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 para a duração do fechamento automático mais 24 horas, o incidente é encerrado. Para condições que não são atendidas, essa configuração faz com que o
a condição de limite de métrica se comporte como uma |
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 houver um incidente aberto para essa condição, o incidente é encerrado. Para condições que não são atendidas, a condição 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 terceirizado para identificar maneiras de reduzir latência de coleta de métricas.
- Use janelas de nova tentativa mais longas nas condições. Como usar uma janela de novo teste mais longa tem a desvantagem de tornar as políticas de alertas menos responsivo.
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 Informações gerais do agente do Monitoring, Visão geral das métricas definidas pelo usuário 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 dos 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 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. As políticas de alertas criadas com o console do Google Cloud não enviam uma notificação quando a condição deixar de ser atendida, a menos que você as ative esse comportamento.
Quando o Monitoring não envia notificações nem cria incidentes
Nas situações a seguir, o Monitoring não cria incidentes ou enviar notificações quando as condições de uma política de alertas forem atendidas:
- A política de alertas está desativada.
- A política de alertas está 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 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 nova tentativa mais recente. A janela de novo teste mais recente pode incluir dados coletados antes, durante e depois as política foi ativada. 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, imagine que você tem uma política de alertas que monitora um e desative essa política. Na semana seguinte, o processo é interrompido, e, como a política de alerta 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é a duração do fechamento automático da política expira.
Políticas de alertas adiadas
O monitoramento não envia notificações nem cria incidentes uma política de alertas adiada. Recomendamos adiar as políticas de alerta quando você quiser impedir que uma política de alerta envie notificações apenas 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ê adiar uma política de alertas, o Monitoring fecha todos os incidentes abertos relacionados à política. 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 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. Quaisquer condições restantes que sejam atendidas ignorados 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 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 quando as notificações são enviadas. Por exemplo, se um servidor tiver uma latência de até 180 segundos, depois O Monitoring não cria um incidente por até 180 segundos após a condição da política de alertas é 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 na coleta de métricas: o tempo que o Monitoring precisa para coletar valores de métricas. Para 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 métricas do AWS CloudWatch, o atraso de visibilidade pode levar 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 informações sobre como criar uma política de alertas, consulte os documentos:
Para ver uma variedade de políticas de alertas, consulte Políticas de amostra.