Sugiro que você leia a transcrição do relatório “ExtendedPromQL” de Roman Khavronenko
Brevemente sobre mim. Meu nome é Romano. Trabalho na CloudFlare e moro em Londres. Mas também sou mantenedor do VictoriaMetrics.
E eu sou o autor para Grafana e é um pequeno proxy para ClickHouse.
Começaremos pela primeira parte, que se chama “Dificuldades de Tradução” e nela falarei sobre o fato de que qualquer idioma ou mesmo apenas um idioma de comunicação é muito importante. Porque é assim que você transmite seus pensamentos a outra pessoa ou sistema, como formula um pedido. As pessoas na Internet discutem sobre qual linguagem é melhor - java ou alguma outra. Quanto a mim, decidi que preciso escolher de acordo com a tarefa, porque tudo isso é específico.
Vamos começar desde o início. O que é PromQL? PromQL é a linguagem de consulta Prometheus. É assim que formamos consultas no Prometheus para obter dados de séries temporais.
O que são dados de série temporal? Literalmente, estes são três parâmetros.
Estes são:
- O que estamos olhando?
- Quando olhamos para isso.
- E que valor isso mostra?
Se você olhar este gráfico (este gráfico é do meu telefone e mostra minhas estatísticas de passos), ele poderá responder rapidamente a essas perguntas.
Nós olhamos para as etapas. Vemos o significado e vemos o momento quando olhamos para ele. Ou seja, olhando para este diagrama, você pode facilmente dizer que no domingo caminhei cerca de 15 passos. Estes são dados de série temporal.
Agora vamos “dividi-los” (convertê-los) em outro modelo de dados na forma de uma tabela. Aqui também temos o que estamos vendo. Aqui adicionei alguns dados adicionais, que chamaremos de metadados, ou seja, não fui eu quem passou por isso, mas duas pessoas, por exemplo, Jay e Silent Bob. É isso que estamos vendo; o que mostra e quando mostra esse valor.
Agora vamos tentar armazenar todos esses dados em um banco de dados. Por exemplo, peguei a sintaxe ClickHouse. E aqui criamos uma tabela chamada “Etapas”, ou seja, o que estamos vendo. Chega um momento em que olhamos para isso; o que mostra e alguns metadados onde armazenaremos quem é: Jay e Silent Bob.
E para tentar visualizar tudo isso vamos usar o Grafana porque, antes de tudo, é lindo.
Também usaremos este plugin. Há duas razões para isso. A primeira é porque eu escrevi. E eu sei exatamente como é difícil extrair dados de séries temporais do ClickHouse para mostrá-los no Grafana.
Iremos exibi-lo no Painel Gráfico. Este é o painel mais popular do Grafana, que mostra a dependência de um valor no tempo, portanto precisamos apenas de dois parâmetros.
Vamos escrever a consulta mais simples - como mostrar estatísticas de etapas no Grafana, armazenando esses dados no ClickHouse, na tabela que criamos. E escrevemos este pedido simples. Nós escolhemos as etapas. Selecionamos um valor e selecionamos o tempo desses valores, ou seja, os mesmos três parâmetros de que falamos.
E como resultado, obteremos um gráfico como este. Quem sabe por que ele é tão estranho?
Isso mesmo, precisamos classificar por tempo.
E no final teremos um cronograma melhor, mas ainda estranho. Quem sabe por quê? É isso mesmo, há dois participantes, e nós da Grafana distribuímos duas séries temporais, porque se você olhar o modelo de dados novamente, cada série temporal é uma combinação única de nome e todos os rótulos de valores-chave.
Portanto, precisamos escolher uma pessoa específica. Nós escolhemos Jay.
E vamos desenhar novamente. Agora o gráfico parece verdadeiro. Agora este é um cronograma normal e tudo está funcionando bem.
E você provavelmente sabe fazer aproximadamente a mesma coisa, mas no Prometheus via PromQL. Algo assim. Um pouco mais simples. E vamos decompor tudo. Demos passos. E filtre por Jay. Não estamos especificando aqui que precisamos obter um valor e não estamos escolhendo um horário.
Agora vamos tentar calcular a velocidade de movimento de Jay ou Silent Bob. No ClickHouse precisaremos fazer runningDifference, ou seja, calcular a diferença entre pares de pontos e dividi-los pelo tempo para obter a velocidade exata. A solicitação será mais ou menos assim.
E mostrará aproximadamente esses valores, ou seja, Silent Bob ou Jay dão aproximadamente 1,8 passos por segundo.
E no Prometheus você também sabe fazer isso. Muito mais fácil do que era antes.
E para facilitar também no Grafana, adicionei este wrapper, que é muito parecido com o PromQL. Chama-se Rate Macros ou como você quiser chamá-lo. No Grafana você simplesmente escreve “taxa”, mas em algum lugar no fundo isso se transforma nessa grande solicitação. E você nem precisa olhar, está em algum lugar, mas você economiza muito tempo, porque escrever consultas SQL tão grandes é sempre caro. Você pode facilmente cometer um erro e ficar sem entender o que está acontecendo por um longo tempo.
E esse é um pedido que não cabia nem em um slide e ainda tive que dividir em duas colunas. Essa também é uma solicitação no ClickHouse, que faz a mesma taxa, mas para as duas séries temporais: Silent Bob e Jay, para que tenhamos duas séries temporais no painel. E isso já é muito difícil, na minha opinião.
E de acordo com Prometeu será soma (taxa). Para ClickHouse, criei uma macro separada chamada RateColumns, que se parece com uma consulta no Prometheus.
Nós olhamos para ele e parece que o PromQL é muito legal, mas tem, é claro, limitações.
Estes são:
- SELEÇÃO limitada.
- JOINs limítrofes.
- Não TER suporte.
E se você já trabalha com isso há muito tempo, sabe que às vezes é muito difícil fazer algo no PromQL, mas no SQL você pode fazer quase tudo, porque todas essas opções que acabamos de falar poderiam ser feitas no SQL . Mas seria conveniente usá-lo? E isso me faz pensar que a linguagem mais poderosa nem sempre é a mais conveniente.
Portanto, às vezes você precisa escolher um idioma para a tarefa. É como se o Batman lutasse contra o Superman. É claro que o Superman é mais forte, mas o Batman conseguiu derrotá-lo porque ele é mais prático e sabia exatamente o que estava fazendo.
E a próxima parte é Estendendo o PromQL.
Mais uma vez sobre VictoriaMetrics. O que é VictoriaMetrics? Este é um banco de dados de série temporal, é em OpenSource, distribuímos suas versões single e cluster. De acordo com nossos benchmarks, é mais rápido do que qualquer coisa no mercado atualmente e a compactação é semelhante, ou seja, pessoas reais relatam compactação de cerca de 0,4 bytes por ponto, enquanto a do Prometheus é de 1,2-1,4.
Apoiamos mais do que apenas o Prometheus. Apoiamos InfluxDB, Grafite, OpenTSDB.
Você pode “escrever” para nós, ou seja, pode transferir dados antigos.
E também funcionamos perfeitamente com Prometheus e Grafana, ou seja, oferecemos suporte ao motor PromQL. E no Grafana você pode simplesmente alterar o endpoint do Prometheus para VictoriaMetrics e todos os seus painéis funcionarão como antes.
Mas você também pode usar recursos adicionais fornecidos pelo VictoriaMetrics.
Examinaremos rapidamente os recursos que adicionamos.
Omitir parâmetro de intervalo – você pode omitir parâmetros de intervalo no Grafana. Quando você não deseja obter gráficos estranhos ao aumentar/diminuir o zoom no painel, é recomendado usar a variável $__interval. Esta é uma alteração interna do Grafana e seleciona o próprio intervalo de dados. E a própria VictoriaMetrics pode entender qual deveria ser essa faixa. E você não precisa atualizar todas as suas solicitações. Será muito mais fácil.
A segunda função é a referência de intervalo. Você pode usar esse intervalo em suas expressões. Você pode multiplicar, dividir, transferir, referir-se a isso.
A seguir está a família de funções rollup. A função Rollup transforma qualquer uma de suas séries temporais em três séries temporais separadas. Estes são mínimo, máximo e média. Acho isso muito conveniente porque às vezes pode mostrar alguns valores discrepantes e imprecisões.
E se você estiver apenas irado ou avaliar, provavelmente perderá alguns casos em que a série temporal não se comporta conforme o esperado. Com esta função fica muito mais fácil de ver, digamos que o máximo está muito longe da média.
A seguir está a variável padrão. Padrão - significa qual valor precisamos desenhar no Grafana se não tivermos uma série temporal no momento. Quando isso acontece? Digamos que você esteja exportando algumas métricas de erro. E você tem um aplicativo tão legal que, ao iniciar, você não terá erros e até mesmo nenhum erro pelas próximas três horas ou até mesmo um dia. E você tem painéis que mostram a relação entre o sucesso e o erro. E eles não mostrarão nada porque você não tem uma métrica de erro. E por padrão você pode especificar qualquer coisa.
Keep_last_Value – salva o último valor da métrica se estiver faltando. Se o Prometheus não o encontrar dentro de 5 minutos após a próxima varredura, então aqui lembraremos seu último valor e seus gráficos não serão quebrados novamente.
Scrape_interval – mostra com que frequência o Prometheus coleta dados em sua métrica e com que frequência. Aqui você pode ver um passe, por exemplo.
A substituição de rótulo é um recurso popular. Mas achamos que é um pouco complicado porque requer argumentos inteiros. E você precisa não apenas lembrar de 5 argumentos, mas também de sua sequência.
Portanto, por que não torná-los mais simples? Ou seja, divida-o em pequenas funções com sintaxe compreensível.
E agora a parte divertida. Por que achamos que isso é PromQL estendido? Porque oferecemos suporte a Expressões de Tabela Comuns. Você pode seguir o código QR (), veja links com exemplos, do playground, onde você pode executar consultas diretamente no VictoriaMetrics sem instalá-lo simplesmente no navegador.
E o que é isso? Este pedido acima é um pedido bastante popular. Acho que em qualquer dashboard de muitas empresas você usa o mesmo filtro para tudo. Geralmente é assim. Mas quando você precisa adicionar algum filtro novo, você tem que atualizar cada painel, ou baixar o dashboard, abri-lo em JSON, encontrar a substituição, o que também leva tempo. Por que não armazenar esse valor em uma variável e reutilizá-lo? Isso parece, na minha opinião, muito mais simples e claro.
Por exemplo, quando preciso atualizar filtros no Grafana em todas as requisições, e o dashboard pode ser enorme ou até mesmo ter vários deles. E como eu gostaria de resolver esse problema no Grafana?
Eu resolvo esse problema desta forma: faço um commonFilter e defino esse filtro nele, para depois reutilizá-lo nas consultas. Mas se você fizer o mesmo agora, não funcionará porque o Grafana não permite o uso de variáveis dentro de variáveis de consulta. E é um pouco estranho.
E então fiz uma opção que permite que você faça isso. E se você estiver interessado ou quiser tal recurso, apoie-o ou não goste se não gostar da ideia.
Mais sobre PromQL estendido. Aqui definimos não apenas uma variável, mas uma função inteira. E chamamos isso de ru (uso de recursos). E esta função aceita recursos gratuitos, limitação de recursos e filtro. A sintaxe parece ser simples. E é muito fácil usar esta função e calcular a porcentagem de memória livre que temos. Ou seja, quanta memória temos, qual a limitação e como filtrar. Parece muito mais conveniente se você escrever tudo, reutilizando os mesmos filtros, porque isso se transformaria em uma consulta muito, muito grande.
E aqui está um exemplo de um pedido tão grande. É do painel oficial do NodeExporter para Grafana. Mas eu mal entendo o que está acontecendo aqui. Isso, claro, eu entendo se você olhar com atenção, mas o número de parênteses pode reduzir imediatamente a motivação para entender o que está acontecendo aqui. E por que não torná-lo mais simples e claro?
Por exemplo, assim, separar coisas ou partes significativas em variáveis. E então faça suas contas básicas. Isso já é mais parecido com programação, é isso que eu gostaria de ver no futuro no Grafana.
Aqui está um segundo exemplo de como poderíamos tornar isso ainda mais fácil se já tivéssemos essa função ru, e ela já existe diretamente no VictoriaMetrics. E você simplesmente passa o valor em cache que declarou no CTE.
Já falei sobre como é importante usar a linguagem de programação correta. E, provavelmente, cada empresa em Grafana tem algo diferente acontecendo. E você provavelmente também dá acesso ao Grafana aos seus desenvolvedores, e os desenvolvedores fazem suas próprias coisas. E todos eles fazem isso de forma diferente. Mas eu queria que fosse de alguma forma igual, isto é, reduzi-lo a um padrão comum.
Digamos que você não tenha apenas engenheiros de sistema, talvez até tenha especialistas, devops ou SRE. Talvez você tenha especialistas que sabem o que é monitoramento, que sabem o que é Grafana, ou seja, trabalham com isso há anos e sabem exatamente como fazer da maneira certa. E eles já escreveram isso 100 vezes e explicaram para todo mundo, mas por algum motivo ninguém escuta.
E se eles pudessem colocar esse conhecimento diretamente no Grafana para que outros usuários pudessem reutilizar os recursos? E se precisassem calcular a porcentagem de memória livre, simplesmente aplicariam a função. E se os criadores de exportadores, junto com seu produto, também disponibilizassem um conjunto de funções de como trabalhar com suas métricas, pois sabem exatamente o que são essas métricas e como calculá-las corretamente?
Isso realmente não existe. Isto é o que eu mesmo fiz. Este é o suporte da biblioteca no Grafana. Digamos que os caras que criaram o NodeExporter fizeram o que eu falei. E eles também forneceram um conjunto de funções.
Ou seja, parece algo assim. Você conecta essa biblioteca ao Grafana, vai para a edição e está escrito de forma muito simples em JSON como trabalhar com essa métrica. Ou seja, algum conjunto de funções, sua descrição e em que se transformam.
Acho que isso pode ser útil, porque aí no Grafana você escreveria assim mesmo. E Grafana “diz” a você que existe tal e tal função em tal ou tal biblioteca - vamos usá-la. Eu acho que isso seria muito legal.
Um pouco sobre VictoriaMetrics. Fazemos muitas coisas interessantes. Leia nossos artigos sobre compressão, sobre nossas competições com outras aplicações de dados de séries temporais, nossa explicação de como trabalhar com PromQL, pois ainda há muitos iniciantes nisso, bem como sobre escalabilidade vertical e sobre o confronto com Thanos.
Perguntas:
Começarei minha pergunta com uma simples história de vida. Quando comecei a usar o Grafana, escrevi uma consulta muito atraente com 5 linhas. O resultado final é um gráfico muito convincente. Este cronograma quase entrou em produção. Mas após uma inspeção mais detalhada, descobriu-se que este gráfico mostra um absurdo absoluto que nada tem a ver com a realidade, embora os números estejam dentro da faixa que esperávamos ver. E minha pergunta. Temos bibliotecas, temos funções, mas como escrevemos testes para o Grafana? Você escreveu uma solicitação complexa da qual depende uma decisão de negócios - solicitar ou não um contêiner real de servidores. E como sabemos, esta função que desenha o gráfico é semelhante à verdade. Obrigado.
Obrigado pela pergunta. Existem duas partes. Primeiro, tenho a impressão, com base na minha experiência, de que a maioria dos usuários, quando olham para seus gráficos, não entendem o que estão mostrando. Por alguma razão, as pessoas são muito boas em inventar uma desculpa para qualquer anomalia que ocorra nos gráficos, mesmo que seja um erro dentro de uma função. E a segunda parte - parece-me que usar tais funções seria uma abordagem muito melhor para resolver seu problema, em vez de cada um de seus desenvolvedores fazer seu próprio planejamento de capacidade e cometer erros com alguma probabilidade.
Como verificar?
Como verificar? Provavelmente não.
Como teste no Grafana.
O que o Grafana tem a ver com isso? Grafana traduz esta solicitação diretamente para o DataSource.
Adicionando um pouco aos parâmetros.
Não, nada é adicionado ao Grafana. Pode haver parâmetros GET, como, digamos, step. Ele não é especificado explicitamente, mas você pode substituí-lo ou não, mas é adicionado automaticamente. Você não escreverá testes aqui. Não acho que devamos confiar no Grafana como fonte de verdade aqui.
Obrigado pelo relatório! Obrigado pela compressão! Você mencionou o mapeamento de uma variável em um gráfico, que no Grafana você não pode usar uma variável dentro de uma variável. Você sabe o que eu quero dizer?
Sim.
Inicialmente, isso foi uma dor de cabeça quando quis criar um alerta no Grafana. E aí você precisa fazer um alerta para cada host separadamente. Essa coisa que você fez funciona para alertas no Grafana?
Se o Grafana não acessar as variáveis de forma diferente, sim, funcionará. Mas meu conselho é não usar alertas no Grafana, é melhor usar o alertmanager.
Sim, eu uso, mas pareceu mais fácil de configurar no Grafana, mas obrigado pelo conselho!
Fonte: habr.com