Дзмітрі Лазерка, співзасновник VictoriaMetrics — серія інтерв’ю

Dzmitry Lazerka, співзасновник VictoriaMetrics — досвідчений інженер‑програміст та технологічний лідер з глибокою експертизою у машинному навчанні, масштабних системах даних, спостережуваності та інфраструктурі. До співзаснування VictoriaMetrics у 2018 році він працював машинним інженером у підрозділі автономних транспортних засобів Level 5 компанії Lyft, де допомагав розробляти системи розпізнавання та аналізу реальних дорожніх сценаріїв. Раніше він керував проектами машинного навчання та інфраструктури даних у Spire Global, був інженер‑співзасновником у Bellgram та працював над системами даних і аналітики у Duetto Research і Google через EPAM Systems. Протягом кар’єри Лазерка створював і керував проєктами в галузях автономного водіння, морського прогнозування, пошуку, аналітики, розподіленої обробки даних та високомасштабованих бек‑енд систем.

VictoriaMetrics — це компанія з відкритим кодом у сфері спостережуваності, яка створює інструменти для збору, зберігання, запитування та аналізу великих обсягів операційних даних. Її технологія почалася з VictoriaMetrics — високопродуктивної бази даних часових рядів і рішення для моніторингу, розроблених для масштабованості, швидких запитів, ефективного зберігання та низьких операційних витрат, а згодом розширилася до ширшого стеку спостережуваності, що охоплює метрики, логи та розподілені трасування через VictoriaMetrics, VictoriaLogs та VictoriaTraces. Компанія також пропонує корпоративні та повністю керовані хмарні розгортання, а також можливості виявлення аномалій, які застосовують машинне навчання до даних часових рядів. Платформа підтримує технології, включаючи OpenTelemetry, робочі процеси, сумісні з Prometheus, Grafana та Kubernetes, надаючи організаціям гнучкість інтегрувати VictoriaMetrics у існуючі середовища спостережуваності.

Перш ніж співзаснувати VictoriaMetrics, ви працювали над масштабними системами даних, аналітики та машинного навчання в Google, Spire Global, підрозділі автономних транспортних засобів Lyft та інших стартапах. Що зрештою спонукало вас створити VictoriaMetrics і які проблеми з цих попередніх ролей переконали вас, що моніторинг і спостережуваність потребують принципово іншого підходу?

Я провів свою кар’єру, працюючи з великими обсягами даних. У Google, Spire, Lyft та інших компаніях швидко розумієш, що те, що добре працює на одному масштабі, може стати дорогим або важким у експлуатації на іншому. Моніторинг має саме цю проблему.

У міру зростання інфраструктури ви створюєте більше метрик. Додаєте більше сервісів, інстансів та міток, доки раптом сама система моніторингу не потребує значних ресурсів інфраструктури, що нам ніколи не здавалось логічним. Система, призначена для моніторингу вашого продакшн‑середовища, не повинна ставати складнішою та дорожчою у експлуатації.

Саме це бачили мої співзасновники Олександр Валялкін та Роман Хавроненко. Вони мали досвід експлуатації Prometheus і стикалися з обмеженнями пам’яті. Додавання систем, таких як Thanos, вирішувало певні проблеми масштабування, але також вводило більше компонентів і підвищувало операційну складність. А з InfluxDB ми побачили, як зміна ліцензування може вплинути на інженерні рішення, коли команди вже інвестували в технологію.

Тому ідея VictoriaMetrics була практичною: чи можемо ми створити базу даних часових рядів, яка виконує ту ж саму роботу з значно меншими ресурсами і простіша в експлуатації?

Ми не починали з плану створити велику компанію у сфері спостережуваності. Ми почали з вирішення інженерної проблеми.

Зробити її відкритою була частиною цього. Інженери могли завантажити VictoriaMetrics, запустити реальні продакшн‑навантаження і самостійно порівняти результати. Нам не треба було казати їм, що вона швидша чи ефективніша. Вони могли це виміряти.

Це найкращий спосіб створювати інфраструктурне ПЗ. Якщо технологія хороша, інженери повинні мати змогу самі це довести.

Витрати на спостережуваність можуть тихо стати значною частиною рахунку компанії за хмару. Де зазвичай ці витрати виходять з‑під контролю і які архітектурні чи закупівельні рішення інженерні команди найчастіше роблять неправильно?

Спершу я б подивився на кардинальність.

Припустимо, ви починаєте з розумної метрики, а потім додаєте мітку з можливими значеннями. Раптом одна метрика перетворюється на тисячі чи мільйони унікальних часових рядів. Система тепер має більше даних для інжесту, індексації, зберігання та запитів, що призводить до збільшення навантаження на CPU, пам’ять і сховище.

Складно те, що це не відбувається через одну погану рішення. Це відбувається поступово. Додаєте більше сервісів, pod‑ів K8s, клієнтів і міток, і витрати множаться.

Друга проблема — зберігання всього з однаковою роздільною здатністю протягом того ж часу. Не всі дані спостережуваності мають однакову цінність. Метрики, потрібні для алерту чи SLO, відрізняються від високовольтних діагностичних телеметрій, які ви переглядаєте один раз під час інциденту.

Якщо ставитися до всіх цих даних однаково, ви в кінцевому підсумку платите преміальні ціни за інфраструктуру чи SaaS за дані, які цього не потребують.

Ось чому деякі компанії розглядають спостережуваність як проблему закупівлі, запитуючи, яка платформа найпростіша у розгортанні сьогодні. Я ставлю питання типу: “Що станеться, коли обсяг телеметрії збільшиться в 10 разів? Що буде з кардинальністю? Що ми зберігаємо? На який термін? І що буде з витратами?”

Існують інженерні рішення цих проблем. Наприклад, за допомогою потокової агрегації можна агрегувати метрики до того, як вони потраплять у сховище, замість зберігання кожного сирого часового ряду та подальшої агрегації. Можна розділяти навантаження з високою кардинальністю від критичного для бізнесу моніторингу. Також можна застосовувати різні політики зберігання та роздільної здатності залежно від цінності даних.

Мета не в тому, щоб збирати якомога менше телеметрії. Потрібно достатньо інформації, щоб розуміти, що роблять ваші системи.

Мета — уникнути витрат ресурсів на збір, обробку та зберігання даних у спосіб, який не приносить додаткової цінності.

Спостережуваність — це інженерна система. Її вартість також має бути спроектована.

Grammarly заявив, що їхній proof‑of‑concept з VictoriaMetrics призвів до зниження рахунку AWS у 10 разів. Коли компанії досягають заощаджень такого масштабу, що саме змінюється «під капотом»: стиснення даних, вимоги до обчислень, архітектура сховища, операційна складність чи їхня комбінація?

Це комбінація, але стиснення та ресурсний слід виконують більшу частину роботи. VictoriaMetrics використовує спеціально створене стиснення для даних часових рядів, тому ті ж метрики займають лише частину дискового простору, яку б займала загальна база даних. Крім того, ми споживаємо в чотири‑п’ять разів менше оперативної пам’яті, ніж Prometheus при аналогічних швидкостях інжесту, і до 10 разів менше дискового простору. Коли Grammarly провели свій proof‑of‑concept, це відразу відобразилося у їхньому рахунку AWS, бо вони не лише зберігали менше даних; вони запускали менше і менші інстанси для цього.

Також важливий аспект операційної складності, хоча він більш непрямий. Багато команд, оцінюючи витрати на спостережуваність, дивляться лише на статті зберігання та обчислень і не враховують інженерні години, витрачені на експлуатацію п’ятикомпонентного стеку Thanos у порівнянні з одним бінарним файлом. Це реальні гроші; просто важче підрахувати їх у цифрах.

Prometheus став фундаментальним для cloud‑native моніторингу, проте деякі організації зрештою стикаються з обмеженнями масштабованості чи операційними обмеженнями. Що зазвичай спонукає компанію шукати альтернативу традиційному розгортанню Prometheus, і коли VictoriaMetrics стає логічною альтернативою?

Prometheus відмінний у тому, для чого його створили: однопоточний збір даних та система сповіщень. Команди зазвичай стикаються зі стіною двома способами: або їхня кардинальність зростає понад те, що один екземпляр Prometheus може вмістити в пам’яті, або їм потрібне довгострокове зберігання та глобальний запит по кількох кластерах, для чого Prometheus ніколи не був розрахований. Тоді люди додають Thanos або Cortex, і саме тут зазвичай починаються операційні болі. Ви переходите від запуску одного бінарного файлу до запуску розподіленої системи з компресором, запитувачем, шлюзом сховища та багатьма іншими компонентами, які можуть зламатися о 3 годині ранку.

VictoriaMetrics стає логічним наступним кроком, оскільки це готова заміна, а не переархітектурування. Команди перенаправляють свою існуючу конфігурацію збору Prometheus на VictoriaMetrics і зберігають усі панелі Grafana, сповіщення та правила запису, які вони вже створили. Міграція — це зміна конфігурації, а не проєкт, і вони отримують масштабованість без додавання п’яти нових компонентів для експлуатації.

Ми спостерігаємо, як інженерні команди переосмислюють, чи потрібні їм великі, повністю керовані платформи спостережуваності, чи вони можуть створювати більш ефективні стеки з відкритих компонентів. Чи вважаєте ви це ширшим структурним зрушенням на ринку спостережуваності, і наскільки відкритий код тисне на традиційні цінові моделі?

Це структурно; а не тимчасова реакція на поганий бюджетний рік. Постачальники рішень спостережуваності історично встановлювали ціни за обсягом інжесту або кількістю хостів, і ця модель працює проти клієнта, коли його бізнес зростає. Чим успішнішою стає компанія, тим більше вона платить, і ціна не має реального зв’язку з доставленою цінністю. Інженерні команди почали самостійно робити розрахунки, розуміючи, що самостійно розгорнутий, ефективний стек з відкритим кодом повністю змінює це рівняння. Це тому, що вартість масштабується разом з реальною інфраструктурою, а не за формулою вимірювання, якою керує постачальник.

Це створює реальний тиск на існуючі ціни. Коли команда може перенаправити свою існуючу конфігурацію збору на відкриту альтернативу і скоротити рахунок на 60‑80 % без втрати функціональності, це не складна розмова всередині компанії. Постачальники, які все ще стягують плату за хост або за користувацьку метрику, продовжуватимуть виснажувати клієнтів, які не роблять такі розрахунки.

Інфраструктура ШІ вводить у рівняння надзвичайно дорогий новий ресурс: GPU. Що мають моніторити компанії, що займаються навчанням або інференсом ШІ, окрім базової зайнятості GPU, і де краща спостережуваність може безпосередньо призвести до зниження витрат на інфраструктуру ШІ?

Зайнятість GPU сама по собі не розповідає достатньо.

Ви можете бачити 90 % зайнятості на панелі та припускати, що все в порядку. Але насправді ви хочете знати: що робить GPU?

Потрібно заглянути глибше. Які CUDA‑ядра працюють? Як розподіляється пам’ять GPU? Скільки часу витрачається на переміщення пам’яті замість обчислень? Чи використовує навантаження Tensor Cores, коли це потрібно? Чи є GPU справжнім вузьким місцем, чи він чекає дані звідкись ще?

Це важливі питання, бо GPU дорогі. Невелика неефективність, повторена на сотнях або тисячах GPU, перетворюється на дуже великі витрати.

Наприклад, якщо GPU чекають, бо конвеєр даних не встигає їх забезпечити, купівля додаткових GPU не вирішить проблему. Потрібно знайти вузьке місце. Те ж саме стосується пам’яті. Якщо навантаження неефективно розподіляє пам’ять, краща видимість може допомогти інженерам налаштувати розмір пакетів або запускати більше навантажень на тому ж обладнанні.

Саме тут спостережуваність стає цікавою для інфраструктури ШІ. Це не лише про виявлення поломки. Вона може підказати, де ви марнуєте обчислення.

Існує також проблема спостережуваності, створена всім цим моніторингом. GPU можуть генерувати багато детальної телеметрії з високою кардинальністю. Якщо ви збираєте все і надсилаєте безпосередньо в дорогий SaaS‑платформу, ви можете зменшити витрати на GPU, а потім витратити частину заощаджень на зберігання даних моніторингу. Але це не є хорошою оптимізацією.

За допомогою OpenTelemetry та проєктів, таких як OpenLIT, ми можемо отримати значно глибшу видимість у навантаженнях GPU. Потім, за допомогою VictoriaMetrics, ми можемо агрегувати дані, видаляти непотрібні виміри та ефективно зберігати інформацію, яка дійсно потрібна інженерам.

Корисне питання не «Наскільки зайняті мої GPU?»

А «Яку корисну роботу я отримую від GPU, за які я плачу?»

Коли ви зможете відповісти на це, ви зможете приймати кращі інженерні та фінансові рішення.

AI‑агенти створюють зовсім інші виклики для спостережуваності порівняно з традиційним програмним забезпеченням, оскільки один запит може викликати виклики моделей, використання інструментів, запити до векторних баз даних, передачі управління та потенційно довгі ланцюжки автономних дій. Як має розвиватися спостережуваність, коли корпоративні застосунки стають все більш агентними?

Традиційна спостережуваність передбачає, що запит проходить досить передбачуваний шлях через вашу інфраструктуру. Агентні навантаження не працюють так. Один агент може викликати модель, потім інструмент, потім іншу модель і тричі повторити спробу, перш ніж щось поверне. Кожен із цих кроків потребує власної видимості.

Режими відмов також різні. Традиційна служба або відповідає правильно, або не відповідає. Агент може успішно відповісти, але все одно бути неправильним, повільним або дорогим, і жоден з цих випадків не відображається як типова помилка на панелі, створеній для моніторингу доступності.

Те, що здивовує команди, — це кардинальність. Одиний робочий процес агента може генерувати метрики, пов’язані з конкретним користувачем, підказкою та викликом інструменту, і цей обсяг швидко зростає, особливо при рекурсивних циклах, коли планувальник постійно викликає один і той же інструмент. Будь-яка система, призначена для спостереження за агентними навантаженнями, має впоратися з таким масштабом без вертикального зростання вартості, що саме є нашою проблемою. Метрики, логи та трасування залишаються правильними будівельними блоками. Потрібно змінити лише обсяг і модель вартості під ними.

VictoriaMetrics також застосовує машинне навчання та AI‑асистовані робочі процеси для виявлення аномалій. Де, на вашу думку, AI справді може покращити моніторинг та реагування на інциденти сьогодні, і де людське судження все ще важко замінити?

Важливо залишати людину в процесі для генерації ідей, керування впровадженням та валідації результатів. Іншими словами, порівняно з традиційним робочим процесом нічого суттєво не змінилося. Змінилося лише те, що можливості генерувати рішення стали більш потужними. Тепер будь-хто може створювати програмне забезпечення, але це не повинно знижувати критерії прийнятності. Навпаки, їх слід значно підвищити.

AI справді допомагає, виявляючи те, що людина могла б пропустити у шумі, наприклад, викиди та тенденції, які не спрацьовують за ручним порогом. У VictoriaMetrics у нас проста внутрішня політика щодо AI: працівники вільні автоматизувати свій робочий процес як завгодно, але залишаються відповідальними за кінцевий результат. Це приблизно той самий стандарт, який ми застосовували б до виявлення аномалій у виробничому середовищі клієнта. Модель може позначити аномалію, але людина все одно має вирішити, що це означає і що робити далі.

VictoriaMetrics залишилася відкритим кодом і обрала підхід самофінансування та фінансування клієнтами, а не традиційну модель стартапу інфраструктури, підтримувану венчурним капіталом. Як це вплинуло на те, як ви створюєте продукт, встановлюєте ціну та вирішуєте, які технології залишаються відкритим кодом?

Самофінансування змінює структуру стимулів більше, ніж люди очікують. Оскільки у нас немає правління, яке вимагало б досягти певного рівня ARR у конкретному кварталі, нам не доводилося робити компроміси, які зазвичай супроводжують такий тиск, наприклад, обмежувати відкриту версію, щоб змусити людей перейти на платний рівень, або змінювати ліцензію, як це зробили InfluxDB чи HashiCorp, коли їм потрібно було захистити доходи від хмарних провайдерів. VictoriaMetrics OSS сьогодні має ліцензію Apache 2.0, і ми не плануємо її змінювати.

Наш підхід до визначення того, що залишається відкритим кодом, простий: ядро‑двигун, те, чим інженери довіряють нам свої виробничі дані, залишається відкритим. Ми стягуємо плату лише за те, що компанії потрібно, коли вона працює у масштабі і потребує відповідального підходу: мульти‑тенантність, корпоративна автентифікація, підтримка відповідності, SLA щодо CVE та прямий доступ до інженерів, які писали код, замість черги підтримки. Фінансування від клієнтів також означає, що дорожня карта формується на основі реальних проблем у продакшені, а не на підставі того, що можна залучити у презентації.

Оскільки метрики, журнали, трасування, телеметрія AI‑застосунків, моніторинг GPU та автоматичне виявлення аномалій все більше збігаються, як ви вважаєте, яким буде стек спостережуваності протягом наступних кількох років і чого інженерні команди очікуватимуть від платформ, які прагнуть залишатися актуальними?

Стек об’єднується операційно ще до того, як стане єдиним продуктом, і ця різниця має значення. Більшість команд не хочуть монолітної платформи з єдиним інтерфейсом, що скріплює все разом. Вони хочуть, щоб метрики, журнали та трасування працювали за єдиною операційною моделлю, у одного постачальника та за однією ліцензійною схемою, не втрачаючи можливості запускати кожний сигнал окремо, якщо це потрібно конкретній команді. Саме в цьому напрямку розвивається VictoriaMetrics. Ми не намагаємося втиснути все в один бінарний файл. Ми прагнемо, щоб три сигнали користувалися одним і тим же двигуном і мали однакові характеристики ефективності, тому додавання другого чи третього сигналу не означає появу другого чи третього операційного болю.

Платформи, які залишаються актуальними, – це ті, що можуть вбудовувати AI‑телеметрію та моніторинг GPU у ту саму модель без різкого зростання вартості. AI‑навантаження генерує телеметрію у об’ємі, для якого традиційне ціноутворення за метрику чи хост не передбачалося. Команди або припиняють збирати потрібні дані, або їх рахунок за спостережуваність зростає швидше, ніж інвестиції в AI, які вони мають контролювати. Інженерні команди очікуватимуть, що платформи впораються з таким об’ємом так само, як вони очікують масштабування будь‑якої інфраструктури, без необхідності перебудовувати архітектуру чи переукладати умови щоразу, коли навантаження зростає.

Дякуємо за чудове інтерв’ю, читачі, які хочуть дізнатися більше, можуть відвідати VictoriaMetrics.