VictoriaMetrics lanserer VictoriaStack for måledata, logger, sporingsdata og AI-assistert feilsøking

VictoriaMetrics har introdusert VictoriaStack, en åpen observabilitetsplattform som samler selskapets produkter for måledata, logger og distribuert sporing i en samordnet driftsmodell. Lanseringen skal gi teknologiteam en måte å utvide telemetridekningen på uten å erstatte hele overvåkingsmiljøet eller tvinge alle signalene inn i samme database.

VictoriaStack kombinerer VictoriaMetrics for måledata, VictoriaLogs for logger og VictoriaTraces for sporingsdata. Team kan ta i bruk signalene de trenger og legge til flere senere. Felles verktøy for utrulling og støtte for OpenTelemetry bidrar til å koble sammen komponentene.

Kunngjøringen utvider også denne modellen til AI-assistert drift. Offisielle Model Context Protocol-servere og agentferdigheter gjør det mulig for assistenter å undersøke telemetri på tvers av plattformen, mens ingeniørene fortsatt har ansvaret for å avgjøre hvilke endringer som skal gjennomføres.

Tre signaler, tre spesialiserte databaser

Måledata, logger og sporingsdata besvarer ulike operative spørsmål. Måledata oppsummerer utviklingen over tid, for eksempel antall forespørsler, feil eller minneforbruk. Logger registrerer hendelser og detaljene rundt dem. Distribuert sporing følger en forespørsel gjennom flere tjenester og viser hvor tiden gikk med, og hvor en feil oppsto.

Under en hendelse kan en ingeniør først oppdage en økning i latenstid i måledataene, avgrense problemet til en tjeneste ved hjelp av sporingsdata og deretter undersøke loggene for å finne den underliggende feilen. Når signalene inngår i en samordnet arbeidsflyt, kan undersøkelsen gå raskere uten at lagringsbehovene deres må være identiske.

VictoriaStacks arkitekturdokumentasjon beskriver uavhengige databaser som deler en felles komponentmodell. Hver database kan kjøres som én binærfil eller som en klynge der inntak, lagring og spørringer er fordelt på ulike deler. Plattformen kan bruke vmauth som inngangspunkt for ruting og lastbalansering.

Spørringsgrensesnittene er fortsatt spesialiserte: VictoriaMetrics bruker PromQL-kompatible MetricsQL, VictoriaLogs bruker LogsQL, og VictoriaTraces støtter LogsQL i tillegg til API-er som er kompatible med Jaeger og Tempo. Samordnet drift betyr derfor ikke at alt bruker én database eller ett universelt spørringsspråk.

Alle de tre kjernedatabasene er tilgjengelige under Apache 2.0-lisensen. Selskapet tilbyr også bedriftsfunksjoner og kommersiell støtte, samt den fullstendig administrerte tjenesten VictoriaMetrics Cloud, som støtter alle de tre signaltypene.

OpenTelemetry knytter sammen innsamlingslaget

OpenTelemetry gir en felles metode for å instrumentere applikasjoner og eksportere telemetri. OTLP-protokollen støttes på tvers av VictoriaStacks løsninger for måledata, logger og sporingsdata, slik at team får en ensartet vei for datainntak selv om dataene lagres i ulike bakender.

Dette skillet blir viktig når en applikasjon vokser fra noen få tjenester til et distribuert system. Instrumenteringen skal bidra til å beskrive hvordan applikasjonen oppfører seg; det å endre hvor telemetrien sendes, bør ikke kreve at overvåkingskoden i hver tjeneste bygges om.

Plattformen støtter også andre formater for datainntak der det er hensiktsmessig. Team som allerede samler inn måledata med Prometheus, kan for eksempel beholde dette økosystemet og samtidig legge til logger eller sporing. Protokollkompatibilitet reduserer arbeidet med migrering, mens valg av oppbevaringstid, kapasitet og spørringsmønstre fortsatt må avgjøres av ingeniørene.

For Kubernetes-utrullinger viser VictoriaMetrics til Operator og Helm-diagrammer som de vanligste verktøyene for administrasjon. Målet er å gjøre utrullinger og oppgraderinger mer ensartede, samtidig som hvert signal fortsatt kan skaleres etter sin egen arbeidsbelastning.

AI-agenter kan undersøke telemetri på tvers av systemet

VictoriaStack tilnærmer seg AI fra to hold: Observabilitetssystemer må kunne håndtere telemetri som genereres av agentbaserte applikasjoner, og AI-assistenter kan hjelpe ingeniører med å undersøke denne telemetrien.

Selskapets dokumentasjon om AI-verktøy beskriver separate MCP-servere for måledata, logger og sporingsdata. De tilbyr strukturerte funksjoner som å spørre etter tidsserier, utforske loggfelt, finne tjenester og operasjoner samt hente sporingsdata. Integrasjonen for måledata støtter også undersøkelser av kardinalitet, spørringsatferd og konfigurasjon av varsler.

Selskapets arkiv med agentferdigheter inneholder gjenbrukbare arbeidsflyter for undersøkelser på tvers av flere signaler og andre relaterte driftsoppgaver. En assistent kan følge en feilsøkingsprosess på tvers av signalene i stedet for å basere seg på ett enkelt kontrollpanel eller en innlimt feilmelding.

Kunngjøringen beskriver skrivebeskyttet tilgang for assistenter, blant annet Claude Code, Codex, Cursor og interne agenter. Den tiltenkte arbeidsflyten er dermed undersøkende: samle bevis, se symptomene i sammenheng og foreslå en forklaring, mens ingeniørene avgjør hva som skal gjennomføres. At en telemetrikilde kobles til en agent, betyr ikke i seg selv at agenten har identifisert den egentlige årsaken korrekt.

Skalere datainntak og spørringer hver for seg

Hurtigstarten for VictoriaStack viser både konfigurasjoner med én node og konfigurasjoner i klynger. Demoen med Docker Compose omfatter en OpenTelemetry-applikasjon og en collector, de tre databasene, Grafana, vmalert og vmauth. Dokumentasjonen presiserer at dette lokale miljøet er ment som en demonstrasjon, ikke som en produksjonsdistribusjon.

I klyngemodellen er komponentene for datainntak og spørringer tilstandsløse og kan skaleres uavhengig av hverandre, mens lagringskomponentene opprettholder dataene. Dermed skilles ulike typer belastning fra hverandre: Mer innkommende telemetri kan kreve større kapasitet for datainntak, mens flere ingeniører eller agenter som gjennomfører undersøkelser, kan øke etterspørselen etter spørringer.

Det er fortsatt viktig å planlegge lagringen. Dokumentasjonen opplyser at databasene lagrer telemetri på lokale filsystemer, og at S3 eller Google Cloud Storage brukes til sikkerhetskopier, ikke som et spørringslag for objektlagring. Den påpeker også at det er en kompleks operasjon å redusere antallet lagringssharder. Disse egenskapene er viktige når man skal velge en topologi og anslå veksten.

En koordinert stakk uten å migrere alt på én gang

VictoriaMetrics presenterer VictoriaStack på KubeCon + CloudNativeCon North America 2026 med en demonstrasjon av en Kubernetes-applikasjon instrumentert med OTLP, som sender de tre telemetrisignalene sine til de tilhørende bakendene, etterfulgt av en feilsøkingsflyt på tvers av signalene.

«Agentenes æra vil føre til mer telemetri og større krav til hvordan vi behandler den», sa Roman Khavronenko, medgründer og teknisk leder i VictoriaMetrics, i kunngjøringen. Han sa at VictoriaStack er utviklet med tanke på skalerbarhet og effektivitet etter hvert som etterspørselen øker.

Det praktiske forslaget er å ta løsningen i bruk trinnvis: Behold et nyttig økosystem for innsamling, ta i bruk signalene som mangler, og administrer de resulterende tjenestene etter en mer enhetlig modell. Verdien av VictoriaStack ligger i hvor godt disse delene fungerer sammen når mengden telemetri og behovet for undersøkelser øker, samtidig som teamene beholder kontrollen over hvor dataene lagres, og hvordan hvert signal skaleres.