Políticas de alertas com MQL

É possível criar políticas de alertas do Monitoring com uma condição que inclui uma consulta na linguagem de consulta do Monitoring (MQL, na sigla em inglês). As consultas do MQL para condições da política de alertas são como outras consultas do MQL, mas também incluem uma operação de alerta do MQL. Se você usar o MQL em uma condição, ela precisará ser a única na política.

Nesta página, apresentamos as operações de alertas do MQL e descrevemos como criar uma política de alertas que as usa. Para informações gerais sobre políticas de alertas do Monitoring, consulte Comportamento de políticas de alertas com base em métricas.

Começar

Todas as consultas MQL começam com os seguintes componentes:

  • Uma operação fetch, que recupera série temporal do Cloud Monitoring.
  • Um argumento, que consiste em um recurso monitorado e um tipo de métrica, que identifica a série temporal a ser buscada.

Por exemplo, a consulta a seguir recupera a série temporal escrita pelas instâncias do Compute Engine para o tipo de métrica compute.googleapis.com/instance/cpu/utilization, que registra a utilização da CPU dessas instâncias:

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization

O argumento do comando fetch consiste em um tipo de recurso monitorado gce_instance, um par de caracteres de dois-pontos, ::, e um tipo de métrica, compute.googleapis.com/instance/cpu/utilization.

Para usar sua consulta em uma política de alertas com uma condição baseada em MQL, a consulta precisa terminar com uma operação que defina os parâmetros sob os quais o Cloud Monitoring aciona um alerta. A operação varia se você estiver criando uma política de alertas de limite de métrica ou de ausência de métrica.

Consultas MQL para políticas de alertas de limite de métrica

As consultas MQL com limite de métrica exigem a operação condition, que avalia uma expressão booleana em cada ponto do ambiente de execução da consulta. Se a expressão for avaliada como true para todos os pontos na janela de duração, o Cloud Monitoring vai acionar um alerta.

Por exemplo, a consulta a seguir avalia as instâncias de VM do Compute Engine e aciona um alerta caso alguma instância tenha gravado mais de 5 gigabytes no disco nas últimas 24 horas:

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| group_by 24h, .sum
| every 30s
| condition val() > 5'GBy'

Você pode usar condições complexas para avaliar intervalos específicos de dados. Por exemplo, a condição a seguir acionará um alerta se uma instância de VM nas últimas 24 horas gravou mais de 5 gigabytes e menos de 6 gigabytes de dados ou mais de 8 gigabytes de dados:

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| group_by 24h, .sum
| every 30s
| condition (val() > 5'GBy' && val() < 6'GBy') || val() > 8'GBy'

O exemplo a seguir usa filter, uma operação deslizante group_by, e uma condição complexa para avaliar cada ponto de dados em uma tabela de entrada alinhada e determinar se o valor de utilização excede o valor limite de 15%:

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
| filter zone =~ 'us-central.*'
| group_by sliding(5m), mean(val())
| every 30s
| condition val() > .15 '10^2.%'

Na consulta anterior, a tabela resultante do operador condition tem duas colunas de valor, uma booleana que registra o resultado da avaliação de limite e uma segunda contendo uma cópia da coluna de valores utilization da tabela de entrada. Como a configuração de janela group_by padrão está deslizando, a expressão group_by é idêntica a group_by 5m, mean(val()).

O valor de utilização da CPU é armazenado como utilização fracionária; os valores variam de 0,0 a 1,0. O descritor de métrica especifica a unidade do valor como 10^2.%, que o gráfico exibe como porcentagem. As unidades do limite precisam ser compatíveis, por isso, expressamos o limite como .15 '10^2.%.

Consultas MQL para políticas de alertas de ausência de métrica

As consultas MQL de ausência de métrica usam a operação absent_for, que leva uma duração em que os dados precisam estar ausentes. Por exemplo, a consulta a seguir testa se faltam dados nas zonas centrais dos EUA por oito horas:

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
| filter zone =~ 'us-central.*'
| every 30s
| absent_for 8h

A operação absent_for leva apenas um argumento de duração que indica por quanto tempo os dados precisam ficar ausentes para satisfazer a condição.

Os dados são considerados ausentes se os dados apareceram no último período de 24 horas, mas não na duração, neste exemplo, as oito horas mais recentes.

Uma consulta absent_for cria uma tabela de saída com valores alinhados usando o alinhamento padrão ou uma operação every após a operação absent_for.

A tabela de saída tem duas colunas.

  • A primeira é a coluna active, que registra os resultados booleanos da ausência de dados. Um valor true significa que houve um ponto de entrada nas últimas 24 horas e nenhum no período de duração.

  • A segunda coluna é a signal. Se a tabela de entrada tiver colunas de valor, a coluna signal conterá o valor da primeira coluna de valor do ponto de entrada mais recente. Se a tabela de entrada não tiver colunas de valor, a coluna signal conterá o número de minutos desde o último ponto de entrada registrado. É possível forçar esse caso, conforme mostrado no exemplo a seguir:

    fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
    | filter zone =~ 'us-central.*'
    | value []
    | every 30s
    | absent_for 8h
    

    No exemplo anterior, a operação value [] remove as colunas de valor da tabela de entrada, de modo que a coluna signal na tabela criada pela operação absent_for contém o número de minutos desde o último ponto de entrada gravado.

Configuração da política de alertas

Além da consulta MQL, uma condição de política de alertas inclui dois outros valores:

  • O número de séries temporais de entrada que precisam atender à condição. O valor pode ser qualquer um destes:
    • Uma única série temporal.
    • Um número específico de séries temporais.
    • Uma porcentagem de séries temporais.
    • Todas as séries temporais.
  • Duração do estado do alerta, ou seja, por quanto tempo a condição de alerta precisa ser avaliada continuamente como true.

Se a consulta for avaliada continuamente para true pela duração especificada de uma determinada série temporal, ela será considerada ativa. Quando o número especificado de séries temporais estiver ativo, a política de alertas será acionada e um alerta será gerado para cada série temporal ativa. Para mais informações sobre como as políticas de alertas são avaliadas, consulte Comportamento de políticas de alertas com base em métricas.

Quando os dados da série temporal param de chegar ou estão atrasados, o Monitoring os classifica como ausentes. Para informações sobre como configurar o Monitoring para avaliar as condições de limite de métrica quando os dados pararem de chegar, consulte Dados de métricas parciais.

Se você usar o MQL em uma condição, essa condição precisará ser a única condição na política. Não é possível usar várias condições em políticas de alertas baseadas em MQL.

Diretrizes

O MQL permite criar rótulos definidos pelo usuário e anexá-los a incidentes. Para exemplos, consulte Adicionar níveis de gravidade a uma política de alertas.

As unidades para tipos de métricas são listadas na tabela relevante de tipos de métricas; para o tipo de métrica compute.googleapis.com/instance/cpu/utilization, consulte a tabela compute.

A seguir

Para informações sobre como usar o console do Google Cloud e a API Cloud Monitoring para criar uma política de alertas com uma condição baseada em MQL, consulte Criar alertas MQL.

Para uma lista de diretrizes e recomendações para configurar políticas de alertas eficazes com uma condição baseada em MQL, consulte Práticas recomendadas para alertas MQL.

Para informações sobre como solucionar problemas comuns de políticas de alertas com uma condição baseada em MQL, consulte Resolver problemas de alertas do MQL.

Para conferir exemplos de políticas de alertas com uma condição baseada em MQL, consulte Casos de uso para alertas MQL.