Propongo leer la transcripción del informe de Roman Khavronenko "ExtendedPromQL"
Brevemente sobre mí. Mi nombre es romano. Trabajo en CloudFlare y vivo en Londres. Pero también soy mantenedor de VictoriaMetrics.
y yo soy el autor para Grafana y es un pequeño proxy para ClickHouse.
Comenzaremos con la primera parte, que se llama “Dificultades de la traducción” y en ella hablaré de que cualquier idioma o incluso solo un idioma de comunicación es muy importante. Porque así es como transmites tus pensamientos a otra persona o sistema, así es como formulas una solicitud. La gente en Internet discute sobre qué idioma es mejor: Java o algún otro. Por mi parte, decidí que debía elegir según la tarea, porque todo esto es específico.
Empecemos desde el principio. ¿Qué es PromQL? PromQL es el lenguaje de consulta Prometheus. Así es como formamos consultas en Prometheus para obtener datos de series de tiempo, series de tiempo.
¿Qué son los datos de series de tiempo? Literalmente, estos son tres parámetros.
Son los siguientes:
- ¿Qué estamos mirando?
- Cuando lo miramos.
- Y qué valor muestra.
Si observa este gráfico (este gráfico es de mi teléfono y muestra las estadísticas de mis pasos), puede responder rápidamente estas preguntas.
Nos fijamos en los pasos. Vemos el significado y vemos el momento cuando lo miramos. Es decir, mirando este diagrama, se puede decir fácilmente que el domingo caminé unos 15 pasos. Estos son datos de series de tiempo.
Ahora vamos a "dividirlos" (transformarlos) en otro modelo de datos en forma de tabla. Aquí también tenemos lo que estamos viendo. Aquí agregué algunos datos adicionales, que llamaremos metadatos, es decir, no fui yo quien pasó, sino dos personas, por ejemplo, Jay y Silent Bob. Esto es lo que estamos viendo; qué muestra y cuándo muestra ese valor.
Ahora intentemos almacenar todos estos datos en la base de datos. Por ejemplo, tomé la sintaxis de ClickHouse. Y aquí estamos creando una tabla llamada "Pasos", es decir, lo que estamos viendo. Hay un momento aquí en el que lo miramos; lo que muestra y algunos metadatos donde almacenaremos quiénes son: Jay y Silent Bob.
Y para intentar visualizar todo esto, usaremos Grafana porque, ante todo, es hermoso.
También usaremos este complemento. Hay dos razones para esto. La primera es porque lo escribí yo. Y sé exactamente lo difícil que es extraer datos de series temporales de ClickHouse para mostrarlos en Grafana.
Lo mostraremos en el Panel de gráficos. Este es el panel más popular en Grafana y muestra el valor versus el tiempo, por lo que solo necesitamos dos parámetros.
Escribamos la consulta más simple: cómo mostrar estadísticas de pasos en Grafana, almacenando estos datos en ClickHouse, en la tabla que creamos. Y escribimos una consulta tan simple. Elegimos entre pasos. Seleccionamos un valor y seleccionamos el tiempo de estos valores, es decir, los mismos tres parámetros de los que hablamos.
Y como resultado, obtendremos un gráfico como este. ¿Quién sabe por qué es tan extraño?
Así es, debes ordenar por tiempo.
Y al final obtendremos un calendario mejor, aunque aún extraño. ¿Quién sabe por qué? Así es, hay dos participantes y en Grafana regalamos dos series de tiempo, porque si miras el modelo de datos nuevamente, cada serie de tiempo es una combinación única de nombre y todas las etiquetas de valor clave.
Por tanto, debemos elegir una persona específica. Elegimos a Jay.
Y volvamos a dibujar. Ahora el gráfico parece la verdad. Ahora este es un horario normal y todo está funcionando bien.
Y probablemente sepas cómo hacer más o menos lo mismo, pero en Prometheus a través de PromQL. Algo como esto. Un poco más sencillo. Y analicémoslo todo. Dimos pasos. Y filtrar por Jay. No especificamos aquí que necesitamos obtener un valor y no elegimos un momento.
Ahora intentemos calcular la velocidad de movimiento de Jay o Silent Bob. En ClickHouse necesitaremos ejecutar RunningDifference, es decir, calcular la diferencia entre pares de puntos y dividirlos por el tiempo para obtener la velocidad exacta. La solicitud se verá así.
Y mostrará aproximadamente estos valores, es decir, Silent Bob o Jay dan aproximadamente 1,8 pasos por segundo.
Y en Prometheus tú también sabes cómo hacerlo. Mucho más fácil que antes.
Y para que también sea fácil de hacer en Grafana, agregué un contenedor que se parece mucho a PromQL. Se llama Rate Macros, o como quieras llamarlo. En Grafana, simplemente escribes "tarifa", pero en algún lugar del fondo se transforma en una solicitud tan grande. Y ni siquiera tienes que mirarlo, está ahí en alguna parte, pero ahorras mucho tiempo, porque escribir consultas SQL tan grandes siempre es costoso. Es fácil cometer un error y luego no comprender lo que está sucediendo durante mucho tiempo.
Y esta es una consulta que ni siquiera cabía en una diapositiva, e incluso tuve que dividirla en dos columnas. Esta también es una solicitud en ClickHouse, que hace la misma tarifa, pero para ambas series temporales: Silent Bob y Jay, por lo que tenemos dos series temporales en el panel. Y esto, en mi opinión, ya es muy difícil.
Y según Prometeo será sum (tasa). Para ClickHouse, creé una macro separada llamada RateColumns, que parece una consulta en Prometheus.
Miramos y parece que PromQL es genial, pero, por supuesto, tiene limitaciones.
Son los siguientes:
- SELECCIÓN limitada.
- UNIONES de borde.
- Sin TENER apoyo.
Y si has trabajado con él durante mucho tiempo, entonces sabes que a veces es muy difícil hacer algo en PromQL, pero en SQL puedes hacer casi todo, porque todas estas opciones de las que acabamos de hablar se pueden hacer en SQL. . ¿Pero sería conveniente utilizarlo? Y esto me hace pensar que el lenguaje más potente puede no ser siempre el más conveniente.
Por lo tanto, a veces es necesario elegir un idioma para la tarea. Es como Batman luchando contra Superman. Está claro que Superman es más fuerte, pero Batman pudo derrotarlo porque es más práctico y sabía exactamente lo que hacía.
Y la siguiente parte es Ampliar PromQL.
Una vez más sobre VictoriaMetrics. ¿Qué es VictoriaMetrics? Esta es una base de datos de series temporales, está en OpenSource, distribuimos sus versiones única y cluster. Según nuestros puntos de referencia, es más rápido que cualquier cosa que haya en el mercado actualmente y la compresión es similar, es decir, personas reales informan una compresión de aproximadamente 0,4 bytes por punto, mientras que la de Prometheus es de 1,2-1,4.
Apoyamos algo más que Prometheus. Admitimos InfluxDB, Graphite, OpenTSDB.
Puede “escribirnos”, es decir, puede transferir datos antiguos.
Y también trabajamos perfectamente con Prometheus y Grafana, es decir, admitimos el motor PromQL. Y en Grafana simplemente puede cambiar el punto final de Prometheus a VictoriaMetrics y todos sus paneles funcionarán como antes.
Pero también puedes utilizar chips adicionales proporcionados por VictoriaMetrics.
Revisaremos rápidamente las funciones que hemos agregado.
Omitir parámetro de intervalo: puede omitir parámetros de intervalo en Grafana. Cuando no desee obtener gráficos extraños al acercar o alejar el panel, se recomienda utilizar la variable $__interval. Este es un cambio interno de Grafana y selecciona el rango de datos por sí mismo. Y la propia VictoriaMetrics puede entender cuál debería ser este rango. Y no es necesario que actualice todas sus solicitudes. Será mucho más fácil.
La segunda función es la referencia a intervalos. Puedes utilizar este espaciado en tus expresiones. Puedes multiplicarlo, dividirlo, transferirlo, consultarlo.
La siguiente es la familia de funciones acumuladas. La función Rollup transforma cualquiera de sus series temporales en tres series temporales separadas. Estos son mínimo, máximo y promedio. Esto me parece muy conveniente porque a veces puede mostrar algunos valores atípicos e imprecisiones.
Y si simplemente estás enojado o calificando, entonces probablemente puedas pasar por alto algunos casos en los que la serie temporal no se comporta de la manera prevista. Es mucho más fácil de ver con esta función, digamos que el máximo está muy por debajo del promedio.
La siguiente es la variable predeterminada. Predeterminado: esto significa qué valor debemos dibujar en Grafana si no tenemos una serie de tiempo en este momento. ¿Cuando sucede? Supongamos que exporta algunas métricas de error. Y tienes una aplicación tan genial que cuando la inicias, no tienes errores y ni siquiera hay errores durante las próximas tres horas o incluso un día. Y tiene paneles que muestran las relaciones desde el éxito hasta el error. Y no te mostrarán nada porque no tienes una métrica de error. Y por defecto puedes especificar cualquier cosa.
Keep_last_Value: guarda el último valor de la métrica si falta. Si Prometheus no lo encuentra dentro de los 5 minutos posteriores al siguiente raspado, aquí recordaremos su último valor y sus gráficos no se volverán a romper.
Scrape_interval: muestra con qué frecuencia Prometheus recopila datos sobre su métrica y con qué frecuencia. Aquí puedes ver un pase, por ejemplo.
El reemplazo de etiquetas es una característica popular. Pero creemos que es un poco complicado porque requiere argumentos enteros. Y no sólo es necesario recordar los 5 argumentos, sino también recordar su secuencia.
Por tanto, ¿por qué no hacerlos más sencillos? Es decir, dividirlo en pequeñas funciones con una sintaxis clara.
Y ahora la parte divertida. ¿Por qué creemos que es PromQL extendido? Porque admitimos expresiones de tabla comunes. Puedes seguir el código QR (), vea enlaces con ejemplos, desde el patio de juegos, donde puede ejecutar consultas directamente en VictoriaMetrics sin instalarlo simplemente en el navegador.
¿Y esto qué es? Esta solicitud anterior es una solicitud bastante popular. Creo que en cualquier panel de muchas empresas se utiliza el mismo filtro para todo. Normalmente es así. Pero cuando necesita agregar algún filtro nuevo, debe actualizar cada panel o descargar el panel, abrirlo en JSON y buscar reemplazo, lo que también lleva tiempo. ¿Por qué no almacenar este valor en una variable y reutilizarlo? En mi opinión, esto parece mucho más sencillo y claro.
Por ejemplo, cuando necesito actualizar filtros en Grafana en todas las solicitudes y el panel puede ser enorme o incluso puede haber varios. ¿Y cómo me gustaría solucionar este problema en Grafana?
Resuelvo este problema de esta manera: hago un filtro común y defino este filtro en él, y luego lo reutilizo en consultas. Pero si haces lo mismo ahora, no funcionará porque Grafana no te permite usar variables dentro de las variables de consulta. Y es un poco raro.
Y entonces hice una opción que te permite hacer esto. Y si está interesado o desea una función de este tipo, apoye o no le guste esta idea.
Más sobre PromQL extendido. Aquí definimos no sólo una variable, sino directamente una función completa. Y lo llamamos ru (uso de recursos). Y esta función acepta recursos gratuitos, un límite de recursos y un filtro. La sintaxis parece ser simple. Y es muy fácil utilizar esta función y calcular el porcentaje de memoria libre que tenemos. Es decir, cuánta memoria tenemos, qué límite y cómo filtrar. Se ve mucho mejor si lo escribieras todo reutilizando los mismos filtros, porque se convertiría en una consulta muy, muy grande.
Y aquí hay un ejemplo de una petición tan grande. Es del panel oficial de NodeExporter para Grafana. Pero apenas entiendo lo que está pasando aquí. Eso es, por supuesto, lo entiendo si miras de cerca, pero la cantidad de paréntesis puede reducir inmediatamente la motivación para comprender lo que está sucediendo aquí. ¿Y por qué no hacerlo más sencillo y claro?
Por ejemplo, así, separar cosas o partes significativas en variables. Y luego haz tus cálculos básicos. Esto ya se parece más a la programación, esto es lo que me gustaría ver en el futuro en Grafana.
Aquí hay un segundo ejemplo de cómo podríamos hacer esto aún más fácil si ya tuviéramos esta función ru y ya existiera directamente en VictoriaMetrics. Y luego simplemente pasas el valor almacenado en caché que declaraste en el CTE.
Ya he hablado de lo importante que es utilizar el lenguaje de programación adecuado. Y probablemente en Grafana en cada empresa esté sucediendo algo diferente. Y, probablemente, todavía le das acceso a Grafana a tus desarrolladores, y los desarrolladores hacen algo por su cuenta. Y todos lo hacen de forma diferente. Pero lo quería de algún modo igual, es decir, reducido a un estándar común.
Digamos que ni siquiera tiene solo ingenieros de sistemas, tal vez incluso tenga expertos, devops o SRE. Quizás tengas expertos que sepan qué es el monitoreo, que sepan qué es Grafana, es decir, que hayan estado trabajando con él durante años y sepan exactamente cómo hacerlo bien. Y ya escribieron esto 100 veces y se lo explicaron a todos, pero por alguna razón nadie escucha.
¿Qué pasaría si pudieran poner este conocimiento directamente en Grafana para que otros usuarios pudieran reutilizar las funciones? Y si necesitaran calcular el porcentaje de memoria libre, simplemente aplicarían la función. ¿Qué pasaría si los creadores de los exportadores, junto con su producto, también proporcionaran un conjunto de funciones sobre cómo trabajar con sus métricas, porque saben exactamente cuáles son estas métricas y cómo calcularlas correctamente?
Éste realmente no existe. Esto es lo que hice yo mismo. Este es el soporte de la biblioteca en Grafana. Digamos que los chicos que crearon NodeExporter hicieron lo que describí. Y también proporcionó un conjunto de características.
Es decir, se parece a esto. Conectas esta biblioteca a Grafana, ingresas a la edición y está escrito de manera muy simple en JSON cómo trabajar con esta métrica. Es decir, un conjunto de funciones, su descripción y en qué se convierten.
En mi opinión, esto podría ser útil, porque entonces escribirías en Grafana así como así. Y Grafana le "dice" que existe tal o cual función de tal o cual biblioteca: usémosla. Creo que sería genial.
Un poco sobre VictoriaMetrics. Hacemos muchas cosas interesantes. Lea nuestros artículos sobre compresión, sobre nuestras competiciones con otras aplicaciones de datos de series temporales, nuestra explicación sobre cómo trabajar con PromQL, porque todavía hay muchos principiantes en esto, así como sobre escalabilidad vertical y sobre la confrontación con Thanos.
Preguntas:
Comenzaré mi pregunta con una simple historia de vida. Cuando comencé a usar Grafana, escribí una consulta muy convincente de 5 líneas. El resultado final es un gráfico muy convincente. Este programa casi ha entrado en producción. Pero tras una inspección más cercana, resultó que este gráfico muestra una absoluta tontería que no tiene nada que ver con la realidad, aunque los números están dentro del rango que esperábamos ver. Y mi pregunta. Tenemos bibliotecas, tenemos funciones, pero ¿cómo escribimos pruebas para Grafana? Ha escrito una solicitud compleja de la que depende una decisión comercial: pedir un contenedor real de servidores o no. Y como sabemos, esta función que dibuja la gráfica es similar a la verdad. Gracias.
Gracias por la pregunta. Hay dos partes aquí. En primer lugar, según mi experiencia, tengo la impresión de que la mayoría de los usuarios, cuando miran sus gráficos, no entienden lo que les muestran. De alguna manera, la gente es muy buena para encontrar una excusa para cualquier anomalía que ocurra en los gráficos, incluso si es un error dentro de una función. Y la segunda parte: me parece que usar tales funciones sería mucho más adecuado para resolver su problema, en lugar de que cada uno de sus desarrolladores haga su propia planificación de capacidad y cometa errores con cierta probabilidad.
¿Cómo verificar?
¿Como revisar? Probablemente no.
Como prueba en Grafana.
¿Y Grafana? Grafana traduce esta solicitud directamente al DataSource.
Agregando un poco a los parámetros.
No, no se agrega nada a Grafana. Puede haber parámetros GET, como el paso. No se especifica explícitamente, pero puede anularlo, no puede anularlo, pero se agrega automáticamente. Aquí no se escriben exámenes. No creo que debas confiar en Grafana aquí como fuente de verdad.
¡Gracias por el informe! ¡Gracias por la compresión! Mencionaste mapear una variable en un gráfico, que en Grafana no puedes usar una variable dentro de una variable. ¿Sabes lo que quiero decir?
Sí.
Inicialmente, esto fue un dolor de cabeza cuando quise crear una alerta en Grafana. Y allí debes hacer una alerta para cada host por separado. Esto que hiciste, ¿funciona para alertas en Grafana?
Si Grafana no accede a las variables de manera diferente, entonces sí, funcionará. Pero mi consejo es no utilizar alertas en Grafana en absoluto, es mejor que utilices alertmanager.
Sí, lo uso, pero me pareció más fácil de configurar en Grafana, ¡pero gracias por el consejo!
Fuente: habr.com