Best Practice für Logdateien etc

[gnatolf]

Hallo Miteinander,

(für die Frage nicht wirklich relevant, aber trotzdem): RaspberryMatic auf Pi3b+, redmatic installiert, funktioniert alles bestens.

Will mir jetzt z.B. (echt nur ein Beispiel) meine Wetterdaten/Temperaturdaten sagen wir mal alle 2 Minuten in eine Logdatei schreiben lassen (kann ich auch :O). Hab nicht so recht gewusst, wie ich danach suchen sollte, daher die Frage: Wie speichere ich die am 'besten'?

Meine (nicht extrem ausgeprägten) Pi-Programmierungserfahrungen gehen dahin, dass man tunlichst nicht so viel auf der SD-Karte rumschreiben sollte. Kann natürlich "einfach" einen USB-Stick anhängen und darauf schreiben. Ist das noch Stand der Dinge? Wenn ich nur mal quick'n'dirty ein/zwei Dateien schreiben möchte, /tmp?

Ihr seht schon, am ehesten geht es mir um eure Erfahrungen/Vorschläge, was da am besten funktioniert, eventuell mit einem kleinen Fokus darauf, wie es (a) zusammen mit Node-Red am besten/einfachsten/robustesten ist, und (b) z.B. mit externem Speichermedium, aber dann mit gewisser Fehlertoleranz, damit man z.B. den Stick mal abziehen kann ohne dass Nodered direkt alle viere von sich streckt (von mir ungetestete Gewässer, was passiert bei I/O-Fehlern in irgendwelchen Nodes?)

[Xel66]

Ist das noch Stand der Dinge?

Da dieses abhängig von der SD-Karte ist und die immer noch keine dauerhaften Schreibvorgänge vertragen, ist das immer so.

Wenn ich nur mal quick'n'dirty ein/zwei Dateien schreiben möchte, /tmp?

Mal zwei Dateien schreiben ist kein Problem, aber zyklisch auf eine SD geht eben nicht. /tmp liegt im RAM und ist bei einem Neustart weg. Insofern kannst du dort hinschreiben, so oft Du willst. Ist eben nur alles dann /dev/null. Für Logdateien bietet sich ein externer Loghost an. Für das Aufzeichnen von Parametern bietet sich Historian an. Für wenige Werte kann man auch CUxD mit dem Aufzeichnen beauftragen. Kommt eben drauf an. Mit Node-Red habe ich keine Erfahrung, aber einen gemounteten Stick einfach so abzuziehen, dürfte definitiv Probleme geben.

Gruß Xel66

[gnatolf]

Danke für die Antwort!

Da dieses abhängig von der SD-Karte ist und die immer noch keine dauerhaften Schreibvorgänge vertragen, ist das immer so.

Ja, leuchtet ein, war wohl keine superclevere Frage

Für Logdateien bietet sich ein externer Loghost an. Für das Aufzeichnen von Parametern bietet sich Historian an.

okay! externe loghosts, könnte also mit zB Historian dann auch einfach 'direkt' auf mein NAS schreiben? Oder geht das gar mit Bordmitteln?

Für wenige Werte kann man auch CUxD mit dem Aufzeichnen beauftragen.

Kommt eben drauf an.

worauf denn? ;> Meine Frage ist ja so offen gestellt, eben weil ich nicht weiß, wann und aus welchen Gründen ich mich für das eine oder andere entscheiden sollte.

[Xel66]

okay! externe loghosts, könnte also mit zB Historian dann auch einfach 'direkt' auf mein NAS schreiben?

Bei mir läuft sowohl der Loghost als auch Historian auf der Diskstation. Loghost gibt man via WebUI ein, Historian muss man installieren.

worauf denn? ;>

Auf die Anzahl der aufzuzeichnenden Daten und wie man sie darstellen und archivieren will. Für eine Hand voll Werte bietet sich CUxD an. Will man etwas mehr, dann eben eine "ausgewachsene" Lösung. Ich finde es auch manchmal interessant, im Nachgang Daten zur Auswertung anschauen zu können. Hat man vorher mit Logit (CuxD) eine Auswahl getroffen, hat man auch nur diese Daten vorrätig. Mit Historian geht eben m.E. mehr. Darum war das damals mein Mittel der Wahl. Mit einer Installation direkt auf der Raspberrymatic hatte ich keinen dauerhaften Erfolg, weil das Speichermedium eben ein USB-Stick mit dessen Beschränkungen war. Mit dem Historian auf dem NAS bin ich das Problem los und es läuft rockstable.

Gruß Xel66

[gnatolf]

Ahja, nen Syslog kann ich natürlich direkt auf der syslog laufen lassen. Hatte (hab) so ein bisschen Sorge wegen der Systemauslastung vom Pi, das wäre ja ganz nett. Danke für die Idee!

Ich gehöre auch eher zur Gruppe der Nicht-wegschmeißer, wer weiß schon, was man nachher mal damit anstellen möchte

[srunschke]

Die Frage ist eher: was ist dein Ziel dahinter "Logs" zu schreiben? Die Logs der RM sind doch eher kryptisch und nicht wirklich human readable.

Für mich klingt das weniger nach Logs, als danach dass du gerne Performancedaten wegschreiben möchtest, damit du sie später im Zweifel analysieren kannst? Oder willst du wirklich Logs sammeln um später Fehlersituationen debuggen zu können?

Da gibt es wie bereits von Xel66 beschrieben eine Menge Möglichkeiten.

CCU-Historian ist sicherlich eine der einfachsten, da es auf die Historisierung von CCU Daten spezialisiert ist und quasi null Einrichtungsarbeit bedeutet. Zusätzlich gibt es das Tool nicht nur als Installable, sondern auch als natives Packet für die Synology - was einen gewissen Charme hat (wenn man eine Synology hat ).

CuXD Logit ist sicher etwas aufwendiger, aber sehr praktisch, wenn man CuXD sowieso für andere Sachen noch einsetzt.

Ich persönlich setze zB ioBroker als Middleware ein und habe dort eine InfluxDB mittels Grafana zur Visualisierung implementiert. Sicherlich deutlich aufwendiger - auch vom Verständnis her - aber dafür schier unendlich in den Möglichkeiten und nicht so proprietär wie die beiden ersten Lösungen. Durch die Nutzung von ioBroker als Middleware kann ich hier auch die Performancedaten von all meinen Homeautomation Systemen (Homematic, HUE, Lightify, Shelly...) aggregieren und übergreifend nutzen.

[gnatolf]

Wie gut, dass ich eine Synology habe

Klingt soweit gut, ich möchte halt node-red als Middleware verwenden, da wird es sicherlich ähnliches geben.

Bzgl der logs hatte ich ja ganz oben ein Beispiel genannt, extra ein bisschen nebulös, da sehe ich viele Möglichkeiten. Mit logs meinte ich daher eher so 'permanente' Datenströme, die aus dem System rausgeholt werden können.

[srunschke]

Naja, „permanente Datenströme“ ist jetzt auch nicht so unbedingt eine bessere Erklärung. Damit kann ich ehrlich gesagt auch nichts anfangen.
Aber aus den Logs wirst du definitiv keine wirklich sinnvollen Informationen ziehen können. Das ist nur auf Systemebene für ein Troubleshooting relevant.