NXLog Community Edition
Syslog ist das vergleichbare Gegenstück zum Windows Eventlog. Systeme können ihre Meldungen an einer zentralen Stelle hinterlassen. Und viele Jahre lang habe ich einfach den KIWI-Syslog-host verwendet, welcher als kommerzielle Software aber auch als Freeware verfügbar ist. Zugegeben hat die kostenfreie Version einige Einschränkungen aber bislang hat mich das nicht gestört, um z.B. die Logs von einem Audiocodes Mediant auf einem Server als Datei für spätere Auswertungen zu speichern. Nachdem aber mein Lync Server auf Windows 2012 mit Lync 2013 migriert wurde, konnte ich Kiwi nicht mehr zum laufen bekommen. Ich hatte wie bisher die Kiwi Eval installiert und darauf vertraut, dass Sie nach 30 Daten dann in den "FreeWare" Mode zurück fällt. Aber nach 30 Tagen lief die Software einfach nicht mehr. Selbst eine Deinstallation und die Installation der nicht einfach zu findenden Freeware hat immer noch einen "Nicht lizenziert"-Status ergeben.
Ich habe dann etwas rumgeschaut, was es an anderen Syslog Daemons für Windows gibt, die diese Funktion ersetzen und vielleicht noch besser machen konnten. Schließlich wollte ich nicht selbst einen SYSLOGD schreiben, auch wenn das anscheinend sehr einfach ist.
Anforderungen
Wenn man schon mal das Programm wechselt, dann sollte die neue Lösung auch den Anforderungen entsprechen. Das hier sind meine:
- Windows Dienst
Auch wenn SYSLOG aus der *NIX Umgebung kommt, so bewege ich mich primär im Windows Umfeld und meine Kunden ebenfalls Ich wollte nun keine Unix-VM irgendwo nur für SYSLOG mitlaufen lassen. - Einfache Konfiguration
Ich brauche keine GUI. Eine einfache Textdatei, die man schnell anpassen und kopieren kann, ist mir fast lieber als eine GUI, die man erst durchklicken muss. - Separierung nach Source-IP
Wer mehrere Gateways betreibt, möchte am Ende nicht in einer großen Textdatei die Zeilen voneinander trennen. Eine eigene Protokolldatei pro Source-IP ist das Mindeste. - Logdateien mit Zeitstempel
Zudem sollte das Log pro Device auch noch mit einem Zeitstempel versehen sein, damit man schnell die "richtige" Datei zur Analyse zu Hand hat. Ich schreibe gerne je Stunde eine Datei. - Abtrennung der Audiocodes
CDR-Einträge
Mein Mediant 1000 sendet per SYSLOG nicht nur seine Trace-Ausgaben sondern optional auch Einzelverbindungsdatensätze (CDR). Beides landet im SYSLOG aber der SYSLOGD sollte z.B.: über Reguläre Expressions die unterschiedlichen Datensätze in getrennte Dateien abspeichern. - Optional Alarmierung und
Aktionen
Nicht zwingend erforderlich aber schön wäre schon eine Funktion, auf bestimmte Einträge zu reagieren und z.B. Alarme zu versenden.
Ich habe schon etwas suchen müssen, denn Google und Co werfen bei SYSLOG und WINDOWS ganz viele Treffer aus. Es gibt einige OpenSource-Projekte von denen viele aber entweder kein Dienst sind oder sonst wie mir unsicher erscheinen. Kommerzielle Tools gibt es auch, die aber wieder beschränkt sind. Aber zufällig habe ich dann NXLog gefunden und dies erfüllt ALLE meine Anforderungen.
NXLog Setup und Features
NXLog ist ein Tausendsassa, der nicht nur Meldungen von verschiedenen Quellen (u.a. auch UDP 514) annehmen, sondern auch an verschiedene Ziele weiter geben kann.
Download
http://sourceforge.net/projects/nxlog-ce/files/latest/download?source=files
PDF-Beschreibung
http://nxlog.org/nxlog-docs/en/nxlog-reference-manual.pdf
Die Installation als MSI-Datei erlaubt nicht einmal die Eingabe des Installationsziel. Es landet immer in C:\Program Files (x86)\nxlog. Auch der Dienst wird schon automatisch installiert, auf automatischen Start gestellt aber nicht direkt gestartet.
Starten Sie den Dienst jetzt noch nicht. Sie müssen erst eine Konfigurationsdatei erstellen und ggfls. in der Windows Firewall noch Ports öffnen.
Alle andere spielt sich dann in den Unterverzeichnissen ab, die eher eine *NIX-Design entsprechen. NXLog ist aber eine reinrassiger Windows Dienst.
Die Konfiguration lieg im Verzeichnis "conf" mit dem Namen "nxlog.conf". Alle Aktionen des Programms selbst protokolliert NXLog im Verzeichnis Data. Interessant sind die Extensions, die schon am Prefix vor dem Namen erkennbar sind und in den entsprechenden Verzeichnissen liegen. IM steht für "Input Modules" während "OM" die Output Module" beschreibt. Zusätzlich gibt es Extension Modules (XM) und Processor (PM), die Eingaben verarbeiten und konvertieren können.
Das ganze System ist hoch flexibel und vieleicht schreibe ich später mal einen Processor, der aus dem Syslog eines Gateways die einzelnen Calls als eigene Dateien extrahiert.
Einsatzbereiche
Ich nutze NXLOG hier erst mal um von einem Mediant die Daten per SYSLOG (UDP 514) anzunehmen, über eingebaute REGEX-Regeln zu filtern und dann in Dateien zu schreiben. Sie können damit aber auch z.B. SYSLOG-Meldungen annehmen und in SQL-Datenbanken ablegen. Sie können aber auch Eventlogs einsammeln, per Regelwerg überwachen und als EXE-Task eine Mail senden. Die Flexibilität macht NXLOG so interessant.
Windows 2012
Die Software ist laut Webseite auch mit Windows 7 lauffähig. Sie lässt sich sogar problemlos unter Windows 2012 installieren. Allerdings trägt das Setup keine Firewall-Regeln ein. Das ist verständlich, wenn sie können NXLOG auch allein lokal nutzen und müssen ja keinen SYSLOG-Empfänger einsetzen. Ich möchte aber mit NXLOG per SYSLOG/UDP Pakete empfangen, so dass ich hier Hand anlegen muss. Der Assistent hilft ihnen einfach erst mal das Programm zu addieren.
- Regeltyp: Programm
- Programm: C:\Program Files (x86)\nxlog\nxlog.exe
- Aktion: Verbindung zulassen
- Profil: Domäne
- Name: NXLog Syslog 514 UDP
Danach sollten Sie aber die "ANY"-Erlaubnis noch auf den UDP-Port 514 beschränken:
Mehr Verbindungen müssen auf das Programm eingehend nicht zugelassen werden, zumindest wenn Sie wie bei mir nur SYSLOG per UDP empfangen wollen.
Konfiguration
Für den Anfang möchte ich aber erst mal nur die SYSLOG-Meldungen des Gateways in Dateien schreiben. Die "Freeware" von Kiwi hat keine Separierung erlaubt und nur die Dateinamen konnten dank Platzhalter durchnummeriert werden. mit NXLOG kann ich aber noch viel mehr, so dass ich folgendes umgesetzt habe
- Ausgabe nach
SYSLOG-Quellhost in
Verzeichnisse getrennt
das erleichtert die Suche nach dem fraglichen Event - Stündliche Dateien
Auch das erleichtert die Suche und erspart mir auch das Übertragen von sehr großen Dateien. - Trennung von Syslog und CDR
Ein Mediant kann z.B. auch Verbindungsdatensätze per SYSLOG senden. Kiwi konnte nur auf 514 laufen, NXLog kann auf beliebigen Ports auch parallel lauschen, so dass man einfach einen eigenen Logger für CDR-Records aufsetzen kann oder per Parser die Daten separiert.
Für NXLog gibt es keine GUI sondern einfach eine Textdatei "nxlog.conf", die im Verzeichnis CONF abgelegt wird. für meine Aufgabenstellung ist die Konfiguration noch überschaubar:
#define ROOT C:\Program Files\nxlog define ROOT C:\Program Files (x86)\nxlog Moduledir %ROOT%\modules CacheDir C:\NXLOG Pidfile C:\NXLOG\nxlog.pid SpoolDir C:\NXLOG LogFile C:\NXLOG\nxlog.log <Input syslog514udp> Module im_udp Port 514 Host 0.0.0.0 </Input> <Input syslog514tcp> Module im_tcp Port 514 Host 0.0.0.0 </Input> <Output consolefile> Module om_file File $MessageSourceAddress+"/Syslog-"+ strftime(now(),"%Y-%m-%d-%H") + ".log" # Addiere Zeitstempel an den Event Exec $raw_event = now() + " " + $raw_event; CreateDir TRUE </Output> <Output cdrfile> Module om_file File $MessageSourceAddress+"/CDR/CDR-"+ strftime(now(),"%Y-%m-%d-%H") + ".log" Exec if $raw_event =~ /(<142>|<141>)\[S=\d+\]\s\|(.*) / { \ $raw_event = $2 ; \ } \ else \ drop(); CreateDir TRUE </Output> <Output cdrlogger> Module om_udp Host 127.0.0.1 Port 1514 Exec if $raw_event =~ /(<142>|<141>)\[S=\d+\]\s\|(.*) / { \ $raw_event = $2 ; \ } \ else \ drop(); </Output> <Route udp> Priority 1 Path syslog514udp => consolefile, cdrfile, cdrlogger </Route> <Route tcp> Priority 2 Path syslog514tcp => consolefile, cdrfile, cdrlogger </Route>
Hinweis
Das Input Modul IM_UDP akzeptiert per Default
nur Pakete von "Localhost". Erst der Eintrag
"Host 0.0.0.0" erlaubt die Annahme auf allen
IP-Schnittstellen. Wobei die Windows Firewall
immer noch zusätzlich konfiguriert werden muss.
Danach können Sie den Dienst einfach über die Systemsteuerung starten.
Logausgabe in Dateien
Nachdem die ersten SYSLOG-Meldungen angekommen sind, sollten Sie diese auch in den entsprechenden Verzeichnissen finden. Ich habe diese einfach in dem Verzeichnis DATA angelegt und das Verzeichnis selbst per SMB für die Lync Administratoren (CSAdministratoren und CSVoiceAdministratoren) zum Lesen freigegeben. So können diese Administratoren problemlos auch eine Fehlersuche betreiben.
Hinweis:
Datenschutzregelungen erfordern, dass Sie solche
Daten nicht länger aufheben als erforderlich. In
der Regel sollten Sie die Dateien nach 30-90
Tagen löschen. NXLog macht das nicht aber
Remove-OldFiles
kann dabei helfen.
Achtung
Wenn Sie Log-Dateien öffnen und damit den
Schreibzugriff von NXLOG unterbinden, dann kann
das dazu führen, dass NXLOG nicht mehr weiter
loggt. Ein Neustart des Dienstes löst diese
Blockade.
Regex, Matching und $raw_event
Anhand der guten Beschreibung und einiger Muster war die Basiskonfiguration schnell erstellt, um UDP-Meldungen einfach in eine Textdatei zu schreiben. Aber um meine Anforderungen zu erfüllen, musste ich schon etwas mehr tun.
Zuerst wollte ich, dass die Ausgaben in Dateien mit einem Zeitstempel erfolgen. Also habe ich mit der Konfiguration von "om_file" gearbeitet.
File $MessageSourceAddress+"/Syslog-"+ year(now()) + month(now()) + day(now()) + hour(now()) + ".log"
So war die Lösung schon fast zum greifen nahe, allerdings fehlten die führenden Nullen und wenn der 22.5.2013 als 2013522 statt 20130522 geschrieben wird, dann ist die Sortierung und Anzeige später nicht optimal. Aber ein Kollege hat mir seine Alternative genannt, die wunderbar funktioniert:
File $MessageSourceAddress+"/Syslog-"+ strftime(now(),"%Y-%m-%d-%H") + ".log" CreateDir TRUE
Die Funktion strftime erlaubt die passende Formatierung. Und dank der von "im_udp" schon gesetzten Variable "$MessageSourceAddress" und der Option "CreateDir TRUE" war es ein leichtes, die Ausgaben in verschiedenen Unterverzeichnissen abzulegen.
Etwas kniffliger war hingegen die Auftrennung der Syslog-Einträge nach dem Inhalt, d.h. CDR-Records abzulegen. Ich habe einige Zeit das PDF-Handbuch studiert, um letztlich weder "Processors" noch "Filter" einzusetzen, sondern einfach nur die EXEC-Statements eine Evaluierung durchzuführen.
Die von "im_udp" gesetzte Variable "$raw_event" enthält die empfangene UDP-Message. Allerdings wollte zuerst der reguläre Ausdruck einfach nicht "matchen".
- Irreführende Ausgabe von $raw_event
Wenn ich mit "Exec log_info("#" + $raw_event + "#"); " den Inhalt in das Log schreiben lasse, dann hat das wie folgt ausgesehen. Allerdings muss man wissen, dass der Zeitstempel und der Text "INFO" nicht Inhalt der Variable ist, sondern durch die Funktion "log_info" addiert wird
2013-05-22 19:42:10 INFO #<133>( lgr_flow)(6221198 ) #49:LOCAL_CALL_RELEASED_EV(Trunk 2013-05-22 19:42:10 INFO #<133>( lgr_flow)(6221199 ) | #49:LOCAL_CALL_RELEASED_EV 2013-05-22 19:42:10 INFO #<133>(lgr_media_service)(6221200 ) MscmlSignalFeature Returned to Pool 2013-05-22 19:42:10 INFO #<133>( lgr_flow)(6221201 ) EndPoint channel# 49 ::Active DSP 2013-05-22 19:42:10 INFO #<132>IR:1 [Code:5004] [CID:30] [Time: 05-22-2013@18:42:09]
- Prefix <132> und <142>
Als nächstes kann man schon mal schnell den Prefix übersehen. Das Programm ACSyslog hat diese Information über Facility/Severity einfach unterschlagen, in $raw_event" steht die Information aber drin. Aber das ist sogar gut, da so eine genaue Trennung von "DEBUG"-.Events und CDR-Events möglich ist. - REGEX und ungenaues Matchen
Zuletzt habe ich mit den Tücken der RegEx Evaluierung gekämpft, da ich mit dem Caret (^) und dem Zeilenende ($) gearbeitet habe, aber die wohl gar nicht passen.
# folgendes matcht nicht ($raw_event =~ /\^<142>\|(.*)$/) # das hier aber schon ($raw_event =~ /<142>\|(.*)/)
Aber nach dem diese Hürden genommen waren, konnte ich mit einer IF-Anfrage die CDR-Einträge ausfiltern und sogar noch normalisieren um die Facility und Severity zu entfernen und alle anderen Einträge verwerfen (drop()).
Logausgabe per UDP
Vielleicht haben sie noch einen Abschnitt gesehen, der erst mal verwirrt.
<Output cdrlogger> Module om_udp Host 127.0.0.1 Port 1514 Exec if ($raw_event =~ /<142>\|(.*)/) { \ $raw_event = $1 ; \ } \ else \ drop(); </Output> <Route 1> Path syslog514 => consolefile, cdrfile, cdrlogger </Route>
Diese Ausgabe sorgt dafür, dass die CDR-Daten nicht nur in eine Datei sondern per UDP auch noch an localhost:1514 gesendet werden. Der Port ist in der Regel "frei" aber ich habe ein Programm, welches über diesen Port dann die Call-Daten aufnimmt und in Realtime ermittelt, wer gerade mit wem telefoniert.
Link zum Skript fehlt noch.
Was noch alles geht
Die Kombination aus Input-Modul, Parser und Filter mit RegEx und verschiedene Ausgaben erlauben umfangreiche automatische Analysen. NXLog kann auch Textdateien auswerten, auch wenn diese sich per "Rollover" umbenennen und damit z.B. IISLogs parsen und beim Vorkommen bestimmter Inhalte wieder Aktionen ausführen oder diese in andere Textdateien oder Logs schreiben oder per SYSLOG versenden. Ebenso kann NXLog auch Eventlogs überwachen und entsprechend agieren.
Vielleicht addiere ich später einmal einen Parser, um z.B. die CDR-Records gleich zu zu verändern, dass einfache CSV-Datein heraus kommen oder die Daten direkt in einer SQL-Datenbank landen. Auch könnte ich mir durchaus vorstellen, später die Meldungen auf "Fehler" oder andere kritische Einträge zu überwachen und direkt zu alarmieren. Denkbar wäre auch, dass ausgewählte Informationen wiederum per SYSLOG an ein anderes System (z.B. SCOM) weiter gemeldet werden und NXLOG quasi als Vorfilter agiert.
Sicher zu den anspruchsvolleren Überlegungen gehört der Versucht, anhand der Debug-Logs die Daten der einzelnen Konversationen zu extrahieren und als eigenständige Tracedateien zu speichern, so dass quasi jeder VoIP-Anruf in einer eigenen Datei protokolliert wird.
Weitere Links
- Syslog
- AC Syslog
- AC CDR
- Projektseite
http://nxlog.org/ - http://sourceforge.net/projects/syslog-server
- http://sourceforge.net/projects/syslog-win32
-
SYSLOGLISTENER
http://prtgtoolsfamily.com/us/products/tools/sysloglistener - MegaLog Test Receiver
2.0.0.42 leider kein Dienst
http://www.secureip.de/de/pro-rec.html - EventSentry Light
http://www.eventsentry.com/downloads/full-vs-light
Syslog schreibt er aber einfach ins Eventlog. So nicht zu gebrauchen - Using NXLog with
Elasticsearch and Kibana
https://nxlog.co/news/using-nxlog-elasticsearch-and-kibana
https://nxlog.co/documentation/nxlog-user-guide-full#elasticsearch - Building a Logging Forensics
Platform using ELK (Elasticsearch,
Logstash, Kibana)
http://blog.davidvassallo.me/2015/04/21/building-a-logging-forensics-platform-using-elk-elasticsearch-logstash-kibana/ - Windows Logs mit NXLOG
sammeln
https://www.scip.ch/?labs.20141106