Influx - Grafana - Problem mit/bei LBS 19002576

[jonofe]

In der neuen Version ist es jetzt so: Wenn E7 leer ist werden ALLE IDs übertragen. In alter Version wurde nichts gemacht.

Habs mir gerade nochmal angeschaut. Works as designed 😉
Steht auch so in der Hilfe:

E7: 'all' or empty will mirror all existing EDOMI data archives to the Influx v2 database.

Und E10 wird auch bei E1=0 ausgeführt, was auch Sinn macht.
E1 ist also der Schalter für das automatische syncen und E10 triggert einmalige Aktivitäten.
Kann aus meiner Sicht auch so bleiben, da es so Sinn macht. Oder?

[gibsonrocker]

Also ich dachte bei der letzten Version war das mit E7 anders. Aber klar, macht alles so Sinn und passt auch so!

Danke Dir!

[jonofe]

Also ich dachte bei der letzten Version war das mit E7 anders.

Kann es mir kaum vorstellen, da intern im LBS der Wert auf 'all' gesetzt wird, wenn er leer ist:

if ($E[7]['value'] != '' && $E[7]['value'] != 'all')
$dataArchiveIds = explode(',', $E[7]['value']);
else
$dataArchiveIds = 'all';​ 

Naja, Hauptsache es funktioniert jetzt so wie dokumentiert.

[stonie2oo4]

Woran kann es denn liegen das ich keine Berechtigung zum anschauen des CutomLog von dem LBS habe?


influx_log.jpg

[jonofe]

mach mal ein

chmod 777 /usr/local/edomi/www/data/log/CUSTOM*

danach sollte es funktionieren.

[stonie2oo4]

Perfekt, funktioniert.
Vielen Dank

[rdeckard]

jonofe
Hallo Andre

Ich habe es nun auch endlich mal geschafft, mich mit deinem InfluxDB LBS zu beschäftigen.
Leider scheint mein Datenarchiv etwas gross zu sein. Es sind nämlich ca. 16 Mio. Einträge in der MySQL DB drin!

grafik.png

Im Edomi Fehler-Log sehe ich diesen einen Eintrag

Datei: /usr/local/edomi/www/data/liveproject/lbs/EXE19002576.php | Fehlercode: 1 | Zeile: 213 | Allowed memory size of 134217728 bytes exhausted (tried to allocate 114554112 bytes) FATALERROR

Da ich dieser VM (bzw. Container) 2 GB RAM zugewiesen habe und dies nie über 500 MB gegangen ist, scheint es sich eher um ein anderes Problem zu handeln (irgend eine Environment Variable).


Hier noch die Vorgeschichte dazu (alles noch Test):

1. Habe einen älteren Mac mini (Intel i5 2.5 GHz, 16 GB RAM, 250 GB SSD) gelöscht und Proxmox 7.3 (Bare metal) installiert.
2. Habe zwei LXC Container erstellt: Den Edomi-Container von starwarsfan (Rocky Linux) und ein Ubuntu 22.10 mit aktuellen InfluxDB 2.6. drin.
3. Habe von meinem produktiven Edomi 2.03 (physisch APU) ein Backup genommen und dieses in den Edomi-Container geladen (KNX und alle LBS deaktiviert).
4. Habe deinen LBS installiert und soweit ich beurteilen kann, keine Probleme erhalten.
5. Da Edomi in diesem Container aktuell keine neuen Archivdaten erhält, geht es mir in erster Linie nur mal um den einmaligen Copy nach InfluxDB. (Im Edomi-Container sind somit alle 16 Mio. Archiveinträge, verteilt auf 31 Archive.)

So sehen die Einstellungen zum LBS aus:

grafik.png

E7 und E8 haben hier ja keine Bedeutung, da keine neuen Archiveinträge geschrieben werden.
E10 habe ich in der Live-Ansicht auf "all" gesetzt. (E13 habe ich testhalber mal auf 500 gesetzt, aber denke nicht, dass dies mein Problem ist.)

Das LBS EXEC-Log sieht so aus:

2022-12-19 19:25:17 CET START
2022-12-19 19:25:17 CET START copying data archives
2022-12-19 19:25:17 CET Data archives in scope: all
2022-12-19 19:25:17 CET Data archives in scope: ["2","3","6","7","8","9","10","11","12","13","1 4"," 15","16","17","18","19","20","21","22","23","24" ," 25","26","27","28","29","30","31","32","33","34"]
2022-12-19 19:25:17 CET COPY-ID:2
2022-12-19 19:25:17 CET Start copying data archive: 2
2022-12-19 19:25:17 CET Query: SELECT name FROM edomiLive.archivKo where id = 2
2022-12-19 19:25:17 CET Copying 'Temperatur Aussen Elsner' data archive to Influx DB...
2022-12-19 19:25:17 CET Query: SELECT * FROM edomiLive.archivKoData where targetid=2 AND datetime > '1970-01-01 00:00:00' AND datetime < '2022-12-19 19:25:17'

In InfluxDB kommt aber nichts an, vermutlich weil der LBS schon vorher abbricht.

Mein nächste Schritt ist mal das Edomi Datenarchiv komplett zu löschen (im Container) und dann mit ein paar manuell erzeugten Archiveinträgen (via Live-Ansicht) testen, ob die ganze Kommunikation zwischen Edomi (LBS) und dem InfluxDB überhaupt funktioniert. (Diese Container Testumgebung habe ich erst heute installiert und somit ist für mich noch alles neu.)

Aber evtl. hast du trotzdem eine Idee, von wo diese Memory Allokations Fehlermeldung herkommen könnte.

Danke!

[rdeckard]

So, ich bin etwas weitergekommen. Habe alle meine Archive auf 1 Woche Speicherdauer gesetzt. (Was aber bei mir eher alle Archiv-Einträge komplett gelöscht hat.)
Immerhin kam nun nicht mehr der Memory-Fehler und das EXEC-Log zeigte nun alle 31 Datenarchive an. (Es kam zwar der bekannte Fehler "No PSR-18 clients found.", aber da gibt es ja im Forum bereits Lösungen dazu.)

Aktuell sieht mein EXEC-Log so aus (Beispiel nur vom ersten Datenarchiv):

2022-12-19 20:21:07 CET START
2022-12-19 20:21:07 CET START copying data archives
2022-12-19 20:21:07 CET Data archives in scope: all
2022-12-19 20:21:07 CET Data archives in scope: ["2","3","6","7","8","9","10","11","12","13","1 4"," 15","16","17","18","19","20","21","22","23","24" ," 25","26","27","28","29","30","31","32","33","34"]
2022-12-19 20:21:07 CET COPY-ID:2
2022-12-19 20:21:07 CET Start copying data archive: 2
2022-12-19 20:21:07 CET Query: SELECT name FROM edomiLive.archivKo where id = 2
2022-12-19 20:21:07 CET Copying 'Temperatur Aussen Elsner' data archive to Influx DB...
2022-12-19 20:21:07 CET Query: SELECT * FROM edomiLive.archivKoData where targetid=2 AND datetime > '1970-01-01 00:00:00' AND datetime < '2022-12-19 20:21:07'
2022-12-19 20:21:07 CET Query SUCCESS

Dumme Frage: Wie kann ich am einfachsten ein paar Werte in das Datenarchiv schreiben? Du hast in diesem Thread mal das folgende geschrieben:

Dann solltest du mal einen Wert in das Datenarchiv schreiben, z.B. über die Liveansicht.
Dann sollte dazu ein Eintrag im Log auftauchen und dann auch in Influx.

Soll ich einfach den LBS nehmen, den ich sonst zum (automatisierten) Schreiben in das Datenarchiv verwende und dann in der Liveansicht manuell Testdaten eingeben?

[rdeckard]

Wieder ein (wichtiger) Schritt weitergekommen.

Edomi und dein LBS schreibt Daten in die InfluxDB!

Habe es geschafft, via Liveansicht jeweils 2 Testeinträge in ein Datenarchiv zu schreiben.
Komischerweise hat dein LBS das nicht getriggert, obwohl E1=1 und E7=all gesetzt war. (spielt es eine Rolle, ob "copy" oder "sync" Mode? Sollte ja eigentlich nicht...)

Hab danach im LBS Liveansicht nochmals E10 auf "all" gesetzt, was dann die Testdaten wirklich in die InfluxDB kopiert hat.

2022-12-19 21:15:42 CET START
2022-12-19 21:15:42 CET START copying data archives
2022-12-19 21:15:42 CET Data archives in scope: all
2022-12-19 21:15:42 CET Data archives in scope: ["2","3","6","7","8","9","10","11","12","13","1 4"," 15","16","17","18","19","20","21","22","23","24" ," 25","26","27","28","29","30","31","32","33","34"]
2022-12-19 21:15:42 CET COPY-ID:2
2022-12-19 21:15:42 CET Start copying data archive: 2
2022-12-19 21:15:42 CET Query: SELECT name FROM edomiLive.archivKo where id = 2
2022-12-19 21:15:42 CET Copying 'Temperatur Aussen Elsner' data archive to Influx DB...
2022-12-19 21:15:42 CET Query: SELECT * FROM edomiLive.archivKoData where targetid=2 AND datetime > '1970-01-01 00:00:00' AND datetime < '2022-12-19 21:15:42'
2022-12-19 21:15:42 CET Query SUCCESS
2022-12-19 21:15:42 CET COPY-ARCHIVE: archiveName: Temperatur Aussen Elsner, archiveId: 2, value: 0.7, Micro Epoch: 1671480600303673
2022-12-19 21:15:42 CET COPY-ARCHIVE: archiveName: Temperatur Aussen Elsner, archiveId: 2, value: 0.7, Micro Epoch: 1671480900212521
2022-12-19 21:15:42 CET COPY-ID:3
2022-12-19 21:15:42 CET Start copying data archive: 3
2022-12-19 21:15:42 CET Query: SELECT name FROM edomiLive.archivKo where id = 3
2022-12-19 21:15:42 CET Copying 'Temperatur Innen' data archive to Influx DB...
2022-12-19 21:15:42 CET Query: SELECT * FROM edomiLive.archivKoData where targetid=3 AND datetime > '1970-01-01 00:00:00' AND datetime < '2022-12-19 21:15:42'
2022-12-19 21:15:42 CET Query SUCCESS
2022-12-19 21:15:42 CET COPY-ARCHIVE: archiveName: Temperatur Innen, archiveId: 3, value: 23.4, Micro Epoch: 1671480600311810
2022-12-19 21:15:42 CET COPY-ARCHIVE: archiveName: Temperatur Innen, archiveId: 3, value: 23.4, Micro Epoch: 1671480900213542

Und so siehts in InfluxDB aus:
grafik.png

Damit kann ich bestätigen, dass meine Konfiguration funktioniert.

Bleibt die ursprüngliche Frage, wie man den Memory-Fehler bei 16 Mio. Einträgen wegbekommt? (Ich könnte sonst auch mal testen, wie es sich mit einzelnen Datenarchiv-IDs anstatt "all" verhält.)

[jonofe]

Einfach eine Ausgangsbox verwenden, die dann ins Datenarchiv schreibt.

Und bzgl. Speicher Problem einfach in kleineren Intervallen (E11) kopieren oder die archive einzeln kopieren (E10). Nicht gleich von 1970, sondern vielleicht mal nur einen Monat. Batch Size ist nicht das Problem.

[rdeckard]

Um Zeit zu sparen, habe ich es mal mit der Brechstange probiert und einfach im /etc/php.ini den Default-Wert

memory_limit = 128M

auf

memory_limit = 1024M

erhöht. (Nur für diese einmalige Sache.)

Und was soll ich sagen: Es hat danach wunderbar geklappt. Mit E10=all konnte ich ALLE 16 Mio. Einträge in einem Rutsch zu InfluxDB kopieren! (Hat ca. 21 Min. gedauert. Von einer VM (bzw. Container) auf die andere auf dem gleichen Proxmox-Host.)

Und auch wenn ich von InfluxDB natürlich eine viel höhere Performance gegenüber MySQL erwartet habe, so hat es mich doch extrem verblüfft, wie schnell ein Query in InfluxDB über diese ganzen 16 Mio. Einträge nun läuft. Z.B. zwei Sensordaten (Feuchtigkeit Innen und Aussentemperatur) über eine Periode von 30 Tage (egal, welches Startdatum) dauert sage und schreibe 0.02 Sekunden, also sofort.
Nach Jahren, wo ich in Edomi schon längst keine Diagramme mehr erstellen konnte, weil die Daten einfach zuviel wurden, ich aber die Daten trotzdem weiter sammeln wollte, ist es für mich aktuell wie eine Offenbarung, wieder auf diese Daten zugreifen zu können. Wahnsinn!

Hier der "Beweis" mit einem Quick'n Dirty Query in InfluxDB 2.6 (kein Grafana!):
grafik.png

Falls es jemand interessiert, hier noch das Verhalten der beiden VMs (bzw. Container) während des Kopierens der Daten:

Edomi
grafik.png
2 GB RAM, 2 CPU und 10 GB Disk wurden von Anfang zugewiesen.
Die Migration wurde um 22:41 gestartet und war um 23:02 fertig (21 Min.).
Max. Werte während der Migration: ca. 40% CPU und ca. 800 MB RAM.
Nach der Migration pendelten sich die Ressourcen wieder auf Werte vor der Migration ein. (Man muss berücksichtigen, dass auf dieser Edomi-Instanz KNX und alle LBS bis auf den InfluxDB-LBS deaktiviert sind, somit läuft nicht viel im Hintergrund.)
Kritisch war das noch aktivierte InfluxDB-LBS Debug-Log, welches mir sehr schnell die Disk füllte. (Musste es mehrmals während der Migration löschen, da ich auf diesem Test Conainter halt nur eine sehr minimale Disk-Grösse zugewiesen hatte.)

InfluxDB
grafik.png
Im Gegensatz zum Edomi-Container habe ich hier mit 1 GB RAM begonnen, merkte aber während der Migration schnell, dass das nicht reicht und habe es dann auf 2 GB erhöht.
Max. Werte während der Migration: ca. 8% CPU und ca. 1.5 GB RAM.
Interessanterweise wurde der RAM Peak erst NACH der eigentlichen Migration erreicht. Auch die CPU-Werte gingen nur langsam runter. Es scheint, dass InfluxDB noch länger im Hintergrund mit diesen neuen Daten "arbeitet" (Index erstellen?).
Was mich auch erstaunt: Obwohl aktuell InfluxDB inaktiv ist (läuft, aber es werden keine neuen Daten geschrieben und keine Queries erzeugt), ist nun die CPU und RAM Last (idle?) wesentlich höher als noch vor der Migration. Selbst jetzt, über 12 Std. später liegen die Idle-Werte bei ca. 630 MB RAM und 1% CPU. (Vor der Migration bei ca. 128 MB RAM und 0.2% CPU)
Die Disk hat erstaunlicherweise die 1 GB (von 10 GB) noch nicht überschritten, scheint also nicht so kritisch zu sein. Die Bucket Grösse (Disk Size) dieser 16 Mio. Edomi-Einträge scheint "nur" 161 MB zu sein.

root@influxdb-test:~# du -sh /var/lib/influxdb/engine/data/25eddba8e7343a21/
161M    /var/lib/influxdb/engine/data/25eddba8e7343a21/​

Vielleicht hilft dem einen oder anderen diese Beobachtungen.

[nno]

Ich bin im Moment auch dabei Daten von Edomi nach Influx DB zu bekommen. Daher erstmal vielen Dank an Andre für den LBS 19002576!

Problem ist, dass ich die Logdatei nicht mehr öffnen kann. Da die Logdatei sehr große geworden war, hatte ich sie in EDOMI gelöscht (Verwaltung > Logdateien > Rechte Mausklick auf "Influx_Data_Archives-EXEC" > Löschen). Wenn ich die Logdatei jetzt anzeigen möchte, geht ein neuer Browser-Tab auf, aber es kommt die Fehlermeldung:

Forbidden

You don't have permission to access /data/log/CUSTOMLOG_Influx_Data_Archives-EXEC.log on this server.

Hat jemand eine Idee wie ich das wieder gefixt bekomme?

[jonofe]

Mit einem chmod 777 auf diese Datei.

[nno]

Danke, hat geklappt.

Beim "Deaktivieren" des Sync (also E1=0) wird das Löschen der DB Trigger im Log im Moment nicht erwähnt. Ich habe den LBS daher angepasst (siehe /* <== ADDED */ unten), so dass Log-Einträge erstellt werden (analog zum Anlegen der Trigger)

...
} elseif ($E[1]['value'] == 0) {
   $mysqli = new mysqli(global_sqlHost, global_sqlUser, global_sqlPass, 'edomiLive');
   if (!$mysqli->connect_error) {
      $mysqli = new mysqli(global_sqlHost, global_sqlUser, global_sqlPass, 'edomiLive');
      if (!$mysqli->connect_error) {
         $query = "DROP PROCEDURE IF EXISTS influx_update;";
         LB_LBSID_logging($id, "Query: " . $query);  /* <== ADDED  */
         $result = $mysqli->query($query);
         $query = "DROP TRIGGER IF EXISTS influx_insert_trigger;";
         LB_LBSID_logging($id, "Query: " . $query); /* <== ADDED  */
         $result = $mysqli->query($query);
         $query = "DROP TRIGGER IF EXISTS influx_update_trigger;";
         LB_LBSID_logging($id, "Query: " . $query); /* <== ADDED  */
         $result = $mysqli->query($query);
         $query = "DROP TRIGGER IF EXISTS influx_delete_trigger;";
         LB_LBSID_logging($id, "Query: " . $query); /* <== ADDED  */​
         $result = $mysqli->query($query);
      } else
         LB_LBSID_logging($id, "ERROR: Unable to delete Influx triggers and stored procedures");
      } else
   LB_LBSID_logging($id, "ERROR: Unable to connect to mysql database");
}
... 

[nno]

Nochmal zu dem Problem, dass die Log Datei nicht mehr angezeigt werden kann, nachdem sie geleert wurde. Das liegt wohl daran, dass die Zugriffsrechte im LBS nur neu gesetzt werden, wenn E1 = 1 gesetzt wird. Da das bei mir im laufenden Betrieb aber nicht passiert, habe ich daher die logging function ergänzt:

function logging($message, $ll = 8)
{
   global $loglevel;
   if ($ll <= $loglevel) {
      touch('/usr/local/edomi/www/data/log/CUSTOMLOG_Influx_Data_Archives-EXEC.log');  /* <== ADDED */
      chmod('/usr/local/edomi/www/data/log/CUSTOMLOG_Influx_Data_Archives-EXEC.log', 0666);  /* <== ADDED */
      file_put_contents('/usr/local/edomi/www/data/log/CUSTOMLOG_Influx_Data_Archives-EXEC.log', date("Y-m-d H:i:s T") . "\t" . $message . "\n", FILE_APPEND);
   }
}