Iesaku izlasīt Romāna Havroņenko ziņojuma “ExtendedPromQL” stenogrammu.
Īsumā par mani. Mani sauc Romāns. Es strādāju CloudFlare un dzīvoju Londonā. Bet es esmu arī VictoriaMetrics uzturētājs.
Un es esmu autors par Grafānu un ir neliels ClickHouse starpniekserveris.
Sāksim ar pirmo daļu, kuras nosaukums ir “Tulkošanas grūtības” un tajā runāšu par to, ka jebkura valoda vai pat tikai saziņas valoda ir ļoti svarīga. Jo šādi tu nodod savas domas citai personai vai sistēmai, kā formulē pieprasījumu. Cilvēki internetā strīdas par to, kura valoda ir labāka - java vai kāda cita. Par sevi es nolēmu, ka man ir jāizvēlas atbilstoši uzdevumam, jo tas viss ir specifisks.
Sāksim no paša sākuma. Kas ir PromQL? PromQL ir Prometheus vaicājumu valoda. Tādā veidā mēs veidojam vaicājumus programmā Prometheus, lai iegūtu laikrindu datus.
Kas ir laikrindu dati? Burtiski tie ir trīs parametri.
Tie ir:
- Ko mēs skatāmies?
- Kad mēs uz to skatāmies.
- Un kādu vērtību tas parāda?
Ja paskatās uz šo diagrammu (šī diagramma ir no mana tālruņa, kas parāda manu soļu statistiku), tā var ātri atbildēt uz šiem jautājumiem.
Mēs skatāmies uz soļiem. Mēs redzam nozīmi un mēs redzam laiku, kad mēs uz to skatāmies. Tas ir, aplūkojot šo diagrammu, jūs varat viegli teikt, ka svētdien es nogāju apmēram 15 000 soļu. Šie ir laikrindu dati.
Tagad "sadalīsim" (pārveidosim) tos citā datu modelī tabulas veidā. Šeit mums ir arī tas, ko mēs skatāmies. Šeit es pievienoju nelielus papildu datus, kurus mēs sauksim par metadatiem, t.i., tas nebija es, kurš to izgāju cauri, bet gan divi cilvēki, piemēram, Džejs un Klusais Bobs. Tas ir tas, ko mēs skatāmies; ko tas parāda un kad tas parāda šo vērtību.
Tagad mēģināsim visus šos datus saglabāt datu bāzē. Piemēram, es izmantoju ClickHouse sintaksi. Un šeit mēs izveidojam vienu tabulu ar nosaukumu “Soļi”, t.i., uz ko mēs skatāmies. Ir laiks, kad mēs uz to skatāmies; ko tas parāda, un daži metadati, kur mēs saglabāsim, kas tas ir: Džejs un Klusais Bobs.
Un, lai mēģinātu to visu vizualizēt, mēs izmantosim Grafana, jo, pirmkārt, tā ir skaista.
Mēs arī izmantosim šo spraudni. Tam ir divi iemesli. Pirmais ir tāpēc, ka es to uzrakstīju. Un es precīzi zinu, cik grūti ir iegūt laikrindu datus no ClickHouse, lai tos parādītu Grafana.
Mēs to parādīsim diagrammu panelī. Šis ir vispopulārākais Grafana panelis, kas parāda vērtības atkarību no laika, tāpēc mums ir nepieciešami tikai divi parametri.
Ierakstīsim visvienkāršāko vaicājumu - kā parādīt soļu statistiku Grafana, saglabājot šos datus ClickHouse, mūsu izveidotajā tabulā. Un mēs rakstām šo vienkāršo pieprasījumu. Mēs izvēlamies no soļiem. Mēs izvēlamies vērtību un šo vērtību laiku, t.i., tos pašus trīs parametrus, par kuriem mēs runājām.
Rezultātā mēs iegūsim šādu grafiku. Kas zina, kāpēc viņš ir tik dīvains?
Tieši tā, mums ir jākārto pēc laika.
Un beigās mēs iegūsim labāku, bet tomēr dīvainu grafiku. Kas zina, kāpēc? Pareizi, ir divi dalībnieki, un mēs Grafana izsniedzam divas laika rindas, jo, ja vēlreiz aplūkojat datu modeli, katra laika rinda ir unikāla nosaukuma un visu atslēgu vērtību etiķešu kombinācija.
Tāpēc mums ir jāizvēlas konkrēta persona. Mēs izvēlamies Džeju.
Un mēs atkal zīmējam. Tagad grafiks izskatās kā patiesība. Tagad tas ir normāls grafiks, un viss darbojas labi.
Un jūs droši vien zināt, kā darīt aptuveni to pašu, bet programmā Prometheus, izmantojot PromQL. Kaut kas tamlīdzīgs. Mazliet vienkāršāk. Un izjauksim to visu. Mēs spērām Steps. Un filtrē pēc Džeja. Mēs šeit nenosakām, ka mums ir jāiegūst vērtība, un mēs neizvēlamies laiku.
Tagad mēģināsim aprēķināt Džeja vai Klusā Boba kustības ātrumu. Programmā ClickHouse mums būs jāveic runDifference, t.i., jāaprēķina starpība starp punktu pāriem un jāsadala ar laiku, lai iegūtu precīzu ātrumu. Pieprasījums izskatīsies apmēram šādi.
Un tas rādīs aptuveni šīs vērtības, t.i., klusais Bobs vai Džejs veic aptuveni 1,8 soļus sekundē.
Un Prometejā jūs arī zināt, kā to izdarīt. Daudz vieglāk, nekā tas bija iepriekš.
Un, lai to būtu viegli izdarīt arī Grafānā, es pievienoju šo iesaiņojumu, kas izskatās ļoti līdzīgs PromQL. To sauc par Rate Macros vai kā vēlaties to saukt. Grafānā jūs vienkārši ierakstāt “likme”, bet kaut kur dziļi tas pārvēršas par šo lielo pieprasījumu. Un jums tas pat nav jāskatās, tas ir kaut kur, bet jūs ietaupāt daudz laika, jo šādu milzīgu SQL vaicājumu rakstīšana vienmēr ir dārga. Var viegli kļūdīties un pēc tam ilgu laiku nesaprast, kas notiek.
Un tas ir pieprasījums, kas pat neietilpa vienā slaidā, un man tas pat bija jāsadala divās kolonnās. Tas ir arī pieprasījums pakalpojumā ClickHouse, kas nodrošina vienādu ātrumu, taču abām laika rindām: Silent Bob un Jay, lai panelī būtu divas laika rindas. Un tas jau ir ļoti grūti, manuprāt.
Un saskaņā ar Prometeju tā būs summa (likme). Programmai ClickHouse es izveidoju atsevišķu makro ar nosaukumu RateColumns, kas izskatās kā vaicājums programmā Prometheus.
Mēs to apskatījām, un šķiet, ka PromQL ir tik foršs, taču tam, protams, ir ierobežojumi.
Tie ir:
- Ierobežota SELECT.
- Robežas JOIN.
- NAV atbalsta.
Un, ja esi ilgi ar to strādājis, tad zini, ka PromQL dažkārt ir ļoti grūti kaut ko izdarīt, bet SQL var gandrīz visu, jo visas šīs opcijas, par kurām tikko runājām, var izdarīt SQL. . Bet vai būtu ērti to izmantot? Un tas man liek domāt, ka visspēcīgākā valoda ne vienmēr var būt ērtākā.
Tāpēc dažreiz uzdevumam ir jāizvēlas valoda. Tas ir kā Betmens, kas cīnās ar Supermenu. Skaidrs, ka Supermens ir spēcīgāks, bet Betmens spēja viņu uzvarēt, jo ir praktiskāks un precīzi zināja, ko dara.
Un nākamā daļa ir PromQL paplašināšana.
Vēlreiz par VictoriaMetrics. Kas ir VictoriaMetrics? Šī ir laikrindu datu bāze, tā ir atvērtā koda versijā, mēs izplatām tās vienas un klasteru versijas. Saskaņā ar mūsu etaloniem tas ir ātrāks nekā jebkas, kas šobrīd ir tirgū, un saspiešana ir līdzīga, t.i., reāli cilvēki ziņo par saspiešanu aptuveni 0,4 baiti uz punktu, savukārt Prometheus ir 1,2–1,4.
Mēs atbalstām ne tikai Prometeju. Mēs atbalstām InfluxDB, Graphite, OpenTSDB.
Jūs varat mums “rakstīt”, tas ir, varat pārsūtīt vecos datus.
Un mēs lieliski strādājam arī ar Prometheus un Grafana, t.i., mēs atbalstām PromQL dzinēju. Programmā Grafana varat vienkārši mainīt Prometheus galapunktu uz VictoriaMetrics, un visi informācijas paneļi darbosies tāpat kā tie.
Taču varat izmantot arī papildu funkcijas, ko nodrošina VictoriaMetrics.
Mēs ātri apskatīsim pievienotās funkcijas.
Izlaist intervāla parametrus — Grafana varat izlaist intervāla parametrus. Ja, tuvinot/tālinot paneli, nevēlaties iegūt dīvainus grafikus, ieteicams izmantot mainīgo $__interval. Šīs ir iekšējas Grafana izmaiņas, un tā atlasa datu diapazonu. Un VictoriaMetrics pati var saprast, kādam vajadzētu būt šim diapazonam. Un jums nav jāatjaunina visi jūsu pieprasījumi. Tas būs daudz vieglāk.
Otrā funkcija ir intervāla atsauce. Jūs varat izmantot šo intervālu savās izteiksmēs. Jūs varat reizināt, dalīt, pārsūtīt, atsaukties uz to.
Nākamā ir apkopošanas funkciju saime. Apkopošanas funkcija pārveido jebkuru jūsu laika rindu trīs atsevišķās laika rindās. Tie ir min, max un vid. Man tas šķiet ļoti ērti, jo dažreiz tas var parādīt dažas novirzes un neprecizitātes.
Un, ja jūs vienkārši darāt dusmas vai vērtējat, tad jūs, iespējams, palaidīsit garām dažus gadījumus, kad laikrindas nedarbojas, kā jūs gaidījāt. Ar šo funkciju ir daudz vieglāk redzēt, pieņemsim, ka max ir ļoti daudz no vid.
Nākamais ir noklusējuma mainīgais. Noklusējums - tas nozīmē, kāda vērtība mums ir jāievelk Grafana, ja mums pašlaik nav laikrindas. Kad tas notiek? Pieņemsim, ka eksportējat dažus kļūdu rādītājus. Un jums ir tik forša lietojumprogramma, ka, startējot, nākamajās trīs stundās vai pat dienā jums nav kļūdu un pat nekādu kļūdu. Un jums ir informācijas paneļi, kas parāda attiecības no panākumiem līdz kļūdām. Un viņi jums neko nerādīs, jo jums nav kļūdu metrikas. Un pēc noklusējuma jūs varat norādīt jebko.
Keep_last_Value — saglabā pēdējo metrikas vērtību, ja tās trūkst. Ja Prometejs to neatradīs 5 minūšu laikā pēc nākamā skrāpējuma, tad šeit mēs atcerēsimies tā pēdējo vērtību un jūsu diagrammas vairs nesaplīsīs.
Scrape_interval — parāda, cik bieži un ar kādu biežumu Prometheus apkopo datus par jūsu metriku. Šeit jūs varat redzēt, piemēram, caurlaidi.
Etiķetes nomaiņa ir populāra funkcija. Bet mēs domājam, ka tas ir nedaudz sarežģīti, jo tas prasa veselus argumentus. Un jums ir ne tikai jāatceras 5 argumenti, bet arī jāatceras to secība.
Tāpēc kāpēc gan tos nepadarīt vienkāršākus? Tas ir, sadaliet to mazās funkcijās ar saprotamu sintaksi.
Un tagad jautrākā daļa. Kāpēc mēs domājam, ka tas ir paplašināts PromQL? Tā kā mēs atbalstām kopējās tabulu izteiksmes. Jūs varat sekot QR kodam (), skatiet saites ar piemēriem no rotaļu laukuma, kur varat izpildīt vaicājumus tieši programmā VictoriaMetrics, neinstalējot to vienkārši pārlūkprogrammā.
Un kas tas ir? Šis iepriekš minētais pieprasījums ir diezgan populārs pieprasījums. Es domāju, ka jebkurā informācijas panelī daudzos uzņēmumos jūs izmantojat vienu un to pašu filtru visam. Parasti tā. Bet, ja jums ir jāpievieno jauns filtrs, jums ir jāatjaunina katrs panelis vai jālejupielādē informācijas panelis, jāatver tas JSON un jāatrod aizstājējs, kas arī prasa laiku. Kāpēc gan nesaglabāt šo vērtību mainīgajā un izmantot to atkārtoti? Tas, manuprāt, izskatās daudz vienkāršāk un skaidrāk.
Piemēram, ja man ir jāatjaunina Grafana filtri visos pieprasījumos, un informācijas panelis var būt milzīgs vai to var būt pat vairāki. Un kā es vēlētos atrisināt šo problēmu Grafānā?
Es atrisinu šo problēmu šādi: izveidoju commonFilter un definēju tajā šo filtru un pēc tam atkārtoti izmantoju to vaicājumos. Bet, ja darīsit to pašu tagad, tas nedarbosies, jo Grafana neļauj izmantot mainīgos vaicājuma mainīgajos. Un tas ir nedaudz dīvaini.
Un tāpēc es izveidoju opciju, kas ļauj jums to izdarīt. Un, ja jūs interesē vai vēlaties šādu funkciju, tad atbalstiet to vai nepatīk, ja jums nepatīk šī ideja.
Vairāk par PromQL paplašināto. Šeit mēs definējam ne tikai mainīgo, bet arī visu funkciju. Un mēs to saucam par ru (resursu izmantošana). Un šī funkcija pieņem bezmaksas resursus, resursu ierobežojumu un filtru. Šķiet, ka sintakse ir vienkārša. Un ir ļoti vienkārši izmantot šo funkciju un aprēķināt brīvās atmiņas procentuālo daudzumu. Tas ir, cik daudz atmiņas mums ir, kādi ir ierobežojumi un kā filtrēt. Daudz ērtāk izskatās, ja tu to visu uzrakstītu, atkārtoti izmantojot tos pašus filtrus, jo tas pārvērstos par lielu, lielu vaicājumu.
Un šeit ir piemērs tik lielam, lielam lūgumam. Tas ir no oficiālā Grafana NodeExporter informācijas paneļa. Bet es tik tikko saprotu, kas šeit notiek. Tas ir, protams, es saprotu, ja paskatās vērīgi, bet iekavās norādītais skaits var uzreiz samazināt motivāciju saprast, kas šeit notiek. Un kāpēc gan to nepadarīt vienkāršāku un skaidrāku?
Piemēram, šādi sadalot nozīmīgas lietas vai daļas mainīgajos. Un tad veiciet pamata matemātiku. Tas jau ir vairāk kā programmēšana, to es vēlētos redzēt nākotnē Grafānā.
Šeit ir otrs piemērs tam, kā mēs to varētu padarīt vēl vienkāršāku, ja mums jau būtu šī ru funkcija, un tā jau pastāv tieši pakalpojumā VictoriaMetrics. Pēc tam jūs vienkārši nododat kešatmiņā saglabāto vērtību, ko deklarējāt CTE.
Es jau runāju par to, cik svarīgi ir izmantot pareizo programmēšanas valodu. Un, iespējams, katrā Grafānas uzņēmumā notiek kaut kas atšķirīgs. Un, iespējams, jūs saviem izstrādātājiem piešķirat piekļuvi programmai Grafana, un izstrādātāji dara savu. Un viņi visi to dara kaut kā savādāk. Bet es gribēju, lai tas būtu kaut kā vienāds, tas ir, lai to samazinātu līdz kopējam standartam.
Pieņemsim, ka jums pat nav tikai sistēmu inženieri, varbūt jums pat ir eksperti, devops vai SRE. Varbūt jums ir eksperti, kas zina, kas ir monitorings, kas zina, kas ir Grafana, tas ir, viņi ir strādājuši ar to gadiem un viņi precīzi zina, kā to izdarīt pareizi. Un viņi jau 100 reizes to ir rakstījuši un visiem skaidrojuši, bet nez kāpēc neviens neklausās.
Ko darīt, ja viņi šīs zināšanas varētu ievietot tieši Grafana, lai citi lietotāji varētu atkārtoti izmantot šīs funkcijas? Un, ja viņiem vajadzēja aprēķināt brīvās atmiņas procentuālo daudzumu, viņi vienkārši izmantos šo funkciju. Kā būtu, ja eksportētāju veidotāji kopā ar savu produktu nodrošinātu arī funkciju kopumu, kā strādāt ar saviem rādītājiem, jo viņi precīzi zina, kas ir šie rādītāji un kā tos pareizi aprēķināt?
Tas īsti neeksistē. Tas ir tas, ko es izdarīju pats. Šis ir Grafana bibliotēkas atbalsts. Pieņemsim, ka puiši, kas izveidoja NodeExporter, izdarīja to, par ko es runāju. Un viņi arī nodrošināja funkciju kopumu.
Tas ir, tas izskatās apmēram šādi. Jūs savienojat šo bibliotēku ar Grafana, sākat rediģēšanu, un JSON ir ļoti vienkārši uzrakstīts, kā strādāt ar šo metriku. Tas ir, daži funkciju kopumi, to apraksts un par ko tās pārvēršas.
Es domāju, ka tas varētu noderēt, jo tad Grafānā jūs rakstītu tieši tāpat. Un Grafana jums “stāsta”, ka no tādas un tādas bibliotēkas ir tāda un tāda funkcija - izmantosim to. Es domāju, ka tas būtu ļoti forši.
Mazliet par VictoriaMetrics. Mēs darām daudz interesantu lietu. Izlasiet mūsu rakstus par saspiešanu, par sacensībām ar citām laikrindu datu lietojumprogrammām, mūsu skaidrojumu par to, kā strādāt ar PromQL, jo šajā jomā vēl ir daudz iesācēju, kā arī par vertikālo mērogojamību un par konfrontāciju ar Thanos.
Jautājumi:
Savu jautājumu sākšu ar vienkāršu dzīvesstāstu. Kad es pirmo reizi sāku lietot Grafana, es uzrakstīju ļoti pārliecinošu vaicājumu, kas bija 5 rindiņas garš. Gala rezultāts ir ļoti pārliecinošs grafiks. Šis grafiks ir gandrīz sācies ražošanā. Bet, papētot rūpīgāk, izrādījās, ka šis grafiks parāda absolūtas muļķības, kurām nav nekāda sakara ar realitāti, lai gan skaitļi ietilpst diapazonā, kuru mēs gaidījām redzēt. Un mans jautājums. Mums ir bibliotēkas, mums ir funkcijas, bet kā mēs rakstām Grafana testus? Jūs esat uzrakstījis sarežģītu pieprasījumu, no kura atkarīgs biznesa lēmums - pasūtīt īstu serveru konteineru vai nepasūtīt. Un, kā mēs zinām, šī funkcija, kas zīmē grafiku, ir līdzīga patiesībai. Paldies.
Paldies par jautājumu. Ir divas daļas. Pirmkārt, man, balstoties uz savu pieredzi, rodas iespaids, ka lielākā daļa lietotāju, skatoties uz savām diagrammām, nesaprot, ko tie rāda. Kādu iemeslu dēļ cilvēki ļoti labi izdomā attaisnojumu jebkurai anomālijai, kas rodas grafikos, pat ja tā ir kļūda funkcijā. Un otrā daļa - man šķiet, ka šādu funkciju izmantošana būtu daudz labāka pieeja tavas problēmas risināšanai, nevis katrs tavs izstrādātājs veiktu savu kapacitātes plānošanu un ar zināmu varbūtību kļūdītos.
Kā pārbaudīt?
Kā pārbaudīt? Visticamāk ne.
Kā pārbaudījums Grafānā.
Kāds sakars Grafanai ar to? Grafana pārvērš šo pieprasījumu tieši datu avotā.
Nedaudz pievienojot parametriem.
Nē, Grafanai nekas nav pievienots. Var būt GET parametri, piemēram, teiksim, solis. Tas nav skaidri norādīts, bet jūs varat to ignorēt vai arī nevar ignorēt, bet tas tiek pievienots automātiski. Jūs šeit nerakstīsit testus. Es nedomāju, ka mums šeit vajadzētu paļauties uz Grafānu kā patiesības avotu.
Paldies par ziņojumu! Paldies par kompresiju! Jūs minējāt mainīgā kartēšanu grafikā, ka programmā Grafana nevar izmantot mainīgo mainīgajā. Vai jūs zināt, ko es domāju?
Jā.
Sākotnēji tās sagādāja galvassāpes, kad vēlējos Grafānā izveidot brīdinājumu. Un tur jums ir jāizdara brīdinājums par katru saimniekdatoru atsevišķi. Vai šī jūsu izveidotā lieta darbojas brīdinājumiem pakalpojumā Grafana?
Ja Grafana nepiekļūst mainīgajiem atšķirīgi, tad jā, tas darbosies. Bet mans padoms ir Grafana neizmantot brīdinājumus, labāk ir izmantot alertmanager.
Jā, es to izmantoju, bet šķita, ka to ir vieglāk iestatīt Grafānā, bet paldies par padomu!
Avots: www.habr.com