Dzmitry Lazerka, mede-oprichter van VictoriaMetrics – Interviewserie

Dzmitry Lazerka, mede-oprichter van VictoriaMetrics is een ervaren software‑engineer en technologieleider met diepgaande expertise in machine learning, grootschalige datasystemen, observability en infrastructuur. Voor hij VictoriaMetrics mede-oprichtte in 2018, werkte hij als Machine Learning Engineer bij Lyft’s Level 5 autonome voertuigafdeling, waar hij hielp bij het ontwikkelen van systemen voor het herkennen en analyseren van real‑world rijscenario’s. Eerder leidde hij machine‑learning‑ en data‑infrastructuurprojecten bij Spire Global, was hij mede‑oprichter van Bellgram, en werkte hij aan data‑ en analysesystemen bij Duetto Research en Google via EPAM Systems. Gedurende zijn loopbaan heeft Lazerka projecten gebouwd en geleid die variëren van autonoom rijden, maritieme voorspelling, zoeken, analytics, gedistribueerde gegevensverwerking tot zeer schaalbare backend‑systemen.

VictoriaMetrics is een open‑source observability‑bedrijf dat tools bouwt voor het verzamelen, opslaan, bevragen en analyseren van grote hoeveelheden operationele data. De technologie begon met VictoriaMetrics, een high‑performance time‑series database en monitoring‑oplossing ontworpen voor schaalbaarheid, snelle queries, efficiënte opslag en lage operationele overhead, en is sindsdien uitgegroeid tot een bredere observability‑stack die metrics, logs en gedistribueerde traces dekt via VictoriaMetrics, VictoriaLogs en VictoriaTraces. Het bedrijf biedt ook enterprise‑ en volledig beheerde cloud‑implementaties, naast anomaliedetectie‑mogelijkheden die machine learning toepassen op time‑series data. Het platform ondersteunt technologieën waaronder OpenTelemetry, Prometheus‑compatibele workflows, Grafana en Kubernetes, waardoor organisaties flexibiliteit krijgen om VictoriaMetrics te integreren in bestaande observability‑omgevingen.

Voordat je VictoriaMetrics mede-oprichtte, werkte je aan grootschalige data‑, analytics‑ en machine‑learning‑systemen bij Google, Spire Global, Lyft’s autonome voertuigafdeling en andere startups. Wat heeft je uiteindelijk ertoe gebracht VictoriaMetrics op te richten, en welke problemen uit die eerdere functies overtuigden je ervan dat monitoring en observability een fundamenteel andere aanpak nodig hadden?

Ik heb mijn carrière besteed aan het werken met grote hoeveelheden data. Bij Google, Spire, Lyft en andere bedrijven leer je snel dat iets dat goed werkt op één schaal, duur of moeilijk te exploiteren kan worden op een andere schaal. Monitoring heeft precies dit probleem.

Naarmate de infrastructuur groeit, creëer je meer metrics. Je voegt meer services, meer instanties en meer labels toe totdat plots het monitoringsysteem zelf een aanzienlijke hoeveelheid infrastructuur nodig heeft, wat voor ons nooit logisch was. Een systeem dat is ontworpen om je productie‑omgeving te monitoren mag niet ingewikkelder en duurder worden om te exploiteren.

Dit is wat mijn mede‑oprichters Aliaksandr Valialkin en Roman Khavronenko direct zagen. Zij hadden ervaring met het exploiteren van Prometheus en liepen tegen geheugenlimieten aan. Het toevoegen van systemen zoals Thanos loste bepaalde schaalbaarheidsproblemen op, maar introduceerde ook meer componenten en meer operationele complexiteit. En met InfluxDB zagen we hoe een licentie‑wijziging engineering‑beslissingen kon beïnvloeden nadat teams al in de technologie hadden geïnvesteerd.

Het idee achter VictoriaMetrics was dus praktisch: Kunnen we een time‑series database bouwen die hetzelfde werk doet met aanzienlijk minder middelen en eenvoudiger te exploiteren is?

We begonnen niet met een plan om een groot observability‑bedrijf op te bouwen. We begonnen met het oplossen van een technisch probleem.

Het open‑source maken maakte daar deel van uit. Engineers konden VictoriaMetrics downloaden, er echte productie‑workloads op draaien en zelf de resultaten vergelijken. We hoefden hen niet te vertellen dat het sneller of efficiënter was. Ze konden het zelf meten.

Dit is de beste manier om infrastructuursoftware te bouwen. Als de technologie goed is, moeten engineers het zelf kunnen bewijzen.

Observability‑kosten kunnen stilletjes een aanzienlijk deel van de cloud‑rekening van een bedrijf worden. Waar lopen die kosten meestal uit de hand, en welke architecturale of aankoopbeslissingen maken engineering‑teams het vaakst verkeerd?

Ik zou eerst naar cardinaliteit kijken.

Stel dat je begint met een redelijk metric, en vervolgens een label met mogelijke waarden toevoegt. Plots wordt één metric duizenden of miljoenen unieke time‑series. Het systeem moet nu meer data ingesteren, indexeren, opslaan en bevragen, wat leidt tot meer CPU, geheugen en opslag.

Het moeilijke is dat dit niet gebeurt omdat iemand één slechte beslissing heeft genomen. Het gebeurt geleidelijk. Voeg meer services, K8s‑pods, klanten en labels toe, en de kosten vermenigvuldigen zich.

Het tweede probleem is alles opslaan met dezelfde resolutie gedurende dezelfde tijdsduur. Niet alle observability‑data heeft dezelfde waarde. De metrics die je nodig hebt voor een alert of een SLO verschillen van de high‑volume diagnostische telemetry die je mogelijk één keer tijdens een incident bekijkt.

Als je al die data op dezelfde manier behandelt, betaal je premium infrastructuur‑ of SaaS‑prijzen voor data die dat niet nodig heeft.

Daarom benaderen sommige bedrijven observability als een aankoopprobleem, en vragen ze welk platform vandaag het makkelijkst te implementeren is. Ik stel vragen als: “Wat gebeurt er als de hoeveelheid telemetry met 10× toeneemt? Wat gebeurt er met de cardinaliteit? Wat slaan we op? Hoe lang? En wat gebeurt er met de kosten?”

Er zijn technische oplossingen voor deze problemen. Bijvoorbeeld, met streaming‑aggregatie kun je metrics aggregeren voordat ze de opslag bereiken in plaats van elke ruwe time‑series op te slaan en later te aggregeren. Je kunt high‑cardinality workloads scheiden van business‑kritische monitoring. Je kunt ook verschillende retentie‑ en resolutie‑policies gebruiken afhankelijk van de waarde van de data.

Het doel is niet om zo weinig mogelijk telemetry te verzamelen. Je hebt voldoende informatie nodig om te begrijpen wat je systemen doen.

Het doel is om te voorkomen dat je middelen besteedt aan het verzamelen, verwerken en opslaan van data op een manier die geen extra waarde oplevert.

Observability is een technisch systeem. De kosten ervan moeten ook technisch worden geoptimaliseerd.

Grammarly heeft gezegd dat hun proof‑of‑concept met VictoriaMetrics heeft geleid tot een 10× lagere AWS‑rekening. Wanneer bedrijven besparingen op die schaal realiseren, wat verandert er dan onder de motorkap: datacompressie, compute‑vereisten, opslagarchitectuur, operationele complexiteit, of een combinatie van deze factoren?

Het is een combinatie, maar compressie en de resource‑voetafdruk doen het grootste deel van het werk. VictoriaMetrics gebruikt speciaal gebouwde compressie voor time‑series data, waardoor dezelfde metrics slechts een fractie van de schijfruimte innemen die ze in een algemene database zouden innemen. Bovendien gebruiken we vier tot vijf keer minder RAM dan Prometheus bij gelijkwaardige ingest‑snelheden, en tot tien keer minder schijfruimte. Toen Grammarly hun proof‑of‑concept uitvoerde, kwam dat direct terug in hun AWS‑rekening, omdat ze niet alleen minder data opsloegen; ze draaiden ook minder en kleinere instances om het te doen.

Het aspect van operationele complexiteit is ook belangrijk, maar het is meer indirect. Veel teams die observability‑kosten berekenen, kijken alleen naar de opslag‑ en compute‑posten en missen de engineering‑uren die besteed worden aan het exploiteren van een vijf‑componenten Thanos‑stack versus een enkele binary. Dat is echt geld; het is alleen moeilijker om er een cijfer aan te hangen.

Prometheus is een fundamenteel onderdeel geworden van cloud‑native monitoring, maar sommige organisaties lopen uiteindelijk tegen schaalbaarheids‑ of operationele beperkingen aan. Wat zorgt er doorgaans voor dat een bedrijf begint te kijken voorbij een conventionele Prometheus‑implementatie, en wanneer wordt VictoriaMetrics een logische alternatief?

Prometheus is uitstekend in wat het is gebouwd om te doen: een enkele‑node scrape‑ en alarmengine. Teams lopen meestal tegen twee muren aan: ofwel groeit hun cardinaliteit voorbij wat een enkele Prometheus‑instantie in het geheugen kan houden, ofwel hebben ze langdurige retentie en globale query’s over meerdere clusters nodig, waarvoor Prometheus nooit is ontworpen. Dat is het moment waarop men Thanos of Cortex toevoegt, en waar de operationele pijn meestal begint. Je gaat van het draaien van één binary naar het draaien van een gedistribueerd systeem met een compactor, een querier, een store‑gateway en nog veel meer dat om 3 uur ’s ochtends kan falen.

VictoriaMetrics wordt de logische volgende stap omdat het een drop‑in vervanging is, geen herarchitectuur. Teams wijzen hun bestaande Prometheus‑scrape‑configuratie naar VictoriaMetrics en behouden elke Grafana‑dashboard, elk alarm en elke opname‑regel die ze al hebben gebouwd. De migratie is een configuratiewijziging, geen project, en ze krijgen de schaalbaarheid zonder vijf nieuwe componenten toe te voegen die beheerd moeten worden.

We zien engineering‑teams heroverwegen of ze grote, volledig beheerde observability‑platforms nodig hebben of dat ze efficiëntere stacks kunnen bouwen uit open‑source componenten. Zie je dit als een bredere structurele verschuiving in de observability‑markt, en hoeveel druk legt open source op traditionele prijsmodellen?

Het is structureel; geen tijdelijke reactie op een slecht budgetjaar. Observability‑leveranciers hebben historisch gezien geprijsd op basis van ingest‑volume of host‑aantal, en dat model werkt tegen de klant naarmate hun bedrijf groeit. Hoe succesvoller een bedrijf wordt, hoe meer het betaalt, en de prijs heeft geen echte relatie tot de geleverde waarde. Engineering‑teams zijn zelf de berekeningen gaan maken en realiseren dat een zelf‑gehoste, efficiënte open‑source stack die vergelijking volledig verandert. Dit komt doordat de kosten schalen met de infrastructuur die daadwerkelijk wordt uitgevoerd in plaats van met een meterformule die een leverancier controleert.

Dit legt echte druk op de bestaande prijsstelling. Wanneer een team hun bestaande scrape‑configuratie kan wijzen naar een open‑source alternatief en de rekening met 60 tot 80 % kan verlagen zonder functionaliteit te verliezen, is dat geen moeilijke discussie om intern te voeren. De leveranciers die nog steeds per host of per aangepaste metric rekenen, zullen de klanten die deze berekening niet maken blijven uitbluten.

AI‑infrastructuur introduceert een ongewoon dure nieuwe resource in de vergelijking: GPU’s. Wat moeten bedrijven die AI‑training of -inference uitvoeren monitoren naast basis‑GPU‑gebruik, en waar kan betere observability direct vertalen naar lagere AI‑infrastructuurkosten?

GPU‑gebruik alleen vertelt je niet genoeg.

Je kunt 90 % gebruik zien op een dashboard en aannemen dat alles in orde is. Maar wat je echt wilt weten is: wat doet de GPU?

Je moet dieper kijken. Welke CUDA‑kernels draaien? Hoe wordt GPU‑geheugen toegewezen? Hoeveel tijd wordt besteed aan het verplaatsen van geheugen in plaats van aan berekeningen? Gebruikt de workload Tensor‑Cores wanneer dat nodig is? Is de GPU daadwerkelijk de bottleneck, of wacht hij op data van ergens anders?

Dit zijn belangrijke vragen omdat GPU’s duur zijn. Een kleine inefficiëntie die zich herhaalt over honderden of duizenden GPU’s wordt een zeer groot geldbedrag.

Bijvoorbeeld, als GPU’s wachten omdat de datapijplijn ze niet snel genoeg kan voeden, lost het kopen van meer GPU’s het probleem niet op. Je moet de bottleneck vinden. Hetzelfde geldt voor geheugen. Als workloads geheugen inefficiënt toewijzen, kan betere zichtbaarheid engineers helpen batch‑groottes aan te passen of meer workloads op dezelfde hardware te draaien.

Dit is waar observability interessant wordt voor AI‑infrastructuur. Het gaat niet alleen om het detecteren dat er iets kapot is. Het kan je vertellen waar je compute verspilt.

Er is ook een observability‑probleem ontstaan door al die monitoring. GPU’s kunnen veel gedetailleerde, high‑cardinality telemetrie genereren. Als je alles verzamelt en direct naar een dure SaaS‑platform stuurt, kun je je GPU‑kosten verlagen en vervolgens een deel van de besparing besteden aan het opslaan van monitoring‑data. Maar dat is geen goede optimalisatie.

Met OpenTelemetry en projecten zoals OpenLIT kunnen we veel diepere zichtbaarheid krijgen in GPU‑workloads. Vervolgens kunnen we met VictoriaMetrics de data aggregeren, dimensies die niet nuttig zijn verwijderen en efficiënt de informatie behouden die engineers daadwerkelijk nodig hebben.

De nuttige vraag is niet: “Hoe benut zijn mijn GPU’s?”

Het is: “Welk nuttig werk haal ik uit de GPU’s waarvoor ik betaal?”

Zodra je dat kunt beantwoorden, kun je betere engineering‑ en kostbeslissingen nemen.

AI‑agenten creëren heel andere observability‑uitdagingen dan traditionele software, omdat een enkel verzoek model‑calls, tool‑gebruik, vector‑database‑queries, overdrachten en mogelijk lange ketens van autonome acties kan triggeren. Hoe moet observability evolueren nu enterprise‑applicaties steeds meer agent‑achtig worden?

Traditionele observability gaat ervan uit dat een verzoek een redelijk voorspelbaar pad door je infrastructuur volgt. Agent‑achtige workloads werken niet op die manier. Een enkele agent kan een model aanroepen, dan een tool, dan weer een model en drie keer opnieuw proberen voordat er iets wordt geretourneerd. Elk van die stappen heeft zijn eigen zichtbaarheid nodig.

De faalmodi zijn ook anders. Een traditionele service reageert correct of niet. Een agent kan succesvol reageren en toch fout, traag of duur zijn, en dat verschijnt niet als een typische fout in een dashboard dat is gebouwd voor uptime.

Het deel dat teams verrast, is cardinaliteit. Een enkele agent‑workflow kan metrics genereren die gekoppeld zijn aan een specifieke gebruiker, prompt en tool‑call, en dat volume groeit snel, vooral bij recursieve lussen waarin een planner dezelfde tool steeds opnieuw aanroept. Elk systeem dat agent‑achtige workloads moet observeren, moet die schaal aankunnen zonder dat de kostencurve verticaal oploopt, wat precies het probleem is dat wij oplossen. Metrics, logs en traces blijven de juiste bouwblokken. Wat moet veranderen is het volume en het kostenmodel eronder.

VictoriaMetrics past ook machine learning en AI‑ondersteunde workflows toe op anomaliedetectie. Waar denk je dat AI vandaag echt monitoring en incident‑respons kan verbeteren, en waar is menselijk oordeel nog moeilijk te vervangen?

Het is belangrijk om een persoon in de lus te houden voor het genereren van ideeën, het sturen van de implementatie en het valideren van de resultaten. Met andere woorden, er is niets wezenlijks veranderd ten opzichte van de traditionele workflow. Wat wel is veranderd, is dat de mogelijkheden om oplossingen te genereren zijn vergroot. Iedereen kan nu software maken, maar dat mag de acceptatiecriteria niet verlagen. Het moet ze juist aanzienlijk verhogen.

Waar AI echt helpt, is het naar voren brengen van wat een persoon anders zou missen in de ruis, zoals uitschieters en trends die geen handmatige drempel activeren. Bij VictoriaMetrics hebben we een eenvoudig intern AI‑beleid: medewerkers mogen hun workflow automatiseren zoals ze willen, maar blijven verantwoordelijk voor het eindresultaat. Dat is ongeveer dezelfde standaard die we zouden hanteren voor anomaliedetectie in de productieomgeving van een klant. Het model kan een anomalie markeren, maar een persoon moet nog steeds bepalen wat het betekent en wat er mee gedaan moet worden.

VictoriaMetrics is open source gebleven en heeft een zelf‑gefinancierde, klant‑gefinancierde aanpak gekozen in plaats van het traditionele venture‑backed infrastructuur‑startupmodel. Hoe heeft dat de manier beïnvloed waarop je het product bouwt, prijst en beslist welke technologieën open source blijven?

Zelf‑financiering verandert de prikkelstructuur meer dan mensen verwachten. Zonder een raad die ons dwingt een ARR‑cijfer te halen in een bepaald kwartaal, hebben we de afwegingen die normaal met die druk gepaard gaan, niet hoeven maken, zoals het verzwakken van de open‑source versie om mensen naar een betaalde tier te dwingen, of het wijzigen van de licentie zoals InfluxDB of HashiCorp deden toen ze hun inkomsten moesten beschermen tegen cloud‑providers. VictoriaMetrics OSS is vandaag Apache 2.0 en we hebben geen plannen om dat te veranderen.

De manier waarop we bepalen wat open source blijft, is simpel: de kernengine, het onderdeel dat engineers moeten kunnen vertrouwen met hun productiedata, blijft open. We rekenen voor wat een bedrijf nodig heeft zodra het op schaal draait en iemand verantwoordelijk moet zijn: multi‑tenancy, enterprise‑authenticatie, compliance‑ondersteuning, een CVE‑SLA en directe toegang tot de engineers die de code hebben geschreven in plaats van een support‑wachtrij. Klant‑gefinancierd zijn betekent bovendien dat de roadmap wordt bepaald door de problemen die mensen in de productie tegenkomen, en niet door wat er in een pitch‑deck gefinancierd kan worden.

Nu metrics, logs, traces, AI‑applicatietelemetrie, GPU‑monitoring en geautomatiseerde anomaliedetectie steeds meer samensmelten, hoe denk je dat de observability‑stack er over een paar jaar uit zal zien, en wat zullen engineering‑teams verwachten van platforms die relevant willen blijven?

De stack convergeert operationeel voordat hij convergeert tot één enkel product, en dat onderscheid is belangrijk. De meeste teams willen geen monolithisch platform met één UI dat alles aan elkaar vastklikt. Wat ze willen is metrics, logs en traces die draaien op één operationeel model, één leverancier en één licentie‑verhaal, zonder de mogelijkheid op te geven om elk signaal onafhankelijk te kunnen uitvoeren als een bepaald team dat nodig heeft. Dat is de richting waarin VictoriaMetrics zich ontwikkelt. We proberen niet alles in één enkele binary te proppen. We willen ervoor zorgen dat de drie signalen dezelfde engine en dezelfde efficiëntie‑kenmerken delen, zodat het toevoegen van een tweede of derde signaal niet betekent dat er een tweede of derde operationele hoofdpijndossier ontstaat.

De platforms die relevant blijven, zijn diegenen die AI‑telemetrie en GPU‑monitoring in datzelfde model kunnen opnemen zonder dat de kostencurve breekt. AI‑workloads genereren telemetrie in een volume waarvoor legacy‑per‑metric‑ of per‑host‑pricing nooit is ontworpen. Teams stoppen ofwel met het verzamelen van de benodigde data, of hun observability‑rekening groeit sneller dan de AI‑investering die ze moeten monitoren. Engineering‑teams zullen van platforms verwachten dat ze dat volume op dezelfde manier kunnen verwerken als elke andere infrastructuur die schaalt, zonder dat ze telkens moeten herarchitectureren of heronderhandelen wanneer de workload groeit.

Bedankt voor het geweldige interview, lezers die meer willen weten, kunnen terecht op VictoriaMetrics.