[BigData] ELK Stack: ElasticSearch + Logstash + Kibana

ELK Stack

Nel presente articolo riporto alcune informazioni rilevanti relative all’ ELK Stack, set di tecnologie open-source più diffuse e utilizzate per l’implementazione di una soluzione di Log Management, costituito dai seguenti prodotti:

  • ElasticSearch: server di ricerca basato su Lucene, e, dunque, con capacità “full-text”, e con supporto ad architetture distribuite e su larga scala. Le modalità di interazione e di interrogazione con la base dati proprietaria (su file system) avvengono attraverso interfaccia RESTful. Le informazioni sono memorizzate internamente come documenti JSON; Riferimento: https://www.elastic.co
  • LogStash: progetto Open Source scritto in JRuby, distribuito in formato JAR, la cui funzione principale è quella di fare il pipe di un qualsiasi evento, che può essere un log di sistema, una riga di testo, un tweet, ecc. Logstash può interfacciarsi con numerosi input, elaborarli, filtrarli e passarli ad un motore di ricerca o memorizzazione, come MongoDB, Redis, ElasticSearch e molto altro, configurando (attraverso un opportuno file di configurazione) la pipeline per l’acquisizione, il filtering e l’invio dei dati. L’integrazione con ElasticSearch è quella più potente e veloce per l’implementazione di una soluzione di log managementRiferimento: https://www.elastic.co/products/logstash
  • Kibana: è un tool che permette di visualizzare, grazie a strumenti di data analytics, le informazioni indicizzate ed acquisite da ElasticSearch o altri prodotti. Permette la rappresentazione delle informazioni in tempo reale, attraverso dashboard configurabili con vari tipi di widget (pie chart, istogrammi, grafici cartesiani, ecc.). Riferimento: https://www.elastic.co/products/kibana

La soluzione ELK Stack permette di implementare differenti modelli architetturali di alta scalabilità. Per maggiori dettagli su LogStash, vi consiglio il seguente riferimento: LogStask Book. Si riportano, di seguito, alcuni dei modelli di riferimento dell’ELK stack.

Modelli di riferimento: soluzioni con ELK Stack

Soluzione di base
La soluzione di base proposta da ELK Stack prevede la configurazione di una singola istanza di LogStash in modo da acquisire i dati non strutturati da differenti sorgenti. E’ possibile configurare più istanze di LogStash (Agent Shipper), in modo da acquisire i dati da datasource differenti ed indirizzare le informazioni strutturate (documenti JSON) ad un’unica istanza di ElasticSearch. Quest’ultimo effettua l’indicizzazione e la memorizzazione dei documenti JSON acquisiti.

ELKStack_SoluzioneBase

Tramite un file di configurazione è possibile far puntare l’istanza agent di LogStash ad uno o più datasource (SysLog Server, File System, DBMS, ecc.), grazie all’utilizzo di vari input plugin.

Inoltre, è possibile configurare le destinazioni, a cui inviare i documenti JSON degli eventi acquisiti, utilizzando vari output plugin. Il parsing e il filtering degli eventi acquisiti dai vari datasource può essere configurato grazie a filter plugin.

ELKStack_SoluzioneBase

Di seguito, si riporta un esempio di trasformazione di un evento di log in formato SysLog (formato non strutturato) in un documento JSON (formato strutturato):

SysLog Message:

Dec 17 16:00:35 joker systemd-logind[2113]: New session 31581 of user bob.

JSON Log Event:

{
  "host" : "joker.example.com",
  "priority" : 13,
  "timestamp" : "Dec 17 16:00:35",
  "logsource" : "joker.example.com",
  "program" : "bob",
  "pid" : "23262",
  "severity" : 5,
  "facility" : 1,
  "facility_label" : "user-level",
  "severity_label" : "Notice",
  "@timestamp" : "2012-12-17T16:00:35.000Z",
  "@version" : "1",
  "message" : "New session 31581 of user bob",
  "type" : "syslog"
}

Soluzione con coda di messaggi
Quando i dati inviati alla pipeline di LogStash eccedono l’abilità del cluster di ElasticSearch di poterli prendere in input, conviene utilizzare un message queue come buffer. Prevedendo un message queue nell’architettura si garantisce un livello di protezione per evitare la perdita dei dati. In questo modo si riesce ad evitare la congestione dell’istanza Indexer, la quale “scoda” i messaggi sulla coda uno alla volta e in maniera asincrona.

ELKStack_SoluzioneCodaJMS

Soluzione ad alta affidabilità
ELKStack_SoluzioneAltaAffidabilità

La soluzione su rappresentata è quella più completa dal punto di vista dell’alta affidabilità. Grazie ad un bilanciatore è possibile instradare differenti datasource verso una istanza agent di LogStash attiva ed inviare il messaggio di evento sul message queue. In pratica, ogni istanza agent di LogStash viene configurata su input multipli e l’architettura può essere scalata orizzontalmente. Pipeline separate incrementano, dunque, la reliability del sistema ed eliminano i single points of failure.

Modello per la memorizzazione degli eventi
Nella soluzione con l’ELK Stack, il prodotto ElasticSearch usa Apache Lucene per la creazione degli indici. Ogni indice è un namespace logico che permette di recuperare tutti gli eventi collezionati nella base dati NOSQL di ElasticSearch. Di default, LogStash invia il documento JSON sull’indice che ha nel nome il suffisso del giorno di acquisizione dell’evento, ad esempio: logstash-2015.11.31.

Questo tipo di memorizzazione potrebbe essere preso come riferimento per collezionare le informazioni in tabelle/indici creati su base temporale (ad esempio, mensilmente). In questo modo si potrebbero salvare tutti gli eventi su base temporale, evitando di caricare di troppi record una singola tabella. Tale scelta dipende anche dai tipi di correlazione che occorrerà fornire per la Log Analysis.

Volendo comparare il modello di memorizzazione di ElasticSearch con quello di un database relazionale si ha che:

  • Un index è una tabella
  • Un document è una riga della tabella
  • Un field è una colonna della tabella.

 

Per maggiori dettagli vi rimando ai tutorial su Mokabyte:

 

Protetto: [BigData&NoSQL] Log Management: un caso d’uso di Big Data e di Operational Intelligence

Il contenuto è protetto da password. Per visualizzarlo inserisci di seguito la password:

[NO-SQL] Appunti su analisi di performance e comparazione dei database NoSQL

Continuando la trattazione dell’argomento dei Database No-SQL, viste le impressioni e segnalazioni via email dei visitatori di questo blog, condivido un pò di appunti in un documento che potete scaricare qui di seguito:

Database NoSQL-Comparazione tecnologie

Il documento raccoglie le considerazioni e le valutazioni oggettive emerse durante la lettura di articoli e documentazioni online sull’argomento dei DB No-SQL. Nello specifico, l’oggetto di studio è stato MongoDB, confrontandolo con altre soluzioni (relazionali e non) e, in particolare, è stata approfondito il suo possibile utilizzo per la gestione di una struttura a grafo.

NoSQL Model

Ecco l’indice dei paragrafi del documento, sperando vi possa essere utile per spunti o per far nascere riflessioni/discussioni sull’argomento:

  1. I database NoSQL
    1. Perché NoSQL? Il teorema di CAP e il No-SQL data model
    2. Un confronto tra le famiglie di DB NoSQL
    3. I database document-oriented e graph-oriented
  2. Breve introduzione su MongoDB
    1. Principali caratteristiche di MongoDB
    2. Comparazione tra MongoDB e MySQL
    3. Ambiti di utilizzo e realizzazione dei direct graph con MongoDB
    4. Soluzioni ibride: MongoDB + database a grafo + RDF triple store
    5. Analisi delle prestazioni di MongoDB all’aumentare dei documenti memorizzati
  3. Confronto tra le performance di MongoDB e di altri database NoSQL
    1. Confronto MongoDB con vari database NoSQL
    2. Confronto HBase e MongoDB
  4. Analisi di performance dei Graph Database
    1. Elenco e caratteristiche di varie implementazioni di Graph Database
    2. Analisi e confronto delle performance di varie implementazioni di Graph Database
    3. Scalabilità
Database NoSQL-Comparazione tecnologie
Titolo: Database NoSQL-Comparazione tecnologie (0 click)
Etichetta:
Filename: database-nosql-comparazione-tecnologie.pdf
Dimensione: 770 kB

Il Tag Cloud: dai blog al Big Data

Ultimamente si parla molto del tag cloud (o word cloud), uno strumento che sta diventando particolarmente utile nell’ambito della data analysis. Basta guardare il grande successo di Expert Systems, nell’ambito appunto dell’analisi semantica di varie fonti online (Expert Systems Rassegna Stampa). Ma il tag cloud c’è da un bel po’: nei blog, per esempio, esiste dalla notte dei tempi, e nell’era del Big Data e dell’Internet of Things ha acquisito la sua giusta notorietà, visto come uno strumento utile per filtrare un bel po’ di informazioni e concetti sulla miriade di contenuti sparsi in rete.

Il Tag Cloud non è altro che una rappresentazione visiva di concetti, detti keyword metadata (tags), ricercati su fonti online e visualizzati sotto forma di testo semplice. I tag sono solitamente parole singole e l’importanza di ognuno di essi è mostrata con un font di dimensione diffente e/o uno specifico colore. Avere una rappresentazione “a nuvola” ci aiuta ad estrapolare meglio i concetti del dominio di analisi e a navigarlo (magari associando ai singoli tag anche dei link ipertestuali agli articoli/fonti da cui sono stati estratti).

Solitamente i tag cloud si basano sul concetto di “frequency“, ossia associano a ciascun tag una frequenza, il numero di volte in cui quel tag è stato “rintracciato” in un singolo item (articolo, pagina web o fonte) e, dunque, sulla “popularity” di quel concetto sulla rete.
Esiste anche un modo per “categorizzare” i tag, con i cosiddetti tag cluster (clustering): i tag che si riferiscono allo stesso contesto (categoria o tassonomia) possono essere classificati in “sotto-nuvole”, dette appunto cluster. La categorizzazione avviene spesso applicando algoritmi di similarità semantica (Natural Language Processing) o statistici.

Sui blog, questa categorizzazione di informazioni viene generata dagli utenti mediante l’utilizzo di parole chiave (o tag) scelte liberamente, e si parla di Folksonomie. Vi invito a leggere l’interessante articolo: “Folksonomy: questione di semantica“.

Vi riporto ora delle librerie che ho studiato e utilizzato per la realizzazione di una tag cloud:

 

Creative Commons License
This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2012/12/06/il-tag-cloud-dai-blog-al-big-data/.

[BigData] Il Big Data Forum 2012 a Roma: le soluzioni ICT per un vantaggio competitivo

Il 21 Novembre scorso si è tenuta a Roma la 2° edizione del Big Data Forum, dallo slogan “Big Data Forum 2012: per fare chiarezza sul fenomeno dell’esplosione dei dati e scoprire le soluzioni ICT che consentono di trasformarlo in vantaggio competitivo“.

L’evento, pubblicizzato da ICT4Executive, con partner di eccezione come Microsoft, Oracle e Informatica Software, è stato condotto da relatori di riguardo, particolarmente distinti sia nel campo della ricerca ICT (in particolare, nella Business Intelligence), che in quello strategico aziendale.

Ho partecipato all’evento e vi riporto un resoconto dettagliato delle tematiche affrontate ed estrapolate dagli interventi dei relatori presenti.

 

La Big Data Analysis

Il moderatore Carlo Vercellis, responsabile dell’Osservatorio di Business Intelligence & Big Data Analytics e professore alla School Management del Politecnico di Milano, ha sottolineato che il BigData è un tema di attualità molto in voga nell’ultimo periodo, come il cloud computing del resto, ma che da fenomeno del momento deve trasformarsi in innovazione tecnologica, in grado di cambiare gli attuali schemi e paradigmi del modo di trattare le informazioni su Internet.
Come non citare lo slogan di Tim Berners-LeeROW DATA, NOW!“. Dati grezzi da trattare, che sono diventati (e diventeranno ancora) troppi e dai cui è difficile poter estrarre informazione. Un fenomeno di cui si vocifera particolarmente nell’ultimo periodo, visti gli impegni delle varie iniziative di Open Data e eGov, che “impongono” ai detentori illegittimi di dati (ndr. come pubbliche amministrazioni) di distribuire informazioni di proprietà dei cittadini.

 

I dati diventano “interessanti” solo se siamo capaci di estrarre da essi un contenuto utile, da trasformare in servizio per gli utenti finali.

 

Continua la lettura