Convido você a conferir a transcrição da apresentação de Roman Khavronenko "ExtendedPromQL"
Um breve resumo sobre mim. Meu nome é Roman. Trabalho na CloudFlare e moro em Londres. Mas também sou mantenedor do VictoriaMetrics.
E sou o autor para Grafana e – é um pequeno proxy para ClickHouse.
Vamos começar pela primeira parte, intitulada "As dificuldades da tradução", onde falarei sobre como qualquer língua ou mesmo apenas a língua de comunicação é muito importante. Porque é assim que você transmite seus pensamentos a outra pessoa ou sistema, como você formula uma solicitação. As pessoas na internet discutem sobre qual linguagem é melhor – java ou outra qualquer. Para mim, decidi que devemos escolher conforme a tarefa, pois tudo isso é específico.
Vamos começar do começo. O que é PromQL? PromQL é a Linguagem de Consulta do Prometheus. É assim que formulamos consultas no Prometheus para obtendo dados de séries temporais.
O que são dados de séries temporais? Literalmente, são três parâmetros.
São:
- No que estamos olhando.
- Quando estamos olhando para isso.
- E qual valor está sendo mostrado.
Se olharmos para este gráfico (este gráfico é do meu telefone, mostrando a estatística dos meus passos), podemos responder rapidamente a essas perguntas.
Olhamos para os passos. Vemos o valor e vemos o tempo em que olhamos para isso. Ou seja, olhando para este gráfico, podemos facilmente dizer que no domingo eu andei cerca de 15.000 passos. Esses são dados de séries temporais.
Agora vamos "quebrar" (transformar) esses dados em outro modelo na forma de uma tabela. Aqui também temos o que estamos observando. Aqui adicionei alguns dados adicionais, que chamaremos de metadados, ou seja, não fui eu que passei, mas duas pessoas, digamos, Jay e Silent Bob. Isso é o que estamos observando; o que isso mostra e quando mostra esse valor.
Agora vamos tentar armazenar todos esses dados em um banco de dados. Para o exemplo, escolhi a sintaxe do ClickHouse. E aqui estamos criando uma tabela chamada "Steps", ou seja, o que estamos observando. Aqui temos o tempo em que estamos olhando; o que isso mostra e alguns metadados, onde armazenaremos quem são: Jay e Silent Bob.
E para tentar visualizar tudo isso, usaremos o Grafana, porque, em primeiro lugar, é bonito.
Também vamos usar este plugin. Existem duas razões para isso. A primeira é porque eu o escrevi. E eu sei exatamente como é difícil extrair dados de séries temporais do ClickHouse para mostrar no Grafana.
Vamos exibir no Graph Panel. Este é o painel mais popular no Grafana, que mostra a relação entre valor e tempo, então só precisamos de dois parâmetros.
Vamos escrever a consulta mais simples — como mostrar a estatística de passos no Grafana, armazenando esses dados no ClickHouse, na tabela que criamos. E escrevemos esta consulta simples. Selecionamos dos passos. Selecionamos o valor e selecionamos o tempo desses valores, ou seja, os mesmos três parâmetros que mencionamos.
E no resultado, obteremos este gráfico. Quem sabe por que ele é tão estranho?
Certo, precisamos ordenar pelo tempo.
E, no final, teremos um gráfico melhor, mas ainda estranho. Quem sabe por quê? Certo, há dois participantes, e no Grafana estamos colocando duas séries temporais, porque se analisarmos o modelo de dados uma vez mais, cada série temporal é uma combinação única de nome e todos os pares chave-valor das labels.
Portanto, precisamos escolher uma pessoa específica. Vamos escolher Jay.
E desenhamos novamente. Agora o gráfico parece verdadeiro. Agora é um gráfico normal e tudo funciona bem.
E, provavelmente, você sabe como fazer algo semelhante, mas no Prometheus através do PromQL. Mais ou menos assim. Um pouco mais fácil. E ainda vamos dividir isso tudo. Pegamos Steps. E filtramos por Jay. Aqui não especificamos que precisamos obter um valor e não escolhemos o tempo.
Agora vamos tentar calcular a velocidade de movimento de Jay ou Silent Bob. No ClickHouse, precisaremos fazer a runningDifference, ou seja, calcular a diferença entre pares de pontos e dividi-los pelo tempo para obter a velocidade exata. A consulta ficará mais ou menos assim.
E mostrará valores como este, ou seja, aproximadamente 1,8 passos por segundo que Silent Bob ou Jay fazem.
E no Prometheus você sabe como fazer isso também. Muito mais fácil do que antes.
E para que isso continue sendo tão simples de fazer no Grafana, eu adicionei esta camada, que se parece muito com PromQL. Ela é chamada de Rate Macros ou como você quiser chamá-la. No Grafana, você simplesmente escreve "rate", mas em algum lugar profundo, isso é transformado em uma grande consulta. E você nem precisa olhar para isso, está lá, mas você economiza muito tempo, pois escrever grandes consultas SQL é sempre dispendioso. Você pode facilmente cometer um erro e depois ficar muito tempo sem entender o que está acontecendo.
E esta é uma consulta que não coube em um único slide e eu tive que dividi-la em duas colunas. Esta também é uma consulta no ClickHouse, que faz a mesma taxa, mas para ambas as séries temporais: tanto Silent Bob quanto Jay, para que tivéssemos duas séries temporais no nosso painel. E isso já é muito complicado, na minha opinião.
E para o Prometheus, isso será sum(rate). Para o ClickHouse, eu criei um macro separado chamado RateColumns, que se parece com uma consulta no Prometheus.
Nós olhamos e parece que o PromQL é muito legal, mas ele tem, é claro, suas limitações.
São:
- SELECT limitado.
- JOINs limitados.
- Sem suporte a HAVING.
E se você trabalhou muito com ele, sabe que às vezes é muito difícil fazer algo no PromQL, enquanto no SQL você pode fazer quase tudo, porque todas essas opções que discutimos agora poderiam ser feitas no SQL. Mas isso seria conveniente de usar? E isso me leva a pensar que nem sempre a linguagem mais poderosa pode ser a mais conveniente.
Portanto, às vezes é necessário escolher a linguagem para as tarefas. É como a batalha entre Batman e Superman. É claro que Superman é mais forte, mas Batman conseguiu vencê-lo porque é mais prático e sabia exatamente o que estava fazendo.
E a próxima parte é Extending PromQL.
Mais uma vez sobre a VictoriaMetrics. O que é a VictoriaMetrics? É uma base de dados de séries temporais, é OpenSource, distribuímos suas versões single e cluster. De acordo com nossos benchmarks, ela é a mais rápida no mercado atualmente e em compressão, da mesma forma, ou seja, pessoas reais reportam compressão em torno de 0,4 bytes por ponto, enquanto no Prometheus é de 1,2-1,4.
Nós suportamos não apenas Prometheus. Nós suportamos InfluxDB, Graphite, OpenTSDB.
Você pode "escrever" em nós, ou seja, pode transferir dados antigos.
E ainda trabalhamos perfeitamente com Prometheus e Grafana, ou seja, suportamos o motor PromQL. E no Grafana, você pode simplesmente mudar o endpoint do Prometheus para VictoriaMetrics e todos os seus dashboards funcionarão como antes.
Mas você também pode aproveitar recursos adicionais que o VictoriaMetrics oferece.
Vamos passar rapidamente pelas funcionalidades que adicionamos.
Omitir o parâmetro de intervalo – você pode pular o parâmetro de intervalo no Grafana. Quando você não quer obter gráficos estranhos ao aumentar ou diminuir o zoom no painel, é recomendável usar a variável $__interval. Esta é uma variável interna do Grafana e ela mesma escolhe o intervalo de dados. E o VictoriaMetrics pode entender qual deve ser esse intervalo. E você não precisa atualizar todas as suas consultas. 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, passar, referenciar.
Em seguida, a família de funções rollup. A função rollup transforma qualquer série temporal sua em três séries temporais distintas. São elas min, max e avg. Eu considero isso muito prático, pois às vezes pode revelar outliers (anomalias) e imprecisões.
E se você simplesmente utilizar irate ou rate, é provável que você perca alguns casos em que a série temporal se comporta de maneira diferente do que você esperava. Com essa função, é muito mais fácil ver, por exemplo, que o max está muito acima do avg.
Agora, a variável default. Default significa qual valor precisamos desenhar no Grafana, se não tivermos a série temporal no momento. Quando isso acontece? Suponha que você está exportando uma métrica de erros. E você tem um aplicativo tão bom que, quando você o lançou, não houve erros, e não houve erros nas três horas seguintes ou até mesmo um dia. E você tem dashboards que mostram a relação entre sucesso e erro. E eles não mostrarão nada, porque você não tem a métrica de erro. Mas em default você pode indicar qualquer coisa.
Keep_last_Value – mantém o último valor da métrica se ela desaparecer. Se o Prometheus não encontrá-la na próxima coleta dentro de 5 minutos, então aqui iremos lembrar seu último valor e seus gráficos não quebrarão novamente.
Scrape_interval – mostra com que frequência o Prometheus coleta dados sobre sua métrica, com que frequência. Aqui você pode ver se houve alguma perda, por exemplo.
Label replace – uma função popular. Mas consideramos que ela é um pouco complicada, pois aceita vários argumentos. E você não apenas precisa lembrar de 5 argumentos, mas também se lembrar da ordem deles.
Por isso, por que não simplificá-los? Ou seja, dividi-los em funções menores com uma sintaxe clara.
E agora a parte mais interessante. Por que consideramos que isso é PromQL estendido? Porque suportamos Expressões de Tabela Comum. Você pode escanear o QR Code (), conferir os links com exemplos, com um playground, onde você pode executar consultas diretamente no VictoriaMetrics sem precisar instalá-lo, apenas pelo navegador.
E o que exatamente é isso? Essa consulta acima é uma consulta bastante popular. Eu acredito que em qualquer dashboard de muitas empresas você usa o mesmo filtro em toda parte. Normalmente é assim. Mas quando você precisa adicionar um novo filtro, tem que atualizar cada painel ou baixar o dashboard, abrir em JSON, fazer um buscar e substituir, o que também leva tempo. Por que não salvar 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 consultas, e o dashboard pode ser enorme ou pode haver vários deles. E como eu gostaria de resolver esse problema no Grafana?
Eu resolvo esse problema assim: eu crio um commonFilter e nele defino esse filtro, e depois o reutilizo nas consultas. Mas se você fizer isso agora, não funcionará, porque o Grafana não permite que você use variáveis dentro de variáveis de consulta. E isso é um pouco estranho.
E por isso eu criei uma versão que permite fazer isso. E se você está interessado ou quer esse recurso, apoie ou dê um deslike, se não gosta da ideia.
Agora, sobre o PromQL estendido. Aqui definimos não apenas uma variável, mas uma função inteira. Chamamos essa função de ru (uso de recursos). E essa função aceita recursos livres, limite de recurso e filtro. O sintaxe parece bem simples. E é muito fácil usar essa função e calcular a porcentagem de memória livre que temos. Ou seja, quanto de memória temos, qual é o limite e como filtrar. Isso parece muito mais conveniente se você escrever tudo isso, reutilizando os mesmos filtros, porque isso se tornaria uma consulta muito grande.
Aqui está um exemplo de uma solicitação muito grande. Ele vem do painel oficial do NodeExporter para o Grafana. Mas eu entendo pouco do que está acontecendo aqui. Ou seja, claro que entendo se olhar de perto, mas a quantidade de parênteses pode rapidamente desmotivar alguém a entender o que está acontecendo. E por que não simplificá-lo e torná-lo mais claro?
Por exemplo, assim, destacando as partes significativas em variáveis. E então fazendo sua matemática básica. Isso já se parece mais com programação, é isso que eu gostaria de ver no futuro no Grafana.
Aqui está um segundo exemplo de como podemos torná-lo ainda mais simples, se já tivéssemos essa função ru, que já está disponível diretamente no VictoriaMetrics. E você simplesmente passa o valor em cache que você declarou no CTE.
Eu já falei sobre como é importante usar a linguagem de programação apropriada. E, provavelmente, em cada empresa, algo único acontece no Grafana. E, certamente, você também dá acesso ao Grafana para seus desenvolvedores, e eles fazem algo próprio. E todos fazem isso de maneiras diferentes. O ideal seria que tudo fosse mais uniforme, ou seja, que se chegasse a um padrão comum.
Suponha que você tenha não apenas engenheiros de sistema, mas talvez até especialistas, devops ou SRE. Pode ser que tenha especialistas que sabem o que é monitoramento, conhecem o Grafana, ou seja, eles trabalham com isso há anos e sabem exatamente como fazer corretamente. E eles já escreveram isso 100 vezes e explicaram a todos, mas, por algum motivo, ninguém escuta.
E se eles pudessem incorporar esse conhecimento diretamente no Grafana, para que outros usuários pudessem reutilizar as funções? E se fosse necessário calcular a porcentagem de memória livre, eles simplesmente aplicariam a função. E se os criadores dos exportadores, junto com seu produto, também fornecessem um conjunto de funções sobre como trabalhar com suas métricas, porque eles sabem exatamente o que são as métricas e como calculá-las corretamente?
Na verdade, isso não existe. Eu fiz isso eu mesmo. É o suporte a bibliotecas no Grafana. Suponha que o pessoal que fez o NodeExporter realizou o que eu descrevi. E também forneceram um conjunto de funções.
Ou seja, isso parece mais ou menos assim. Você conecta essa biblioteca no Grafana, vai para a edição e aqui está muito simples em JSON como trabalhar com essa métrica. Ou seja, um conjunto de funções, suas descrições e como elas se desdobram.
Na minha opinião, isso poderia ser útil, porque assim no Grafana você escreveria apenas assim. E o Grafana "diz" que existe tal função com tal biblioteca – vamos usá-la. Acho que isso seria muito legal.
Um pouco sobre VictoriaMetrics. Estamos fazendo muitas coisas interessantes. Confira 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, porque ainda há muitos novatos nisso, bem como sobre escalabilidade vertical e sobre o confronto com o Thanos.
Perguntas:
Vou começar minha pergunta com uma história da vida real. Quando comecei a usar o Grafana pela primeira vez, escrevi uma consulta muito convincente com 5 linhas. No final, resultou em um gráfico muito convincente. Esse gráfico quase foi para produção. Mas ao olhar mais de perto, ficou claro que esse gráfico mostrava uma absoluta bobagem, que não tinha relação alguma com a realidade, embora os números estivessem 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 consulta complexa, da qual depende a decisão de negócios – pedir um verdadeiro container de servidores ou não. E como sabemos se a função que desenha o gráfico se parece com a verdade. Obrigado.
Obrigado pela pergunta. Aqui há duas partes. A primeira – tenho a impressão, com base na minha prática, que a maioria dos usuários, quando olha para seus gráficos, não entende o que eles estão mostrando. Por algum motivo, as pessoas são muito boas em inventar justificativas para qualquer anomalia que ocorra nos gráficos, mesmo que seja um erro dentro da função. E a segunda parte – acho que o uso de tais funções se encaixaria muito melhor na solução do seu problema, ao invés de cada um dos seus desenvolvedores fazer seu planejamento de capacidade e errar com alguma probabilidade.
Como verificar?
Como verificar? Provavelmente, não dá.
Na forma de teste no Grafana.
Qual é a relação com o Grafana? O Grafana traduz essa consulta diretamente para a DataSource.
Adicionando um pouco mais aos parâmetros.
Não, o Grafana não adiciona nada. Pode haver parâmetros GET, como, por exemplo, step. Ele não é claramente especificado, mas você pode sobrescrevê-lo ou não, sendo adicionado automaticamente. Você não escreverá testes aqui. Eu acho que não devemos confiar no Grafana como uma fonte de verdade.
Obrigado pela apresentação! Obrigado pela compressão! Você mencionou o mapeamento de variáveis no gráfico, que no Grafana não se pode usar uma variável dentro de outra variável. Você entende do que estou falando?
Sim.
Isso foi inicialmente uma dor de cabeça quando eu queria criar um alerta no Grafana. E você precisa fazer alertas para cada host separadamente. Essa coisa que você fez, ela funciona para alertas no Grafana?
Se o Grafana não lida com variáveis de forma diferente, então - sim, funcionará. Mas meu conselho é não usar alertas no Grafana de forma alguma, é melhor usar o alertmanager.
Sim, eu o utilizo, mas pareceu mais fácil de configurar no Grafana, obrigado pela dica!
Fonte: habr.com
