Proponuję przeczytać transkrypcję raportu Romana Chawronienki „ExtendedPromQL”
Krótko o mnie. Nazywam się Roman. Pracuję dla CloudFlare i mieszkam w Londynie. Ale jestem także opiekunem VictoriaMetrics.
A ja jestem autorem dla Grafany i to mały serwer proxy dla ClickHouse.
Zaczniemy od pierwszej części, która nosi tytuł „Trudności w tłumaczeniu” i w niej opowiem o tym, że każdy język, a nawet tylko język komunikacji jest bardzo ważny. Ponieważ w ten sposób przekazujesz swoje myśli innej osobie lub systemowi, w jaki sposób formułujesz prośbę. Ludzie w Internecie spierają się o to, który język jest lepszy - java czy jakiś inny. Dla siebie zdecydowałem, że konieczne jest wybranie zadania, ponieważ wszystko to jest specyficzne.
Zacznijmy od samego początku. Co to jest PromQL? PromQL to język zapytań Prometheusa. W ten sposób tworzymy zapytania w Prometeuszu, aby uzyskać dane szeregów czasowych, szeregi czasowe.
Co to są dane szeregów czasowych? Dosłownie są to trzy parametry.
Czy to, że:
- Na co patrzymy.
- Kiedy na to patrzymy.
- I jaką wartość pokazuje.
Jeśli spojrzysz na ten wykres (ten wykres jest z mojego telefonu, który pokazuje statystyki moich kroków), to tutaj możesz szybko odpowiedzieć na te pytania.
Patrzymy na stopnie. Widzimy znaczenie i widzimy czas, kiedy na to patrzymy. Czyli patrząc na ten diagram można spokojnie powiedzieć, że w niedzielę przeszedłem około 15 000 kroków. To są dane szeregów czasowych.
Teraz „złammy” (przekształćmy) je w inny model danych w postaci tabeli. Tutaj też mamy to, na co patrzymy. Tutaj dodałem trochę dodatkowych danych, które nazwiemy metadanymi, czyli to nie ja przeszedłem, ale dwie osoby, na przykład Jay i Cichy Bob. Oto, na co patrzymy; co pokazuje i kiedy pokazuje tę wartość.
Teraz spróbujmy zapisać wszystkie te dane w bazie danych. Na przykład wziąłem składnię ClickHouse. I tutaj tworzymy jedną tabelę o nazwie „Kroki”, czyli to, na co patrzymy. Jest taki czas, kiedy na to patrzymy; co pokazuje i niektóre metadane, w których będziemy przechowywać, kto to jest: Jay i Cichy Bob.
A żeby spróbować to wszystko zwizualizować, użyjemy Grafany, bo po pierwsze jest piękna.
Również użyjemy tej wtyczki. Są tego dwa powody. Po pierwsze dlatego, że to napisałem. I dokładnie wiem, jak trudno jest wyciągnąć dane szeregów czasowych z ClickHouse, aby pokazać je w Grafanie.
Wyświetlimy w panelu wykresu. Jest to najpopularniejszy panel w Grafanie i pokazuje wartość w funkcji czasu, więc potrzebujemy tylko dwóch parametrów.
Napiszmy najprostsze zapytanie - jak wyświetlić statystyki kroków w Grafanie, przechowując te dane w ClickHouse, w tabeli, którą stworzyliśmy. I piszemy takie proste zapytanie. Wybieramy spośród kroków. Wybieramy wartość i wybieramy czas tych wartości, czyli te same trzy parametry, o których mówiliśmy.
W rezultacie otrzymujemy ten wykres. Kto wie, dlaczego jest taki dziwny?
Zgadza się, musisz posortować według czasu.
I w końcu dostajemy lepszy, ale wciąż dziwny harmonogram. Kto wie dlaczego? Zgadza się, jest dwóch uczestników, aw Grafanie rozdajemy dwa szeregi czasowe, ponieważ jeśli ponownie zajmiemy się modelem danych, to każdy szereg czasowy jest unikalną kombinacją nazwy i wszystkich etykiet par klucz-wartość.
Dlatego musimy wybrać konkretną osobę. Wybieramy Jaya.
I rysuj ponownie. Teraz wykres wygląda jak prawda. Teraz jest to normalny harmonogram i wszystko działa dobrze.
I prawdopodobnie wiesz, jak zrobić to samo, ale w Prometheus przez PromQL. Mniej więcej tak. Trochę łatwiej. I rozbijmy to wszystko. Podjęliśmy kroki. I filtruj według Jaya. Nie określamy tutaj, że musimy uzyskać wartość i nie wybieramy czasu.
Teraz spróbujmy obliczyć prędkość ruchu Jaya lub Cichego Boba. W ClickHouse będziemy musieli wykonać runDifference, czyli obliczyć różnicę między parami punktów i podzielić je przez czas, aby uzyskać dokładną prędkość. Żądanie będzie wyglądać mniej więcej tak.
I pokaże w przybliżeniu te wartości, czyli około 1,8 kroku na sekundę robi Cichy Bob lub Jay.
A w Prometeuszu też wiesz, jak to zrobić. Dużo łatwiej niż wcześniej.
A żeby było to łatwe również w Grafanie, dodałem takie oto opakowanie, które wygląda bardzo podobnie do PromQL. Nazywa się to Makrami Oceny lub jakkolwiek chcesz to nazwać. W Grafanie po prostu piszesz „ocena”, ale gdzieś w głębi zamienia się to w tak wielką prośbę. I nawet nie trzeba na to patrzeć, gdzieś tam jest, ale oszczędza się mnóstwo czasu, bo pisanie tak ogromnych zapytań SQL jest zawsze drogie. Możesz łatwo popełnić błąd, a potem przez długi czas nie rozumieć, co się dzieje.
I to jest zapytanie, które nawet nie zmieściło się na jednym slajdzie, a nawet musiałem je podzielić na dwie kolumny. Jest to również żądanie w ClickHouse, które robi tę samą stawkę, ale dla obu szeregów czasowych: Cichy Bob i Jay, dzięki czemu mamy dwa szeregi czasowe na panelu. A to już jest moim zdaniem bardzo trudne.
A według Prometeusza będzie to suma (stawka). Dla ClickHouse stworzyłem osobne makro o nazwie RateColumns, które wygląda jak zapytanie Prometheus.
Przyjrzeliśmy się i wydaje się, że PromQL jest taki fajny, ale ma oczywiście ograniczenia.
Czy to, że:
- Ograniczony WYBIERZ.
- Edge JOIN.
- Brak POSIADANIA wsparcia.
A jeśli pracowałeś z tym przez długi czas, to wiesz, że czasami bardzo trudno jest coś zrobić w PromQL, a w SQL można zrobić prawie wszystko, ponieważ wszystkie te opcje, o których właśnie mówiliśmy, można było zrobić w SQL . Ale czy korzystanie z niego byłoby wygodne? I to sprawia, że myślę, że nie zawsze najpotężniejszy język może być najwygodniejszy.
Dlatego czasami trzeba wybrać język dla zadań. To jak bitwa między Batmanem a Supermanem. Oczywiste jest, że Superman jest silniejszy, ale Batman był w stanie go pokonać, ponieważ jest bardziej praktyczny i dokładnie wiedział, co robi.
Następna część to rozszerzenie PromQL.
Jeszcze raz o VictoriaMetrics. Co to jest VictoriaMetrics? To jest baza danych szeregów czasowych, jest w OpenSource, dystrybuujemy jej wersje pojedyncze i klastrowe. Według naszych testów porównawczych jest to najszybszy obecnie dostępny na rynku i podobny pod względem kompresji, tj. żyjący ludzie zgłaszają kompresję na poziomie około 0,4 bajta na punkt, podczas gdy Prometheus ma 1,2-1,4.
Wspieramy nie tylko Prometeusza. Obsługujemy InfluxDB, Graphite, OpenTSDB.
Możesz w nas „napisać”, czyli przenieść stare dane.
Doskonale współpracujemy też z Prometheusem i Grafaną, czyli wspieramy silnik PromQL. A w Grafanie możesz po prostu zmienić punkt końcowy Prometheus na VictoriaMetrics, a wszystkie Twoje pulpity nawigacyjne będą działać tak, jak wcześniej.
Ale możesz także użyć dodatkowych żetonów dostarczonych przez VictoriaMetrics.
Szybko przejrzymy dodane przez nas funkcje.
Pomiń parametr interwału - możesz pominąć parametr interwału w Grafanie. Jeśli nie chcesz otrzymywać dziwnych wykresów podczas powiększania/pomniejszania panelu, zaleca się użycie zmiennej $__interval. Jest to wewnętrzna zmiana Grafany i sama wybiera zakres danych. A VictoriaMetrics sama może zrozumieć, jaki powinien być ten zakres. I nie musisz aktualizować wszystkich żądań. Będzie dużo łatwiej.
Drugą funkcją jest odniesienie do interwału. Możesz użyć tego odstępu w swoich wyrażeniach. Można mnożyć, dzielić, przenosić, odwoływać się do tego.
Następna jest rodzina funkcji zestawiania. Funkcja zestawienia przekształca dowolne szeregi czasowe w trzy oddzielne szeregi czasowe. Są to min, max i śr. Uważam to za bardzo wygodne, ponieważ czasami może pokazać pewne wartości odstające (anomalie) i nieścisłości.
A jeśli po prostu robisz irate lub rate, prawdopodobnie możesz przegapić niektóre przypadki, w których szeregi czasowe nie zachowują się tak, jak zamierzałeś. O wiele łatwiej jest to zobaczyć dzięki tej funkcji, powiedzmy, że max jest bardzo odbiegający od średniej.
Następna jest zmienna domyślna. Default - oznacza to, jaką wartość musimy narysować w Grafanie, jeśli w danej chwili nie mamy szeregu czasowego. Kiedy to się dzieje? Załóżmy, że eksportujesz dane o błędach. I masz tak fajną aplikację, że po uruchomieniu nie masz żadnych błędów, a nawet żadnych błędów przez następne trzy godziny, a nawet dzień. I masz pulpity nawigacyjne, które pokazują relacje od sukcesu do błędu. I nic ci nie pokażą, ponieważ nie masz miernika błędu. Domyślnie możesz określić wszystko.
Keep_last_Value - zapisuje ostatnią wartość metryki, jeśli jej brakuje. Jeśli Prometheus po kolejnym zeskrobaniu nie znalazł go w ciągu 5 minut, to tutaj zapamiętamy jego ostatnią wartość i Twoje wykresy już się nie psują.
Scrape_interval - pokazuje, jak często Prometheus zbiera dane o Twojej metryce, z jaką częstotliwością. Tutaj możesz zobaczyć na przykład przepustkę.
Popularną funkcją jest zastępowanie etykiet. Uważamy jednak, że jest to trochę skomplikowane, ponieważ wymaga argumentów całkowitych. I musisz nie tylko zapamiętać 5 argumentów, ale także zapamiętać ich kolejność.
Dlaczego więc nie uczynić ich prostszymi? Oznacza to, że podziel go na małe funkcje z jasną składnią.
A teraz najciekawsze. Dlaczego uważamy, że jest to rozszerzony PromQL? Ponieważ obsługujemy wspólne wyrażenia tabelowe. Możesz śledzić kod QR (), zobacz linki z przykładami, z placu zabaw, gdzie możesz uruchamiać zapytania bezpośrednio w VictoriaMetrics bez instalowania go tylko w przeglądarce.
I co to jest? Ta prośba z góry jest dość popularną prośbą. Myślę, że w każdym dashboardzie w wielu firmach używasz tego samego filtra do wszystkiego. Zwykle tak. Ale kiedy musisz dodać jakiś nowy filtr, musisz zaktualizować każdy panel lub pobrać pulpit nawigacyjny, otworzyć go w JSON, wykonać find replace, co również wymaga czasu. Dlaczego nie zapisać tej wartości w zmiennej i nie użyć jej ponownie? Moim zdaniem wygląda to dużo prościej i przejrzyściej.
Na przykład, gdy muszę zaktualizować filtry w Grafanie we wszystkich żądaniach, a dashboard może być ogromny lub może być ich nawet kilka. A jak chciałbym rozwiązać ten problem w Grafanie?
Rozwiązuję ten problem w następujący sposób: tworzę commonFilter i definiuję w nim ten filtr, a następnie ponownie używam go w zapytaniach. Ale jeśli zrobisz to samo teraz, to nie zadziała, ponieważ Grafana nie pozwala na używanie zmiennych wewnątrz zmiennych zapytania. I to jest trochę dziwne.
Dlatego stworzyłem opcję, która pozwala ci to zrobić. A jeśli jesteś zainteresowany lub chcesz takiej funkcji, to wspieraj lub nie podobaj się, jeśli nie podoba ci się ten pomysł.
Więcej o rozszerzeniu PromQL. Tutaj definiujemy nie tylko zmienną, ale bezpośrednio całą funkcję. I nazywamy to ru (wykorzystanie zasobów). Ta funkcja akceptuje wolne zasoby, limit zasobów i filtr. Składnia wydaje się prosta. I bardzo łatwo jest użyć tej funkcji i obliczyć procent wolnej pamięci, którą mamy. Czyli ile pamięci mamy, jaki limit i jak filtrować. Wygląda o wiele lepiej, gdybyś napisał to wszystko ponownie przy użyciu tych samych filtrów, ponieważ zamieniłoby się to w duże, duże zapytanie.
A oto przykład tak wielkiej, wielkiej prośby. Pochodzi z oficjalnego pulpitu nawigacyjnego NodeExporter dla Grafana. Ale nie bardzo rozumiem o co tutaj chodzi. To znaczy, oczywiście, rozumiem, jeśli przyjrzysz się uważnie, ale liczba nawiasów może natychmiast zmniejszyć motywację do zrozumienia, co się tutaj dzieje. A dlaczego nie uczynić tego prostszym i bardziej przejrzystym?
Na przykład w ten sposób, podkreślając istotne rzeczy lub części w zmiennych. A potem wykonaj podstawową matematykę. To już bardziej przypomina programowanie, to właśnie chciałbym zobaczyć w przyszłości w Grafanie.
Oto drugi przykład tego, jak możemy to jeszcze bardziej ułatwić, gdybyśmy mieli już tę funkcję ru i istnieje ona już bezpośrednio w VictoriaMetrics. A potem po prostu przekazujesz wartość z pamięci podręcznej, którą zadeklarowałeś w CTE.
Mówiłem już o tym, jak ważne jest używanie odpowiedniego języka programowania. I chyba w Grafanie w każdej firmie dzieje się coś innego. I prawdopodobnie nadal dajesz swoim programistom dostęp do Grafany, a programiści robią coś własnego. I wszyscy robią to w inny sposób. Ale chciałem, żeby to było jakoś tak samo, to znaczy sprowadzone do wspólnego standardu.
Powiedzmy, że nie masz nawet inżynierów systemowych, może masz nawet ekspertów, devopsów lub SRE. Może masz ekspertów, którzy wiedzą, czym jest monitoring, wiedzą, czym jest Grafana, czyli pracują z tym od lat i dokładnie wiedzą, jak to zrobić dobrze. I napisali to już 100 razy i wyjaśnili to wszystkim, ale z jakiegoś powodu nikt nie słucha.
Co by było, gdyby mogli umieścić tę wiedzę bezpośrednio w Grafanie, aby inni użytkownicy mogli ponownie korzystać z funkcji? A gdyby trzeba było obliczyć procent wolnej pamięci, po prostu zastosowaliby tę funkcję. Ale co by było, gdyby twórcy eksporterów wraz ze swoim produktem udostępnili również zestaw funkcji, jak pracować z ich metrykami, bo dokładnie wiedzą, czym te metryki są i jak je poprawnie obliczyć?
Ten naprawdę nie istnieje. Oto, co sam zrobiłem. To jest wsparcie biblioteki w Grafanie. Powiedzmy, że faceci, którzy stworzyli NodeExporter, zrobili to, co opisałem. A także zapewnił zestaw funkcji.
To znaczy wygląda to mniej więcej tak. Podłączasz tę bibliotekę do Grafany, przechodzisz do edycji, a tutaj jest bardzo proste w JSON, jak pracować z tą metryką. To znaczy jakiś zestaw funkcji, ich opis i to, w co się rozwijają.
Moim zdaniem mogłoby się to przydać, bo wtedy pisałbyś w Grafanie tak po prostu. A Grafana "mówi" że jest taka a taka funkcja z takiej a takiej biblioteki - skorzystajmy. Myślę, że to byłoby bardzo fajne.
Trochę o VictoriaMetrics. Robimy wiele ciekawych rzeczy. Przeczytaj nasze artykuły o kompresji, o naszej konkurencji z innymi aplikacjami do przetwarzania danych szeregów czasowych, o tym, jak pracować z PromQL, bo nowicjuszy jest w tym znacznie więcej, a także o pionowej skalowalności i konfrontacji z Thanosem.
Pytania:
Zacznę moje pytanie od prostej historii z życia. Kiedy po raz pierwszy zacząłem używać Grafany, napisałem bardzo przekonujące 5-liniowe zapytanie. Efektem końcowym jest bardzo przekonujący wykres. Ten wykres prawie wszedł do produkcji. Ale po bliższym przyjrzeniu się okazało się, że ten wykres pokazuje absolutną bzdurę, która nie ma nic wspólnego z rzeczywistością, chociaż liczby mieszczą się w przedziale, którego się spodziewaliśmy. I moje pytanie. Mamy biblioteki, mamy funkcje, ale jak piszemy testy dla Grafany? Napisałeś złożone zapytanie, które wpływa na decyzję biznesową - zamówić prawdziwy kontener serwerów czy nie. A jak wiemy, ta funkcja rysująca wykres jest podobna do prawdy. Dziękuję.
Dzięki za pytanie. Tutaj są dwie części. Po pierwsze, mam wrażenie, bazując na moim doświadczeniu, że większość użytkowników, patrząc na swoje wykresy, nie rozumie, co im pokazują. W jakiś sposób ludzie są bardzo dobrzy w wymyślaniu wymówek dla wszelkich anomalii występujących na wykresach, nawet jeśli jest to błąd wewnątrz funkcji. I druga część - wydaje mi się, że użycie takich funkcji byłoby znacznie lepiej dostosowane do rozwiązania twojego problemu, zamiast tego, aby każdy z twoich programistów sam planował wydajność i popełniał błędy z pewnym prawdopodobieństwem.
Jak sprawdzić?
Jak sprawdzić? Prawdopodobnie nie.
Jako test w Grafanie.
A co z Grafaną? Grafana tłumaczy to żądanie bezpośrednio do DataSource.
Dodając trochę do parametrów.
Nie, nic nie jest dodawane do Grafany. Mogą istnieć parametry GET, takie jak step. Nie jest to wyraźnie określone, ale można je zastąpić, nie można go zastąpić, ale jest dodawane automatycznie. Tu nie pisze się testów. Nie sądzę, że powinieneś polegać tutaj na Grafanie jako na źródle prawdy.
Dzięki za raport! Dzięki za kompresję! Przypomniałeś sobie o mapowaniu zmiennej na wykresie, że w Grafanie nie można użyć zmiennej w zmiennej. Rozumiesz co mam na myśli?
Tak.
To był początkowo ból głowy, kiedy chciałem zrobić alert w Grafanie. I tam musisz zrobić alert dla każdego hosta osobno. Oto, co zrobiłeś, czy działa to w przypadku alertów w Grafanie?
Jeśli Grafana nie uzyskuje dostępu do zmiennych w inny sposób, to tak, będzie działać. Ale moja rada to w ogóle nie używać alertów w Grafanie, lepiej użyj alertmanager.
Tak, używam go, ale po prostu wydawało mi się, że łatwiej jest skonfigurować w Grafanie, ale dzięki za wskazówkę!
Źródło: www.habr.com