VictoriaMetrics lanserar VictoriaStack för mätvärden, loggar, spårningar och AI-stödd felsökning

VictoriaMetrics har lanserat VictoriaStack, en observabilitetsplattform med öppen källkod som samlar företagets produkter för mätvärden, loggar och distribuerad spårning i en samordnad driftsmodell. Lanseringen ska ge teknikteam möjlighet att utöka sin telemetritäckning utan att byta ut hela sin övervakningsmiljö eller tvinga in alla signaler i samma databas.

VictoriaStack kombinerar VictoriaMetrics för mätvärden, VictoriaLogs för loggar och VictoriaTraces för spårningar. Team kan börja med de signaler de behöver och lägga till fler senare. Gemensamma verktyg för driftsättning och stöd för OpenTelemetry hjälper till att koppla samman delarna.

Tillkännagivandet utvidgar också modellen till AI-stödd drift. Officiella servrar för Model Context Protocol och agentfärdigheter ger assistenter möjlighet att undersöka telemetri i hela plattformen, medan ingenjörerna fortsatt ansvarar för att avgöra vilka ändringar som ska genomföras.

Tre signaler, tre specialiserade databaser

Mätvärden, loggar och spårningar besvarar olika operativa frågor. Mätvärden sammanfattar beteenden över tid, till exempel antal förfrågningar, antal fel eller minnesförbrukning. Loggar registrerar händelser och deras detaljer. Distribuerade spårningar följer en förfrågan genom flera tjänster och visar var tiden gick åt och var ett fel uppstod.

Vid en incident kan en ingenjör först upptäcka en latensökning i mätvärdena, ringa in problemet till en tjänst med hjälp av spårningar och sedan granska loggarna för att hitta det underliggande felet. När signalerna ingår i ett enhetligt arbetsflöde kan undersökningen gå snabbare utan att lagringskraven behöver vara desamma.

VictoriaStacks arkitekturdokumentation beskriver fristående databaser som delar en gemensam komponentmodell. Varje databas kan köras som en enda binärfil eller som ett kluster där inläsning, lagring och frågor hanteras separat. Plattformen kan använda vmauth som ingångspunkt för dirigering och lastbalansering.

Även frågegränssnitten är specialiserade: VictoriaMetrics använder MetricsQL, som är kompatibelt med PromQL, VictoriaLogs använder LogsQL och VictoriaTraces stöder LogsQL samt API:er som är kompatibla med Jaeger och Tempo. Samordnad drift innebär alltså inte att allt använder en enda databas eller ett universellt frågespråk.

Alla tre kärndatabaser finns tillgängliga under licensen Apache 2.0. Företaget erbjuder också företagsfunktioner och kommersiell support samt den helt hanterade tjänsten VictoriaMetrics Cloud, som stöder alla tre signalerna.

OpenTelemetry kopplar samman insamlingslagret

OpenTelemetry erbjuder ett gemensamt sätt att instrumentera applikationer och exportera telemetri. OTLP-protokollet stöds för mätvärden, loggar och spårningar i VictoriaStack, vilket ger teamen en enhetlig väg för dataöverföring även om data lagras i olika system.

Den skillnaden blir viktig när en applikation växer från några få tjänster till ett distribuerat system. Instrumenteringen ska bidra till att beskriva applikationens beteende; ett byte av mottagare för telemetrin ska inte kräva att övervakningskoden för varje tjänst utformas på nytt.

Plattformen stöder även andra format för dataöverföring när det är lämpligt. Team som redan samlar in mätvärden med Prometheus kan till exempel behålla det ekosystemet och samtidigt lägga till loggar eller spårning. Protokollkompatibilitet minskar arbetet med migreringen, medan val av lagringstid, kapacitet och frågemönster fortfarande är tekniska beslut.

För Kubernetes-driftsättningar pekar VictoriaMetrics på sin Operator och sina Helm-diagram som de vanligaste verktygen för hantering. Målet är att göra driftsättningar och uppgraderingar mer enhetliga, samtidigt som varje signal fortsatt kan skalas efter sina egna arbetsbelastningar.

AI-agenter kan undersöka telemetri i hela plattformen

VictoriaStack närmar sig AI från två håll: observabilitetssystem måste kunna hantera telemetri från agentbaserade applikationer, och AI-assistenter kan hjälpa ingenjörer att undersöka den telemetrin.

Företagets dokumentation om AI-verktyg beskriver separata MCP-servrar för mätvärden, loggar och spårningar. De tillhandahåller strukturerade funktioner, som att ställa frågor mot tidsserier, utforska loggfält, hitta tjänster och operationer samt hämta spårningar. Integrationen för mätvärden stöder också undersökningar av kardinalitet, frågebeteende och konfiguration av aviseringar.

Företagets kodförråd för agentfärdigheter innehåller återanvändbara arbetsflöden för undersökningar som omfattar flera signaler och närliggande driftuppgifter. En assistent kan följa ett felsökningsförlopp genom flera signaler i stället för att förlita sig på en enda kontrollpanel eller ett inklistrat felmeddelande.

Tillkännagivandet beskriver skrivskyddad åtkomst för assistenter som Claude Code, Codex, Cursor och interna agenter. Det avsedda arbetsflödet är därmed undersökande: samla in belägg, koppla samman symtom och föreslå en förklaring, medan ingenjörerna avgör vad som ska genomföras. Att koppla en telemetrikälla till en agent innebär inte i sig att agenten har identifierat grundorsaken korrekt.

Skala datainhämtning och frågor var för sig

Snabbstart för VictoriaStack visar både konfigurationer med en enda nod och klustrade konfigurationer. Demomiljön med Docker Compose innehåller en OpenTelemetry-applikation och en insamlare, de tre databaserna, Grafana, vmalert och vmauth. Dokumentationen framhåller uttryckligen att den här lokala miljön är avsedd som en demonstration, inte för produktionsdrift.

I klustermodellen är komponenterna för inmatning och frågor tillståndslösa och kan skalas oberoende av varandra, medan lagringskomponenterna bevarar data. På så sätt skiljs olika belastningar åt: mer inkommande telemetri kan kräva större inmatningskapacitet, medan fler ingenjörer eller agenter som genomför undersökningar kan öka efterfrågan på frågor.

Det är fortfarande viktigt att planera lagringen. Enligt dokumentationen lagrar databaserna telemetri i lokala filsystem; S3 eller Google Cloud Storage används för säkerhetskopior, inte som ett frågelager baserat på objektlagring. Dokumentationen påpekar också att det är en komplicerad åtgärd att minska antalet lagringsshards. Dessa egenskaper spelar roll när man väljer topologi och gör prognoser för tillväxten.

En samordnad stack utan att migrera allt på en gång

VictoriaMetrics presenterar VictoriaStack på KubeCon + CloudNativeCon North America 2026. Demonstrationen visar en OTLP-instrumenterad Kubernetes-applikation som skickar sina tre telemetrisignaler till motsvarande backendtjänster, följt av ett felsökningsflöde som omfattar flera signaler.

”Agenternas era kommer att medföra mer telemetri och högre krav på hur vi bearbetar den”, sade Roman Khavronenko, medgrundare och utvecklingschef på VictoriaMetrics, i tillkännagivandet. Han sade att VictoriaStack är utformat för att vara skalbart och effektivt i takt med att efterfrågan ökar.

Det praktiska förslaget är att införa lösningen stegvis: behålla ett användbart ekosystem för insamling, lägga till de signaler som saknas och hantera de tjänster som tillkommer genom en mer enhetlig modell. Värdet med VictoriaStack ligger i hur väl delarna fungerar tillsammans när telemetrimängden och behovet av undersökningar ökar, samtidigt som teamen själva får bestämma var deras data lagras och hur varje signal skalas.