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

DS_Starter · 14 Oktober 2020, 20:09:48

Hallo Thorsten,

in deiner Definition ist eine Angabe zu viel drin. Richtig wäre z.B.:


defmod syslog_client Log2Syslog 192.168.168.100 ident:Test event:.* fhem:.*

oder der Name des Zielservers statt IP 192.168.168.100.

Grüße,
Heiko

smeagel · 14 Oktober 2020, 20:38:10

Super, funktioniert.

Vielen Dank für Deine schnelle Hilfe.

Viele Grüße
Thorsten

fhemxperte · 02 November 2020, 11:47:17

Hallo zusammen,

ich hatte bei der definition vor einigen Tagen genau dasselbe Problem mit der Logfile Archivierung. Irgendwann hat es dann funktioniert das Device zu erstellen und es lief einige Tage. Heute musste ich Fhem allerdings neustarten und das Modul hat beim Starten genau dieselben Fehler geschmissen bis Fhem wegen "Out of Memory" abbricht nach 36MB Logfiles. Dies hat sich in einer Schleife bis ins unendlich wiederholt, da Fhem automatisiert neugestartet wird, sollte der Service nicht laufen.

Ich musste das Modul leider wieder aus meiner Konfiguration schmeißen, da es einfach zu risikoreich ist um es produktiv zu nutzen, obwohl ich es geliebt habe die Logdaten zentral auf meinem DB Server zu haben.

Meine global Einstellungen:

Code Auswählen


archivedir /opt/fhem/log/oldlogs
nrarchive 4

Ein archivecompress habe ich nicht eingestellt.

Zitat von: Phiolin am 03 April 2020, 10:11:57
Definieren des devices lässt bei mir FHEM abstürzen:

Code Auswählen Erweitern
define syslogSender Log2Syslog 10.0.20.37 event:.* fhem:.*

Aus irgendeinem Grund versucht er dann permanent, dasselbe alte Logfile in den Archive Ordner zu schieben und nach gefühlt 1 Milliarde versuchen pro Sekunde, stürzt der Prozess dann ab.
Hier beißt sich offenbar was mit der FHEM global archive Funktion.
Ich habe im global device definiert:
Code Auswählen Erweitern
nrarchive 3 archivedir /opt/fhem/log/archive archiveCompress 1

Code Auswählen Erweitern
2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive 2020.04.03 10:08:28 2: Moving fhem-2019-12.log to /opt/fhem/log/archive

Bei mir sammelt ein Graylog die Daten ein.
Der versteht aber offenbar die Uhrzeiten falsch und schreibt alles 2 Stunden in die Zukunft. Offenbar wird kein UTC als Zeitstempel mitgegeben. Ist das konfigurierbar?
Ich sehe das der Timestamp keine Zeitzonen-Angabe enthält, wie man es eigentlich erwarten würde:

Code Auswählen Erweitern
<45>1 2020-04-03T10:29:44 fhem. syslogSender_event 268 FHEM [version@Log2Syslog version="5.8.3"] EG.fl.Fully motion_detection: off
Müsste hier eigentlich einen Zeitstempel 2020-04-03T10:29:44+0200 haben. Alternativ 2020-04-03T08:29:44Z wenn es GMT wäre.

RFC 5424 zeigt das in Sektion 6.2.3.1 bei den Beispielen: https://tools.ietf.org/html/rfc5424#section-6.2.3
RFC 3339 beschreibt Timestamp allgemein: https://tools.ietf.org/html/rfc3339#section-4.2

Vielleicht kann das optional konfigurierbar gemacht werden?

DS_Starter · 02 November 2020, 13:09:51

Das Modul hat mit der Verwaltung der Logfiles nichts zu tun. Ich kann es bei mir auch nicht nachvollziehen.

Generell ... du musst sicherstellen, dass das Verzeichnis /opt/fhem/log/oldlogs existiert und auch den entsprechenden Owner (fhem:dialout) sowie Schreibrechte für ihn existieren.
Sonst wird FHEM ständig versuchen zum entsprechenden Zeitpunkt das eingestellte Regime umzusetzen was im Fall Nichtvorhandensein des Archive-Verzeichnisses nicht vollzogen werden kann.

Bei mir steht z.B.

archivedir = ./log/archive

DS_Starter · 02 November 2020, 15:31:25

Hallo fhemxperte, @all,

jetzt hat mir das Ganze doch keine Ruhe gelassen und ich habe eine Stelle gefunden, die möglicherweise in ungünstigen Fällen doch eine unerwünschte Nebenwirkung haben könnte. Ich habe die Stelle beseitigt.

Bitte teste(t) die Version in meinem contrib.

Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben und danach FHEM restarten:

Code Auswählen


"wget -qO ./FHEM/93_Log2Syslog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_Log2Syslog.pm"

Grüße,
Heiko

fhemxperte · 02 November 2020, 17:09:43

Hi,

schaue ich mir an. Gebe gleich Rückmeldung.

Berechtigungen und alles andere sind in meiner Fhem Installation korrekt und hatte bisher auch nie Probleme (läuft seit mehreren Jahren stabil).

Vielen Dank für die Mühe.

Gruß,
Michael

Zitat von: DS_Starter am 02 November 2020, 15:31:25
Hallo fhemxperte, @all,

jetzt hat mir das Ganze doch keine Ruhe gelassen und ich habe eine Stelle gefunden, die möglicherweise in ungünstigen Fällen doch eine unerwünschte Nebenwirkung haben könnte. Ich habe die Stelle beseitigt.

Bitte teste(t) die Version in meinem contrib.

Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben und danach FHEM restarten:

Code Auswählen Erweitern
"wget -qO ./FHEM/93_Log2Syslog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_Log2Syslog.pm"

Grüße,
Heiko

fhemxperte · 02 November 2020, 17:22:19

Hi,

das Device konnte ohne Probleme erstellt werden und hat mehrere (alle) Restarts überlebt. Ich denke da hast du die Stelle gefunden, die zu Problemen geführt hat. Vielen Dank. Sollte es doch nicht diese Stelle gewesen sein, werde ich mich nochmal melden.

Ggf. kann Phiolin ja auch nochmal gegenprüfen...

PS: Sehr geniales Modul! Mich freut es, dass ich es weiter verwenden kann in einer wahrscheinlich nun stabilen Version.

Viele Grüße,
Michael

Zitat von: DS_Starter am 02 November 2020, 15:31:25
Hallo fhemxperte, @all,

jetzt hat mir das Ganze doch keine Ruhe gelassen und ich habe eine Stelle gefunden, die möglicherweise in ungünstigen Fällen doch eine unerwünschte Nebenwirkung haben könnte. Ich habe die Stelle beseitigt.

Bitte teste(t) die Version in meinem contrib.

Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben und danach FHEM restarten:

Code Auswählen Erweitern
"wget -qO ./FHEM/93_Log2Syslog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_Log2Syslog.pm"

Grüße,
Heiko

DS_Starter · 02 November 2020, 18:14:10

Hallo Michael,

danke für die Rückmeldung.
Checke es heute Abend noch ein und ist dann morgen früh im Regelupdate.

Grüße,
Heiko

cortmen · 25 Mai 2021, 09:07:04

:)Hallo zusammen,

Ich habe seit ein paar Tagen, wenn ich mal auf Verbose 5 schalte, sehr viele Meldungen im log.
Hat jemand einen Tipp?

Code Auswählen

021.05.25 08:52:46 5: Log2Syslog mysyslog - Warning - Payload NOT sent due to Message Severity not in attribute "respectSeverity"

DS_Starter · 25 Mai 2021, 09:14:19

Moin,

ja. Du hast wahrscheinlich so wie es in der Meldung steht die zu übermittelnden Schweregrade mit dem Attr respectSeverity gefiltert. D.h. es kommen Schweregrade im System vor die wegen der Filterung nicht übertragen werden was ja i.A. dem Willen des Anwenders entspricht sonst hätte er den Filter nicht gesetzt.

respectSeverity

Es werden nur Nachrichten übermittelt (Sender) bzw. beim Empfang berücksichtigt (Collector), deren Schweregrad im Attribut enthalten ist. Ist "respectSeverity" nicht gesetzt, werden Nachrichten aller Schweregrade verarbeitet.

Also entweder die Nachricht ignorieren (ist ja verbose 5) oder den Filter anpassen/löschen.

LG,
Heiko

cortmen · 25 Mai 2021, 10:06:37

Vielen Dank für die schnelle Reaktion,

Grund warum ich verbose 5 eingeschaltet habe war eine andere Meldung >200 x im Syslog.

Code Auswählen


nfo
2021-05-25 08:01:48   SYSTEM
Event detection: Received log which severity is [err]. Log content: [1: Error parsing >connected< for]
Info
2021-05-25 08:01:42
SYSTEM
Event detection: Received log which severity is [err]. Log content: [1: Error parsing >disconnected< for]

Habe jetzt wieder alles aktivert, mal schauen ob der Fehler wieder kommt.

KurtK · 22 Juni 2021, 20:09:14

Moin Moin,
ich nutze seit ein paar Tagen das Modul als Collector um DHCP Infos von meinem Mikrotik Router zu empfangen und so eine Anwesenheitserkennung durchzuführen. Das funktioniert auch alles problemlos.

Heute ist mir aufgefallen, das durch das Modul und evtl. der Hostnameabfragen eine sehr große Menge an DNS Abfragen auf meinem Pi-Hole zu sehen sind, was natürlich ganz schön meine Statistik verfälscht.

Habe die DNS Abfragen im Router mal mitgeloggt und für jedes SysLog Event erfolgt eine Abfrage, was ca. 40-60 Einträge pro Minute zur Folge hat.

Wäre es möglich diese Abfragen im Modul zu deaktivieren?

Viele Grüße

DS_Starter · 22 Juni 2021, 22:14:52

Hallo KurtK,

das Modul hat einen integrierten Hostnamencache sofern der DNS-Server den Hostnamen zu er empfangenen Adresse liefern kann.
Man kann das kontrollieren, indem man ein "list <name>" ausführt:

Code Auswählen


Internals:
   FD         20
   FUUID      5c44b572-f33f-b178-c1b3-7532097d28b2061b
   FVERSION   93_Log2Syslog.pm:v5.12.4-s23875/2021-03-01
   INTERFACE  global
   MODEL      Collector v5.12.4
   MYFQDN     fhemtest.myds.me
   MYHOST     fhemtest
   NAME       SyslogServer_BSD
   NR         480
   NTFY_ORDER 50-SyslogServer_BSD
   PORT       7514
   PROFILE    Automatic
   PROTOCOL   udp
   SEQNO      2
   STATE      active : 0
   TYPE       Log2Syslog
   HELPER:
     LTIME      1624392258
     OLDSEQNO   2
     OLDSTATE   active
     PACKAGE    FHEM::Log2Syslog
     TCPPADDR   192.168.2.46
     VERSION    5.12.4
   HIPCACHE:
     192.168.2.46 fhem.myds.me

Man findet dann die gecachten Adressen/Hostnamen nach dem Schlüssel HIPCACHE wie oben zu sehen.
Du musst nur dafür Sorge tragen dass dein DNS-Server die Adresse zu dem Hostnamen zuordnen kann.
Checke das mal bitte.

Grüße,
Heiko

KurtK · 23 Juni 2021, 18:51:53

Moin Moin,
danke für die schnelle Antwort und auch die schnelle Lösung.
Es lag tatsächlich an der fehlenden Namensauflösung.
Als die häufigen Anfragen auftraten, war unter HIPCACHE kein Eintrag vorhanden.

Habe einen entsprechenden Eintrag in die Hosts-Datei des FHEM-Server gemacht welcher mit list auch sofort aufgeführt wird und die Anfragen beim pi-hole beendet hat.

Viele Grüße