Loki per la gestione centralizzata dei log nell'hosting

Separare chiaramente Loki, Alloy e Grafana

La gestione centralizzata dei log parte dai sistemi che generano gli eventi: host Linux, server virtuali, container e applicazioni. È lì che vengono creati, ad esempio, i record di journal di systemd, i log di accesso e di errore di Nginx o gli output standard dei container Docker. Grafana Alloy legge tali fonti, le elabora prima dell'invio e le inoltra a Loki. Alloy funge quindi da raccoglitore di dati, non da archivio centrale dei log.

Grafana Loki riceve i dati di log, li raggruppa e li archivia per successive interrogazioni. Un sistema di archiviazione a oggetti può ospitare i dati persistiti. Grafana, dal canto suo, fornisce spesso l’interfaccia per Explore, le dashboard e gli avvisi, ma tecnicamente non fa parte di Loki. Questa separazione facilita una chiara attribuzione delle responsabilità in caso di modifiche, guasti e diritti di accesso.

In un piccolo esempio di hosting, Alloy legge su un VPS il journal di systemd, i file di Nginx e i log dei container. Invia le righe selezionate a Loki; un amministratore le esamina poi in Grafana, invece di dover accedere singolarmente a ciascun host per una prima analisi degli errori. A monte di Loki, un proxy inverso o un livello di identità dovrebbe gestire gli accessi, il TLS, il routing e, se necessario, l’assegnazione dei clienti.

L'aggregazione centralizzata riduce i percorsi di ricerca, ma non sostituisce né l'analisi delle cause né i processi operativi. Protezione dell'accesso deve stabilire chi è autorizzato a consultare quali dati; il principio di minimizzazione dei dati determina, già prima dell’invio, quali campi devono essere rimossi. Anche la definizione di una strategia di backup e ripristino rimane un compito a sé stante: Loki rende reperibili i log esistenti, ma non garantisce di per sé la loro protezione, completezza o conservazione conforme alla normativa.

In pratica, quindi, Loki è utile solo dopo aver effettuato un inventario delle fonti: quali log sono utili per la gestione operativa e la risoluzione degli incidenti, quali contengono informazioni riservate o dati personali e chi ha bisogno di accedervi? Solo queste risposte determinano i filtri, i tempi di conservazione e le autorizzazioni. Centralizzare tutti i log Linux senza prima averli verificati significa semplicemente spostare le informazioni sensibili in un archivio più facilmente consultabile.

Comprendere stream, etichette e LogQL

Loki non organizza le righe in entrata principalmente come indice di testo completo. Le raggruppa in base all’ID del cliente e al loro insieme di etichette in un Flusso insieme. I dati di log veri e propri sono memorizzati in forma compressa in chunk; l'indice associa i set di etichette a questi chunk. Durante una ricerca, Loki restringe quindi innanzitutto gli stream corrispondenti tramite le etichette e carica successivamente i dati interessati per filtrarli ulteriormente o analizzarli.

Le etichette dovrebbero esprimere un contesto duraturo e ben definito: ad esempio env, service e con server stabili host. Negli ambienti containerizzati, possono essere utili anche i cluster, i namespace o le applicazioni. Tuttavia, ogni combinazione univoca costituisce uno stream. Gli ID di richiesta, di utente e di traccia, gli ID dei container variabili o gli indirizzi IP dei client generano un numero molto elevato di valori e pertanto non rientrano solitamente nelle etichette.

Per rare analisi approfondite, tali informazioni dinamiche rimangono nella riga di log e vengono valutate solo al momento della query, ad esempio tramite parsing JSON o Logfmt. I dati di contesto ad alta cardinalità, di uso frequente, possono risultare più adatti come metadati strutturati. È fondamentale verificare il modello di dati su fonti reali prima del lancio, anziché etichettare tutti i campi disponibili senza alcun filtro.

Una query LogQL di sola lettura per gli errori di Nginx potrebbe presentarsi in questo modo. È adatta, ad esempio, a Grafana Explore o LogCLI e presuppone che le etichette selezionate siano state effettivamente assegnate durante la raccolta dei dati.

{env="prod", service="nginx"} |= " 500 "

Il selettore a monte della pipeline riduce inizialmente i flussi di produzione del servizio Nginx; solo |= " 500 " cerca il testo. L'efficacia di una query dipende tuttavia dall'intervallo di tempo, dal volume dei log, dalle latenze di archiviazione e dalla struttura delle etichette. Loki non garantisce quindi un tempo di risposta fisso. Intervalli di tempo ridotti e selettori precisi e stabili costituiscono un punto di partenza sensato per un'analisi graduale.

Quale architettura Loki è più adatta all'hosting

Per un singolo VPS, un laboratorio o piccoli volumi di log, il funzionamento monolitico Spesso è il punto di partenza più intuitivo: un processo Loki raggruppa i componenti necessari. La documentazione indica questa modalità per esperimenti e per piccoli volumi di lettura e scrittura fino a circa 20 GB di log al giorno. Si tratta di una indicazione del produttore per questo ambito di applicazione, non di una garanzia di capacità per ogni struttura di archiviazione, interrogazione o etichettatura.

Se i requisiti di disponibilità aumentano senza che sia necessario scalare in modo mirato i singoli ruoli di Loki, si può prendere in considerazione un’architettura monolitica ad alta disponibilità. Per cluster di grandi dimensioni o ambienti Kubernetes in cui i componenti devono essere scalati separatamente, è prevista la modalità microservizi. Tuttavia, questa granularità non elimina la necessità di pianificazione: aumenta il numero di componenti operativi e, di conseguenza, anche lo sforzo di diagnostica e manutenzione.

La modalità Simple Scalable Deployment non rappresenta una via di mezzo neutrale per le nuove decisioni. Grafana ha contrassegnato SSD come obsoleta e ne ha annunciato la rimozione con Loki 4.0. Chi sta realizzando un sistema oggi dovrebbe quindi valutare un approccio monolitico con un livello di disponibilità adeguato oppure l’utilizzo di microservizi in base alle effettive esigenze di scalabilità, anziché pianificare a lungo termine un’architettura di transizione.

Per facilitare la decisione, non contano solo i gigabyte generati quotidianamente. Sono rilevanti anche i picchi di scrittura, il numero e la cardinalità degli stream, la necessaria separazione dei mandanti, la conservazione dei dati e le competenze del team in materia di Kubernetes e componenti distribuiti. I progetti con distribuzione globale richiedono comunque una chiara distinzione tra servizi operativi centralizzati e componenti edge; a questo proposito è utile anche l’articolo su Web hosting per il rendering edge e la consegna decentralizzata.

Inizia in piccolo, se le fonti di log, le etichette e gli accessi non sono ancora definiti in modo stabile. Un cambiamento di architettura dovrebbe essere motivato da esigenze concrete, come ad esempio una scalabilità mirata o una maggiore disponibilità, e non da una generica aspettativa di crescita futura. In questo modo, lo sforzo richiesto per Gestione dei log rispetto ai vantaggi offerti dalla ricerca centralizzata e dalla gestione degli incidenti.

Raccogliere i log di Linux in modo sicuro con Alloy

Prima della configurazione è necessario effettuare un inventario delle fonti: quali log sono effettivamente utili per il funzionamento e la gestione degli incidenti? Su un server web Linux si tratta spesso del journal di systemd, dei log di accesso e di errore di Nginx, di PHP-FPM, degli eventi SSH e dei cron job. Nel caso dei container, si aggiungono gli output del runtime e i log specifici dell’applicazione. Altrettanto importante è la verifica preliminare di password, chiavi API, ID di sessione e dati personali; tali contenuti non devono essere trasmessi a livello centrale senza essere prima controllati.

Per le nuove installazioni è Grafana Alloy Il metodo supportato per la raccolta e l'inoltro dei dati. Promtail non dovrebbe più essere considerato lo standard a tal fine: il suo ciclo di vita è terminato il 2 marzo 2026 e la documentazione rimanda ad Alloy o a un altro client supportato per le migrazioni e le nuove configurazioni. Un'installazione Promtail esistente richiede quindi una migrazione pianificata anziché un aggiornamento automatico.

Lo schema di configurazione rimane semplice: una fonte legge i file, il journal o i log dei container; un’elaborazione opzionale può scartare le righe indesiderate o elaborare i campi; successivamente, trasferisce loki.write i dati a Loki. Alloy fornisce componenti, tra l’altro, per file, journal di systemd, Docker, Kubernetes, Syslog ed eventi di Windows. La scelta della fonte dipende dal luogo in cui l’applicazione invia i propri eventi in modo affidabile.

Un modello non è ancora una configurazione pronta per la produzione. I diritti sui file devono garantire al processo Alloy solo l’accesso in lettura necessario; l’accesso al journal, l’indirizzo di destinazione, la verifica dei certificati, il TLS, il buffering in caso di interruzioni di rete e la gestione dei guasti devono essere verificati in base alla specifica installazione. I dati di accesso e le informazioni sui clienti non devono essere inclusi nei file di esempio condivisi. Inizia con poche fonti, controlla il contenuto e il volume e solo successivamente amplia la raccolta.

Il filtraggio a livello di agente non riduce la responsabilità relativa alla fonte né sostituisce un sistema di autorizzazioni. Tuttavia, impedisce che output di debug noti o informazioni riservate chiaramente identificate entrino a far parte dell’archivio centrale. Per i contenuti necessari dal punto di vista tecnico, dovrebbe essere tracciabile quale servizio li invia, chi è autorizzato a leggerli in seguito e per quanto tempo sono necessari.

Concetto del marchio e pianificazione prima del lancio

A Concetto del marchio definisce in quale contesto stabile è possibile reperire i log. Per più host e ambienti sono adatti, ad esempio env, cluster, namespace, app, service e, se il riferimento è utile a lungo termine, un nome host. I valori devono essere limitati e prevedibili. Ogni insieme distinto di etichette costituisce un flusso a sé stante; pertanto, il modello influisce direttamente sull’inserimento, sull’indicizzazione e sulle successive interrogazioni.

Gli ID di richiesta, di traccia e di utente, gli indirizzi IP dei client e gli ID dinamici dei container non sono invece etichette adeguate. Generano troppi valori diversi e quindi molti piccoli flussi. Le informazioni ad alto cardinale possono essere eventualmente incluse come metadati strutturati. Per un'analisi occasionale, spesso è più sensato recuperare il contenuto del log solo al momento della query con json, logfmt, pattern oppure regexp da analizzare.

La tabella non fornisce una previsione dello spazio di archiviazione, ma una base decisionale. In particolare, la conservazione dei dati fa parte del piano, poiché non può essere dedotta dal volume dei log: gli obblighi di conservazione previsti dalla normativa, le esigenze di sicurezza e le direttive di cancellazione possono differire tra loro. Anche la ripristinabilità costituisce un requisito a sé stante; la cancellazione automatica dei log scaduti non sostituisce un piano di backup o di ripristino.

Un primo standard praticabile potrebbe essere, ad esempio, env, service e host da utilizzare per i server web classici; le piattaforme di container sono un’integrazione solo se cluster e namespace, se questi vengono effettivamente utilizzati in modo selettivo durante la ricerca degli errori. Lo schema dovrebbe essere concordato con gli sviluppatori e il personale operativo. Etichette aggiunte in un secondo momento e non uniformi rendono più difficile il confronto tra i diversi ambienti e rendono la ricerca centralizzata meno affidabile.

Nella fase di progettazione non conta solo ciò che è tecnicamente rilevabile, ma anche la ripartizione delle responsabilità. Un team dovrebbe essere responsabile delle fonti e dei filtri, mentre un altro, se necessario, dello storage e dell’accesso. In questo modo risulta chiaro se un campo mancante nel formato di log debba essere aggiunto, trattato come metadati strutturati o, al contrario, non raccolto intenzionalmente.

Proteggere in modo efficace i clienti e gli accessi

Loki è in grado di elaborare i dati di log in modo multi-cliente. Se è attivata la separazione dei clienti, Loki richiede l'intestazione per ogni richiesta X-Scope-OrgID. Tuttavia, questa intestazione non costituisce né un’autenticazione né una prova di autorizzazione: altrimenti un client potrebbe determinarne autonomamente il valore. Loki non include un livello di autenticazione completo; la protezione e l’assegnazione obbligatoria devono precederlo.

Un flusso di lavoro sicuro inizia dal reverse proxy o dal livello di identità affidabile. Dopo l’autenticazione riuscita, questo livello identifica l’organizzazione autorizzata, imposta l’ID cliente lato server, impone l’uso del protocollo TLS e inoltra a Loki solo le richieste consentite. Gli endpoint Loki diretti, accessibili dalla rete, aggirerebbero questo controllo. Anche gli accessi in scrittura da parte degli agenti richiedono un’identità chiaramente delimitata e un canale di trasmissione protetto.

Il modello di autorizzazione stabilisce chi è autorizzato a leggere o inserire i log. Esso non sostituisce né il filtraggio delle informazioni riservate né la verifica della protezione dei dati: token, ID di sessione e dati personali possono rappresentare un problema anche all’interno di un mandante correttamente assegnato. La minimizzazione dei dati deve quindi essere applicata già alla fonte e durante il trattamento, mentre i diritti limitano il volume residuo in base alle mansioni e ai mandanti.

Nelle architetture di hosting distribuite, è utile considerare il punto di accesso come un confine di sicurezza a sé stante. L'articolo su l'hosting decentralizzato e le relative questioni architetturali spiega perché i componenti distribuiti non eliminano la responsabilità centrale in materia di identità e accesso ai dati. Per Loki ciò significa, in concreto, che ogni inoltro deve essere attribuibile in modo tracciabile a un’istanza affidabile e a una regola di client predefinita.

I controlli periodici non dovrebbero quindi limitarsi alle dashboard. Verifica se il proxy rifiuta gli accessi anonimi, se un'intestazione client predefinita possa essere sovrascritta dal client e se gli account di scrittura raggiungano solo le destinazioni previste. Tali controlli non garantiscono una sicurezza totale, ma individuano tempestivamente le tipiche vulnerabilità tra login, routing e archiviazione dei log.

Gestire in modo controllato la conservazione e l'archiviazione

I log centrali non dovrebbero essere conservati semplicemente finché c'è spazio nella memoria oggetto. I Mantenimento deve essere conforme agli obblighi di conservazione previsti dalla legge, dai contratti e dall’azienda – e deve inoltre tenere conto del momento a partire dal quale i dati non sono più utili ai fini dell’analisi degli errori. Senza l’attivazione della conservazione, secondo la documentazione i log inviati a Loki vengono conservati a tempo indeterminato. Ciò può comportare un aumento dei costi, dei rischi per la protezione dei dati e dell’entità di un eventuale ripristino successivo.

Nel caso di TSDB e BoltDB-Shipper, il Compactor applica i periodi di cancellazione configurati. Dovrebbe essere eseguito come singola istanza e disporre di una directory di lavoro persistente, in modo che il suo lavoro non vada perso in modo incompleto in caso di riavvio. La memoria oggetti contiene sia i log chunk che i dati di indice; la sua progettazione rientra quindi nel concetto operativo e non solo nella pianificazione della capacità.

Può essere opportuno applicare scadenze diverse a seconda del flusso di log, ad esempio quando gli eventi di sicurezza devono essere conservati più a lungo rispetto agli output di debug dettagliati. Tali regole relative ai flussi richiedono una conservazione di almeno 24 ore e funzionano esclusivamente con selettori di etichette. Non sono previsti filtri basati sul contenuto né espressioni LogQL arbitrarie. Pertanto, le etichette devono già rappresentare in modo affidabile il contesto tecnico prima che le regole di conservazione possano basarsi su di esse.

Avviso: una regola di ciclo di vita generica applicata all’intero bucket di archiviazione può rimuovere oggetti relativi agli indici o allo stato dei cluster e compromettere le query. È preferibile adottare un approccio mirato alla cancellazione che tenga conto della conservazione dei dati in Loki, delle classi di archiviazione e di bucket o prefissi separati. Inoltre, la conservazione dei dati non sostituisce il backup: essa determina la cancellazione pianificata dei dati di log, mentre i requisiti di ripristino stabiliscono quali configurazioni, percorsi di accesso ed eventualmente dati di archiviazione debbano essere disponibili in caso di guasto.

Rilevare le onde di errore e verificare eventuali problemi di registrazione

In Grafana Explore è possibile analizzare gli eventi di più host in un intervallo di tempo comune. Ciò semplifica la procedura in caso di incidente: invece di accedere uno dopo l’altro ai server web, l’analisi può essere inizialmente circoscritta in base all’ambiente e al servizio. Una ricerca centralizzata mostra tuttavia le correlazioni, non automaticamente la causa; metriche, tracce, distribuzioni e stato dell’applicazione rimangono elementi complementari importanti per la diagnosi.

In caso di un'ondata di errori, LogQL può ricavare una metrica dalle righe pertinenti. La seguente query, ad esempio, conta le righe Nginx con stato HTTP 500 come frequenza su un intervallo di cinque minuti. Essa costituisce una base per un'analisi o un avviso, ma non fornisce indicazioni su quale valore sia critico in ciascuna applicazione.

sum(rate({env="prod", service="nginx"} |= " 500 " [5m]))

Un modo sensato Soglia di allerta deriva dal normale tasso di errore, dal comportamento dell’applicazione e dai segnali di monitoraggio disponibili. Un singolo errore 500 può essere valutato in modo diverso se si verifica in una funzione amministrativa utilizzata raramente rispetto a quanto avviene durante il checkout. Verifica quindi innanzitutto i modelli storici e assegna l’allarme a un team di responsabilità ben definito prima che venga escalato in ambiente di produzione.

Se Loki restituisce il codice 429 durante la scrittura, non si dovrebbero aumentare i limiti d’istinto. Occorre innanzitutto chiarire se un servizio generi un numero insolito di righe, se un ciclo ripeta errori o se le etichette dinamiche generino un gran numero di piccoli flussi. Loki limita la registrazione a livello globale e per singolo flusso per proteggere la piattaforma. Solo dopo questa verifica è possibile decidere se siano necessari filtri, correzioni delle etichette o un adeguamento motivato dei limiti.

Utilizzare Loki in modo adeguato e responsabile

Per un singolo VPS con Nginx, systemd e pochi container, Loki in modalità monolitica può fornire una ricerca centralizzata gestibile, a condizione che le fonti dei log, lo spazio di archiviazione e gli accessi siano chiaramente definiti. La documentazione attribuisce questa modalità a scenari sperimentali e a volumi di lettura e scrittura ridotti; circa 20 GB di log al giorno rappresentano un valore indicativo fornito dal produttore, non una garanzia di capacità per ogni struttura di archiviazione, interrogazione o etichettatura.

Diversi server web Linux traggono particolare vantaggio da una timeline comune per gli eventi web, di log e delle applicazioni. Nelle implementazioni basate su container, un modello di etichette stabile per l’ambiente e il servizio determina se questa ricerca rimane gestibile. Ambienti Kubernetes di grandi dimensioni o ruoli che devono essere scalati in modo mirato e separato possono giustificare la modalità microservizi, ma comportano un carico di lavoro significativamente maggiore in termini di gestione operativa e analisi degli errori. Per i nuovi progetti, SSD non è un’opzione standard a lungo termine, poiché questa modalità è contrassegnata come obsoleta.

Una piattaforma multi-tenant richiede inoltre una catena di accesso affidabile. Loki separa le richieste tramite l’identificativo del tenant, ma non fornisce un livello di autenticazione completo. Un proxy affidabile o un livello di identità deve autenticare gli accessi, imporre l’uso del protocollo TLS e impostare la mappatura lato server. Anche un agente supportato fa parte dei requisiti fondamentali: Promtail non è più supportato; per le nuove installazioni, ad esempio, la soluzione prevista è Grafana Alloy.

• Singolo VPS: definire l'inventario delle fonti, i filtri per le informazioni riservate e una politica di conservazione semplice e verificabile prima del lancio.
• Host multipli: concordare etichette stabili per l’ambiente e il servizio, in modo che la ricerca centralizzata riduca effettivamente i percorsi degli incidenti.
• Piattaforma container: non utilizzare gli ID dinamici come etichette; monitorare costantemente il numero di stream e il comportamento di registrazione.
• Funzionamento multi-cliente: implementare l'autenticazione, l'assegnazione dei clienti lato server e le autorizzazioni prima della condivisione degli endpoint Loki.
• Qualsiasi ambiente: documentare i requisiti di ripristino e verificare regolarmente la configurazione, il modello di archiviazione e i termini di cancellazione.

In assenza di responsabili delle fonti di log, di una politica sui contenuti sensibili o di chiari obiettivi di ripristino, occorre innanzitutto definire questi Principi di funzionamento deve essere chiarito. Loki è in grado di aggregare i log e renderli ricercabili, ma non sostituisce né la minimizzazione dei dati né i backup, né il controllo degli accessi né un’analisi tecnica delle cause. Il vantaggio si concretizza solo quando la tecnologia, le responsabilità e la conservazione dei dati vengono pianificate congiuntamente.