VictoriaMetrics lancerer VictoriaStack til metrikker, logge, spor og AI-assisteret fejlfinding

VictoriaMetrics har lanceret VictoriaStack, en open source-observabilityplatform, der samler virksomhedens produkter til metrikker, logge og distribueret sporing i en koordineret driftsmodel. Lanceringen skal give tekniske teams mulighed for at udvide deres telemetridækning uden at udskifte hele deres overvågningsmiljø eller tvinge alle signaler ind i den samme database.

VictoriaStack kombinerer VictoriaMetrics til metrikker, VictoriaLogs til logge og VictoriaTraces til spor. Teams kan tage de signaltyper i brug, de har brug for, og tilføje flere senere. Fælles værktøjer til implementering og understøttelse af OpenTelemetry hjælper med at forbinde delene.

Meddelelsen udvider også denne model til AI-assisteret drift. Officielle servere til Model Context Protocol og agentfærdigheder giver assistenter mulighed for at undersøge telemetri på tværs af platformen, mens ingeniørerne fortsat har ansvaret for at beslutte, hvilke ændringer der skal gennemføres.

Tre signaltyper, tre specialiserede databaser

Metrikker, logge og spor besvarer forskellige driftsmæssige spørgsmål. Metrikker sammenfatter adfærd over tid, for eksempel forespørgselsrater, antal fejl eller hukommelsesforbrug. Logge registrerer hændelser og deres detaljer. Distribuerede spor følger en forespørgsel gennem flere tjenester og viser, hvor tiden blev brugt, og hvor en fejl opstod.

Under en hændelse vil en ingeniør måske først opdage en stigning i svartiden i metrikkerne, derefter afgrænse problemet til en tjeneste ved hjælp af spor og til sidst undersøge loggene for at finde den underliggende fejl. Når signalerne indgår i en ensartet arbejdsgang, kan undersøgelsen gå hurtigere, uden at deres lagringsbehov behøver at være ens.

VictoriaStacks arkitekturdokumentation beskriver uafhængige databaser, der deler en fælles komponentmodel. Hver database kan køre som én binær fil eller som en klynge, hvor indlæsning, lagring og forespørgsler er adskilt. Platformen kan bruge vmauth som indgangspunkt til dirigering og belastningsfordeling.

Forespørgselssprogene er også fortsat specialiserede: VictoriaMetrics bruger PromQL-kompatible MetricsQL, VictoriaLogs bruger LogsQL, og VictoriaTraces understøtter LogsQL samt API’er, der er kompatible med Jaeger og Tempo. Koordineret drift betyder derfor ikke, at der kun er én database eller ét universelt forespørgselssprog.

Alle tre kernedatabaser er tilgængelige under Apache 2.0-licensen. Virksomheden tilbyder også virksomhedsfunktioner og kommerciel support samt den fuldt administrerede tjeneste VictoriaMetrics Cloud, der understøtter alle tre signaltyper.

OpenTelemetry forbinder indsamlingslaget

OpenTelemetry tilbyder en fælles tilgang til instrumentering af applikationer og eksport af telemetri. OTLP-protokollen understøttes på tværs af VictoriaStacks metrikker, logge og spor, så teams får en ensartet vej til indlæsning, selvom dataene ender i forskellige backends.

Denne forskel bliver vigtig, når en applikation vokser fra nogle få tjenester til et distribueret system. Instrumenteringen skal gøre det muligt at beskrive applikationens adfærd; ændring af telemetriens destination bør ikke kræve, at overvågningskoden i hver tjeneste redesignes.

Platformen understøtter også andre formater til indlæsning, når det er relevant. Teams, der allerede indsamler metrikker baseret på Prometheus, kan for eksempel fortsætte med at bruge dette økosystem og samtidig føje logge eller sporing til. Protokolkompatibilitet mindsker arbejdet med migrering, mens valg af opbevaringsperiode, kapacitet og forespørgselsmønstre fortsat er en teknisk beslutning.

Til Kubernetes-implementeringer fremhæver VictoriaMetrics sin Operator og sine Helm-diagrammer som de almindelige værktøjer til administration. Målet er at gøre implementeringer og opgraderinger mere ensartede og samtidig bevare muligheden for at skalere hver signaltype efter dens egen arbejdsbelastning.

AI-agenter kan undersøge telemetri på tværs af platformen

VictoriaStack arbejder med AI fra to vinkler: Observabilitetssystemer skal kunne håndtere telemetri, der genereres af agentbaserede applikationer, og AI-assistenter kan hjælpe ingeniører med at undersøge denne telemetri.

Virksomhedens dokumentation for AI-værktøjer beskriver separate MCP-servere til metrikker, logge og spor. De stiller strukturerede funktioner til rådighed, såsom forespørgsler på tidsserier, udforskning af logfelter, søgning efter tjenester og operationer samt hentning af spor. Integrationen til metrikker understøtter også undersøgelser af kardinalitet, forespørgselsadfærd og konfiguration af alarmering.

Virksomhedens lager med agentfærdigheder føjer genanvendelige arbejdsgange til for undersøgelser på tværs af flere signaltyper og beslægtede driftsopgaver. En assistent kan følge en fejlfindingsproces på tværs af signaler i stedet for kun at støtte sig til et enkelt kontrolpanel eller en indsat fejlmeddelelse.

Meddelelsen beskriver skrivebeskyttet adgang for assistenter som Claude Code, Codex, Cursor og interne agenter. Den tilsigtede arbejdsgang er dermed undersøgende: Indsamling af dokumentation, sammenkædning af symptomer og fremsættelse af en mulig forklaring, mens ingeniørerne beslutter, hvad der skal gennemføres. At forbinde en telemetrikilde med en agent betyder ikke i sig selv, at agenten har identificeret den grundlæggende årsag korrekt.

Skalering af indlæsning og forespørgsler hver for sig

Hurtig start med VictoriaStack viser både konfigurationer med én enkelt node og konfigurationer i klynger. Demoen med Docker Compose omfatter en OpenTelemetry-applikation og -indsamler, de tre databaser, Grafana, vmalert og vmauth. Dokumentationen understreger, at dette lokale miljø er en demonstration og ikke en produktionsudrulning.

I klyngemodellen er indlæsnings- og forespørgselskomponenterne tilstandsløse og kan skaleres uafhængigt af hinanden, mens lagerkomponenterne opbevarer dataene. Det adskiller forskellige belastninger: Mere indgående telemetri kan kræve større indlæsningskapacitet, mens flere ingeniører eller agenter, der udfører undersøgelser, kan øge behovet for forespørgsler.

Det er fortsat vigtigt at planlægge lagerkapaciteten. Dokumentationen oplyser, at databaserne gemmer telemetri på lokale filsystemer; S3 eller Google Cloud Storage bruges til sikkerhedskopier og ikke som et forespørgselslag baseret på objektlagring. Den bemærker også, at det er en kompliceret proces at reducere antallet af lagerfragmenter. Disse forhold har betydning, når man vælger en topologi og forudsiger væksten.

En koordineret stak uden at migrere det hele på én gang

VictoriaMetrics præsenterer VictoriaStack på KubeCon + CloudNativeCon North America 2026 med en demonstration af en OTLP-instrumenteret Kubernetes-applikation, der sender sine tre telemetrisignaler til de tilsvarende backends, efterfulgt af et fejlfindingsforløb på tværs af signalerne.

»Agenternes tidsalder vil føre til mere telemetri og større krav til, hvordan vi behandler den,« sagde Roman Khavronenko, medstifter af VictoriaMetrics og teknisk leder, i annonceringen. Han sagde, at VictoriaStack er udviklet med fokus på skalerbarhed og effektivitet, efterhånden som efterspørgslen vokser.

Det praktiske forslag er en gradvis indførelse: Behold et nyttigt indsamlingsøkosystem, tilføj de manglende signaler, og administrer de tjenester, der følger med, efter en mere ensartet model. Værdien af VictoriaStack afhænger af, hvor godt disse dele fungerer sammen, efterhånden som telemetrimængden og behovet for undersøgelser vokser, samtidig med at teams selv kan bestemme, hvor deres data lagres, og hvordan hvert signal skaleres.