Dzmitry Lazerka, medstifter af VictoriaMetrics – Interviewserie

Dzmitry Lazerka, medstifter af VictoriaMetrics er en erfaren softwareingeniør og teknologileder med dyb ekspertise inden for maskinlæring, store datasystemer, observabilitet og infrastruktur. Før han medstiftede VictoriaMetrics i 2018, arbejdede han som maskinlæringsingeniør i Lyft’s Level 5 autonome køretøjsdivision, hvor han hjalp med at udvikle systemer til at genkende og analysere virkelige kørescenarier. Tidligere ledede han maskinlærings- og datainfrastrukturprojekter hos Spire Global, var medstifter af Bellgram, og arbejdede på data- og analysesystemer hos Duetto Research og Google gennem EPAM Systems. Gennem sin karriere har Lazerka bygget og ledet projekter inden for autonom kørsel, maritim forudsigelse, søgning, analyse, distribueret databehandling og meget skalerbare backend-systemer.

VictoriaMetrics er en open-source observabilitetsvirksomhed, der bygger værktøjer til indsamling, lagring, forespørgsel og analyse af store mængder driftsdata. Teknologien startede med VictoriaMetrics, en højtydende tidsseriedatabase og overvågningsløsning designet til skalerbarhed, hurtige forespørgsler, effektiv lagring og lav driftsomkostning, og har siden udvidet sig til en bredere observabilitetsstack, der dækker metrics, logs og distribuerede spor gennem VictoriaMetrics, VictoriaLogs og VictoriaTraces. Virksomheden tilbyder også enterprise‑ og fuldt administrerede cloud‑deploymenter samt anomalidetektionsfunktioner, der anvender maskinlæring på tidsseriedata. Platformen understøtter teknologier som OpenTelemetry, Prometheus‑kompatible arbejdsgange, Grafana og Kubernetes, hvilket giver organisationer fleksibilitet til at integrere VictoriaMetrics i eksisterende observabilitetsmiljøer.

Før du medstiftede VictoriaMetrics, arbejdede du med store data-, analyse- og maskinlæringssystemer hos Google, Spire Global, Lyft’s autonome køretøjsdivision og andre startups. Hvad førte dig i sidste ende til at grundlægge VictoriaMetrics, og hvilke problemer fra de tidligere roller overbeviste dig om, at overvågning og observabilitet havde brug for en grundlæggende anderledes tilgang?

Jeg har tilbragt min karriere med at arbejde med store datamængder. Hos Google, Spire, Lyft og andre virksomheder lærer man hurtigt, at noget der fungerer godt i én skala, kan blive dyrt eller svært at drive i en anden skala. Overvågning har præcis dette problem.

Efterhånden som infrastrukturen vokser, skaber du flere metrics. Du tilføjer flere tjenester, flere instanser og flere labels, indtil pludselig overvågningssystemet selv kræver en betydelig mængde infrastruktur, hvilket aldrig gav mening for os. Et system designet til at overvåge dit produktionsmiljø bør ikke blive mere kompliceret og dyrt at drive.

Dette var, hvad mine medstiftere Aliaksandr Valialkin og Roman Khavronenko så direkte. De havde erfaring med at drive Prometheus og stødte på hukommelsesbegrænsninger. Tilføjelse af systemer som Thanos løste visse skaleringsproblemer, men introducerede også flere komponenter og mere driftskompleksitet. Og med InfluxDB så vi, hvordan en licensændring kunne påvirke ingeniørbeslutninger, efter at teams allerede havde investeret i teknologien.

Så idéen bag VictoriaMetrics var praktisk: Kan vi bygge en tidsseriedatabase, der udfører det samme arbejde med betydeligt færre ressourcer og er enklere at drive?

Vi startede ikke med en plan om at bygge en stor observabilitetsvirksomhed. Vi begyndte med at løse et ingeniørproblem.

At gøre den open source var en del af det. Ingeniører kunne downloade VictoriaMetrics, køre reelle produktionsarbejdsbelastninger på den og sammenligne resultaterne selv. Vi behøvede ikke at fortælle dem, at den var hurtigere eller mere effektiv. De kunne måle det.

Dette er den bedste måde at bygge infrastruktursoftware på. Hvis teknologien er god, bør ingeniører kunne bevise det selv.

Observabilitetsomkostninger kan stille og roligt udgøre en betydelig del af en virksomheds cloud‑regning. Hvor bliver disse omkostninger typisk ude af kontrol, og hvilke arkitektoniske eller indkøbsbeslutninger begår ingeniørteamene oftest forkert?

Jeg vil først se på kardinalitet.

Lad os sige, du starter med en rimelig metric, og så tilføjer en label med mulige værdier. Pludselig bliver én metric til tusinder eller millioner af unikke tidsserier. Systemet har nu mere data at indtage, indeksere, lagre og forespørge, hvilket resulterer i mere CPU, hukommelse og lagerplads.

Den svære del er, at dette ikke sker fordi nogen har truffet en dårlig beslutning. Det sker gradvist. Tilføj flere tjenester, K8s‑pods, kunder og labels, så multipliceres omkostningerne.

Det andet problem er at gemme alt med samme opløsning i samme tidsperiode. Ikke al observabilitetsdata har samme værdi. De metrics, du har brug for til en alarm eller et SLO, er forskellige fra den højvolumen diagnostiske telemetri, du måske kun ser én gang under en hændelse.

Hvis du behandler al den data ens, ender du med at betale premium‑infrastruktur eller SaaS‑priser for data, der ikke kræver det.

Det er derfor, nogle virksomheder ser på observabilitet som et indkøbsproblem og spørger, hvilken platform der er lettest at implementere i dag. Jeg stiller spørgsmål som: “Hvad sker der, når mængden af telemetri øges 10‑fold? Hvad sker der med kardinaliteten? Hvad gemmer vi? Hvor længe? Og hvad sker der med omkostningerne?”

Der findes ingeniørløsninger på disse problemer. For eksempel kan du med streaming‑aggregation aggregere metrics, før de når lagringen, i stedet for at gemme hver rå tidsserie og aggregere den senere. Du kan adskille høj‑kardinalitets‑arbejdsbelastninger fra forretningskritisk overvågning. Du kan også anvende forskellige fastholdelses‑ og opløsningspolitikker afhængigt af dataens værdi.

Målet er ikke at indsamle så lidt telemetri som muligt. Du har brug for nok information til at forstå, hvad dine systemer gør.

Målet er at undgå at bruge ressourcer på at indsamle, behandle og lagre data på en måde, der ikke giver dig ekstra værdi.

Observabilitet er et ingeniørsystem. Dets omkostninger bør også designes.

Grammarly har sagt, at deres proof‑of‑concept med VictoriaMetrics resulterede i en 10‑gang lavere AWS‑regning. Når virksomheder opnår besparelser i den skala, hvad ændrer der sig egentlig under motorhjelmen: datakomprimering, beregningskrav, lagringsarkitektur, driftskompleksitet eller en kombination af disse faktorer?

Det er en kombination, men komprimeringen og ressourceforbruget udfører det meste af arbejdet. VictoriaMetrics bruger specialbygget komprimering til tidsseriedata, så de samme metrics optager en brøkdel af den diskplads, de ville i en generel database. Derudover kører vi fire til fem gange lettere på RAM end Prometheus ved tilsvarende indtagsrater, og op til 10‑gang lettere på disk. Da Grammarly kørte deres proof‑of‑concept, fremgik det direkte i deres AWS‑regning, fordi de ikke kun gemte mindre data; de kørte færre og mindre instanser for at gøre det.

Den driftskompleksitet spiller også en rolle, men den er mere indirekte. Mange teams, der beregner observabilitetsomkostninger, ser kun på lagrings‑ og beregningsposterne og overser de ingeniørtimer, der bruges på at drive en fem‑komponents Thanos‑stack i stedet for en enkelt binær. Det er rigtige penge; det er blot sværere at sætte et tal på.

Prometheus er blevet grundlæggende for cloud‑native overvågning, men nogle organisationer støder efterhånden på skalerings‑ eller driftsbegrænsninger. Hvad får typisk en virksomhed til at begynde at kigge ud over en konventionel Prometheus‑deployment, og hvornår bliver VictoriaMetrics et logisk alternativ?

Prometheus er fremragende til det, det blev bygget til: en enkelt-node indsamling- og alarmmotor. Teams støder typisk på en mur på to måder: Enten vokser deres kardinalitet ud over, hvad en enkelt Prometheus‑instans kan holde i hukommelsen, eller de har brug for langtidsopbevaring og global forespørgsel på tværs af flere klynger, hvilket Prometheus aldrig var designet til at gøre på egen hånd. Det er da, folk tilføjer Thanos eller Cortex, hvilket som regel er, hvor den operationelle smerte begynder. Man går fra at køre én binær til at køre et distribueret system med en komprimeringskomponent, en forespørgselskomponent, en lagringsgateway og meget mere, som kan gå i stykker kl. 3 om morgenen.

VictoriaMetrics bliver det logiske næste skridt, fordi det er en drop‑in‑erstatning, ikke en genarkitektur. Teams peger deres eksisterende Prometheus‑indsamlingskonfiguration mod VictoriaMetrics og beholder alle Grafana‑dashboards, alarmer og optagelsesregler, de allerede har bygget. Migrationen er en konfigurationsændring, ikke et projekt, og de får skalerbarheden uden at skulle tilføje fem nye komponenter til driften.

Vi ser, at ingeniørteams genovervejer, om de har brug for store, fuldt administrerede observabilitetsplatforme, eller om de kan bygge mere effektive stakke af open‑source‑komponenter. Ser du dette som et bredere strukturelt skift på observabilitetsmarkedet, og hvor meget pres lægger open source på traditionelle prismodeller?

Det er strukturelt; ikke en midlertidig reaktion på et dårligt budgetår. Observabilitetsleverandører har historisk prissat enten efter indtagsvolumen eller antal værter, og den model virker imod kunden, efterhånden som deres forretning vokser. Jo mere succesfuld en virksomhed bliver, jo mere betaler den, og prisen har ingen reel sammenhæng med den leverede værdi. Ingeniørteams er begyndt at lave beregningerne selv og indser, at en selv‑hostet, effektiv open‑source‑stak ændrer den ligning fuldstændigt. Det skyldes, at omkostningerne skalerer med den infrastruktur, der faktisk kører, frem for en måleformel, som en leverandør kontrollerer.

Dette lægger reelt pres på de etablerede prisstrukturer. Når et team kan pege deres eksisterende indsamlingskonfiguration på et open‑source‑alternativ og reducere regningen med 60 til 80 % uden at miste funktionalitet, er det ikke en svær samtale internt. Leverandørerne, der stadig opkræver per vært eller brugerdefineret metrik, vil fortsat tømme kunder, der ikke laver denne beregning.

AI‑infrastruktur introducerer en usædvanligt dyr ny ressource i ligningen: GPU’er. Hvad bør virksomheder, der kører AI‑træning eller inferens, overvåge udover grundlæggende GPU‑udnyttelse, og hvor kan bedre observabilitet direkte omsættes til lavere AI‑infrastrukturomkostninger?

GPU‑udnyttelse alene fortæller dig ikke nok.

Du kan se 90 % udnyttelse på et dashboard og antage, at alt er i orden. Men det, du virkelig vil vide, er: Hvad laver GPU’en?

Du skal grave dybere. Hvilke CUDA‑kerner kører? Hvordan allokeres GPU‑hukommelsen? Hvor meget tid bruges på at flytte hukommelse i stedet for at udføre beregninger? Bruger arbejdsbelastningen Tensor‑Cores, når den burde? Er GPU’en faktisk flaskehalsen, eller venter den på data fra et andet sted?

Dette er vigtige spørgsmål, fordi GPU’er er dyre. En lille ineffektivitet, der gentages på hundreder eller tusinder af GPU’er, bliver til en meget stor pengebeløb.

For eksempel, hvis GPU’er venter, fordi datapipelinen ikke kan forsyne dem hurtigt nok, vil køb af flere GPU’er ikke løse problemet. Du skal finde flaskehalsen. Det samme gælder hukommelsen. Hvis arbejdsbelastninger allokerer hukommelse ineffektivt, kan bedre synlighed hjælpe ingeniører med at justere batch‑størrelser eller køre flere arbejdsbelastninger på den samme hardware.

Det er her, observabilitet bliver interessant for AI‑infrastruktur. Det handler ikke kun om at opdage, at noget er i stykker. Det kan fortælle dig, hvor du spilder beregning.

Der er også et observabilitetsproblem skabt af al denne overvågning. GPU’er kan generere en masse detaljeret, høj‑kardinalitet telemetry. Hvis du indsamler alt og sender det direkte til en dyr SaaS‑platform, kan du reducere dine GPU‑omkostninger og så bruge en del af besparelsen på at gemme overvågningsdata. Men det er ikke en god optimering.

Med OpenTelemetry og projekter som OpenLIT kan vi få meget dybere indsigt i GPU‑arbejdsbelastninger. Derefter kan vi med VictoriaMetrics aggregere dataene, fjerne dimensioner, der ikke er nyttige, og effektivt bevare den information, som ingeniører faktisk har brug for.

Det nyttige spørgsmål er ikke: “Hvor udnyttede er mine GPU’er?”

Det er: “Hvilket nyttigt arbejde får jeg ud af de GPU’er, jeg betaler for?”

Når du kan besvare det, kan du begynde at træffe bedre ingeniør‑ og omkostningsbeslutninger.

AI‑agenter skaber meget forskellige observabilitetsudfordringer i forhold til traditionel software, fordi en enkelt anmodning kan udløse model‑kald, værktøjsbrug, vektor‑database‑forespørgsler, overdragelser og potentielt lange kæder af autonome handlinger. Hvordan skal observabilitet udvikle sig, når virksomheds‑applikationer i stigende grad bliver agent‑baserede?

Traditionel observabilitet antager, at en anmodning følger en forholdsvis forudsigelig sti gennem din infrastruktur. Agent‑baserede arbejdsbelastninger fungerer ikke på den måde. En enkelt agent kan kalde en model, derefter et værktøj, så en anden model og prøve tre gange, før den returnerer noget. Hvert af disse trin kræver sin egen synlighed.

Fejltilstandene er også forskellige. En traditionel tjeneste svarer enten korrekt eller svarer ikke. En agent kan svare succesfuldt og stadig være forkert, langsom eller dyr, og intet af dette vises som en typisk fejl i et dashboard designet til oppetid.

Det, der overrasker teams, er kardinaliteten. En enkelt agents arbejdsflow kan generere metrikker knyttet til en specifik bruger, prompt og værktøjskald, og den mængde vokser hurtigt, især med rekursions‑loops hvor en planlægger fortsat kalder det samme værktøj. Ethvert system, der skal observere agent‑baserede arbejdsbelastninger, skal kunne håndtere den skala uden at omkostningskurven går lodret, hvilket er præcis det problem, vi løser. Metrikker, logs og spor er stadig de rette byggesten. Det, der skal ændres, er volumen og omkostningsmodellen under dem.

VictoriaMetrics har også anvendt maskinlæring og AI‑assisterede arbejdsprocesser til anomali‑detektion. Hvor mener du, at AI i dag kan forbedre overvågning og hændelsesrespons ægte, og hvor er menneskelig dømmekraft stadig svær at erstatte?

Det er vigtigt at holde en person i kredsløbet for at generere idéer, styre implementeringen og validere resultaterne. Med andre ord har der i bund og grund ikke ændret sig i forhold til den traditionelle arbejdsproces. Det, der har ændret sig, er, at evnerne til at generere løsninger er forstærket. Alle kan nu skabe software, men det bør ikke sænke acceptkriterierne. Det bør snarere hæve dem betydeligt.

Hvor AI virkelig hjælper, er ved at fremhæve, hvad en person ellers ville overse i støjen, såsom outliers og tendenser, der ikke udløser en manuel tærskel. Hos VictoriaMetrics har vi en simpel intern AI‑politik: Medarbejdere er fri til at automatisere deres arbejdsproces, som de vil, men de forbliver ansvarlige for slutresultatet. Det er stort set den samme standard, vi ville anvende på anomali‑detektion i en kundes produktionsmiljø. Modellen kan flagge det, men en person skal stadig afgøre, hvad det betyder, og hvad der skal gøres ved det.

VictoriaMetrics har forblevet open source og har valgt en selv‑finansieret, kunde‑finansieret tilgang i stedet for den traditionelle venture‑backede infrastruktur‑startup‑model. Hvordan har det påvirket den måde, I bygger produktet på, prissætter det, og beslutter, hvilke teknologier der forbliver open source?

At være selv‑finansieret ændrer incitamentsstrukturen mere, end folk forventer. Uden et bestyrelsesmedlem, der kræver, at vi rammer et ARR‑tal inden for et specifikt kvartal, har vi ikke behøvet at foretage de afvejninger, der normalt følger med det pres, såsom at svække open‑source‑versionen for at tvinge folk ind i en betalt tier, eller ændre licensen som InfluxDB eller HashiCorp gjorde, da de skulle beskytte indtægter fra cloud‑udbydere. VictoriaMetrics OSS er Apache 2.0 i dag, og vi har ingen planer om at ændre det.

Den måde, vi beslutter, hvad der forbliver open source, er enkel: Kernemotoren, den del, som ingeniører skal kunne stole på med deres produktionsdata, forbliver åben. Vi opkræver for det, en virksomhed har brug for, når den kører i stor skala og har brug for en ansvarlig part: multi‑tenancy, virksomhedsautentificering, compliance‑support, en CVE‑SLA og direkte adgang til de ingeniører, der har skrevet koden, i stedet for en support‑kø. At være kunde‑finansieret betyder også, at roadmap’en fastsættes af, hvad folk faktisk støder på i produktionen, ikke af, hvad der kan finansieres i en pitch‑deck.

Efterhånden som metrics, logs, traces, AI‑applikationstelemetri, GPU‑overvågning og automatiseret anomali‑detektion i stigende grad konvergerer, hvordan tror du, observabilitets‑stacken vil se ud i løbet af de næste par år, og hvad vil ingeniørteams forvente af platforme, der ønsker at forblive relevante?

Stacken konvergerer operationelt, før den konvergerer som et enkelt produkt, og den sondring er vigtig. De fleste teams ønsker ikke én monolitisk platform med en enkelt brugergrænseflade, der låser alting sammen. Det, de vil have, er metrics, logs og traces, der kører på én operationel model, én leverandør og én licenshistorie, uden at skulle opgive muligheden for at køre hvert signal uafhængigt, hvis det er, hvad et givet team har brug for. Det er den retning, VictoriaMetrics bygger i. Vi forsøger ikke at samle alting i én enkelt binær fil. Vi forsøger at sikre, at de tre signaler deler den samme motor og de samme effektivitetsegenskaber, så tilføjelsen af et andet eller tredje signal ikke betyder, at man skal håndtere et andet eller tredje operationelt hovedpinepunkt.

De platforme, der forbliver relevante, er dem, der kan absorbere AI‑telemetri og GPU‑overvågning i den samme model uden, at omkostningskurven bryder sammen. AI‑arbejdsbelastninger genererer telemetri i et omfang, som den ældre prissætning pr. metric eller pr. host aldrig var designet til. Teams stopper enten med at indsamle de data, de har brug for, eller deres observabilitetsregning vokser hurtigere end AI‑investeringen, den skal overvåge. Ingeniørteams vil forvente, at platforme håndterer dette volumen på samme måde, som de forventer, at enhver infrastruktur skalerer, uden at skulle omdesigne eller genforhandle hver gang arbejdsbelastningen vokser.

Tak for det fantastiske interview, læsere der ønsker at lære mere, bør besøge VictoriaMetrics.