Dzmitry Lazerka, соучредитель 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, запустить на ней реальные производственные нагрузки и сравнить результаты сами. Нам не нужно было говорить им, что она быстрее или эффективнее. Они могли измерить это.

Это лучший способ создавать инфраструктурное программное обеспечение. Если технология хороша, инженеры должны иметь возможность доказать это сами.

Затраты на наблюдаемость могут тихо стать значительной частью облачного счёта компании. Где обычно эти затраты выходят из‑под контроля, и какие архитектурные или закупочные решения чаще всего ошибаются инженерные команды?

Сначала я бы посмотрел на кардинальность.

Допустим, вы начинаете с разумной метрики, затем добавляете метку с возможными значениями. Внезапно одна метрика превращается в тысячи или миллионы уникальных временных рядов. Система теперь имеет больше данных для приёма, индексации, хранения и запросов, что приводит к большему использованию процессора, памяти и дискового пространства.

Трудность в том, что это происходит не из‑за одной плохой решения. Это происходит постепенно. Добавляете больше сервисов, pod‑ов K8s, клиентов и меток, и стоимость умножается.

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

Если относиться ко всем этим данным одинаково, вы в итоге платите премиальные цены за инфраструктуру или SaaS за данные, которые этого не требуют.

Поэтому некоторые компании рассматривают наблюдаемость как проблему закупок, спрашивая, какая платформа самая простая в развертывании сегодня. Я задаю вопросы вроде: «Что происходит, когда объём телеметрии увеличивается в 10 раз? Что происходит с кардинальностью? Что мы храним? Как долго? И что происходит с затратами?»

Существует инженерные решения этих проблем. Например, с потоковой агрегацией вы можете агрегировать метрики до того, как они попадут в хранилище, вместо того чтобы хранить каждый сырой временной ряд и агрегировать их позже. Вы можете отделить нагрузки с высокой кардинальностью от бизнес‑критичного мониторинга. Вы также можете использовать разные политики удержания и разрешения в зависимости от ценности данных.

Цель не в том, чтобы собирать как можно меньше телеметрии. Нужно достаточно информации, чтобы понять, что делают ваши системы.

Цель — избежать траты ресурсов на сбор, обработку и хранение данных способом, который не приносит дополнительной ценности.

Наблюдаемость — это инженерная система. Её стоимость также должна быть спроектирована.

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

Это комбинация, но сжатие и ресурсный след делают большую часть работы. VictoriaMetrics использует специально разработанное сжатие для данных временных рядов, поэтому те же метрики занимают лишь небольшую часть дискового пространства, которую они занимали бы в универсальной базе данных. Кроме того, мы потребляем в четыре‑пять раз меньше ОЗУ, чем Prometheus при тех же скоростях ingest, и до десяти раз меньше диска. Когда Grammarly провела свой proof‑of‑concept, это отразилось непосредственно в их счёте AWS, потому что они хранили не только меньше данных; они запускали меньше и меньших по размеру инстансов.

Сложность операционной части тоже важна, но более косвенно. Многие команды, оценивая затраты на наблюдаемость, смотрят только на позиции хранения и вычислений и упускают часы инженерных усилий, затрачиваемые на эксплуатацию пятикомпонентного стека Thanos по сравнению с одним бинарником. Это реальные деньги; просто труднее их количественно оценить.

Prometheus стал фундаментом облачно‑нативного мониторинга, однако некоторые организации в конечном итоге сталкиваются с ограничениями масштабируемости или эксплуатации. Что обычно заставляет компанию искать альтернативу традиционному развертыванию 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‑агенты создают совершенно иные задачи наблюдаемости по сравнению с традиционным программным обеспечением, потому что один запрос может вызвать вызовы моделей, использование инструментов, запросы к векторным базам данных, передачи управления и потенциально длинные цепочки автономных действий. Как должна развиваться наблюдаемость, когда корпоративные приложения становятся всё более агентными?

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

Сценарии отказов тоже отличаются. Традиционный сервис либо отвечает корректно, либо нет. Агент может ответить успешно, но при этом быть ошибочным, медленным или дорогим, и ни один из этих факторов не отобразится как типичная ошибка на панели, построенной для мониторинга доступности.

То, что удивляет команды, — это кардинальность. Одна workflow агента может генерировать метрики, привязанные к конкретному пользователю, запросу и вызову инструмента, и такой объём быстро растёт, особенно при рекурсивных циклах, где планировщик постоянно вызывает один и тот же инструмент. Любая система, предназначенная для наблюдения за агентными нагрузками, должна справляться с этим масштабом без вертикального роста стоимости, что именно мы и решаем. Метрики, логи и трассировки остаются правильными строительными блоками. Нужно изменить лишь объём и модель стоимости, лежащие в их основе.

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

Важно сохранять участие человека при генерации идей, управлении реализацией и проверке результатов. Другими словами, по сравнению с традиционным процессом ничего действительно не изменилось. Изменилось лишь то, что возможности создания решений усилились. Сейчас любой может создавать программное обеспечение, но это не должно снижать критерии приемки. Их следует значительно повысить.

Где ИИ действительно помогает — в выявлении того, что человек иначе упустил бы в шуме, например, выбросов и трендов, которые не срабатывают на ручном пороге. В VictoriaMetrics у нас простая внутренняя политика по ИИ: сотрудники могут автоматизировать свои рабочие процессы как угодно, но они остаются ответственными за конечный результат. Это примерно тот же стандарт, который мы применяли бы к обнаружению аномалий в производственной среде клиента. Модель может пометить аномалию, но человек всё равно должен решить, что это значит и как действовать.

VictoriaMetrics осталась открытым проектом и выбрала подход самофинансирования, финансируемый клиентами, вместо традиционной модели стартапа инфраструктуры, поддерживаемой венчурным капиталом. Как это повлияло на то, как вы создаёте продукт, формируете его цену и решаете, какие технологии остаются открытыми?

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

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

По мере того как метрики, логи, трассировки, телеметрия AI‑приложений, мониторинг GPU и автоматическое обнаружение аномалий всё больше сходятся, как вы думаете, как будет выглядеть стек наблюдаемости в ближайшие несколько лет и чего будут ожидать инженерные команды от платформ, желающих оставаться актуальными?

Стек сначала конвергирует операционно, а уже потом как единый продукт, и это различие имеет значение. Большинство команд не хотят монолитную платформу с единой UI, связывающей всё вместе. Они хотят, чтобы метрики, логи и трассировки работали по одной операционной модели, у одного поставщика и по одной лицензии, не отказываясь от возможности запускать каждый сигнал независимо, если это требуется конкретной команде. Именно в этом направлении развивается VictoriaMetrics. Мы не пытаемся собрать всё в один бинарный файл. Мы стремимся обеспечить, чтобы три сигнала использовали один и тот же движок и одинаковые характеристики эффективности, так что добавление второго или третьего сигнала не превращается во вторую или третью операционную головную боль.

Платформы, остающиеся актуальными, способны интегрировать телеметрию AI и мониторинг GPU в ту же модель без разрушения кривой стоимости. AI‑нагрузки генерируют телеметрию в объёме, для которого традиционная цена за метрику или за хост никогда не была рассчитана. Команды либо прекращают сбор нужных данных, либо их счёт за наблюдаемость растёт быстрее, чем инвестиции в AI, которые они должны контролировать. Инженерные команды будут ожидать, что платформы справятся с этим объёмом так же, как они ожидают масштабирование любой инфраструктуры, без необходимости каждый раз перестраивать архитектуру или вести новые переговоры при росте нагрузки.

Спасибо за отличное интервью, читатели, желающие узнать больше, могут посетить VictoriaMetrics.