Las consultas de PromQL en Google Cloud Managed Service para Prometheus se evalúan de forma parcial en el backend de Monarch y existen algunas diferencias conocidas en los resultados de la consulta. En este documento, se describen las diferencias.
Aparte de las diferencias que se mencionan en este documento, PromQL en Managed Service para Prometheus está a la par de PromQL disponible en la versión 2.44 de Prometheus.Es posible que las funciones de PromQL agregadas después de la versión 2.44 de Prometheus no sean compatibles.
Compatibilidad con UTF-8
PromQL para Cloud Monitoring admite consultas en UTF-8.
Si el nombre de tu métrica de Prometheus solo consta de caracteres alfanuméricos más los caracteres _ o :, y si las claves de tus etiquetas solo constan de caracteres alfanuméricos más el carácter _, puedes realizar consultas con la sintaxis tradicional de PromQL.
Por ejemplo, una consulta válida podría verse así: job:my_metric:sum{label_key="label_value"}.
Sin embargo, si el nombre de la métrica de Prometheus usa caracteres especiales, excepto _ o :, o si las claves de etiquetas usan caracteres especiales, excepto _, debes crear la consulta según la especificación UTF-8 para PromQL.
Los nombres de métricas en UTF-8 deben estar entre comillas y dentro de los corchetes. Los nombres de etiquetas también deben estar entre comillas si contienen caracteres incompatibles con versiones anteriores. Los siguientes ejemplos de consultas válidas son 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"}
Coincidencias en nombres de métricas
Solo se admite la coincidencia exacta en los nombres de métricas. Debes incluir una coincidencia exacta del nombre de la métrica en tu consulta.
Recomendamos las siguientes soluciones alternativas para situaciones comunes que usan un comparador de expresiones regulares en la etiqueta __name__:
- Las configuraciones del adaptador de Prometheus suelen usar el operador
=~para hacer coincidir varios nombres de métricas. Para corregir este uso, expande la configuración para usar una política separada para cada métrica y nombra cada métrica de forma explícita. Esto también evita que se realice un ajuste de escala automático accidental en métricas inesperadas. - Las expresiones regulares se suelen usar para representar varias métricas no dimensionales en el mismo gráfico. Por ejemplo, si tienes una métrica como
cpu_servicename_usage, puedes usar un comodín para generar un gráfico de todos tus servicios juntos. Usar métricas no dimensionales como esta es una práctica explícitamente incorrecta en Cloud Monitoring, y esta práctica genera un rendimiento extremadamente bajo de las consultas. Para corregir este uso, traslada toda la dimensionalidad a las etiquetas de métricas en lugar de incorporar dimensiones en el nombre de la métrica. - Las consultas sobre varias métricas se suelen usar para ver qué métricas están disponibles para la consulta. En su lugar, te recomendamos que uses la llamada
/labels/__name__/valuespara descubrir métricas. También puedes descubrir métricas con la IU de Cloud Monitoring. - La correlación de varias métricas es útil para ver cuántas muestras se recuperaron, transfirieron y cobraron por métrica. Cloud Monitoring te proporciona esta información en la página Administración de métricas. También puedes acceder a esta información como datos de métricas con la métrica Samples Ingested o la métrica Samples Written by Attribution ID.
Inactivo
La inactividad no es compatible con el backend de Monarch.
Cálculo de irate
Cuando el período de visualización de la función irate es menor que el tamaño del paso, aumentamos la ventana al tamaño del paso.
Monarch requiere este cambio para garantizar que ninguno de los datos de entrada se ignore por completo en el resultado. Esta diferencia también se aplica a los cálculos de rate.
Cálculo de rate y increase
Cuando el período de visualización de la función rate es menor que el tamaño del paso, aumentamos la ventana al tamaño del paso.
Monarch requiere este cambio para garantizar que ninguno de los datos de entrada se ignore por completo en el resultado. Esta diferencia también se aplica a los cálculos de irate.
Existen diferencias en los cálculos de interpolación y extrapolación. Monarch usa un algoritmo de interpolación diferente al de Prometheus, y esta diferencia puede generar resultados un poco diferentes. Por ejemplo, los ejemplos de contador Monarch se almacenan con un intervalo de tiempo en lugar de la marca de tiempo única que usa Prometheus. Por lo tanto, las muestras de contadores en Monarc se pueden incluir en un cálculo de frecuencia aunque la marca de tiempo de Prometheus las excluya. Por lo general, esto da como resultado resultados más precisos, en especial cuando se consulta el principio o el final de las series temporales subyacentes.
Cálculo de histogram_quantile
Un cálculo de histogram_quantile de PromQL en un histograma sin muestras produce un valor de NaN. El cálculo del lenguaje de consulta interno no produce ningún valor, sino que se descarta el punto en la marca de tiempo.
Las diferencias de cálculo de frecuencia también pueden afectar la entrada a las consultas histogram_quantile.
Funciones de tipo específico en métricas de tipado diferente
Aunque Prometheus upstream es de tipado débil, Monarch es de tipado fuerte. Esto significa que la ejecución de funciones específicas de un solo tipo en una métrica de tipado diferente (por ejemplo, ejecutar rate() en una métrica GAUGE o histogram_quantile() en una métrica COUNTER o sin tipado) no funciona en Managed Service para Prometheus, aunque estas funciones funcionan en Prometheus upstream.