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

Begonnen von DS_Starter, 14 August 2017, 23:40:10

Vorheriges Thema - Nächstes Thema

vencam

Eben getestet, bekomme keine Fehlermeldung mehr. Vielen Dank  ;)

DS_Starter

Freut mich dass es auch bei dir klappt.  :)
Werde es einchecken und ist morgen dann im Update.

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Hallo zusammen,

ich hatte das Parsing aus #125 nun eine Weile für UniFi Controller laufen und hat das getan was es sollte.
Nun habe ich es fest eingebaut und ist im parseProfile als "UniFi" auswählbar.
Dazu noch einiges an Code review.

Die Version ist zum Test wieder in mein contrib geladen:
Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben:

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

Und restarten.

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Habe die Version 5.9.0 heute den ganzen Tag auf zwei Sytemen getestet und ist anstandslos gelaufen.
Die Version ist eingecheckt und morgen früh im Regelupdate enthalten.

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Phiolin

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: 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

Hallo Phiolin,

das Verhalten konnte ich bei mir noch nicht beobachten, allerdings habe ich bei mir auch kein archivedir gesetzt.
Ich versuche es mal nachzuvollziehen, wobei der Zusammenhang mir etwas suspect vorkommt.

Es wird die lokale Zeit verwendet. Greylog kannst du m.W. entsprechend konfigurieren:

https://community.graylog.org/t/time-configuration/6932

Jetzt läuft es wohl da du ja Werte im Syslog-Server bekommst ?

EDIT: Zeitangabe konfigurierbar machen kann ich mal mit vorsehen. Die RFC's kenne ich danke. ;)

LG,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Hallo Phiolin, @all,

ich habe deine Anregung bzgl. einstellbarer Zeitformate übernommen und im Modul umgesetzt.
Es gibt ein Attribut timeSpec welches zur Umschaltung dient wenn gewünscht. Es werden die Zeitformen gemäß RFC 3339 verwendet.

* timeSpec [Local | UTC]

Verwendung des lokalen bzw. UTC Zeitformats im Device. Nur empfangene Zeitdatagramme, die die Spezifikation gemäß RFC 3339 aufweisen, werden entsprechend umgewandelt. Die Zeitspezifikation beim Datenversand (Model Sender) erfolgt immer entsprechend des eingestellten Zeitformats.
Default: Local.

    Beispiele unterstützter Zeitspezifikationen
    2019-04-12T23:20:50Z
    2019-12-19T16:39:57-08:00
    2020-01-01T12:00:27+00:20
    2020-04-04T16:33:10+00:00
    2020-04-04T17:15:00+02:00

Bezüglich deines Absturzproblems konnte ich nichts nachvollziehen. Habe bei mir ebenfalls archivedir eingestellt und alles mögliche durchgespielt inklusive neu definieren -> kein Prob.

Die Version 5.10.0 liegt zum Test wieder in meinem contrib. Download wie weiter oben bereits beschrieben.
Restart bitte nicht vergessen.
Freue mich über eine Rückmeldung wie es mit Greylog zusammenspielt. Meine Tests mit Synology Protokoll-Center und zwei FHEM Instanzen untereinander (Sender -> Collector) waren durchweg erfolgreich.

LG,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Version 5.10.0 ist eingecheckt. Ich habe noch einiges im Code weiterentwickelt, z.B. bzgl. Octet Counting Erweiterung gemäß RFC 6587.

VG
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Phiolin

Sorry, war ein paar Tage beschäftigt.

Also Graylog kann man zwar wie von dir verlinkt konfigurieren, diese Einstellung hat aber keinen Einfluss auf die Zeitzone die für Syslog Inputs herangezogen wird. Der Syslog Input erwartet immer einen Timestamp mit Zeitzonenangabe, wenn diese fehlt, nimmt er UTC an. Die konfigurierte root Timezone setzt nur den Standard, falls für einen User nichts anderweitiges konfiguriert ist. Auf den Input selbst hat es leider keinen Einfluss.

Mit deiner Änderung funktioniert es jetzt, Logs kommen ordentlich zur richtigen Zeit im Graylog an. :)

Was mit dem Absturz wegen des Log-Archives falsch war, hab ich leider nicht herausgefunden. Er hat immer versucht, das Dezember Log zu archivieren und das irgendwie nicht hinbekommen, mit dem File selber war aber nichts auffälliges.
Hab das Dezember Log einfach gelöscht, danach war Ruhe. ;)

DS_Starter

ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

cortmen

Hallo zusammen, schöne Idee dieses Modul

Kurze Unterstützung bitte:
Ich habe ein kl. Problem mit dem Attrib  "exclErrCond"
Ganz einfach es filtern nichts, selbst einfache Events.
Internals:
   DEF        x.x.x.x event:.* fhem:.*
   FUUID      5e898b9f-f33f-0190-238e-6b325fa8319695be
   FVERSION   93_Log2Syslog.pm:v1.1.1-s21611/2020-04-05
   MODEL      Sender v5.12.0
   MYFQDN     xxxxxxx
   MYHOST     xxxxxxx
   NAME       mysyslog
   NR         340
   NTFY_ORDER 50-mysyslog
   PEERHOST   x.x.x.x
   SEQNO      68
   STATE      active
   TYPE       Log2Syslog
   HELPER:
     EVNTLOG    .*
     FHEMLOG    .*
     LTIME      1589296310
     OLDSEQNO   68
     OLDSTATE   active
     PACKAGE    FHEM::Log2Syslog
     SSLALGO    n.a.
     SSLVER     n.a.
     VERSION    5.12.0
   READINGS:
     2020-05-12 16:38:29   SSL_Algorithm   n.a.
     2020-05-12 16:38:29   SSL_Version     n.a.
     2020-05-12 17:11:50   Transfered_logs_per_minute 5
     2020-05-12 17:12:32   state           active
Attributes:
   disable    0
   exclErrCond Internals:
   DEF        x.x.x.x event:.* fhem:.*
   FUUID      5e898b9f-f33f-0190-238e-6b325fa8319695be
   FVERSION   93_Log2Syslog.pm:v1.1.1-s21611/2020-04-05
   MODEL      Sender v5.12.0
   MYFQDN     xxxxxxx
   MYHOST     xxxxxxx
   NAME       mysyslog
   NR         340
   NTFY_ORDER 50-mysyslog
   PEERHOST   x.x.x.x
   SEQNO      68
   STATE      active
   TYPE       Log2Syslog
   HELPER:
     EVNTLOG    .*
     FHEMLOG    .*
     LTIME      1589296310
     OLDSEQNO   68
     OLDSTATE   active
     PACKAGE    FHEM::Log2Syslog
     SSLALGO    n.a.
     SSLVER     n.a.
     VERSION    5.12.0
   READINGS:
     2020-05-12 16:38:29   SSL_Algorithm   n.a.
     2020-05-12 16:38:29   SSL_Version     n.a.
     2020-05-12 17:11:50   Transfered_logs_per_minute 5
     2020-05-12 17:12:32   state           active
Attributes:
   disable    0
   exclErrCond Vacuum error_code: None,Vacuum error: none,DS1 Error: none,DS1 Errorcode: none,
   logFormat  IETF
   respectSeverity Critical,Error
   room       Systeminfos,Vacuum error: none,DS1 Error: none,DS1 Errorcode: none,
   logFormat  IETF
   respectSeverity Critical,Error
   room       Systeminfos


Auch ein    .*Vacuum.*error_code:.*None.*    oder  error_code:.*None.*       .*error_code:.*[Nn]one.*    bringt keine Änderung

Jemand einen Tipp.

DS_Starter

Definiere bitte "filtern" mal genauer was du darunter verstehst.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

cortmen

 :)Danke für die schnelle Hilfe,

Ich habe einige Devices die halt alle 10 Min Events senden, wo halt ein z.B.    Vacuum error: none    als Meldung auf im Syslog Protokoll der Syno steht.


2020-05-12 17:19:36  Fehler  hostx   syslog   mysyslog_event   Vacuum error_code: None


cortmen

 :)

Das scheint zu greifen..


exclErrCond   error_code: None,error: none,Error: none,Errorcode: none


Vacuum error_code: None     mag der "Error - Filter" so nicht

DS_Starter

Passt  :)

Bei Vacuum error_code: None könntest du mal probieren "Vacuum\serror_code:\sNone"
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter