Dzmitry Lazerka, medgründer av VictoriaMetrics – Intervjuserie

Dzmitry Lazerka, medgründer av VictoriaMetrics er en erfaren programvareingeniør og teknologileder med dyp kompetanse innen maskinlæring, storskala datasystemer, observabilitet og infrastruktur. Før han medgründet VictoriaMetrics i 2018, jobbet han som maskinlæringsingeniør i Lyft’s Level 5 autonome kjøretøysavdeling, hvor han bidro til å utvikle systemer for å gjenkjenne og analysere virkelige kjørescenarier. Tidligere ledet han maskinlæring- og datainfrastrukturprosjekter hos Spire Global, var medgründer av engineering hos Bellgram, og arbeidet med data- og analyssystemer hos Duetto Research og Google via EPAM Systems. Gjennom karrieren har Lazerka bygget og ledet prosjekter som spenner over autonom kjøring, maritim prediksjon, søk, analyse, distribuert dataprosessering og svært skalerbare backend-systemer.

VictoriaMetrics er et åpen kildekode observabilitetsfirma som bygger verktøy for innsamling, lagring, spørring og analyse av store mengder operasjonelle data. Teknologien startet med VictoriaMetrics, en høyytelses tidsseriedatabase og overvåkningsløsning designet for skalerbarhet, raske spørringer, effektiv lagring og lav driftskostnad, og har siden utvidet seg til en bredere observabilitetsstack som dekker måledata, logger og distribuerte spor gjennom VictoriaMetrics, VictoriaLogs og VictoriaTraces. Selskapet tilbyr også bedrifts‑ og fullt administrerte sky‑distribusjoner, samt avviksdeteksjonsfunksjoner som bruker maskinlæring på tidsseriedata. Plattformen støtter teknologier som OpenTelemetry, Prometheus‑kompatible arbeidsflyter, Grafana og Kubernetes, og gir organisasjoner fleksibilitet til å integrere VictoriaMetrics i eksisterende observabilitetsmiljøer.

Før du medgründet VictoriaMetrics, jobbet du med storskala data-, analyse‑ og maskinlæringssystemer hos Google, Spire Global, Lyft’s autonome kjøretøysavdeling og andre oppstartsbedrifter. Hva førte deg til slutt til å grunnlegge VictoriaMetrics, og hvilke problemer fra de tidligere rollene overbeviste deg om at overvåking og observabilitet trengte en grunnleggende annerledes tilnærming?

Jeg har tilbrakt karrieren med å jobbe med store mengder data. Hos Google, Spire, Lyft og andre selskaper lærer du raskt at noe som fungerer bra i én skala kan bli dyrt eller vanskelig å drifte i en annen skala. Overvåking har akkurat dette problemet.

Når infrastrukturen vokser, lager du flere måledata. Du legger til flere tjenester, flere instanser og flere etiketter til du plutselig ser at overvåkingssystemet selv krever en betydelig mengde infrastruktur, noe som aldri ga mening for oss. Et system designet for å overvåke ditt produksjonsmiljø bør ikke bli mer komplisert og dyrt å drifte.

Dette var det mine medgründere Aliaksandr Valialkin og Roman Khavronenko så direkte. De hadde erfaring med å drive Prometheus og støtte på minnebegrensninger. Å legge til systemer som Thanos løste visse skaleringsproblemer, men introduserte også flere komponenter og mer operasjonell kompleksitet. Og med InfluxDB så vi hvordan en lisensendring kunne påvirke ingeniørbeslutninger etter at team allerede hadde investert i teknologien.

Så idéen bak VictoriaMetrics var praktisk: Kan vi bygge en tidsseriedatabase som gjør samme jobb med betydelig færre ressurser og er enklere å drifte?

Vi startet ikke med en plan om å bygge et stort observabilitetsfirma. Vi begynte med å løse et ingeniørproblem.

Å gjøre det åpen kildekode var en del av dette. Ingeniører kunne laste ned VictoriaMetrics, legge ekte produksjonsbelastninger på det og sammenligne resultatene selv. Vi trengte ikke å fortelle dem at det var raskere eller mer effektivt. De kunne måle det.

Dette er den beste måten å bygge infrastrukturprogramvare på. Hvis teknologien er god, bør ingeniører kunne bevise det selv.

Observabilitetskostnader kan stille og rolig bli en betydelig del av et selskaps skyregning. Hvor blir disse kostnadene vanligvis ute av kontroll, og hvilke arkitektur‑ eller innkjøpsbeslutninger gjør ingeniørteam oftest feil?

Jeg vil først se på kardinalitet.

La oss si at du starter med en rimelig måling, og deretter legger til en etikett med mulige verdier. Plutselig blir én måling tusenvis eller millioner av unike tidsserier. Systemet har nå mer data å ta inn, indeksere, lagre og spørring, noe som resulterer i mer CPU, minne og lagring.

Den vanskelige delen er at dette ikke skjer fordi noen tok en dårlig beslutning. Det skjer gradvis. Legg til flere tjenester, K8s‑pods, kunder og etiketter, og kostnaden multipliseres.

Det andre problemet er å lagre alt med samme oppløsning over samme tidsperiode. Ikke all observabilitetsdata har samme verdi. Målingene du trenger for en alarm eller et SLO er forskjellige fra høy‑volum diagnostisk telemetri du kanskje ser på én gang under en hendelse.

Hvis du behandler all denne dataen likt, ender du opp med å betale premium‑infrastruktur‑ eller SaaS‑priser for data som ikke krever det.

Dette er grunnen til at noen selskaper ser på observabilitet som et innkjøpsproblem, og spør hvilken plattform som er enklest å distribuere i dag. Jeg stiller spørsmål som: «Hva skjer når mengden telemetri øker ti‑fold? Hva skjer med kardinaliteten? Hva lagrer vi? Hvor lenge? Og hva skjer med kostnaden?»

Det finnes ingeniørløsninger på disse problemene. For eksempel kan du med strøm‑aggregasjon aggregere målinger før de når lagring i stedet for å lagre hver rå tidsserie og aggregere den senere. Du kan skille høy‑kardinalitets‑arbeidsbelastninger fra forretningskritisk overvåking. Du kan også bruke ulike retensjons‑ og oppløsningspolicyer avhengig av dataens verdi.

Målet er ikke å samle så lite telemetri som mulig. Du trenger nok informasjon til å forstå hva systemene dine gjør.

Målet er å unngå å bruke ressurser på å samle, behandle og lagre data på en måte som ikke gir deg ekstra verdi.

Observabilitet er et ingeniørsystem. Kostnadene bør også bli konstruert.

Grammarly har sagt at deres proof‑of‑concept med VictoriaMetrics førte til en ti‑fold lavere AWS‑regning. Når selskaper oppnår besparelser i den skalaen, hva endrer seg egentlig under panseret: datakomprimering, beregningskrav, lagringsarkitektur, operasjonell kompleksitet, eller en kombinasjon av disse faktorene?

Det er en kombinasjon, men komprimeringen og ressursfotavtrykket gjør mesteparten av arbeidet. VictoriaMetrics bruker spesialbygd komprimering for tidsseriedata, så de samme målingene opptar en brøkdel av diskplassen de ville gjort i en generell database. I tillegg bruker vi fire til fem ganger mindre RAM enn Prometheus ved tilsvarende inntakshastigheter, og opptil ti ganger mindre disk. Da Grammarly kjørte sitt proof‑of‑concept, viste det seg direkte i deres AWS‑regning, fordi de ikke bare lagret mindre data; de kjørte færre og mindre instanser for å gjøre det.

Den operasjonelle kompleksiteten spiller også en rolle, men den er mer indirekte. Mange team som priser observabilitetskostnader ser kun på lagrings‑ og beregningspostene og overser ingeniørtimene som brukes på å drifte en fem‑komponent‑Thanos‑stack versus en enkelt binær. Det er ekte penger; det er bare vanskeligere å sette et tall på.

Prometheus har blitt grunnleggende for sky‑native overvåking, men noen organisasjoner støter etter hvert på skalerings‑ eller operasjonsbegrensninger. Hva får vanligvis et selskap til å begynne å se utover en konvensjonell Prometheus‑distribusjon, og når blir VictoriaMetrics et logisk alternativ?

Prometheus er utmerket på det den ble bygget for: en enkelt-node innsamling- og alarmmotor. Team støter vanligvis på en vegg på to måter: Enten vokser kardinaliteten forbi hva en enkelt Prometheus-instans kan holde i minnet, eller de trenger langtidslagring og global spørring på tvers av flere klynger, noe Prometheus aldri ble designet for å gjøre på egen hånd. Det er da folk legger til Thanos eller Cortex, som vanligvis er der den operasjonelle smerten begynner. Du går fra å kjøre én binær til å kjøre et distribuert system med en komprimerer, en spørrer, en lagringsgateway og mye mer som kan gå i stykker klokken 03.00.

VictoriaMetrics blir det logiske neste steget fordi det er en drop‑in‑erstatning, ikke en ny arkitektur. Team peker sin eksisterende Prometheus‑innsamlingskonfigurasjon mot VictoriaMetrics og beholder alle Grafana‑dashbord, alarmer og opptaksregler de allerede har bygget. Migreringen er en konfigurasjonsendring, ikke et prosjekt, og de får skalaen uten å legge til fem nye komponenter som må driftes.

Vi ser at ingeniørteam revurderer om de trenger store, fullt administrerte observabilitetsplattformer eller om de kan bygge mer effektive stakker fra åpen‑kilde‑komponenter. Ser du dette som et bredere strukturelt skifte i observabilitetsmarkedet, og hvor mye press legger åpen kilde på tradisjonelle prismodeller?

Det er strukturelt; ikke en midlertidig reaksjon på et dårlig budsjettår. Observabilitetsleverandører har historisk priset etter enten inntaksvolum eller antall verter, og den modellen virker mot kunden etter hvert som virksomheten vokser. Jo mer suksessfullt et selskap blir, jo mer betaler det, og prisene har ingen reell sammenheng med den leverte verdien. Ingeniørteam har begynt å gjøre regnestykket selv, og innser at en selv‑hostet, effektiv åpen‑kilde‑stakk endrer den ligningen fullstendig. Dette skyldes at kostnaden skalerer med infrastrukturen som faktisk kjøres, snarere enn en måleformel som leverandøren kontrollerer.

Dette legger reelt press på eksisterende prisstrukturer. Når et team kan peke sin eksisterende innsamlingskonfigurasjon mot et åpen‑kilde‑alternativ og kutte regningen med 60 til 80 % uten å miste funksjonalitet, er det ikke en vanskelig samtale internt. Leverandørene som fortsatt tar betalt per vert eller egendefinert metrikk vil fortsette å tappe kunder som ikke gjør dette regnestykket.

AI‑infrastruktur introduserer en uvanlig dyr ny ressurs i ligningen: GPU‑er. Hva bør selskaper som kjører AI‑trening eller inferens overvåke utover grunnleggende GPU‑utnyttelse, og hvor kan bedre observabilitet direkte oversettes til lavere AI‑infrastrukturkostnader?

GPU‑utnyttelse alene forteller deg ikke nok.

Du kan se 90 % utnyttelse på et dashbord og anta at alt er i orden. Men det du egentlig vil vite er: Hva gjør GPU‑en?

Du må se dypere. Hvilke CUDA‑kjerner kjører? Hvordan blir GPU‑minnet allokert? Hvor mye tid brukes på å flytte minne i stedet for å utføre beregning? Bruker arbeidsbelastningen Tensor Cores når den burde? Er GPU‑en faktisk flaskehalsen, eller venter den på data fra et annet sted?

Dette er viktige spørsmål fordi GPU‑er er dyre. En liten ineffektivitet som gjentas over hundre eller tusenvis av GPU‑er blir en svært stor sum penger.

For eksempel, hvis GPU‑er venter fordi datapipelinen ikke kan levere data raskt nok, vil kjøp av flere GPU‑er ikke løse problemet. Du må finne flaskehalsen. Det samme gjelder minnet. Hvis arbeidsbelastninger allokerer minne ineffektivt, kan bedre innsikt hjelpe ingeniører med å justere batch‑størrelser eller kjøre flere arbeidsbelastninger på samme maskinvare.

Dette er hvor observabilitet blir interessant for AI‑infrastruktur. Det handler ikke bare om å oppdage at noe er ødelagt. Det kan fortelle deg hvor du sløser med beregning.

Det finnes også et observabilitetsproblem skapt av all denne overvåkingen. GPU‑er kan generere mye detaljert, høy‑kardinalitets‑telemetri. Hvis du samler alt og sender det direkte inn i en dyr SaaS‑plattform, kan du redusere GPU‑kostnadene og deretter bruke en del av besparelsene på lagring av overvåkingsdata. Men det er ikke en god optimalisering.

Med OpenTelemetry og prosjekter som OpenLIT kan vi få mye dypere innsikt i GPU‑arbeidsbelastninger. Deretter, med VictoriaMetrics, kan vi aggregere dataene, fjerne dimensjoner som ikke er nyttige og effektivt beholde informasjonen ingeniører faktisk trenger.

Det nyttige spørsmålet er ikke: «Hvor utnyttet er GPU‑ene mine?»

Det er: «Hva slags nyttig arbeid får jeg fra GPU‑ene jeg betaler for?»

Når du kan svare på det, kan du begynne å ta bedre ingeniør‑ og kostnadsbeslutninger.

AI‑agenter skaper svært ulike observabilitetsutfordringer sammenlignet med tradisjonell programvare fordi en enkelt forespørsel kan utløse modell‑kall, verktøybruk, vektordatabase‑spørringer, overleveringer, og potensielt lange kjeder av autonome handlinger. Hvordan må observabiliteten utvikles etter hvert som bedriftsapplikasjoner blir stadig mer agentbaserte?

Tradisjonell observabilitet forutsetter at en forespørsel følger en relativt forutsigbar sti gjennom infrastrukturen din. Agentbaserte arbeidsbelastninger fungerer ikke slik. En enkelt agent kan kalle en modell, deretter et verktøy, så en annen modell og prøve på nytt tre ganger før den returnerer noe. Hvert av disse trinnene trenger sin egen synlighet.

Feilmønstrene er også forskjellige. En tradisjonell tjeneste svarer enten korrekt eller ikke. En agent kan svare vellykket og likevel være feil, treg eller dyr, og ingenting av dette vises som en typisk feil i et dashbord laget for oppetid.

Det som overrasker team er kardinalitet. En enkelt agent‑arbeidsflyt kan generere metrikk knyttet til en spesifikk bruker, prompt og verktøykall, og den mengden øker raskt, spesielt med rekursjonsløkker hvor en planlegger stadig kaller det samme verktøyet. Ethvert system som skal observere agentbaserte arbeidsbelastninger må håndtere den skalaen uten at kostnadskurven går vertikalt, noe som er akkurat problemet vi løser. Metrikker, logger og spor er fortsatt de rette byggesteinene. Det som må endres er volumet og kostnadsmodellen under dem.

VictoriaMetrics har også tatt i bruk maskinlæring og AI‑assisterte arbeidsflyter for avviksdeteksjon. Hvor tror du AI virkelig kan forbedre overvåkning og hendelsesrespons i dag, og hvor er menneskelig dømmekraft fortsatt vanskelig å erstatte?

Det er viktig å ha en person med i prosessen for å generere ideer, styre implementeringen og validere resultatene. Med andre ord har ingenting egentlig endret seg sammenlignet med den tradisjonelle arbeidsflyten. Det som har endret seg er at evnene til å generere løsninger er forsterket. Alle kan lage programvare nå, men det bør ikke senke akseptkriteriene. Det bør heve dem betydelig.

Der AI virkelig hjelper, er å avdekke det en person ellers ville gå glipp av i støyen, ting som avvik og trender som ikke utløser en manuell terskel. Hos VictoriaMetrics har vi en enkel intern AI‑policy: Ansatte står fritt til å automatisere arbeidsflyten sin på hvilken som helst måte, men de er fortsatt ansvarlige for sluttresultatet. Det er omtrent samme standard vi ville brukt på avviksdeteksjon i en kundes produksjonsmiljø. Modellen kan flagge det, men en person må fortsatt avgjøre hva det betyr og hva som skal gjøres med det.

VictoriaMetrics har forblitt åpen kilde og har tatt en selv‑finansiert, kunde‑finansiert tilnærming i stedet for å følge den tradisjonelle venture‑støttede infrastruktur‑oppstartmodellen. Hvordan har dette påvirket måten du bygger produktet på, priser det, og bestemmer hvilke teknologier som forblir åpen kilde?

Å være selv‑finansiert endrer insentivstrukturen mer enn folk forventer. Uten et styre som krever at vi når et ARR‑tall innen et bestemt kvartal, har vi ikke trengt å gjøre de avveiningene som vanligvis følger med det presset, som å svekke den åpne kilde‑versjonen for å tvinge folk inn i en betalt tier, eller endre lisensen slik InfluxDB eller HashiCorp gjorde da de måtte beskytte inntektene mot sky‑leverandører. VictoriaMetrics OSS er Apache 2.0 i dag, og vi har ingen planer om å endre det.

Måten vi bestemmer hva som forblir åpen kildekode på er enkel: Kjerne­motoren, det ingeniørene må stole på med produksjonsdataene sine, forblir åpen. Vi tar betalt for det en bedrift trenger når den kjører i skala og trenger noen ansvarlige: flerleietakelse, bedriftsautentisering, etterlevelsesstøtte, en CVE‑SLA og direkte tilgang til ingeniørene som skrev koden i stedet for en supportkø. Å være kundestøttet betyr også at veikartet settes av det folk faktisk støter på i produksjon, ikke av det som er finansierbart i en pitch‑deck.

Ettersom målinger, logger, sporinger, AI‑applikasjonstelemetri, GPU‑overvåkning og automatisert avviksdeteksjon i økende grad konvergerer, hvordan tror du observabilitetsstakken vil se ut de neste årene, og hva vil ingeniørteam forvente av plattformer som ønsker å forbli relevante?

Stakken konvergerer operasjonelt før den konvergerer som ett enkelt produkt, og den distinksjonen er viktig. De fleste team vil ikke ha én monolitisk plattform med ett enkelt brukergrensesnitt som låser alt sammen. Det de ønsker er målinger, logger og sporinger som kjører på én operasjonsmodell, én leverandør og én lisenshistorie, uten å måtte gi opp muligheten til å kjøre hvert signal uavhengig dersom det er det et gitt team trenger. Det er retningen VictoriaMetrics bygger mot. Vi prøver ikke å slå alt sammen i én binærfil. Vi prøver å sikre at de tre signalene deler samme motor og samme effektivitetskarakteristikker, slik at tillegg av et andre eller tredje signal ikke betyr at man må ta på seg et andre eller tredje operasjonelt hodepine.

Plattformene som forblir relevante er de som kan absorbere AI‑telemmetri og GPU‑overvåkning inn i samme modell uten at kostnadskurven bryter. AI‑arbeidsbelastninger genererer telemetri i et volum som tradisjonell prisfastsettelse per måling eller per vert aldri var laget for. Teamene slutter enten å samle inn dataene de trenger, eller så vokser observabilitetsregningen raskere enn AI‑investeringen den skal overvåke. Ingeniørteam vil forvente at plattformer håndterer dette volumet på samme måte som de forventer at enhver infrastruktur skalerer, uten å måtte omstrukturere eller reforhandle hver gang arbeidsbelastningen vokser.

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke VictoriaMetrics.