Esta página foi traduzida pela API Cloud Translation.
Switch to English

Comportamento dos alertas

As políticas de alertas existem em ambientes dinâmicos e complexos. Portanto, usá-las de maneira eficaz requer uma compreensão de algumas das variáveis que podem afetar o comportamento delas. As métricas e os recursos monitorados por condições, as janelas de duração das condições e os canais de notificação podem ter, cada uma, um efeito.

Esta página fornece algumas informações adicionais para ajudar você a entender o comportamento das suas políticas de alertas.

O período de alinhamento e a 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. Por exemplo, se o período de alinhamento for cinco minutos, às 13h, o período de alinhamento conterá 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.

Para ilustrar o efeito do período de alinhamento em uma condição na política de alertas, considere uma condição 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. Por fim, suponha que a condição seja atendida quando o valor alinhado da série temporal for maior que dois por uma duração de três minutos e que a condição for avaliada a cada minuto.

A figura a seguir ilustra várias avaliações sequenciais da condição:

Figura ilustrando o efeito do período de alinhamento.

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 exibidos com pontos azuis. Os pontos mais antigos aparecem em cinza. Cada linha exibe o valor alinhado e se esse valor está acima do limite de dois. Para a linha rotulada start, o valor alinhado é calculado como 1, que está abaixo do limite. Na próxima avaliação, a soma das amostras no período de alinhamento será 2. Na terceira avaliação, a soma é 3 e é maior que o limite. O avaliador de condição também inicia o timer da janela de duração.

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. Se você estiver usando o Console do Google Cloud, o campo Para no painel Configuração corresponderá à janela de duração.

A figura anterior ilustra três avaliações da condição. Às start + 2m, o valor alinhado estava acima do limite. No entanto, a condição não foi atendida porque a janela de duração foi definida como três minutos. A figura a seguir ilustra os resultados para as próximas avaliações da condição:

Figura ilustrando o efeito da janela de duração.

Como ilustrado, mesmo que o valor alinhado esteja acima do limite às start + 2m, a condição não será atendida até que o valor alinhado esteja acima do limite por três minutos. Isso ocorre às start + 5m.

Para maior clareza, o exemplo anterior omitiu a possibilidade de combinar os pontos de dados alinhados de várias séries temporais em uma única medição. É a medida comparada ao limite para determinar se a condição é atendida.

Uma condição redefine sua janela de duração sempre que uma medida não satisfaz a condição. Esse comportamento é ilustrado no seguinte exemplo:

Exemplo: essa política especifica uma janela de duraçã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 duração afeta a avaliação da condição:

  1. A latência HTTP está abaixo de dois segundos.
  2. Nos próximos três minutos consecutivos, a latência HTTP está acima de dois segundos.
  3. Na próxima medição, a latência fica abaixo de dois segundos, de modo que a condição redefine a janela de duração.
  4. Nos próximos cinco minutos consecutivos, a latência HTTP fica acima de dois segundos, então, a condição é atendida e a política é acionada.

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.

Como selecionar o período de alinhamento e a janela de duração

As condições da política de alertas são avaliadas com uma frequência fixa. As escolhas feitas no período de alinhamento e na janela de duração não afetam a frequência de avaliação da condição.

A figura anterior ilustra que o período de alinhamento determina quantas amostras de dados são combinadas com o alinhador. Se você escolher um período longo, muitas amostras serão combinadas. Se você escolher um período curto, é possível que apenas um ponto de dados esteja no intervalo. Já a janela de duração especifica o quanto os valores alinhados precisam estar acima do limite antes que a condição seja atendida. Se a janela de duração for definida como 0, um único valor alinhado acima do limite significa que a condição foi atendida.

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 sua política de alertas tiver várias condições, especifique quando as condições individuais serão atendidas. Quando uma condição é atendida, isso resulta na criação de um evento e possivelmente na abertura de um incidente:

  • Se você estiver usando o Console do Google Cloud, use o campo Disparadores de política.
  • Se você estiver usando a API Cloud Monitoring, use o campo combiner.

Esta tabela lista as configurações no Console do Cloud, o valor equivalente na API Cloud Monitoring e uma descrição de cada configuração:

Valor de acionamento da política do Console do Google em nuvem
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 por pelo menos um recurso, 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 above 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 high monitora o uso da CPU das instâncias. Essa condição é atendida quando a utilização da CPU de qualquer instância está acima de 100 ms/s por um minuto.
  • A condição chamada Excessive utilization monitora a utilização da CPU das instâncias. Essa condição é atendida quando a utilização da CPU de qualquer instância está acima de 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. Isso faz com que a condição CPU usage is too high seja 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 utilization seja atendida.

    Como observação geral, se vm2 tiver causado a condição CPU usage is too high, isso também resultará na criação de um incidente. Isso ocorre porque a VM1 que faz a condição CPU usage is too high ser atendida e a vm2 que faz a condição CPU usage is too high ser 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 high seja atendido, enquanto a vm2 faz com que Excessive utilization seja atendido.

Políticas de alertas desativadas

É possível interromper e reiniciar temporariamente as políticas de alertas ao desativá-las e ativá-las. Por exemplo, se você tiver uma política de alertas que notifica quando um processo fica inativo por mais de cinco minutos, será possível desativá-la ao desligar o processo para realizar upgrade ou outra manutenção.

Desativar uma política de alerta evita que a política acione ou feche incidentes, mas isso não impede que o Cloud Monitoring avalie as condições da política e registre os resultados. Se você desativar uma política de alertas e quiser que os problemas abertos sejam colocados no estado fechado, silencie o incidente. Para informações sobre esse processo, consulte Como isolar incidentes.

Vamos supor que o processo monitorado fique inativo por 20 minutos para manutenção. Se você reiniciar o processo e reativar imediatamente a política de alertas, ele reconhecerá que o processo não estava ativo há 5 minutos e abrirá um incidente.

Quando uma política desativada é reativada, o Monitoring examina os valores de todas as condições na janela de duração mais recente, que pode incluir dados coletados antes, durante e depois do intervalo pausado. As políticas podem ser acionadas imediatamente após serem retomadas mesmo com grandes janelas de duração.

Dados de métricas parciais

Se estão faltando medições (por exemplo, se não há solicitações HTTP por alguns minutos), a política usa o último valor gravado para avaliar as condições.

Exemplo

  1. Uma condição especifica a latência HTTP de dois segundos ou mais durante cinco minutos consecutivos.
  2. Por três minutos consecutivos, a latência HTTP é de três segundos.
  3. Por dois minutos consecutivos, não há solicitações HTTP. Neste caso, uma condição leva adiante a última medição (três segundos) para esses dois minutos.
  4. Após um total de cinco minutos, a política é acionada, mas sem dados nos últimos dois minutos.

Com a perda ou o atraso nos dados de métricas, talvez não haja alerta de políticas e 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 duração, pode fazer com que as condições entrem em um estado "desconhecido". Quando os dados finalmente chegam, o Cloud 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.

Você pode minimizar esses problemas fazendo um dos seguintes procedimentos:

  • Entre em contato com seu fornecedor de nuvem de terceiros para ver se há uma maneira de reduzir a latência da coleta de métrica.
  • Use janelas de duração mais longas nas condições. Isso 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 Cloud Monitoring.
    • Métricas com base em registros, se a coleta de registros não estiver atrasada.

Para mais informações, consulte Visão geral do agente do Monitoring, Como usar métricas personalizadas e Métricas com base em registros.

Incidentes por política

Uma política de alertas pode ser aplicada a muitos recursos, e um problema que afeta todos os recursos pode acionar a política e abrir 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 5.000.

Por exemplo, se uma política se aplicar a 2.000 (ou 20.000) instâncias do Compute Engine, e cada instância fizer com que as condições de alerta sejam atendidas, somente 5.000 incidentes serão abertos. Todas as condições restantes que são atendidas são ignoradas até que alguns dos incidentes abertos para essa política sejam fechados.

Notificações por incidente

Uma notificação é enviada a cada série temporal que faz com que uma condição seja atendida. Configure uma política de alertas para também emitir uma notificação quando essa série temporal não fizer mais o que a condição seja atendida. Quando a condição não é mais atendida, o incidente é fechado.

Se uma política contiver várias condições, ela poderá enviar várias notificações, dependendo de como você configurar a política:

  • Se uma política for acionada somente quando todas as condições forem atendidas, a política enviará uma notificação somente quando um incidente for aberto pela primeira vez.

  • Se uma política for acionada quando qualquer condição for atendida, ela enviará uma notificação sempre que uma nova combinação de condições for atendida. Por exemplo:

    1. A Condição A é atendida, um incidente é aberto e uma notificação é enviada.
    2. O incidente ainda está aberto quando uma medição posterior atende tanto à condição A quanto à condição B. Nesse caso, o incidente permanece aberto, e outra notificação é enviada.

Por padrão, as notificações são enviadas quando uma política de alertas é acionada. Ou seja, quando um incidente é criado, uma notificação é enviada aos canais de notificação configurados.

Para receber uma notificação quando o incidente for aberto e quando ele estiver fechado, edite a política de alertas e, na seção de notificações, marque Notificar quando o incidente for encerrado.

Latência da notificação

A latência de notificação é o atraso a partir do momento em que um problema se inicia pela primeira vez até o momento em que uma política é acionada.

Os eventos e as configurações a seguir contribuem para a latência geral da notificação:

  • Atraso de coleta de métrica: o tempo que o Cloud Monitoring precisa para coletar valores de métrica. Para os valores do Google Cloud, isso é normalmente insignificante. Para as métricas do AWS CloudWatch, podem ser 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 e duração).

  • Janela de duração: a janela configurada para a condição. As condições só serão atendidas se uma condição for verdadeira ao longo da janela de duração. Por exemplo, se você especificar uma janela de cinco minutos, a notificação será atrasada pelo menos cinco minutos a partir da data 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