Frage zu DBLog

dt2510 · 25 Mai 2018, 16:27:39

Ich habe seit einiger Zeit bei mir eine MariaDB laufen und auch ein DBLog eingerichtet. Dazu hätte ich noch ein Paar Fragen:

- es werden weiterhin Logdateien für die Devices geschrieben - ist das erforderlich ?
- was passiert, wenn die MariaDB nicht erreichbar ist ?
- für den Fall, daß die Logdateien zwingend geschrieben werden müssen - kann man diese mit der Datenbank (z.B. nach nicht Erreichbarkeit) synchronisieren ?

Aktuell läuft MariaDB mit FHEM auf meinem NUC, alternativ hätte ich noch eine MariaDB auf einer Synology. Diese wäre allerdings bei einem Ausfall des Netzwerks (wegen Defekt o.Ä.) nicht mehr erreichbar.

RomanticBoy83 · 25 Mai 2018, 16:31:10

Die Dateien, die du meinst sind jeweils ein Filelog. Die benötigt du wahrscheinlich nicht mehr.
Wenn die DB nicht erreichbar ist? Nun ja, keine Anzeigen und auch keine weiteren Daten!

betateilchen · 25 Mai 2018, 17:30:58

Zitat von: RomanticBoy83 am 25 Mai 2018, 16:31:10
Wenn die DB nicht erreichbar ist? Nun ja, keine Anzeigen und auch keine weiteren Daten!

Kommt darauf an, warum die Datenbank nicht erreichbar ist und wie lange die Erreichbarkeit dauert. Das DbLog kann Logdaten durchaus intern puffern, um sie asynchron wegzuschreiben, wenn die Datenbank wieder erreichbar ist.

Und hier ist übrigens der falsche Forumbereich für Fragen zu DbLog.

dt2510 · 25 Mai 2018, 17:56:38

Ich hoffe ich bin jetzt im richtigen Bereich ...

Im Normalfall müsste die Datenbank auch auf der DiskStation erreichbar sein, da sie ebenfalls 24/7 läuft und auch Kameras, USV usw. darüber laufen.

Zitat von: RomanticBoy83 am 25 Mai 2018, 16:31:10
Die Dateien, die du meinst sind jeweils ein Filelog. Die benötigt du wahrscheinlich nicht mehr.

Wahrscheinlich hilft mir leider nicht viel weiter

Brauche ich sie noch oder kann ich die FileLog Definitionen (und nach Import in die DB auch die txt Files) entfernen ?

Zitat von: betateilchen am 25 Mai 2018, 17:30:58
Kommt darauf an, warum die Datenbank nicht erreichbar ist und wie lange die Erreichbarkeit dauert. Das DbLog kann Logdaten durchaus intern puffern, um sie asynchron wegzuschreiben, wenn die Datenbank wieder erreichbar ist.

Kann man das irgendwo festlegen, wie groß der Puffer ist bzw. wie lange gepuffert wird ?

betateilchen · 25 Mai 2018, 20:25:15

Zitat von: dt2510 am 25 Mai 2018, 17:56:38
Ich hoffe ich bin jetzt im richtigen Bereich ...

Nein. https://forum.fhem.de/index.php/topic,13092.0.html

Zitat von: dt2510 am 25 Mai 2018, 17:56:38
Wahrscheinlich hilft mir leider nicht viel weiter

Langsam wirds ziemlich ungemütlich hier...

Zitat von: dt2510 am 25 Mai 2018, 17:56:38
Brauche ich sie noch oder kann ich die FileLog Definitionen (und nach Import in die DB auch die txt Files) entfernen ?

Niemand kann Dir die Frage beantworten, ob DU die FileLog devices noch brauchst. Aber FHEM braucht sie jedenfalls nicht mehr, nachdem Du auf DbLog umgestellt hast. Mach damit, was Du willst.

Zitat von: dt2510 am 25 Mai 2018, 17:56:38
Kann man das irgendwo festlegen, wie groß der Puffer ist bzw. wie lange gepuffert wird ?

Lies doch einfach mal die Doku zu DbLog. Tipp "help dblog" in die FHEM Befehlszeile oben eingeben.

dt2510 · 26 Mai 2018, 11:21:18

Laut help DBlog sollte es hierher gehören. Es tut mir leid wenn ich nicht alles, was hier im Forum geschrieben wird lese(n kann) und ich nicht wusste, daß man das passende Forum über den help Befehl herausbekommt...

Zitat von: betateilchen am 25 Mai 2018, 20:25:15
Langsam wirds ziemlich ungemütlich hier...
Niemand kann Dir die Frage beantworten, ob DU die FileLog devices noch brauchst. Aber FHEM braucht sie jedenfalls nicht mehr, nachdem Du auf DbLog umgestellt hast. Mach damit, was Du willst.

Ich verstehe nicht was Deine Anspielung von wegen "ungemütlich" soll ? Die Antwort war zum Einen an RomanticBoy83 gerichtet und zum Anderen nicht bierernst gemeint (deshalb der

)
Ich hatte eigentlich erwartet, daß das Forum dazu da ist, daß man sich gegenseitig hilft und nicht die Formulierung haarklein analysiert .... natürlich wollte ich wissen ob FHEM auch weiterhin die FileLogs benötigt wenn DBlog verwendet wird !!

Aber um auf das eigentliche Problem zurück zu kommen:

Wenn ich es richtig verstanden habe (korrigiert mich bitte, wenn ich mich irre), muss ich

Code Auswählen

attr DBlog asyncMode 1
attr DBlog cacheLimit 1000
attr DBlog syncInterval 60

angeben, wenn ich entweder nach 1000 Events oder nach 60 Sekunden (je nachdem was zuerst eintritt) mit der Datenbank synchronisieren will. Sollte die Datenbank nicht erreichbar sein, wird es nach 30 Sekunden wieder versucht.

Was ich nicht gefunden habe ist:

- da der Cache im Speicher ist, sind die gecachten Events nach einem Absturz weg - kann man auch in eine lokale Datei cachen die dann noch da wäre (wie ein LogFile)
- was passiert mit neuen Events wenn das cacheLimit erreicht ist und die Datenbank immer noch nicht erreichbar ist ?

DS_Starter · 26 Mai 2018, 18:25:39

Zitat
...angeben, wenn ich entweder nach 1000 Events oder nach 60 Sekunden (je nachdem was zuerst eintritt) mit der Datenbank synchronisieren will.

Richtig.

ZitatSollte die Datenbank nicht erreichbar sein, wird es nach 30 Sekunden wieder versucht.

Nicht ganz ... gilt nur im Fall wenn cacheLimit erreicht/überschritten ist (syncInterval/2). Sonst gilt die Zeit von syncInterval.

Zitat.... kann man auch in eine lokale Datei cachen die dann noch da wäre (wie ein LogFile)

Nicht im eigentlichen Sinne. Es gibt aber das "set <name> exportCache [nopurge | purgecache]" Kommando. Damit kann man sich im Falle einer Störung den Cache sicherheitshalber in ein CSV-File exportieren und später bei Bedarf wieder importieren. Zur Steuerung dieses Vorgangs kannst du z.B. ein Notify auf das Event CacheUsage verwenden. Sieh dir dazu auch das Attribut cacheEvents an.

Zitatwas passiert mit neuen Events wenn das cacheLimit erreicht ist und die Datenbank immer noch nicht erreichbar ist ?

Die neuen Events werden weiterhin dem Cache hinzugefügt. Es gibt zur Zeit keine hart programmierte Obergrenze. Der User sollte sich bei Bedarf eine Mitteilung zusenden lassen wenn ein indviduell festzulegender Obergrenzen-Wert von CacheUsage gerissen wird (Attribut cacheEvents). Dann weiß man dass etwas nicht stimmt und kann Massnahmen einleiten. Die Daten bleiben solange erhalten bis sie wieder in die DB geschrieben werden können und FHEM nicht abstürzt.

Zum Thema Absturz.... auf meinem Produktivsystem habe ich schon seit "Ewigkeiten" keinen Absturz mehr gehabt. Ich setze nur zuvor auf einem Testsystem getestete Module/Verfahren und Codes ein. Das ist zwar keine Garantie, aber für mich ein Hilfsmittel zur Qualitätsicherung. In dem Sinne hat Zuverlässigkeit bei mir Vorrang vor Schönheit.

dt2510 · 27 Mai 2018, 09:58:01

Super .. danke

exportCache/cacheUsage sehe ich mir auf jeden Fall mal noch genauer an.

Einen echten Absturz hatte ich eigentlich noch nie auf meinem (Linux) System, ich dachte da eher an einen Stromausfall, wenn die USV schlapp macht (hatte hier im letzten Jahr einen über 2 Stunden).
Ich habe kürzlich gerade deshalb auch NUT installiert und in FHEM eingebunden, muss aber noch sehen, wie ich FHEM im Falle eines Shutdowns durch NUT sauber beende...

DS_Starter · 27 Mai 2018, 12:45:44

Zitat
Einen echten Absturz hatte ich eigentlich noch nie auf meinem (Linux) System, ich dachte da eher an einen Stromausfall, wenn die USV schlapp macht (hatte hier im letzten Jahr einen über 2 Stunden).
Ich habe kürzlich gerade deshalb auch NUT installiert und in FHEM eingebunden, muss aber noch sehen, wie ich FHEM im Falle eines Shutdowns durch NUT sauber beende...

Diesen Fall habe ich bei mir auch mit Hilfe NUT und Synology abgesichert. NUT ist auf den FHEM-Servern installiert und kommuniziert über LAN mit dem Netzwerk USV-Server der Syno. Die USV ist per USB mit der Syno verbunden und dort in der Systemsteuerung -> Hardware&Energie -> USV ist der USV-Server mit aktiviert und auch die IP-Adressen der zugelassenen (FHEM)-Rechner hinterlegt.

Das NUT-Device ist so definiert:

Code Auswählen


defmod USV NUT ups 192.168.2.10:3493
attr USV asReadings battery.charge,battery.runtime,input.voltage,ups.load,ups.power,ups.realpower,ups.model
attr USV devStateIcon .*OL.*CHRG:control_arrow_rightward .*OB.*DISCHRG:control_arrow_leftward@red .*OL:10px-kreis-gruen
attr USV disable 0
attr USV event-on-change-reading battery.charge
attr USV event-on-update-reading state
attr USV group Serverkabinett
attr USV icon it_ups
attr USV pollState 10
attr USV pollVal 30

Ich verwende ein Notify um zu überprüfen wenn die Batterieladung unter 80% sinkt und fahre dann FHEM runter:

Code Auswählen


defmod N.USV.Energy.down notify USV:OB.*DISCHRG { \
    if (ReadingsVal($NAME,"battery.charge",100) <= 80) {\
        DebianMailnbl ('<User>@<Domain>','Shutdown FHEM', 'Stromausfall - die Ladung der USV ist gering, FHEM wird in 10s gestoppt.');;\
        fhem "sleep 10;; shutdown"\
    } \
}
attr N.USV.Energy.down room Energie

Damit fährt FHEM runter bevor die Syno offline geht.

beste Grüße
Heiko

dt2510 · 28 Mai 2018, 15:57:31

Nutzt du dann eigentlich DBlog auch mit der MariaDb auf der SyNo in Verbindung mit asyncMode oder eine lokale DB ?

DS_Starter · 28 Mai 2018, 18:01:28

ZitatNutzt du dann eigentlich DBlog auch mit der MariaDb auf der SyNo in Verbindung mit asyncMode oder eine lokale DB ?

Ich benutze die MariaDB auf der Syno in Verbindung mit dem asynch Mode, also remote. Daneben noch Postgre-SQL auf der Syno (die eingebaute) und SQLite für Testzwecke.
Aber produktiv sind es zwei DB's MariaDB auf der NAS.