Übergang von FileLog auf DbLog

[PNinBB]

Ich habe vor einigen Wochen auf DbLog umgestellt. Vor allem davor aber auch danach viel im Forum und anderswo gelesen.
Eine - wie mir scheint - fundamentale Frage habe ich noch. Zur Vorgeschichte:

• Seit Beginn der FHEM-Nutzung hatte ich das Logging mit FileLog. Die Definition erfolgte - mehr oder weniger - automatisch mit dem Inkludieren. Plots etc. funktionierte wie gewünscht.
• Nach dem Einrichten von DbLog läuft beides parallel, was ich eigentlich nicht benötige. Die neu eingerichteten bzw. übernommenen Plots ziehen die Daten nun aus der mySQL-DB.

Nun die Frage: Wie bekomme ich die FileLogs weg ?
Einfach das "Gerät" LogFile aufrufen und mit 'delete this device ()' löschen ?
Laufen also beide System echt parallel und kann ich demzufolge FileLog liqudieren ?
Eine richtige klare Aussage dazu habe ich nirgends gefunden.
Danke auf jeden Fall für eine Aussage und einen schönen Abend noch.
Peter.

[DS_Starter]

Hallo Peter,

Nun die Frage: Wie bekomme ich die FileLogs weg ?
Einfach das "Gerät" LogFile aufrufen und mit 'delete this device ()' löschen ?

Ja, soweit richtig. Die Files auf BS-Ebene mußt du aber separat löschen. Möglicherweise möchtest du aber die Daten aus den Filelogs in die DB importieren. Dazu kannst du das Modul Modul 98_FileLogConvert.pm verwenden (siehe commandref DbLog Version 2.22.5).

Laufen also beide System echt parallel und kann ich demzufolge FileLog liqudieren ?

Ja ... wenn du "parallel laufen" so verstehst, dass beide logging Varianten unabhängig voneinander funktionieren. Jedes logging funktioniert über die Auswertung der erzeugten Events entsprechend der angegebenen Regex in Filelog bzw. DbLog und jedes Logging-Device wertet für sich diese Events separat aus. Insofern kann man dieses Verfahren als "parallel" bezeichnen.

Grüße
Heiko

[PNinBB]

Guten Morgen Heiko,
besten Dank für deine klare Aussage, die meine Vermutungen bestätigt hat.
Ein solcher Hinweis sollte m.E. auch im Wiki stehen.
Ich habe nachfolgend eine Vorschlag zur Ergänzung als Pkt. 2.3. (neu).

Code Auswählen Erweitern


2.3. Zwei Log-Verfahren: FileLog und DbLog
Das mit FHEM entstandene Logging-Verfahren basiert auf der Sammlung der Einträge in ,,klassischen" Dateien.
Das dazu notwendige ,device' wurde mit der Inkludierung von Geräten mehr oder weniger automatisch eingerichtet.
Die von den Geräten erzeugten ,events' veranlassten letztendlich kontinuierlich die Einträge in den entsprechenden Dateien.
Verschiedene Gründe, u.a. Performancefragen, führten zu Überlegungen und letztendlich zur Implementierung
eines auf Datenbanken basierenden Logging-Verfahrens. Auch diese Einträge in die Datenbank werden durch die
von den Geräten veranlassten ,events' erzeugt.
Hat man nun die Datenbank und das ,device' wie oben beschrieben konfiguriert, dann werden, durch die ,events' getriggert,
die Dateien UND die Datenbank entsprechend gefüllt.
Die bereits existierenden FileLog-Dateien können in die Datenbank übernommen werden.
Dafür steht das Modul ,98_FileLogConvert.pm' zur Verfügung (siehe in commandref unter: DbLog).
Hat man sich für die DbLog-Variante entschieden, benötigt man eigentlich die LogFile-Variante nicht mehr.
Beim Löschen sind allerdings zwei Punkte zu beachten:
1. Das entsprechende ,device' FileLog_..., welches Anfangs mit define ... eingerichtet wurde, wird mit dem FHEM-Befehl ,delete FileLog_...' gelöscht.
2. Die erzeugten LogFiles müssen allerdings nachfolgend durch entsprechende Befehle des Betriebssystems gelöscht werden.
Grundsätzlich ist es also möglich, beide Varianten parallel laufen zu lassen.

Der bisherige Punkt 2.3. sollte dann 2.4. sein.
Ich bin mir nur nicht sicher, ob du der richtige Adressat bist für diese Ergänzung ?
Schönen Tag
Peter

[Amenophis86]

Ich finde, dass das im Punkt Einleitung eigentlich schon erklärt ist:

Mit der Zeit entstehen im fhem recht umfangreiche Log-Daten für die verschiedensten konfigurierten Devices. Die übliche Einstiegs-Konfiguration sieht vor, dass die Logs als FileLog gespeichert werden - je nach Einstellung in wenigen sehr großen oder vielen kleineren Dateien. Der Datei-basierte Zugriff ist allerdings nicht wirklick performant und kann schnell zum Flaschenhals werden (z.B. bei der Darstellung von Graphen über einen längeren Zeitraum).

Alternativ kann Fhem die Log-Daten mittels DbLog in einer Datenbank speichern. Diese kann lokal als einfache SQLite- oder als zentrale Server-Datenbank (s.u.) gestaltet sein. Schon eine lokale einfache SQLite-Datenbank ist in der Regel deutlich performanter als File-basierte Logs.

[DS_Starter]

Guten Morgen zusammen,

offensichtlich gibt es ja hin und wieder weiteren Erklärungsbedarf.

Das Modul 93_DbLog wird eigentlich von Tobais Faust (Tobias) als Maintainer betreut und er pflegt sicherlich auch den Wiki-Eintrag von DbLog.
@Peter, du kannst ihm ja eine PM mit dem Hinweis auf deine Ergänzung schicken und bitten ob die von Amenophis erwähnte Passage noch mit deinen Ergänzungen "aufgebessert" werden kann.

Ich komme die nächste Zeit urlaubsbedingt nicht dazu allzu viel zu unterstützen, danach wieder gerne.

Grüße
Heiko

[ph1959de]

Zur Beschreibung / Verbesserungen im Wiki von DBLog gibt es gerade ohnehin einen Thread.

Wenn sich dann jemand gefunden hat, der das ins Wiki einarbeiten möchte, kann der auch gern den Wiki Zugriff bekommen (sofern noch nicht vorhanden) 

PH nahe BB

[DS_Starter]

Zur Beschreibung / Verbesserungen im Wiki von DBLog gibt es gerade ohnehin einen Thread.

Ah, guter Hinweis auf diesen Thread .... kannte ich noch nicht. Danke !

[PNinBB]

Auch wenn ich Gefahr laufe, zu erfahren, dass schon alles geklärt ist, noch eine Frage:
Nach dem ich auf DbLog umgestellt und fast alle LogFile-Geräte gelöscht habe, ist das Systemlog übrig geblieben.
Wenn ich das Gerät 'Logfile' nun auch noch lösche, verschwindet dann auch die Funktion 'Logfile' auf dem Navigationspanel des Webportals, oder greift diese Funktion dann auf die Datenbank zu und die Wirkung bleibt erhalten ?

[Amenophis86]

Wenn du von dem Systemlog sprichst, dann würde ich das nicht löschen. Dieses würde ich als Filelog behalten. Geht mal die Datenbank nicht, oder gibt es andere Probleme dann sollte man dies auch immer sehen können.

[PNinBB]

Danke für den Hinweis; ich werde so verfahren.
Peter

[DS_Starter]

Noch zur Info, Filelog und fhem systemlog sind zwei ganz unterschiedliche paar schuhe. in das filelog werden informationen aus device events geschrieben, wie auch in dblog.  in das systemlog file schreibt der entwickler eines moduls die meldungen entsprechend der verbose levels hinein. diese meldungen kommen auch nicht in dblog an. man kann sie zum beispiel mit sys2syslog abgreifen und anderweitig verarbeiten.

[rudolfkoenig]

Ein paar weitere Infos rund um das FHEM-Log:
- wenn man die FHEM-Instanz "Logfile" loescht (kommt mit der standard fhem.cfg seit 3-4 Jahren) dann gibt es links in FHEMWEB Menue keinen Eintrag, um auf das FHEM-Log (aka "Systemlog") zuzugreifen. Die Daten werden aber weiterhin in die Datei geschrieben, was man per "attr global logfile" definiert hat.
- um das Schreiben in die Datei zu unterbinden, kann man "attr global logfile /dev/null" angeben. Das sollte aber nur derjenige machen, der genau weiss, was er sich damit antut. Das Attribut kann man nicht via deleteattr loeschen, und falls man es aus der fhem.cfg entfernt, dann wird "-" angenommen, was fuer STDOUT steht.
- man kann mit dem (relativ neuen) Syslog Modul diese Daten _zusaetzlich_ auch zu einem Syslog-Server weiterleiten.
- eine einfache Moeglichkeit, diese Daten in eine DB zu schreiben, ist mir nicht bekannt.
- die Meldungen aus dem FHEM-Log kann man per notify auswerten, wenn man im notify das readLog Attribut setzt.
- die Meldungen kann man auch im Event-Monitor anschauen, wenn man da einen Haken bei "FHEM log" setzt.