Les invito a revisar la transcripción de la presentación de Roman Khavronenko "ExtendedPromQL"
Brevemente sobre mí. Me llamo Roman. Trabajo en CloudFlare y vivo en Londres. Pero también soy mantenedor de VictoriaMetrics.
Y soy el autor para Grafana y – es un pequeño proxy para ClickHouse.
Comenzaremos con la primera parte, titulada "Dificultades de la traducción", donde hablaré sobre cómo cualquier idioma, o incluso simplemente el lenguaje de comunicación, es muy importante. Porque es la forma en que transfieres tus pensamientos a otra persona o a un sistema, cómo formulas tu solicitud. La gente en internet discute sobre qué lenguaje es mejor: Java u otro. Para mí, he decidido que hay que elegir según la tarea, porque todo esto es específico.
Empecemos desde el principio. ¿Qué es PromQL? PromQL es el lenguaje de consulta de Prometheus. Así es como formulamos consultas en Prometheus para obtener datos de series temporales.
¿Qué son los datos de series temporales? Literalmente, son tres parámetros.
Son:
- A qué estamos mirando.
- Cuándo lo estamos mirando.
- Y qué valor muestra.
Si miramos este gráfico (este gráfico es de mi teléfono, que muestra la estadística de mis pasos), aquí podemos responder rápidamente a estas preguntas.
Estamos viendo los pasos. Vemos el valor y vemos el tiempo cuando lo estamos observando. Es decir, mirando este gráfico, es fácil decir que el domingo caminé alrededor de 15,000 pasos. Eso son datos de series temporales.
Ahora, vamos a "descomponer" (transformar) estos datos en otro modelo de datos en forma de tabla. Aquí también tenemos lo que estamos mirando. He añadido algunos datos adicionales, que llamaremos metadatos, es decir, no fui yo, sino dos personas, digamos, Jay y Silent Bob. Esto es lo que estamos mirando; qué muestra y cuándo muestra ese valor.
Ahora intentemos guardar todos estos datos en una base de datos. Para ello, he tomado la sintaxis de ClickHouse. Aquí creamos una tabla llamada "Steps", es decir, lo que estamos mirando. Hay un tiempo, que es cuando lo estamos observando; qué muestra y algunos metadatos, donde almacenaremos quiénes son: Jay y Silent Bob.
Y para intentar visualizar todo esto, utilizaremos Grafana, porque, primero, es bonito.
También utilizaremos este plugin. Hay dos razones para ello. La primera es porque yo lo escribí. Y sé lo difícil que es extraer datos de series temporales de ClickHouse para mostrar en Grafana.
Vamos a mostrarlos en Graph Panel. Este es el panel más popular en Grafana, que muestra la dependencia del valor en función del tiempo, por lo que solo necesitamos dos parámetros.
Escribamos la consulta más sencilla: cómo mostrar las estadísticas de pasos en Grafana, almacenando estos datos en ClickHouse, en la tabla que creamos. Escribimos esta simple consulta. Seleccionamos de pasos. Elegimos el valor y seleccionamos el tiempo de esos valores, es decir, los mismos tres parámetros de los que hablamos.
Y como resultado obtendremos este gráfico. ¿Alguien sabe por qué se ve tan extraño?
Correcto, hay que ordenar por tiempo.
Y al final obtendremos uno mejor, pero todavía extraño. ¿Alguien sabe por qué? Correcto, hay dos participantes, y en Grafana estamos entregando dos series temporales, porque si revisamos el modelo de datos una vez más, cada serie temporal es una combinación única de nombre y todos los pares clave-valor de labels.
Por lo tanto, necesitamos elegir a una persona específica. Elegimos a Jay.
Y dibujamos una vez más. Ahora el gráfico se asemeja a la realidad. Ahora es un gráfico normal y todo funciona bien.
Y probablemente sepas cómo hacer algo similar, pero en Prometheus a través de PromQL. Aproximadamente así. Un poco más fácil. Y además, desglosaremos todo. Estábamos tratando con Steps. Y filtramos por Jay. Aquí no especificamos que necesitamos obtener el valor ni elegimos el tiempo.
Ahora intentemos calcular la velocidad de Jay o Silent Bob. En ClickHouse, tendremos que hacer runningDifference, es decir, calcular la diferencia entre pares de puntos y dividirlas por el tiempo para obtener la velocidad exacta. La consulta se verá aproximadamente así.
Y mostrará valores como estos, es decir, aproximadamente 1.8 pasos por segundo realiza Silent Bob o Jay.
Y en Prometheus también sabes cómo hacerlo. Mucho más fácil que antes.
Y para que esto sea igual de fácil de hacer en Grafana, añadí un envoltorio que se parece mucho a PromQL. Se llama Rate Macros, o como quieras llamarlo. En Grafana, solo escribes «rate», pero en el fondo se transforma en una consulta muy extensa. No necesitas ni mirarla, está ahí, pero ahorras un montón de tiempo, porque escribir consultas SQL tan grandes siempre es costoso. Es fácil equivocarse y luego no entender qué está pasando.
Y esta es una consulta que ni siquiera cabía en una sola diapositiva y tuve que dividirla en dos columnas. También es una consulta en ClickHouse que hace lo mismo que rate, pero para ambas series temporales: tanto para Silent Bob como para Jay, para que tengamos dos series temporales en el panel. Y esto ya es muy complicado, en mi opinión.
Y para Prometheus será sum(rate). Para ClickHouse hice un macro separado que se llama RateColumns, que se ve como una consulta en Prometheus.
Vimos que PromQL es genial, pero, claro, tiene limitaciones.
Son:
- SELECT limitado.
- JOINs limitados.
- Sin soporte para HAVING.
Y si has trabajado con esto durante mucho tiempo, sabes que a veces es muy difícil hacer algo en PromQL, mientras que en SQL se puede hacer prácticamente todo, porque todas estas opciones que hemos discutido ahora se podrían hacer en SQL. ¿Pero sería conveniente usarlo? Y esto me lleva a pensar que el lenguaje más poderoso no siempre puede ser el más conveniente.
Así que a veces hay que elegir el lenguaje según las tareas. Es como la batalla de Batman contra Superman. Está claro que Superman es más fuerte, pero Batman logró derrotarlo porque es más práctico y sabía exactamente lo que hacía.
Y la siguiente parte es Extending PromQL.
Una vez más sobre VictoriaMetrics. ¿Qué es VictoriaMetrics? Es una base de datos de series temporales, es OpenSource, distribuimos sus versiones single y cluster. Según nuestras benchmarks, es lo más rápido que hay en el mercado ahora y también en compresión, es decir, las personas reportan compresión de alrededor de 0.4 bytes por punto, mientras que con Prometheus es de 1.2-1.4.
No solo soportamos Prometheus. También soportamos InfluxDB, Graphite, OpenTSDB.
Se puede "escribir" en nosotros, es decir, se pueden migrar datos antiguos.
Y también trabajamos perfectamente con Prometheus y Grafana, es decir, soportamos el motor PromQL. Y en Grafana, puedes simplemente cambiar el endpoint de Prometheus a VictoriaMetrics y todos tus dashboards funcionarán como solían hacerlo.
Pero puedes utilizar características adicionales que ofrece VictoriaMetrics.
Repasaremos rápidamente las funciones que hemos añadido.
Omitir el parámetro de intervalo – puedes omitir el intervalo de parámetros en Grafana. Cuando no desees obtener gráficos extraños al hacer zoom in o zoom out en el panel, se recomienda usar la variable $__interval. Esta es una variable interna de Grafana y ella misma selecciona el rango de datos. Y VictoriaMetrics puede entender cuál debe ser ese rango. No necesitarás actualizar todas tus consultas. Será mucho más sencillo.
La segunda función es la referencia de intervalo. Puedes utilizar este intervalo en tus expresiones. Puedes multiplicar, dividir, pasar, referenciarlo.
Luego está la familia de funciones de rollup. La función de rollup transforma cualquier serie temporal en tres series temporales distintas: min, max y avg. Creo que es muy útil, porque a veces puede mostrar algunos outliers (anomalías) y imprecisiones.
Y si simplemente haces irate o rate, probablemente puedes perder algunos casos en los que la serie temporal se comporta de manera diferente a lo que esperabas. Con esta función es mucho más fácil ver, por ejemplo, que el max es significativamente mayor que el avg.
A continuación, la variable default. Default indica qué valor necesitamos mostrar en Grafana si no tenemos serie temporal en ese momento. ¿Cuándo sucede esto? Por ejemplo, si estás exportando alguna métrica de errores. Y tienes una aplicación tan genial que cuando inicias, no tienes errores e incluso no tienes errores durante las siguientes tres horas o un día. Y tienes dashboards que muestran la relación entre éxito y error. Y no te mostrarán nada porque no tienes métrica de error. Pero en default puedes especificar lo que quieras.
Keep_last_Value – guarda el último valor de la métrica si esta desaparece. Si Prometheus no la encuentra en el siguiente scrape después de 5 minutos, aquí recordaremos su último valor y tus gráficos no se romperán.
Scrape_interval – muestra con qué frecuencia Prometheus recoge datos de tu métrica, con qué frecuencia. Aquí puedes ver saltos, por ejemplo.
Label replace – una función popular. Pero creemos que es un poco complicada porque toma varios argumentos. Y no solo tienes que recordar 5 argumentos, sino también recordar su secuencia.
Entonces, ¿por qué no simplificarlos? Es decir, dividir en funciones pequeñas con una sintaxis clara.
Y ahora, lo más interesante. ¿Por qué consideramos que esto es PromQL extendido? Porque soportamos Expresiones de Tabla Común. Puedes escanear el código QR (), ver enlaces con ejemplos, con un playground donde puedes ejecutar consultas directamente en VictoriaMetrics sin necesidad de instalarla, solo en el navegador.
¿Y qué es esto? Esta consulta de arriba es una consulta bastante popular. Creo que en cualquier tablero de muchas empresas utilizas el mismo filtro para todo. Así suele ser. Pero cuando necesitas añadir un nuevo filtro, tienes que actualizar cada panel, o descargar el tablero, abrirlo en JSON, hacer un buscar y reemplazar, lo que también toma tiempo. ¿Por qué no guardar ese valor en una variable y reutilizarlo? Me parece que es mucho más simple y claro.
Por ejemplo, cuando necesito actualizar filtros en Grafana en todas las consultas, y el tablero puede ser enorme o incluso pueden ser varios. ¿Y cómo quisiera resolver este problema en Grafana?
Yo resuelvo este problema así: hago commonFilter y defino ese filtro, y luego lo reutilizo en las consultas. Pero si ahora lo haces así, no funcionará, porque Grafana no te permite utilizar variables dentro de las variables de consulta. Y es un poco extraño.
Y por eso hice una variante que permite hacerlo. Y si te interesa o deseas esta función, apóyala o dale un dislike si no te gusta la idea.
Ahora, sobre PromQL extendido. Aquí definimos no solo una variable, sino una función completa. Y la llamamos ru (uso de recursos). Esta función toma recursos libres, limitaciones de recursos y un filtro. Parece que la sintaxis es bastante simple. Y es muy fácil usar esta función y calcular el porcentaje de memoria libre que tenemos. Es decir, cuánta memoria tenemos, cuál es la limitación y cómo filtrar. Esto resulta mucho más conveniente si escribes todo esto reutilizando los mismos filtros, ya que se convertiría en una gran consulta.
Y aquí hay un ejemplo de una consulta muy, muy grande. Proviene del panel oficial de NodeExporter para Grafana. Pero no entiendo del todo qué está pasando aquí. Es decir, entiendo si me detengo a mirar, pero la cantidad de paréntesis puede desanimar a cualquiera de intentar entender lo que sucede. ¿Por qué no hacerlo más simple y comprensible?
Por ejemplo, así, destacando cosas o partes significativas en variables. Y luego realizar tus cálculos básicos. Esto se asemeja más a la programación, algo que me gustaría ver en el futuro en Grafana.
Aquí hay un segundo ejemplo de cómo podríamos hacerlo aún más sencillo, si ya tuviéramos esta función ru, y ya está directamente en VictoriaMetrics. Entonces simplemente pasarías el valor almacenado que declaraste en CTE.
Ya he mencionado lo importante que es utilizar el lenguaje de programación adecuado. Y, probablemente, en cada empresa en Grafana hay algo único. Seguramente también dan acceso a Grafana a sus desarrolladores, y los desarrolladores hacen algo diferente. Todos lo hacen de diferentes maneras. Y desearía que pudiera ser más uniforme, es decir, reducirlo a un estándar común.
Supongamos que tienes no solo ingenieros de sistemas, tal vez incluso expertos, DevOps o SRE. Tal vez tengas expertos que saben lo que es la monitorización, saben lo que es Grafana, es decir, han trabajado con ello durante años y saben exactamente cómo hacerlo bien. Ya lo han escrito 100 veces y se lo han explicado a todos, pero por alguna razón, nadie escucha.
¿Y qué pasaría si pudieran incorporar ese conocimiento directamente en Grafana para que otros usuarios pudieran reutilizar funciones? Y si tuvieran que 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 qué son esas métricas y cómo contarlas correctamente?
Eso en realidad no existe. Esto lo hice yo mismo. Esto es soporte para bibliotecas en Grafana. Supongamos que los chicos que crearon NodeExporter hicieron lo que he mencionado. Y también proporcionaron un conjunto de funciones.
Es decir, se ve algo así. Conectas esta biblioteca en Grafana, accedes a la edición y aquí está muy simple en JSON cómo trabajar con esta métrica. Es decir, un conjunto de funciones, su descripción y en qué se desarrollan.
Creo que esto podría ser útil, porque entonces en Grafana escribirías simplemente así. Y Grafana te "dice" que hay tal función de tal biblioteca, así que vamos a usarla. Me parece que sería genial.
Un poco sobre VictoriaMetrics. Hacemos muchas cosas interesantes. Lee nuestros artículos sobre compresión, sobre nuestras competiciones con otras aplicaciones de series temporales, nuestra explicación sobre cómo trabajar con PromQL, porque hay muchos principiantes en esto, así como sobre escalabilidad vertical y sobre la competencia con Thanos.
Preguntas:
Empezaré mi pregunta con una simple historia de vida. Cuando comencé a usar Grafana, escribí una consulta muy convincente de 5 líneas. Al final, resultó ser un gráfico muy convincente. Este gráfico estuvo a punto de ir a producción. Pero al mirarlo de cerca, resultó que ese 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 es, tenemos bibliotecas, tenemos funciones, pero ¿cómo escribimos pruebas para Grafana? Has escrito una consulta compleja de la que depende una decisión empresarial: pedir un contenedor real de servidores o no. Y, ¿cómo sabemos que esta función que dibuja el gráfico se asemeja a la verdad? Gracias.
Gracias por la pregunta. Aquí hay dos partes. La primera es que tengo la impresión, basándome en mi experiencia, que la mayoría de los usuarios, cuando miran sus gráficos, no entienden lo que les están mostrando. De alguna manera, las personas son muy buenas para inventar una justificación para cualquier anomalía que aparezca en los gráficos, incluso si es un error dentro de la función. Y la segunda parte es que creo que usar este tipo de funciones sería mucho más adecuado para resolver tu problema, en lugar de que cada uno de tus desarrolladores haga su planificación de capacidad y se equivoque con alguna probabilidad.
¿Cómo comprobar?
¿Cómo comprobar? Probablemente, de ninguna manera.
En forma de prueba en Grafana.
¿Qué tiene que ver Grafana? Grafana traduce esta consulta directamente en el DataSource.
Agregando un poco más en los parámetros.
No, en Grafana no se añade nada. Pueden haber parámetros GET, como, por ejemplo, step. No se especifica claramente, pero lo puedes sobrescribir, puedes no sobrescribirlo, pero se agrega automáticamente. Aquí no vas a escribir pruebas. Creo que no vale la pena confiar aquí en Grafana como una fuente de verdad.
¡Gracias por la presentación! ¡Gracias por la compresión! Mencionaste el mapeo de la variable en el gráfico, que en Grafana no se puede usar una variable dentro de otra variable. ¿Entiendes de qué hablo?
Sí.
Eso fue originalmente un dolor de cabeza, cuando quería crear alertas en Grafana. Y allí necesitas hacer alertas para cada host por separado. Este truco que hiciste, ¿funciona para alertas en Grafana?
Si Grafana no accede a las variables de otra manera, entonces sí, funcionará. Pero mi consejo es no usar alertas en Grafana en absoluto, es mejor que uses alertmanager.
Sí, lo uso, pero simplemente me pareció más fácil de configurar en Grafana, ¡gracias por el consejo!
Fuente: habr.com
