Nesta página, explicamos por que algumas políticas de alertas com condições baseadas na linguagem de consulta do Monitoring (MQL, na sigla em inglês) podem se comportar de maneira diferente do esperado e oferece possíveis soluções para essas situações.
Lacunas de dados
Você criou uma política de alertas com uma condição baseada em MQL, e os resultados da consulta MQL mostram uma lacuna inesperada nos dados informados.
As lacunas aparecem nos dados alinhados quando um cálculo resulta em um valor nulo em um determinado carimbo de data/hora. Por exemplo, a tabela de dados a seguir está relacionada a uma consulta com um período de 30 segundos:
Tabela A1
Carimbo de data/hora | Valor |
---|---|
00:00:00 | 1 |
00:00:30 | 2 |
00:01:30 | 3 |
00:02:00 | 4 |
Como você tem um período de 30 segundos, espera-se que você veja um carimbo de data/hora em 00:01:00. Lacunas como essa podem ocorrer por vários motivos.
Lacunas devido ao alinhamento
Janelas de alinhador muito estreitas podem causar lacunas de dados. Por exemplo, a tabela a seguir de dados brutos de métricas não alinhadas é gravada aproximadamente a cada 30 segundos.
Tabela B1
Carimbo de data/hora | Valor |
---|---|
00:00:01 | 1 |
00:00:28 | 2 |
00:01:01 | 3 |
00:01:32 | 4 |
Se você executar uma consulta que alinha seus dados em 00:02:00 usando uma operação
next_older(30s)
,
receberá a seguinte saída, que tem um intervalo de dados em 00:01:00:
Tabela B2
Carimbo de data/hora | Valor |
---|---|
00:00:30 | 2 |
00:00:28 | 3 |
00:01:01 | 4 |
Essa lacuna de dados ocorre porque nenhum ponto nos dados brutos está na janela de 30 segundos que termina em 00:01:00. Para evitar uma lacuna como essa, use uma janela maior.
Por exemplo, uma operação next_older(1m)
produz uma tabela sem lacunas de dados:
Tabela B3
Carimbo de data/hora | Valor |
---|---|
00:00:01 | 1 |
00:00:28 | 2 |
00:01:01 | 3 |
00:01:32 | 4 |
Em geral, se os dados forem gravados a cada S segundos, use uma janela de alinhamento maior que S. Dessa forma, você pode contabilizar a distribuição desigual de pontos de dados ao longo do tempo.
Lacunas devido a operações de tabela
Algumas operações de tabela podem produzir lacunas inesperadas. Por exemplo, a operação join
produz saída apenas em carimbos de data/hora que têm um valor em todas as tabelas de entrada.
Operações de tabela como join
podem produzir lacunas. Por exemplo, você mescla
as duas tabelas alinhadas a seguir:
Tabela C1
Carimbo de data/hora | Valor |
---|---|
00:00:30 | 2 |
00:01:30 | 3 |
00:02:00 | 4 |
Tabela C2
Carimbo de data/hora | Valor |
---|---|
00:00:30 | 4 |
00:01:00 | 3 |
00:01:30 | 2 |
00:02:00 | 1 |
Você receberá esta saída:
Tabela C3
Carimbo de data/hora | Valor A | Valor B |
---|---|---|
00:00:30 | 1 | 4 |
00:01:30 | 2 | 2 |
00:02:00 | 3 | 1 |
Esta tabela não tem valor em 00:01:00
devido à ausência de um valor em
00:01:00
na tabela C1.
Lacunas devido a valores ausentes
Algumas funções produzem lacunas quando a saída não pode ser convertida ou está indefinida. Por exemplo, você aplica value.string_to_int64
à seguinte
tabela de valores de string:
Tabela D1
Carimbo de data/hora | Valor |
---|---|
00:00:30 | "4" |
00:01:00 | "3" |
00:01:30 | "init" |
00:02:00 | "1" |
Sua tabela resultante contém uma lacuna em 00:01:30 porque o MQL
não pode converter 'init'
em um número inteiro:
Tabela D2
Carimbo de data/hora | Valor |
---|---|
00:00:30 | 4 |
00:01:00 | 3 |
00:01:30 | null |
00:02:00 | 1 |
Para evitar lacunas nos dados devido a valores inválidos ou ausentes, use as funções
has_value
ou or_else
para processar esses
valores.
has_value
retorna false
se o argumento é avaliado como nulo. Caso contrário, retornará true
. Por exemplo, se você aplicar value has_value(1 / val())
à Tabela D2, seus resultados não terão lacunas:
Tabela D3
Carimbo de data/hora | Valor |
---|---|
00:00:30 | true |
00:01:00 | true |
00:01:30 | false |
00:02:00 | true |
O alerta de limite é acionado quando o gráfico MQL mostra que o limite não foi ultrapassado
Você quer receber uma notificação se uma máquina virtual (VM) tiver grandes flutuações no
uso da CPU. Portanto, crie uma política de alertas que monitore
a métrica compute.googleapis.com/instance/cpu/utilization
. Você cria e configura a condição para gerar um incidente quando a utilização da CPU a cada seis horas for maior que um limite de 50%. Sua
condição usa a seguinte consulta:
fetch gce_instance | metric 'compute.googleapis.com/instance/cpu/utilization' | group_by 5m, [value_utilization_mean: mean(value.utilization)] | align delta_gauge(6h) | condition val() > 0.5
Você vai receber um alerta após 30 segundos. No entanto, o gráfico MQL mostra que o delta de utilização não foi maior que o limite.
As políticas de alertas têm uma janela de saída de 30 segundos. Esse período não pode ser substituído deixando-o indefinido ou definindo outro período na consulta. Por exemplo, as consultas a seguir ainda usam uma janela de saída de 30 segundos:
fetch gce_instance | metric 'compute.googleapis.com/instance/cpu/utilization' | group_by 5m, [value_utilization_mean: mean(value.utilization)] | align delta_gauge(6h) # period not 30 seconds | condition val() > 0.5
fetch gce_instance | metric 'compute.googleapis.com/instance/cpu/utilization' | group_by 5m, [value_utilization_mean: mean(value.utilization)] | align delta_gauge() # undefined period | condition val() > 0.5
O limite da métrica foi ultrapassado nos primeiros 30 segundos da avaliação. Por isso, o Cloud Monitoring enviou um alerta. Para evitar esse problema,
adicione | every 30s
ao final da consulta para verificar se a janela de saída
produz os resultados pretendidos. Exemplo:
fetch gce_instance | metric 'compute.googleapis.com/instance/cpu/utilization' | group_by 5m, [value_utilization_mean: mean(value.utilization)] | align delta_gauge() | every 30s # explicit 30 second output window | condition val() > 0.5
Erro: não foi possível salvar a política de alertas. A solicitação tem um argumento inválido.
Você criou uma política de alertas com uma condição baseada em MQL. Ao salvar a política de alertas, você recebe a seguinte mensagem de erro:
Error: Unable to save alerting policy. Request contains an invalid argument.
Algumas operações de tabela MQL, como group_by
, exigem que as entradas
sejam alinhadas. Se a consulta não alinhar as entradas, o MQL vai alinhar os dados automaticamente. No entanto, esse alinhamento automático às vezes resulta em argumentos inválidos.
Para evitar esse problema, se a consulta usar uma operação de tabela, verifique se inclui o alinhamento de dados. Para conferir uma lista de funções de alinhamento de dados, consulte a seção aligning na documentação de referência do MQL.
A linha de limite não aparece no gráfico MQL
Você criou uma política de alertas de limite de métrica com uma condição baseada em MQL. No entanto, ela não aparece no gráfico MQL.
O Cloud Monitoring desenha a linha de limite somente quando a consulta contém uma expressão booleana que compara dois valores, em que um é uma coluna e o outro é um literal. Por exemplo, a expressão a seguir traça uma linha de limite:
val() > 5'GBy'
No entanto, as expressões a seguir não traçam uma linha de limite:
val(0) > val(1) #one of the values must be a literal
5 > 4 #one of the values must be a column
val() #the expression must be a comparison