Dzmitry Lazerka, co-fondator al VictoriaMetrics – Seria de interviuri

Dzmitry Lazerka, co-fondator al VictoriaMetrics este un inginer software experimentat și lider tehnologic cu o expertiză profundă în învățarea automată, sisteme de date la scară largă, observabilitate și infrastructură. Înainte de a co-fonda VictoriaMetrics în 2018, a lucrat ca inginer de învățare automată la divizia de vehicule autonome Level 5 a Lyft, unde a contribuit la dezvoltarea sistemelor pentru recunoașterea și analizarea scenariilor de conducere din viața reală. Anterior, a condus proiecte de învățare automată și infrastructură de date la Spire Global, a fost co-fondator tehnic la Bellgram și a lucrat la sisteme de date și analiză la Duetto Research și Google prin EPAM Systems. Pe parcursul carierei sale, Lazerka a construit și condus proiecte ce acoperă conducerea autonomă, predicția maritimă, căutarea, analiza, procesarea distribuită a datelor și sisteme backend extrem de scalabile.

VictoriaMetrics este o companie de observabilitate open-source care dezvoltă instrumente pentru colectarea, stocarea, interogarea și analizarea volumelor mari de date operaționale. Tehnologia sa a început cu VictoriaMetrics, o bază de date de serii temporale de înaltă performanță și o soluție de monitorizare concepută pentru scalabilitate, interogări rapide, stocare eficientă și costuri operaționale reduse, și s-a extins ulterior într-un set mai larg de instrumente de observabilitate ce acoperă metrici, jurnale și trasări distribuite prin VictoriaMetrics, VictoriaLogs și VictoriaTraces. Compania oferă, de asemenea, implementări enterprise și complet gestionate în cloud, împreună cu capabilități de detectare a anomaliilor care aplică învățarea automată la datele de serii temporale. Platforma sa suportă tehnologii precum OpenTelemetry, fluxuri de lucru compatibile cu Prometheus, Grafana și Kubernetes, oferind organizațiilor flexibilitatea de a integra VictoriaMetrics în mediile existente de observabilitate.

Înainte de a co-fonda VictoriaMetrics, ați lucrat la sisteme de date la scară largă, analiză și învățare automată la Google, Spire Global, divizia de vehicule autonome a Lyft și alte startup-uri. Ce v-a determinat în cele din urmă să înființați VictoriaMetrics și care probleme din acele roluri anterioare v-au convins că monitorizarea și observabilitatea necesitau o abordare fundamental diferită?

Mi-am petrecut cariera lucrând cu cantități mari de date. La Google, Spire, Lyft și alte companii, înveți repede că ceva ce funcționează bine la o scară poate deveni scump sau dificil de operat la o altă scară. Monitorizarea are exact această problemă.

Pe măsură ce infrastructura crește, creați mai multe metrici. Adăugați mai multe servicii, mai multe instanțe și mai multe etichete până când, brusc, sistemul de monitorizare în sine necesită o cantitate semnificativă de infrastructură, lucru care nu a avut niciodată sens pentru noi. Un sistem conceput pentru a monitoriza mediul de producție nu ar trebui să devină mai complicat și mai costisitor de operat.

Acesta a fost exact ceea ce au observat direct colegii mei co-fondatori Aliaksandr Valialkin și Roman Khavronenko. Ei aveau experiență în operarea Prometheus și s-au confruntat cu limitări de memorie. Adăugarea de sisteme precum Thanos a rezolvat anumite probleme de scalare, dar a introdus și mai multe componente și o complexitate operațională sporită. Iar cu InfluxDB, am văzut cum o schimbare de licențiere poate afecta deciziile tehnice după ce echipele au investit deja în tehnologie.

Așadar ideea din spatele VictoriaMetrics a fost practică: Putem construi o bază de date de serii temporale care să îndeplinească aceeași sarcină cu mult mai puține resurse și să fie mai simplă de operat?

Nu am început cu un plan de a construi o companie mare de observabilitate. Am început prin rezolvarea unei probleme de inginerie.

Faptul că a fost open source a făcut parte din acest lucru. Inginerii puteau descărca VictoriaMetrics, să ruleze sarcini reale de producție pe el și să compare rezultatele pe cont propriu. Nu a trebuit să le spunem că este mai rapid sau mai eficient. Ei puteau să îl măsoare.

Aceasta este cea mai bună modalitate de a construi software de infrastructură. Dacă tehnologia este bună, inginerii ar trebui să poată să o dovedească singuri.

Costurile de observabilitate pot deveni în tăcere o parte semnificativă a facturii cloud a unei companii. Unde se declanșează de obicei aceste costuri și ce decizii arhitecturale sau de achiziție greșesc cel mai frecvent echipele de inginerie?

Aș privi mai întâi cardinalitatea.

Să zicem că începeți cu o metrică rezonabilă, apoi adăugați o etichetă cu valori posibile. Dintr-o dată, o metrică devine mii sau milioane de serii temporale unice. Sistemul are acum mai multe date de ingerat, indexat, stocat și interogat, rezultând în mai mult CPU, memorie și stocare.

Partea dificilă este că acest lucru nu se întâmplă din cauza unei singure decizii greșite. Se petrece treptat. Adăugați mai multe servicii, poduri K8s, clienți și etichete, iar costul se multiplică.

A doua problemă este stocarea tuturor datelor la aceeași rezoluție pentru aceeași perioadă de timp. Nu toate datele de observabilitate au aceeași valoare. Metricile de care aveți nevoie pentru o alertă sau un SLO diferă de telemetria de diagnostic de mare volum pe care o puteți examina o singură dată în timpul unui incident.

Dacă tratați toate aceste date în același mod, veți ajunge să plătiți prețuri premium pentru infrastructură sau SaaS pentru date care nu necesită acest nivel.

Acesta este motivul pentru care unele companii abordează observabilitatea ca o problemă de achiziție, întrebându-se care platformă este cea mai ușor de implementat astăzi. Întreb eu lucruri de genul: “Ce se întâmplă când volumul de telemetrie crește de 10 ori? Ce se întâmplă cu cardinalitatea? Ce stocăm? Pentru cât timp? Și ce se întâmplă cu costul?”

Există soluții de inginerie pentru aceste probleme. De exemplu, prin agregare în flux, puteți agrega metricile înainte să ajungă la stocare în loc să stocați fiecare serie brută și să o agregați ulterior. Puteți separa sarcinile cu cardinalitate mare de monitorizarea critică pentru afacere. De asemenea, puteți folosi politici diferite de retenție și rezoluție în funcție de valoarea datelor.

Obiectivul nu este să colectați cât mai puțină telemetrie posibil. Aveți nevoie de suficiente informații pentru a înțelege ce fac sistemele dumneavoastră.

Obiectivul este să evitați cheltuirea de resurse pentru colectarea, procesarea și stocarea datelor într-un mod care nu vă aduce valoare suplimentară.

Observabilitatea este un sistem de inginerie. Costul său ar trebui să fie și el proiectat.

Grammarly a afirmat că demonstrația de concept cu VictoriaMetrics a condus la o factură AWS de 10 ori mai mică. Când companiile obțin economii la această scară, ce se schimbă cu adevărat în spatele cortinei: comprimarea datelor, cerințele de calcul, arhitectura de stocare, complexitatea operațională sau o combinație a acestor factori?

Este o combinație, dar comprimarea și amprenta de resurse fac cea mai mare parte din muncă. VictoriaMetrics folosește o comprimare creată special pentru date de serii temporale, astfel încât aceleași metrici ocupă o fracțiune din spațiul pe disc pe care l-ar ocupa într-o bază de date cu scop general. În plus, rulăm de patru până la cinci ori mai puțin RAM decât Prometheus la rate de ingestie echivalente și până la 10 ori mai puțin spațiu pe disc. Când Grammarly a realizat demonstrația de concept, acest lucru a apărut direct în factura lor AWS, deoarece nu stocau doar mai puține date; rulau și mai puține și mai mici instanțe pentru a face acest lucru.

Partea de complexitate operațională contează, de asemenea, dar este mai indirectă. Multe echipe care estimează costurile de observabilitate se uită doar la elementele de stocare și calcul și omite orele de inginerie petrecute pentru operarea unui stack Thanos de cinci componente în comparație cu un singur binar. E vorba de bani reali; este doar mai greu să pui un număr pe aceasta.

Prometheus a devenit fundamental pentru monitorizarea cloud-native, totuși unele organizații în cele din urmă se confruntă cu limitări de scalabilitate sau operaționale. Ce determină în mod obișnuit o companie să înceapă să caute dincolo de o implementare convențională Prometheus și când devine VictoriaMetrics o alternativă logică?

Prometheus este excelent în ceea ce a fost creat: un motor de colectare și alertare pe un singur nod. Echipele de obicei se lovește de limită în două moduri: fie cardinalitatea lor crește peste ceea ce poate reține în memorie o singură instanță Prometheus, fie au nevoie de păstrare pe termen lung și interogare globală pe mai multe clustere, pentru care Prometheus nu a fost niciodată proiectat să facă singur. Atunci oamenii adaugă Thanos sau Cortex, ceea ce de obicei marchează începutul durerii operaționale. Treceți de la rularea unui singur binar la rularea unui sistem distribuit cu un compactor, un interogator, un gateway de stocare și multe altele care pot ceda la ora 3 dimineața.

VictoriaMetrics devine pasul logic următor deoarece este un înlocuitor drop‑in, nu o rearchitectură. Echipele îndreaptă configurația lor existentă de colectare Prometheus către VictoriaMetrics și păstrează fiecare tablou de bord Grafana, alertă și regulă de înregistrare pe care le-au construit deja. Migrarea este o schimbare de configurare, nu un proiect, și obțin scalabilitatea fără a adăuga cinci noi componente de operat.

Observăm echipele de inginerie reconsiderând dacă au nevoie de platforme mari, complet gestionate de observabilitate sau dacă pot construi stack‑uri mai eficiente din componente open‑source. Considerați că aceasta reprezintă o schimbare structurală mai largă pe piața de observabilitate și câtă presiune exercită open‑source asupra modelelor tradiționale de tarifare?

Este structural; nu o reacție temporară la un an cu buget slab. Furnizorii de observabilitate au prețuit istoric fie pe volumul de ingestie, fie pe numărul de gazde, iar acest model lucrează împotriva clientului pe măsură ce afacerea lor crește. Cu cât o companie are mai mult succes, cu atât plătește mai mult, iar prețul nu are nicio legătură reală cu valoarea livrată. Echipele de inginerie au început să facă singure calculele, realizând că un stack open‑source auto‑găzduit și eficient schimbă complet această ecuație. Acest lucru se datorează faptului că costul scalează cu infrastructura efectiv rulată, nu cu o formulă de tarifare controlată de furnizor.

Acest lucru exercită o presiune reală asupra prețurilor existente. Când o echipă poate îndrepta configurația lor existentă de colectare către o alternativă open‑source și poate reduce factura cu 60‑80 % fără a pierde funcționalitate, nu este o discuție dificilă internă. Furnizorii care încă taxează pe gazdă sau metrică personalizată vor continua să „sângereze” clienții care nu fac aceste calcule.

Infrastructura AI introduce o resursă nouă neobișnuit de costisitoare în ecuație: GPU‑urile. Ce ar trebui să monitorizeze companiile care rulează antrenament sau inferență AI dincolo de utilizarea de bază a GPU‑urilor și unde poate o observabilitate mai bună să se traducă direct în costuri mai mici ale infrastructurii AI?

Utilizarea GPU‑ului singură nu îți spune suficient.

Poți vedea 90 % utilizare pe un tablou de bord și să presupui că totul este în regulă. Dar ceea ce vrei cu adevărat să știi este: Ce face GPU‑ul?

Trebuie să te uiți mai adânc. Ce kerneluri CUDA rulează? Cum este alocată memoria GPU? Cât timp se petrece mutând memoria în loc să se facă calcul? Folosește sarcina Tensor Cores când ar trebui? Este GPU‑ul cu adevărat blocajul, sau așteaptă date de undeva altundeva?

Acestea sunt întrebări importante deoarece GPU‑urile sunt scumpe. O mică ineficiență repetată pe sute sau mii de GPU‑uri devine o sumă foarte mare de bani.

De exemplu, dacă GPU‑urile așteaptă pentru că linia de date nu le poate alimenta suficient de rapid, achiziționarea a mai multe GPU‑uri nu va rezolva problema. Trebuie să găsești blocajul. Aceeași situație se aplică memoriei. Dacă sarcinile alocă memoria ineficient, o vizibilitate mai bună poate ajuta inginerii să ajusteze dimensiunile loturilor sau să ruleze mai multe sarcini pe același hardware.

Aici observabilitatea devine interesantă pentru infrastructura AI. Nu este doar despre a detecta că ceva este defect. Poate să îți spună unde irosești calculul.

Există, de asemenea, o problemă de observabilitate creată de tot acest monitorizare. GPU‑urile pot genera o cantitate mare de telemetrie detaliată, cu cardinalitate ridicată. Dacă colectezi totul și îl trimiți direct într‑o platformă SaaS costisitoare, poți reduce costurile GPU‑urilor și apoi să cheltui o parte din economii pentru stocarea datelor de monitorizare. Dar aceasta nu este o optimizare bună.

Cu OpenTelemetry și proiecte precum OpenLIT, putem obține o vizibilitate mult mai profundă în sarcinile GPU. Apoi, cu VictoriaMetrics, putem agrega datele, elimina dimensiunile inutile și reține eficient informațiile de care inginerii au cu adevărat nevoie.

Întrebarea utilă nu este „Cât de utilizate sunt GPU‑urile mele?”

Este „Ce lucru util obțin de la GPU‑urile pentru care plătesc?”

Odată ce poți răspunde la asta, poți începe să iei decizii mai bune din punct de vedere ingineresc și al costurilor.

Agenții AI creează provocări de observabilitate foarte diferite față de software‑ul tradițional, deoarece o singură cerere poate declanșa apeluri de model, utilizarea de instrumente, interogări în baze de date vectoriale, transferuri și, potențial, lanțuri lungi de acțiuni autonome. Cum trebuie să evolueze observabilitatea pe măsură ce aplicațiile enterprise devin tot mai agentice?

Observabilitatea tradițională presupune că o cerere urmează un traseu destul de previzibil prin infrastructura ta. Sarcinile agentice nu funcționează astfel. Un singur agent poate apela un model, apoi un instrument, apoi un alt model și să reîncerce de trei ori înainte să returneze ceva. Fiecare dintre acești pași necesită propria vizibilitate.

Modurile de eșec sunt, de asemenea, diferite. Un serviciu tradițional răspunde corect sau nu răspunde. Un agent poate răspunde cu succes și totuși să fie greșit, lent sau costisitor, iar niciunul dintre acestea nu apare ca o eroare tipică într‑un tablou de bord conceput pentru disponibilitate.

Partea care surprinde echipele este cardinalitatea. Un flux de lucru al unui agent poate genera metrici legate de un utilizator specific, de un prompt și de un apel de instrument, iar volumul se acumulează rapid, în special în buclele recursive în care un planificator continuă să apeleze același instrument. Orice sistem destinat să observe sarcini agentice trebuie să gestioneze această scară fără ca curba de cost să devină verticală, ceea ce este exact problema pe care o rezolvăm. Metricile, jurnalele și trasările rămân blocurile de bază potrivite. Ce trebuie să se schimbe este volumul și modelul de cost de bază.

VictoriaMetrics a aplicat, de asemenea, învățarea automată și fluxuri de lucru asistate de AI pentru detectarea anomaliilor. Unde credeți că AI poate îmbunătăți cu adevărat monitorizarea și răspunsul la incidente astăzi și unde judecata umană este încă dificil de înlocuit?

Este important să menții o persoană în circuit pentru generarea de idei, ghidarea implementării și validarea rezultatelor. Cu alte cuvinte, nimic nu s‑a schimbat cu adevărat comparativ cu fluxul de lucru tradițional. Ce s‑a schimbat este că capacitățile de generare a soluțiilor s‑au amplificat. Oricine poate crea software acum, dar asta nu ar trebui să scadă criteriile de acceptare. Ar trebui să le ridice semnificativ.

Unde AI ajută cu adevărat este în evidențierea a ceea ce o persoană ar rata în zgomot, lucruri precum valori aberante și tendințe care nu declanșează un prag manual. La VictoriaMetrics, avem o politică internă simplă de AI: Angajații sunt liberi să își automatizeze fluxul de lucru cum doresc, dar rămân responsabili pentru rezultatul final. Este aproximativ același standard pe care l‑am aplica pentru detectarea anomaliilor în mediul de producție al unui client. Modelul poate semnala, dar o persoană trebuie în continuare să decidă ce înseamnă și ce să facă în legătură cu asta.

VictoriaMetrics a rămas open‑source și a adoptat o abordare autofinanțată, finanțată de clienți, în loc să urmeze modelul tradițional de startup de infrastructură susținut de capital de risc. Cum a influențat acest lucru modul în care construiți produsul, îl prețuiți și decideți ce tehnologii rămân open‑source?

A fi autofinanțat schimbă structura de stimulente mai mult decât se așteaptă oamenii. Fără un consiliu care să ne ceară să atingem un anumit ARR într‑un trimestru specific, nu am fost nevoiți să facem compromisurile care vin de obicei cu această presiune, cum ar fi să slăbim versiunea open‑source pentru a forța utilizatorii să treacă la un nivel plătit, sau să schimbăm licența așa cum au făcut InfluxDB sau HashiCorp când au trebuit să protejeze veniturile de furnizorii de cloud. VictoriaMetrics OSS este astăzi Apache 2.0 și nu avem planuri să schimbăm asta.

Modul în care decidăm ce rămâne open source este simplu: motorul de bază, elementul în care inginerii trebuie să aibă încredere pentru datele lor de producție, rămâne deschis. Taxăm pentru ceea ce o companie are nevoie odată ce rulează la scară și necesită responsabilitate: multi-tenancy, autentificare enterprise, suport pentru conformitate, un SLA pentru CVE și acces direct la inginerii care au scris codul în loc de o coadă de suport. Finanțarea de la clienți înseamnă, de asemenea, că foaia de parcurs este stabilită de problemele reale întâmpinate în producție, nu de ceea ce poate fi finanțat într-un pitch deck.

Pe măsură ce metricele, jurnalele, trasările, telemetria aplicațiilor AI, monitorizarea GPU și detectarea automată a anomaliilor converg tot mai mult, cum credeți că va arăta stack-ul de observabilitate în următorii câțiva ani și ce vor aștepta echipele de inginerie de la platformele care doresc să rămână relevante?

Stack-ul converge operațional înainte de a converge ca un singur produs, iar această diferență contează. Majoritatea echipelor nu doresc o platformă monolitică cu o singură interfață care să blocheze totul împreună. Ce își doresc este ca metricele, jurnalele și trasările să ruleze pe un singur model operațional, un singur furnizor și o singură poveste de licențiere, fără a fi nevoiți să renunțe la posibilitatea de a rula fiecare semnal independent dacă aceasta este necesitatea unei echipe. Aceasta este direcția în care VictoriaMetrics construiește. Nu încercăm să forțăm totul într-un singur binar. Încercăm să ne asigurăm că cele trei semnale împărtășesc același motor și aceleași caracteristici de eficiență, astfel încât adăugarea unui al doilea sau al treilea semnal să nu însemne adoptarea unei a doua sau a treia bătăi de cap operaționale.

Platformele care rămân relevante sunt cele care pot absorbi telemetria AI și monitorizarea GPU în același model fără ca curba de costuri să se rupă. Sarcinile AI generează telemetrie la un volum pentru care prețurile tradiționale pe metrică sau pe gazdă nu au fost niciodată concepute. Echipele fie încetează să colecteze datele de care au nevoie, fie factura de observabilitate crește mai repede decât investiția în AI pe care ar trebui să o monitorizeze. Echipele de inginerie se vor aștepta ca platformele să gestioneze acel volum în același mod în care se așteaptă ca orice infrastructură să se scaleze, fără a le cere să refacă arhitectura sau să renegocieze de fiecare dată când sarcina crește.

Vă mulțumim pentru interviul excelent, cititorii care doresc să afle mai multe ar trebui să viziteze VictoriaMetrics.