Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Programmazione II

Monitoraggio di log operazionali con la suite ELK

Anno Accademico 2016/2017 Candidato: Michele Bevilacqua Matr. N46/002001

A mia madre e mio padre.

Indice

Indice .................................................................................................................................................. III Introduzione ......................................................................................................................................... 4 Capitolo 1: Suite ELK .......................................................................................................................... 6

1.1 Analisi dei log ............................................................................................................................ 6

1.2 Elasticsearch............................................................................................................................... 7 1.2.1 Caratteristiche principali ..................................................................................................... 8 1.2.2 Architettura del sistema ...................................................................................................... 9

1.3 Logstash ................................................................................................................................... 11

1.4 Kibana ...................................................................................................................................... 12

1.4.1 Geo Tile............................................................................................................................. 12 1.4.2 Timelion ............................................................................................................................ 13

Capitolo 2: Installazione e configurazione ......................................................................................... 15 2.1 Elasticsearch............................................................................................................................. 16 2.2 Logstash ................................................................................................................................... 17

2.2.1 Input plugins ..................................................................................................................... 18

2.2.2 Filter plugins ..................................................................................................................... 19 2.2.3 Output plugins ................................................................................................................... 21

2.3 Kibana ...................................................................................................................................... 22 Capitolo 3: Analisi di un log operazionale......................................................................................... 24

3.1 Descrizione del sistema ............................................................................................................ 24

3.2 Raccolta dei log ........................................................................................................................ 25

3.2.1 Tracciati numerici ............................................................................................................. 25

3.2.2 Log testuali ........................................................................................................................ 26 3.3 Analisi e visualizzazione .......................................................................................................... 27

3.3.1 Condizioni nominali .......................................................................................................... 28 3.3.2 Presenza di failure ............................................................................................................. 30

Conclusioni ........................................................................................................................................ 33 Bibliografia ........................................................................................................................................ 34

4

Introduzione

In informatica un log è un file in cui vengono annotate tutte le operazioni effettuate da

una macchina al fine di analizzare le segnalazioni di errore, le operazioni ed i

responsabili di queste, oppure ripristinare situazioni precedenti in seguito a fallimenti

del sistema. Il termine deriva dall’inglese e significa tronco di legno. Nel gergo

nautico del 1700 rappresentava il pezzo di legno che veniva utilizzato per calcolare

approssimativamente la velocità di una nave. Ad intervalli di tempo regolari venivano

annotate, all’interno di un registro di navigazione, il cosiddetto logbook, oltre alla

velocità altre informazioni tra le quali il tempo e la forza del vento. Nella seconda

metà degli anni Novanta il termine log fu importato nell’ambito informatico con il

significato di giornale di bordo [1]. Con lo sviluppo di sistemi sempre più complessi si

è reso necessario l’utilizzo di un software per l’analisi dei file di log. Infatti questi

presentano diversi tipi di formattazione, a volte anche complessi, e inoltre possono

raggiungere dimensioni molto elevate. Da ciò deriva l’impossibilità di una facile o

immediata gestione in assenza del supporto offerto da software per l’analisi. Esistono

numerosi tipi di software per la raccolta e la gestione dei log, alcuni dei quali

commerciali ed altri open source. L’obiettivo del presente elaborato è illustrare il

monitoraggio e l’analisi di un log mediante la suite ELK, che appartiene alla famiglia

dei software open-source ed è composta da: Elasticsearch, Logstash e Kibana. Nel

primo capitolo, dopo una breve introduzione ai log, vengono presentati i tre strumenti,

5

analizzando nello specifico le caratteristiche principali offerte da ognuno di essi per

analizzare i log. Nel secondo capitolo viene illustrato come installarli, configurarli ed

utilizzarli per l’analisi di un file di log. Il terzo e ultimo capitolo si focalizza

interamente sul caso di studio trattato.

6

Capitolo 1: Suite ELK

Prima di trattare nello specifico i tre strumenti che compongono la pila ELK è bene fornire

una definizione di file di log e introdurre la problematica dell’analisi dei log.

1.1 Analisi dei log

Un file di log è costituito da una sequenza di righe di informazioni, relative ad eventi

regolari ed anomali catturati da un sistema durante la sua esecuzione. Tipicamente, ad ogni

riga è associato un Timestamp, ovvero data e ora in cui i dati contenuti all’interno sono

stati raccolti. I file di log possono avere formati differenti a seconda del dominio

applicativo dal quale sono stati generati [2]. Segue nella figura 1.1 un esempio di un log

Apache (Unix) [3].

Figura 1.1 Esempio di log

L’analisi di un log passa attraverso tre fasi: raccolta, indicizzazione e visualizzazione.

Con il supporto di specifici software vengono inizialmente raccolti tutti gli eventi,

successivamente vengono indicizzati per poter essere manipolati ed infine visualizzati.

Una possibile soluzione per l’analisi di un log è fornita dallo stack ELK. Logstash fa da

7

pipe a diversi tipi di evento; si interfaccia con diversi tipi di input, tra i quali i file di log, e

dopo averli elaborati e filtrati li passa ad un motore di ricerca o memorizzazione. Le

informazioni contenute nei file di log vengono quindi indirizzate in Elasticsearch, che si

occupa di conservare e indicizzare i dati. In fondo alla pila troviamo Kibana, un tool che

permette di visualizzare ed esplorare le informazioni contenute in Elasticsearch in tempo

reale [4].

Figura 1.2 ELK Stack

1.2 Elasticsearch

Elasticsearch è un server di ricerca open source in grado di memorizzare grandi

quantità di dati in modo da favorire ricerche basate sul linguaggio. Nel 2004 Shay

Bannon diede vita al progetto Compass con il fine di creare una soluzione open source

per un motore di ricerca distribuito, ma mentre lavorava verso la nascita della terza

versione si rese conto che per garantire un prodotto di ricerca scalabile sarebbe stato

necessario riscriverne gran parte [5]. Da qui nacque la decisione di riscrivere da zero

una soluzione, e nel 2010 venne presentata la prima versione di Elasticsearch [6].

Basato su Apache Lucene, una API concepita per realizzare applicazioni che

necessitano di funzionalità di indicizzazione e ricerca Full-Text, ovvero ricerche basate

interamente sul testo, il motore di ricerca esamina tutte le parole contenute in ogni

documento e tenta di trovare un riscontro secondo determinati criteri. Elasticsearch è il

primo strumento in grado di eseguire ricerche full-text in modo parallelo, scalabile e

8

real-time. Tutte queste caratteristiche gli hanno permesso di scalare le classifiche dei

motori di ricerca più utilizzati portandolo nel Gennaio 2016 al primo posto [7]. Tra i

più famosi utilizzatori di Elasticsearch troviamo: Wikimedia, Mozilla, Foursquare,

SoundCloud e Netflix.

Figura 1.3 Logo Elasticsearch

1.2.1 Caratteristiche principali

A seguire alcune caratteristiche principali [8]:

Protocollo JSON/HTTP: Elasticsearch fornisce le funzionalità attraverso il

protocollo http, il quale utilizza l’architettura software REST ovvero

REpresentational State Transfer, rendendo di fatto standard l’interfaccia di

comunicazione. Affiancato ad http troviamo JSON, utilizzato da Elasticsearch

per gestire le informazioni. JSON, ovvero JavaScript Object Notation, è un

formato di interscambio dati il quale memorizza le informazioni in maniera

organizzata affinché siano facilmente leggibili ed accessibili.

Schemaless: Elasticsearch gestisce dati senza uno schema fisso. In questo

modo è possibile inserire qualsiasi documento JSON ed indicizzare tutti i suoi

campi, potendo poi utilizzare tutti gli indici in query di ricerca.

Scalabilità ed affidabilità: Elasticsearch è configurato come un cluster

contenente uno o più nodi, ovvero le singole istanze di esecuzione di

Elasticsearch. Questa configurazione garantisce la scalabilità del sistema,

progettato per supportare una ricerca in parallelo e in maniera tale da poter

aumentare la capacità di storage semplicemente aggiungendo nodi al cluster. I

dati sono contenuti all’interno di indici, ovvero contenitori di dati legati tra di

loro. Un indice è diviso orizzontalmente in più shards, ovvero singole istanze

9

di Lucene che permettono la suddivisione di un indice su più nodi. Le shards

sono anche il componente che garantisce l’affidabilità all’interno del sistema.

Infatti all’interno di un cluster per ogni shard troviamo anche una sua replica,

in maniera tale da poterla utilizzare in caso di fault di un nodo dove è presente

la shard principale. All’interno del cluster è presente un nodo, detto master,

responsabile dell’organizzazione dei dati nel cluster stesso e dell’aggiunta e

rimozione dei nodi, secondo l’architettura master-slave. A seguire uno schema

semplificato dell’architettura di un cluster.

Figura 1.4 Cluster

Query DSL: Elasticsearch supporta le ricerche attraverso il linguaggio query

DSL. Essendo basato su JSON offre una libertà di ricerca molto più ampia e

potente rispetto al linguaggio SQL, ma allo stesso tempo è più complesso. La

caratteristica più importante di questo linguaggio è che permette di effettuare

ricerche full-text in grado di restituire non solo i documenti che soddisfano i

criteri specificati, ma anche quelli che si avvicinano al risultato.

1.2.2 Architettura del sistema

Abbiamo già introdotto l’architettura di Elasticsearch parlando di cluster, nodi e

shards nel precedente paragrafo. Segue adesso un confronto con le più note basi di

dati relazionali per evidenziarne ancor meglio le potenzialità [9].

10

Elasticsearch RDBMS

Index Database

Type Tabella

Document Tupla

Shard Shard

Come mostrato nella tabella sopra, possiamo vedere un indice come un database di

una base di dati relazionale in quanto entrambi hanno il fine di contenere dati di

tipo diverso. In un RDBMS possiamo trovare oggetti che condividono la stessa

struttura, ovvero che appartengono ad una certa classe, in una stessa tabella. In

questo modo la tabella definisce la struttura della classe e le tuple che la

compongono rappresentano le singole istanze degli oggetti di quella classe.

Parallelamente in Elasticsearch un Type rappresenta la struttura di una classe di

oggetti e un Document è una singola istanza di quel Type serializzato in JSON e

memorizzato associandogli un ID univoco.

Nel precedente paragrafo è stato mostrato come l’architettura di Elasticsearch

permetta di ottenere un’elevata scalabilità orizzontale, cosa che è invece molto più

difficile in un database relazionale. Della scalabilità ne beneficia anche la

manutenibilità. Infatti per far fronte ad un fallimento di un nodo è semplicemente

necessario sostituirlo, mentre invece in un RDBMS si va incontro alla necessità di

avere competenze in materia abbastanza avanzate. Inoltre Elasticsearch va incontro

al problema della concorrenza legato all’affidabilità. Infatti, mentre in un database

relazionale viene utilizzato il Pessimistic Concurrency Control per risolvere il

problema, Elasticsearch utilizza invece il paradigma Optimistic Concurrency

Control [10]. Nel primo viene effettuato il lock di una tupla quando un processo

vuole leggere i dati all’interno di essa contenuti, in modo tale da rendere atomica

un’eventuale modifica o non inconsistente una contemporanea lettura da parte di

un altro processo. Nel secondo invece non vi sono politiche di lock e, quando un

documento viene modificato, creato oppure cancellato la nuova versione viene

11

propagata in tutti i nodi del cluster con il rischio che arrivi fuori sequenza. Per

ovviare a questo problema Elasticsearch mantiene solo l’ultima versione dei

documenti.

1.3 Logstash

Logstash è un motore di raccolta dati in grado di prelevare e unificare dati da più

sorgenti e normalizzarle nelle destinazioni desiderate. Creato da Jordan Sissel, si

unì ad Elasticsearch nel 2013, in modo da fornire insieme un supporto completo

all’analisi e alla gestione dei log [11].

Figura 1.5 Logstash

In un sistema distribuito più macchine generano contemporaneamente file di log.

Grazie a Logstash questi vengono raccolti, processati, filtrati ed infine mandati ad

Elasticsearch. Una Logstash pipeline è formata da tre elementi: input, filter e

output. Con il primo si specificano le sorgenti dalle quale proverranno i dati, quali

possono essere ad esempio: file, stdin, jms, jdbc, syslog e molti altri. I dati raccolti

possono essere poi filtrati per apportarvi modifiche, identificare ed associare tipi e

nomi ai campi, creare strutture con la finalità di fornire un formato comune che sia

facilmente leggibile ed interpretabile. Infine i dati elaborati possono essere inviati

12

ad una vasta quantità di destinazioni attraverso i plugin di output. Per questi motivi

Logstash combinato insieme ad Elasticsearch costituisce un potentissimo

strumento per utilizzare al meglio le proprietà offerte da quest’ultimo.

1.4 Kibana

A completare lo stack troviamo infine Kibana, una piattaforma di analisi e

visualizzazione ideata da Rashid Khan, che permette di interagire con i dati

contenuti all’interno di Elasticsearch.

Figura 1.6 Logo Kibana

Per comprendere l’importanza di questo tool basta pensare alla grandissima mole

di dati con la quale solitamente ci si trova a lavorare in Elasticsearch. Senza infatti

poter disporre di un applicativo che permetta di visualizzare le informazioni sotto

forma di grafici sarebbe quasi impossibile analizzare e studiare tutti i dati raccolti.

Di fianco ai classici grafici a torta, istogrammi e grafici a linee, Kibana mette a

disposizione altri tipi di visualizzazione che mostrano appieno le sue potenzialità e

permettono di sfruttate completamente le capacità di aggregazione di Elasticsearch

[12]. In aggiunta può anche essere utilizzato per monitorare lo stato del cluster, i

nodi ed avere una panoramica delle prestazioni della suite.

1.4.1 Geo Tile

Elasticsearch supporta campi di tipo geo-points, ovvero coppie di numeri che

rappresentano la latitudine e la longitudine di un punto geografico. In questo tipo

13

di visualizzazione, offerta da Kibana, si possono visualizzare i punti su di una

mappa geografica, ma la peculiarità più importante è che si possono applicare

numerose aggregazioni o filtrarne un sottoinsieme in base a specifici valori dei

campi. Si possono inoltre effettuare delle geo queries, ovvero ricercare i

documenti che abbiano geo-points entro una determinata distanza da un punto

centrale o che si trovino all’interno di un’area delimitata.

Figura 1.7 Geo Tile

1.4.2 Timelion

E’ un plugin utile per rappresentare le serie temporali e mediante il quale si

possono interrogare diverse sorgenti di dati da una singola interfaccia Kibana.

Attraverso un’espressione in un linguaggio semplice ed intuitivo su una singola

riga si possono eseguire e visualizzare calcoli matematici sulle metriche, sia

basilari come ad esempio divisioni e sottrazioni, sia più complessi quali derivate e

medie mobili. Timelion, la cui pronuncia è “Time line”, offre anche un supporto

all’utente, il quale è facilitato nello scrivere l’espressione da un’auto-

completamento delle funzioni che si possono utilizzare e dei tipi degli argomenti

che ricevono in input. Questa feature, affiancata ad un linguaggio di alto livello

molto intuitivo e diretto, permette di tradurre facilmente le richieste in una

espressione Timelion. Questo plugin permette di rispondere a domande alle quali,

14

senza di esso, non si sarebbe mai pensato di poter rispondere. Infatti, applicando un

argomento offset si possono osservare, su una singola time line, i dati relativi ad

intervalli di tempo differenti, per poter comparare, ad esempio, informazioni

relative ad una settimana con quelle relative alla settimana precedente [13].

Vedremo come configurarlo ed utilizzarlo per analizzare un caso di studio nei

capitoli seguenti.

Figura 1.8 Timelion

15

Capitolo 2: Installazione e configurazione

In questo capitolo verrà mostrato come scaricare, installare e configurare per

l’utilizzo i tre strumenti che compongono la suite presentata. I prodotti sono forniti

da Elastic, per scaricarli è sufficiente recarsi nella sezione downloads del sito

https://www.elastic.co/ e scegliere il formato dei pacchetti di Elasticsearch,

Logstash e Kibana desiderato. Tra i formati disponibili troviamo tar, deb, msi e

zip. In questo elaborato si è scelto come ambiente di lavoro Windows e la versione

5.4.1 dei tre strumenti. Come accennato nel primo capitolo, Lucene è interamente

scritto in Java, per cui, per utilizzare la suite ELK, è necessario scaricare l’ultima

versione di JDK dal sito Java di Oracle.

Figura 2.1 Pagina Download ELK

16

2.1 Elasticsearch

Una volta scaricato l’archivio .zip basta estrarne il contenuto ed Elasticsearch è

pronto per l’utilizzo. Analizzando i file estratti possiamo trovare un file di

configurazione in formato yml nella sottocartella config. YAML è uno standard di

serializzazione dati facilmente interpretabile dall’uomo per tutti i linguaggi di

programmazione [14]. Il file di configurazione presenta diverse sezioni, attraverso

le quali è possibile modificare i nomi del cluster e dei nodi e il path dove vengono

memorizzati i dati. Si può inoltre settare il numero di porta sul quale il modulo http

fornisce le API di Elasticsearch su HTTP, settato di default a 9200. Segue un

frammento del file elasticsearch.yml configurato per avere un cluster e un nodo.

Figura 2.2 Parte del file di configurazione

Dopo aver settato il file di configurazione si può procedere ad avviare

Elasticsearch spostandosi da riga di comando nella sottocartella bin e lanciando il

comando elasticsearch o in alternativa si può far partire il file elasticsearch.bat.

Se invece si volesse modificare il nome del cluster e del nodo direttamente da

terminale quando si avvia l’istanza si potrebbe utilizzare il seguente comando:

17

Se tutto è andato a buon fine, facendo partire il file batch si dovrebbero

visualizzare sul terminale i seguenti messaggi:

A questo punto per accedere alle REST API di Elasticsearch si può utilizzare il

comando curl http://localhost:9200/ che sfrutta cURL, un tool da linea di

comando che permette di trasferire dati usando vari tipi di protocolli tra i quali

http, oppure lanciando il comando Invoke-RestMethod http://localhost:9200

attraverso PowerShell. In alternativa è possibile utilizzare software che gestiscono

il traffico http come Fiddler o navigare con il nostro browser all’indirizzo locale e

numero di porta scelto.

2.2 Logstash

Come per Elasticsearch, così anche per installare Logstash è sufficiente scaricare il

file .zip ed estrarlo. Fatto ciò bisogna preparare un file di configurazione e poi

lanciarlo mediante il comando logstash -f conf_file.conf. Come accennato

già nel precedente capitolo questo file è composto da tre tipi di plugins: input, filter

e output.

18

2.2.1 Input plugins

Esistono diversi tipi di plugin di input, ciascuno dei quali abilita una specifica

sorgente dalla quale Logstash leggerà i dati. Nella seguente tabella sono presenti

alcuni plugin e la relativa descrizione [15].

Input Descrizione

elasticsearch Legge i risultati di una query da un cluster Elasticsearch

file Il flusso di dati proviene da file

generator Genera eventi di log casuali a scopo di test

stdin Legge i dati da uno stream di input

tcp Riceve eventi da una socket TCP

jms Legge eventi da un Broker JMS

Vediamo nello specifico come impostare la sezione input di un file di

configurazione per leggere i dati da file.

Il plugin file presenta diverse opzioni di configurazione. In questo esempio si è

utilizzato type che indica il tipo da associare ai messaggi che verranno processati;

path che prende in input un array nel quale sono specificati il percorso o i percorsi

da cui andranno prelevati i files ed infine start_position, che può assumere i due

valori beginning o end, a seconda di dove Logstash deve iniziare a leggere i file:

dall’inizio o dalla fine. Di default ogni riga rappresenta un singolo evento, dunque

ad ogni interruzione di riga corrisponde un nuovo evento. Logstash offre anche la

possibilità di unire più righe di testo ad un solo evento, grazie al codec multiline

[16].

19

Tra le opzioni di configurazione del codec troviamo:

Pattern: utilizzata per specificare un indicatore di appartenenza del campo ad

un evento multiline.

Negate: può essere true o false. Indica se il messaggio deve corrispondere o

meno al pattern per essere accodato all’evento specificato dall’opzione

what.

What: può essere previous o next. Indica la relazione del messaggio con gli

eventi.

Supponendo di dover analizzare un file di log, nel quale ogni evento inizia con un

timestamp e al quale sono associate più righe, segue un esempio di impostazione

del codec affinché tutte le righe che non iniziano con un timestamp vengano unite

a quella precedente.

2.2.2 Filter plugins

I plugins di filtro eseguono un’elaborazione intermedia su un evento ricevuto in

input, prima che questo venga mandato in output. Dei numerosi filtri che esistono

ne tratteremo tre: grok, date e mutate. Grok permette di analizzare e strutturare

dati non strutturati. Mediante l’opzione di configurazione match viene eseguita la

corrispondenza tra il messaggio, ovvero il testo non strutturato ricevuto in input, e

diversi pattern scelti a seconda di come si vuole strutturare i dati contenuti al suo

20

interno. Per effettuare il match tra il messaggio e la struttura che vogliamo

applicare si effettua la seguente corrispondenza:

dove SINTASSI rappresenta il pattern con il quale verrà identificato il testo e

semantica è un identificativo della porzione di testo associata a quel pattern. In

aggiunta ai numerosi pattern messi a disposizione da Logstash [17] si possono

specificare, grazie all’opzione patterns_dir, una o più directory all’interno delle

quali se ne trovano ulteriori definiti dall’utente. Installando l’X-Pack di Kibana

viene fornito un tool, Grok Debugger, che permette di simulare come viene

analizzato il testo in input e se il match tra il messaggio e la struttura avviene

correttamente [18].

E’ stato accennato in precedenza che generalmente ad ogni evento di log è

associato un timestamp, ovvero una marca temporale che indichi data e ora in cui

quell’evento si è verificato. Per analizzare informazioni temporali viene utilizzato

il plugin date. Attraverso l’opzione di configurazione match si può specificare sia

il nome che si vuole assegnare al campo che i possibili formati in cui si può trovare

l’informazione.

Con questa configurazione, ad esempio, si sta definendo che nel log in analisi si

possono trovare timestamp in tre formati differenti. Nei primi due viene effettuata

una corrispondenza diretta, utilizzando una sintassi che prevede l’uso di lettere,

spazi e punti per indicare l’esatto formato in cui si troveranno [19]. Con l’ultimo

invece si utilizza il pattern di Logstash ISO 8601 per poter analizzare date che

appartengono al relativo standard.

L’ultimo filtro plugin di nostro interesse è il filtro mutate. Viene utilizzato per

21

apportare modifiche generali ai campi, quali possono essere: copiare, modificare,

rimuovere o effettuare conversioni di tipo. L’opzione di configurazione gsub

permette di rimpiazzare porzioni di stringhe, riceve in input un vettore di tre

elementi, rispettivamente: il nome del campo di tipo stringa al quale apportare la

modifica; il carattere da sostituire ed il carattere con il quale rimpiazzarlo. La

seguente configurazione sostituisce tutti gli slash del campo stringa con degli

underscore.

2.2.3 Output plugins

Gli output plugins vengono utilizzati per mandare gli eventi strutturati verso le

destinazioni di interesse [20]. Logstash supporta una grandissima varietà di plugin

di output, segue la descrizione di alcuni nella seguente tabella:

Output Descrizione

elasticsearch Immagazzina i dati in Elasticsearch

file Scrive gli eventi in un file

email Manda le informazioni raccolte a uno specifico indirizzo email

jms Indirizza gli eventi ad un Broker JMS

pipe Canalizza le informazioni verso un altro programma di standard input

stdout Stampa gli eventi sullo standard di output

Per configurare un plugin di output in modo tale da indirizzare gli eventi in uno

22

specifico indice di Elasticsearch, bisogna specificare attraverso due opzioni di

configurazione l’url dell’host, o degli hosts, ed il nome dell’indice all’interno del

quale si vogliono memorizzare i dati.

2.3 Kibana

Per completare lo stack ELK e scaricare Kibana è sufficiente navigare nella

sottosezione dedicata della pagina download e scaricare l’archivio nel formato

desiderato. Una volta estratto il contenuto si può aprire il file kibana.yml, che si

trova nella sottocartella config, e modificare il campo elasticsearch.url per

specificare su quale istanza Elasticsearch lavorare. Per avviare ed interagire con

Kibana è quindi necessario eseguire kibana.bat, che si trova nella sottocartella bin,

e navigare all’indirizzo http://localhost:5601 da un qualsiasi browser. La

pagina che si aprirà contiene un menu attraverso il quale è possibile accedere alle

differenti funzionalità di Kibana [21].

Discover: Permette di visualizzare ed effettuare query sui dati contenuti negli

23

indici Elasticsearch. Dopo aver selezionato l’indice mediante l’apposito

menu a tendina, per cercare una parola è sufficiente digitarla nella barra di

ricerca in cima alla pagina. Se invece si vuole cercare gli eventi che

contengono una parola in uno specifico campo si può digitare

campo:parola.

Visualize: Utilizzato per creare e salvare viste predefinite.

Dashboard: Permette di comporre ed integrare viste di tipo diverso in una

singola pagina, creando un’interfaccia completa.

Timelion: Fornisce l’accesso al relativo plugin, per creare e visualizzare

serie temporali.

Management: Permette di visualizzare i pattern degli indici e di

personalizzare impostazioni avanzate.

Dev Tools: Kibana mette a disposizione un plugin Console, ovvero

un’interfaccia utente, per interagire con le REST API di Elasticsearch.

24

Capitolo 3: Analisi di un log operazionale

Con il seguente capitolo si vuole mostrare come utilizzare la suite presentata per

analizzare gli eventi di log relativi ad un sistema per l’Air Traffic Control.

3.1 Descrizione del sistema

Il sistema di riferimento è un middleware per l'Air Traffic Control (ATC) che

consente l'integrazione di differenti applicazioni ATC legacy, come Flight Data

Processors (FDPs) e Controller Working Positions (CWPs). Il middleware è

composto da due layer: communication layer ed adapting layer. Il communication

layer consente la comunicazione tra le applicazioni, secondo il paradigma publish-

subscribe, mentre l'adapting layer permette alle applicazioni di utilizzare il

middleware ed i suoi servizi.

I log fanno riferimento a diverse run del sistema: una in condizioni di

funzionamento nominali, ovvero la Golden Run; le altre invece in presenza di

fallimenti del sistema quali crash o comportamenti errati. Durante ogni run sono

stati raccolti due log testuali generati dal middleware, cioè server.log ed ospl-

info.log, ed un log contenente tracciati numerici generato da un tool di monitoring.

I log testuali contengono rispettivamente le log entry generate dal communication

layer del middleware e le log entry generate dal middleware. I tracciati numerici

contengono, invece, statistiche sull'utilizzo delle risorse di sistema da parte del

processo che esegue il middleware [22].

25

3.2 Raccolta dei log

La prima operazione da compiere è preparare un file di configurazione per

raccogliere i dati con Logstash ed indirizzarli in Elasticsearch. Per facilitare la

successiva analisi e visualizzazione si è scelto di creare un indice per ogni run ed

importare in ognuno di essi i tre rispettivi file di log.

3.2.1 Tracciati numerici

Il file di log relativo ai tracciati numerici presenta al suo interno eventi disposti su

singola riga, ciascuna composta da 25 informazioni numeriche. Si costruisce il file

di configurazione come segue:

Nella sezione di input si è utilizzato il plugin file, utilizzando l’opzione di

configurazione type per dare un nome al tipo dei documenti che corrisponderà poi

al type in Elasticsearch. Per la sezione filter si è utilizzato il plugin grok,

aggiungendo ai parametri di sintassi e semantica già illustrati nel precedente

26

paragrafo anche il tipo del campo a cui verrà fatto corrispondere in Elasticsearch. Il

timestamp degli eventi è nel formato UNIX_MS, per cui si è scelto di utilizzare

come sintassi del campo la parola chiave POSINT, ovvero intero positivo, ed

utilizzare successivamente il plugin date per indicare che quel campo rappresenta

un data in formato Unix con millisecondi. Infine sono state indicate come

destinazioni di output l’indirizzo dell’host Elasticsearch e lo standard output, con

l’aggiunta del codec rubydebug, per monitorare da terminale, in un formato

facilmente leggibile, il corretto avanzamento delle operazioni [23].

Lanciando il comando logstash -f conf_file.conf viene fatta partire la

pipeline ed effettuata la connessione con l’istanza Elasticsearch, in questo modo gli

eventi di log contenuti nei file di input vengono processati e mandati alle

destinazioni specificate.

Figura 3.1 Evento processato e mandato a stdout

3.2.2 Log testuali

I due log testuali differiscono da quello appena visto poiché gli eventi si trovano

disposti su più righe. Nel file ospl-info.log, infatti, gli eventi sono delimitati tra

loro da una serie di simboli “=”, mentre in server.log ogni evento inizia con un

timestamp in formato ISO 8601. Vediamo dunque come impostare i due file di

27

configurazione utilizzando il codec multiline.

Il codec multiline è stato impostato in maniera tale da unire tutte le righe che non

iniziano con un timestamp a quella precedente. Si è utilizzato poi anche l’opzione

gsub per trasformare in spazi tutti i caratteri di terminazione di riga derivati

dall’utilizzo del codec. Il codec multiline presente nel file di configurazione

relativo a ospl-info.log è analogo, con la sola differenza che in quel caso il pattern

dell’identificativo dell’evento multiline è una serie di “=”.

3.3 Analisi e visualizzazione

Una volta raccolti i file di log relativi alle runs all’interno dei rispettivi indici in

Elasticsearch si può procedere ad utilizzare Kibana per monitorarli. La prima

operazione da svolgere è creare un index pattern per ogni indice che è stato

generato. Per far ciò è necessario scegliere la voce management dal menu di

28

Kibana e digitare il nome dell’indice. Sempre sotto la scheda management si

possono osservare sulla sinistra tutti gli index pattern creati e, navigando in ognuno

di essi, i relativi campi, tipi ed ulteriori informazioni.

3.3.1 Condizioni nominali

Si analizzano nel seguito alcune informazioni contenute nei file di log relativi alla

Golden Run, ovvero un’esecuzione nominale del sistema. E’ utile, ad esempio,

analizzare l’andamento della CPU nel tempo attraverso un Timelion. Segue

l’espressione da costruire per visualizzare la time line desiderata:

Per ogni line che vogliamo rappresentare su un solo grafico bisogna inserire

un’espressione che inizi con .es e che riceva i seguenti argomenti in input:

Index: rappresenta l’indice dal quale devono essere reperite le informazioni.

Timefield: è il campo temporale sul quale si costruisce la serie.

Metric: indica la metrica da rappresentare sull’asse delle ordinate e il tipo di

aggregazione, nel nostro caso abbiamo scelto avg (che sta per average,

media).

Come accennato in precedenza, all’occorrenza si può aggiungere un argomento

offset per confrontare eventi relativi ad intervalli temporali differenti. Le singole

espressioni sono separate tra loro da una virgola e ad ognuna di esse si possono

aggiungere un gran numero di funzioni per migliorare la visualizzazione. In questo

caso si è scelto di utilizzare: label, che permette di assegnare un’etichetta nella

legenda; lines per modificare la larghezza delle linee e per indicare se si vuole

riempire l’area sottesa alla stessa ed infine color che permette di modificare il

colore della linea. Eseguendo l’espressione si ottiene il seguente grafico:

29

Figura 3.1 Andamento CPU Golden Run

Il plugin Timelion permette, tramite il comando add nella barra in alto, di creare

altre time line e di visualizzarle in un’unica pagina. In questo modo si possono

affiancare più visualizzazioni, per riga o per colonna, e monitorarle con più

semplicità. Se si vogliono, invece, visualizzare contemporaneamente non solo serie

temporali, ma anche grafici a torta, metrici o altri tipi offerti è più conveniente

utilizzare una dashboard. Un altro parametro interessante da monitorare è l’utilizzo

della Ram. Per costruire la time line ci si serve di un’espressione molto simile a

quella vista in precedenza, modificando opportunamente il campo metric e

l’etichetta.

Figura 3.2 Utilizzo Ram Golden Run

30

3.3.2 Presenza di failure

Adesso si vuole confrontare gli stessi comportamenti all’interno della run

v_networkQueue.i_OWVAV_10 dove si verifica un erratic.

Figura 3.3 Andamento CPU v_networkQueue.i_OWVAV_10

Figura 3.4 Utilizzo RAM v_networkQueue.i_OWVAV_10

Si nota facilmente che la percentuale di utilizzo della CPU è incrementata

notevolmente rispetto alle condizioni nominali di funzionamento del sistema.

Inoltre si è verificato anche un leggero incremento nell’utilizzo della RAM, che in

precedenza rimaneva pressoché costante.

I due grafici analizzati sono relativi entrambi al file di log contenente tracciati

numerici, si vuole integrare adesso queste informazioni con altre derivanti dai log

testuali. E’ interessante, ad esempio, analizzare l’andamento della CPU al

31

verificarsi di messaggi di warning. Per far ciò risulta necessaria la creazione di una

dashboard. Prima di procedere alla sua creazione però, bisogna creare le

visualizzazioni che vi si integreranno successivamente. Per monitorare un

eventuale rialzo nell’utilizzo della CPU all’occorrenza di messaggi di warning si

utilizza una time line. L’espressione Timelion che genera il grafico desiderato è la

seguente:

Rispetto a quelle viste in precedenza questa presenta un ulteriore argomento di tipo

query in cui viene specificato il campo ed il testo da filtrare. Si è infine scelto

come tipo di aggregazione count sul campo msg. In questo modo si visualizzano

nella time line il numero di occorrenze di messaggi il cui campo msg è uguale a

WARN. Per completare la dashboard si creano un grafico a torta che mostri la

percentuale di messaggi di warning ed uno per il conteggio totale delle occorrenze.

Una volta impostate tutte le visualizzazioni da utilizzare, per creare la dashboard si

naviga nell’apposita sezione del menu Kibana e, scelto l’indice su cui lavorare, si

aggiungono e si dispongono a piacimento le visualizzazioni da utilizzare.

32

Si evince praticamente a colpo d’occhio che la CPU ha un improvviso picco

nell’utilizzo al verificarsi di un numero di messaggi di warning più elevato. La

dashboard costituisce, quindi, una soluzione ancora più completa per analizzare e

monitorare i dati indicizzati in Elasticsearch grazie alla possibilità di integrare in

un’unica interfaccia sia serie temporali che altri tipi di grafici.

33

Conclusioni

Con l’avvento dei log e dei sistemi distribuiti è nata la necessità di utilizzare strumenti

in grado di fornire un supporto completo all’analisi degli stessi. Dopo aver analizzato

le caratteristiche dei componenti della suite ELK: Elasticsearch, Logstash e Kibana, e

mediante alcuni esempi in cui si illustrano alcune delle funzionalità offerte da essi, si è

dimostrato come la suite si presti perfettamente alla risoluzione di questo problema. La

licenza open-source, il supporto a sistemi operativi differenti, l’ampia documentazione

e la facilità di utilizzo senza necessitare di competenze troppo specifiche o avanzate,

fanno sì che i tre strumenti costituiscano una delle migliori scelte in circolazione per la

raccolta, l’analisi e il monitoraggio di file di log.

34

Bibliografia

[1] Marcello Missiroli, Tecnologia e progettazione per il mondo digitale e per il web

III, Digital Index, 2016

[2] Cosimo Accoto, Misurare le Audience in Internet, FrancoAngeli, 2007

[3] Monitor Ware, http://www.monitorware.com/en/logsamples/apache.php,

consultato il 01/08/2017

[4] Francesco Ficetola, http://www.francescoficetola.it/2016/12/27/bigdata-elk-stack-

elasticsearch-logstash-kibana/, consultato il 01/08/2017

[5] The Dude Abides, http://thedudeabides.com/articles/the_birth_of_compass,

consultato il 27/07/2017

[6] The Dude Abides, http://thedudeabides.com/articles/the_future_of_compass,

consultato il 27/07/2017

[7] DB-Engines, https://db-engines.com/en/ranking/search+engine, consultato il

27/07/2017

[8] Elastic, https://www.elastic.co/, consultato il 02/08/2017

[9] W3ii.com, http://www.w3ii.com/elasticsearch/elasticsearch_quick_guide.html,

consultato il 02/08/2017

[10] IBM, Pessimistic vs Optimistic concurrency control, https://www.ibm.com,

consultato il 02/08/2017

[11] Elastic, https://www.elastic.co/blog/welcome-jordan-logstash, consultato il

04/08/2017

[12] Elastic, https://www.elastic.co/products/kibana, consultato il 04/08/2017

[13] Elastic, https://www.elastic.co/blog/timelion-timeline, consultato il 05/08/2017

35

[14] Yaml, http://www.yaml.org/, consultato il 05/08/2017

[15] Elastic, https://www.elastic.co/guide/en/logstash/5.4/input-plugins.html,

consultato il 05/08/2017

[16] Elastic, https://www.elastic.co/guide/en/logstash/5.4/plugins-codecs-

multiline.html, consultato il 06/08/2017

[17] GitHub, https://github.com/hpcugent/logstash-patterns/blob/master/files/grok-

patterns, consultato il 07/08/2017

[18] Grok Debugger, https://grokdebug.herokuapp.com/, consultato il 09/08/2017

[19] Elastic, https://www.elastic.co/guide/en/logstash/5.4/plugins-filters-

date.html#plugins-filters-date-match, consultato il 11/08/2017

[20] Elastic, https://www.elastic.co/guide/en/logstash/5.4/output-plugins.html,

consultato il 16/08/2017

[21] Elastic, https://www.elastic.co/guide/en/kibana/5.4/introduction.html, consultato

il 16/08/2017

[22] Characterizing Direct Monitoring Techniques in Software Systems

M. Cinque, D. Cotroneo, R. Della Corte, A. Pecchia

IEEE Transactions on Reliability 65 (4), 1665-1681

[23] Elastic, https://www.elastic.co/guide/en/logstash/5.4/plugins-codecs-

rubydebug.html, consultato il 16/08/2017