Detalhes sobre as políticas de alertas

Nesta página, você encontra uma visão geral detalhada dos conceitos das políticas de alertas. Ao entender esse material, você usará as políticas de alertas com eficácia.

Para ver informações sobre como criar e gerenciar políticas de alertas, consulte:

Políticas

A política de alertas define condições em que um serviço é considerado não íntegro. Quando as condições são atendidas, a política é acionada e um novo incidente é aberto. Essa política também enviará notificações se você a tiver configurado para isso.

Uma política pertence a um espaço de trabalho individual, e cada espaço de trabalho pode conter até 500 políticas.

Condições

A condição determina quando uma política de alertas é acionada. Para descrever uma condição, você especifica:

  • uma métrica para medir;
  • um teste para determinar quando essa métrica atingirá um estado que você quer verificar.

Dependendo do que você quer monitorar, é possível criar uma condição relacionada ao seguinte:

Tipos de condições

As condições se baseiam em métricas. Elas monitoram, por exemplo, se uma métrica alcança um valor ou começa a mudar rapidamente. As métricas são associadas a recursos e medem alguma característica deles. Isso inclui o uso médio da CPU em um grupo de VMs. Para ver mais informações sobre métricas, consulte Métricas, séries temporais e recursos.

Todas as condições levam em conta três fatores: algumas métricas que se comportam de um jeito determinado por um período.

Todas as condições são implementadas como um destes dois tipos gerais:

  • Uma condição de ausência de métrica, que é acionada quando qualquer série temporal da métrica não tem dados para uma janela de duração específica.

    As condições de ausência de métrica exigem pelo menos uma medição bem-sucedida, uma que recupere dados, desde que a política tenha sido instalada ou dentro da janela de duração máxima de 24 horas.

    Por exemplo, vamos supor que você defina a janela de duração em uma política de ausência de métrica como 30 minutos. A condição não será atendida se o subsistema que grava dados de métrica nunca tiver gravado um ponto de dados. O subsistema precisará produzir pelo menos um ponto de dados e, em seguida, deixar de produzir pontos de dados adicionais por 30 minutos.

  • A condição de limite de métrica, que é acionada quando uma métrica fica acima ou abaixo de um valor de uma janela de duração específica.

    Dentro da classe dessas condições, há padrões que se enquadram em subcategorias gerais:

    • Taxa (porcentagem) de mudança de métrica: acionada se uma métrica aumentar ou diminuir em pelo menos um percentual específico ou mais em uma janela de duração.

      Nesse tipo de condição, um cálculo de porcentagem de mudança é aplicado à série temporal antes da comparação com o limite.

      A condição faz uma média dos valores da métrica nos últimos 10 minutos e, em seguida, compara o resultado com a média de 10 minutos que foi medida logo antes da janela de duração. A janela de lookback de 10 minutos usada por uma taxa de métrica de condição de mudança é um valor fixo: não é possível alterá-lo. No entanto, você especifica a janela de duração ao criar a condição.

    • Limite de agregação de grupo: acionado se uma métrica medida em um grupo de recursos ultrapassar um limite.

    • Integridade da verificação de tempo de atividade: acionada se você tiver criado uma verificação de tempo de atividade, e o recurso deixar de responder a uma solicitação enviada de pelo menos dois locais geográficos.

      Os resultados das verificações de tempo de atividade são exibidos somente na página de visão geral delas no console do Stackdriver Monitoring. Ao criar uma política de alertas em uma verificação de tempo de atividade, você pode ter verificações que abram incidentes indiretamente e, como opção, enviem notificações quando eles falharem.

    • Integridade do processo: acionada se o número de processos (1) em execução em uma instância de VM ou grupo de instâncias e (2) que corresponda a alguma string ficarem acima ou abaixo de um número específico no decorrer de uma janela de duração.

      Esse tipo de condição requer que o agente do Monitoring esteja em execução nos recursos monitorados.

Veja exemplos de cada um desses tipos:

Tipo de condição Exemplo de IU Exemplo de JSON
Ausência de métrica Ver Ver
Limite de métrica Ver Ver
Taxa de mudança Ver Ver
Agregação de grupo Ver Ver
Verificação de tempo de atividade Ver Ver
Integridade do processo Ver Ver

Como combinar condições

Uma política pode conter até seis condições. Se você estiver usando várias delas, há três opções para especificar as combinações que violam uma política:

  • OR: qualquer condição é atendida.
  • AND: cada condição é violada por pelo menos um recurso, mesmo se um recurso diferente violar todas elas.
  • AND_WITH_RESOURCES: todas as condições são violadas pelo mesmo recurso. Essa opção está disponível apenas para condições criadas com a API.

Janela de duração

A condição inclui uma janela de duração, que é o período de tempo que uma condição precisa avaliar como verdadeiro antes do acionamento. As janelas de duração nas condições evitam que a política de alertas tenha reações exageradas. É necessário reduzir os falsos positivos, porque uma política de alertas que envia notificações constantes acabará sendo ignorada.

Como regra geral, quanto mais alta a disponibilidade do serviço ou maior a penalidade por não detectar problemas, mais curta será a janela de duração especificada.

Devido às flutuações normais no desempenho, não é aconselhável que uma política seja acionada se uma única medição corresponder a uma condição. Em vez disso, é necessário que várias medições consecutivas atendam a uma condição antes de considerar que o aplicativo está com estado não íntegro.

Sempre que uma medição não satisfizer a condição, ela reiniciará a respectiva janela de duração.

Exemplo

A condição a seguir especifica uma janela de duração de cinco minutos:
latência HTTP acima de dois segundos por cinco minutos consecutivos.

A sequência a seguir ilustra como a janela de duração afeta a avaliação da condição:

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

As janelas de duração precisam ser longas o suficiente para reduzir falsos positivos, mas curtas o bastante para garantir que os incidentes sejam abertos na hora certa.

Comportamento da política

As políticas de alerta estão presentes em ambientes dinâmicos e complexos. Portanto, usá-las corretamente requer um entendimento de algumas das variáveis que podem afetar o comportamento delas. As métricas e recursos monitorados pelas condições, as janelas de duração delas e os canais de notificação podem ser afetados individualmente.

Nesta seção, você encontra algumas informações adicionais para entender o comportamento das políticas de alertas.

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 alertas impede o acionamento ou a resolução de incidentes. No entanto, isso não evita que o Stackdriver avalie as condições da política e registre os resultados.

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

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

Incidentes anômalos

Talvez as políticas de alertas apareçam na página Alerta > Incidentes como acionadas incorretamente ou antes da hora, principalmente as com condições de ausência de métrica ou de limite máximo.

Isso ocorre quando há uma lacuna nos dados, mas nem sempre é fácil identificá-la. Às vezes, a lacuna está oculta e, em outras, foi corrigida.

Por exemplo, nos gráficos, as lacunas nos dados são interpoladas. É possível que vários minutos de dados estejam faltando, mas o gráfico conecta pontos ausentes pela proximidade visual. Uma lacuna desse tipo nos dados subjacentes é suficiente para acionar uma política de alertas.

É possível que os pontos nas métricas com base em registros cheguem atrasados e sejam preenchidos em até 10 minutos no passado. Isso corrige a lacuna efetivamente. Ela é preenchida quando os dados chegam. Assim, uma lacuna em uma métrica baseada em registros que não pode mais ser vista pode causar o acionamento de uma política de alertas.

As condições de ausência de métrica e de limite máximo são avaliadas em tempo real, com um pequeno atraso na consulta. O status da condição pode mudar entre o horário em que é avaliada e o horário em que o respectivo incidente fica visível no console do Stackdriver Monitoring.

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 levaria adiante a última medição (três segundos) para esses dois minutos.
  4. Após um total de cinco minutos, a política é acionada, apesar de não ter havido 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 chegarem, o Stackdriver Monitoring poderá ter perdido um pouco 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.

É possível minimizar esses problemas realizando 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 dados diretamente no Stackdriver Monitoring.
    • Métricas com base em registros, se a coleta de registros não estiver atrasada.

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

Notificações por incidente

O número de notificações enviadas por incidente varia de acordo com as condições da política.

Se uma política tiver apenas uma condição, uma única notificação será enviada quando o incidente for aberto inicialmente, mesmo que as medições posteriores continuem a atender à condição.

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, ela enviará uma notificação somente quando o incidente for aberto inicialmente.

  • 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.

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étricas: o tempo que o Stackdriver Monitoring precisa para coletar valores de métricas. Para valores do GCP, geralmente é insignificante. Para as métricas do AWS CloudWatch, podem ser vários minutos. Para verificações de tempo de atividade, pode ser uma média de 4 minutos até um máximo de 5 minutos e 30 segundos (a partir do fim da janela de duração).

  • Janela de duração: a janela configurada para a condição. Observe que 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 por pelo menos cinco minutos a partir da primeira ocorrência do evento.

  • Tempo para a chegada da notificação: os canais de notificação, como e-mail e SMS, podem enfrentar latências de rede ou 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.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Stackdriver Monitoring
Precisa de ajuda? Acesse nossa página de suporte.