VictoriaMetrics lancia VictoriaStack per metriche, log, tracce e risoluzione dei problemi assistita dall’IA

VictoriaMetrics ha presentato VictoriaStack, uno stack di osservabilità open source che riunisce i suoi prodotti per metriche, log e tracciamento distribuito in un modello operativo coordinato. Il lancio mira a offrire ai team di ingegneria un modo per ampliare la copertura della telemetria senza sostituire l’intero ambiente di monitoraggio né obbligare a raccogliere ogni segnale nello stesso database.

VictoriaStack combina VictoriaMetrics per le metriche, VictoriaLogs per i log e VictoriaTraces per le tracce. I team possono adottare i segnali di cui hanno bisogno e aggiungerne altri in seguito, con strumenti di distribuzione condivisi e il supporto a OpenTelemetry che aiutano a integrare i vari componenti.

L’annuncio estende questo modello anche alle operazioni assistite dall’IA. I server ufficiali del Model Context Protocol e le competenze per gli agenti consentono agli assistenti di esaminare la telemetria nell’intero stack, mentre spetta agli ingegneri decidere quali modifiche applicare.

Tre segnali, tre database specializzati

Metriche, log e tracce rispondono a domande operative diverse. Le metriche riassumono il comportamento nel tempo, ad esempio i tassi di richiesta, il numero di errori o il consumo di memoria. I log registrano gli eventi e i relativi dettagli. Le tracce distribuite seguono una richiesta attraverso più servizi, mostrando dove è stato impiegato il tempo e dove si è verificato un problema.

Durante un incidente, un ingegnere potrebbe notare innanzitutto un picco di latenza nelle metriche, circoscrivere il problema a un servizio tramite le tracce e poi esaminare i log per individuare l’errore sottostante. Riunire questi segnali in un flusso di lavoro coerente può abbreviare l’indagine senza rendere identici i requisiti di archiviazione.

La documentazione sull’architettura di VictoriaStack descrive database indipendenti che condividono un modello comune di componenti. Ognuno può essere eseguito come singolo binario oppure in un cluster che separa acquisizione, archiviazione ed esecuzione delle query. Lo stack può utilizzare vmauth come punto di ingresso per l’instradamento e il bilanciamento del carico.

Anche le interfacce per le query restano specializzate: VictoriaMetrics utilizza MetricsQL, compatibile con PromQL; VictoriaLogs utilizza LogsQL; e VictoriaTraces supporta LogsQL, oltre alle API compatibili con Jaeger e Tempo. Il funzionamento coordinato, quindi, non implica l’uso di un unico database o di un linguaggio di query universale.

Tutti e tre i database principali sono disponibili con licenza Apache 2.0. L’azienda offre inoltre funzionalità enterprise e assistenza commerciale, oltre a VictoriaMetrics Cloud, un servizio completamente gestito che supporta tutti e tre i segnali.

OpenTelemetry collega il livello di raccolta

OpenTelemetry offre un approccio comune per strumentare le applicazioni ed esportare la telemetria. Il suo protocollo OTLP è supportato per metriche, log e tracce in VictoriaStack, offrendo ai team un percorso di acquisizione coerente, anche se i dati vengono inviati a backend diversi.

Questa distinzione diventa importante quando un’applicazione passa da pochi servizi a un sistema distribuito. La strumentazione dovrebbe aiutare a descrivere il comportamento dell’applicazione; cambiare la destinazione della telemetria non dovrebbe richiedere di riprogettare il codice di monitoraggio di ogni servizio.

Lo stack supporta anche altri formati di acquisizione, ove opportuno. I team che già raccolgono metriche basate su Prometheus, ad esempio, possono mantenere quell’ecosistema e affiancargli log o tracciamento. La compatibilità dei protocolli riduce il lavoro di migrazione, mentre la scelta dei criteri di conservazione, della capacità e dei modelli di query resta una decisione ingegneristica.

Per le distribuzioni su Kubernetes, VictoriaMetrics indica il proprio operatore e i propri chart Helm come strumenti di gestione più comuni. L’obiettivo è rendere più coerenti le distribuzioni e gli aggiornamenti, mantenendo la possibilità di scalare ciascun segnale in base al carico di lavoro specifico.

Gli agenti IA possono esaminare la telemetria in modo trasversale

VictoriaStack affronta il tema dell’IA in due modi: i sistemi di osservabilità devono gestire la telemetria generata dalle applicazioni basate su agenti, e gli assistenti IA possono aiutare gli ingegneri a interrogare tale telemetria.

La documentazione degli strumenti di IA dell’azienda descrive server MCP distinti per metriche, log e tracce. Questi mettono a disposizione funzionalità strutturate, come l’esecuzione di query sulle serie temporali, l’esplorazione dei campi dei log, l’individuazione di servizi e operazioni e il recupero delle tracce. L’integrazione per le metriche consente inoltre di analizzare la cardinalità, il comportamento delle query e la configurazione degli avvisi.

Il repository delle competenze per gli agenti aggiunge flussi di lavoro riutilizzabili per indagini che coinvolgono più segnali e per altre attività operative correlate. Un assistente può seguire una procedura di risoluzione dei problemi che attraversa diversi segnali, anziché affidarsi a un’unica dashboard o a un messaggio di errore copiato e incollato.

L’annuncio descrive l’accesso in sola lettura per assistenti come Claude Code, Codex, Cursor e agenti sviluppati internamente. Il flusso di lavoro previsto è quindi investigativo: raccogliere prove, collegare i sintomi e proporre una spiegazione, lasciando agli ingegneri la decisione su cosa applicare. Collegare una fonte di telemetria a un agente non dimostra di per sé che l’agente abbia individuato correttamente la causa principale.

Scalare separatamente l’acquisizione e le query

La Guida rapida di VictoriaStack illustra sia le configurazioni a nodo singolo sia quelle in cluster. La demo Docker Compose include un’applicazione e un collector OpenTelemetry, i tre database, Grafana, vmalert e vmauth. La documentazione specifica chiaramente che questo ambiente locale è una dimostrazione, non una distribuzione in produzione.

Nel modello a cluster, i componenti di acquisizione e di interrogazione non mantengono stato e possono essere scalati in modo indipendente, mentre i componenti di archiviazione conservano i dati. In questo modo si separano esigenze diverse: un aumento della telemetria in ingresso può richiedere maggiore capacità di acquisizione, mentre un numero maggiore di ingegneri o agenti che conducono indagini può accrescere la domanda di interrogazioni.

La pianificazione dell’archiviazione resta importante. La documentazione spiega che i database conservano la telemetria nei filesystem locali; S3 o Google Cloud Storage vengono utilizzati per i backup, non come livello di interrogazione basato su storage a oggetti. Segnala inoltre che ridurre il numero di shard di archiviazione è un’operazione complessa. Queste caratteristiche sono importanti per scegliere una topologia e prevedere la crescita.

Uno stack coordinato senza migrare tutto in una volta

VictoriaMetrics presenterà VictoriaStack a KubeCon + CloudNativeCon North America 2026, con una dimostrazione di un’applicazione Kubernetes strumentata con OTLP che invia i suoi tre segnali di telemetria ai backend corrispondenti, seguita da un flusso di lavoro per la risoluzione dei problemi che incrocia i diversi segnali.

«L’era degli agenti porterà più telemetria e maggiori esigenze riguardo a come la elaboriamo», ha dichiarato nell’annuncio Roman Khavronenko, cofondatore di VictoriaMetrics e responsabile del team di ingegneria. Ha aggiunto che VictoriaStack è progettato per offrire scalabilità ed efficienza con l’aumento della domanda.

La proposta pratica punta a un’adozione graduale: mantenere un ecosistema di raccolta utile, introdurre i segnali mancanti e gestire i servizi che ne derivano secondo un modello più uniforme. Il valore di VictoriaStack dipende da quanto bene questi elementi funzionano insieme all’aumentare del volume di telemetria e della domanda di indagini, lasciando al contempo ai team il controllo su dove risiedono i dati e su come viene scalato ciascun segnale.