Este documento descreve como períodos de alinhamento e novas janelas de teste determinar quando uma condição é atendida, como as políticas de alertas combinam vários e como as políticas de alertas 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 saber mais 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 da série temporal sejam monitorados por uma política de alertas, eles precisam ser regularizada para que a política de alertas tenha regularmente dados espaçados para avaliação. O processo de regularização é chamado de alinhamento.
O alinhamento envolve duas etapas:
Dividir a série temporal em intervalos 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 é a 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 for 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 Monitoring configura um período de alinhamento da seguinte maneira:
Console do Google Cloud
Você configura o período de alinhamento Escolha 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 que você executa 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 um
explicação, consulte Tipos, 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. 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 um
explicação, consulte Tipos, 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 foi atendida
quando o valor alinhado da série temporal for maior do que dois para
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 exibe o valor alinhado e
se esse valor é maior do 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 novo teste, o que impede a seja atingida 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 em type
- As condições de limite de métrica são atendidas quando, para um única série temporal, toda medida alinhada em um intervalo de 15 minutos viola o limite.
- As condições de ausência de métrica são atendidas quando nenhum dado chega para em 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 e a condição continua a ser cumprida.
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 novo teste, defina o campo chamado
duration nas APIs MetricThreshold e
Estruturas MetricAbsence.
A figura anterior ilustrou três avaliações de um limite de métrica
condição. 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 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 à 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 será maior de 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 novo teste para ser longa o suficiente para minimizar falsos positivos, mas curtas o suficiente para assegurar 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 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 para 5 * 300 segundos, ou 1.500 segundos.
O valor máximo do período de alinhamento é 24 horas a menos que a ingestão atraso 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, para ter uma política de alertas mais responsiva, defina a janela de novo teste como zero. Um único valor alinhado faz com que esses tipos de que precisam ser atendidas.
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 se a política de alertas tiver várias condições, será preciso especificar quando 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 do
Estrutura do 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:
| 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 é aberto se cada é atendida, mesmo que um o recurso different faz 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 o uso da CPU de qualquer instância é maior que 60% por 1 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 de 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, o que também resulta 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 têm atraso, O Monitoring classifica os dados como ausentes. A falta de dados pode 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" state. 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 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 Monitoring determina o valor de substituição para dados ausentes, use o campo Avaliação de dados ausentes definido na etapa Gatilho de condição. Esse campo fica desativado quando janela de teste novamente está definida como Sem novo teste.
A janela de novo teste é o campo chamado "duração" na API Cloud Monitoring.
Para configurar quanto tempo 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 no 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 "Avaliação de dados ausentes" campo |
Resumo | Detalhes |
|---|---|---|
| Dados ausentes vazios | Incidentes abertos permanecem abertos. 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 houver um incidente aberto para essa condição, o incidente permanece aberto. Quando um incidente está aberto e nenhum dado chegar, 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 as condições não sejam atendidas, a condição continua a não ser atendidos quando os dados pararem 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 houver um incidente aberto para essa condição, o incidente permanece 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 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 que são atendidas, a condição deixa de ser cumprida 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 atendidos quando os dados pararem de chegar. |
API
É possível configurar como o Monitoring avalia 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 Monitoring determina o valor de substituição para dados ausentes, use o
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:
| API Campo evaluationMissingData |
Resumo | Detalhes |
|---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED |
Incidentes abertos permanecem abertos. 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 houver um incidente aberto para essa condição, o incidente permanece aberto. Quando um incidente está aberto e nenhum dado chegar, 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 as condições não sejam atendidas, a condição continua a não ser atendidos quando os dados pararem de chegar. |
EVALUATION_MISSING_DATA_ACTIVE |
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 houver um incidente aberto para essa condição, o incidente permanece 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 um |
EVALUATION_MISSING_DATA_INACTIVE |
Os incidentes abertos foram fechados. Novos incidentes não são abertos. |
Para as condições que são atendidas, a condição deixa de ser cumprida 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 atendidos quando os dados pararem 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 mais longas para testar novamente nas suas condições. Como usar uma janela mais longa de novo teste 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 e monitoramento.
- métricas com base em registros, se a coleta de entradas de registro não atrasar.
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 canais de notificação. Você não pode restringir uma notificação a um canal específico ou a um subconjunto da sua canais.
Se você configurar notificações repetidas, faça o seguinte: a mesma notificação é reenviada e canais de notificação da política de alertas.
Você pode receber várias notificações exclusivas relacionadas a uma política de alertas quando seguintes são verdadeiros:
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ê receber dependem do valor do atributo multicondição da política de alertas gatilho:
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, enviar apenas uma notificação quando a política de alertas contiver várias conditions.
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 é adiada.
- O monitoramento atingiu o limite do número máximo de sobre possíveis incidentes.
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 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 as política foi ativada. As condições de uma política desativada podem ser atendidas imediatamente depois de retomar a política, mesmo com janelas grandes de novo teste.
Por exemplo, imagine que você tem uma política de alertas que monitora um e desative essa política. Na semana seguinte, o processo for desativada, e como a política de alertas está desativada, você não receberá notificações. Se você reiniciar o processo e ativar a política de alertas imediatamente, O Monitoring reconhece que o processo não esteve pronto para o nos últimos cinco minutos e abre 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 expirar.
Políticas de alertas adiadas
O monitoramento não envia notificações nem cria incidentes uma política de alertas adiada. Recomendamos adiar políticas de alertas quando você quiser impedir que uma política de alertas envie apenas por intervalos curtos. Por exemplo, antes de realizar em uma máquina virtual (VM), poderá criar um adiamento e adicionar ao critérios de adiamento das 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. Monitoramento pode abrir novos incidentes depois que o adiamento expirar. Para mais informações, consulte Suspender 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 todos os recursos podem 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. sendo atendidos.
Para evitar a sobrecarga do sistema, o número de incidentes que um único política podem ser abertas simultaneamente é limitado a 1.000.
Por exemplo, considere uma política que se aplica à Compute Engine 2000 instâncias, 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 de uma vez. Se o sistema de alertas tem vários canais de notificação, então esse limite se aplica a cada canal de notificação de modo independente.
Latência
Latência refere-se ao atraso entre o momento em que o Monitoring coleta uma métrica e quando o ponto de dados da métrica se torna visível como dados da 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 mais informações, consulte Latência dos dados de métricas.
Os seguintes eventos e configurações 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 visível por 60 segundos após a coleta; mas o atraso depende na 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, 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ó são atendidas quando uma condição é verdadeira durante todo o novo teste janela. Por exemplo, uma configuração de janela de novo teste de cinco minutos faz com que atrasos na notificação de pelo menos cinco minutos a partir do momento em que o evento ocorre pela primeira vez.
Tempo para a chegada da notificação: canais de notificação, como e-mail e SMS, pode haver latências de rede ou outras latências (não relacionadas à o que está sendo entregue), às vezes chegando aos 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.