In che modo l’aggregazione delle metriche è diversa dall’aggregazione dei log? I log non possono includere metriche? I sistemi di aggregazione dei log non possono fare le stesse cose dei sistemi di aggregazione delle metriche?

Queste sono domande che sento spesso. Ho anche visto venditori lanciare il loro sistema di aggregazione dei log come la soluzione a tutti i problemi di osservabilità. L’aggregazione dei log è uno strumento prezioso, ma normalmente non è un buon strumento per i dati in serie temporali.

Un paio di caratteristiche preziose in un sistema di aggregazione di metriche in serie temporali sono l’intervallo regolare e il sistema di archiviazione personalizzato appositamente per i dati in serie temporali. L’intervallo regolare permette all’utente di ricavare risultati matematici reali in modo coerente. Se un sistema di aggregazione di log sta raccogliendo metriche in un intervallo regolare, può potenzialmente funzionare allo stesso modo. Tuttavia, il sistema di archiviazione non è ottimizzato per i tipi di query che sono tipici in un sistema di aggregazione di metriche. Queste query richiederanno più risorse e tempo per essere elaborate utilizzando i sistemi di archiviazione che si trovano negli strumenti di aggregazione dei log.

Quindi, sappiamo che un sistema di aggregazione dei log probabilmente non è adatto ai dati in serie temporali, ma per cosa è buono? Un sistema di aggregazione di log è un ottimo posto per raccogliere dati di eventi. Queste sono attività irregolari che sono significative. Un esempio potrebbero essere i log di accesso per un servizio web. Questi sono significativi perché vogliamo sapere cosa sta accedendo ai nostri sistemi e quando. Un altro esempio potrebbe essere una condizione di errore di un’applicazione – perché non è una condizione di funzionamento normale, potrebbe essere preziosa durante la risoluzione dei problemi.

Una manciata di regole per la registrazione:

• DO includere un timestamp
• DO formattare in JSON
• NON registrare eventi insignificanti
• DO registrare tutti gli errori dell’applicazione
• PURE registrare gli avvertimenti
• DO attivare la registrazione
• DO scrivere messaggi in una forma leggibile all’uomoleggibile dall’uomo
• NON registrare dati informativi in produzione
• NON registrare nulla che un umano non possa leggere o a cui non possa reagire

Costi del cloud

Quando si studiano strumenti di aggregazione dei log, il cloud potrebbe sembrare un’opzione attraente. Tuttavia, può comportare costi significativi. I log rappresentano un sacco di dati quando vengono aggregati su centinaia o migliaia di host e applicazioni. L’ingestione, l’archiviazione e il recupero di tali dati sono costosi nei sistemi basati sul cloud.

Come punto di riferimento di un sistema reale, una raccolta di circa 500 nodi con alcune centinaia di applicazioni comporta 200GB di dati di log al giorno. C’è probabilmente un margine di miglioramento in quel sistema, ma anche riducendolo della metà si arriva a costare quasi 10.000 dollari al mese in molte offerte SaaS. Questo spesso include una conservazione di soli 30 giorni, che non è molto lungo se si vuole guardare i dati di tendenza anno dopo anno.

Questo non è per scoraggiare l’uso di questi sistemi, in quanto possono essere molto preziosi, soprattutto per le piccole organizzazioni. Lo scopo è quello di sottolineare che ci potrebbero essere costi significativi, e può essere scoraggiante quando vengono realizzati. Il resto di questo articolo si concentrerà sulle soluzioni open source e commerciali che sono self-hosted.

Opzioni di strumenti

ELK

ELK, abbreviazione di Elasticsearch, Logstash, e Kibana, è lo strumento di aggregazione di log open source più popolare sul mercato. È usato da Netflix, Facebook, Microsoft, LinkedIn e Cisco. I tre componenti sono tutti sviluppati e mantenuti da Elastic. Elasticsearch è essenzialmente un NoSQL, implementazione del motore di ricerca Lucene. Logstash è un sistema di pipeline di log che può ingerire i dati, trasformarli e caricarli in un negozio come Elasticsearch. Kibana è uno strato di visualizzazione sopra Elasticsearch.

Alcuni anni fa sono stati introdotti i Beats. I Beats sono raccoglitori di dati. Semplificano il processo di spedizione dei dati a Logstash. Invece di dover capire la sintassi corretta di ogni tipo di log, un utente può installare un Beat che esporterà correttamente i log di NGINX o i log del proxy Envoy in modo che possano essere utilizzati efficacemente all’interno di Elasticsearch.

Quando si installa uno stack ELK a livello di produzione, si possono includere alcuni altri pezzi, come Kafka, Redis e NGINX. Inoltre, è comune sostituire Logstash con Fluentd, di cui parleremo più avanti. Questo sistema può essere complesso da gestire, il che nei suoi primi giorni ha portato a un sacco di problemi e lamentele. Questi sono stati in gran parte risolti, ma è ancora un sistema complesso, quindi potreste non volerlo provare se siete una piccola operazione.

Detto questo, ci sono servizi disponibili in modo da non dovervi preoccupare di questo. Logz.io lo eseguirà per voi, ma il suo prezzo di listino è un po’ troppo alto se avete molti dati. Naturalmente, voi siete probabilmente più piccoli e potreste non avere molti dati. Se non puoi permetterti Logz.io, potresti guardare qualcosa come AWS Elasticsearch Service (ES). ES è un servizio offerto da Amazon Web Services (AWS) che rende molto facile far funzionare Elasticsearch velocemente. Ha anche strumenti per ottenere tutti i log di AWS in ES usando Lambda e S3. Questa è un’opzione molto più economica, ma c’è una certa gestione richiesta e ci sono alcune limitazioni.

Elastic, la società madre dello stack, offre un prodotto più robusto che utilizza il modello open core, che fornisce ulteriori opzioni intorno agli strumenti di analisi e di reporting. Può anche essere ospitato su Google Cloud Platform o AWS. Questa potrebbe essere l’opzione migliore, poiché questa combinazione di strumenti e piattaforme di hosting offre una soluzione più economica della maggior parte delle opzioni SaaS e fornisce ancora molto valore. Questo sistema potrebbe effettivamente sostituire o dare la capacità di un sistema di gestione delle informazioni e degli eventi di sicurezza (SIEM).

Lo stack ELK offre anche grandi strumenti di visualizzazione attraverso Kibana, ma manca una funzione di allerta. Elastic fornisce funzionalità di allerta all’interno dell’add-on a pagamento X-Pack, ma non c’è nulla di integrato per il sistema open source. Yelp ha creato una soluzione a questo problema, chiamata ElastAlert, e probabilmente ce ne sono altre. Questo software aggiuntivo è abbastanza robusto, ma aumenta la complessità di un sistema già complesso.

Graylog

Graylog è recentemente cresciuto in popolarità, ma ha avuto il suo inizio quando Lennart Koopmann lo ha creato nel 2010. Due anni dopo è nata un’azienda con lo stesso nome. Nonostante il suo crescente utilizzo, è ancora molto indietro rispetto allo stack ELK. Questo significa anche che ha meno caratteristiche sviluppate dalla comunità, ma può usare gli stessi Beats che usa lo stack ELK. Graylog ha guadagnato lodi nella comunità Go con l’introduzione del Graylog Collector Sidecar scritto in Go.

Graylog usa Elasticsearch, MongoDB e il Graylog Server sotto il cofano. Questo lo rende complesso da eseguire come lo stack ELK e forse un po’ di più. Tuttavia, Graylog viene fornito con avvisi incorporati nella versione open source, così come diverse altre caratteristiche degne di nota come lo streaming, la riscrittura dei messaggi e la geolocalizzazione.

La funzione di streaming consente ai dati di essere indirizzati a specifici flussi in tempo reale mentre vengono elaborati. Con questa funzione, un utente può vedere tutti gli errori del database in un singolo flusso e gli errori del server web in un altro flusso. Gli avvisi possono anche essere basati su questi flussi quando vengono aggiunti nuovi elementi o quando una soglia viene superata. La latenza è probabilmente uno dei maggiori problemi con i sistemi di aggregazione dei log, e gli stream eliminano questo problema in Graylog. Non appena il log arriva, può essere instradato ad altri sistemi attraverso uno Stream senza essere elaborato completamente.

La funzione di riscrittura dei messaggi utilizza il motore di regole open source Drools. Questo permette a tutti i messaggi in arrivo di essere valutati rispetto a un file di regole definito dall’utente che consente di eliminare un messaggio (chiamato Blacklisting), aggiungere o rimuovere un campo, o modificare il messaggio.

La caratteristica più interessante potrebbe essere la capacità di geolocalizzazione di Graylog, che supporta il tracciamento degli indirizzi IP su una mappa. Questa è una caratteristica abbastanza comune ed è disponibile anche in Kibana, ma aggiunge un sacco di valore, soprattutto se si desidera utilizzare questo come sistema SIEM. La funzionalità di geolocalizzazione è fornita nella versione open source del sistema.

Graylog, l’azienda, si fa pagare per il supporto sulla versione open source se lo si desidera. Offre anche un modello di base aperto per la sua versione Enterprise che offre archiviazione, registrazione di audit e supporto aggiuntivo. Non ci sono molte altre opzioni per il supporto o l’hosting, quindi probabilmente sarete da soli se non usate Graylog (l’azienda).

Fluentd

Fluentd è stato sviluppato da Treasure Data, e il CNCF lo ha adottato come progetto in incubazione. È stato scritto in C e Ruby ed è raccomandato da AWS e Google Cloud. Fluentd è diventato un sostituto comune per Logstash in molte installazioni. Agisce come un aggregatore locale per raccogliere tutti i log dei nodi e inviarli ai sistemi di archiviazione centrale. Non è un sistema di aggregazione dei log.

Utilizza un robusto sistema di plugin per fornire integrazioni facili e veloci con diverse fonti di dati e output di dati. Poiché ci sono oltre 500 plugin disponibili, la maggior parte dei vostri casi d’uso dovrebbe essere coperta. Se non lo sono, questa sembra un’opportunità per contribuire alla comunità open source.

Fluentd è una scelta comune in ambienti Kubernetes a causa dei suoi bassi requisiti di memoria (solo decine di megabyte) e il suo elevato throughput. In un ambiente come Kubernetes, dove ogni pod ha un sidecar Fluentd, il consumo di memoria aumenterà linearmente con ogni nuovo pod creato. L’utilizzo di Fluentd ridurrà drasticamente l’utilizzo del sistema. Questo sta diventando un problema comune con gli strumenti sviluppati in Java che sono destinati ad essere eseguiti uno per nodo, dove l’overhead di memoria non è stato un problema importante.