I collector OpenTelemetry ottengono la gestione centralizzata senza Alloy
I collector OpenTelemetry possono ora essere gestiti centralmente in Grafana Cloud senza passare prima a Grafana Alloy, secondo quanto riferito da Marko Bachvarovski di Grafana. Grafana afferma che il supporto per Open Agent Management Protocol (OpAMP), un protocollo per la gestione remota degli agenti software, è disponibile a livello generale in Fleet Management. La novità estende un flusso di lavoro precedentemente incentrato su Alloy alle distribuzioni upstream supportate di OpenTelemetry Collector, ossia ai pacchetti supportati del software collector sviluppato dalla comunità.
OpenTelemetry, spesso abbreviato in OTel, fornisce strumenti per raccogliere dati di telemetria, ovvero misurazioni e registrazioni utilizzate per comprendere il comportamento del software. I suoi collector ricevono, elaborano e inoltrano queste informazioni. Alloy è la distribuzione di OpenTelemetry Collector realizzata da Grafana. Per i team che utilizzano già altre distribuzioni supportate, l'annuncio significa che la gestione centralizzata non deve necessariamente iniziare con la sostituzione del software collector, la riscrittura della configurazione nel formato di Alloy o la modifica degli ambienti in cui vengono eseguiti i collector.
Il problema operativo di fondo va oltre il singolo prodotto: con l'espansione di un'installazione di monitoraggio, i team hanno bisogno di regole comuni senza perdere le impostazioni specifiche dei singoli servizi o ambienti. Devono inoltre sapere se i collector stessi funzionano correttamente. L'implementazione di Grafana riunisce l'assegnazione mirata delle configurazioni e lo stato di salute dei collector in un unico flusso di gestione, mantenendo il formato YAML di OTel, il formato di testo strutturato utilizzato per descrivere le impostazioni dei collector.
Configurazione condivisa senza carichi di lavoro identici
Fleet Management consente ai team di definire pipeline di telemetria, sequenze di passaggi di raccolta ed elaborazione, nel formato YAML di OTel e di assegnarle ai collector che corrispondono ai criteri stabiliti. Una regola di elaborazione condivisa può quindi essere aggiornata centralmente, mentre la raccolta aggiuntiva resta limitata ai team, ai servizi o agli ambienti che ne hanno bisogno. Grafana mostra anche un test di configurazione che supera una verifica della sintassi: questa controlla la struttura della configurazione, senza però dimostrarne il comportamento con ogni possibile carico di lavoro.
Per i team che utilizzano l'infrastructure as code, la pratica di gestire l'infrastruttura tramite file di configurazione archiviati, Grafana descrive il supporto per Terraform, uno strumento che applica tali file. Attraverso questo flusso di lavoro, i team possono creare pipeline basate su YAML e registrare i collector attivi. La configurazione e la registrazione possono quindi diventare processi ripetibili, tracciati tramite il controllo di versione, un sistema che registra le modifiche apportate ai file nel tempo.
La registrazione configura anche l'automonitoraggio dei collector. Secondo Grafana, gli OTel Collector registrati inviano automaticamente a Grafana Cloud metriche, ossia misurazioni numeriche; log, ossia eventi registrati; e tracce, ossia registrazioni delle richieste che attraversano il software. Questo vale indipendentemente dal sistema operativo o dalla modalità di distribuzione. I collector eseguiti al di fuori di Kubernetes, un sistema per gestire applicazioni confezionate in container, ricevono anche una pipeline di monitoraggio dell'host, per aiutare i team a esaminare la macchina sottostante insieme al collector.
Queste pipeline di monitoraggio non impongono destinazioni fisse né criteri di raccolta obbligatori. Grafana afferma che i team possono modificarle, disabilitarle o reindirizzarne i dati verso un altro backend, il sistema ricevente che archivia o analizza i dati di telemetria. Questa distinzione è importante quando si verifica che cosa invia un collector registrato e dove vengono inviati i dati.
Perché combinare le configurazioni richiede più di una verifica della sintassi
Un collector può ricevere diverse pipeline di Fleet Management e, allo stesso tempo, mantenere la configurazione locale. Le impostazioni risultanti devono funzionare insieme. Bachvarovski spiega che Alloy definisce i componenti, i singoli elementi di raccolta o elaborazione, in blocchi collegati tramite riferimenti ai rispettivi output. Gli OTel Collector definiscono invece i componenti al livello principale della configurazione e li richiamano da una o più pipeline di telemetria.
Esiste una seconda differenza importante: Alloy mantiene separate le configurazioni locali e remote, mentre gli OTel Collector le combinano in un'unica configurazione effettiva. Se più fonti definiscono un componente con lo stesso nome, una definizione può sovrascriverne un'altra e alterare il comportamento della pipeline. Le pipeline create indipendentemente possono quindi entrare in conflitto anche quando i rispettivi autori avevano previsto comportamenti diversi per i componenti con nomi identici.
Grafana affronta questo problema con un algoritmo di unione, una procedura per combinare le configurazioni, che esegue una post-elaborazione delle impostazioni remote. Aggiunge il nome della pipeline di Fleet Management agli identificatori delle pipeline e dei componenti OTel, quindi aggiorna i riferimenti a tali identificatori. Quando i componenti hanno sia lo stesso tipo sia la stessa configurazione, elimina i duplicati, mantenendo una definizione condivisa anziché copie superflue. Grafana mostra inoltre una vista di sola lettura della configurazione remota associata a un collector.
Questo meccanismo mira a consentire ai team di mantenere le pipeline remote come elementi riutilizzabili, anziché creare manualmente un file di configurazione distinto per ogni possibile combinazione. La lezione applicabile anche ad altri contesti è che la configurazione centralizzata richiede regole esplicite per nomi, riferimenti e unione. Accettare soltanto YAML valido non chiarisce come interagiranno configurazioni scritte separatamente.
Separare la raccolta locale dall'elaborazione condivisa
Fleet Management supporta diversi modelli di distribuzione. Un'opzione descritta da Grafana per insiemi di agenti numerosi o eterogenei è il modello gateway, che suddivide i collector in due livelli. I collector periferici, vicini alle applicazioni, raccolgono i dati di telemetria da servizi, pod Kubernetes (gruppi di container applicativi) e nodi (le macchine che li eseguono). Li inoltrano ai collector gateway, che applicano un'elaborazione condivisa prima di inviarli a un backend.
A livello di gateway, i team possono aggiungere alle metriche etichette che identificano il team, filtrare i log o applicare il tail sampling alle tracce, scegliendo quali registrazioni delle richieste conservare dopo averne osservato lo svolgimento. Mantenere questi criteri sul gateway evita di inserire la stessa logica di elaborazione in ogni collector periferico. Fleet Management può assegnare le pipeline di raccolta ai collector periferici e quelle di elaborazione ai gateway, gestendo entrambi centralmente senza confonderne le responsabilità.
I due livelli non devono necessariamente eseguire lo stesso software. Grafana afferma che gli agenti esistenti, come Fluent Bit o Telegraf, possono rimanere alla periferia e inoltrare i dati di telemetria ai gateway OTel tramite protocolli compatibili. Fleet Management gestisce quindi i gateway OTel supportati e le relative impostazioni di elaborazione condivisa. Si tratta di un percorso graduale per adottare OpenTelemetry, non dell'affermazione che ogni agente esistente diventi direttamente gestibile tramite Fleet Management.
I gateway sono facoltativi: anche i collector supportati che inviano direttamente a un backend possono utilizzare il flusso di lavoro basato su OpAMP. Grafana suggerisce di iniziare registrando un collector, assegnandogli una pipeline YAML e verificandone lo stato di salute prima di estendere l'approccio ai diversi ambienti. L'annuncio non elenca tutte le distribuzioni supportate, quindi la compatibilità va verificata anziché data per scontata.
Per le aziende che stanno riesaminando il modo in cui proteggono l'infrastruttura monitorata, i servizi gestiti per il cloud e l'infrastruttura dati di AEU Data offrono un punto di riferimento pertinente per valutare il monitoraggio e il supporto operativo insieme alla gestione dei collector. La decisione centrale resta pratica: preservare il modello di raccolta adatto al carico di lavoro, comprendere come si comportano le impostazioni combinate e mantenere il controllo sui dati di monitoraggio inviati da quei collector.