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 пропонує використовувати Operator і чарти 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 полягає в тому, наскільки злагоджено ці компоненти працюють разом зі зростанням обсягу телеметрії та потреб у розслідуваннях, водночас залишаючи командам контроль над місцем зберігання даних і масштабуванням кожного сигналу.