VictoriaMetrics представляет VictoriaStack для метрик, логов, трассировок и устранения неполадок с помощью ИИ

VictoriaMetrics представила VictoriaStack — стек наблюдаемости с открытым исходным кодом, который объединяет продукты компании для работы с метриками, логами и распределёнными трассировками в единую модель эксплуатации. Запуск призван дать инженерным командам возможность расширять охват телеметрии, не заменяя всю имеющуюся среду мониторинга и не вынуждая сводить все сигналы в одну базу данных.

VictoriaStack объединяет VictoriaMetrics для работы с метриками, VictoriaLogs для логов и VictoriaTraces для трассировок. Команды могут подключать нужные им сигналы, а остальные добавлять позже; общие инструменты развёртывания и поддержка OpenTelemetry помогают связать компоненты.

Анонс также распространяет эту модель на эксплуатацию с помощью ИИ. Официальные серверы Model Context Protocol и навыки для агентов позволяют помощникам исследовать телеметрию во всём стеке, а решение о том, какие изменения применить, остаётся за инженерами.

Три сигнала — три специализированные базы данных

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

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

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

Интерфейсы запросов также остаются специализированными: VictoriaMetrics использует совместимый с PromQL язык MetricsQL, VictoriaLogs — LogsQL, а VictoriaTraces поддерживает LogsQL, а также API, совместимые с Jaeger и Tempo. Таким образом, согласованная работа не означает, что всё сводится к одной базе данных или единому языку запросов.

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

OpenTelemetry объединяет уровень сбора данных

OpenTelemetry предлагает единый подход к инструментированию приложений и передаче телеметрии. Протокол OTLP поддерживается для метрик, логов и трассировок в VictoriaStack, благодаря чему команды могут использовать единый путь приёма данных, даже если они поступают в разные системы хранения.

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

При необходимости стек поддерживает и другие форматы передачи данных. Например, команды, уже собирающие метрики на основе Prometheus, могут сохранить эту экосистему и параллельно добавить сбор логов или трассировок. Совместимость протоколов снижает объём работ по миграции, однако выбор сроков хранения, ёмкости и шаблонов запросов по-прежнему остаётся инженерным решением.

Для развёртывания в Kubernetes VictoriaMetrics рекомендует использовать оператор и диаграммы Helm как основные инструменты управления. Их цель — сделать развёртывание и обновления более единообразными, сохранив возможность масштабировать каждый сигнал с учётом нагрузки на него.

ИИ-агенты могут исследовать телеметрию по всем системам

VictoriaStack использует два подхода к ИИ: системы наблюдаемости должны обрабатывать телеметрию, создаваемую агентными приложениями, а ИИ-помощники могут помогать инженерам анализировать эти данные.

В документации по инструментам ИИ компании описаны отдельные MCP-серверы для метрик, логов и трассировок. Они предоставляют структурированные возможности, например запросы к временным рядам, изучение полей логов, поиск сервисов и операций, а также получение трассировок. Интеграция с метриками также помогает исследовать кардинальность, поведение запросов и настройки оповещений.

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

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

Раздельное масштабирование приёма данных и выполнения запросов

Краткое руководство по началу работы с VictoriaStack демонстрирует конфигурации как с одним узлом, так и кластерную. В демонстрационный пример Docker Compose входят приложение и коллектор OpenTelemetry, три базы данных, Grafana, vmalert и vmauth. В документации прямо указано, что эта локальная среда предназначена для демонстрации, а не для промышленного развертывания.

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

Планирование хранилища по-прежнему важно. В документации сказано, что базы данных хранят телеметрию в локальных файловых системах, а S3 или Google Cloud Storage используются для резервного копирования, а не как уровень выполнения запросов на основе объектного хранилища. Также отмечается, что уменьшить количество сегментов хранения — сложная задача. Эти особенности важно учитывать при выборе топологии и прогнозировании роста.

Согласованный стек без одномоментной миграции

VictoriaMetrics представляет VictoriaStack на KubeCon + CloudNativeCon North America 2026. В рамках демонстрации приложение Kubernetes с инструментированием OTLP передаёт три сигнала телеметрии в соответствующие серверные системы, после чего показывается процесс устранения неполадок с использованием данных разных типов телеметрии.

«В эпоху агентных систем объём телеметрии вырастет, а требования к её обработке станут выше», — заявил в анонсе Роман Хавроненко, сооснователь VictoriaMetrics и руководитель инженерного отдела. По его словам, VictoriaStack создана с расчётом на масштабируемость и эффективность по мере роста спроса.

Практическое преимущество такого подхода — возможность внедрять решение поэтапно: сохранить полезную экосистему сбора данных, добавить недостающие типы телеметрии и управлять получившимися сервисами по более согласованной модели. Ценность VictoriaStack определяется тем, насколько слаженно работают её компоненты при росте объёма телеметрии и потребности в расследованиях, при этом команды сохраняют контроль над местом хранения данных и масштабированием каждого типа телеметрии.