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.
As technology continually evolves, keeping our software stack up to date is essential for performance, security, and access to new functionalities. In this post, I want to share how we upgraded MariaDB from version 10.3 to 10.11 as part of Read More
In some test or development environments, you may need to simulate the presence of GSM modems without having an actual physical device. This can be useful for example when testing monitoring checks, SMS management systems, or creating new notification rules. Read More
Just like last year, we had the wonderful opportunity to attend FOSDEM, the most important open source conference in Europe. This year was no exception, and among the many exciting talks, one that particularly caught my attention was Alex Stefanini’s Read More
When designing an Elasticsearch architecture, choosing the right storage is crucial. While NFS might seem like a convenient and flexible option, it comes with several pitfalls when used for hosting live Elasticsearch data (hot, warm, cold, and frozen nodes). However, Read More
When using Kibana in environments that require a proxy to reach external services, you might encounter issues with unrecognized SSL certificates. Specifically, if the proxy is exposed with its own certificate and acts as an SSL terminator, requests made by Read More