VictoriaMetrics wprowadza VictoriaStack do obsługi metryk, dzienników, śladów i rozwiązywania problemów wspomaganego przez AI

VictoriaMetrics wprowadziła VictoriaStack — otwartoźródłowy zestaw narzędzi do obserwowalności, który łączy jej produkty do obsługi metryk, dzienników i śledzenia rozproszonego we wspólnym modelu operacyjnym. Celem tego wdrożenia jest zapewnienie zespołom inżynierskim możliwości poszerzenia zakresu zbieranych danych telemetrycznych bez konieczności zastępowania całego środowiska monitorowania ani wymuszania przechowywania wszystkich sygnałów w tej samej bazie danych.

VictoriaStack łączy VictoriaMetrics do obsługi metryk, VictoriaLogs do obsługi dzienników oraz VictoriaTraces do śledzenia. Zespoły mogą wdrożyć potrzebne im sygnały, a pozostałe dodać później; wspólne narzędzia wdrożeniowe i obsługa OpenTelemetry ułatwiają integrację poszczególnych elementów.

Ogłoszenie rozszerza ten model również na operacje wspomagane przez AI. Oficjalne serwery Model Context Protocol i umiejętności agentów umożliwiają asystentom analizowanie danych telemetrycznych w całym zestawie, a inżynierowie zachowują odpowiedzialność za decyzję, które zmiany wdrożyć.

Trzy sygnały, trzy wyspecjalizowane bazy danych

Metryki, dzienniki i ślady pomagają odpowiadać na różne pytania operacyjne. Metryki podsumowują zachowanie systemu w czasie, na przykład tempo napływu żądań, liczbę błędów czy zużycie pamięci. Dzienniki rejestrują zdarzenia i ich szczegóły. Śledzenie rozproszone pozwala prześledzić żądanie w wielu usługach, ujawniając, gdzie upłynął czas i gdzie wystąpiła awaria.

Podczas incydentu inżynier może najpierw zauważyć skok opóźnień w metrykach, następnie za pomocą śladów zawęzić problem do konkretnej usługi, a potem sprawdzić dzienniki w poszukiwaniu przyczyny błędu. Ujęcie tych sygnałów w spójny proces pracy może skrócić analizę, nie oznacza jednak, że wszystkie wymagają identycznego sposobu przechowywania.

Dokumentacja architektury VictoriaStack opisuje niezależne bazy danych korzystające ze wspólnego modelu komponentów. Każdą z nich można uruchomić jako pojedynczy plik binarny lub klaster, w którym rozdzielono przyjmowanie danych, ich przechowywanie i wykonywanie zapytań. Zestaw może wykorzystywać vmauth jako punkt wejścia do kierowania ruchem i równoważenia obciążenia.

Interfejsy zapytań również pozostają wyspecjalizowane: VictoriaMetrics korzysta z języka MetricsQL zgodnego z PromQL, VictoriaLogs używa LogsQL, a VictoriaTraces obsługuje LogsQL oraz interfejsy API zgodne z Jaeger i Tempo. Skoordynowane działanie nie oznacza więc jednej bazy danych ani jednego uniwersalnego języka zapytań.

Wszystkie trzy podstawowe bazy danych są dostępne na licencji Apache 2.0. Firma oferuje również funkcje dla przedsiębiorstw i komercyjne wsparcie, a także w pełni zarządzaną usługę VictoriaMetrics Cloud obsługującą wszystkie trzy sygnały.

OpenTelemetry łączy warstwę zbierania danych

OpenTelemetry zapewnia wspólne podejście do instrumentowania aplikacji i eksportowania danych telemetrycznych. Protokół OTLP jest obsługiwany przez wszystkie elementy VictoriaStack — metryki, dzienniki i ślady — dzięki czemu zespoły mogą korzystać ze spójnej ścieżki przyjmowania danych, mimo że trafiają one do różnych systemów zaplecza.

To rozróżnienie ma znaczenie, gdy aplikacja rozrasta się z kilku usług do systemu rozproszonego. Instrumentacja powinna pomagać opisywać zachowanie aplikacji; zmiana miejsca docelowego danych telemetrycznych nie powinna wymagać przeprojektowania kodu monitorującego każdą usługę.

Zestaw obsługuje również inne formaty przyjmowania danych, jeśli są odpowiednie. Zespoły, które już zbierają metryki za pomocą Prometheusa, mogą na przykład zachować ten ekosystem, a jednocześnie dodać do niego dzienniki lub śledzenie. Zgodność protokołów ogranicza nakład pracy związany z migracją, natomiast wybór zasad przechowywania danych, pojemności i wzorców zapytań pozostaje decyzją inżynierską.

W przypadku wdrożeń Kubernetes firma VictoriaMetrics wskazuje swoje narzędzie Operator i wykresy Helm jako standardowe narzędzia do zarządzania. Mają one zapewnić większą spójność wdrożeń i aktualizacji, a jednocześnie zachować możliwość skalowania każdego sygnału odpowiednio do jego własnego obciążenia.

Agenci AI mogą analizować różne rodzaje danych telemetrycznych

VictoriaStack podchodzi do AI z dwóch stron: systemy obserwowalności muszą obsługiwać dane telemetryczne generowane przez aplikacje agentowe, a asystenci AI mogą pomagać inżynierom analizować te dane.

Dokumentacja narzędzi AI firmy opisuje oddzielne serwery MCP do obsługi metryk, dzienników i śladów. Udostępniają one uporządkowane funkcje, takie jak wykonywanie zapytań o szeregi czasowe, przeglądanie pól dzienników, wyszukiwanie usług i operacji oraz pobieranie śladów. Integracja z metrykami ułatwia również analizowanie kardynalności, działania zapytań i konfiguracji alertów.

Repozytorium umiejętności agentów zawiera ponadto wielokrotnego użytku procesy analizy wielu sygnałów i powiązanych z nią zadań operacyjnych. Asystent może przeprowadzić proces rozwiązywania problemów, analizując różne sygnały, zamiast opierać się na jednym pulpicie nawigacyjnym lub wklejonym komunikacie o błędzie.

W ogłoszeniu opisano dostęp tylko do odczytu dla asystentów, takich jak Claude Code, Codex, Cursor oraz agenci tworzeni wewnętrznie. Zamierzony sposób pracy ma więc charakter analityczny: asystent zbiera dowody, łączy objawy i proponuje wyjaśnienie, a inżynierowie decydują, co zostanie wdrożone. Samo połączenie źródła danych telemetrycznych z agentem nie oznacza, że agent prawidłowo ustalił przyczynę źródłową.

Niezależne skalowanie przyjmowania danych i wykonywania zapytań

Szybki start VictoriaStack pokazuje zarówno konfiguracje jednowęzłowe, jak i klastrowe. Prezentacja Docker Compose obejmuje aplikację i kolektor OpenTelemetry, trzy bazy danych, Grafanę, vmalert i vmauth. Dokumentacja wyraźnie zaznacza, że to lokalne środowisko służy do demonstracji, a nie do wdrożenia produkcyjnego.

W modelu klastrowym komponenty odpowiedzialne za przyjmowanie danych i obsługę zapytań są bezstanowe i można je skalować niezależnie, natomiast komponenty przechowujące dane je utrzymują. Pozwala to rozdzielić różne potrzeby: większy napływ danych telemetrycznych może wymagać większej przepustowości przyjmowania danych, a większa liczba inżynierów lub agentów prowadzących dochodzenia może zwiększyć zapotrzebowanie na obsługę zapytań.

Planowanie pamięci masowej nadal ma znaczenie. Dokumentacja informuje, że bazy danych przechowują dane telemetryczne w lokalnych systemach plików, a S3 lub Google Cloud Storage służą do tworzenia kopii zapasowych, a nie jako warstwa obsługi zapytań oparta na pamięci obiektowej. Zwraca również uwagę, że zmniejszenie liczby fragmentów pamięci masowej jest złożoną operacją. Te cechy mają znaczenie przy wyborze topologii i prognozowaniu wzrostu.

Skoordynowany stos bez migracji wszystkiego naraz

VictoriaMetrics prezentuje VictoriaStack podczas KubeCon + CloudNativeCon North America 2026. Pokaz obejmuje aplikację Kubernetes instrumentowaną za pomocą OTLP, która wysyła trzy rodzaje sygnałów telemetrycznych do odpowiednich systemów zaplecza, a następnie prezentuje przepływ pracy związany z diagnozowaniem problemów na podstawie różnych sygnałów.

„Era agentów przyniesie więcej danych telemetrycznych i większe wymagania dotyczące ich przetwarzania” — powiedział w komunikacie Roman Khavronenko, współzałożyciel VictoriaMetrics i kierownik zespołu inżynierskiego. Dodał, że VictoriaStack zaprojektowano z myślą o skalowalności i wydajności w miarę wzrostu tego zapotrzebowania.

Praktyczna propozycja zakłada stopniowe wdrażanie: zachowanie użytecznego ekosystemu gromadzenia danych, dodanie brakujących sygnałów i zarządzanie powstałymi usługami w bardziej spójny sposób. Wartość VictoriaStack zależy od tego, jak dobrze te elementy współpracują w miarę wzrostu ilości danych telemetrycznych i zapotrzebowania na prowadzenie dochodzeń, przy jednoczesnym zachowaniu przez zespoły kontroli nad miejscem przechowywania danych i sposobem skalowania każdego sygnału.