As consultas da PromQL no Google Cloud Managed Service para Prometheus são parcialmente avaliadas no back-end do Monarch, e há algumas diferenças conhecidas nos resultados da consulta. Veja neste documento as diferenças.
Além das diferenças listadas neste documento, o PromQL no serviço gerenciado para Prometheus é igual ao PromQL disponível na versão 2.44 do Prometheus.As funções PromQL adicionadas após a versão 2.44 do Prometheus podem não ser compatíveis.
Compatibilidade com UTF-8
O PromQL para Cloud Monitoring é compatível com consultas UTF-8.
Se o nome da métrica do Prometheus consistir apenas em caracteres alfanuméricos mais os caracteres _ ou :, e se as chaves de rótulo consistirem apenas em caracteres alfanuméricos mais o caractere _, você poderá consultar usando a sintaxe tradicional do PromQL.
Por exemplo, uma consulta válida pode ser assim: job:my_metric:sum{label_key="label_value"}.
No entanto, se o nome da métrica do Prometheus usar caracteres especiais, exceto _ ou :, ou se as chaves de rótulo usarem caracteres especiais, exceto _, você precisará criar a consulta de acordo com a especificação UTF-8 para PromQL.
Os nomes de métricas UTF-8 precisam ser colocados entre aspas e chaves. Os nomes de rótulos também precisam ser colocados entre aspas se contiverem caracteres incompatíveis com versões legadas. Os exemplos de consultas válidas a seguir são equivalentes:
{"my.domain.com/metric/name_bucket", "label.key"="label.value"}{__name__="my.domain.com/metric/name_bucket", "label.key"="label.value"}{"__name__"="my.domain.com/metric/name_bucket", "label.key"="label.value"}
Como corresponder com nomes de métricas
Só é possível fazer a correspondência exata com nomes de métricas. Você precisa incluir uma correspondência exata no nome da métrica na sua consulta.
Recomendamos as seguintes soluções alternativas para cenários comuns que usam um
comparador de expressões regulares no marcador __name__:
- As configurações do adaptador do Prometheus geralmente usam o operador
=~para corresponder a vários nomes de métricas. Para corrigir esse uso, expanda a configuração para usar uma política separada para cada métrica e nomeie cada uma explicitamente. Isso também evita que você faça o escalonamento automático acidentalmente em métricas inesperadas. - As expressões regulares são usadas com frequência para representar graficamente várias métricas sem dimensão no mesmo gráfico. Por exemplo, se você tiver uma métrica como
cpu_servicename_usage, poderá usar um curinga para representar todos os serviços juntos. Usar métricas não dimensionais como essa é uma prática explicitamente ruim no Cloud Monitoring, e isso leva a um desempenho de consulta extremamente ruim. Para corrigir esse uso, mova toda a dimensionalidade para rótulos de métricas em vez de incorporar dimensões no nome da métrica. - A consulta em várias métricas é usada com frequência para ver quais métricas estão disponíveis. Recomendamos que você use a chamada
/labels/__name__/valuespara descobrir métricas. Você também pode descobrir métricas usando a interface do Cloud Monitoring. - A correspondência de várias métricas é útil para saber quantas amostras foram coletadas, ingeridas e cobradas por métrica. O Cloud Monitoring fornece essas informações na página Gerenciamento de métricas. Também é possível acessar essas informações como dados de métrica usando a métrica "Exemplos ingeridos" ou "Exemplos gravados por ID de atribuição".
Inatividade
A inatividade não é compatível com o back-end do Monarch.
Cálculo de irate
Quando a janela de lookback da função irate
é menor que o tamanho da etapa, aumentamos a janela para o tamanho da etapa.
O Monarch requer essa mudança para garantir que nenhum dos dados de entrada seja completamente ignorado na saída. Essa diferença também se aplica a cálculos rate.
Cálculo de rate e increase
Quando a janela de lookback da função rate
é menor que o tamanho da etapa, aumentamos a janela para o tamanho da etapa.
O Monarch exige essa mudança para garantir que nenhum dos dados de entrada seja completamente ignorado na saída. Essa diferença também se aplica a cálculos irate.
Há diferenças nos cálculos de interpolação e extrapolação. O Monarch usa um algoritmo de interpolação diferente do Prometheus, e essa diferença pode levar a resultados um pouco diferentes. Por exemplo, as amostras do contador Monarch são armazenadas com um intervalo de tempo em vez do único carimbo de data/hora usado pelo Prometheus. Portanto, as amostras de contador no Monarch podem ser incluídas em um cálculo de taxa, mesmo que o carimbo de data/hora do Prometheus as exclua. Isso normalmente gera resultados de taxa mais precisos, especialmente ao consultar o início ou o fim da série temporal subjacente.
Cálculo de histogram_quantile
Um cálculo histogram_quantile do PromQL em um histograma sem amostras produz um valor NaN. O cálculo da linguagem de consulta interna não produz valor. Em vez disso, o ponto no carimbo de data/hora é descartado.
As diferenças de cálculo de taxa também podem afetar a entrada em consultas histogram_quantile.
Funções específicas de tipo em métricas de tipos diferentes
Embora o Prometheus upstream seja do tipo fraco, o Monarch tem uma classificação forte. Isso significa que a execução de funções específicas para um único tipo em uma métrica de tipo diferente (por exemplo, executar rate() em uma métrica do GAUGE ou histogram_quantile() em uma métrica de COUNTER ou sem tipo) não funciona no Managed Service para Prometheus, mesmo que essas funções funcionem no Prometheus upstream.