VictoriaMetrics este un SGBD rapid și scalabil pentru stocarea și procesarea datelor sub forma unei serii temporale (o înregistrare constă din timp și un set de valori corespunzătoare acestui timp, de exemplu, obținute prin sondarea periodică a stării senzorilor sau colecție de metrici).
Numele meu este Kolobaev Pavel. DevOps, SRE, LeroyMerlin, totul este ca un cod - totul este despre noi: despre mine și despre alți angajați LeroyMerlin.
Există un cloud bazat pe OpenStack. Există o mică legătură către radarul tehnic.
Este construit pe hardware-ul Kubernetes, precum și pe toate serviciile conexe pentru OpenStack și logare.
Aceasta este schema pe care o aveam în dezvoltare. Când dezvoltam toate acestea, aveam un operator Prometheus care stoca date în interiorul cluster-ului K8s. Găsește automat ceea ce trebuie curățat și îl pune sub picioare, aproximativ vorbind.
Va trebui să mutăm toate datele în afara clusterului Kubernetes, pentru că dacă se întâmplă ceva, trebuie să înțelegem ce și unde.
Prima soluție este că folosim federația atunci când avem un Prometheus terță parte, când mergem la clusterul Kubernetes prin mecanismul de federare.
Dar există câteva mici probleme aici. În cazul nostru, problemele au început când aveam 250 de metrici, iar când erau 000 de metrici, ne-am dat seama că nu putem lucra așa. Am mărit scrape_timeout la 400 de secunde.
De ce a trebuit să facem asta? Prometheus începe să numere timeout-ul de la începutul gardului. Nu contează că datele încă mai curg. Dacă în această perioadă specificată datele nu sunt îmbinate și sesiunea nu este închisă prin http, atunci sesiunea este considerată a eșuată și datele nu intră în Prometheus în sine.
Toată lumea este familiarizată cu graficele pe care le primim atunci când unele dintre date lipsesc. Programele sunt rupte și nu suntem mulțumiți de asta.
Următoarea opțiune este sharding-ul bazat pe două Prometheus diferite prin același mecanism de federație.
De exemplu, luați-le și împărțiți-le după nume. Poate fi folosit și acesta, dar am decis să mergem mai departe.
Acum va trebui să procesăm aceste cioburi cumva. Puteți lua promxy, care merge în zona shard și înmulțește datele. Funcționează cu două cioburi ca un singur punct de intrare. Acest lucru poate fi implementat prin promxy, dar este încă prea dificil.
Prima variantă este că vrem să renunțăm la mecanismul de federație pentru că este foarte lent.
Dezvoltatorii Prometheus spun clar: „Băieți, folosiți un alt TimescaleDB pentru că nu vom accepta stocarea pe termen lung a valorilor”. Aceasta nu este sarcina lor.
Notam pe o bucata de hartie pe care mai trebuie sa o descarcam afara, pentru a nu depozita totul intr-un singur loc.
Al doilea dezavantaj este consumul de memorie. Da, înțeleg că mulți vor spune că în 2020 câțiva gigaocteți de memorie costă un ban, dar totuși.
Acum avem un mediu de dezvoltare și producție. În dezvoltare, este de aproximativ 9 gigaocteți pentru 350 de metrici. În prod, este de 000 gigaocteți și puțin peste 14 de metrici. În același timp, timpul nostru de reținere este de doar 780 de minute. Asta e rău. Și acum voi explica de ce.
Facem un calcul, adică cu un milion și jumătate de metrici, și suntem deja aproape de ele, în faza de proiectare obținem 35-37 de gigabytes de memorie. Dar deja 4 milioane de valori necesită aproximativ 90 de gigaocteți de memorie. Adică a fost calculat folosind formula oferită de dezvoltatorii Prometheus. Ne-am uitat la corelație și am realizat că nu am vrut să plătim câteva milioane pentru un server doar pentru monitorizare.
Nu doar că vom crește numărul de mașini, ci monitorizăm și mașinile virtuale în sine. Prin urmare, cu cât mai multe mașini virtuale, cu atât mai multe metrici de diferite tipuri etc. Vom avea o creștere deosebită a clusterului nostru în ceea ce privește metrica.
Cu spațiu pe disc, nu totul este atât de rău aici, dar aș dori să-l îmbunătățesc. Am primit un total de 15 de gigaocteți în 120 zile, dintre care 100 sunt date comprimate, 20 sunt date necomprimate, dar ne dorim întotdeauna mai puține.
În consecință, mai notăm un punct - acesta este un consum mare de resurse, pe care încă vrem să-l economisim, deoarece nu dorim ca clusterul nostru de monitorizare să consume mai multe resurse decât clusterul nostru, care gestionează OpenStack.
Mai există un dezavantaj al lui Prometheus, pe care l-am identificat pentru noi înșine, acesta este cel puțin un fel de limitare a memoriei. Cu Prometheus, totul este mult mai rău aici, pentru că nu are deloc asemenea răsturnări. Utilizarea unei limite în docker nu este, de asemenea, o opțiune. Dacă brusc RAF-ul tău a căzut și există 20-30 de gigaocteți, atunci va dura foarte mult timp să crească.
Acesta este un alt motiv pentru care Prometheus nu este potrivit pentru noi, adică nu putem limita consumul de memorie.
Ar fi posibil să vină cu o astfel de schemă. Avem nevoie de această schemă pentru a organiza un cluster HA. Dorim ca valorile noastre să fie disponibile întotdeauna și oriunde, chiar dacă serverul care stochează aceste valori se blochează. Și astfel va trebui să construim o astfel de schemă.
Această schemă spune că vom avea duplicarea cioburi și, în consecință, duplicarea costurilor resurselor consumate. Poate fi scalat aproape orizontal, dar cu toate acestea consumul de resurse va fi infernal.
Dezavantaje în ordine în forma în care le-am notat pentru noi înșine:
- Necesită încărcarea valorilor extern.
- Consum mare de resurse.
- Nu există nicio modalitate de a limita consumul de memorie.
- Implementarea complexă și consumatoare de resurse a HA.
Pentru noi înșine, am decis că ne mutăm de la Prometheus ca depozit.
Am identificat cerințe suplimentare pentru noi înșine de care avem nevoie. Acest:
- Acesta este suportul promql, deoarece au fost deja scrise multe lucruri pentru Prometheus: interogări, alerte.
- Și apoi avem Grafana, care este deja scrisă exact în același mod pentru Prometheus ca backend. Nu vreau să rescriu tablourile de bord.
- Vrem să construim o arhitectură HA normală.
- Dorim să reducem consumul oricăror resurse.
- Există o altă mică nuanță. Nu putem folosi diferite tipuri de sisteme de colectare a valorilor din cloud. Nu știm încă ce va intra în aceste valori. Și din moment ce orice poate zbura acolo, trebuie să ne limităm la plasarea locală.
A fost puțină alegere. Am adunat tot ce am avut experiență. Ne-am uitat la pagina Prometheus din secțiunea de integrare, am citit o grămadă de articole și am văzut ce era acolo. Și pentru noi înșine, am ales VictoriaMetrics ca înlocuitor pentru Prometheus.
De ce? Deoarece:
- Cunoaște promql.
- Există o arhitectură modulară.
- Nu necesită modificări la Grafana.
- Și cel mai important, probabil că vom oferi stocarea de metrici în cadrul companiei noastre ca serviciu, așa că urmărim în avans restricții de diferite tipuri, astfel încât utilizatorii să poată folosi toate resursele clusterului într-un mod limitat, pentru că există o șansă. că va avea mai multe locații.
Să facem prima comparație. Luăm același Prometeu în interiorul clusterului, Prometeu extern merge la el. Adăugați prin remoteWrite VictoriaMetrics.
Voi face imediat o rezervare că aici am prins o ușoară creștere a consumului procesorului de la VictoriaMetrics. Wiki VictoriaMetrics vă spune care parametri sunt cei mai buni. Le-am verificat. Au redus foarte bine consumul procesorului.
În cazul nostru, consumul de memorie al Prometheus, care se află în clusterul Kubernetes, nu a crescut semnificativ.
Comparăm două surse de date ale acelorași date. În Prometheus vedem aceleași date lipsă. Totul este bine la VictoriaMetrics.
Rezultatele testului de spațiu pe disc. Noi, cei de la Prometheus, am primit 120 de gigabytes în total. La VictoriaMetrics primim deja 4 gigaocteți pe zi. Există un mecanism ușor diferit față de ceea ce suntem obișnuiți să vedem în Prometeu. Adică datele sunt deja comprimate destul de bine într-o zi, într-o jumătate de oră. Au fost deja culese bine într-o zi, într-o jumătate de oră, în ciuda faptului că datele se vor pierde tot mai târziu. Ca rezultat, am economisit spațiu pe disc.
Economisim și consumul de resurse de memorie. La momentul testării, aveam Prometheus implementat pe o mașină virtuală - 8 nuclee, 24 gigaocteți. Prometheus mănâncă aproape orice. A căzut pe OOM Killer. În același timp, doar 900 de valori active au fost turnate în el. Aceasta este aproximativ 000-25 de metrici pe secundă.
Am rulat VictoriaMetrics pe o mașină virtuală dual-core cu 8 gigaocteți de memorie RAM. Am reușit să facem ca VictoriaMetrics să funcționeze bine, jucându-ne cu câteva lucruri pe o mașină de 8 GB. Până la urmă, l-am păstrat la 7 gigaocteți. În același timp, viteza de livrare a conținutului, adică a metricilor, a fost chiar mai mare decât cea a lui Prometheus.
Procesorul a devenit mult mai bun în comparație cu Prometheus. Aici Prometheus consumă 2,5 nuclee, iar VictoriaMetrics consumă doar 0,25 nuclee. La început – 0,5 nuclee. Pe măsură ce se îmbină, ajunge la un nucleu, dar acest lucru este extrem, extrem de rar.
În cazul nostru, alegerea a căzut pe VictoriaMetrics din motive evidente; am vrut să economisim și am făcut-o.
Să tăiem imediat două puncte – încărcarea de valori și consumul ridicat de resurse. Și trebuie doar să decidem două puncte pe care ni le mai rămân pentru noi.
Aici voi face imediat o rezervare, considerăm VictoriaMetrics ca un stocare de metrici. Dar, din moment ce cel mai probabil vom oferi VictoriaMetrics ca spațiu de stocare pentru tot Leroy, trebuie să îi limităm pe cei care vor folosi acest cluster, astfel încât să nu ni-l ofere.
Există un parametru minunat care vă permite să limitați după timp, după volumul de date și după timpul de execuție.
Există, de asemenea, o opțiune excelentă care ne permite să limităm consumul de memorie, astfel putem găsi chiar echilibrul care ne va permite să obținem o viteză normală de funcționare și un consum adecvat de resurse.
Minus încă un punct, adică tăiați punctul - nu puteți limita consumul de memorie.
În primele iterații, am testat VictoriaMetrics Single Node. Apoi trecem la versiunea VictoriaMetrics Cluster.
Aici avem mână liberă pentru a separa diferite servicii în VictoriaMetrics în funcție de ce vor rula acestea și de ce resurse vor consuma. Aceasta este o soluție foarte flexibilă și convenabilă. Am folosit asta pentru noi înșine.
Componentele principale ale versiunii VictoriaMetrics Cluster sunt vmstsorage. Pot exista N dintre ele. În cazul nostru sunt 2 dintre ele până acum.
Și există vminsert. Acesta este un server proxy care ne permite: să organizăm sharding-ul între toate stocările despre care i-am spus și, de asemenea, permite o replică, adică veți avea atât sharding, cât și o replică.
Vminsert acceptă protocoalele OpenTSDB, Graphite, InfluxDB și remoteWrite de la Prometheus.
Există și vmselect. Sarcina sa principală este de a merge la vmstorage, de a primi date de la ei, de a deduplica aceste date și de a le oferi clientului.
Există un lucru minunat numit vmagent. Ne place foarte mult de ea. Vă permite să configurați exact ca Prometheus și să faceți totul exact ca Prometheus. Adică, colectează valori de la diferite entități și servicii și le trimite către vminsert. Atunci totul depinde de tine.
Un alt serviciu excelent este vmalert, care vă permite să utilizați VictoriaMetrics ca backend, să primiți date procesate de la vminsert și să le trimiteți către vmselect. Procesează alertele în sine, precum și regulile. În cazul alertelor, primim alerta prin alertmanager.
Există o componentă wmauth. S-ar putea sau nu (nu ne-am decis încă) să-l folosim ca sistem de autorizare pentru versiunea multi-tenancy a clusterelor. Suportă remoteWrite pentru Prometheus și poate autoriza pe baza adresei URL, sau mai degrabă a doua parte a acesteia, unde puteți sau nu scrie.
Există și vmbackup, vmrestore. Aceasta este, în esență, restaurarea și backupul tuturor datelor. Poate face S3, GCS, fișier.
Prima iterație a clusterului nostru a fost făcută în timpul carantinei. La acel moment, nu exista o replică, așa că iterația noastră a constat din două clustere diferite și independente în care am primit date prin remoteWrite.
Aici voi face o rezervare că atunci când am trecut de la VictoriaMetrics Single Node la VictoriaMetrics Cluster Version, am rămas în continuare cu aceleași resurse consumate, adică principala este memoria. Cam așa au fost distribuite datele noastre, adică consumul de resurse.
O replică a fost deja adăugată aici. Am combinat toate acestea într-un singur cluster relativ mare. Toate datele noastre sunt fragmentate și replicate.
Întregul cluster are N puncte de intrare, ceea ce înseamnă că Prometheus poate adăuga date prin HAPROXY. Aici avem acest punct de intrare. Și prin acest punct de intrare vă puteți autentifica din Grafana.
În cazul nostru, HAPROXY este singurul port care selectează, inserează și alte servicii proxy în cadrul acestui cluster. În cazul nostru, a fost imposibil să facem o singură adresă; a trebuit să facem mai multe puncte de intrare, deoarece mașinile virtuale în sine pe care rulează clusterul VictoriaMetrics sunt situate în zone diferite ale aceluiași furnizor de cloud, adică nu în interiorul cloud-ului nostru, ci în exterior. .
Avem alerte. Îl folosim. Folosim alertmanager de la Prometheus. Folosim Opsgenie și Telegram ca canal de livrare de alerte. În Telegram se toarnă de la dev, poate ceva de la prod, dar mai ales ceva statistic, necesar inginerilor. Și Opsgenie este critică. Acestea sunt apeluri, managementul incidentelor.
Eterna întrebare: „Cine monitorizează monitorizarea?” În cazul nostru, monitorizarea monitorizează monitorizarea în sine, deoarece folosim vmagent pe fiecare nod. Și din moment ce nodurile noastre sunt distribuite în diferite centre de date ale aceluiași furnizor, fiecare centru de date are propriul său canal, sunt independente și chiar dacă sosește un creier divizat, vom primi în continuare alerte. Da, vor fi mai multe, dar este mai bine să primiți mai multe alerte decât niciuna.
Încheiem lista noastră cu o implementare HA.
Și mai departe aș dori să notez experiența comunicării cu comunitatea VictoriaMetrics. A ieșit foarte pozitiv. Băieții sunt receptivi. Ei încearcă să aprofundeze în fiecare caz care este oferit.
Am început probleme pe GitHub. Au fost rezolvate foarte repede. Mai sunt câteva probleme care nu sunt complet închise, dar pot vedea deja din cod că lucrările în această direcție sunt în curs de desfășurare.
Principala durere pentru mine în timpul iterațiilor a fost că, dacă închidem un nod, atunci în primele 30 de secunde vminsert nu putea înțelege că nu există backend. Acest lucru a fost decis acum. Și literalmente într-o secundă sau două, datele sunt preluate de la toate nodurile rămase, iar cererea nu mai așteaptă acel nod lipsă.
La un moment dat am vrut ca VictoriaMetrics să fie un operator VictoriaMetrics. L-am așteptat. Acum construim în mod activ un cadru pentru ca operatorul VictoriaMetrics să accepte toate regulile de precalculare etc. Prometheus, deoarece folosim destul de activ regulile care vin cu operatorul Prometheus.
Există propuneri de îmbunătățire a implementării clusterului. Le-am subliniat mai sus.
Și chiar vreau să reduc eșantionarea. În cazul nostru, eșantionarea este necesară exclusiv pentru vizualizarea tendințelor. Aproximativ vorbind, o măsurătoare este suficientă pentru mine în timpul zilei. Aceste tendințe sunt necesare pentru un an, trei, cinci, zece ani. Și o valoare metrică este suficientă.
- Am cunoscut durerea, la fel ca unii dintre colegii noștri, atunci când folosim Prometheus.
- Am ales VictoriaMetrics pentru noi.
- Se scalează destul de bine atât pe verticală, cât și pe orizontală.
- Putem distribui diferite componente la un număr diferit de noduri din cluster, le putem limita prin memorie, adăuga memorie etc.
Vom folosi VictoriaMetrics acasă pentru că ne-a plăcut foarte mult. Asta a fost și a devenit.
Câteva coduri QR pentru chat VictoriaMetrics, contactele mele, radarul tehnic LeroyMerlin.
Sursa: www.habr.com