1. 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:

2. 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 )

3. Architettura del progetto

4. 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

5. 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

6. 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

7. 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

8. Configurazione del LogStash Indexer

9. 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

10. Diagramma progettuale di Advisor. Diagramma progettuale di S3.

11. 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.

12. 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

13. 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