As consultas PromQL no Google Cloud Managed Service for Prometheus são avaliadas parcialmente no back-end Monarch, e existem algumas diferenças conhecidas nos resultados das consultas. Este documento descreve as diferenças.
Além das diferenças indicadas neste documento, o PromQL no Managed Service for Prometheus está em paridade com o 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 suportadas.
Suporte de UTF-8
O PromQL para o Cloud Monitoring suporta consultas UTF-8.
Se o nome da métrica do Prometheus consistir apenas em carateres alfanuméricos mais os carateres _ ou :, e se as chaves de etiquetas consistirem apenas em carateres alfanuméricos mais o caráter _, pode consultar através da sintaxe PromQL tradicional.
Por exemplo, uma consulta válida pode ter o seguinte aspeto:
job:my_metric:sum{label_key="label_value"}.
No entanto, se o nome da métrica do Prometheus usar carateres especiais, exceto os carateres _ ou :, ou se as chaves de etiqueta usarem carateres especiais, exceto o carater _, tem de criar a consulta de acordo com a especificação UTF-8 para PromQL.
Os nomes de métricas UTF-8 têm de estar entre aspas e ser movidos para as chavetas. Os nomes das etiquetas também têm de estar entre aspas se contiverem carateres incompatíveis com versões anteriores. Os seguintes exemplos de consultas válidas são todos 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"}
Correspondência nos nomes das métricas
Apenas é suportada a correspondência exata nos nomes das métricas. Tem de 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 motor de correspondência de expressões regulares na etiqueta __name__:
- As configurações do adaptador do Prometheus usam frequentemente o operador
=~para fazer a correspondência com vários nomes de métricas. Para corrigir esta utilização, expanda a configuração para usar uma política separada para cada métrica e nomeie cada métrica explicitamente. Isto também impede que faça a escala automática acidentalmente em métricas inesperadas. - As expressões regulares são frequentemente usadas para representar graficamente várias métricas não dimensionais no mesmo gráfico. Por exemplo, se tiver uma métrica como
cpu_servicename_usage, pode usar um caráter universal para representar graficamente todos os seus serviços em conjunto. A utilização de métricas não dimensionais como esta é uma prática explicitamente má no Cloud Monitoring, e esta prática leva a um desempenho de consulta extremamente fraco. Para corrigir esta utilização, mova toda a dimensionalidade para etiquetas de métricas em vez de incorporar dimensões no nome da métrica. - A consulta de várias métricas é frequentemente usada para ver que métricas estão disponíveis para consulta. Em alternativa, recomendamos que use a chamada
/labels/__name__/valuespara descobrir métricas. Também pode descobrir métricas através da IU do Cloud Monitoring. - A correspondência de várias métricas é útil para ver quantas amostras foram extraídas, carregadas e cobradas por métrica. O Cloud Monitoring fornece-lhe estas informações na página Gestão de métricas. Também pode aceder a estas informações como dados de métricas através da métrica Samples Ingested ou da métrica Samples Written by Attribution ID.
Desatualização
A obsolescência não é suportada no back-end do Monarch.
Cálculo de irate
Quando a janela retrospetiva da função irate é inferior ao tamanho do passo, aumentamos a janela para o tamanho do passo.
O Monarch requer esta alteração para garantir que nenhum dos dados de entrada é completamente ignorado na saída. Esta diferença também se aplica aos cálculos de rate.
Cálculo de rate e increase
Quando a janela retrospetiva da função rate é inferior ao tamanho do passo, aumentamos a janela para o tamanho do passo.
O Monarch requer esta alteração para garantir que nenhum dos dados de entrada é completamente ignorado na saída. Esta diferença também se aplica aos cálculos de irate.
Existem diferenças nos cálculos de interpolação e extrapolação. O Monarch usa um algoritmo de interpolação diferente do Prometheus, e esta diferença pode originar resultados ligeiramente diferentes. Por exemplo, as amostras de contador do Monarch são armazenadas com um intervalo de tempo em vez da indicação de tempo única que o Prometheus usa. Por conseguinte, as amostras de contador no Monarch podem ser incluídas num cálculo da taxa, mesmo que a data/hora do Prometheus as exclua. Geralmente, isto resulta em resultados de taxas mais precisos, especialmente quando consulta dados no início ou no fim da série cronológica subjacente.
Cálculo de histogram_quantile
Um cálculo de PromQL histogram_quantile
num histograma sem amostras produz um valor NaN. O cálculo da linguagem de consulta interna não produz nenhum valor. Em alternativa, o ponto na data/hora é ignorado.
As diferenças de cálculo das tarifas também podem afetar a entrada de consultas histogram_quantile.
Funções específicas do tipo em métricas com tipos diferentes
Embora o Prometheus a montante seja fracamente tipado, o Monarch é fortemente tipado. Isto significa que a execução de funções específicas de um único tipo numa métrica de tipo diferente (por exemplo, a execução de rate() numa métrica GAUGE ou histogram_quantile() numa métrica COUNTER ou sem tipo) não funciona no serviço gerido para Prometheus, mesmo que estas funções funcionem no Prometheus a montante.