Logs auslagern - lokal oder NAS?

[claudio-fhem]

Hallo!

Da der Schreibzugriff auf die SD-Karte des FHEM Raspi immer mehr zunimmt, will ich die logs auslagern. Möglichkeiten: Ein USB-Stick lokal oder auf ein NAS.

USB-Stick ist auch ein Flash-Medium (Verschleiss), aber billiger als die Festplatten im NAS (müssen ja dann auch 24h am Tag rödeln). Außerdem ist die Frage: was passiert, wenn das NAS mal rebootet und nicht für einen Schreibvorgang zu erreichen ist? Bockt dann FHEM oder stürzt gar ab?

Theoretisch kommt auch eine billige SSD mit SATA-USB-Adapter in Frage...

Wer kann denn aus seiner Erfahrung mit ausgelagerten Logs Geschichten beitragen, die die Entscheidung erleichtern?

[DS_Starter]

Hallo Claudio,

Außerdem ist die Frage: was passiert, wenn das NAS mal rebootet und nicht für einen Schreibvorgang zu erreichen ist? Bockt dann FHEM oder stürzt gar ab?

Kommt darauf an welches Logging du benutzt.
Solltest du DbLog im asynchronen Modus benutzen, passiert nichts. d.h. FHEM läuft normal weiter und schreibt die zwischenzeitlich aufgelaufenben Events in die DB wenn die NAS/DB wieder verfügbar ist.
Das ist in meiner Umgebung Standard.

...aber billiger als die Festplatten im NAS (müssen ja dann auch 24h am Tag rödeln)

In meinem NAS befinden sich Serverplatten (WB red). Die sind für den 24x7 Dauerbetrieb ausgelegt und deswegen ist dieser Betriebsmodus (für solche Platten) auch unkritisch. Tun schon ein paar Jahre ihren Dienst zuverlässig.

Grüße,
Heiko

[guhu]

Ich nutze auch einen USB Stick zum Logging in Dateien. Da wird manchmal das Dateisystem zerschossen und dann stürzt fhem ab.

[claudio-fhem]

Danke für die Antworten!

@DS-Starter

WD-red hier auch, aber im 24/ sind die nach 3-4 Jahren hinüber, wenn nicht ständig in Betrieb werden es auch mal 6 Jahre.

Deine Art Logging ist nicht der Standard, oder? Gibt es einen Thread/Wiki zum Thema?

@guhu
Was ist denn "manchmal"? Alle 2 Jahre? Eine Idee, warum das FS leidet? Kenne ich sonst eigentlich nicht...

[DS_Starter]

WD-red hier auch, aber im 24/ sind die nach 3-4 Jahren hinüber

Kann ich jetzt bei mir nicht bestätigen, aber wenn du diese Erfahrung gemacht hast wäre es wohl ein Thema für die Qualitätssicherng von WD. 

Deine Art Logging ist nicht der Standard, oder? Gibt es einen Thread/Wiki zum Thema?

Also wenn du den asynchronen Modus im DbLog meinst, dann ist er nicht Standard nach dem Define von DbLog. Kann aber leicht mit asynchMode=1 umgestellt werden und wird von sehr vielen genutzt wenn meine Wahrnehmung richtig ist. Das hat historische Gründe, früher gab es diesen Modus nicht.
Hinweise gibt es dazu mit Sicherheit viele, angefangen bei der Commandref  . Aktuell wären vllt. diese Threads etwas für dich um solche Fragen zu erörten:

https://forum.fhem.de/index.php/topic,65860.0.html
https://forum.fhem.de/index.php/topic,107201.0.html

Grüße,
Heiko

[claudio-fhem]

Ich habe in der Vergangenheit viele WD red 2.5" (in Buffalo Linkstations) gehabt. Kann mit der Größe zusammenhängen, auch werden die Platten in den Buffalos gut gebraten.

Ich werde mal abwarten, ob noch mehr Meinungen eintrudeln. Vielleicht probier ich's mit einem 64 GB USB-Stick mit einer 50 GB NTFS Partition. Die Heizung hat in ein paar Tagen schon 16 MB zusammengeloggt. Ich habe einen Thread gesehen, wie man nur "neue" Werte loggen kann, mit dummy und Gedöns. Vielleicht ist das auch noch eine Überlegung wert?

[DS_Starter]

Ja. klar.
Aber auch lokal kann/wird es sich lohnen den asynchMode einzuschalten wenn du das noch nicht kennst. Dadurch kannst du auch zumindest die Anzahl bzw. zeitlichen Intervalle über das Attribut synchInterval optimieren. Vielleicht hilft es.

[claudio-fhem]

Bei mir laufen die logs derzeit einfach in Textfiles in /opt/fhem/log. Also müsste ich als erste Maßnahme mal das hier aktivieren:

https://commandref.fhem.de/#DbLog

...da geht's schon los. MariaDB? Oder SQlite? Oder...? Mein hauseigener Nerd ist derzeit nicht zu sprechen. Aber in's Blaue rein, will ich solche Entscheidungen nicht treffen.

Schwierig...

[DS_Starter]

Ich bin selbst nicht unvoreingenommen und würde MariaDB nehmen weil mir diese DB "liegt" und sehr stabil läuft.
Aber sie braucht auf jeden Fall RAM Ressourcen, also nichts für minimalistische Systeme.

Vielleicht mal hier ansprechen:
https://forum.fhem.de/index.php/topic,65860.0.html

LG,
Heiko

[Wernieman]

64 GB USB-Stick mit einer 50 GB NTFS

Dein FHEM läuft doch auf einem PI mit Linux? Warum dann unbedingt ntfs?? Willst Du es Dir unbedingt schwer machen??
Besser währen native Fileysteme wie ext3/4 ....

Allerdings bin ich persöhnlich kein Freund von USB-Sticks. Beine persönliche Erfahrung ist eher, das schlechter als SD-Cards ....

Edit:
Und Logs reduzieren, d.h. nur as unbedingt notwendig (und fürs Debugging Sinnvoll)

[guhu]

@guhu
Was ist denn "manchmal"? Alle 2 Jahre? Eine Idee, warum das FS leidet? Kenne ich sonst eigentlich nicht...

Unregelmäßig, derzeit ca. 3x im Jahr. Wahrscheinlich ist der USB-Stick irgendwann mal hinüber.

[claudio-fhem]

@guhu

NTFS kennt keine user Rechte und fragmentiert, was für Flash-Speicher eher ein Vorteil sein dürfte

EXT4 ist auch kein Problem.

Was schreibt denn dein Log so im Monat an GBs, damit du in 3 Monaten einen USB-stick himmelst? :-O

@DSStarter

MariaDB ist halt eine grooooooße Baustelle auf einem Raspi2. SQL light soll (laut einheimischem Nerd, ich haben ihn mit Apfelkuchen aus seinem Stall gelockt...) nur ein advanced Fileformat sein, ohne großen Überbau. Vielleicht erstmal sowas?

[DS_Starter]

SQL light soll (laut einheimischem Nerd, ich haben ihn mit Apfelkuchen aus seinem Stall gelockt...) nur ein advanced Fileformat sein, ohne großen Überbau. Vielleicht erstmal sowas?

Ja, so ist es. Passt schon. SQLite hat eben wegen seiner Architektur ein paar Eigenheiten. Es verkraftet parallele Schreibprozesse nicht so gut. Aber um mit der DB Materie erstmal etwas warm zu werden ist das schon gut. Außerdem ist es ein sehr weit verbreitetes DB-System und werkelt auch. Bei mir auf Testsystemen wegen der Modulentwicklung und rennt ...
SQLite sollte man nach meinen Erfahrungen aber nicht auf gemounteten Netzwerklaufwerken anlegen. Dabei kam es häufig zu Korruptionen.

Apropos Kurruptionen ... im DbRep-Modul gibt es mit repairSQLite eine Reparaturmöglichkeit wenn man doch mal eine SQLite Korruption hat (Erfolg nicht garantiert)

EDIT: Ebenfalls im DbRep gibt es Routinen zum Backup/Restore der DB im laufenden Betrieb. Nicht ganz unwichtig 
Näheres im Wiki: https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Backup.2FRestore_einer_SQLite_Datenbank_im_laufenden_Betrieb

Grüße,
Heiko

[claudio-fhem]

Im Zweifelsfall ist mir lieber, ich mache alle 6 Monate eine frische SD-Karte (oder USB-Stick), als mir eine Instabilität anzulachen. Ich bin manchmal recht weitläufig unterwegs und kann nicht (manuell) auf das System zugreifen, nur via ssh.

"Unbedingte Voraussetzung für Zuverlässigkeit ist absolute Unkompliziertheit"

(könnte von mir sein, isses aber nicht...)

...mal weiter drüber nachdenken...

[Wernieman]

NTFS kennt keine user Rechte und fragmentiert, was für Flash-Speicher eher ein Vorteil sein dürfte

Bist Du Dir da sooo sicher?
https://de.wikipedia.org/wiki/NTFS

Das ich USB-Sticks nicht so mag liegt bei mir nicht am PI, sondern ich hatte berufsmäßig mal einen Server mit so etwas, zum Glück gespiegelt. Mindestens 1mal im Jahr mussten wir tauschen (lassen). Hatte es hier im Forum schon mal erwähnt.....

Speziell beim PI kommt noch hinzu, das USB dort aus Hardwaregründen nicht so ...  sicher (sicher im Sinne von stabil, zuverlässig etc.). Linux mag es nicht, wenn ein Datenträger ohne unmounten entfernt wird .... in Summe (nach meiner Meinung) also unsicher als reine SDCard.

Habe übrigens (persönlich) auf keinen PI  die SDCard zerschossen, obwohl ich viele PIs verwende (persönlich zum Basteln/Testen und beruflich als Monitoringsysteme). Allerdings läuft hier FHEM auf einem ZOTAC