Dzmitry Lazerka, Co-Fondatore di VictoriaMetrics – Serie di Interviste

Dzmitry Lazerka, Co-Fondatore di VictoriaMetrics è un ingegnere del software esperto e un leader tecnologico con una profonda competenza in machine learning, sistemi di dati su larga scala, osservabilità e infrastruttura. Prima di co-fondare VictoriaMetrics nel 2018, ha lavorato come Ingegnere di Machine Learning nella divisione di veicoli autonomi Level 5 di Lyft, dove ha contribuito allo sviluppo di sistemi per il riconoscimento e l’analisi di scenari di guida del mondo reale. In precedenza, ha guidato progetti di machine learning e infrastruttura dati presso Spire Global, è stato co-fondatore ingegneristico di Bellgram e ha lavorato su sistemi di dati e analisi presso Duetto Research e Google tramite EPAM Systems. Nel corso della sua carriera, Lazerka ha costruito e guidato progetti che spaziano dalla guida autonoma, alla previsione marittima, alla ricerca, all’analisi, all’elaborazione distribuita dei dati e a backend altamente scalabili.

VictoriaMetrics è un’azienda di osservabilità open-source che crea strumenti per la raccolta, l’archiviazione, l’interrogazione e l’analisi di grandi volumi di dati operativi. La sua tecnologia è nata con VictoriaMetrics, un database a serie temporali ad alte prestazioni e una soluzione di monitoraggio progettata per la scalabilità, query rapide, archiviazione efficiente e basso overhead operativo, e si è poi ampliata in uno stack di osservabilità più ampio che copre metriche, log e tracce distribuite tramite VictoriaMetrics, VictoriaLogs e VictoriaTraces. L’azienda offre anche distribuzioni enterprise e completamente gestite in cloud, insieme a capacità di rilevamento anomalie che applicano il machine learning ai dati a serie temporali. La sua piattaforma supporta tecnologie tra cui OpenTelemetry, flussi di lavoro compatibili con Prometheus, Grafana e Kubernetes, offrendo alle organizzazioni la flessibilità di integrare VictoriaMetrics negli ambienti di osservabilità esistenti.

Prima di co-fondare VictoriaMetrics, hai lavorato su sistemi di dati su larga scala, analisi e machine learning presso Google, Spire Global, la divisione di veicoli autonomi di Lyft e altre startup. Cosa ti ha spinto infine a fondare VictoriaMetrics, e quali problemi di quegli incarichi precedenti ti hanno convinto che il monitoraggio e l’osservabilità necessitassero di un approccio fondamentalmente diverso?

Ho trascorso la mia carriera lavorando con grandi quantità di dati. In Google, Spire, Lyft e altre aziende, si impara rapidamente che qualcosa che funziona bene a una certa scala può diventare costoso o difficile da gestire a un’altra scala. Il monitoraggio ha esattamente questo problema.

Man mano che l’infrastruttura cresce, crei più metriche. Aggiungi più servizi, più istanze e più etichette finché, improvvisamente, il sistema di monitoraggio stesso richiede una quantità significativa di infrastruttura, cosa che per noi non ha mai avuto senso. Un sistema progettato per monitorare l’ambiente di produzione non dovrebbe diventare più complesso e costoso da gestire.

Questo è ciò che i miei co-fondatori Aliaksandr Valialkin e Roman Khavronenko hanno osservato direttamente. Avevano esperienza nell’uso di Prometheus e nei limiti di memoria. L’aggiunta di sistemi come Thanos risolveva alcuni problemi di scalabilità, ma introdusse anche più componenti e una maggiore complessità operativa. Inoltre, con InfluxDB, abbiamo visto come un cambiamento di licenza potesse influenzare le decisioni ingegneristiche dopo che i team avevano già investito nella tecnologia.

Quindi l’idea alla base di VictoriaMetrics era pratica: possiamo costruire un database a serie temporali che svolga lo stesso compito con risorse significativamente inferiori e sia più semplice da gestire?

Non abbiamo iniziato con l’intento di costruire una grande azienda di osservabilità. Abbiamo iniziato risolvendo un problema di ingegneria.

Renderlo open source è stato parte di questo. Gli ingegneri potevano scaricare VictoriaMetrics, eseguire carichi di lavoro di produzione reali e confrontare i risultati autonomamente. Non dovevamo dir loro che era più veloce o più efficiente. Potevano misurarlo.

Questo è il modo migliore per costruire software di infrastruttura. Se la tecnologia è buona, gli ingegneri dovrebbero essere in grado di dimostrarlo da soli.

I costi dell’osservabilità possono silenziosamente diventare una parte significativa della bolletta cloud di un’azienda. Dove tipicamente questi costi sfuggono al controllo, e quali decisioni architetturali o di acquisto le squadre di ingegneria sbagliano più spesso?

Guarderei prima alla cardinalità.

Immaginiamo di iniziare con una metrica ragionevole, poi aggiungere un’etichetta con valori possibili. Improvvisamente, una metrica diventa migliaia o milioni di serie temporali uniche. Il sistema ora ha più dati da ingerire, indicizzare, archiviare e interrogare, il che comporta un aumento di CPU, memoria e spazio di archiviazione.

La parte difficile è che ciò non avviene a causa di una singola decisione sbagliata. Accade gradualmente. Aggiungendo più servizi, pod K8s, clienti e etichette, il costo si moltiplica.

Il secondo problema è memorizzare tutto alla stessa risoluzione per lo stesso periodo di tempo. Non tutti i dati di osservabilità hanno lo stesso valore. Le metriche necessarie per un avviso o un SLO sono diverse dalla telemetria diagnostica ad alto volume che potresti consultare una sola volta durante un incidente.

Se tratti tutti quei dati allo stesso modo, finisci per pagare prezzi premium per infrastrutture o SaaS per dati che non lo richiedono.

Questo è il motivo per cui alcune aziende considerano l’osservabilità come un problema di acquisto, chiedendosi quale piattaforma sia più facile da distribuire oggi. Io pongo domande del tipo: “Cosa succede quando la quantità di telemetria aumenta di 10 volte? Cosa accade alla cardinalità? Cosa stiamo memorizzando? Per quanto tempo? E cosa succede al costo?”

Esistono soluzioni ingegneristiche a questi problemi. Per esempio, con l’aggregazione in streaming, è possibile aggregare le metriche prima che raggiungano lo storage anziché archiviare ogni serie temporale grezza e aggregarla in seguito. Si possono separare i carichi di lavoro ad alta cardinalità dal monitoraggio critico per il business. È anche possibile utilizzare diverse politiche di retention e risoluzione a seconda del valore dei dati.

L’obiettivo non è raccogliere la minima telemetria possibile. Serve avere informazioni sufficienti per capire cosa stanno facendo i tuoi sistemi.

L’obiettivo è evitare di spendere risorse per raccogliere, elaborare e archiviare dati in un modo che non fornisce valore aggiunto.

L’osservabilità è un sistema di ingegneria. Anche il suo costo dovrebbe essere progettato.

Grammarly ha affermato che il suo proof-of-concept con VictoriaMetrics si è tradotto in una fattura AWS 10 volte più bassa. Quando le aziende ottengono risparmi di tale portata, cosa cambia realmente sotto il cofano: compressione dei dati, requisiti di calcolo, architettura di storage, complessità operativa o una combinazione di questi fattori?

È una combinazione, ma la compressione e l’impronta delle risorse fanno la maggior parte del lavoro. VictoriaMetrics utilizza una compressione appositamente progettata per i dati a serie temporali, così le stesse metriche occupano una frazione dello spazio su disco rispetto a un database generico. Inoltre, consumiamo da quattro a cinque volte meno RAM rispetto a Prometheus a pari velocità di ingestione, e fino a 10 volte meno spazio su disco. Quando Grammarly ha eseguito il loro proof-of-concept, questo si è tradotto direttamente nella loro fattura AWS, perché non stavano solo archiviando meno dati; stavano eseguendo un numero minore e istanze più piccole per farlo.

La componente della complessità operativa è importante comunque, ma è più indiretta. Molte squadre che stimano i costi dell’osservabilità considerano solo le voci di storage e calcolo e trascurano le ore di ingegneria spese per gestire uno stack Thanos a cinque componenti rispetto a un unico binario. Si tratta di denaro reale; è solo più difficile quantificarlo.

Prometheus è diventato fondamentale per il monitoraggio cloud-native, ma alcune organizzazioni finiscono per incontrare limiti di scalabilità o operativi. Cosa spinge tipicamente un’azienda a cercare alternative a un’implementazione convenzionale di Prometheus, e quando VictoriaMetrics diventa un’alternativa logica?

Prometheus è eccellente in quello per cui è stato creato: un motore di raccolta e avviso a nodo singolo. I team di solito si trovano di fronte a due limiti: oppure la loro cardinalità supera ciò che un’istanza singola di Prometheus può contenere in memoria, oppure hanno bisogno di conservazione a lungo termine e query globali su più cluster, cosa per cui Prometheus non è mai stato progettato. È in quel momento che le persone aggiungono Thanos o Cortex, il che è solitamente l’inizio del dolore operativo. Si passa dall’eseguire un unico binario a gestire un sistema distribuito con un compattatore, un interrogatore, un gateway di archiviazione e molto altro che può guastarsi alle 3 del mattino.

VictoriaMetrics diventa il passo logico successivo perché è un sostituto drop‑in, non una ristrutturazione. I team indirizzano la loro configurazione di scraping Prometheus esistente verso VictoriaMetrics e mantengono tutte le dashboard Grafana, gli avvisi e le regole di registrazione già create. La migrazione è una modifica di configurazione, non un progetto, e ottengono la scalabilità senza aggiungere cinque nuovi componenti da gestire.

Stiamo vedendo i team di ingegneria riconsiderare se hanno bisogno di grandi piattaforme di osservabilità completamente gestite o se possono costruire stack più efficienti da componenti open‑source. Vedi questo come un cambiamento strutturale più ampio nel mercato dell’osservabilità, e quanto pressione sta esercitando l’open source sui modelli di prezzo tradizionali?

È strutturale; non una reazione temporanea a un anno di bilancio negativo. I fornitori di osservabilità hanno storicamente fissato i prezzi in base al volume di ingestione o al numero di host, e quel modello penalizza il cliente man mano che la sua attività cresce. Più un’azienda ha successo, più paga, e il prezzo non ha alcuna reale correlazione con il valore fornito. I team di ingegneria hanno iniziato a fare i conti da soli, rendendosi conto che uno stack open‑source auto‑ospitato ed efficiente cambia completamente quell’equazione. Questo perché il costo scala con l’infrastruttura effettivamente eseguita, anziché con una formula di misurazione controllata dal fornitore.

Ciò esercita una reale pressione sui prezzi dei fornitori esistenti. Quando un team può indirizzare la propria configurazione di scraping verso un’alternativa open‑source e ridurre la fattura del 60–80 % senza perdere funzionalità, non è una conversazione difficile da avere internamente. I fornitori che continuano a fatturare per host o metrica personalizzata continueranno a prosciugare i clienti che non effettuano questi calcoli.

L’infrastruttura AI introduce una nuova risorsa insolitamente costosa nell’equazione: le GPU. Cosa dovrebbero monitorare le aziende che eseguono addestramento o inferenza AI oltre al semplice utilizzo delle GPU, e dove una migliore osservabilità può tradursi direttamente in costi più bassi per l’infrastruttura AI?

L’utilizzo delle GPU da solo non fornisce informazioni sufficienti.

Puoi vedere il 90 % di utilizzo su una dashboard e presumere che tutto sia a posto. Ma quello che vuoi davvero sapere è: cosa sta facendo la GPU?

Devi approfondire. Quali kernel CUDA sono in esecuzione? Come viene allocata la memoria della GPU? Quanto tempo viene speso a spostare la memoria invece di eseguire calcoli? Il carico di lavoro sta usando i Tensor Core quando dovrebbe? La GPU è davvero il collo di bottiglia, o sta aspettando dati da qualche altra parte?

Queste sono domande importanti perché le GPU sono costose. Una piccola inefficienza ripetuta su centinaia o migliaia di GPU si traduce in una somma di denaro molto elevata.

Ad esempio, se le GPU sono in attesa perché la pipeline di dati non riesce a fornirle abbastanza velocemente, acquistare più GPU non risolverà il problema. Devi individuare il collo di bottiglia. Lo stesso vale per la memoria. Se i carichi di lavoro allocano la memoria in modo inefficiente, una migliore visibilità può aiutare gli ingegneri a regolare le dimensioni dei batch o a eseguire più carichi di lavoro sullo stesso hardware.

È qui che l’osservabilità diventa interessante per l’infrastruttura AI. Non riguarda solo il rilevare che qualcosa è rotto. Può indicare dove stai sprecando capacità di calcolo.

C’è anche un problema di osservabilità creato da tutto questo monitoraggio. Le GPU possono generare una grande quantità di telemetria dettagliata e ad alta cardinalità. Se raccogli tutto e lo invii direttamente a una piattaforma SaaS costosa, puoi ridurre i costi delle GPU e poi spendere parte del risparmio per archiviare i dati di monitoraggio. Ma non è un’ottimizzazione efficace.

Con OpenTelemetry e progetti come OpenLIT, possiamo ottenere una visibilità molto più profonda sui carichi di lavoro delle GPU. Poi, con VictoriaMetrics, possiamo aggregare i dati, rimuovere le dimensioni non utili e conservare in modo efficiente le informazioni di cui gli ingegneri hanno realmente bisogno.

La domanda utile non è, “Quanto sono utilizzate le mie GPU?”

È, “Quale lavoro utile sto ottenendo dalle GPU per le quali sto pagando?”

Una volta che puoi rispondere a ciò, puoi iniziare a prendere decisioni migliori in termini di ingegneria e costi.

Gli agenti AI creano sfide di osservabilità molto diverse rispetto al software tradizionale perché una singola richiesta può attivare chiamate a modelli, utilizzo di strumenti, query a database vettoriali, passaggi di mano e potenzialmente lunghe catene di azioni autonome. Come deve evolvere l’osservabilità man mano che le applicazioni aziendali diventano sempre più agentiche?

L’osservabilità tradizionale presume che una richiesta segua un percorso abbastanza prevedibile attraverso la tua infrastruttura. I carichi di lavoro agentici non funzionano così. Un singolo agente può chiamare un modello, poi uno strumento, poi un altro modello e riprovare tre volte prima di restituire qualcosa. Ognuno di questi passaggi necessita della propria visibilità.

Anche le modalità di errore sono diverse. Un servizio tradizionale risponde correttamente o no. Un agente può rispondere con successo e comunque essere errato, lento o costoso, e nulla di ciò appare come un errore tipico in una dashboard progettata per la disponibilità.

La parte che sorprende i team è la cardinalità. Un singolo flusso di lavoro di un agente può generare metriche legate a un utente specifico, a un prompt e a una chiamata di strumento, e quel volume cresce rapidamente, soprattutto con loop ricorsivi in cui un planner continua a chiamare lo stesso strumento. Qualsiasi sistema destinato a osservare carichi di lavoro agentici deve gestire tale scala senza che la curva dei costi diventi verticale, che è esattamente il problema che stiamo risolvendo. Metriche, log e trace sono ancora i blocchi costitutivi corretti. Ciò che deve cambiare è il volume e il modello di costo sottostante.

VictoriaMetrics ha anche applicato l’apprendimento automatico e i flussi di lavoro assistiti dall’AI per il rilevamento delle anomalie. Dove credi che l’AI possa migliorare realmente il monitoraggio e la risposta agli incidenti oggi, e dove il giudizio umano è ancora difficile da sostituire?

È importante mantenere una persona nel ciclo per generare idee, guidare l’implementazione e convalidare i risultati. In altre parole, nulla è realmente cambiato rispetto al flusso di lavoro tradizionale. Ciò che è cambiato è che le capacità di generare soluzioni sono amplificate. Chiunque può creare software ora, ma ciò non dovrebbe abbassare i criteri di accettazione. Dovrebbe invece aumentarli in modo significativo.

Dove l’AI aiuta davvero è nel far emergere ciò che una persona altrimenti perderebbe nel rumore, cose come outlier e tendenze che non attivano una soglia manuale. In VictoriaMetrics, abbiamo una semplice politica interna sull’AI: i dipendenti sono liberi di automatizzare il proprio flusso di lavoro come desiderano, ma rimangono responsabili del risultato finale. È sostanzialmente lo stesso standard che applichiamo al rilevamento delle anomalie nell’ambiente di produzione di un cliente. Il modello può segnalarlo, ma una persona deve ancora decidere cosa significa e cosa fare al riguardo.

VictoriaMetrics è rimasta open source e ha adottato un approccio autofinanziato e finanziato dai clienti, anziché seguire il tradizionale modello di startup infrastrutturale sostenuta da venture capital. In che modo ciò ha influenzato il modo in cui costruisci il prodotto, lo prezzi e decidi quali tecnologie rimangono open source?

Essere autofinanziati cambia la struttura degli incentivi più di quanto la gente si aspetti. Senza un consiglio che ci chieda di raggiungere un ARR entro un trimestre specifico, non abbiamo dovuto fare i compromessi che di solito accompagnano quella pressione, come compromettere la versione open source per costringere le persone a passare a un livello a pagamento, o cambiare la licenza come hanno fatto InfluxDB o HashiCorp quando hanno dovuto proteggere i ricavi dai provider cloud. VictoriaMetrics OSS è oggi Apache 2.0 e non abbiamo intenzione di cambiarla.

Il modo in cui decidiamo cosa rimane open source è semplice: il motore centrale, l’elemento di cui gli ingegneri hanno bisogno per fidarsi di noi con i loro dati di produzione, rimane aperto. Addebitiamo ciò di cui un’azienda ha bisogno una volta che opera su larga scala e necessita di qualcuno responsabile: multitenancy, autenticazione enterprise, supporto alla conformità, un SLA per le CVE e accesso diretto agli ingegneri che hanno scritto il codice invece di una coda di supporto. Essere finanziati dai clienti significa anche che la roadmap è determinata da ciò che le persone incontrano realmente in produzione, non da ciò che è finanziabile in un pitch deck.

Man mano che metriche, log, trace, telemetria delle applicazioni AI, monitoraggio GPU e rilevamento automatico delle anomalie convergono sempre più, come pensi che sarà lo stack di osservabilità nei prossimi anni e cosa si aspetteranno i team di ingegneria dalle piattaforme che vogliono rimanere rilevanti?

Lo stack converge operativamente prima di convergere in un unico prodotto, e questa distinzione è importante. La maggior parte dei team non vuole una piattaforma monolitica con un’unica interfaccia che blocchi tutto insieme. Ciò che desiderano è metriche, log e trace che funzionino su un unico modello operativo, un unico fornitore e una singola licenza, senza dover rinunciare alla possibilità di gestire ogni segnale in modo indipendente se è ciò di cui un determinato team ha bisogno. È la direzione in cui VictoriaMetrics sta costruendo. Non stiamo cercando di unire tutto in un unico binario. Vogliamo assicurarci che i tre segnali condividano lo stesso motore e le stesse caratteristiche di efficienza, così aggiungere un secondo o terzo segnale non significa introdurre un secondo o terzo problema operativo.

Le piattaforme che rimangono rilevanti sono quelle che riescono a integrare la telemetria AI e il monitoraggio GPU nello stesso modello senza che la curva dei costi si rompa. I carichi di lavoro AI generano telemetria a un volume per il quale i prezzi legacy per metrica o per host non sono mai stati progettati. I team o smettono di raccogliere i dati di cui hanno bisogno o la bolletta dell’osservabilità cresce più rapidamente dell’investimento AI che dovrebbe monitorare. I team di ingegneria si aspetteranno che le piattaforme gestiscano quel volume allo stesso modo in cui si aspettano che qualsiasi infrastruttura scala, senza doverle far riprogettare o rinegoziare ogni volta che il carico di lavoro aumenta.

Grazie per la splendida intervista, i lettori che desiderano saperne di più dovrebbero visitare VictoriaMetrics.