„VictoriaMetrics“ yra greita ir keičiamo dydžio DBVS, skirta duomenims saugoti ir apdoroti laiko eilučių pavidalu (įrašą sudaro laikas ir reikšmių rinkinys, atitinkantis šį laiką, pavyzdžiui, gaunamas periodiškai apklausiant jutiklių būseną arba metrikų rinkinys).
Mano vardas Kolobajevas Pavelas. DevOps, SRE, LeroyMerlin, viskas kaip kodas – viskas apie mus: apie mane ir kitus LeroyMerlin darbuotojus.
Yra debesis, pagrįstas „OpenStack“. Yra nedidelė nuoroda į techninį radarą.
Jis sukurtas naudojant „Kubernetes“ aparatinę įrangą, taip pat visas susijusias „OpenStack“ ir registravimo paslaugas.
Tai yra schema, kurią mes sukūrėme. Kai visa tai kūrėme, turėjome Prometheus operatorių, kuris saugojo duomenis pačiame K8s klasteryje. Jis automatiškai suranda, ką reikia šveisti, ir, grubiai tariant, pakiša po kojomis.
Turėsime perkelti visus duomenis už Kubernetes klasterio ribų, nes jei kas nors atsitiks, turime suprasti, kas ir kur.
Pirmasis sprendimas yra tai, kad mes naudojame federaciją, kai turime trečiosios šalies „Prometheus“, kai per federacijos mechanizmą einame į „Kubernetes“ klasterį.
Tačiau čia yra mažų problemų. Mūsų atveju problemos prasidėjo, kai turėjome 250 000 metrikų, o kai buvo 400 000 metrikų, supratome, kad taip dirbti negalime. Padidinome scrape_timeout iki 25 sekundžių.
Kodėl mes turėjome tai padaryti? Prometėjas pradeda skaičiuoti skirtąjį laiką nuo tvoros pradžios. Nesvarbu, kad duomenys vis dar teka. Jei per šį nurodytą laikotarpį duomenys nesujungiami ir seansas neuždaromas per http, tai laikoma, kad seansas nepavyko ir duomenys nepatenka į patį Prometėją.
Visi žino diagramas, kurias gauname, kai trūksta kai kurių duomenų. Tvarkaraščiai suplėšyti ir mes tuo nepatenkinti.
Kitas variantas yra suskaidymas, pagrįstas dviem skirtingais „Prometheus“, naudojant tą patį federacijos mechanizmą.
Pavyzdžiui, tiesiog paimkite juos ir susmulkinkite juos vardu. Tai taip pat gali būti naudojama, bet nusprendėme judėti toliau.
Dabar turėsime kažkaip apdoroti šias šukes. Galite pasiimti „Promxy“, kuris eina į shardų sritį ir padaugina duomenis. Jis veikia su dviem skeveldromis kaip vienas įėjimo taškas. Tai gali būti įgyvendinta per „Promxy“, tačiau tai vis tiek per sunku.
Pirmas variantas – norime atsisakyti federacijos mechanizmo, nes jis labai lėtas.
„Prometheus“ kūrėjai aiškiai sako: „Vaikinai, naudokite kitą TimescaleDB, nes nepalaikysime ilgalaikio metrikų saugojimo“. Tai ne jų užduotis.
Surašome ant lapelio, kad dar reikia iškrauti lauke, kad nesusidėliotume visko vienoje vietoje.
Antrasis trūkumas yra atminties suvartojimas. Taip, suprantu, kad daugelis sakys, kad 2020 metais pora gigabaitų atminties kainuoja centą, bet vis tiek.
Dabar turime kūrimo ir gaminių aplinką. Dev. tai yra apie 9 gigabaitai 350 000 metrikų. Gamybinėje versijoje tai yra 14 gigabaitų ir šiek tiek daugiau nei 780 000 metrikų. Tuo pačiu metu mūsų saugojimo laikas yra tik 30 minučių. Tai yra blogai. O dabar paaiškinsiu kodėl.
Skaičiuojame, tai yra su pusantro milijono metrikų, ir jau esame arti jų, projektavimo etape gauname 35-37 gigabaitus atminties. Tačiau jau 4 milijonai metrikų reikalauja apie 90 gigabaitų atminties. Tai yra, jis buvo apskaičiuotas naudojant Prometheus kūrėjų pateiktą formulę. Pažiūrėjome koreliaciją ir supratome, kad nenorime mokėti poros milijonų už serverį vien už stebėjimą.
Mes ne tik padidinsime mašinų skaičių, bet ir stebime pačias virtualias mašinas. Todėl kuo daugiau virtualių mašinų, tuo daugiau įvairių metrikų ir tt Mes turėsime ypatingą savo klasterio augimą metrikos požiūriu.
Su vietos diske ne viskas čia taip blogai, bet norėčiau patobulinti. Iš viso per 15 dienų gavome 120 gigabaitų, iš kurių 100 suspaustų duomenų, 20 nesuspaustų duomenų, bet visada norisi mažiau.
Atitinkamai užrašome dar vieną tašką – tai yra didelis resursų suvartojimas, kurį vis tiek norime sutaupyti, nes nenorime, kad mūsų stebėjimo klasteris sunaudotų daugiau resursų nei mūsų klasteris, valdantis OpenStack.
Yra dar vienas Prometėjo trūkumas, kurį mes patys nustatėme, tai bent kažkoks atminties apribojimas. Su Prometėju čia viskas daug blogiau, nes jame visai nėra tokių vingių. Naudoti limitą dockere taip pat negalima. Jei staiga jūsų RAF nukrito ir yra 20–30 gigabaitų, tada pakilti reikės labai ilgai.
Tai dar viena priežastis, kodėl Prometėjas mums netinka, t.y. negalime riboti atminties suvartojimo.
Galima būtų sugalvoti tokią schemą. Šios schemos mums reikia norint organizuoti HA klasterį. Norime, kad mūsų metrika būtų pasiekiama visada ir visur, net jei serveris, kuriame saugoma ši metrika, sugenda. Ir todėl turėsime sukurti tokią schemą.
Ši schema sako, kad turėsime šukių dubliavimą ir atitinkamai sunaudotų išteklių sąnaudų dubliavimą. Jį galima keisti beveik horizontaliai, tačiau vis dėlto išteklių suvartojimas bus pragariškas.
Trūkumai tokia tvarka, kokia mes juos sau užrašėme:
- Metrikas reikia įkelti iš išorės.
- Didelis išteklių suvartojimas.
- Nėra jokio būdo apriboti atminties suvartojimą.
- Sudėtingas ir daug išteklių reikalaujantis HA įgyvendinimas.
Patys nusprendėme, kad nuo Prometėjo kaip saugyklos tolstame.
Mes nustatėme sau papildomų reikalavimų, kurių mums reikia. Tai:
- Tai promql palaikymas, nes Prometheus jau daug kas parašyta: užklausos, įspėjimai.
- Ir tada mes turime Grafana, kuri jau yra parašyta lygiai taip pat Prometheus kaip backend. Nenoriu perrašyti prietaisų skydelių.
- Norime sukurti normalią HA architektūrą.
- Norime sumažinti bet kokių išteklių vartojimą.
- Yra dar vienas mažas niuansas. Negalime naudoti įvairių tipų debesų metrikos rinkimo sistemų. Kol kas nežinome, kas pateks į šiuos rodiklius. Ir kadangi ten gali nuskristi bet kas, turime apsiriboti vietos išdėstymu.
Pasirinkimo buvo mažai. Surinkome viską, ką turėjome patirties. Pažiūrėjome į Prometėjo puslapį integracijos skiltyje, perskaitėme krūvą straipsnių ir pamatėme, kas ten yra. O patys pasirinkome VictoriaMetrics kaip Prometėjo pakaitalą.
Kodėl? Nes:
- Žino promql.
- Yra modulinė architektūra.
- Grafana pakeitimų nereikia.
- Ir svarbiausia, kad metrikų saugojimą savo įmonėje tikriausiai teiksime kaip paslaugą, todėl iš anksto ieškome įvairių apribojimų, kad vartotojai galėtų ribotai naudotis visais klasterio ištekliais, nes yra galimybė. kad tai bus daugiabučiai.
Palyginkime pirmą kartą. Tą patį Prometėją paimame į klasterio vidų, išorinis Prometėjas eina į jį. Pridėti per nuotolinįWrite VictoriaMetrics.
Iškart padarysiu išlygą, kad čia šiek tiek padidėjo „VictoriaMetrics“ procesoriaus suvartojimas. „VictoriaMetrics“ wiki nurodo, kurie parametrai yra geriausi. Mes juos patikrinome. Jie labai gerai sumažino procesoriaus suvartojimą.
Mūsų atveju „Prometheus“, esančio „Kubernetes“ klasteryje, atminties suvartojimas reikšmingai nepadidėjo.
Lyginame du tų pačių duomenų šaltinius. Prometėjuje matome tuos pačius trūkstamus duomenis. „VictoriaMetrics“ viskas gerai.
Vietos diske bandymo rezultatai. Mes, „Prometheus“, iš viso gavome 120 gigabaitų. „VictoriaMetrics“ jau gauname 4 gigabaitus per dieną. Yra šiek tiek kitoks mechanizmas, nei esame įpratę matyti Prometėjuje. Tai yra, duomenys jau gana gerai suglaudinami per dieną, per pusvalandį. Per dieną, per pusvalandį jie jau buvo nupjauti gerai, nepaisant to, kad vėliau duomenys vis tiek bus prarasti. Dėl to sutaupėme vietos diske.
Taip pat taupome atminties išteklių sąnaudas. Testavimo metu „Prometheus“ turėjome įdiegtą virtualioje mašinoje – 8 branduoliai, 24 gigabaitai. Prometėjas valgo beveik viską. Jis nukrito ant OOM Killer. Tuo pačiu metu į jį buvo supilta tik 900 000 aktyvių metrikų. Tai yra apie 25 000–27 000 metrikų per sekundę.
„VictoriaMetrics“ paleidome dviejų branduolių virtualioje mašinoje su 8 gigabaitais RAM. Mums pavyko priversti „VictoriaMetrics“ gerai veikti, kai 8 GB įrenginyje sutvarkėme keletą dalykų. Galų gale mes jį išlaikėme iki 7 gigabaitų. Tuo pačiu metu turinio, ty metrikos, pristatymo greitis buvo net didesnis nei „Prometheus“.
CPU tapo daug geresnis, palyginti su Prometheus. Čia „Prometheus“ sunaudoja 2,5 branduolio, o „VictoriaMetrics“ – tik 0,25 branduolio. Pradžioje – 0,5 branduolio. Susiliedamas jis pasiekia vieną šerdį, tačiau tai yra labai, labai retai.
Mūsų atveju dėl akivaizdžių priežasčių pasirinkome „VictoriaMetrics“; norėjome sutaupyti pinigų ir tai padarėme.
Iš karto perbraukime du punktus – metrikų įkėlimą ir didelį išteklių suvartojimą. Ir mes tiesiog turime nuspręsti du dalykus, kuriuos dar turime sau.
Čia iš karto padarysiu rezervaciją, VictoriaMetrics laikome metrikų saugykla. Tačiau kadangi greičiausiai suteiksime „VictoriaMetrics“ kaip saugyklą visam „Leroy“, turime apriboti tuos, kurie naudos šią klasterį, kad jie jo mums neduotų.
Yra puikus parametras, leidžiantis apriboti laiką, duomenų kiekį ir vykdymo laiką.
Taip pat yra puikus pasirinkimas, leidžiantis apriboti atminties sunaudojimą, tokiu būdu mes galime rasti patį balansą, kuris leis mums pasiekti normalų veikimo greitį ir tinkamą išteklių suvartojimą.
Atėmus dar vieną tašką, t.y. užbraukti tašką – negalite apriboti atminties suvartojimo.
Pirmosiose iteracijose išbandėme „VictoriaMetrics Single Node“. Toliau pereiname prie „VictoriaMetrics Cluster“ versijos.
Čia mes turime laisvą ranką atskirti skirtingas „VictoriaMetrics“ paslaugas, priklausomai nuo to, kuo jos veiks ir kokius išteklius sunaudos. Tai labai lankstus ir patogus sprendimas. Mes tai naudojome sau.
Pagrindiniai VictoriaMetrics Cluster Version komponentai yra vmstsorage. Jų gali būti N skaičius. Mūsų atveju jų kol kas yra 2.
Ir yra vminsert. Tai tarpinis serveris, leidžiantis mums: organizuoti dalijimąsi tarp visų saugyklų, apie kurias pranešėme, taip pat leidžia kopiją, t. y. turėsite ir dalijimą, ir kopiją.
„Vminsert“ palaiko „Prometheus“ „OpenTSDB“, „Graphite“, „InfluxDB“ ir „remoteWrite“ protokolus.
Taip pat yra vmselect. Pagrindinė jo užduotis yra eiti į vmstorage, gauti iš jų duomenis, panaikinti šių duomenų dublikatus ir perduoti juos klientui.
Yra nuostabus dalykas, vadinamas vmagent. Mums ji labai patinka. Tai leidžia konfigūruoti tiksliai kaip Prometėjas ir vis tiek daryti viską tiksliai kaip Prometėjas. Tai yra, ji renka metrikas iš skirtingų objektų ir paslaugų ir siunčia jas į vminsert. Tada viskas priklauso nuo jūsų.
Kita puiki paslauga yra „vmalert“, kuri leidžia naudoti „VictoriaMetrics“ kaip užpakalinę programą, gauti apdorotus duomenis iš „vminsert“ ir siųsti juos „vmselect“. Jis apdoroja pačius įspėjimus ir taisykles. Įspėjimų atveju įspėjimą gauname per alertmanager.
Yra wmauth komponentas. Galime arba ne (dar neapsisprendėme dėl to) naudoti kaip daugialypės klasterių versijos autorizacijos sistemą. Jis palaiko „Prometheus“ nuotolinio rašymo funkciją ir gali autorizuoti pagal URL arba, tiksliau, antrąją jo dalį, kur galite arba negalite rašyti.
Taip pat yra vmbackup, vmrestore. Iš esmės tai yra visų duomenų atkūrimas ir atsarginė kopija. Gali daryti S3, GCS, failą.
Pirmoji mūsų klasterio iteracija buvo atlikta karantino metu. Tuo metu replikos nebuvo, todėl mūsų iteracija susideda iš dviejų skirtingų ir nepriklausomų grupių, į kurias gaudavome duomenis per remoteWrite.
Čia aš padarysiu išlygą, kad kai perėjome iš VictoriaMetrics Single Node į VictoriaMetrics Cluster Version, likome su tais pačiais sunaudotais ištekliais, t.y. pagrindinis yra atmintis. Maždaug taip buvo paskirstyti mūsų duomenys, t.y. išteklių suvartojimas.
Čia jau pridėta kopija. Visa tai sujungėme į vieną gana didelę klasterį. Visi mūsų duomenys yra suskaidyti ir pakartoti.
Visame klasteryje yra N įėjimo taškų, o tai reiškia, kad „Prometheus“ gali pridėti duomenis per HAPROXY. Čia mes turime šį įėjimo tašką. Ir per šį įėjimo tašką galite prisijungti iš Grafana.
Mūsų atveju HAPROXY yra vienintelis tarpinis serveris, kuris pasirenka, įterpia ir kitas paslaugas šiame klasteryje. Mūsų atveju nebuvo įmanoma sukurti vieno adreso, reikėjo padaryti kelis įėjimo taškus, nes pačios virtualios mašinos, kuriose veikia VictoriaMetrics klasteris, yra skirtingose to paties debesų tiekėjo zonose, t.y. ne mūsų debesyje, o išorėje. .
Turime įspėjimą. Mes jį naudojame. Naudojame Alertmanager iš Prometheus. Kaip įspėjimų pristatymo kanalą naudojame „Opsgenie“ ir „Telegram“. Telegramoje jie pila iš dev, gal kažkas iš prod, bet dažniausiai kažkas statistinio, reikalingo inžinieriams. Ir Opsgenie yra kritiška. Tai skambučiai, incidentų valdymas.
Amžinas klausimas: „Kas stebi stebėjimą? Mūsų atveju stebėjimas stebi patį stebėjimą, nes kiekviename mazge naudojame vmagent. O kadangi mūsų mazgai yra paskirstyti skirtinguose to paties teikėjo duomenų centruose, kiekvienas duomenų centras turi savo kanalą, jie yra nepriklausomi ir net jei atkeliaus suskilusios smegenys, vis tiek gausime įspėjimus. Taip, jų bus daugiau, bet geriau gauti daugiau įspėjimų nei jų negauti.
Sąrašą baigiame HA įgyvendinimu.
Ir toliau norėčiau atkreipti dėmesį į bendravimo su VictoriaMetrics bendruomene patirtį. Tai pasirodė labai teigiama. Vaikinai reaguoja. Jie stengiasi įsigilinti į kiekvieną siūlomą atvejį.
Pradėjau problemas „GitHub“. Jie buvo išspręsti labai greitai. Yra dar keletas problemų, kurios nėra visiškai uždarytos, bet jau dabar matau iš kodo, kad darbas šia kryptimi vyksta.
Pagrindinis skausmas man per iteracijas buvo tai, kad jei išjungiau mazgą, tai pirmas 30 sekundžių vminsert negalėjo suprasti, kad nėra backend. Dabar tai nuspręsta. Ir pažodžiui per sekundę ar dvi, duomenys paimami iš visų likusių mazgų, ir užklausa nustoja laukti to trūkstamo mazgo.
Kažkuriuo metu norėjome, kad „VictoriaMetrics“ būtų „VictoriaMetrics“ operatorius. Mes jo laukėme. Dabar aktyviai kuriame sistemą, kad VictoriaMetrics operatorius galėtų atsižvelgti į visas išankstinio skaičiavimo taisykles ir tt Prometheus, nes gana aktyviai naudojame taisykles, kurios pateikiamos su Prometheus operatoriumi.
Yra pasiūlymų tobulinti klasterio įgyvendinimą. Aš juos aprašiau aukščiau.
Ir aš tikrai noriu sumažinti mėginius. Mūsų atveju sumažinimas reikalingas tik tendencijoms peržiūrėti. Grubiai tariant, per dieną man užtenka vieno rodiklio. Šios tendencijos reikalingos metus, trejus, penkerius, dešimt metų. Ir vienos metrinės vertės visiškai pakanka.
- Naudodami Prometėją, kaip ir kai kurie mūsų kolegos, žinojome skausmą.
- Mes pasirinkome VictoriaMetrics sau.
- Jis gana gerai mastelis tiek vertikaliai, tiek horizontaliai.
- Galime paskirstyti skirtingus komponentus įvairiems klasterio mazgų skaičiui, apriboti juos atmintimi, pridėti atmintį ir pan.
Namuose naudosime VictoriaMetrics, nes labai patiko. Štai kas buvo ir kas tapo.
Pora QR kodų „VictoriaMetrics“ pokalbiui, mano kontaktai, „LeroyMerlin“ techninis radaras.
Šaltinis: www.habr.com