La tasa Prometheus () funciona mejor con VictoriaMetrics

Hay muchas cosas que me gustan de Prometheus; su modelo de datos es excelente para monitorear aplicaciones y el lenguaje PromQL suele ser más expresivo que SQL para las necesidades de recuperación de datos que tiene en el espacio de observación. Sin embargo, una cosa que odio de Prometheus con una profunda pasión es su comportamiento de velocidad () y características similares, profundamente arraigadas en el modelo computacional de Prometheus, que el equipo de desarrollo me dijo que es poco probable que cambie.

Entonces, ¿cuál es el problema y por qué es tan grande?

Primero – el problema. Las funciones de tasa () le dan la tasa de cambio de la serie de tiempo para el Intervalo proporcionado, así como tarifa (mysql_global_status_questions[10s]) Simplemente le dará el número promedio de consultas de MySQL en los últimos 10 segundos. Todo es excelente hasta ahora.

Pero, ¿y si la resolución de esta serie temporal es inferior a 10 segundos, por ejemplo, si tomamos mysql_global_status_questions ¿Mides solo cada minuto? En este caso, la función tasa () no devolverá nada y los datos desaparecerán del gráfico.

¿Qué me gustaría ver en su lugar? ¡Dale sentido común! Si le digo que la pregunta de MySQL fue 1M a las 0:00 y 2M a las 10:00, y le pregunto cuál fue el número promedio de consultas por segundo de 4:00 a 5:00, solo usará la mejor estimación que tenga disponible. y da el promedio basado en los datos disponibles.

Por supuesto, tal enfoque no está exento de problemas, por ejemplo, es posible que MySQL en realidad fuera a 10 millones de consultas a las 5:00 y cuando se reinició, fue a 2 millones, y luego los datos serán incorrectos; Sin embargo, creo que, en la mayoría de los casos, tener esos datos es preferible a no tener datos disponibles.

«Soluciones» existentes

Una «solución» que Prometheus proporciona a este problema es la función irate () que le brinda la «tasa inmediata» basada en los dos últimos puntos de datos en la serie temporal. Si usa irate () con un rango bastante grande, puede evitar obtener «sin datos», pero lo lleva a otro problema: obtiene datos muy volátiles basados ​​​​en dos mediciones que, aunque menos volátiles, son suaves. por un período de tiempo más largo y puede ser deseable.

Otro problema con furioso () Es solo calificar () función tiene una función correspondiente, mientras que otras funciones como avg_over_time () o max_over_time () no tienes grandes opciones.

Una solución, que a menudo se recomienda, es crear solo sus tableros para que coincidan con la resolución de la captura de datos para que no pueda entrar en tales situaciones.

Este no es un comienzo para nuestro caso de uso en Percona..

Usamos Prometheus como un componente clave en Percona Monitoring and Management (PMM) y la resolución de captura de datos es altamente configurable, por lo que puede diferir en diferentes períodos de tiempo y diferentes series de tiempo en el sistema. Además, la mayoría de los tableros que proporcionamos son dinámicos y utilizan un período de medios más bajo como «acercamiento» a los datos.

VictoriaMetrics al rescate

VictoriaMetrics es una base de datos de series de tiempo que se puede conectar a Prometheus usando escritura remota back-end Implementa la API de lectura, que también es compatible en su mayoría con Prometheus. MétricasQLque es en su mayoría compatible con PromQL y ofrece algunas funciones de idioma adicionales.

VictoriaMetrics tiene otras ventajas en comparación con Prometheus, que van desde operación masivamente paralela para escalabilidad, mejor rendimiento y mejor compresión de datos, aunque el enfoque de esta publicación de blog está en calificar () gestión de funciones.

Asas VictoriaMetrics calificar () funcionar en el sentido común que describí anteriormente!

Veamos la diferencia en la práctica. Aquí usamos un prototipo de Monitoreo y Gestión de Percona con VictoriaMetrics. En el panel «Preguntas» usamos la fórmula innecesariamente complicada:

Que podemos simplificar a la fórmula de «sentido común» que queramos usar, sin necesidad de nada más:

Compara ahora los gráficos entre Prometheus (Izquierda) y VictoriaMetrics (Derecha)

Gama 1h

Prometheus vs VictoriaMetrics

Para un intervalo de 1 hora, tenemos una resolución bastante alta para los datos de visualización de Prometheus y VictoriaMetrics. Las diferencias en los gráficos provienen del hecho de que estos son dos casos separados que realizan cargas de trabajo similares en lugar de los mismos datos en los dos almacenes de datos.

rango de 5 minutos

Prometheus vs VictoriaMetrics

En este caso, como puede ver, Prometheus no muestra datos, mientras que VictoriaMetrics proporciona datos incluso si la resolución probada es de 1 segundo y los datos están disponibles con solo 5 segundos de resolución.

Resumen

Estamos en las primeras etapas del proceso de evaluación de VictoriaMetrics, pero estoy muy emocionado de resolver este molesto problema que tenemos con la administración de las aplicaciones de Prometheus. Me pregunto si esto también es un problema para ti, y si también encontrarás el comportamiento de VictoriaMetrics más amigable o si el comportamiento de Prometheus es el preferido en tu entorno.

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario