Le query PromQL in Google Cloud Managed Service per Prometheus vengono valutate parzialmente nel backend Monarch e ci sono alcune differenze note nei risultati delle query. Questo documento descrive le differenze.
A parte le differenze elencate in questo documento, la PromQL in Managed Service per Prometheus è alla pari con la PromQL disponibile in Prometheus versione 2.44.Le funzioni PromQL aggiunte dopo la versione 2.44 di Prometheus potrebbero non essere supportate.
Supporto di UTF-8
PromQL per Cloud Monitoring supporta le query UTF-8.
Se il nome della metrica Prometheus è composto solo da caratteri alfanumerici più i caratteri
_ o :
e se le chiavi delle etichette sono composte solo da caratteri alfanumerici più
il carattere _, puoi eseguire query utilizzando la sintassi PromQL tradizionale.
Ad esempio, una query valida potrebbe avere il seguente aspetto:
job:my_metric:sum{label_key="label_value"}.
Tuttavia, se il nome della metrica Prometheus utilizza caratteri speciali
ad eccezione dei caratteri _ o : oppure se le chiavi delle etichette utilizzano caratteri speciali
ad eccezione del carattere _, devi creare la query
in base alla specifica UTF-8 per PromQL.
I nomi delle metriche UTF-8 devono essere racchiusi tra virgolette e spostati tra le parentesi graffe. I nomi delle etichette devono essere racchiusi tra virgolette anche se contengono caratteri incompatibili con le versioni precedenti. Le seguenti query valide di esempio sono tutte equivalenti:
{"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"}
Corrispondenza in base ai nomi delle metriche
È supportata solo la corrispondenza esatta dei nomi delle metriche. Devi includere una corrispondenza esatta del nome della metrica nella query.
Consigliamo le seguenti soluzioni alternative per gli scenari comuni che utilizzano un matcher di espressioni regolari sull'etichetta __name__:
- Le configurazioni dell'adattatore Prometheus spesso utilizzano l'operatore
=~per la corrispondenza con più nomi di metriche. Per correggere questo utilizzo, espandi la configurazione in modo da utilizzare una norma separata per ogni metrica e assegna un nome esplicito a ciascuna metrica. In questo modo si evita anche di scalare automaticamente in base a metriche impreviste. - Le espressioni regolari vengono spesso utilizzate per rappresentare graficamente più metriche non dimensionali
nello stesso grafico. Ad esempio, se hai una metrica come
cpu_servicename_usage, puoi utilizzare un carattere jolly per rappresentare graficamente tutti i tuoi servizi insieme. L'utilizzo di metriche non dimensionali come questa è una pratica esplicitamente sconsigliata in Cloud Monitoring e porta a prestazioni delle query estremamente scarse. Per correggere questo utilizzo, sposta tutta la dimensionalità nelle etichette delle metriche anziché incorporare le dimensioni nel nome della metrica. - L'esecuzione di query su più metriche viene spesso utilizzata per vedere quali metriche sono disponibili per le query. Ti consigliamo invece di utilizzare la chiamata
/labels/__name__/valuesper scoprire le metriche. Puoi anche scoprire le metriche utilizzando la UI di Cloud Monitoring. - La corrispondenza di più metriche è utile per vedere quanti campioni sono stati sottoposti a scraping, importati e addebitati in base a ciascuna metrica. Cloud Monitoring fornisce queste informazioni nella pagina Gestione metriche. Puoi accedere a queste informazioni anche come dati delle metriche utilizzando la metrica Campioni importati o la metrica Campioni scritti dall'ID attribuzione.
Mancato aggiornamento
L'obsolescenza non è supportata nel backend di Monarch.
Calcolo di irate
Quando l'intervallo di ricerca della funzione irate
è inferiore alla dimensione del passo, aumentiamo l'intervallo fino alla dimensione del passo.
Monarch richiede questa modifica per garantire che nessuno dei dati di input
venga completamente ignorato nell'output. Questa differenza si applica anche ai calcoli di
rate.
Calcolo di rate e increase
Quando l'intervallo di ricerca della funzione rate
è inferiore alla dimensione del passo, aumentiamo l'intervallo fino alla dimensione del passo.
Monarch richiede questa modifica per garantire che nessuno dei dati di input
venga completamente ignorato nell'output. Questa differenza si applica anche ai calcoli di
irate.
Esistono differenze nei calcoli di interpolazione ed estrapolazione. Monarch utilizza un algoritmo di interpolazione diverso da Prometheus e questa differenza può portare a risultati leggermente diversi. Ad esempio, i campioni del contatore Monarch vengono archiviati con un intervallo di tempo anziché con il singolo timestamp utilizzato da Prometheus. Pertanto, i campioni del contatore in Monarch possono essere inclusi nel calcolo della velocità anche se il timestamp di Prometheus li escluderebbe. In genere, ciò comporta risultati più precisi, soprattutto quando si eseguono query all'inizio o alla fine della serie temporale sottostante.
Calcolo di histogram_quantile
Un calcolo histogram_quantile
PromQL su un istogramma senza campioni produce un valore NaN. Il calcolo del linguaggio di query interno non produce alcun valore; il punto al timestamp viene eliminato.
Le differenze nel calcolo della tariffa possono influire anche sull'input delle query histogram_quantile.
Funzioni specifiche per tipo su metriche con tipi diversi
Sebbene Prometheus upstream sia a tipizzazione debole, Monarch è a tipizzazione
forte. Ciò significa che l'esecuzione di funzioni specifiche per un singolo tipo su una metrica di tipo diverso (ad esempio, l'esecuzione di rate() su una metrica GAUGE o di histogram_quantile() su una metrica COUNTER o senza tipo) non funziona in Managed Service per Prometheus, anche se queste funzioni funzionano in Prometheus upstream.