Proszę zapoznać się z transkrypcją wystąpienia Romana Hawronienki "ExtendedPromQL"
Krótko o mnie. Nazywam się Roman. Pracuję w CloudFlare, mieszkam w Londynie. Ale jestem także maintainerem VictoriaMetrics.
I jestem autorem dla Grafany i – to mały proxy dla ClickHouse.
Zaczniemy od pierwszej części, która nosi tytuł „Trudności w tłumaczeniu”, gdzie będę opowiadać o tym, że każdy język, a nawet po prostu język komunikacji, jest bardzo ważny. Ponieważ to sposób, w jaki przekazujesz swoje myśli innej osobie lub systemowi, jak formułujesz zapytanie. Ludzkość w Internecie spiera się, który język jest lepszy – java czy inny. Dla siebie zdecydowałem, że trzeba wybierać w zależności od zadania, ponieważ wszystko jest specyficzne.
Zacznijmy od początku. Czym jest PromQL? PromQL to język zapytań Prometheusa. To sposób, w jaki formułujemy zapytania w Prometheusie, aby uzyskać dane szeregów czasowych.
Czym są dane szeregów czasowych? Jeśli chodzi o dosłowne znaczenie, to są trzy parametry.
One to:
- Na co patrzymy.
- Kiedy na to patrzymy.
- I jaka wartość się pokazuje.
Jeśli spojrzysz na ten wykres (ten wykres jest z mojego telefonu, który pokazuje statystyki moich kroków), to można szybko odpowiedzieć na te pytania.
Patrzymy na kroki. Widzimy wartość i czas, kiedy na to patrzymy. To znaczy, patrząc na ten wykres, łatwo można powiedzieć, że w niedzielę przeszedłem około 15 000 kroków. To są dane szeregów czasowych.
Teraz rozłóżmy je (przekształćmy) w inną model danych w postaci tabeli. Tutaj również mamy to, na co patrzymy. Dodałem tutaj trochę dodatkowych danych, które nazwaliśmy metadanymi, to znaczy, że to nie ja przeszedłem, a dwie osoby, powiedzmy, Jay i Silent Bob. To jest to, na co patrzymy; co to pokazuje i kiedy pokazuje tę wartość.
Teraz spróbujmy zachować wszystkie te dane w bazie danych. Dla przykładu użyłem składni ClickHouse. I tutaj tworzymy jedną tabelę, która nazywa się „Kroki”, to znaczy, na co patrzymy. Tutaj jest czas, kiedy na to patrzymy; co to pokazuje i jakieś metadane, gdzie będziemy przechowywać, kto to: Jay i Silent Bob.
I aby spróbować zwizualizować to wszystko, użyjemy Grafany, ponieważ, po pierwsze, to ładne.
Również będziemy korzystać z tej wtyczki. Są na to dwie przyczyny. Po pierwsze, ponieważ ją napisałem. I dokładnie wiem, jak trudno jest wydobywać dane szeregów czasowych z ClickHouse, aby pokazać je w Grafanie.
Wyświetlimy to w Graph Panel. To najpopularniejszy panel w Grafanie, który pokazuje zależność wartości od czasu, więc potrzebujemy tylko dwóch parametrów.
Napiszmy najprostsze zapytanie — jak pokazać statystykę kroków w Grafanie, przechowując te dane w ClickHouse, w tej tabeli, którą stworzyliśmy. I piszemy takie proste zapytanie. Wybieramy z kroków. Wybieramy wartość i wybieramy czas tych wartości, tzn. te same trzy parametry, o których mówiliśmy.
I w rezultacie otrzymamy taki wykres. Kto wie, dlaczego jest taki dziwny?
Właśnie, trzeba posortować według czasu.
I w końcu otrzymamy lepszy, ale wciąż dziwny wykres. Kto wie, dlaczego? Właśnie, są dwaj uczestnicy, a w Grafanie oddajemy dwa szeregi czasowe, ponieważ jeśli przyjrzeć się modelowi danych jeszcze raz, to każdy szereg czasowy to unikalna kombinacja nazwy i wszystkich par klucz-wartość etykiet.
Dlatego musimy wybrać konkretnego człowieka. Wybieramy Jaya.
I rysujemy jeszcze raz. Teraz wykres przypomina rzeczywistość. Teraz to normalny wykres i wszystko działa dobrze.
I prawdopodobnie wiecie, jak zrobić mniej więcej to samo, ale w Prometheusie przez PromQL. Mniej więcej tak. Trochę prościej. I jeszcze rozbijemy to wszystko. Braliśmy kroki. I filtrujemy po Jayu. Tutaj nie wskazujemy, że musimy otrzymać wartość i nie wybieramy czasu.
A teraz spróbujmy obliczyć prędkość poruszania się Jaya lub Silent Boba. W ClickHouse musimy zastosować runningDifference, tzn. obliczyć różnicę między parami punktów i podzielić je przez czas, aby uzyskać dokładną prędkość. Zapytanie będzie wyglądać mniej więcej tak.
I pokaże to mniej więcej takie wartości, tzn. Silent Bob lub Jay wykonują około 1,8 kroku na sekundę.
I w Prometheusie wiecie, jak to zrobić również. Dużo łatwiej niż wcześniej.
Aby to było tak samo proste do zrobienia w Grafanie, dodałem taką owijającą funkcję, która wygląda bardzo podobnie do PromQL. Nazywa się Rate Macros lub jak tylko chcecie ją nazwać. W Grafanie piszecie po prostu „rate”, ale gdzieś w głębi przekształca się to w tak dużą kwerendę. I nie musicie nawet na nią patrzeć, gdzieś tam jest, ale oszczędzacie mnóstwo czasu, ponieważ pisanie takich ogromnych zapytań SQL zawsze wiąże się z kosztami. Możecie łatwo popełnić błąd i potem długo nie rozumieć, co się dzieje.
A to jest zapytanie, które nie zmieściło się nawet na jednym slajdzie, więc musiałem je podzielić na dwie kolumny. To również zapytanie w ClickHouse, które robi to samo co rate, ale dla obu szeregów czasowych: zarówno dla Silent Boba, jak i dla Jaya, abyśmy mieli dwa szeregi czasowe na panelu. I to już jest bardzo skomplikowane, moim zdaniem.
W przypadku Prometheusa to będzie sum (rate). Dla ClickHouse stworzyłem osobny makro, który nazywa się RateColumns, który wygląda jak zapytanie w Prometheus.
Spojrzeliśmy i wydaje się, że PromQL jest świetny, ale ma oczywiście swoje ograniczenia.
One to:
- Ograniczone SELECT.
- Ograniczone JOIN.
- Brak wsparcia dla HAVING.
I jeśli długo z nim pracowaliście, to wiecie, że czasami bardzo trudno jest coś zrobić w PromQL, a w SQL można praktycznie wszystko, ponieważ wszystkie te opcje, o których teraz rozmawialiśmy, można było zrobić w SQL. Ale czy byłoby wygodnie z tego korzystać? To prowadzi mnie do myśli, że nie zawsze najpotężniejszy język może być najwygodniejszy.
Dlatego czasami trzeba wybierać język odpowiedni do zadań. To jak bitwa Batmana z Supermanem. Jasne, że Superman jest silniejszy, ale Batman zdołał go pokonać, ponieważ był bardziej praktyczny i dokładnie wiedział, co robi.
A następna część – to Extending PromQL.
Jeszcze raz o VictoriaMetrics. Czym jest VictoriaMetrics? To baza danych szeregów czasowych, jest w OpenSource, dystrybuujemy jej wersje pojedyncze i klastrowe. Z naszych benchmarków wynika, że jest najszybsza na rynku i pod względem kompresji podobnie, czyli żywi ludzie raportują kompresję na poziomie około 0,4 bajta na punkt, podczas gdy w Prometheus to 1,2–1,4.
Obsługujemy nie tylko Prometheus. Obsługujemy InfluxDB, Graphite, OpenTSDB.
Można w nas "pisać", tzn. można przenosić stare dane.
I jeszcze idealnie współpracujemy z Prometheusem i Grafaną, czyli wspieramy silnik PromQL. I w Grafanie możecie po prostu zmienić punkt końcowy Prometheusa na VictoriaMetrics i wszystkie wasze pulpity będą działać jak wcześniej.
Ale możesz także korzystać z dodatkowych funkcji, które oferuje VictoriaMetrics.
Szybko przejdziemy przez funkcje, które dodaliśmy.
Omiń parametr interwału – możesz pomijać parametry interwału w Grafana. Gdy nie chcesz uzyskiwać dziwnych wykresów przy powiększaniu lub pomniejszaniu na panelu, zaleca się użycie zmiennej $__interval. To wewnętrzna zmienna Grafana i ona sama wybiera zakres danych. A VictoriaMetrics potrafi sama zrozumieć, jaki ten zakres powinien być. Nie musisz aktualizować wszystkich swoich zapytań. To będzie znacznie łatwiejsze.
Drugą funkcją jest referencjonowanie interwałów. Możesz używać tego interwału w swoich wyrażeniach. Możesz go mnożyć, dzielić, przekazywać, odnosić się do niego.
Dalej mamy rodzinę funkcji rollup. Funkcja rollup przekształca każdą Twoją serię czasową w trzy oddzielne serie czasowe. To min, max i avg. Uważam, że to bardzo wygodne, ponieważ czasami może to pokazać jakieś odstępstwa (anomalia) i nieścisłości.
I jeśli po prostu robisz irate lub rate, to prawdopodobnie możesz przeoczyć niektóre przypadki, kiedy seria czasowa zachowuje się inaczej niż się spodziewałeś. Z tą funkcją znacznie łatwiej zobaczyć, na przykład, że max znacznie odbiega od avg.
Dalej zmienna default. Default oznacza, jaką wartość musimy wyświetlić w Grafana, jeśli w danym momencie nie mamy serii czasowej. Kiedy to się dzieje? Na przykład, eksportujesz jakąś metrykę dotyczącą błędów. A Twoja aplikacja jest tak świetna, że po uruchomieniu nie masz błędów, a nawet przez następne trzy godziny lub nawet dzień. Masz panele, które pokazują stosunek sukcesów do błędów. I nic Ci nie wykażą, ponieważ nie masz metryki błędów. A w default możesz wskazać cokolwiek.
Keep_last_Value – zapamiętuje ostatnią wartość metryki, jeśli zniknęła. Jeśli Prometheus po następnym skanowaniu nie znajdzie jej przez 5 minut, to zapamiętamy jej ostatnią wartość, a Twoje wykresy znowu się nie zepsują.
Scrape_interval – pokazuje, jak często Prometheus zbiera dane na temat Twojej metryki, z jaką częstotliwością. Tutaj możesz zobaczyć pominięcie, na przykład.
Label replace – popularna funkcja. Ale uważamy, że jest nieco skomplikowana, ponieważ przyjmuje pięć argumentów. I musisz pamiętać nie tylko o pięciu argumentach, ale także o ich kolejności.
Dlatego dlaczego nie uprościć ich? To znaczy, podzielić na mniejsze funkcje z czytelną składnią.
A teraz najciekawsze. Dlaczego uważamy, że to jest rozbudowane PromQL? Ponieważ wspieramy wspólne wyrażenia tabelaryczne. Możesz zeskanować kod QR (), aby zobaczyć linki z przykładami, z placem zabaw, gdzie możesz wykonać zapytania bez instalacji VictoriaMetrics, po prostu w przeglądarce.
I co to właściwie jest? To zapytanie na górze – to dość popularne zapytanie. Myślę, że w każdym pulpicie nawigacyjnym w wielu firmach używasz tego samego filtru dla wszystkiego. Zwykle tak jest. Ale gdy musisz dodać nowy filtr, musisz zaktualizować każdy panel lub pobrać pulpit nawigacyjny, otworzyć go w JSON, wykonać find replace, co również zajmuje czas. Dlaczego nie zachować tę wartość w zmiennej i ponownie ją wykorzystać? To wydaje mi się znacznie prostsze i bardziej zrozumiałe.
Na przykład, gdy muszę aktualizować filtry w Grafanie we wszystkich zapytaniach, a pulpit nawigacyjny może być ogromny lub może być ich nawet kilka. Jak chciałbym rozwiązać ten problem w Grafanie?
Rozwiązuję ten problem w ten sposób: robię commonFilter i w nim definiuję ten filtr, a potem ponownie go wykorzystuję w zapytaniach. Ale jeśli teraz zrobisz tak samo, to nie zadziała, ponieważ Grafana nie pozwala ci używać zmiennych w zmiennych zapytań. I to jest trochę dziwne.
I dlatego zrobiłem taką wersję, która to umożliwia. A jeśli jesteś zainteresowany lub chciałbyś tę funkcję, to wesprzyj ją lub daj dislike, jeśli ta idea ci się nie podoba.
Dalej mówimy o rozszerzonym PromQL. Tutaj definiujemy nie tylko zmienną, ale bezpośrednio całą funkcję. Nazywamy ją ru (zużycie zasobów). Funkcja ta przyjmuje wolne zasoby, ograniczenia zasobów i filtr. Składnia wydaje się być prosta. I bardzo łatwo jest używać tej funkcji i obliczyć procent wolnej pamięci u nas. To znaczy, ile mamy pamięci, jakie mamy ograniczenia i jak filtrować. To wydaje się znacznie wygodniejsze, gdybyś wszystko pisał, ponownie wykorzystując te same filtry, ponieważ to zamieniłoby się w ogromne zapytanie.
Oto przykład takiego ogromnego zapytania. Pochodzi z oficjalnego panelu NodeExporter dla Grafany. Ale słabo rozumiem, co tutaj się dzieje. To znaczy, oczywiście, rozumiem, jeśli się przyjrzę, ale liczba nawiasów może natychmiast obniżyć motywację do rozumienia, co tutaj się wydarzyło. A czemu by nie uczynić tego prostszym i bardziej zrozumiałym?
Na przykład, tak, wydobywając znaczące rzeczy lub części do zmiennych. A potem przeprowadzając swoją podstawową matematykę. To już bardziej przypomina programowanie, to jest to, co chciałbym zobaczyć w przyszłości w Grafanie.
Oto drugi przykład, jak moglibyśmy to jeszcze uprościć, gdybyśmy już mieli tę funkcję ru, a ona już istnieje w VictoriaMetrics. Wtedy po prostu przekazujesz zaksięgowaną wartość, którą zadeklarowałeś w CTE.
Już mówiłem, jak ważne jest użycie odpowiedniego języka programowania. I prawdopodobnie w każdej firmie w Grafanie dzieje się coś własnego. I zapewne dajesz dostęp do Grafany swoim programistom, a programiści robią coś swojego. A wszyscy robią to jakoś inaczej. A chciałbym, żeby jakoś było to jednolite, to znaczy sprowadzić to do wspólnego standardu.
Załóżmy, że masz nie tylko inżynierów systemowych, może masz nawet ekspertów, DevOpsów lub SRE. Może masz ekspertów, którzy wiedzą, co to jest monitorowanie, wiedzą, co to jest Grafana, to znaczy pracują z tym od lat i dokładnie wiedzą, jak robić to prawidłowo. I pisali to już 100 razy i wszystkim wyjaśniali, ale z jakiegoś powodu nikt ich nie słucha.
A co, jeśli mogliby te wiedzę bezpośrednio umieścić w Grafanie, aby inni użytkownicy mogli ponownie wykorzystywać te funkcje? A jeśli trzeba by było obliczyć procent wolnej pamięci, po prostu zastosowaliby funkcję. A co, jeśli twórcy eksporterów, wraz ze swoim produktem, dostarczali również zestaw funkcji do pracy z ich metrykami, ponieważ dokładnie wiedzą, czym są te metryki i jak je prawidłowo obliczać?
To na prawdę nie istnieje. To zrobiłem sam. To wsparcie dla bibliotek w Grafanie. Załóżmy, że chłopaki, którzy zrobili NodeExporter, zrobili to, o czym rozmawiałem. I również dostarczyli zestaw funkcji.
To znaczy, wygląda to mniej więcej tak. Podłączasz tę bibliotekę w Grafanie, przechodzisz do edytora i wszystko jest bardzo prosto opisane w JSON-ie, jak działać z tą metryką. To znaczy jakiś zestaw funkcji, ich opisy i w co one są rozwijane.
Moim zdaniem, to mogłoby być przydatne, ponieważ wtedy w Grafanie pisałbyś po prostu w ten sposób. I Grafana "mówi", że jest taka a taka funkcja z tej biblioteki – użyjmy jej. Wydaje mi się, że to byłoby naprawdę świetne.
Kilka słów o VictoriaMetrics. Robimy wiele interesujących rzeczy. Przeczytaj nasze artykuły o kompresji, o naszych rywalizacjach z innymi aplikacjami danych szeregów czasowych, nasze wyjaśnienie, jak pracować z PromQL, ponieważ w tym wciąż jest wielu nowicjuszy, a także o pionowej skalowalności i o rywalizacji z Thanos.
Pytania:
Zacznę moje pytanie od prostej historii z życia. Kiedy po raz pierwszy zacząłem korzystać z Grafany, napisałem bardzo przekonujące zapytanie składające się z 5 linii. Ostatecznie powstał bardzo przekonujący wykres. Ten wykres niemal trafił do produkcji. Ale po bliższym przyjrzeniu okazało się, że ten wykres pokazuje absolutne bzdury, które nie mają żadnego związku z rzeczywistością, chociaż liczby mieszczą się w zakresie, który spodziewaliśmy się zobaczyć. I moje pytanie. Mamy biblioteki, mamy funkcje, a jak piszemy testy dla Grafany? Napisałeś skomplikowane zapytanie, od którego zależy decyzja biznesowa – zamówić prawdziwy kontener serwerów, czy nie zamawiać. I jak możemy mieć pewność, że ta funkcja, która rysuje wykres, przypomina prawdę. Dziękuję.
Dziękuję za pytanie. To ma dwie części. Po pierwsze – mam wrażenie, na podstawie mojego doświadczenia, że większość użytkowników, kiedy patrzy na swoje wykresy, nie rozumie, co one im pokazują. Dlaczegoś ludzie są bardzo dobrzy w wymyślaniu usprawiedliwienia dla każdej anomalii, która występuje na wykresach, nawet jeśli jest to błąd wewnątrz funkcji. A druga część – wydaje mi się, że użycie takich funkcji lepiej odpowiadałoby na rozwiązanie twojego problemu, zamiast tego, by każdy z twoich deweloperów robił swój planowanie pojemności i mylił się z jakimś prawdopodobieństwem.
Jak sprawdzić?
Jak sprawdzić? Prawdopodobnie, wcale.
W formie testu w Grafanie.
Co ma z tym wspólnego Grafana? Grafana przekłada to zapytanie bezpośrednio na DataSource.
Dodając trochę do parametrów.
Nie, w Grafanie niczego nie dodają. Mogą być parametry GET, jak na przykład step. Nie jest on wyraźnie określony, ale możesz go nadpisać, możesz go nie nadpisywać, ale dodawany jest automatycznie. Nie napiszesz tutaj testów. Myślę, że nie warto polegać na Grafanie jako źródle prawdy.
Dziękuję za prezentację! Dziękuję za kompresję! Wspomniałeś o mapowaniu zmiennej w wykresie, że w Grafanie nie można używać zmiennej w zmiennej. Rozumiesz, o co mi chodzi?
Tak.
To była pierwotnie prawdziwa zmora, kiedy chciałem stworzyć alert w Grafanie. Musisz tworzyć alert dla każdego hosta z osobna. Czy ta rzecz, którą zrobiłeś, działa dla alertów w Grafanie?
Jeśli Grafana nie odwołuje się do zmiennych w inny sposób, to tak, będzie działać. Ale moją radą jest, aby w ogóle nie używać alertów w Grafanie, lepiej użyć alertmanagera.
Tak, używam go, ale po prostu w Grafanie wydawało się to łatwiejsze w konfiguracji, ale dziękuję za radę!
Źródło: habr.com
