Práticas recomendadas para políticas de alertas MQL

Nesta página, você encontra um índice de práticas recomendadas para políticas de alertas com uma condição baseada na linguagem de consulta do Monitoring (MQL, na sigla em inglês). Use as informações coletadas aqui como uma referência rápida do que ter em mente ao configurar uma política de alertas com uma condição baseada em MQL.

Esta página não descreve os conceitos básicos de como usar consultas MQL nas políticas de alertas. Se você é um novo usuário, consulte Políticas de alertas com MQL.

Operações recomendadas para consultas MQL em políticas de alertas

A avaliação da política de alertas envolve vários serviços internos. Devido à forma como esses serviços interagem com o MQL, recomendamos o uso de determinadas operações MQL em vez de outras. Por exemplo, se você usar delta em vez de delta_gauge, os alertas poderão ser acionados em horários incorretos.

A tabela a seguir mostra uma lista das operações que devem ser evitadas e das recomendadas.

O que você não deve fazer	Recomendações
adjacent_rate	rate
adjacent_delta	delta_gauge
delta	delta_gauge
window	sliding

Usar a instrução every 30s com políticas de alertas

As políticas de alertas avaliam a condição a cada 30 segundos. Esse intervalo de tempo é chamado de janela de saída. Recomendamos que suas condições incluam uma operação every 30s explícita como um lembrete visual desse período.

Por exemplo, a seguinte consulta MQL de política de alertas inclui uma instrução every 30s explícita:

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| group_by sliding(1h)
| every 30s

Se você salvar uma política de alertas com uma consulta MQL que usa um valor diferente para a operação every, o Cloud Monitoring ainda vai usar um valor de 30 segundos quando a política de alertas estiver ativa. Por exemplo, uma política de alertas com a consulta a seguir ainda tem uma janela de saída de 30 segundos:

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| group_by sliding(1h)
| every 90s

Melhorar a eficiência da consulta

As consultas são executadas lentamente ao processar grandes volumes de dados. Para melhorar a eficiência da consulta, tente reduzir a quantidade de dados que ela processa. As seções a seguir fornecem várias opções para reduzir o volume de dados avaliado pela sua consulta.

Inclua filtros antes na consulta

Quando você coloca filtros anteriormente na consulta, eles podem filtrar dados desnecessários antes que a consulta execute operações nos dados. Por exemplo, considere a seguinte consulta:

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| group_by [resource.zone], .sum
| filter zone = 'us-west1-b'
| condition val() > 5'GBy'

A consulta poderá ser executada mais rapidamente se você mover a operação filter antes da operação group_by:

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| filter zone = 'us-west1-b'
| group_by [resource.zone], .sum
| condition val() > 5'GBy'

Diminuir a janela de alinhamento da consulta

Quando uma consulta usa a operação align, uma janela de alinhamento menor representa um intervalo de tempo menor que o Cloud Monitoring avalia para cada ponto da série temporal. Como resultado, tente melhorar a eficiência da consulta reduzindo o valor da operação align. Por exemplo, a consulta a seguir tem uma janela de alinhamento de duas horas:

fetch gce_instance :: compute.googleapis.com/instance/disk/read_bytes_count
| group_by window(1h), .sum
| align next_older(2h)
| every 30s
| condition val() > 2'GBy'

No entanto, se você precisar ver os dados de apenas uma janela de uma hora, poderá reduzir a janela de alinhamento para uma hora:

fetch gce_instance :: compute.googleapis.com/instance/disk/read_bytes_count
| group_by window(1h), .sum
| align next_older(1h)
| every 30s
| condition val() > 2'GBy'

Para mais informações, consulte Alinhamento.

Diminuir a janela de duração da política de alertas

A janela de duração da política de alertas representa o período em que cada medida precisa violar a condição antes do envio de um alerta. Se você reduzir a janela de duração da política de alertas sem aumentar a janela de alinhamento da consulta, o Cloud Monitoring terá menos pontos para avaliar a condição da política de alertas.

Para mais informações, consulte a Janela de duração.

Atribuir valores padrão a metadados nulos

Se um valor de metadados for nulo, as consultas poderão produzir resultados inesperados. Evite resultados inesperados usando a função or_else para atribuir um valor padrão aos metadados que, de outra forma, teriam um valor nulo.

Por exemplo, você executa uma consulta que agrega todos os dados juntos:

fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count
| group_by [], 24h, sum(egress_bytes_count)
| condition val() > 10'MBy'

A consulta produz um resultado de 10 MBy. Em seguida, execute uma consulta para verificar como os 10 MBy são distribuídos entre as zonas do nó:

fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count
| group_by [metadata.system.node_zone], 24h, sum(egress_bytes_count)
| condition val() > 10'MBy'

A consulta de distribuição retorna os seguintes resultados:

node_zone	egress_byte_count
us-central1-f	7,3 MBy
us-west1-b	2,5 MBy

Esses resultados mostram um total de 9,8 MBy em vez dos 10 MB esperados. Essa discrepância poderá ocorrer se um dos rótulos de metadados agregados tiver um valor nulo, como no seguinte conjunto de dados:

valor	valor de metadados
7,3 MBy	us-central1-f
2,5 MBy	us-west1-b
0,2 MBy

Para evitar problemas de metadados nulos, é possível unir sua referência de metadados em uma operação or_else, que permite especificar um valor padrão caso uma coluna de metadados não tenha valor. Por exemplo, a consulta a seguir usa or_else para definir um valor de metadados de no zone para todas as colunas de metadados sem um valor:

fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count
| group_by [or_else(metadata.system.node_zone, 'no zone')], 24h, sum(egress_bytes_count)
| condition val() > 10'MBy'

Essa nova consulta produz os seguintes resultados, que somam 10 MBy:

node_zone	egress_byte_count
us-central1-f	7,3 MBy
us-west1-b	2,5 MBy
nenhuma zona	0,2 MBy