Autor Thema: Modul 93_Log2Syslog - FHEM Logs an Syslog-Server leiten und Syslogs empfangen  (Gelesen 19966 mal)

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7236
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
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf Synology
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline smeagel

  • Jr. Member
  • **
  • Beiträge: 75
Super, funktioniert.  :)

Vielen Dank für Deine schnelle Hilfe.


Viele Grüße
Thorsten

Offline fhemxperte

  • New Member
  • *
  • Beiträge: 32
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:
archivedir /opt/fhem/log/oldlogs
nrarchive 4


Ein archivecompress habe ich nicht eingestellt.


Definieren des devices lässt bei mir FHEM abstürzen:

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:
nrarchive 3
archivedir /opt/fhem/log/archive
archiveCompress 1

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:

<45>1 2020-04-03T10:29:44 fhem. syslogSender_event 268 FHEM [version@Log2Syslog version="5.8.3"] EG.fl.Fully motion_detection: offMü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?

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7236
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
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf Synology
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7236
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:

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

Grüße,
Heiko
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf Synology
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline fhemxperte

  • New Member
  • *
  • Beiträge: 32
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

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:

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

Grüße,
Heiko

Offline fhemxperte

  • New Member
  • *
  • Beiträge: 32
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

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:

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

Grüße,
Heiko

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7236
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
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf Synology
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline cortmen

  • Full Member
  • ***
  • Beiträge: 157
 :)Hallo zusammen,

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

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

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7236
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
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf Synology
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline cortmen

  • Full Member
  • ***
  • Beiträge: 157
Vielen Dank für die schnelle Reaktion,

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

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.
« Letzte Änderung: 25 Mai 2021, 10:16:49 von cortmen »

Offline KurtK

  • New Member
  • *
  • Beiträge: 28
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
- FHEM auf Intel NUC mit Proxmox -
- FTUI mit FUIP -
- HM, Zigbee,  WLAN -

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7236
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:

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
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf Synology
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline KurtK

  • New Member
  • *
  • Beiträge: 28
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
- FHEM auf Intel NUC mit Proxmox -
- FTUI mit FUIP -
- HM, Zigbee,  WLAN -
Gefällt mir Gefällt mir x 1 Liste anzeigen