La raccolta, manipolazione e conservazione di log in ambienti Kubernetes può essere complessa, soprattutto a causa dell’eterogeneità dei servizi che li producono. In particolare, la continua aggiunta di nuovi servizi o modifica di servizi legacy già esistenti, con formati di log sempre diversi che richiedono  una preparazione diversa prima di essere archiviati, rende complessa la gestione delle configurazioni dell’infrastruttura di gestione del logging.

In ambito Kubernetes, il Logging Operator aiuta proprio in questo: permette di descrivere e mantenere tale infrastruttura in maniera semplificata con una serie di descrittori YAML, come mostro in questo articolo con un caso d’uso che ho presentato il 19 maggio a Cloud Native Days Italy 2026.

Prima del Logging Operator, o come soffrire a ogni cambio di configurazione

L’ambiente oggetto del caso d’uso presenta molte tipologie di servizi: alcuni che loggavano su stdout, altri che loggavano su file, ognuno con formati diversi. Prima dell’introduzione del Logging Operator la conservazione dei log avveniva su due supporti diversi: un volume accessibile dagli sviluppatori tramite una VM per i log emessi su file, e lo strumento open source Loki per i log emessi su stdout e raccolti da Grafana Alloy.

Questa infrastruttura presentava molteplici criticità: i log su file non erano facilmente esplorabili, mentre ogni volta che era necessario aggiungere regole di parsing per i log su stdout occorreva mettere mano alla configurazione di Alloy. Dato che l’obiettivo era di migrare un po’ per volta ogni servizio alla modalità di logging su stdout, questo avrebbe implicato frequenti modifiche alla configurazione di Alloy.

Per semplificare queste operazioni si è scelto di introdurre l’uso del Logging Operator.

Dopo il Logging Operator, o come gestire in maniera modulare la configurazione di scraping

L’introduzione del Logging Operator e di un’apposita Chart Helm per deployare le sue risorse ha permesso di semplificare la gestione della configurazione della raccolta dei log.

• I componenti base dell’infrastruttura di logging, ovvero Fluentbit come scraper e Fluentd come aggregatore, sono deployati al momento della configurazione del cluster installando l’apposita Chart.
• Ogni volta che è necessario introdurre una nuova pipeline di log, ovvero una nuova sequenza di trasformazioni da applicare a uno specifico insieme di log, si installa un’ulteriore release della Chart per creare risorse di tipo ClusterFlow e ClusterOutput, che poi l’operator usa per definire la configurazione finale di Fluentbit e Fluentd.

Rispetto alla situazione senza Logging Operator, ci sono diversi vantaggi come:

• Facilità di configurazione, e quindi facilità di manutenzione: invece di dover definire la configurazione in un blocco unico, si possono configurare le singole pipeline di log. L’operator poi produce la configurazione completa a partire dai descrittori Kubernetes deployati con la Chart, che offre un’interfaccia semplificata per definirli.
• Divisione delle responsabilità: team diversi possono definire pipeline di log personalizzate in maniera indipendente, installando multiple volte la chart di configurazione, senza doversi coordinare per modificare lo stesso file di configurazione.
• Condivisione delle configurazioni: pipeline di log diverse possono utilizzare componenti comuni, ad esempio la definizione di dove Fluentd deve inviare i log per la conservazione a lungo termine, evitando ripetizioni.

L’uso del Logging Operator va a semplificare la migrazione dei servizi dal logging su file al logging su stdout, che una volta completata porterebbe ad avere un unico standard condiviso di logging e una migliore modalità di esplorazione dei log.

Bello il Logging Operator, ma…

Nonostante l’infrastruttura di logging sia ora migliore di prima, la migrazione della modalità di logging dei servizi non è ancora stata completata, e procede molto lentamente, a causa di problemi organizzativi e timori sulla possibilità di perdere log modificando la configurazione degli applicativi. Questo, nonostante la soddisfazione dei team che hanno già migrato le loro applicazioni e possono consultare i propri log in maniera molto più semplice ed efficace.

Quindi possiamo dire che, pur con alcune difficoltà e pur essendo migliorabile sotto certi aspetti, in questa situazione l’introduzione del Logging Operator è stata la scelta giusta per modernizzare la gestione dei log. Una scelta che offre una soluzione standardizzabile, scalabile, ripetibile ed efficace, integrabile in una piattaforma di monitoraggio più ampia che permette a chi sviluppa di avere una visione più completa possibile dello stato delle proprie applicazioni.