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