Dzmitry Lazerka, medgrundare av VictoriaMetrics – Intervjuserie

Dzmitry Lazerka, medgrundare av VictoriaMetrics är en erfaren mjukvaruingenjör och teknikledare med djup expertis inom maskininlärning, storskaliga datasystem, observabilitet och infrastruktur. Innan han medgrundade VictoriaMetrics år 2018 arbetade han som maskininlärningsingenjör i Lyfts Level 5‑avdelning för autonoma fordon, där han hjälpte till att utveckla system för att känna igen och analysera verkliga körsituationer. Tidigare ledde han maskininlärnings‑ och datainfrastrukturprojekt på Spire Global, var medgrundare av engineering‑teamet på Bellgram och arbetade med data‑ och analystsystem på Duetto Research och Google via EPAM Systems. Under sin karriär har Lazerka byggt och lett projekt som spänner över autonom körning, maritim prognostisering, sökning, analys, distribuerad databehandling och mycket skalbara backend‑system.

VictoriaMetrics är ett open‑source‑observabilitetsföretag som bygger verktyg för insamling, lagring, frågning och analys av stora volymer operativ data. Dess teknik började med VictoriaMetrics, en högpresterande tidsseriedatabas och övervakningslösning designad för skalbarhet, snabba frågor, effektiv lagring och låg driftskostnad, och har sedan dess expanderat till en bredare observabilitetsstack som täcker metrik, loggar och distribuerade spår via VictoriaMetrics, VictoriaLogs och VictoriaTraces. Företaget erbjuder också företags‑ och helt hanterade molldeploymenter, samt avvikelserkenningsfunktioner som tillämpar maskininlärning på tidsseriedata. Plattformen stödjer teknologier inklusive OpenTelemetry, Prometheus‑kompatibla arbetsflöden, Grafana och Kubernetes, vilket ger organisationer flexibilitet att integrera VictoriaMetrics i befintliga observabilitetsmiljöer.

Innan du medgrundade VictoriaMetrics arbetade du med storskalig data, analys och maskininlärningssystem på Google, Spire Global, Lyfts avdelning för autonoma fordon och andra startups. Vad ledde dig i slutändan till att grunda VictoriaMetrics, och vilka problem från de tidigare rollerna övertygade dig om att övervakning och observabilitet behövde ett fundamentalt annorlunda tillvägagångssätt?

Jag har tillbringat min karriär med att arbeta med stora mängder data. På Google, Spire, Lyft och andra företag lär man sig snabbt att något som fungerar bra i en skala kan bli dyrt eller svårt att driva i en annan skala. Övervakning har exakt detta problem.

När infrastrukturen växer skapar du fler metrik. Du lägger till fler tjänster, fler instanser och fler etiketter tills plötsligt övervakningssystemet självt kräver en betydande mängd infrastruktur, vilket aldrig har känts logiskt för oss. Ett system som är designat för att övervaka din produktionsmiljö bör inte bli mer komplicerat och dyrt att driva.

Det var detta mina medgrundare Aliaksandr Valialkin och Roman Khavronenko såg direkt. De hade erfarenhet av att driva Prometheus och stötte på minnesbegränsningar. Att lägga till system som Thanos löste vissa skalningsproblem, men introducerade också fler komponenter och mer operativ komplexitet. Och med InfluxDB såg vi hur en licensändring kunde påverka ingenjörsbeslut efter att team redan investerat i tekniken.

Så idén bakom VictoriaMetrics var praktisk: Kan vi bygga en tidsseriedatabas som utför samma arbete med avsevärt färre resurser och som är enklare att driva?

Vi började inte med en plan att bygga ett stort observabilitetsföretag. Vi började med att lösa ett ingenjörsproblem.

Att göra det open‑source var en del av det. Ingenjörer kunde ladda ner VictoriaMetrics, köra riktiga produktionsarbetsbelastningar mot det och själva jämföra resultaten. Vi behövde inte säga åt dem att det var snabbare eller mer effektivt. De kunde mäta det.

Det är det bästa sättet att bygga infrastrukturprogramvara. Om teknologin är bra bör ingenjörer kunna bevisa det själva.

Observabilitetskostnader kan tyst bli en betydande del av ett företags molnbill. Var blir dessa kostnader vanligtvis okontrollerade, och vilka arkitektur‑ eller inköpsbeslut gör ingenjörsteam oftast fel på?

Jag skulle först titta på kardinalitet.

Låt oss säga att du börjar med en rimlig metrik och sedan lägger till en etikett med möjliga värden. Plötsligt blir en metrik tusentals eller miljontals unika tidsserier. Systemet har nu mer data att ta emot, indexera, lagra och fråga, vilket resulterar i mer CPU, minne och lagring.

Det svåra är att detta inte sker på grund av ett enda dåligt beslut. Det händer gradvis. Lägg till fler tjänster, K8s‑pods, kunder och etiketter, så multipliceras kostnaden.

Det andra problemet är att lagra allt med samma upplösning under samma tidsperiod. Inte all observabilitetsdata har samma värde. De metrik du behöver för en varning eller ett SLO skiljer sig från högvolymdiagnostisk telemetri som du kanske bara tittar på en gång under en incident.

Om du behandlar all den datan lika hamnar du med att betala premium‑infrastruktur‑ eller SaaS‑priser för data som inte kräver det.

Det är därför vissa företag ser på observabilitet som ett inköpsproblem och frågar vilken plattform som är enklast att distribuera idag. Jag ställer frågor som: ”Vad händer när mängden telemetri ökar tio‑faldigt? Vad händer med kardinaliteten? Vad lagrar vi? Hur länge? Och vad händer med kostnaden?”

Det finns ingenjörslösningar på dessa problem. Till exempel kan du med strömmande aggregering samla in metrik innan de når lagring istället för att lagra varje rå tidsserie och aggregera den senare. Du kan separera högkardinalitetsarbetsbelastningar från affärskritisk övervakning. Du kan också använda olika retention‑ och upplösningspolicyer beroende på datans värde.

Målet är inte att samla in så lite telemetri som möjligt. Du behöver tillräckligt med information för att förstå vad dina system gör.

Målet är att undvika att spendera resurser på att samla in, bearbeta och lagra data på ett sätt som inte ger dig extra värde.

Observabilitet är ett ingenjörssystem. Dess kostnad bör också ingenjöras.

Grammarly har sagt att deras proof‑of‑concept med VictoriaMetrics ledde till en tio‑faldigt lägre AWS‑räkning. När företag uppnår besparingar i den skalan, vad förändras egentligen under huven: datakomprimering, beräkningskrav, lagringsarkitektur, operativ komplexitet, eller någon kombination av dessa faktorer?

Det är en kombination, men komprimeringen och resursavtrycket gör det mesta av jobbet. VictoriaMetrics använder skräddarsydd komprimering för tidsseriedata, så samma metrik upptar en bråkdel av det diskutrymme de skulle i en allmän databas. Dessutom kör vi fyra till fem gånger mindre på RAM än Prometheus vid motsvarande insamlingshastigheter, och upp till tio gånger mindre på disk. När Grammarly körde sitt proof‑of‑concept visade det sig direkt i deras AWS‑räkning, eftersom de inte bara lagrade mindre data; de körde färre och mindre instanser för att göra det.

Den operativa komplexitetsdelen spelar också roll, men den är mer indirekt. Många team som beräknar observabilitetskostnader tittar bara på lagrings‑ och beräkningsposterna och missar de ingenjörstimmar som läggs på att driva en fem‑komponents Thanos‑stack jämfört med en enda binär. Det är riktiga pengar; det är bara svårare att sätta ett tal på.

Prometheus har blivit grundläggande för molnnativ övervakning, men vissa organisationer stöter så småningom på skalnings‑ eller operativa begränsningar. Vad får vanligtvis ett företag att börja se bortom en konventionell Prometheus‑deployment, och när blir VictoriaMetrics ett logiskt alternativ?

Prometheus är utmärkt på det det byggdes för: en enskild nod för insamling och larmmotor. Team stöter vanligtvis på två typer av hinder: Antingen växer deras kardinalitet förbi vad en enda Prometheus‑instans kan hålla i minnet, eller så behöver de långsiktig lagring och globala frågor över flera kluster, vilket Prometheus aldrig var designat för att göra på egen hand. Det är då man lägger till Thanos eller Cortex, vilket vanligtvis är där den operativa smärtan börjar. Man går från att köra en binär till att driva ett distribuerat system med en komprimerare, en frågemotor, en lagringsgateway och mycket mer som kan gå sönder klockan 03.00.

VictoriaMetrics blir det logiska nästa steget eftersom det är en drop‑in‑ersättning, inte en omarknadsföring. Team pekar sin befintliga Prometheus‑insamlingskonfiguration mot VictoriaMetrics och behåller alla Grafana‑instrumentpaneler, larm och inspelningsregler de redan har byggt. Migreringen är en konfigurationsändring, inte ett projekt, och de får skalan utan att behöva lägga till fem nya komponenter att driva.

Vi ser att ingenjörsteam omprövar huruvida de behöver stora, helt hanterade observabilitetsplattformar eller om de kan bygga mer effektiva stackar av öppen‑källakod. Ser du detta som ett bredare strukturellt skifte på observabilitetsmarknaden, och hur mycket press lägger öppen källkod på traditionella prismodeller?

Det är strukturellt; inte en tillfällig reaktion på ett dåligt budgetår. Observabilitetsleverantörer har historiskt prissatt antingen efter insamlingsvolym eller antalet värdar, och den modellen fungerar emot kunden när deras verksamhet växer. Ju mer framgångsrikt ett företag blir, desto mer betalar de, och prissättningen har ingen verklig koppling till det levererade värdet. Ingenjörsteam har börjat göra beräkningarna själva och insett att en självhostad, effektiv open‑source‑stack förändrar hela ekvationen. Detta beror på att kostnaden skalar med den infrastruktur som faktiskt körs snarare än med en mätformel som en leverantör kontrollerar.

Detta lägger verklig press på befintliga prismodeller. När ett team kan peka sin befintliga insamlingskonfiguration mot ett open‑source‑alternativ och minska fakturan med 60 till 80 % utan att förlora funktionalitet, är det inte ett svårt samtal att föra internt. Leverantörerna som fortfarande tar betalt per värd eller anpassad metrik kommer fortsätta tömma kunder som inte gör dessa beräkningar.

AI‑infrastruktur introducerar en ovanligt dyr ny resurs i ekvationen: GPU:er. Vad bör företag som kör AI‑träning eller inferens övervaka utöver grundläggande GPU‑användning, och var kan bättre observabilitet direkt översättas till lägre AI‑infrastrukturkostnader?

GPU‑användning ensam berättar inte tillräckligt.

Du kan se 90 % användning på en instrumentpanel och anta att allt är bra. Men det du egentligen vill veta är: Vad gör GPU:n?

Du måste gräva djupare. Vilka CUDA‑kärnor körs? Hur allokeras GPU‑minnet? Hur mycket tid spenderas på att flytta minne istället för att utföra beräkningar? Använder arbetsbelastningen Tensor‑Kärnor när den bör? Är GPU:n faktiskt flaskhalsen, eller väntar den på data från någon annanstans?

Detta är viktiga frågor eftersom GPU:er är dyra. En liten ineffektivitet som upprepas över hundratals eller tusentals GPU:er blir en mycket stor summa pengar.

Till exempel, om GPU:er väntar för att datapipelinen inte kan mata dem tillräckligt snabbt, kommer inköp av fler GPU:er inte lösa problemet. Du måste hitta flaskhalsen. Detsamma gäller minnet. Om arbetsbelastningar allokerar minne ineffektivt kan bättre insyn hjälpa ingenjörer att justera batch‑storlekar eller köra fler arbetsbelastningar på samma hårdvara.

Det är här observabilitet blir intressant för AI‑infrastruktur. Det handlar inte bara om att upptäcka att något är trasigt. Det kan visa var du slösar beräkningskraft.

Det finns också ett observabilitetsproblem som skapas av all denna övervakning. GPU:er kan generera mycket detaljerad, hög‑kardinalitets‑telemetri. Om du samlar in allt och skickar det direkt till en dyr SaaS‑plattform kan du minska dina GPU‑kostnader och sedan spendera en del av besparingen på att lagra övervakningsdata. Men det är ingen bra optimering.

Med OpenTelemetry och projekt som OpenLIT kan vi få mycket djupare insyn i GPU‑arbetsbelastningar. Sedan, med VictoriaMetrics, kan vi aggregera data, ta bort dimensioner som inte är användbara och effektivt behålla den information som ingenjörer faktiskt behöver.

Den användbara frågan är inte, “Hur utnyttjade är mina GPU:er?”

Den är, “Vilket användbart arbete får jag ut av de GPU:er jag betalar för?”

När du kan svara på det kan du börja fatta bättre ingenjörs‑ och kostnadsbeslut.

AI‑agenter skapar mycket olika observabilitetsutmaningar jämfört med traditionell mjukvara eftersom en enda förfrågan kan trigga modell‑anrop, verktygsanvändning, vektordatabas‑frågor, överlämningar och potentiellt långa kedjor av autonoma handlingar. Hur måste observabiliteten utvecklas när företagsapplikationer blir alltmer agentdrivna?

Traditionell observabilitet antar att en förfrågan följer en ganska förutsägbar väg genom din infrastruktur. Agentdrivna arbetsbelastningar fungerar inte så. En enda agent kan anropa en modell, sedan ett verktyg, sedan en annan modell och försöka tre gånger innan den returnerar något. Varje steg kräver sin egen insyn.

Felmoderna är också annorlunda. En traditionell tjänst svarar antingen korrekt eller så svarar den inte. En agent kan svara framgångsrikt och ändå vara felaktig, långsam eller dyr, och inget av detta visas som ett typiskt fel i en instrumentpanel byggd för drifttid.

Det som överraskar team är kardinaliteten. Ett enskilt agent‑arbetsflöde kan generera metrik kopplad till en specifik användare, prompt och verktygsanrop, och den volymen växer snabbt, särskilt med rekursiva slingor där en planerare fortsätter anropa samma verktyg. Alla system som ska observera agentdrivna arbetsbelastningar måste hantera den skalan utan att kostnadskurvan blir vertikal, vilket är exakt det problem vi löser. Metrik, loggar och spår är fortfarande rätt byggstenar. Vad som måste förändras är volymen och kostnadsmodellen under dem.

VictoriaMetrics har också börjat använda maskininlärning och AI‑assisterade arbetsflöden för avvikelsedetektion. Var tror du AI kan förbättra övervakning och incidentrespons idag, och var är mänskligt omdöme fortfarande svårt att ersätta?

Det är viktigt att hålla en person i slingan för att generera idéer, styra implementeringen och validera resultaten. Med andra ord har egentligen inget förändrats jämfört med det traditionella arbetsflödet. Det som har förändrats är att möjligheterna att generera lösningar har förstärkts. Alla kan skapa mjukvara nu, men det bör inte sänka acceptanskriterierna. Det bör snarare höja dem avsevärt.

Där AI verkligen hjälper är att lyfta fram vad en person annars skulle missa i bruset, saker som avvikelser och trender som inte triggar en manuell tröskel. På VictoriaMetrics har vi en enkel intern AI‑policy: Anställda får automatisera sina arbetsflöden hur de vill, men de förblir ansvariga för slutresultatet. Det är ungefär samma standard vi skulle tillämpa på avvikelsedetektion i en kunds produktionsmiljö. Modellen kan flagga det, men en person måste fortfarande avgöra vad det betyder och vad som ska göras åt det.

VictoriaMetrics har förblivit öppen källkod och har tagit en självfinansierad, kundfinansierad strategi snarare än att följa den traditionella riskkapitalfinansierade infrastruktur‑startup‑modellen. Hur har det påverkat hur du bygger produkten, prissätter den och beslutar vilka teknologier som förblir öppen källkod?

Att vara självfinansierad förändrar incitamentsstrukturen mer än vad folk förväntar sig. Utan någon styrelse som kräver att vi når ett ARR‑mål under ett specifikt kvartal har vi inte behövt göra de avvägningar som vanligtvis följer med den pressen, som att försvaga open‑source‑versionen för att tvinga folk till en betald nivå, eller ändra licensen som InfluxDB eller HashiCorp gjorde när de behövde skydda intäkter från molnleverantörer. VictoriaMetrics OSS är Apache 2.0 idag, och vi har inga planer på att ändra det.

Sättet vi beslutar vad som förblir öppen källkod är enkelt: Kärnmotorn, den sak ingenjörer måste lita på med sin produktionsdata, förblir öppen. Vi tar betalt för det ett företag behöver när det kör i skala och behöver någon ansvarig: flertjänst, företagsautentisering, efterlevnadsstöd, en CVE‑SLA och direkt åtkomst till ingenjörerna som skrev koden istället för en supportkö. Att vara kundfinansierat innebär också att färdplanen sätts av vad folk faktiskt stöter på i produktion, inte av vad som är finansierbart i en pitch‑deck.

När metrik, loggar, spår, AI‑applikationstelemetri, GPU‑övervakning och automatiserad avvikelsedetektion i allt högre grad konvergerar, hur tror du att observabilitetsstacken kommer att se ut under de kommande åren, och vad kommer ingenjörsteam förvänta sig av plattformar som vill förbli relevanta?

Stacken konvergerar operativt innan den konvergerar till en enda produkt, och den distinktionen är viktig. De flesta team vill inte ha en monolitisk plattform med ett enda UI som låser ihop allt. Vad de vill ha är metrik, loggar och spår som körs på en gemensam operativ modell, en leverantör och en licensberättelse, utan att behöva ge upp möjligheten att köra varje signal oberoende om det är vad ett givet team behöver. Det är den riktning VictoriaMetrics bygger mot. Vi försöker inte bulta in allt i en enda binär. Vi försöker säkerställa att de tre signalerna delar samma motor och samma effektivitetsegenskaper, så att tillägg av en andra eller tredje signal inte innebär att man måste anta en andra eller tredje operativ huvudvärk.

De plattformar som förblir relevanta är de som kan absorbera AI‑telemetri och GPU‑övervakning i samma modell utan att kostnadskurvan bryts. AI‑arbetsbelastningar genererar telemetri i en volym som äldre per‑metrik‑ eller per‑host‑prissättning aldrig var byggd för. Team antingen slutar samla in den data de behöver eller så växer deras observabilitetskostnad snabbare än AI‑investeringen den ska övervaka. Ingenjörsteam kommer att förvänta sig att plattformar hanterar den volymen på samma sätt som de förväntar sig att någon infrastruktur ska skala, utan att behöva omarkitektera eller omförhandla varje gång arbetsbelastningen växer.

Tack för den fantastiska intervjun, läsare som vill lära sig mer bör besöka VictoriaMetrics.