Qualche tempo fa pubblicai un articolo sull’utilizzo del NetEye Log Management per la visualizzazione delle notifiche SMS. Ora, in base all’esperienza acquisita, ho scoperto che ciò che scrissi non era totalmente corretto. Infatti le funzioni di time/date per i filtri Logstash sono leggermente più complicate di ciò che possono sembrare inizialmente. In particolare, la data era scritta nel protocollo SMS nel seguente modo:
June 29th 2016, 10:30:22 CEST 2016
E avevamo utilizzato questo filtro per convertirla:
date {
locale = "en"
match = [ "sms_timestamp_text", "EEE MMM dd HH:mm:ss" ]
}
Col passare del tempo (alcuni giorni dopo l’inizio del mese successivo) abbiamo scoperto però che la data nei primi giorni del mese veniva visualizzata nel seguente modo:
July 1th 2016, 10:30:22 CEST 2016
Poiché utilizziamo un timezone testuale, abbiamo infatti constatato che i filtri applicati sulla data non lo supportano. Nel primo draft abbiamo utilizzato questa regola per riuscire ad eseguire il parse dell’sms_timestamp_text:
match =>[ "message", "%{SMS_TIMESTAMP_SHORT:sms_timestamp_text}
%{WORD:timezone} %{YEAR}:%{INT:sms_phonenumber}:%{GREEDYDATA:sms_text}"
Questi sono i pattern che abbiamo quindi pensato di utilizzare:
SMS_TIMESTAMP_SHORT %{DAY} %{MONTH} +%{MONTHDAY} %{TIME}
SMS_TIMESTAMP %{SMS_TIMESTAMP_SHORT} %{WORD:tz} %{YEAR}
In questo modo tutto sembra funzionare correttamente, ma non è così…
Infatti abbiamo scoperto che il nostro filtro non funziona ancora correttamente poiché abbiamo inserito due cifre per il giorno “gg”. Come possiamo quindi risolvere questo problema dato che la data non può essere definita né con una sola cifra “g” né con due “gg”? Dopo aver approfondito tale problematica abbiamo trovato la soluzione più appropriata. È infatti possibile avere “or” come regola all’interno della data e in questo modo poterla far combaciare con il formato della data. Per cui abbiamo modificato il filtro in questo modo:
date {
locale = "en"
match => [ "sms_timestamp_text", "EEE MMM dd HH:mm:ss Z yyyy", "EEE MMM d HH:mm:ss Z yyyy" ]
}
Potete vedere la nuova Z e i parametri yyyy perché se non facciamo combaciare la data completa non può funzionare correttamente. Per essere in grado di analizzare questo correttamente, ho scoperto che il modello utilizzato doveva essere cambiato nel seguente modo:
match => [ "message", "%{SMS_TIMESTAMP:sms_timestamp_text}:%{INT:sms_phonenumber}:%{GREEDYDATA:sms_text}" ]
Come anticipato prima, Logstash non può analizzare i fusi orari testuali (textual time zone). E allora perché lo abbiamo inserito e come dobbiamo comportarci? Sappiamo che la nostra data coincide con il fuso orario dell’Europa occidentale, perciò la soluzione consiste nel mutare il tag nel seguente modo:
mutate {
gsub => ["sms_timestamp_text", "CEST", "+0200"]
}
mutate {
gsub => ["sms_timestamp_text", "CET", "+0100"]
}
In questo modo il tag Z può funzionare e abbiamo analizzato la data nel giusto formato.
Problema risolto: i logs possono essere analizzati correttamente!
Juergen Vigna
NetEye Solution Architect at Würth IT Italy
I have over 20 years of experience in the IT branch. After first experiences in the field of software development for public transport companies, I finally decided to join the young and growing team of Würth Phoenix (now Würth IT Italy). Initially, I was responsible for the internal Linux/Unix infrastructure and the management of CVS software. Afterwards, my main challenge was to establish the meanwhile well-known IT System Management Solution WÜRTHPHOENIX NetEye. As a Product Manager I started building NetEye from scratch, analyzing existing open source models, extending and finally joining them into one single powerful solution. After that, my job turned into a passion: Constant developments, customer installations and support became a matter of personal. Today I use my knowledge as a NetEye Senior Consultant as well as NetEye Solution Architect at Würth Phoenix.
Author
Latest posts by Juergen Vigna
22. 05. 2025
NetEye, Unified Monitoring
Automatic Integration of NagVis Map into Icinga Web 2/NetEye Monitoring