Tutor: Stefano Dindo Follow me on Twitter @stefanodindo

Progetto Open per l’analisi dei log in

tempo reale di architetture Cloud

Laureando: Mattia Peterle

Site: www.zero12.it Twitter: @zero12srl

LOGSTASH:

Realizzare un sistema di log Analysis: • Dinamico • Scalabile • Portabile su diversi servizi con un unico backend • Autonomo • Capace di monitorare in tempo reale i log dei server di DriveFarm con notifiche tramite email e conservazione dei log anche dopo il termine di una risorsa di computazione

Scopo del progetto

( Istanze EC2 di Amazon Web Services )

Architettura del progetto

L’architettura alla base del sistema di Log Analysis prevede l’utilizzo di:

REDIS: Database utilizzato come Broker per la trasmissione degli

Eventi

LOGSTASH: Software principale

per la manipolazione degli Eventi

L’architettura alla base del sistema di Log Analysis prevede l’utilizzo di:

KIBANA: Web-App per la

visualizzazione dei Log, effettua query

ad ElasticSearch

ELASTICSEARCH: Motore di ricerca e

indicizzazione, indicizza i Log da

LogStash

.

Obiettivo -> Rispettare la scalabilità richiesta dal Software as a Service DriveFarm. Conseguenza -> Istanziare dei LogStash sulle macchine virtuali in cui viene eseguito DriveFarm (AMI poichè si usa infrastruttura AWS) che inviino gli eventi al Broker Redis presente in un calcolatore centrale.

VANTAGGI L’integrazione di LogStash in

modalità «shipper» nelle istanze di DriveFarm non

richiede l’intervento umano per la configurazione in

quanto tutti i log vengono inviati ad un nodo centrale

per l’elaborazione.

SVANTAGGI Nell’attuale architettura è

prevista solo un’istanza centrale di Log Stash

designata alla manipolazione dei Log. Questa

configurazione può rappresentare un possibile

collo di bottiglia nell’attività di Log Analysis

Classificazione e gestione Log Gli Eventi raccolti dal LogStash « indexer » devono subire due processi:

ElasticSearch: per indicizzare i Log e richiederli attraverso Kibana.

GESTIONE ALLE USCITE:

Grep: per rimuovere o marchiare degli eventi.

Grok: per istaurare campi di metadati e trasformare gli Eventi in Log.

Multiline: per gestire la presenza di StackTrace attraverso Regexp.

Advisor: per la temporizzazione di messaggi da inviare in Output.

CLASSIFICAZIONE ATTRAVERSO FILTRI:

SNS: per inviare mail d’avviso contenenti messaggi di Advisor. S3: per lo stoccaggio dei Log d’interesse su un Bucket sicuro

Configurazione del LogStash Indexer

Causa: Supportare SNS affinché limitasse lo spam d’informazioni superflue.

Conservare Log importanti per future rivisitazioni. (Asincronicità)

Sviluppi: •  Advisor: due funzionalità principali gestite da un Thread

dormiente. La possibilità di clonare il primo diverso Evento che si manifesta nell’arco di un tempo t e spedirlo nella coda di LogStash. La costruzione di un evento il cui corpo è un elenco del numero di

diversi eventi raccolti in un tempo t. •  S3: implementare le API di Amazon e costruire un’estensione che: Spedisca sul Bucket file di Log dopo un tempo t o una dimensione

m. Introduca un sistema «Restore» e uno standard di denominazione

file.

Modifiche: Multiline per bug su StackTrace, SNS per bug ARN e link http Kibana.

Estensione software

Diagramma progettuale di Advisor. Diagramma progettuale di S3.

Es. «advisor_first» •  Email inviata da SNS. •  Primo diverso evento, clonato (viene scartato da ElasticSearch) ed inviato. •  Filtro Multiline per StackTrace. •  Si ripresenta se incombe allo scadere di «time_adv». • Link Kibana per UI rapida.

Es. «advisor_info» •  Email inviata da SNS. •  Racchiude il numero di eventi che si sono manifestati. •  Il corpo degli eventi è limitato (taglia di SNS). •  Allo scadere di «time_adv» il ciclo si ripete per i nuovi eventi

Risultati Benefici per zero12

Contributo community logstash:

Lo sviluppo del sistema di log Analysis ha permesso di: •  Ricevere notifiche tramite e-mail in tempo reale in caso di errori sul servizio DriveFarm •  Disponendo di un’infrastruttura scalabile in cui le risorse possono essere rilasciate è stato possibile conservare i log di errori per la loro risoluzione anche dopo il termine di una risorsa di computazione •  Garantire una risposta tempestiva agli errori migliorando il servizio al cliente •  Sviluppare statistiche sui LogLevel d’arrivo e sull’accesso all’applicativo. •  Disporre di un ambiente di log analysis flessbile e dinamico in base alle diverse sorgenti da monitorare.

L’attività e la qualità del servizio prodotto con questa attività di sviluppo è stata riconosciuta dalla comunità di logstash che ha approvato nel repository ufficiale i plugin sviluppati: https://github.com/logstash/logstash/blob/master/lib/logstash/filters/advisor.rb https://github.com/logstash/logstash/blob/master/lib/logstash/outputs/s3.rb