Dzmitry Lazerka, spoluzakladatel VictoriaMetrics – série rozhovorů

Dzmitry Lazerka, spoluzakladatel VictoriaMetrics je zkušený softwarový inženýr a technologický lídr s hlubokou odborností v oblasti strojového učení, rozsáhlých datových systémů, observability a infrastruktury. Před založením VictoriaMetrics v roce 2018 pracoval jako inženýr strojového učení v divizi autonomních vozidel Level 5 společnosti Lyft, kde pomáhal vyvíjet systémy pro rozpoznávání a analýzu reálných dopravních scénářů. Dříve vedl projekty strojového učení a datové infrastruktury ve Spire Global, působil jako technický spoluzakladatel v Bellgram a pracoval na datech a analytických systémech v Duetto Research a Google prostřednictvím EPAM Systems. Během své kariéry Lazerka vybudoval a vedl projekty zahrnující autonomní řízení, námořní predikci, vyhledávání, analytiku, distribuované zpracování dat a vysoce škálovatelné backendové systémy.

VictoriaMetrics je open-source společnost zabývající se observabilitou, která vytváří nástroje pro sběr, ukládání, dotazování a analýzu velkých objemů provozních dat. Její technologie začala s VictoriaMetrics, vysoce výkonnou databází časových řad a monitorovacím řešením navrženým pro škálovatelnost, rychlé dotazy, efektivní úložiště a nízkou provozní zátěž, a od té doby se rozšířila do širšího stacku observability pokrývajícího metriky, logy a distribuované stopy prostřednictvím VictoriaMetrics, VictoriaLogs a VictoriaTraces. Společnost také nabízí enterprise a plně spravovaná cloudová nasazení spolu s funkcemi detekce anomálií, které používají strojové učení na data časových řad. Její platforma podporuje technologie včetně OpenTelemetry, pracovních toků kompatibilních s Prometheus, Grafana a Kubernetes, což organizacím poskytuje flexibilitu integrovat VictoriaMetrics do existujících prostředí observability.

Před založením VictoriaMetrics jste pracoval na systémech pro rozsáhlá data, analytiku a strojové učení ve společnosti Google, Spire Global, divizi autonomních vozidel Lyft a dalších startupech. Co vás nakonec přimělo založit VictoriaMetrics a které problémy z těchto předchozích rolí vás přesvědčily, že monitorování a observabilita potřebují zásadně odlišný přístup?

Celou svou kariéru jsem pracoval s velkými objemy dat. Ve společnosti Google, Spire, Lyft a dalších firmách rychle zjistíte, že něco, co funguje dobře v jedné škále, může v jiné škále stát draho nebo být obtížně provozovatelné. Monitorování má přesně tento problém.

Jak infrastruktura roste, vytváříte více metrik. Přidáváte více služeb, více instancí a více štítků, až najednou samotný monitorovací systém potřebuje značné množství infrastruktury, což pro nás nikdy nedávalo smysl. Systém určený k monitorování vašeho produkčního prostředí by se neměl stát složitějším a dražším na provoz.

Tohle viděli přímo moji spoluzakladatelé Aliaksandr Valialkin a Roman Khavronenko. Měli zkušenosti s provozem Prometheus a narazili na omezení paměti. Přidání systémů jako Thanos vyřešilo některé problémy se škálováním, ale také zavedlo více komponent a větší provozní složitost. A u InfluxDB jsme viděli, jak změna licencování může ovlivnit technická rozhodnutí poté, co týmy již do technologie investovaly.

Myšlenka za VictoriaMetrics byla praktická: Můžeme postavit databázi časových řad, která vykonává stejnou práci s podstatně menšími zdroji a je jednodušší na provoz?

Nevycházeli jsme z plánu vybudovat velkou observabilní společnost. Začali jsme řešením technického problému.

Udělat ji open source byl součástí toho. Inženýři si mohli stáhnout VictoriaMetrics, nasadit na ní reálné produkční zatížení a sami porovnat výsledky. Nemuseli jsme jim říkat, že je rychlejší nebo efektivnější. Mohli si to změřit.

Toto je nejlepší způsob, jak budovat infrastrukturu software. Pokud je technologie dobrá, měli by inženýři být schopni ji sami dokázat.

Náklady na observabilitu mohou tiše představovat významnou část cloudového účtu společnosti. Kde tyto náklady typicky vymknou kontrole a jaká architektonická nebo nákupní rozhodnutí technické týmy nejčastěji udělají špatně?

Nejprve bych se podíval na kardinalitu.

Předpokládejme, že začnete s rozumnou metrikou a pak přidáte štítek s možnými hodnotami. Najednou se jedna metrika promění na tisíce nebo miliony unikátních časových řad. Systém nyní musí ingestovat, indexovat, ukládat a dotazovat více dat, což vede k vyššímu využití CPU, paměti a úložiště.

Těžké je, že se to nestane kvůli jedné špatné rozhodnutí. Děje se to postupně. Přidáváte více služeb, K8s podů, zákazníků a štítků a náklady se násobí.

Druhý problém je ukládání všeho ve stejné rozlišení po stejnou dobu. Ne všechna data observability mají stejnou hodnotu. Metriky potřebné pro alarm nebo SLO se liší od vysokobjemové diagnostické telemetrie, kterou můžete jednou během incidentu prohlížet.

Pokud zacházíte se všemi těmito daty stejně, končíte placením prémiových cen za infrastrukturu nebo SaaS za data, která to nevyžadují.

Proto některé společnosti přistupují k observabilitě jako k nákupnímu problému a ptají se, která platforma je dnes nejjednodušší k nasazení. Kladu otázky jako: „Co se stane, když se množství telemetrie zvýší 10‑krát? Co se stane s kardinalitou? Co ukládáme? Na jak dlouho? A co se stane s náklady?“

Existují technická řešení těchto problémů. Například pomocí streamovací agregace můžete agregovat metriky před tím, než dorazí do úložiště, místo ukládání každé surové časové řady a pozdější agregace. Můžete oddělit vysokokardinalitní pracovní zatížení od kritického monitorování podnikání. Můžete také použít různé politiky retence a rozlišení v závislosti na hodnotě dat.

Cílem není sbírat co nejméně telemetrie. Potřebujete dostatek informací, abyste pochopili, co vaše systémy dělají.

Cílem je vyhnout se utrácení zdrojů na sběr, zpracování a ukládání dat způsobem, který vám nepřináší další hodnotu.

Observabilita je technický systém. Jeho náklady by měly být také navrženy.

Grammarly uvedlo, že jeho proof‑of‑concept s VictoriaMetrics vedl k desetinásobně nižšímu účtu AWS. Když společnosti dosáhnou úspor v takovém měřítku, co se ve skutečnosti mění pod kapotou: komprese dat, požadavky na výpočet, architektura úložiště, provozní složitost nebo nějaká kombinace těchto faktorů?

Je to kombinace, ale komprese a nároky na zdroje dělají většinu práce. VictoriaMetrics používá speciální kompresi pro data časových řad, takže stejné metriky zabírají zlomek místa na disku, které by zabíraly v obecné databázi. Navíc běžíme čtyř‑ až pětkrát lehčeji na RAM než Prometheus při stejných rychlostech ingestu a až desetkrát lehčeji na disku. Když Grammarly provedlo svůj proof‑of‑concept, ukázalo se to přímo v jejich účtu AWS, protože neukládali jen méně dat; provozovali méně a menší instance.

Provozní složitost také hraje roli, ale je to spíše nepřímé. Mnoho týmů, které odhadují náklady na observabilitu, se dívá jen na položky úložiště a výpočtu a přehlíží inženýrské hodiny strávené provozem pětkomponentového Thanos stacku oproti jedné binárce. To jsou skutečné peníze; jen je těžší je vyčíslit.

Prometheus se stal základem cloud‑native monitorování, ale některé organizace nakonec narazí na omezení škálovatelnosti nebo provozní limity. Co typicky způsobí, že se společnost začne poohlížet za tradičním nasazením Prometheus, a kdy se VictoriaMetrics stane logickou alternativou?

Prometheus je vynikající v tom, k čemu byl vytvořen: jednojádrový engine pro sběr a upozorňování. Týmy obvykle narazí na limit dvěma způsoby: buď jejich kardinalita přesáhne, co jediná instance Promethea dokáže držet v paměti, nebo potřebují dlouhodobé uchovávání a globální dotazování napříč více clustery, což Prometheus nikdy nebyl navržen zvládnout sám. V tu chvíli lidé přidávají Thanos nebo Cortex, což je obvykle místo, kde začíná operační bolest. Přecházíte z provozu jednoho binárního souboru na provoz distribuovaného systému s kompakátorem, dotazovačem, úložní bránou a mnoha dalšími komponentami, které mohou selhat v 3 ráno.

VictoriaMetrics se stává logickým dalším krokem, protože jde o drop‑in náhradu, ne o přepracování architektury. Týmy nasměrují svou existující konfiguraci sběru Promethea na VictoriaMetrics a zachovají všechny Grafana dashboardy, upozornění i nahrávací pravidla, které již vytvořily. Migrace je změna konfigurace, ne projekt, a získají škálovatelnost, aniž by museli přidávat pět nových komponent k provozu.

Vidíme, že technické týmy přehodnocují, zda potřebují velké, plně spravované platformy pro observabilitu, nebo zda mohou postavit efektivnější stacky z open‑source komponent. Vidíte v tom širší strukturální posun na trhu observability a jaký tlak vyvíjí open source na tradiční cenové modely?

Je to strukturální, ne dočasná reakce na špatný rozpočtový rok. Dodavatelé observability historicky stanovovali ceny buď podle objemu ingestu, nebo počtu hostů, a tento model pracuje proti zákazníkovi, jak jeho podnik roste. Čím úspěšnější firma je, tím více platí, a cena nemá skutečný vztah k dodané hodnotě. Technické týmy si začaly samy počítat, uvědomují si, že samostatně hostovaný, efektivní open‑source stack tuto rovnici zcela mění. Důvod je ten, že náklady škálují s infrastrukturou, která je skutečně provozována, místo aby se řídily metrickým vzorcem, který kontroluje dodavatel.

To vyvíjí reálný tlak na stávající cenové modely. Když tým může nasměrovat svou existující konfiguraci sběru na open‑source alternativu a snížit účet o 60 % až 80 % bez ztráty funkčnosti, není to těžká interní konverzace. Dodavatelé, kteří stále účtují za host nebo vlastní metriky, budou i nadále krvácet zákazníky, kteří si tento výpočet neudělají.

AI infrastruktura zavádí neobvykle drahý nový zdroj do rovnice: GPU. Co by měly společnosti provozující AI trénink nebo inference monitorovat nad rámec základního využití GPU a kde může lepší observabilita přímo přispět ke snížení nákladů na AI infrastrukturu?

Využití GPU samotné vám nedává dostatek informací.

Na dashboardu můžete vidět 90 % využití a předpokládat, že je vše v pořádku. Ale co opravdu chcete vědět, je: Co GPU dělá?

Musíte se podívat hlouběji. Které CUDA kernely běží? Jak je alokována paměť GPU? Kolik času se stráví přesunem paměti místo výpočtu? Využívá pracovní zátěž Tensor Cores, když by měla? Je GPU skutečně úzkým hrdlem, nebo čeká na data z jiného místa?

Jedná se o důležité otázky, protože GPU jsou drahé. Malá neefektivita opakovaná na stovkách či tisících GPU se promění v obrovské finanční částky.

Například pokud GPU čekají, protože datová pipeline je nedokáže zásobovat dostatečnou rychlostí, pořízení dalších GPU problém nevyřeší. Musíte najít úzké hrdlo. Totéž platí pro paměť. Pokud pracovní zátěže alokují paměť neefektivně, lepší viditelnost může inženýrům pomoci upravit velikosti batchů nebo spustit více úloh na stejném hardware.

Zde se observabilita stává zajímavou pro AI infrastrukturu. Nejde jen o detekci toho, že něco je rozbité. Může vám říct, kde plýtváte výpočetním výkonem.

Existuje také problém s observabilitou vytvořený tímto monitorováním. GPU mohou generovat spoustu detailní, vysokokardinalitní telemetrie. Pokud sbíráte vše a posíláte to přímo do drahé SaaS platformy, můžete snížit náklady na GPU a pak část úspor utratit za ukládání monitorovacích dat. To však není dobrá optimalizace.

S OpenTelemetry a projekty jako OpenLIT můžeme získat mnohem hlubší viditelnost do GPU pracovních zátěží. Pak s VictoriaMetrics můžeme data agregovat, odstranit dimenze, které nejsou užitečné, a efektivně uchovávat informace, které inženýři skutečně potřebují.

Užitečná otázka není: „Jak moc jsou mé GPU využité?“

Je to: „Jakou užitečnou práci získávám z GPU, za které platím?“

Jakmile na to dokážete odpovědět, můžete začít činit lepší technické a nákladové rozhodnutí.

AI agenti vytvářejí velmi odlišné výzvy pro observabilitu oproti tradičnímu softwaru, protože jediný požadavek může spustit volání modelu, použití nástroje, dotazy do vektorové databáze, předání a potenciálně dlouhé řetězce autonomních akcí. Jak se musí observabilita vyvíjet, když se podnikové aplikace stávají stále více agentními?

Tradiční observabilita předpokládá, že požadavek následuje poměrně předvídatelnou cestu vaším infrastrukturou. Agentní pracovní zátěže tak nefungují. Jeden agent může zavolat model, pak nástroj, pak další model a třikrát se opakovat, než něco vrátí. Každý z těchto kroků potřebuje vlastní viditelnost.

Selhání jsou také odlišná. Tradiční služba buď odpoví správně, nebo ne. Agent může odpovědět úspěšně a přesto být špatný, pomalý nebo drahý, a nic z toho se neukáže jako typická chyba v dashboardu určeném pro dostupnost.

To, co týmy překvapuje, je kardinalita. Jedna agentní workflow může generovat metriky svázané s konkrétním uživatelem, výzvou a voláním nástroje, a tento objem rychle roste, zejména při rekurzivních smyčkách, kde plánovač opakovaně volá stejný nástroj. Jakýkoli systém určený k pozorování agentních pracovních zátěží musí zvládnout tuto škálu, aniž by křivka nákladů šla vertikálně, což je přesně problém, který řešíme. Metriky, logy a trace jsou stále správnými stavebními kameny. Co se musí změnit, je objem a nákladový model pod nimi.

VictoriaMetrics také aplikuje strojové učení a AI‑asistované workflow na detekci anomálií. Kde podle vás AI může dnes skutečně zlepšit monitorování a reakci na incidenty a kde je lidský úsudek stále těžko nahraditelný?

Je důležité mít člověka v cyklu pro generování nápadů, řízení implementace a ověřování výsledků. Jinými slovy, oproti tradičnímu workflow se nic zásadně nezměnilo. Co se změnilo, je to, že schopnosti generovat řešení jsou zesílené. Každý může nyní vytvářet software, ale nemělo by to snižovat kritéria přijetí. Mělo by je to výrazně zvýšit.

Kde AI skutečně pomáhá, je v odhalování toho, co by člověk v šumu přehlédl, jako jsou odlehlé hodnoty a trendy, které nevyvolají manuální prahovou hodnotu. Ve VictoriaMetrics máme jednoduchou interní AI politiku: Zaměstnanci mohou automatizovat svůj pracovní tok, jak chtějí, ale zůstávají zodpovědní za konečný výsledek. To je zhruba stejný standard, který bychom uplatnili na detekci anomálií v produkčním prostředí zákazníka. Model může anomálii označit, ale člověk musí rozhodnout, co to znamená a co s tím udělat.

VictoriaMetrics zůstala open source a zvolila přístup financovaný zákazníky místo tradičního modelu startupu podporovaného venture kapitálem. Jak to ovlivnilo způsob, jakým produkt budujete, jak jej ceníte a jak rozhodujete, které technologie zůstávají open source?

Být samofinancovaný mění strukturu motivací více, než lidé očekávají. Bez představenstva, které by nás tlačilo k dosažení určitého ARR v konkrétním čtvrtletí, jsme nemuseli dělat kompromisy, které obvykle s tímto tlakem přicházejí, jako je omezení open‑source verze, aby se lidé přiměli přejít na placenou úroveň, nebo změna licence, jak to udělaly InfluxDB nebo HashiCorp, když potřebovaly chránit příjmy před poskytovateli cloudu. VictoriaMetrics OSS je dnes pod licencí Apache 2.0 a nemáme v úmyslu ji měnit.

Rozhodování o tom, co zůstane open source, je jednoduché: jádro enginu, to, čemu vývojáři musí důvěřovat se svými produkčními daty, zůstává otevřené. Za to, co společnost potřebuje, když běží ve velkém měřítku a potřebuje odpovědnou osobu, si účtujeme: multi‑tenancy, enterprise autentizaci, podporu souladu, SLA pro CVE a přímý přístup k inženýrům, kteří kód napsali, místo fronty podpory. Financování zákazníky také znamená, že roadmapa je určována tím, s čím se lidé ve výrobě skutečně potýkají, a ne tím, co je možné získat v pitch decku.

Jak se metriky, logy, trace, telemetrie AI aplikací, monitorování GPU a automatické detekce anomálií stále více sbližují, jak si představujete, že bude vypadat stack observability během několika následujících let, a co budou od platforem očekávat inženýrské týmy, aby zůstaly relevantní?

Stack se sbližuje operačně dříve, než se spojí do jednoho produktu, a tento rozdíl je podstatný. Většina týmů nechce monolitickou platformu s jedním UI, která vše sváže dohromady. Chtějí metriky, logy a trace běžící na jednom operačním modelu, u jednoho dodavatele a s jedním licenčním příběhem, aniž by museli vzdát schopnost spouštět každý signál samostatně, pokud to daný tým potřebuje. To je směr, kterým VictoriaMetrics směřuje. Nesnažíme se všechno spojit do jediné binárky. Snažíme se zajistit, aby tři signály sdílely stejný engine a stejné charakteristiky efektivity, takže přidání druhého nebo třetího signálu neznamená přijetí druhé nebo třetí operační bolesti hlavy.

Platformy, které zůstávají relevantní, jsou ty, které dokážou absorbovat AI telemetrii a monitorování GPU do stejného modelu, aniž by se zlomila křivka nákladů. AI pracovní zátěže generují telemetrii v objemu, na který starší cenové modely za metriku nebo hostitele nebyly nikdy navrženy. Týmy buď přestanou sbírat potřebná data, nebo jejich účet za observabilitu roste rychleji než investice do AI, kterou má sledovat. Inženýrské týmy budou od platforem očekávat, že zvládnou tento objem stejným způsobem, jakým očekávají, že se škáluje jakákoli infrastruktura, aniž by je nutili přestavovat architekturu nebo znovu vyjednávat pokaždé, když se pracovní zátěž rozroste.

Děkujeme za skvělý rozhovor, čtenáři, kteří se chtějí dozvědět více, by měli navštívit VictoriaMetrics.