Propoño ler a transcrición do informe de Roman Khavronenko "ExtendedPromQL"
Brevemente sobre min. Chámome Romano. Traballo para CloudFlare e vivo en Londres. Pero tamén son mantedor de VictoriaMetrics.
E eu son o autor para Grafana e é un pequeno proxy para ClickHouse.
Comezaremos pola primeira parte, que se chama “Dificultades de tradución” e nela falarei de que calquera lingua ou incluso só unha lingua de comunicación é moi importante. Porque así é como transmites os teus pensamentos a outra persoa ou sistema, como formulas unha solicitude. A xente en Internet discute sobre cal é o mellor idioma: java ou outro. Para min, decidín que é necesario escoller unha tarefa, porque todo isto é específico.
Comecemos dende o principio. Que é PromQL? PromQL é a linguaxe de consulta de Prometheus. Así é como formamos consultas en Prometheus para obter datos de series temporais, series temporais.
Que son os datos de series temporais? Literalmente, estes son tres parámetros.
Estes son:
- Que estamos mirando.
- Cando o miramos.
- E que valor mostra.
Se miras este gráfico (este gráfico é do meu teléfono, que mostra as estatísticas dos meus pasos), aquí podes responder rapidamente a estas preguntas.
Estamos mirando os pasos. Vemos o significado e vemos o tempo cando o miramos. É dicir, mirando este diagrama, pódese dicir facilmente que o domingo camiñei uns 15 pasos. Estes son datos de series temporais.
Agora imos "romper" (transformalos) noutro modelo de datos en forma de táboa. Aquí tamén temos o que estamos mirando. Aquí engadín uns pequenos datos adicionais, que chamaremos metadatos, é dicir, non fun eu o que pasou, senón dúas persoas, por exemplo, Jay e Silent Bob. Iso é o que estamos mirando; que mostra e cando mostra ese valor.
Agora imos tentar almacenar todos estes datos na base de datos. Por exemplo, tomei a sintaxe de ClickHouse. E aquí estamos creando unha táboa chamada "Pasos", é dicir, o que estamos mirando. Hai un tempo aquí no que o miramos; o que mostra e algúns metadatos onde almacenaremos quen é: Jay e Silent Bob.
E para tentar visualizalo todo, usaremos Grafana, porque, en primeiro lugar, é bonito.
Tamén usaremos este complemento. Hai dúas razóns para iso. O primeiro é porque o escribín. E sei exactamente o difícil que é sacar datos de series temporais de ClickHouse para mostralos en Grafana.
Amosarémolo no panel de gráficos. Este é o panel máis popular en Grafana e mostra o valor fronte ao tempo, polo que só necesitamos dous parámetros.
Escribamos a consulta máis sinxela: como mostrar as estatísticas de pasos en Grafana, almacenando estes datos en ClickHouse, na táboa que creamos. E escribimos unha consulta tan sinxela. Escollemos entre pasos. Seleccionamos un valor e seleccionamos o tempo destes valores, é dicir, os mesmos tres parámetros dos que falamos.
E como resultado, obtemos este gráfico. Quen sabe por que é tan raro?
É certo, cómpre ordenar por tempo.
E ao final temos un calendario mellor, pero aínda estraño. Quen sabe por que? É certo, hai dous participantes e regalamos dúas series temporais en Grafana, porque se tratamos de novo co modelo de datos, cada serie temporal é unha combinación única dun nome e de todas as etiquetas clave-valor.
Polo tanto, necesitamos escoller unha persoa específica. Escollemos a Jay.
E debuxa de novo. Agora o gráfico parece a verdade. Agora é un horario normal e todo funciona ben.
E, probablemente, sabes como facer o mesmo, pero en Prometheus a través de PromQL. Aproximadamente así. Un pouco máis fácil. E desglosámolo todo. Damos Pasos. E filtrar por Jay. Non especificamos aquí que necesitamos obter un valor e non eliximos un momento.
Agora imos tentar calcular a velocidade de movemento de Jay ou Silent Bob. En ClickHouse, teremos que facer runningDifference, é dicir, calcular a diferenza entre pares de puntos e dividilos por tempo para obter a velocidade exacta. A solicitude terá un aspecto así.
E mostrará aproximadamente estes valores, é dicir, aproximadamente 1,8 pasos por segundo fai Silent Bob ou Jay.
E en Prometheus tamén sabes como facelo. Moito máis doado que antes.
E para que tamén sexa fácil de facer en Grafana, engadín un envoltorio que se parece moito a PromQL. Chámase Macros de tarifas, ou como queiras chamarlle. En Grafana, só escribes "taxa", pero nalgún lugar no fondo transfórmase nunha petición tan grande. E nin sequera tes que miralo, está aí nalgún lugar, pero aforras moito tempo, porque escribir consultas SQL tan grandes sempre é caro. Pode facilmente cometer un erro e despois non entender o que está a suceder durante moito tempo.
E esta é unha consulta que nin sequera cabía nunha diapositiva, e ata tiven que dividila en dúas columnas. Esta tamén é unha solicitude en ClickHouse, que fai a mesma tarifa, pero para ambas as series temporais: Silent Bob e Jay, polo que temos dúas series temporais no panel. E isto xa é moi difícil, na miña opinión.
E segundo Prometeo será suma (taxa). Para ClickHouse fixen unha macro separada chamada RateColumns que parece unha consulta de Prometheus.
Miramos e parece que PromQL é moi xenial, pero ten, por suposto, limitacións.
Estes son:
- SELECCIÓN LIMITADA.
- Edge JOINs.
- Non hai apoio.
E se traballas con el durante moito tempo, sabes que ás veces é moi difícil facer algo en PromQL, e en SQL podes facer case todo, porque todas estas opcións das que acabamos de falar poderían facerse en SQL. . Pero sería conveniente usalo? E isto faime pensar que non sempre a lingua máis poderosa pode ser a máis conveniente.
Polo tanto, ás veces cómpre escoller un idioma para as tarefas. É como unha batalla entre Batman e Superman. Está claro que Superman é máis forte, pero Batman puido derrotalo porque é máis práctico e sabía exactamente o que estaba a facer.
E a seguinte parte é A extensión de PromQL.
Unha vez máis sobre VictoriaMetrics. Que é VictoriaMetrics? Esta é unha base de datos de series temporais, está en OpenSource, distribuímos as súas versións single e cluster. Segundo os nosos puntos de referencia, é o máis rápido que hai no mercado agora e é similar en termos de compresión, é dicir, as persoas vivas informan de compresión duns 0,4 bytes por punto, cando Prometheus ten 1,2-1,4.
Apoiamos non só a Prometeo. Soportamos InfluxDB, Graphite, OpenTSDB.
Podes "escribir" en nós, é dicir, podes transferir datos antigos.
E tamén traballamos perfectamente con Prometheus e Grafana, é dicir, admitimos o motor PromQL. E en Grafana, simplemente podes cambiar o punto final de Prometheus a VictoriaMetrics e todos os teus paneis funcionarán como o fixeron.
Pero tamén podes usar chips adicionais proporcionados por VictoriaMetrics.
Imos repasar rapidamente as funcións que engadimos.
Omitir parámetro de intervalo: pode omitir o intervalo de parámetros en Grafana. Cando non quere obter gráficos estraños ao achegar ou diminuír o zoom no panel, recoméndase utilizar a variable $__interval. Este é un cambio interno de Grafana e escolle o propio intervalo de datos. E VictoriaMetrics pode entender por si mesma cal debería ser este rango. E non tes que actualizar todas as túas consultas. Será moito máis doado.
A segunda función é a referencia de intervalos. Podes usar este espazo nas túas expresións. Podes multiplicar, dividir, transferir, referirse a el.
O seguinte é a familia de funcións de acumulación. A función de acumulación transforma calquera das súas series temporais en tres series temporais separadas. Estes son min, max e avg. Paréceme moi conveniente, porque ás veces pode mostrar algúns valores atípicos (anomalías) e imprecisións.
E se só estás enfurecido ou valoras, probablemente podes perder algúns casos nos que a serie temporal non se comporta como querías. É moito máis fácil de ver con esta función, digamos que max está moi fóra da media.
A continuación é a variable predeterminada. Por defecto: isto significa que valor necesitamos debuxar en Grafana se non temos unha serie temporal neste momento. Cando ocorre? Digamos que exportas algunhas métricas de erro. E tes unha aplicación tan xenial que cando inicias, non tes erros nin sequera durante as próximas tres horas ou mesmo un día. E tes paneis que mostran as relacións de éxito a erro. E non che mostrarán nada porque non tes unha métrica de erro. E por defecto podes especificar calquera cousa.
Keep_last_Value: garda o último valor da métrica se falta. Se Prometheus despois do seguinte raspado non o atopou en 5 minutos, aquí lembraremos o seu último valor e os teus gráficos non volverán romper.
Scrape_interval: mostra con que frecuencia Prometheus recolle datos sobre a túa métrica, con que frecuencia. Aquí podes ver o pase, por exemplo.
A substitución de etiquetas é unha característica popular. Pero pensamos que é un pouco complicado porque necesita argumentos enteiros. E cómpre non só lembrar os 5 argumentos, senón tamén lembrar a súa secuencia.
Polo tanto, por que non facelos máis sinxelos? É dicir, dividilo en pequenas funcións cunha sintaxe clara.
E agora o máis interesante. Por que pensamos que é PromQL estendido? Porque admitimos Common Table Expressions. Podes seguir o código QR (), consulta ligazóns con exemplos, do parque infantil, onde podes realizar consultas directamente en VictoriaMetrics sen instalalo só no navegador.
E que é? Esta solicitude desde arriba é unha solicitude bastante popular. Creo que en calquera panel de moitas empresas utilizas o mesmo filtro para todo. Normalmente así. Pero cando necesites engadir algún filtro novo, tes que actualizar cada panel, ou descargar o panel, abrilo en JSON, facer unha substitución de busca, o que tamén leva tempo. Por que non almacenar este valor nunha variable e reutilizalo? Parece, na miña opinión, moito máis sinxelo e claro.
Por exemplo, cando necesito actualizar filtros en Grafana en todas as solicitudes, e o panel pode ser enorme ou incluso pode haber varios deles. E como me gustaría resolver este problema en Grafana?
Resolvo este problema así: fago un commonFilter e defino este filtro nel, e despois reutilizoo nas consultas. Pero se fai o mesmo agora, non funcionará porque Grafana non che permite usar variables dentro das variables de consulta. E é un pouco raro.
E por iso fixen unha opción que che permite facelo. E se estás interesado ou queres esa función, apoia ou non che gusta se non che gusta esta idea.
Máis información sobre PromQL estendido. Aquí definimos non só unha variable, senón directamente unha función enteira. E chamámoslle ru (uso de recursos). E esta función acepta recursos gratuítos, un límite de recursos e un filtro. A sintaxe parece ser sinxela. E é moi sinxelo usar esta función e calcular a porcentaxe de memoria libre que temos. É dicir, canta memoria temos, que límite e como filtrar. Parece moito mellor se o escribiras todo reutilizando os mesmos filtros, porque se convertería nunha consulta grande e grande.
E aquí tes un exemplo dunha petición tan grande e grande. É do panel oficial de NodeExporter para Grafana. Pero realmente non entendo o que está a pasar aquí. Iso é, por suposto, entendo se miras detidamente, pero o número de corchetes pode reducir inmediatamente a motivación para comprender o que está a suceder aquí. E por que non facelo máis sinxelo e claro?
Por exemplo, así, destacando cousas ou partes significativas en variables. E despois fai as túas matemáticas básicas. Isto xa é máis como programar, isto é o que me gustaría ver no futuro en Grafana.
Aquí tes un segundo exemplo de como podemos facelo aínda máis sinxelo se xa tiñamos esta función ru, e xa existe directamente en VictoriaMetrics. E entón só pasas o valor almacenado na caché que declarou no CTE.
Xa falei do importante que é empregar a linguaxe de programación adecuada. E, probablemente, algo diferente está a suceder en Grafana en cada empresa. E, probablemente, aínda dás acceso a Grafana aos teus desenvolvedores, e os desenvolvedores fan algo propio. E todos fano dun xeito diferente. Pero queríao dalgún xeito igual, é dicir, reducido a un estándar común.
Digamos que nin sequera tes enxeñeiros de sistemas, quizais teñas expertos, devops ou SRE. Quizais teñas expertos que saben o que é a vixilancia, saben o que é Grafana, é dicir, levan anos traballando con isto e saben exactamente como facelo ben. E xa o escribiron 100 veces e explicárono a todos, pero por algo ninguén escoita.
E se puidesen poñer estes coñecementos directamente en Grafana para que outros usuarios poidan reutilizar as funcións? E se fose necesario calcular a porcentaxe de memoria libre, entón simplemente aplicarían a función. Pero e se os creadores dos exportadores, xunto co seu produto, tamén proporcionasen un conxunto de funcións, como traballar coas súas métricas, porque saben exactamente cales son estas métricas e como calculalas correctamente?
Este realmente non existe. Aquí está o que fixen eu mesmo. Este é o soporte da biblioteca en Grafana. Digamos que os mozos que fixeron NodeExporter fixeron o que describín. E tamén proporcionou un conxunto de características.
É dicir, parece algo así. Conectas esta biblioteca a Grafana, entras na edición e aquí é moi sinxelo en JSON como traballar con esta métrica. É dicir, algún conxunto de funcións, a súa descrición e en que se desenvolven.
Na miña opinión, isto podería ser útil, porque así escribirías en Grafana. E Grafana "dílle" que hai tal función de tal biblioteca, empregámola. Creo que sería moi chulo.
Un pouco sobre VictoriaMetrics. Facemos moitas cousas interesantes. Lea os nosos artigos sobre compresión, sobre a nosa competencia con outras aplicacións de datos de series temporais, a nosa explicación de como traballar con PromQL, porque hai moitos máis principiantes nisto, así como sobre a escalabilidade vertical e sobre a confrontación con Thanos.
Preguntas:
Comezo a miña pregunta cunha simple historia de vida. Cando comecei a usar Grafana, escribín unha consulta de 5 liñas moi persuasiva. O resultado final é un gráfico moi convincente. Este gráfico case entrou en produción. Pero tras unha inspección máis atenta, resultou que este gráfico mostra un despropósito absoluto que non ten nada que ver coa realidade, aínda que os números entran no rango que esperabamos ver. E a miña pregunta. Temos bibliotecas, temos funcións, pero como escribimos probas para Grafana? Escribiu unha consulta complexa que afecta á decisión empresarial: pedir un contedor real de servidores ou non pedir. E como sabemos, esta función que debuxa unha gráfica é semellante á verdade. Grazas.
Grazas pola pregunta. Aquí hai dúas partes. En primeiro lugar, teño a impresión, baseándome na miña experiencia, de que a maioría dos usuarios, cando miran os seus gráficos, non entenden o que lles están mostrando. Dalgunha maneira, a xente é moi boa para buscar unha escusa para calquera anomalía que ocorre nos gráficos, aínda que sexa un erro dentro dunha función. E a segunda parte, paréceme que usar tales funcións sería moito máis adecuado para resolver o teu problema, en lugar de que cada un dos teus desenvolvedores faga a súa propia planificación da capacidade e cometa erros con certa probabilidade.
Como comprobar?
Como comprobar? Probablemente non.
Como proba en Grafana.
E que pasa con Grafana? Grafana traduce esta solicitude directamente ao DataSource.
Engadindo un pouco aos parámetros.
Non, non se lle engade nada a Grafana. Pode haber parámetros GET, como step. Non se especifica explícitamente, pero pode anulalo, non pode anulalo, pero engádese automaticamente. Non escribes probas aquí. Non creo que debas confiar aquí en Grafana como fonte de verdade.
Grazas polo informe! Grazas pola compresión! Lembraches sobre a asignación dunha variable nun gráfico, que en Grafana non podes usar unha variable nunha variable. Entendes o que quero dicir?
Si
Isto foi inicialmente unha dor de cabeza cando quixen facer unha alerta en Grafana. E hai que facer alertas para cada host por separado. Aquí está o que fixeches, funciona para alertas en Grafana?
Se Grafana non accede ás variables doutro xeito, entón si, funcionará. Pero o meu consello é que non uses as alertas en Grafana, é mellor que uses alertmanager.
Si, úsoo, pero pareceume máis fácil de configurar en Grafana, pero grazas polo consello.
Fonte: www.habr.com