11. 04. 2024
Business Service Monitoring, NetEye, SLM
Vor einiger Zeit habe ich einen Artikel veröffentlicht in dem ich beschrieben habe wie Logs vom NetEye SMS Protokoll in einer ELK-Umgebung gespeichert werden können. Jetzt, nachdem ich es einige Male selbst wie beschrieben implementiert habe, habe ich bemerkt, dass es leider nicht ganz korrekt funktioniert. Das kommt daher, dass die Time/Date Funktionen für Logstash-Filter etwas kompliziert sind.
Konkret, ist das Datum im File des SMS-Protokolls so geschrieben:
June 29th 2016, 10:30:22 CEST 2016
Und wir benutzten den Logstash Datumsfilter um es zu konvertieren:
date {
locale = "en"
match = [ "sms_timestamp_text", "EEE MMM dd HH:mm:ss" ]
}
Auf den ersten Blick schien es zu funktionieren, aber nach einiger Zeit (ein paar Tage nach Beginn des nächsten Monats), haben wir bemerkt, dass das Datum der ersten Tage im Monat so aussah:
July 1th 2016, 10:30:22 CEST 2016
Da wir eine textuelle Zeitzone hatten und Logstash Datumsfilter dies nicht unterstützen, hatten wir diese Regel um den sms_timestamp_text zu parsen:
match =>[ "message", "%{SMS_TIMESTAMP_SHORT:sms_timestamp_text}
%{WORD:timezone} %{YEAR}:%{INT:sms_phonenumber}:%{GREEDYDATA:sms_text}"
Das sind die Pattern die wir dafür verwenden würden:
SMS_TIMESTAMP_SHORT %{DAY} %{MONTH} +%{MONTHDAY} %{TIME}
SMS_TIMESTAMP %{SMS_TIMESTAMP_SHORT} %{WORD:tz} %{YEAR}
Theoretisch würde das alles funktionieren, aber…
Wir haben erkannt, dass unsere Filter nicht richtig funktionierten, da wir „dd“ für zweistellige Tage verwenden. Was machen wir nun wenn ein Datum weder bei „d“ noch bei „dd“ passt? Nachdem ich mir die Filter-Regeln genauer angeschaut habe, habe ich die Lösung gefunden. Es ist möglich „or“ Regeln innerhalb eines Datums zu definieren und somit mehreren Datumsformaten zu entsprechen:
date {
locale = "en"
match => [ "sms_timestamp_text", "EEE MMM dd HH:mm:ss Z yyyy", "EEE MMM d HH:mm:ss Z yyyy" ]
}
Sie sehen den neuen Z und yyyy Parameter, denn wenn kein genaues Datum passt, kann es nicht richtig funktionieren. Um richtig zu parsen, muss der Pattern-Match folgendermaßen geändert werden:
match => [ "message", "%{SMS_TIMESTAMP:sms_timestamp_text}:%{INT:sms_phonenumber}:%{GREEDYDATA:sms_text}" ]
Wie vorhin erwähnt, kann Logstash textuelle Zeitzonen nicht parsen, aber genau diese Situation haben wir hier. Was sollen wir also tun?
Wir wissen, dass unser Datum in westeuropäischer Zeit ist, deshalb haben wir eine Lösung um diesen Tag umzuwandeln:
mutate {
gsub => ["sms_timestamp_text", "CEST", "+0200"]
}
mutate {
gsub => ["sms_timestamp_text", "CET", "+0100"]
}
So funktioniert der Z-Tag und wir parsen das Datum im richtigen Format.
Problem gelöst. Logs können korrekt geparst werden.
Juergen Vigna
NetEye Solution Architect at Würth Phoenix
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
Latest posts by Juergen Vigna
23. 02. 2024
Log-SIEM, NetEye, Unified Monitoring
Monitoring Logs in Elasticsearch: A Practical Example
30. 11. 2023
Log Management, Log-SIEM, NetEye, Unified Monitoring
Monitor Your Elasticsearch Agents Registered in the Elastic Fleet Server
28. 04. 2023
Icinga Web 2, NetEye, Unified Monitoring
Elasticsearch Snapshots and How to Monitor Them