Ég legg til að lesa afrit skýrslu Roman Khavronenko "ExtendedPromQL"
Stutt um mig. Ég heiti Roman. Ég vinn hjá CloudFlare og bý í London. En ég er líka viðhaldsaðili VictoriaMetrics.
Og ég er höfundurinn fyrir Grafana og er lítið umboð fyrir ClickHouse.
Við byrjum á fyrsta hlutanum, sem kallast „Þýðingarerfiðleikar“ og þar mun ég tala um þá staðreynd að hvaða tungumál sem er eða jafnvel bara samskiptamál er mjög mikilvægt. Vegna þess að þetta er hvernig þú miðlar hugsunum þínum til annarrar manneskju eða kerfis, hvernig þú mótar beiðni. Fólk á netinu er að rífast um hvaða tungumál sé betra - java eða eitthvað annað. Fyrir sjálfan mig ákvað ég að það væri nauðsynlegt að velja verkefni, því allt þetta er sérstakt.
Við skulum byrja alveg frá byrjun. Hvað er PromQL? PromQL er Prometheus Query Language. Svona myndum við fyrirspurnir í Prometheus til að fá tímaraðargögn, tímaraðir.
Hvað eru tímaraðargögn? Bókstaflega eru þetta þrjár breytur.
Þetta eru:
- Hvað erum við að skoða.
- Þegar við skoðum það.
- Og hvaða gildi sýnir það.
Ef þú skoðar þetta töflu (þetta töflu er úr símanum mínum, sem sýnir tölfræðina yfir skrefin mín), þá geturðu fljótt svarað þessum spurningum hér.
Við erum að skoða skref. Við sjáum merkinguna og við sjáum tímann þegar við horfum á hana. Það er að segja ef þú horfir á þessa skýringarmynd geturðu auðveldlega sagt að á sunnudaginn hafi ég gengið um 15 skref. Þetta eru tímaraðir gögn.
Nú skulum við „brjóta“ (umbreyta) þeim í annað gagnalíkan í formi töflu. Hér höfum við líka það sem við erum að skoða. Hér bætti ég við smá gögnum til viðbótar, sem við munum kalla meta-gögn, það er að segja að það var ekki ég sem fór í gegnum, heldur tveir einstaklingar, til dæmis Jay og Silent Bob. Þetta er það sem við erum að skoða; hvað það sýnir og hvenær það sýnir það gildi.
Nú skulum við reyna að geyma öll þessi gögn í gagnagrunninum. Til dæmis tók ég ClickHouse setningafræðina. Og hér erum við að búa til eina töflu sem heitir „Step“, þ.e.a.s. það sem við erum að skoða. Það er tími hér þegar við lítum á það; hvað það sýnir og nokkur meta-gögn þar sem við munum geyma hver það er: Jay og Silent Bob.
Og til að reyna að sjá þetta allt fyrir okkur munum við nota Grafana, því í fyrsta lagi er það fallegt.
Einnig munum við nota þessa viðbót. Það eru tvær ástæður fyrir þessu. Það fyrsta er vegna þess að ég skrifaði það. Og ég veit nákvæmlega hversu erfitt það er að draga út tímaraðagögn frá ClickHouse til að sýna þau í Grafana.
Við munum birta í grafspjaldinu. Þetta er vinsælasta spjaldið í Grafana og sýnir gildi á móti tíma, þannig að við þurfum aðeins tvær breytur.
Við skulum skrifa einföldustu fyrirspurnina - hvernig á að sýna skrefatölfræði í Grafana, geyma þessi gögn í ClickHouse, í töflunni sem við bjuggum til. Og við skrifum svo einfalda fyrirspurn. Við veljum úr þrepum. Við veljum gildi og veljum tíma þessara gilda, þ.e.a.s. sömu þrjár breytur og við töluðum um.
Og fyrir vikið fáum við þetta graf. Hver veit af hverju hann er svona skrítinn?
Það er rétt, þú þarft að raða eftir tíma.
Og á endanum fáum við betri, en samt undarlega dagskrá. Hver veit hvers vegna? Það er rétt, þátttakendur eru tveir og við gefum tvær tímaraðir í Grafana, því ef við tökumst á við gagnalíkanið aftur, þá er hver tímaröð einstök samsetning af nafni og öllum merkjum lykilgildum.
Þess vegna þurfum við að velja ákveðna manneskju. Við veljum Jay.
Og teikna aftur. Nú lítur grafið út eins og sannleikurinn. Nú er venjuleg dagskrá og allt gengur vel.
Og líklega veist þú hvernig á að gera um það sama, en í Prometheus í gegnum PromQL. Svona nokkurn veginn. Aðeins auðveldara. Og við skulum brjóta þetta allt niður. Við tókum skref. Og sía eftir Jay. Við tilgreinum ekki hér að við þurfum að fá gildi og við veljum ekki tíma.
Nú skulum við reyna að reikna út hreyfihraða Jay eða Silent Bob. Í ClickHouse þurfum við að gera runningDifference, þ.e.a.s. reikna muninn á punktapörum og deila þeim með tíma til að fá nákvæman hraða. Beiðnin mun líta einhvern veginn svona út.
Og hann mun sýna um það bil þessi gildi, þ.e.a.s. um það bil 1,8 skref á sekúndu gerir Silent Bob eða Jay.
Og í Prometheus þú veist hvernig á að gera það líka. Miklu auðveldara en áður.
Og til að gera það líka auðvelt að gera í Grafana bætti ég við svona umbúðum sem lítur mjög út og PromQL. Það heitir Rate Macros, eða hvað sem þú vilt kalla það. Í Grafana skrifarðu bara „gengi“ en einhvers staðar innst inni breytist það í svo stóra beiðni. Og þú þarft ekki einu sinni að skoða það, það er þarna einhvers staðar, en þú sparar mikinn tíma, því að skrifa svona risastórar SQL fyrirspurnir er alltaf dýrt. Þú getur auðveldlega gert mistök og skilur svo ekki hvað er að gerast í langan tíma.
Og þetta er fyrirspurn sem passaði ekki einu sinni á eina glæru og ég þurfti meira að segja að skipta henni í tvo dálka. Þetta er líka beiðni í ClickHouse, sem gerir sama hlutfall, en fyrir báðar tímaraðir: Silent Bob og Jay, þannig að við höfum tvær tímaraðir á pallborðinu. Og þetta er nú þegar mjög erfitt, að mínu mati.
Og samkvæmt Prometheus mun það vera summa (hlutfall). Fyrir ClickHouse gerði ég sérstaka fjölvi sem heitir RateColumns sem lítur út eins og Prometheus fyrirspurn.
Við skoðuðum og það virðist sem PromQL sé allt svo flott, en það hefur auðvitað takmarkanir.
Þetta eru:
- Takmarkað VAL.
- Edge JOIN.
- Enginn stuðningur.
Og ef þú hefur unnið með það í langan tíma, þá veistu að stundum er mjög erfitt að gera eitthvað í PromQL, og í SQL geturðu gert næstum allt, því allir þessir valkostir sem við töluðum um gætu verið í SQL . En væri þægilegt að nota það? Og þetta fær mig til að halda að það sé ekki alltaf öflugasta tungumálið sem er þægilegast.
Þess vegna þarftu stundum að velja tungumál fyrir verkefni. Þetta er eins og barátta milli Batman og Superman. Það er ljóst að Superman er sterkari, en Batman gat sigrað hann því hann er praktískari og vissi nákvæmlega hvað hann var að gera.
Og næsti hluti er Extending PromQL.
Enn og aftur um VictoriaMetrics. Hvað er VictoriaMetrics? Þetta er tímaraðargagnagrunnur, hann er í OpenSource, við dreifum stak- og klasaútgáfum hans. Samkvæmt viðmiðunum okkar er það það hraðasta sem er á markaðnum núna og það er svipað hvað varðar þjöppun, þ.e.a.s. lifandi fólk tilkynnir um þjöppun upp á um 0,4 bæti á punkt, þegar Prometheus er með 1,2-1,4.
Við styðjum ekki aðeins Prometheus. Við styðjum InfluxDB, Graphite, OpenTSDB.
Þú getur "skrifað" í okkur, það er, þú getur flutt gömul gögn.
Og við vinnum líka fullkomlega með Prometheus og Grafana, þ.e.a.s. við styðjum PromQL vélina. Og í Grafana geturðu einfaldlega breytt Prometheus endapunktinum í VictoriaMetrics og öll mælaborðin þín munu virka eins og þau gerðu.
En þú getur líka notað aukaflögur frá VictoriaMetrics.
Við munum fljótt fara í gegnum eiginleikana sem við höfum bætt við.
Slepptu millibilsparam - þú getur sleppt færibreytubili í Grafana. Þegar þú vilt ekki fá skrítið graf þegar þú stækkar/út í spjaldið er mælt með því að nota breytuna $__interval. Þetta er innri Grafana breyting og hún velur sjálf gagnasviðið. Og VictoriaMetrics getur sjálf skilið hvað þetta svið ætti að vera. Og þú þarft ekki að uppfæra allar beiðnir þínar. Það verður miklu auðveldara.
Önnur aðgerðin er millibilsvísun. Þú getur notað þetta bil í tjáningunum þínum. Þú getur margfaldað, deilt, flutt, vísað til þess.
Næst er upprifjunaraðgerðafjölskyldan. Samantektaraðgerðin breytir hvaða tímaröð sem er í þrjár aðskildar tímaraðir. Þetta eru lágmark, hámark og meðaltal. Mér finnst það mjög þægilegt, vegna þess að stundum getur það sýnt einhverjar útlínur (frávik) og ónákvæmni.
Og ef þú ert bara að reiðast eða meta, þá geturðu sennilega misst af sumum tilfellum þar sem tímaröðin hegðar sér ekki eins og þú ætlaðir þér. Það er miklu auðveldara að sjá með þessari aðgerð, segjum að max sé mjög mikið undir meðaltali.
Næst er sjálfgefna breytan. Sjálfgefið - þetta þýðir hvaða gildi við þurfum að draga í Grafana ef við erum ekki með tímaröð í augnablikinu. Hvenær gerist það? Segjum að þú flytur út villumælingar. Og þú ert með svo flott forrit að þegar þú byrjar ertu með engar villur og jafnvel engar villur næstu þrjár klukkustundir eða jafnvel á dag. Og þú ert með mælaborð sem sýna tengsl frá árangri til villu. Og þeir munu ekki sýna þér neitt vegna þess að þú ert ekki með villumælingu. Og sjálfgefið er hægt að tilgreina hvað sem er.
Keep_last_Value - vistar síðasta gildi mæligildisins ef það vantar. Ef Prometheus eftir næstu skafa fann það ekki innan 5 mínútna, þá munum við hér síðasta gildi þess og töflurnar þínar munu ekki brotna aftur.
Scrape_interval - sýnir hversu oft Prometheus safnar gögnum um mælikvarða þína, með hvaða tíðni. Hér má til dæmis sjá skarðið.
Skipta um merkimiða er vinsæll eiginleiki. En við teljum að þetta sé svolítið flókið vegna þess að það þarf heiltalna rök. Og þú þarft ekki aðeins að muna 5 rökin, heldur muna einnig röð þeirra.
Því ekki að gera þær einfaldari? Það er að segja, skiptu því niður í litlar aðgerðir með skýrri setningafræði.
Og nú það áhugaverðasta. Af hverju höldum við að það sé framlengt PromQL? Vegna þess að við styðjum Common Table Expression. Þú getur fylgst með QR kóðanum (), sjá tengla með dæmum, frá leikvellinum, þar sem þú getur keyrt fyrirspurnir beint í VictoriaMetrics án þess að setja það bara upp í vafranum.
Og hvað er það? Þessi beiðni að ofan er nokkuð vinsæl beiðni. Ég held að í hvaða mælaborði sem er í mörgum fyrirtækjum notarðu sömu síuna fyrir allt. Yfirleitt svo. En þegar þú þarft að bæta við einhverri nýrri síu þarftu að uppfæra hvert spjald, eða hlaða niður mælaborðinu, opna það í JSON, finna út, sem tekur líka tíma. Af hverju ekki að geyma þetta gildi í breytu og endurnýta það? Það lítur út að mínu mati miklu einfaldara og skýrara.
Til dæmis þegar ég þarf að uppfæra síur í Grafana í öllum beiðnum og mælaborðið getur verið risastórt eða jafnvel verið nokkrar af þeim. Og hvernig myndi ég vilja leysa þetta vandamál í Grafana?
Ég leysi þetta vandamál svona: Ég bý til commonFilter og skilgreini þessa síu í honum og svo endurnota ég hana í fyrirspurnum. En ef þú gerir það sama núna mun það ekki virka vegna þess að Grafana leyfir þér ekki að nota breytur inni í fyrirspurnarbreytum. Og það er svolítið skrítið.
Og svo bjó ég til valmöguleika sem gerir þér kleift að gera þetta. Og ef þú hefur áhuga eða vilt slíkan eiginleika, þá skaltu styðja eða mislíka ef þér líkar ekki við þessa hugmynd.
Meira um PromQL framlengt. Hér skilgreinum við ekki aðeins breytu, heldur beint heilt fall. Og við köllum það ru (auðlindanotkun). Og þessi aðgerð tekur við ókeypis auðlindum, auðlindamörkum og síu. Setningafræðin virðist vera einföld. Og það er mjög auðvelt að nota þessa aðgerð og reikna út hlutfall af lausu minni sem við höfum. Það er, hversu mikið minni við höfum, hvaða mörk og hvernig á að sía. Það lítur miklu betur út ef þú myndir skrifa þetta allt með því að endurnýta sömu síurnar, því það myndi breytast í stóra, stóra fyrirspurn.
Og hér er dæmi um svo stóra, stóra beiðni. Það er frá opinberu NodeExporter mælaborðinu fyrir Grafana. En ég skil ekki alveg hvað er í gangi hérna. Það er auðvitað, ég skil það ef þú skoðar vel, en fjöldi sviga getur strax dregið úr hvatanum til að skilja hvað er að gerast hér. Og hvers vegna ekki að gera það einfaldara og skýrara?
Til dæmis, eins og þetta, að draga fram mikilvæga hluti eða hluta í breytum. Og gerðu svo grunn stærðfræðina þína. Þetta er nú þegar meira eins og forritun, þetta er það sem ég myndi vilja sjá í framtíðinni í Grafana.
Hér er annað dæmi um hvernig við getum gert það enn auðveldara ef við hefðum nú þegar þessa ru aðgerð og hún er þegar til beint í VictoriaMetrics. Og svo sendirðu bara skyndiminni gildið sem þú gafst upp í CTE.
Ég hef þegar talað um hversu mikilvægt það er að nota rétt forritunarmál. Og líklega er eitthvað annað að gerast í Grafana í öllum fyrirtækjum. Og líklega veitirðu forriturum þínum aðgang að Grafana og verktaki gerir eitthvað af sínu. Og þeir gera það allir á annan hátt. En ég vildi hafa það einhvern veginn eins, það er að segja, minnkað í sameiginlegan staðal.
Segjum að þú sért ekki einu sinni bara með kerfisfræðinga, kannski ertu jafnvel með sérfræðinga, devops eða SREs. Kannski ertu með sérfræðinga sem vita hvað vöktun er, vita hvað Grafana er, þ.e.a.s. þeir hafa verið að vinna með þetta í mörg ár og þeir vita nákvæmlega hvernig á að gera þetta rétt. Og þeir hafa þegar skrifað það 100 sinnum og útskýrt það fyrir öllum, en einhverra hluta vegna hlustar enginn.
Hvað ef þeir gætu sett þessa þekkingu beint inn í Grafana svo aðrir notendur gætu endurnýtt aðgerðirnar? Og ef það þyrfti að reikna út hlutfall af lausu minni, þá myndu þeir einfaldlega beita fallinu. En hvað ef höfundar útflytjenda, ásamt vöru þeirra, útveguðu líka safn af aðgerðum, hvernig á að vinna með mæligildi þeirra, vegna þess að þeir vita nákvæmlega hvað þessar mælingar eru og hvernig á að reikna þær rétt?
Þessi er í rauninni ekki til. Hér er það sem ég gerði sjálfur. Þetta er bókasafnsstuðningurinn í Grafana. Segjum að strákarnir sem gerðu NodeExporter gerðu það sem ég lýsti. Og veitti einnig safn eiginleika.
Það er, það lítur eitthvað svona út. Þú tengir þetta bókasafn við Grafana, þú ferð í klippingu og hér er mjög einfalt í JSON hvernig á að vinna með þennan mælikvarða. Það er að segja einhver mengi aðgerða, lýsingu þeirra og hvað þær þróast í.
Að mínu mati gæti þetta verið gagnlegt, því þá skrifar maður bara svona í Grafana. Og Grafana "segir" þér að það sé til svo og svo aðgerð frá svona og svo bókasafni - við skulum nota það. Ég held að það væri mjög flott.
Smá um VictoriaMetrics. Við gerum margt áhugavert. Lestu greinar okkar um þjöppun, um samkeppni okkar við önnur tímaröð gagnaforrit, útskýringu okkar á því hvernig á að vinna með PromQL, því það eru mun fleiri byrjendur í þessu, sem og um lóðréttan sveigjanleika og um árekstra við Thanos.
Spurningar:
Ég byrja spurninguna mína á einfaldri lífssögu. Þegar ég byrjaði fyrst að nota Grafana skrifaði ég mjög sannfærandi 5 línu fyrirspurn. Lokaniðurstaðan er mjög sannfærandi graf. Þetta graf hefur næstum farið í framleiðslu. En við nánari athugun kom í ljós að þetta graf sýnir algjöra vitleysu sem hefur ekkert með raunveruleikann að gera, þó tölurnar falli á það bil sem við bjuggumst við að sjá. Og spurningin mín. Við erum með bókasöfn, við höfum aðgerðir, en hvernig skrifum við próf fyrir Grafana? Þú hefur skrifað flókna fyrirspurn sem hefur áhrif á viðskiptaákvörðun - að panta alvöru gám af netþjónum eða panta ekki. Og eins og við vitum er þetta fall sem teiknar línurit svipað og sannleikann. Þakka þér fyrir.
Takk fyrir spurninguna. Hér eru tveir hlutar. Í fyrsta lagi fæ ég til kynna, byggt á reynslu minni, að flestir notendur, þegar þeir skoða töflurnar sínar, skilji ekki hvað þeir eru að sýna þeim. Einhvern veginn er fólk mjög gott í að koma með afsökun fyrir hvers kyns fráviki sem gerist á töflunum, jafnvel þótt það sé galli inni í falli. Og seinni hlutinn - mér sýnist að notkun slíkra aðgerða væri miklu betur til þess fallin að leysa vandamál þitt, í stað þess að hver og einn af forriturum þínum geri sína eigin getuáætlun og gerir mistök með einhverjum líkindum.
Hvernig á að athuga?
Hvernig á að athuga? Örugglega ekki.
Sem próf í Grafana.
Og hvað með Grafana? Grafana þýðir þessa beiðni beint í DataSource.
Með því að bæta smá við breytur.
Nei, ekkert er bætt við Grafana. Það geta verið GET færibreytur, svo sem skref. Það er ekki sérstaklega tilgreint, en þú getur hnekið því, þú getur ekki hnekið því, en það er bætt við sjálfkrafa. Þú skrifar ekki próf hér. Ég held að þú ættir ekki að treysta á Grafana hér sem sannleiksbrunn.
Takk fyrir skýrsluna! Takk fyrir samþjöppunina! Þú minntist á að kortleggja breytu í línuriti, að í Grafana er ekki hægt að nota breytu í breytu. Skilurðu hvað ég á við?
Já ég er.
Þetta var upphaflega höfuðverkur þegar ég vildi gera viðvörun í Grafana. Og þar þarftu að gera viðvörun fyrir hvern gestgjafa fyrir sig. Hér er þetta sem þú gerðir, virkar það fyrir viðvaranir í Grafana?
Ef Grafana hefur ekki aðgang að breytum á annan hátt, þá já, það mun virka. En mitt ráð er að nota alerting alls ekki í Grafana, þú ættir að nota alertmanager.
Já, ég nota það, en það virtist bara auðveldara að setja upp í Grafana, en takk fyrir ábendinguna!
Heimild: www.habr.com