Modul 93_Log2Syslog - FHEM Logs an Syslog-Server leiten und Syslogs empfangen

DS_Starter · 22 August 2017, 08:48:39

Guten Morgen,

die V2.4.1 ist nach ./contrib geladen. Neben kleineren internen Codeänderungen wird das Syslog-Feld PROCID mit einer fortlaufenden Nummer, die sich mit jedem Event/FhemLog um 1 erhöht, gefüllt.
Damit kann man die lückenlose Übertragung zum Syslog-Server nachverfolgen sofern der Syslog-Server dieses Feld mit ausgiebt (nur IETF).
In Splunk sieht man das (siehe Anhang).

Zur Zeit arbeite ich noch an der Integration der TLS-Verschlüsselung zur Übertragung an den Syslog-Server.

VG,
Heiko

DS_Starter · 25 August 2017, 10:38:26

Hallo zusammen,

die Version 2.5.1 ist verfügbar. Nun wird das TLS Transport Prokokoll unterstützt. Ist TLS gewählt, wird automatisch zu TCP umgeschaltet.
Es sind noch ein paar Readings dazu gekommen. Zum Besipiel wird im Fall von TLS die verwendete SSL-Version und der Algorithmus angezeigt.
Das Reading Transfered_logs_per_minute enthält die durchschnittliche Übertragungsrate (logs/minute).

Das ist zusammengefasst der gegenwärtige Stand.

Ich würde mich über ein paar Rückmeldungen zu Tests - auch positive falls nichts auffallen sollte - freuen.

viele Grüße
Heiko

DS_Starter · 27 August 2017, 12:15:47

Die geplant finale Version habe ich nach ./contrib hochgeladen.
Es hat sich noch folgendes geändert:

- es können mehrere LogSyslog-Devices definiert werden (z.B. wenn man die Weiterleitung von FHEM-Logs und Events trennen möchte)
- das Attribut "type" wurde nach "protocol" umbenannt. Type war ein Arbeitstitel.

Das Modul werde ich dann in Kürze einchecken.

VG
Heiko

dtavb · 30 August 2017, 10:16:55

Hey danke für das Modul, gleich aktiviert

Und "plappert" gleich los in Richtung graylog2.

DS_Starter · 30 August 2017, 10:28:55

Hallo dtavb,

super

Könntest du vielleicht ein Screenshot dranhängen und kurz angeben ob du IETF oder BSD benutzt ?
Es ist einfach mal interessant wie gut das Parsing mit anderen Syslog-Produkten als Splunk bzw. Synology Protocolcenter funktioniert.

LG
Heiko

dtavb · 15 September 2017, 06:19:12

Hoi DS_Starter,

ja klar:
Format: IETF

Hier das define:
defmod tosyslog Log2Syslog collector.media.home event:.* fhem:.*
attr tosyslog alias syslog
attr tosyslog icon lan_rs485
attr tosyslog port 8514
attr tosyslog protocol UDP
attr tosyslog room Unsorted

setstate tosyslog active
setstate tosyslog 2017-09-12 05:22:33 SSL_Algorithm n.a.
setstate tosyslog 2017-09-12 05:22:33 SSL_Version n.a.
setstate tosyslog 2017-09-15 06:13:30 Transfered_logs_per_minute 14
setstate tosyslog 2017-09-13 08:56:19 state active

In graylog habe ich ein Input-Objekt definiert, ohne weitere Angabe.
Wobei graylog im Standard IETF erwartet, meine ganzen rsyslog-Definitionen sind danach ausgerichtet.
Für ossec zB gibt es ein plugin für graylog damit er diese gleich schön formatiert ausgibt, da diese in einem eigenen Format sind.

Grüsse,
dtavb

DS_Starter · 01 August 2018, 21:48:40

Hallo zusammen,

nach längerer Zeit habe ich das Modul weiterentwickelt und ihm nun auch eine Syslog-Serverfunktion spendiert und insgesamt weiterentwickelt.

Download aus dem contrib-Verzeichnis: https://svn.fhem.de/trac/browser/trunk/fhem/contrib

Die deutsche Commandref ist im Modul bereits angepasst.

Nach der Installation des Moduls ist sie über "help Log2Syslog" aufrufbar.

Das Modul hat nun das Unterscheidungsmerkmal Internal MODEL.

MODEL = Sender -> Syslog-Client wie bisher
MODEL = Collector -> Syslog-Servermode

Zur Erstellung eines Collectors gibt es einen neuen Definitionsaufruf ohne weitere Parameter.

Definition eines Collectors

define <name> Log2Syslog

Wegen der momentan andauernden Fortentwicklung erstmal contrib.
Über Mitteilungen zu Einsatz-/Testergebnissen würde ich mich freuen.

LG,
Heiko

JoeALLb · 02 August 2018, 08:21:54

Hallo Heiko,

genial, herzlichen Dank! An solche Möglichkeiten hatte ich noch gar nicht gedacht!!!
Das Eröffnet ganz neue Horizonte!!!

Ich bin erst am Testen und "einlernen" mit den Möglichkeiten davon.
Bekomme zB folgende Parserfehlermeldung:

Code Auswählen

Log2Syslog SyslogServer - error parse msg: system,info Router: dhcp server dhcp-vrrp changed by admin

mit RAW wird es natürlich angezeigt. Ist es gedacht, dass man für sowas dann einen eigenen Parser schreibt?
Ist es so gedacht, dass ich dann zB mit einem Notify die Events filtere und mir daraus je nach bedarf zB ein Reading oer etwas anderes generiere?

Ich versuche gerade, darüber die Anwesenheitserkennung durch Abgreifen des DHCP-Servers zu verbessern, was sehr vielversprechend aussieht
und sogar einfacher, bzw. schneller zu funktionieren scheint wie SNMP.

Danke für die Info,

sG

Joe

DS_Starter · 02 August 2018, 08:34:44

Morgen Joe,

ZitatBekomme zB folgende Parserfehlermeldung:

Schau mal ob ob du das richtige Format BSD/IETF eingestellt hast
verbose 5 im Zweifel mal posten.

Zitatmit RAW wird es natürlich angezeigt. Ist es gedacht, dass man für sowas dann einen eigenen Parser schreibt?

Hast du richtig erkannt

Idee ist dass spezielle PArser im Attribut parseProfile zu hinterlegen (z.Zt. raw/default) bzw. dem User die Möglichkeit zu geben eigene Parser einzubinden.

ZitatIst es so gedacht, dass ich dann zB mit einem Notify die Events filtere und mir daraus je nach bedarf zB ein Reading oer etwas anderes generiere?

Genau. Oder im DbLOg mit valueFn die zu loggenden Werte zu extrahieren für SVGs etc.
Der Phantasie sind ja kaum grenzen gesetzt.

Grüße
Heiko

JoeALLb · 02 August 2018, 09:22:45

Zitat von: DS_Starter am 02 August 2018, 08:34:44
Schau mal ob ob du das richtige Format BSD/IETF eingestellt hast
verbose 5 im Zweifel mal posten.

Das war mein Verbose 5 Log

Mehr steht da nicht. aber wie gesagt, sind erst die ersten Gehversuche...
Das Format habe ich richtig eingestellt. Habe auch auf beiden Seiten mal auf BSD umgestellt, was mir nicht schlechter gefällt,
daher bin ich noch unentschieden, welches Format ich letztlich tatsächlich verwenden soll/werde.

Zitat von: DS_Starter am 02 August 2018, 08:34:44
Idee ist dass spezielle PArser im Attribut parseProfile zu hinterlegen (z.Zt. raw/default) bzw. dem User die Möglichkeit zu geben eigene Parser einzubinden.

Schön wäre natürlich, wenn ich so einen Parser in einem Attribut ähnlich wie valueFn hinterlegen könnte.

Nur als Verständnisfrage: Wenn dein Regex auf die Daten nicht stimmt, bedeutet das, dass mein Router keine Standardkonformen Syslog-Meldungen schickt?
(habe mich in den Standard noch nicht eingelesen...)

Dein Regex passt jedenfalls nicht auf die Meldungen meines Routers!

Anbei dein Regexp mit benannten Backreferences: Wäre es möglich, solche zu verwenden? Diese sind meine rMeinung nach viel leichter lesbar und besser debugbar
und sollte ohne sonstige Änderung auch direkt so genutzt werden können. $1, etc. funktionieren damit immer noch!
Zumindest als Beispiel! (siehe Screenshot).

Code Auswählen

^<(?<priority>\d{1,3})>(?<version>\d+)\s(?<date>\d{4}-\d{2}-\d{2})T(?<time>\d{2}:\d{2}:\d{2})\S*\s(?<host>\S+)\s(?<ident>\S+)\s(?<pidid>\S+)\s(?<mid>\S+)\s(?<sdfield>\[.*\]|-)\s(?<content>.*)

Wenn mein Router gewisse Werte wie PIDID nicht liefert, sollte die entsprechende Regex-Klammer dann einfach leer bleiben?

Danke, sG
Joe

DS_Starter · 02 August 2018, 09:48:18

HI Joe,

wenn das die Raw Message ist:

Zitatsystem,info Router: dhcp server dhcp-vrrp changed by admin

Dann ist die Meldung weder nach Standard BSD noch nach IETF.
Wie der Messageaufbau nach RFC ist, habe ich versucht in der Hilfe darzustellen. Siehst du mit "help log2syslog".

ZitatWenn mein Router gewisse Werte wie PIDID nicht liefert, sollte die entsprechende Regex-Klammer dann einfach leer bleiben?

Technisch sicherlich ok so.
Aber wenn das parseProfil "standard" eingestellt ist, soll das Parsing strikt nach den Vorgaben der Syslog-RFC Dokumente erfolgen.

Wenn das Parsing damit nicht funktioniert, soll eben die Möglichkeit bestehen ein anderes/eigenes Parsing-Profil zu verwenden.
Im Zweifel raw.

ZitatAnbei dein Regexp mit benannten Backreferences: Wäre es möglich, solche zu verwenden? Diese sind meine rMeinung nach viel leichter lesbar und besser debugbar

Das ist gut, ich checke es und übernehme deinen Vorschlag wenn alles passt

LG,
Heiko

DS_Starter · 03 August 2018, 11:12:11

Hallo Joe,

habe das Modul im contrib upgedated.
Es wird nun immer der peerHost/peerAdresse ermittelt und als Reading im erstellten Event verwendet unabhängig davon ob der Sender sie in der Message mitliefert.

Ich habe nämlich festgestellt, dass meine TP-Link WLAN Accesspoints auch keine BSD/IETF-konforme Message senden.
Bei denen sieht es z.B. so aus:

Code Auswählen

<4> <;4>LAN IP and mask changed to 192.168.2.3 255.255.255.0

Hier scheint jeder Hersteller etwas eigenes zu machen. Man erkennt es _wahrscheinlich_ daran, dass man im Setup vom Syslog in dem entsprechenden Gerät weder BSD noch IETF Format auswählen kann. Fehlt diese Auswahl auch bei deinem Router ?
Bei meiner Synology kann ich z.B. auswählen ob sie Meldungen in BSD oder IETF Format an einen Syslog-Server sendet.

Welchen Typ Router hast du denn ?
Und kannst du bitte nochmal verifizieren ob die raw-Message wirklich so ist wie du oben geschrieben hattest ?

Vielleicht bietet es sich an, für einige gebräuchliche Geräte entsprechende Parseprofile auswählbar zu hinterlegen.
Ansonsten will ich dann noch ein Attribut "parseFn" einfügen mit dem der Nutzer eigene Parsingmöglichkeiten entwickeln kann.

Edit: BTW ... welchen Regex-Tester verwendest du ?

Grüße,
Heiko

JoeALLb · 03 August 2018, 21:44:40

Hallo Heiko, sorry, bin ab heute im Urlaub.
Mein Router kann "irgendwas" senden, oder eben BSD.
Ich nutzte Mikrotik Router und habe davon 8 Stück im Haus
(Mesh Netzwerk). Das Regex Programm heißt Regexbuddy, und ist genial. Kostet aber ein paar Euro.
Was ich ehrlich gesagt noch toll fände ist, wenn man Reading s ohne Notify erzeugen könnte, also als Art erweiterte "userreadings". Ich würde dafür sogar die Eventerzeugung in ein Attribut packen, damit man auf diese verzichten kann, wenn man alles über seine userreadings erschlagen hat. Dies wurde die Übersicht enorm vereinfachen. Aber das Mal nur so als Gedanke, ich melde mich die Tage, sicher aber wieder nach meinem Urlaub zurück... 😁.

SG Joe

DS_Starter · 05 August 2018, 21:14:11

Habe eine weiterentwickelte Version nach contrib geladen.

Über Attr parseProfile kann man neben den festen Auswertungsprofilen IETF,BSD,raw auch "ParsFn" auswählen um eine eigene Parsefunktion zu schreiben.
Im attr "parseFn" wird die Funktion dann hinterlegt.
Es werden umfangreiche Variablen/Felder für die Programmierung zur Verfügung gestellt. Mit dem attr "outputFields" können flexibel die Felder und deren Reihenfolge definiert werden, aus denen sich der generierte Event zusammensetzen soll.
Mit dem Attribut "makeMsgEvent" wird gesteuert, ob nur Events über die interne Logik (default), nur Readings ohne Event oder Readings mit Eventgenerierung in Abhängigkeit der event-on-.* Attribute erstellt werden sollen.
In der deutschen Modulhilfe "help Log2Syslog" ist alles beschrieben.

Grüße
Heiko

DS_Starter · 08 August 2018, 08:39:04

Ein Device vom Typ "Sender" kann nun Testmessages im BSD/IETF/raw Format senden.
Im Collecter habe ich das BSD-Parsing überarbeitet/verfeinert.

Download aus dem contrib-Verzeichnis: https://svn.fhem.de/trac/browser/trunk/fhem/contrib