VictoriaMetrics lansează VictoriaStack pentru metrici, jurnale, urme și depanare asistată de IA

VictoriaMetrics a introdus VictoriaStack, o stivă de observabilitate cu cod sursă deschis, care reunește produsele sale pentru metrici, jurnale și trasare distribuită într-un model operațional coordonat. Lansarea urmărește să le ofere echipelor de inginerie o modalitate de a extinde acoperirea telemetriei fără să înlocuiască întregul mediu de monitorizare sau să forțeze stocarea tuturor semnalelor în aceeași bază de date.

VictoriaStack reunește VictoriaMetrics pentru metrici, VictoriaLogs pentru jurnale și VictoriaTraces pentru urme. Echipele pot adopta semnalele de care au nevoie și le pot adăuga pe celelalte ulterior, iar instrumentele comune de implementare și compatibilitatea cu OpenTelemetry ajută la conectarea componentelor.

Anunțul extinde acest model și la operațiunile asistate de IA. Serverele oficiale Model Context Protocol și competențele pentru agenți le permit asistenților să investigheze telemetria din întreaga stivă, în timp ce inginerii păstrează responsabilitatea de a decide ce modificări să aplice.

Trei semnale, trei baze de date specializate

Metricile, jurnalele și urmele răspund unor întrebări operaționale diferite. Metricile sintetizează comportamentul în timp, de exemplu rata solicitărilor, numărul de erori sau consumul de memorie. Jurnalele înregistrează evenimentele și detaliile acestora. Urmele distribuite urmăresc o solicitare prin mai multe servicii, arătând cât timp a fost petrecut în fiecare etapă și unde a apărut o defecțiune.

În timpul unui incident, un inginer ar putea observa mai întâi o creștere bruscă a latenței în metrici, apoi ar putea restrânge problema la un anumit serviciu cu ajutorul urmelor și, în cele din urmă, ar putea examina jurnalele pentru a găsi eroarea de la bază. Reunirea acestor semnale într-un flux de lucru consecvent poate scurta investigația, fără a presupune că au aceleași cerințe de stocare.

Documentația despre arhitectură VictoriaStack descrie baze de date independente care folosesc un model comun de componente. Fiecare poate rula ca un singur fișier executabil sau ca un cluster în care ingestia, stocarea și interogarea sunt separate. Stiva poate folosi vmauth ca punct de intrare pentru rutare și echilibrarea încărcării.

Interfețele de interogare rămân, de asemenea, specializate: VictoriaMetrics folosește MetricsQL, compatibil cu PromQL, VictoriaLogs folosește LogsQL, iar VictoriaTraces acceptă LogsQL, precum și API-uri compatibile cu Jaeger și Tempo. Prin urmare, operarea coordonată nu înseamnă folosirea unei singure baze de date sau a unui limbaj universal de interogare.

Toate cele trei baze de date de bază sunt disponibile sub licența Apache 2.0. Compania oferă, de asemenea, funcționalități pentru întreprinderi și asistență comercială, precum și serviciul VictoriaMetrics Cloud, complet gestionat, care acceptă toate cele trei semnale.

OpenTelemetry conectează nivelul de colectare

OpenTelemetry oferă o abordare comună pentru instrumentarea aplicațiilor și exportul datelor de telemetrie. Protocolul său OTLP este acceptat pentru metrici, jurnale și urme în VictoriaStack, oferind echipelor o cale consecventă de ingestie, chiar dacă datele ajung în sisteme de stocare diferite.

Această distincție contează atunci când o aplicație evoluează de la câteva servicii la un sistem distribuit. Instrumentarea ar trebui să ajute la descrierea comportamentului aplicației; schimbarea destinației datelor de telemetrie nu ar trebui să impună reproiectarea codului de monitorizare al fiecărui serviciu.

Stiva acceptă și alte formate de ingestie, atunci când sunt potrivite. De exemplu, echipele care colectează deja metrici pe baza Prometheus pot păstra acest ecosistem și pot adăuga jurnale sau trasare. Compatibilitatea protocoalelor reduce efortul de migrare, în timp ce deciziile privind retenția, capacitatea și tiparele de interogare țin în continuare de inginerie.

Pentru implementările Kubernetes, VictoriaMetrics indică Operatorul și graficele Helm drept instrumente uzuale de gestionare. Scopul este să facă implementările și actualizările mai consecvente, păstrând totodată posibilitatea de a scala fiecare semnal în funcție de propria sarcină de lucru.

Agenții IA pot investiga întreaga telemetrie

VictoriaStack abordează IA din două direcții: sistemele de observabilitate trebuie să gestioneze datele de telemetrie generate de aplicațiile cu agenți, iar asistenții IA îi pot ajuta pe ingineri să interogheze aceste date.

Documentația companiei despre instrumentele IA descrie servere MCP separate pentru metrici, jurnale și urme. Acestea oferă funcționalități structurate, precum interogarea seriilor temporale, explorarea câmpurilor din jurnale, găsirea serviciilor și a operațiunilor și recuperarea urmelor. Integrarea pentru metrici permite, de asemenea, investigarea cardinalității, a comportamentului interogărilor și a configurației alertelor.

Depozitul de competențe pentru agenți adaugă fluxuri de lucru reutilizabile pentru investigații care implică mai multe semnale și pentru sarcini operaționale conexe. Un asistent poate urma un proces de depanare care acoperă mai multe semnale, în loc să se bazeze pe un singur tablou de bord sau pe un mesaj de eroare copiat.

Anunțul descrie accesul doar în citire pentru asistenți precum Claude Code, Codex, Cursor și agenții dezvoltați intern. Fluxul de lucru avut în vedere este, așadar, unul de investigare: colectarea dovezilor, corelarea simptomelor și formularea unei explicații, în timp ce inginerii decid ce modificări se aplică. Conectarea unei surse de telemetrie la un agent nu demonstrează, prin ea însăși, că agentul a identificat corect cauza principală.

Scalarea separată a ingestiei și a interogărilor

Ghidul de pornire rapidă VictoriaStack prezintă atât configurații cu un singur nod, cât și configurații în cluster. Demonstrația Docker Compose include o aplicație și un colector OpenTelemetry, cele trei baze de date, Grafana, vmalert și vmauth. Documentația precizează explicit că acest mediu local este destinat demonstrațiilor, nu implementării în producție.

În modelul de cluster, componentele de ingestie și interogare nu păstrează stare și pot fi scalate independent, în timp ce componentele de stocare păstrează datele. Astfel, sunt gestionate separat presiuni distincte: un volum mai mare de telemetrie de intrare poate necesita o capacitate mai mare de ingestie, în timp ce un număr mai mare de ingineri sau agenți care desfășoară investigații poate spori cererea de interogare.

Planificarea stocării rămâne importantă. Documentația precizează că bazele de date păstrează telemetria în sisteme de fișiere locale; S3 sau Google Cloud Storage sunt folosite pentru copii de rezervă, nu ca nivel de interogare bazat pe stocare de obiecte. De asemenea, menționează că reducerea numărului de fragmente de stocare este o operațiune complexă. Aceste caracteristici contează la alegerea unei topologii și la estimarea creșterii.

O stivă coordonată, fără migrare dintr-o singură etapă

VictoriaMetrics prezintă VictoriaStack la KubeCon + CloudNativeCon North America 2026, cu o demonstrație în care o aplicație Kubernetes instrumentată cu OTLP trimite cele trei semnale de telemetrie către sistemele backend corespunzătoare, urmată de un flux de lucru de depanare între semnale.

„Era agentică va aduce mai multă telemetrie și cerințe mai mari privind modul în care o procesăm”, a declarat Roman Khavronenko, cofondator și manager de inginerie la VictoriaMetrics, în anunț. Acesta a spus că VictoriaStack este concepută pentru scalabilitate și eficiență pe măsură ce cererea crește.

În practică, abordarea presupune adoptarea treptată: păstrarea unui ecosistem de colectare util, introducerea semnalelor care lipsesc și gestionarea serviciilor rezultate printr-un model mai unitar. Valoarea VictoriaStack depinde de cât de bine funcționează împreună aceste componente pe măsură ce cresc volumul de telemetrie și cererea de investigații, lăsând totodată echipelor controlul asupra locului în care sunt păstrate datele și asupra modului în care se scalează fiecare semnal.