Las consultas de PromQL en Google Cloud Managed Service para Prometheus se evalúan parcialmente en el backend de Monarch y hay algunas diferencias conocidas en los resultados de las consultas. En este documento se describen las diferencias.
Aparte de las diferencias que se indican en este documento, la versión de PromQL de Managed Service para Prometheus es igual a la de Prometheus 2.44.Es posible que no se admitan las funciones de PromQL añadidas después de la versión 2.44 de Prometheus.
Compatibilidad con UTF-8
PromQL para Cloud Monitoring admite consultas UTF-8.
Si el nombre de tu métrica de Prometheus solo contiene caracteres alfanuméricos más los caracteres _ o :, y si las claves de tus etiquetas solo contienen caracteres alfanuméricos más el carácter _, puedes hacer consultas con la sintaxis tradicional de PromQL.
Por ejemplo, una consulta válida podría ser la siguiente:
job:my_metric:sum{label_key="label_value"}.
Sin embargo, si el nombre de tu métrica de Prometheus usa caracteres especiales, excepto _ o :, o si tus claves de etiqueta usan caracteres especiales, excepto _, debes crear tu consulta de acuerdo con la especificación UTF-8 de PromQL.
Los nombres de métricas UTF-8 deben incluirse entre comillas y colocarse entre llaves. Los nombres de las etiquetas también deben incluirse entre comillas si contienen caracteres no compatibles con versiones anteriores. Las siguientes consultas válidas de ejemplo son 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"}
Coincidencia por nombre de métrica
Solo se admite la coincidencia exacta de nombres de métricas. Debe incluir una coincidencia exacta del nombre de la métrica en su consulta.
Te recomendamos las siguientes soluciones alternativas para los casos habituales en los que se usa un buscador de expresiones regulares en la etiqueta __name__:
- Las configuraciones del adaptador de Prometheus suelen usar el operador
=~para buscar coincidencias en varios nombres de métricas. Para corregir este uso, amplíe la configuración para usar una política independiente para cada métrica y asigne un nombre explícito a cada métrica. De esta forma, también se evita que se aplique el autoescalado por error en métricas inesperadas. - Las expresiones regulares se suelen usar para representar gráficamente varias métricas no dimensionales en el mismo gráfico. Por ejemplo, si tiene una métrica como
cpu_servicename_usage, puede usar un comodín para representar gráficamente todos sus servicios juntos. Usar métricas no dimensionales como esta es una práctica inadecuada en Cloud Monitoring, y lleva a un rendimiento de las consultas extremadamente bajo. Para corregir este uso, mueva toda la dimensionalidad a las etiquetas de métricas en lugar de insertar dimensiones en el nombre de la métrica. - Las consultas de varias métricas se suelen usar para ver qué métricas se pueden consultar. En su lugar, te recomendamos que uses la llamada
/labels/__name__/valuespara descubrir métricas. También puede descubrir métricas mediante la interfaz de Cloud Monitoring. - Asociar varias métricas es útil para ver cuántas muestras se han recogido, ingerido y cobrado por métrica. Cloud Monitoring te proporciona esta información en la página Gestión de métricas. También puede acceder a esta información como datos de métricas mediante la métrica Muestras ingeridas o la métrica Muestras escritas por ID de atribución.
Falta de actualización
La obsolescencia no se admite en el backend de Monarch.
Cálculo de irate
Si la ventana retrospectiva de la función irate es inferior al tamaño del paso, aumentamos la ventana hasta el tamaño del paso.
Monarch requiere este cambio para asegurarse de que no se ignore por completo ningún dato de entrada en la salida. Esta diferencia también se aplica a los cálculos de rate.
Cálculo de rate y increase
Si la ventana retrospectiva de la función rate es inferior al tamaño del paso, aumentamos la ventana hasta el tamaño del paso.
Monarch requiere este cambio para asegurarse de que no se ignore por completo ningún dato de entrada en la salida. Esta diferencia también se aplica a los cálculos de irate.
Hay 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 dar lugar a resultados ligeramente distintos. Por ejemplo, las muestras de contador de Monarch se almacenan con un intervalo de tiempo en lugar de con la única marca de tiempo que usa Prometheus. Por lo tanto, las muestras de contador de Monarch se pueden incluir en un cálculo de la tasa, aunque la marca de tiempo de Prometheus las excluya. Por lo general, esto da como resultado tasas más precisas, sobre todo cuando se consulta el principio o el final de la serie temporal subyacente.
Cálculo de histogram_quantile
Un cálculo de PromQL histogram_quantile
en un histograma sin muestras produce un valor NaN. El cálculo del lenguaje de consulta interno no produce ningún valor, sino que se elimina el punto de la marca de tiempo.
Las diferencias en el cálculo de las tarifas también pueden afectar a las entradas de las consultas histogram_quantile.
Funciones específicas de tipo en métricas de tipos diferentes
Aunque Prometheus upstream tiene un tipado débil, Monarch tiene un tipado fuerte. Esto significa que ejecutar funciones específicas de un solo tipo en una métrica de otro tipo (por ejemplo, ejecutar rate() en una métrica GAUGE o histogram_quantile() en una métrica COUNTER o sin tipo) no funciona en Managed Service para Prometheus, aunque estas funciones sí funcionen en la versión upstream de Prometheus.