LoxBerry: Statistik Plugin - Diskussion

[Christian Fenzl]

Wow, super!
Ich werde der erste Tester! Ich hab nämlich beim Formatieren und Probieren mit einer externen Platte irgendwann mal unabsichtlich die SD statt SDA erwischt... Und trotz Sicherung zickt jetzt mein Cacti-Poller herum...

Während du am GUI arbeitest, würde ich anbieten, einen Loxone-Import zu bewerkstelligen.

Lg, Christian

[Prof.Mobilux]

Kurzes Update:

Das Erstellen von Datenbanken funktioniert jetzt sowohl mit Standardeinstellungen als auch im "Experten-Modus". Als nächstes kommt jetzt das Skript zum Holen der Daten vom Miniserver an die Reihe (zu 60% fertig).



Danach werde ich eine erste Version auf GIT veröffentlichen, mit der man dann schon etwas spielen kann :-)

[Prof.Mobilux]

Wenn Du Dich einlesen willst: Schau Dir mal das kleine Beispiel an: https://www.heise.de/make/artikel/Ku...r-2714517.html Ich habe es einfach nachgebaut und es hat mir sehr geholfen zu kapieren wie es funktioniert :-)

Ich dachte, ich könnte mich vorab schon ein wenig einlesen (auf der rrd Webseite habe ich da zuviel gefunden...) Ging mir mehr darum. Gut Ding will Weile habe, das weiß ich ja :-)

[Christian Fenzl]

Wart doch mal ab, bis Michael fertig ist! Hilft nichts, was zu erklären, was noch gar nicht da ist.

Wie geht das denn? Ich weiß leider nicht, wie man Daten in eine Datenbank bekommt... ich bin zu wenig in Sachen Programmierung unterwegs. Ansonsten: ja, wäre die elegantere Variante!

[Prof.Mobilux]

Prinzipiell kannst du später auch einfach per Cronjob die Werte in die Datenbank schreiben anstelle sie vom Miniserver abzuholen.

Man auf das Plugin freu ich mich schon! Ich hätte noch zwei Ideen, was man auch als Statistik erfassen könnte. Wie würde ich denn die Daten in die Datenbank schießen können? Es handelt sich um den Speedtest (speedtest.net), den man von der CLI her ausführen kann. Am Ende werden die Daten in ein Textfile geschrieben, das könnte ich dann auslesen und in die DB übertragen. Gleiches gilt für ein anderes Script zur Überwachung des Kabel-Anbieter-Backbone (benötigt einen DVB-C USB Stick zum Auslesen der Frequenzkanäle und deren Auslastung). Könnte man in einem Cronjob durchführen lassen und dann auch in die DB übertragen lassen. Ist eine andere Art von Statistik, aber gerade das mit dem Speedtest finde ich sehr aufschlussreich, da viele Probleme mit der Internetperformance haben, könnte man so Statistiken erstellen lassen um die Performance zu tracken.

P.S. So sieht die Ausgabe von Speedtest auf der CLI aus:

Speedtest at Tue Nov 1 12:00:01 CET 2016
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Unitymedia (37.49.87.118)...
Selecting best server based on latency...
Hosted by PfalzKom (Ludwigshafen) [103.94 km]: 21.827 ms
Testing download speed........................................
Download: 191.48 Mbit/s
Testing upload speed............................................. .....
Upload: 9.81 Mbit/s

Ausgelöst wird es in der Crontab durch:
*/30 * * * * echo "Speedtest at $(date)" >> /home/user/speedlog.txt
*/30 * * * * /usr/local/bin/speedtest-cli >> /home/user/speedlog.txt

Im ersten Schritt wird der Zeiteintrag durchgeführt und danach der Speedtest durchgeführt. Die Daten werden dann in die Speedlog.txt eingetragen (>> für das Anhängen der Daten, mit einem > wird dann jedes Mal eine neue Datei geschrieben, was bei Statistiken zu bevorzugen wäre, da braucht man keine Historie im File). Das Speedlog.txt kann dann mit rrd ausgelesen werden.

[Prof.Mobilux]

Auf Basis dessen, was ich verwende (und ich heute für Gut oder Schlecht empfinde), würde ich folgendes Set als Default machen:
Tage/Minuten:
31 (1 Monat) / 5 Min.
92 (2 Monate) /15 Min.
365 (1 Jahr) / 60 Min.
7305 (20 Jahre) /1440 (1 Tag)

Super, perfekt! Das werde ich als Plugin-Standard verwenden, wer möchte kann dann diese Voreinstellungen nach Herzenslust ändern. Ich werde zudem noch vorsehen, dass man eigene Änderungen dann wiederum als Vorgabe selbst abspeichern kann.

Ich werde jetzt erst einmal den Datenbank-Teil sowie das Pullen vom Miniserver realisieren und als Zwischenstand per GIT veröffentlichen. Wenn das abgeschlossen ist und stabil läuft mache ich mich an die erste Grafik-Engine heran.

[Christian Fenzl]

Es lässt sich sogar mit create ein neues RRD mit Datenquelle altes RRD verwenden. Je nach neuer RRA-Definition werden die Daten dann interpoliert.

[BSiege]

Nun ist es ja so, dass man zum Zeitpunkt der Erstellung der Datenbanken schon sehr viele Vorgaben bzgl. Speicherintervall, Archive, etc. machen muss. Die meisten davon sind später nicht mehr änderbar. Das wird einen Laien mit Sicherheit überfordern (ich habe auch mehrere Anläufe gebraucht, bis ich Step, Heartbeat, RRA, PDP, CDP, XFF usw. voreinander bekommen habe).

Das ist mit entsprechendem Aufwand schon änderbar mittels dump nach xml. Gewisse Parameter können auch mit rrdtune beeinflusst werden. Ganz wichtig ist auch: das RRD-Format ist stark auf die Architektur optimiert. Wenn von einem 32-Bit auf ein 64-Bit System gewechselt wird, muss auch der Schritt über rrddump und rrdrestore gemacht werden.

[Christian Fenzl]

Hallo Michael,

das gleiche Excel hab ich auch verwendet :-)

Was du dir beim Excel noch dazumachen solltest, ist die Datengröße. Jeder Datenpunkt ("rows") benötigt 8 Byte Diskspace. So kann man sich die Größe jedes RRA und die Gesamtgröße der Datei ausrechnen. Ca. ein Kilobyte größer ist das File wegen der Metadaten danach, aber das ist vernachlässigbar.
Mit den Standardsettings des Excels ist das ca. 110 kB, mal 3 (AVG, MIN, MAX) = 330 kB.

Ich würde in allen Fällen und für alle Detailgrade immer AVG, MIN, MAX nehmen.

Bezüglich Aufzeichnungs-Detailgrad würde ich per Default grundsätzlich auf fünf Minuten gehen, und nur in Ausnahmefällen (als Option) eine Minute ermöglichen. Es kommt bei vielen Statistiken schon einiges an Last am Miniserver zusammen, das darf man nicht außer Acht lassen.

Meine RRA-Intervalle sehen ähnlich aus wie im Excel.

Auf Basis dessen, was ich verwende (und ich heute für Gut oder Schlecht empfinde), würde ich folgendes Set als Default machen:
Tage/Minuten:
31 (1 Monat) / 5 Min.
92 (2 Monate) /15 Min.
365 (1 Jahr) / 60 Min.
7305 (20 Jahre) /1440 (1 Tag)

Das ergibt eine Dateigröße (AVG/MIN/MAX) von ca. 800 kB pro Statistik. In meinen laufenden Statistiken habe habe ich hier teilweise andere Einstellungen, die mich stören (beispielsweise die 5-Minuten-Werte nur eine Woche, stört mich beim Vergleichen von KWs; oder die 60 Minuten-Werte habe ich mehr als ein Jahr, aber völlig nutzlos; den 20-Jahr-RRA habe ich gar nicht, und das stört mich, weil ich mit meinen Daten nur 2 Jahre vergleichen kann).

Eine Erfahrung ist, dass man auch keine größeren Poll-Intervalle als 5 Minuten will. Auch wenn es Daten gibt, wo es keinen Sinn macht, diese so oft abzuholen, will der innere Schweinehund einfach aktuelle Daten sehen, und nicht was, was Stunden her ist. Es gibt auch ein schnelles Erfolgserlebnis (die Diskussionen kennen wir ja vom IRR mit den Fragen, "schaltet zu bald ein" nach 5 Minuten Betrieb... ;-) ).
Vielleicht höchstens noch 60 Minuten, aber das macht (leider) die Generierung und das Polling der Daten komplizierter (STEP und HEARTBEAT).

Den xff-Parameter - wird meist mit 0,5 definiert - solltest du auf 0,08 setzen. Warum 0,08? Stellt man später ein Polling-Intervall von 5 Minuten auf 60 Minuten (1/12), funktioniert das Datenset noch! Ebenso würde ich das beim Heartbeat machen - fix auf stepsize * 13. Man erkennt zwar später, wenn die Datenquelle ausgefallen ist, aber bekommt dafür später NaN-Einträge.

Den --start Parameter bitte unbedingt auf Loxone-Epoch 0 setzen! Das ermöglicht nachträglich den Import z.B. von Loxone-Statistikdaten! Standardmäßig ist die Startzeit die Erstellungszeit, und RRD lässt keine älteren Daten zu!

Du solltest den gesamten Code unter Einbeziehung des rrdcached-Daemons aufbauen. Es muss am System dann nur eine Environment-Variable geben, die Host:Port des Daemons angibt, damit dieser von den Funktionen (vor allem UPDATE) verwendet wird. Das FETCH (egal ob den RRD-Graph oder durch eine andere Visualisierung aufgerufen), triggert vor Abruf von Daten dann automatisch ein Flush. Ob das dateibasierte Journaling von rrdcached auf der SD einen Sinn macht, weiß ich nicht.
Mit rrdcached hab ich selbst jedoch keine Erfahrung, weil Cacti sein eigenes Caching verwendet.
Bei Cacti verwende ich ein Flush-Intervall von 60 Minuten.

Das Pollen von Loxone mache ich mit einer Sekunde Pause zwischen jedem Objekt, damit sich der Miniserver "erholen" kann. Das dauert dann zwar etwas länger, aber sei's drum.

Ich glaub, ich hab alles :-)

lg, Christian

PS beim Testen: Die Intervalle kann man auch human readable angeben, z.B. 5m oder 24h, statt alles mit der Stepsize umzurechnen.

[Prof.Mobilux]

Also ich habe das Wochenende genutzt um mich ein wenig mehr mit dem RRDTool zu beschäftigen und mich ein wenig einzulesen. Ich bin wirklich begeistert und werde RRD für das Plugin als Datenbank verwenden.

Nun ist es ja so, dass man zum Zeitpunkt der Erstellung der Datenbanken schon sehr viele Vorgaben bzgl. Speicherintervall, Archive, etc. machen muss. Die meisten davon sind später nicht mehr änderbar. Das wird einen Laien mit Sicherheit überfordern (ich habe auch mehrere Anläufe gebraucht, bis ich Step, Heartbeat, RRA, PDP, CDP, XFF usw. voreinander bekommen habe).

Ich möchte daher beim Anlegen der Datenbanken für den Laien sinnvolle Vorgaben machen, die aber dann natürlich per "Expertenmodus" überschrieben werden können.

Christian Fenzl Du hast ja schon Erfahrung mit den RRD-Datenbanken. Kannst Du etwas zu sinnvollen Vorgaben sagen? Wäre das abhängig vom gewählten Erfassungsintervall? Oder besser von der Art des erfassten Messwerts (Temperatur, Energie, etc.)? Auch stelle ich mir die Frage ob man nur Mittelwerte ins Archiv schreibt oder auch gleich Min/Max-Werte.

Ziel müsste es sein Vorgaben zu finden, die einen vernünftigen Kompromiss zwischen Speicherbedarf und Auswertemöglichkeiten bilden und für möglichst viele User brauchbar sind (alle wird man nicht unter einen Hut bekommen und "Experten" können nach herzenslust anpassen).

Ich habe dazu im Netz eunen RRD-Calculator gefunden, mit dem ich schon etwss rumgespielt habe. Die häufigsten Erfassungsintervalle werden sicherlich 1, 3, 5, 10, 15, 30 ,60 Minuten auf dem LoxBerry sein.

[Gerrit]

Hab den ELK Stack auch schon in verschiedenen Projekten eingesetzt. Curator hilft dir nur wie du schon schreibst um Daten komplett zu löschen, aber nicht wie RRD normalerweise entsprechend nach gewissen Zeitabständen zu aggregieren und die Ursprungswerte zu löschen. Beim Strom, Wasser-verbrauch oder PV Anlagen Erzeugung etc. möchte man aber schon Jahre vergleichen. Daten dann doppelt vorzuhalten ist nicht effizient (weil bei PV etc.interessieren dich auch aktuelle Werte in feinerer Auflösung) und kostet Performance. Das ist auch etwas was Loxone auf jeden Fall verbessern müsste.

Ich glaub auch dass ELK einfach zu anspruchsvoll für den Raspi sein wird, insbesondere wenn man ja auch noch andere Dinge darauf laufen lassen will. Viel Daten im RAM cachen geht wegen wenig RAM nicht und SD Karte ist auch im Vergleich zur normalen Festplatte (nicht SSD) im Nachteil.

[bdaenzer]

um alte daten zu löschen/archivieren/datenmenge im griff zu halten (und auch die performance) gibt es für den ELK stack eine komponente namens "curator".

https://www.elastic.co/blog/curator-tending-your-time-series-indices

man darf einfach nicht endlos füllen ohne wieder mal zu spülen... sonst geht's irgendwann an den speed und den speicherplatz. für die meisten smarthome themen dürfte aber nicht viel mehr als das letzte jahr interessant sein. sonst muss man einen separaten export für langzeitstorage / einzelne datenelemente machen.
was stimmt ist, man kann nicht einfach die daten "reduzieren". entweder stehen alle in der ganzen detailtiefe zur verfügung oder dann gar nicht.

http://logz.io/learn/complete-guide-elk-stack/