Stats4Lox - Das Statistik-Plugin

[marcb]

Erst mal vielen Dank für das geniale Plugin!

Ich habe gestern Abend ca. 100 Statistiken eingelesen - dabei ist dann aber der Miniserver mehrmals "ausgestiegen" (d.h. er war ca. eine Minute nicht mehr erreichbar, auch nicht über die LoxApp. es wurde aber keine Neustart im Systemstatus geloggt ). Ca. 30 Statistiken waren zunächst "dead", wurden nach weiteren Versuchen dann aber alle korrekt eingelesen.

Bei einer Statistik gab es einen Error, die hatte ich gestern schon mehrmals neu gestartet, und als ich sie heute neu gestartet habe ist der Miniserver erneut ausgestiegen. Daher vermute ich dass auch die Probleme gestern von dieser einen Datei kamen.
So, nochmal probiert, ist reproduzierbar mit dieser Statistik, hier das LOG zu dem Error: import_1_16dbbac7-0318-205f-ffffc538dfda455c.json.log

Mein Loxberry läuft als VM mit ausreichend Ressourcen (2GB Ram, 30HB HD)

Gibt es eine Größenordnung (Anzahl der Live-Werte die vom Miniserver pro 5Min eingesammelt werden) ab der ein Miniserver2 an seine Grenzen kommt?

[marcb]

ich habe gerade festgestellt dass ich heute doch 2 Neustarts des MS in zeitlichem Zusammenhang mit dem fehlgeschlagenen Import hatte

[marcb]

Ich habe die erste Statistik-Datei vom Mai 2021, bei welcher der Fehler aufgetreten ist, mal gelöscht. Anschließend konnte ich die restlichen Statistikdaten bis heute problemlos einlesen.
Hier die "schuldige" Datei: 16dbbac7-0318-205f-ffffc538dfda455c.202105.txt

[Christian Fenzl]

Da ich beim Import nicht das Loxone Binary herunterlade, sondern das über die Web-API von Loxone mache (ich bekomme die Daten also „lesbar“ vom MS geliefert), gehe ich davon aus, dass das Binary schon am MS kaputt ist, was den Miniserver zum Absturz bringt.

[Futureweb]

Ja, das ist heftig.....

Versuch mal, ob du mit
rm logs_sqlite.dat*
die Files löschen kannst.

19 Stunden später ist die Ramdisk schon wieder voll ... :-/

root@loxberry:/opt/loxberry/log/system_tmpfs# ll -h log*
-rw-r--r-- 1 loxberry loxberry 128M Nov 16 07:45 logs_sqlite.dat
-rw-r--r-- 1 loxberry loxberry 480K Nov 16 07:45 logs_sqlite.dat-shm
-rw-r--r-- 1 loxberry loxberry 229M Nov 16 10:25 logs_sqlite.dat-wal

Bekommen wir da iw. raus wieso die Logs so schnell explodieren? 🤔

[Christian Fenzl]

Kannst du prüfen, ob du im Log Manager bei irgendwas ungewöhnlich viele Warnings/Errors in der I-Übersicht hast?
Irgendeins der Logfiles ist dafür verantwortlich, und ich muss die Meldung kennen, die das Log flutet, damit ich das adressieren kann.

[Futureweb]

Gerade geschaut ... Alle Logiles 0B ... kann es sein dass er sie nicht mehr auslesen kann wenn die RAMDISK voll ist?!?
Ich lösche nochmal, reboote und schau mal ob ich dann nen schnellen Anstieg feststellen kann ...

[Futureweb]

Christian Fenzl Sodala - LoxBerry ist seit ca. 15 Minuten wieder up ... In der LoxBerry Log-Übersicht sehe ich leider KEINEN Ausreisser beim Speicherverbrauch ... (Logiles/Mehr Logfiles)

Aber das logs_sqlite.dat-wal ist schon wieder auf 4MB oben ...

-rw-r--r-- 1 loxberry loxberry 128K Nov 16 14:19 logs_sqlite.dat
-rw-r--r-- 1 loxberry loxberry 32K Nov 16 14:26 logs_sqlite.dat-shm
-rw-r--r-- 1 loxberry loxberry 4.0M Nov 16 14:26 logs_sqlite.dat-wal

Vorher war das logs_sqlite.dat-wal ja auf 229MB ... sollte das Write-Ahead-Logging nicht generell automatisch nach ~1.000 Pages flushed werden?!? (https://www.sqlite.org/wal.html)
(Dann würde wohl daslogs_sqlite.dat anwachsen ... also nur ne Verschiebung des Problems ... ^^)-

[Futureweb]

2h20min online - und wieder vollgelaufen - Alle Logs im LoxBerry zeigen wieder 0B an ... :-/

root@loxberry:/opt/loxberry/log/system_tmpfs# uptime
16:30:13 up 2:18, 1 user, load average: 0.61, 0.29, 0.12
root@loxberry:/opt/loxberry/log/system_tmpfs# ll -h logs_sqlite.dat*
-rw-r--r-- 1 loxberry loxberry 130M Nov 16 16:30 logs_sqlite.dat
-rw-r--r-- 1 loxberry loxberry 480K Nov 16 16:30 logs_sqlite.dat-shm
-rw-r--r-- 1 loxberry loxberry 226M Nov 16 16:30 logs_sqlite.dat-wal

[Christian Fenzl]

Hast du einen Storage, wo du das gezippt hochladen kannst, damit ich mir die DB anschauen kann?

[Futureweb]

svethi - Leider nicht ;-)
Christian - bekommst gleich einen Download-Link mit der DB per PM

[Futureweb]

Neuestes Release schaut schon mal gut aus bzgl. der Log Problematik ... Logs heute noch im Rahmen ... ;-)

-rw-r--r-- 1 loxberry loxberry 816K Nov 17 11:36 logs_sqlite.dat
-rw-r--r-- 1 loxberry loxberry 32K Nov 17 11:38 logs_sqlite.dat-shm
-rw-r--r-- 1 loxberry loxberry 5.4M Nov 17 11:38 logs_sqlite.dat-wal

[toubee]

Ich hatte ja ursprünglich ein ähnliches Problem (Aussetzer bei der Datenerfassung über MQTT). Leider kann ich noch kein Feedback geben, ob das Problem weiterbesteht, denn um allfällige Performance-Probleme zu eliminieren habe den Loxberry kürzlich in eine VM migriert.

ein ähnliches Problem wie Futureweb hatte ich auch kürzlich, aber bei mir wars ganz offensichtlich eine volle RAM-Disk, vermutlich ausgelöst durch den Loglevel = Debug vom Stats4Lox Plugin nach einem input von Christian :-)

Lustigerweise habe ich zur Zeit ein ganz anderes (zusätzliches) Problem: Ich glaube ich habe mir die Konfiguration des Plugins etwas "zerschossen".

Ich krieg seit einiger Zeit folgende Fehlermeldungen beim der Log-Gruppe 'Grabber_loxone':



Ich bin mir ziemlich sicher, dass hier noch ein "Zombie"-Statistikselektionen versuchen Daten von einem Merker zu holen, welchen ich aus der Config gelöscht hatte, bevor ich den Statistik-download deaktiviert hatte
Ich konnte einen Teil der Fehlermeldungen loswerden, indem ich:

• eine ältere config geladen habe
• Im Plugin unter "Loxone and Import" -> "Statistic Selection" die Config neu vom Miniserver geladen habe
• bei der betroffenen Statistikselektion den regelmässigen Abruf deaktiviert habe
• wieder die aktuelle config geladen habe

Ich konnte auf die Schnelle keine Einfachere Lösung finden, da Statistikselektionen, welche zwar noch aktiviert sind, jedoch in der Config nicht mehr existieren unter "Statistic Selection" nicht aufgeführt werden.

Vielleicht weiss jemand eine Möglichkeit wie ich die restlichen 2 Zombies loswerde (habe die entsprechende Config nicht mehr gefunden).

Oder aber ich würde ein Feature vorschlagen, welches bei den Filtern eine zusätzliche Option hat, um diese verwaisten Statistikselektionen anzeigen zu können, vielleicht hat jemand anders in Zukunft das gleiche Problem wie ich.



Vielen Dank und Grüsse, toubee

[Christian Fenzl]

toubee
Issue ist erzeugt: https://github.com/mschlenstedt/LoxB...-NG/issues/118

Du kannst derzeit nur manuell die toten Einträge entfernen:
/opt/loxberry/config/plugins/stats4lox/stats.json

Mit den Namen findest du die Blöcke.
Mach vorher ein Backup der Datei! Und mach das json nicht kaputt 😁

[toubee]

Habe mir schon gedacht, dass ich das irgendwo manuell korrigieren kann.
Cool, danke für den Input und für die Erstellung des Tickets!

[bastelbert]

Christian Fenzl

Ich habe das Plugin installiert und win wenig damit gespielt. Nun habe ich es deinstalliert da ich es auf einer eigenen VM laufen lassen will.
Außer die Plugin Ordner wird irgendwie nichts entfernt, Telegraf, Grafana InfluxDB etc bleiben auf dem System.
Das finde ich jetzt auch noch nicht schlimm, was mit aber aufgefallen ist, der eine MQTT Live Eintrag den ich angelegt hatte sendet munter weiter, auch wenn das Plugin deinstalliert ist.


Wo ist der angelegt?
Wie kann ich den deaktivieren?

Könnt ihr das bei der Deinstallation berücksichtigen das solche Einträge mit gelöscht werden?.
Bzw. gibt es vielleicht einen Grund den ich nicht sehe warum MQTT Live weiter aktiv bleibt?

Ich stelle nach der Deinstallation des Plugins ebenfalls fest, dass die Prozesse telegraf, influxd und grafana-server noch laufen.
Ein Neustart des Loxberry bringt keine Abhilfe. Wie kann ich die Rückstände sauber entfernen?
Danke euch!

[Thomas M.]

Komisches Phänomen … nach x Wochen Laufzeit ist mir aufgefallen, Dass in einem Diagramm eine Kurve fehlte.

ich konnte keine einzige Kurve mehr hinzufügen.

In den loxberry geguckt …
alles voll mit Warnungen und Fehlern

-es konnten keine Mails gesendet werden. Nichtmal eine Testmail - temp voll.
-Irgend ein Speicher voll, temp irgendwas
- CPU Last x mal so hoch als normal
- CPU temp 50 statt ca. 40grad
- minisverver backup voller fehler (backups laufen so gegen 21 Uhr an glaub ich)

nur ein Reboot löste das Problem.

was kann das sein?

[Futureweb]

-Irgend ein Speicher voll, temp irgendwas

Das Problem mit RamDisk vollgelaufen hatte ich auch - wenn es bei dir das gleiche Problem sein sollte (nachdem es aussieht) dann sollte die letzte Version aus dem GITHUB das Problem beheben - hat mir Christian letztens geschickt ... :-) --> https://github.com/mschlenstedt/LoxB...heads/main.zip

[Thomas M.]

Thx werde ich probieren

[Thomas M.]

-es konnten keine Mails gesendet werden. Nichtmal eine Testmail - temp voll.
-Irgend ein Speicher voll, temp irgendwas
- CPU Last x mal so hoch als normal
- CPU temp 50 statt ca. 40grad


nur ein Reboot löste das Problem.

was kann das sein?

minisverver backup war auch voller fehler. Backups laufen so gegen 21 Uhr an glaub ich, der screenshot zeigt, dass zu dem Zeitpunkt der Temp- CPU load, ... anstieg und nicht mehr runterging.

Liegt das Problem überhaupt an dem Plugin oder vielleicht ganz wo anders?
Ich habe 2 oder 3 per mqtt live einfliegende Daten, die sich quasi sekündlich ändern. Kann es damit auch zusammenhängen?

Ich probier die änderung am stats4lox natürlich aus.

[Christian Fenzl]

Stats4Lox V0.9.5

Alle, die die V0.9.4 installiert haben, bitte diese Version installieren:
https://github.com/mschlenstedt/LoxB...tags/0.9.5.zip

Vorher bitte den LoxBerry Selbsttest machen, dass die RAMDisk nicht voll ist.

Das erweiterte Logging bei den Grabbern in V0.9.4 zusammen mit einer Unachtsamkeit von mir wird dazu führen, dass eure Log-Datenbank die RAM-Disk anfüllen wird.
Wenn die Ramdisk bereits voll ist, bitte einmal rebooten und dann nochmal den Selbsttest ausführen. Nur, wenn die RAM-Disk nicht ganz voll ist, das Update ausführen.

lg, Christian

PS Thomas M. Wenn die Ramdisk voll ist, funktioniert meistens überhaupt nichts mehr richtig.

[t_heinrich]

Stats4Lox V0.9.5

Hallo,

kann es sein, dass die automatische Update-Prüfung (noch) nicht greift?
Ist nicht sonderlich schlimm, ist mir nur aufgefallen.

Gruß Thomas

[Prof.Mobilux]

Ja, das pflegen wir aktuell noch nicht. Kommt, wenn wir aus der Betaphase raus sind.

[t_heinrich]

Alles klar, ihr habt es also aufm Schirm! :-)
Danke euch!

[Thomas M.]

ok ich hab mal 0.9.5. draufge-installt