Negli ultimi anni si parla sempre più spesso di Big Data, Centralized Log Management e Analytics alimentando l’ecosistema delle soluzioni commerciali e open source. In questo e nel prossimo articolo, gli autori descrivono un caso reale, gestito nelle attività del Gruppo Imola, la soluzione architetturale basata sul modello open source ELK stack e il contributo dato con la creazione di un plug-in per Logstash.
Il problema affrontato
Qualche anno fa un nostro cliente ci ha coinvolto nel risolvere un problema che si trascinava dietro da anni. La sua realtà consiste in un centinaio di uffici operativi sparsi in tutta Italia, in ognuno dei quali è installata localmente una suite di applicazioni che servono per la sua normale operatività.
La suite si compone di un numero di applicativi variabile da 3 a 6 realizzati da fornitori differenti, più un analogo numero di processi d’integrazione che hanno il compito di allineare gli archivi usati dalle diverse applicazioni. Questi applicativi sono utilizzati dai dipendenti a seconda delle situazioni.
Esistono, inoltre, degli uffici organizzativi nei quali sono presenti altri prodotti per le analisi di business sui dati elaborati negli uffici operativi.
Le esigenze riscontrate
Da una analisi della situazione, sono apparse chiare alcune necessità:
- monitorare gli applicativi nei vari uffici vale a dire il tempo di esecuzione dei processi e le quantità di informazioni elaborate;
- disporre di cruscotti ad hoc di monitoraggio e business analytics;
- creare un sistema di alerting che permettesse di notificare la non terminazione dei processi per ogni singolo ufficio;
- centralizzare i log prodotti dai sistemi di ogni ufficio tenendo in considerazione l’eterogeneità dei log stessi ed eliminando il “rumore” alla fonte;
- realizzare una soluzione scalabile e facilmente estendibile.
Sulla base di tutti questi aspetti, La richiesta può essere inquadrata come un problema di log management e big data.
Log management
Per la gestione e l’analisi del logging esistono validi strumenti commerciali quali ad esempio Splunk [1], su cui oltretutto come Gruppo Imola [3] abbiamo consolidato negli anni una valida competenza. Però, in questo scenario, è stata scartata l’adozione di soluzioni commerciali, sostanzialmente perch� non conformi ad alcuni requisiti funzionali richiesti, tra i quali, ad esempio, la possibilità di trattare correttamente processi non terminati.
Vista l’eterogeneità dei sistemi coinvolti si è ritenuta preferibile una soluzione open source più flessibile e customizzabile e quindi la scelta è ricaduta su strumenti come Elasticsearch, Logstash e Kibana. Tale soluzione è oramai diventata uno standard de facto riconosciuto in letteratura come ELK stack [2], dalle iniziali dei nomi dei tre prodotti. Nella figura 1 riportiamo la soluzione architetturale proposta e accettata.
Figura 1 – Diagramma architetturale della soluzione proposta.
La progettazione del plug-in elapsed
L’estendibilità della soluzione scelta ci ha permesso di progettare e implementare il plug-in elapsed per Logstash [4]. Il plug-in è stato accettato e validato come community-contributed plug-in e rilasciato dalla versione 1.3.0 di Logstash. Nel prossimo articolo descriveremo dettagliatamente questo plug-in e il processo che ha portato alla sua realizzazione, mentre in questo articolo ci concentreremo nella descrizione dettagliata dei componenti dell’architettura proposta.
Big Data
Il problema affrontato ricade nell’ambito Big Data in quanto soddisfa le 3 caratteristiche principali richieste per tale definizione:
- volume, per la dimensione effettiva dei dataset gestiti;
- variety, per i differenti tipi di dati (strutturati, semi-strutturati e non strutturati);
- velocity, per il fattore velocità da considerare (“Quanto sono veloci i dati disponibili per l’analisi?”, “Quanto velocemente li dobbiamo trattare e analizzare?”).
Nel nostro caso occorreva gestire, analizzare e storicizzare circa 2 GigaByte di dati al giorno all’interno dei quali i log event sono per loro natura eterogenei e passano nel loro ciclo di vita da una forma non strutturata a documenti json strutturati.
I file log sono alimentati nell’arco delle 24 ore sia dalle applicazioni dei vari uffici, sia dai processi di allineamento e consolidamento; i monitoraggi e gli analytics vengono aggiornati in modo continuo.
Passiamo ora ad analizzare i diversi elementi che costituiscono l’architettura adottata.
Redis
Redis [5] è un engine NoSQL estremamente performante e scalabile. Redis è uno store chiave-valore che utilizza la memoria RAM come repository principale: proprio per questo motivo Redis è molto performante durante le operazioni di scrittura; tuttavia un meccanismo di snapshot su disco rigido consente di mantenere una sorta di persistenza del dato.
Nella nostra soluzione proposta è utilizzato come Broker degli event log (formato documento json) provenienti da tutti gli uffici.
Logstash
Logstash [6] è un progetto open source creato da Jordan Sissel. Scritto in JRuby, è distribuito in formato JAR e necessita della JVM per essere eseguito.
Logstash ha il compito di raccogliere, analizzare, normalizzare, aggregare e indicizzare i dati (in vari formati e tipologie) e di memorizzarli in un unico storage per facilitare ulteriori possibili trasformazioni e lavorazioni.
Nella configurazione di Logstash è definita una pipeline che caratterizza l’intero ciclo di vita di un log event (timestamp + dati). La pipeline si divide in tre sezioni: inputs, filters, outputs.
Inputs
La sezione di inputs esegue l’estrazione dei singoli log event o messaggi da uno o più stream di input, nel nostro caso file o Redis a seconda del componente architetturale.
Filters
La sezione di filters esegue tutte le trasformazioni del messaggio che passa nella pipeline.
Outputs
La sezione di outputs è il duale dell’input verso database, sistemi di storage, servizi etc. Nel nostro caso Redis ed ElasticSearch.
File di configurazione
Riportiamo a titolo di esempio il file di configurazione semplificato dei componenti Logstash Shipper (processo agent per ogni ufficio) che ha il compito di catturare tutti gli event log dai file generati, eliminare le informazioni non utili e generare una struttura json da inviare al Broker:
// Estrapolazione dal file di configurazione LogstashShpper.conf (Shipper) { input { file { type => "Consolidamento" path => ["/logs/*.log"] exclude => ["*.gz", "shipper.log"] } } filter { //Filtro GROK per la normalizzazione dei timespamp non standard grok { patterns_dir => ["../patternsShipper"] match => ["message", "%{LOG_TIMESTAMP}"] } } output { //Invio vero il cluster redis redis { host => "host" data_type => "list" key => "logstash" } }
Quando nei file di log le applicazioni scrivono questo esempio di log:
[2015_03_28-22_55_03] [CONSOLIDAMENTO] ; $# Nome della Sequenza: Seq_AI_1379503146 $# Identificativo del territorio: 9904 $# Azzonamento del territorio: AI;
lo shipper in ascolto preleva il messaggio flat. Al termine della pipeline al Broker è inviato il seguente documento json:
{ "message" => "[2015_03_28-22_55_03] [CONSOLIDAMENTO] ; $# Nome della Sequenza: Seq_AI_1379503146 $# Identificativo del territorio: 9904 $# Azzonamento del territorio: AI;", "@timestamp" => "2015-03-28T22:55:03.000Z", "@version" => "1", "type" => "cons", "host" => "UFFICIO_N", "logdate" => "[2015_03_28-22_55_03]", "tags" => [ [0] "Dated" ] }
In particolare è importante notare la standardizzazione del timestamp (proprietà @timestamp) e l’inserimento di nuove proprietà molto utili per identificare i log event come ad esempio l’host di provenienza.
Plug-in
Sicuramente uno dei punti di forza di Logstash deriva dal buon numero di plug-in di base o sviluppati e testati dalla community, come ad esempio il filtro Elapsed [4] da noi progettato e implementato.
Per avere un’idea del numero di plug-in e della “potenza di fuoco” fornita da Logstash riportiamo nella figura 2 la lista completa di input, filter e output all’ultima versione 1.4.2.
Figura 2 – Lista di plug-in per Logstash ver. 1.4.2
Nella soluzione architetturale proposta il componente centrale è il Logstash Indexer definito come cluster di installazioni di Logstash. Ogni elemento del cluster (in HA) recupera tutti i log event dal Broker e li elabora, in base ai filtri configurati, prima di inviarli a Elasticsearch [2].
Elasticsearch
Elasticsearch [7] è un potente motore di ricerca open source distribuito e scalabile e basato su Apache Lucene. È divenuto nel tempo molto popolare nell’ambito Big Data, negli ambienti enterprise e nel settore del cloud computing per l’incredibile capacità di ricercare, analizzare e mostrare dati contenuti nei documenti json, con interrogazioni che avvengono quasi in tempo reale.
Ad oggi è il secondo motore di ricerca più popolare [10] ed è usato in progetti come Netflix, Atlassian e Github, Facebook, Wikipedia, Wikimedia, e così via [11].
Le caratteristiche di Elasticsearch
Una delle caratteristiche importanti di Elastisearch per la gestione degli event log è di essere senza schema ossia è possibile inserire un qualsiasi documento json e tutti i suoi campi sono indicizzati e tutti gli indici possono essere usati in query di ricerca.
Tutte le funzionalità sono nativamente esposte tramite interfaccia RESTful; questa caratteristica, insieme alla capacità espressiva delle query DSL, ci ha permesso facilmente di costruire cruscotti di monitoraggio (figura 3) e analytics (figura 4) utilizzando tecnologia JQuery/Google API.
Figura 3 – Cruscotto di monitoraggio sulle tempistiche dei processi.
Esistono svariati plug-in preconfezionati e facilmente installabili nei cluster Elasticsearch che espongono interfaccie web di amministrazione e/o ricerca e gestione dati. In particolare noi stiamo utilizzando ElasticHQ Plug-in [12] molto utile per definire e costruire query DSL o per avere statistiche sullo stato dei vari nodi del cluster.
Figura 4 – Mappa iterativa dei singoli uffici. Permette di verificare l’operatività degli uffici e la quantità di dati inviati alle sede centrale.
Kibana 3
Kibana [13] è il motore di visualizzazione dei dati di Elasticsearch che permette un’interazione nativa con tutti i dati presenti nello storage attraverso dashboard personalizzate. Le dashboard panels di Kibana sono dinamiche, salvabili, condivisibili ed esportabili.
Figura 5 – Tempi massimi di esecuzione per processo su distribuzione temporale.
È possibile eseguire l’analisi dati attraverso un’interfaccia utente performante, utilizzando dashboard definite precedentemente o caricando queste dashboard in tempo reale, per l’analisi immediata dei dati.
Figura 6 – Somma tempi per tipo processo su distribuzione temporale.
Riportiamo a titolo di esempio, nelle figure 5, 6 e 7, alcuni grafici definiti per le dashboard del cliente. Tutti i grafici sono dinamici ovvero è possibile aggiungere o eliminare elementi graficati ed è possibile restringere o aumentare il range temporale su cui eseguire le ricerche.
Figura 7 – Frequenza Log Event per tipo processo.
Conclusioni
Siamo partiti dall’analisi di un caso reale in cui ci siamo trovati ad operare come Gruppo Imola, dove opera un gruppo di esperti ([14] e [15]) sulle tematiche di Data Governance e Knowledge Management e dove svolgiamo ricerca applicata sul campo per risolvere una parte dei problemi classificabili come Big Data.
Già da tempo ci siamo resi conto della forte crescita della soluzione open source basata su Elasticsearch, Logstash e Kibana; e in questo articolo abbiamo descritto un caso di uso reale dell’architettura basata appunto sull’ELK Stack. Inoltre abbiamo apprezzato le caratteristiche di flessibilità ed estensibilità offerte dal componente Logstash (la “L” di ELK), supportato, oltre che dalla Elastic Co., anche dalle community. Questo ci ha consentito di progettare e implementare il plug-in elapsed: e di questo parleremo nel prossimo articolo, entrando nei dettagli di tale realizzazione