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:
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:
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. 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
Juergen Vigna
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. 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.
IPMI (the Intelligent Platform Management Interface) has been the de facto standard for managing and monitoring computer hardware for many years, but as Intel explicitly stated here no further updates to the IPMI specification are planned or should be expected. Read More
In a previous article I analyzed how you can create effective visualizations in Kibana, and how to apply machine learning jobs with the goal of extracting as much information as possible from our data. However, you can also think of Read More
ITOA ITOA is the NetEye component which represents time series data using the Grafana graphics engine. Data is usually collected by Telegraf agents and stored into an InfluxDB specialized non-relational database. Flux In order to manipulate the time series data, Read More
The Cyber Apocalypse CTF is back with the 2022 edition. It’s a Jeopardy-style competition organized by Hack The Box and is open to everyone. Together as a security-focused guild (a concept taken from the Spotify model) we here at Würth Read More
The correct configuration and scheduling of downtime is an essential element of a monitoring system for several reasons: Mitigating notificationsProviding IT operations and Service Desk teams with timely information about when monitored systems may be subject to faults due to Read More