Influx - Grafana - Problem mit/bei LBS 19002576

[fudi6489]

Bei mir funktioniert leider das laufende Synchronisieren von Edomi auf InfluxDB nicht.
Gestern Abend habe ich mit E10 die gesamte Datenbank überspielt, was auch funktioniert hat.

image.pngAuch ist mir aufgefallen dass die Uhrzeit um eine Stunde falsch geht, das muss ich mir auch noch ansehen warum das so ist.

Danach habe ich den LBS wie folgt angepasst, und Edomi neu gestartet, nur leider bleiben die Datenbankeinträge in der InfluDB gleich.

image.png

Edomi hat mittlerweile schon 19600454 Einträge.

image.png

Ich habe auch schon versucht an E7 "all" gegen "" quasi leer auszutauschen und auf E1, E7,E8 nochmals zu triggern, alles ohne Erfolg.

Kann mir irgendwie nicht erklären an was es da scheitert.
Datum an E11 stand am Anfang noch drinnen, ist aber aktuell auch entfernt da ich in einem Beitrag gelesen habe dass dies auch nur für das einmalige Überspielen nötig ist.

LOG nach dem nächsten Neustart:

image.pngExec Log habe ich gelöscht da die Datei schon einige GB groß war, seitdem funktioniert diese nicht mehr so richtig. Rechte habe ich per

chmod 777 /usr/local/edomi/www/data/log/CUSTOMLOG_Influx_Data_Archives-EXEC.log

angepasst, aber nach Edomi Neustart sind diese wieder bei 666.

Liebe Grüße
Jürgen

[fudi6489]

Ich habe Probleme den LBS auf meinem NUC mit Yves RockyLinux zum Laufen zu bekommen.
Über Nodered habe ich schon Daten auf die InfluxDB geschrieben, sollte also grundsätzlich passen.

Ich hatte die Pakete etwa vor einem Monat schon installiert, gut möglich dass ich irgendwas übersehen habe.
Zumindest jetzt taucht der Fehler auch zuverlässig auf.

[root@edomi ~]# yum -y install php-process git gcc make mysql-devel php-devel
Letzte Prüfung auf abgelaufene Metadaten: vor 2:07:00 am Mo 06 Feb 2023 08:41:53                                                                                                              CET.
Das Paket php-process-7.4.30-1.module+el8.7.0+1067+0a7071cc.x86_64 ist bereits i                                                                                                             nstalliert.
Das Paket git-2.31.1-2.el8.x86_64 ist bereits installiert.
Das Paket gcc-8.5.0-16.el8_7.x86_64 ist bereits installiert.
Das Paket make-1:4.2.1-11.el8.x86_64 ist bereits installiert.
Das Paket mysql-devel-8.0.30-1.module+el8.6.0+1057+4d6a1721.x86_64 ist bereits i                                                                                                             nstalliert.
Das Paket php-devel-7.4.30-1.module+el8.7.0+1067+0a7071cc.x86_64 ist bereits ins                                                                                                             talliert.
Abhängigkeiten sind aufgelöst.
Nichts zu tun.
Fertig.
[root@edomi ~]# yum -y install autoconf automake libtool
Letzte Prüfung auf abgelaufene Metadaten: vor 2:07:14 am Mo 06 Feb 2023 08:41:53                                                                                                              CET.
Das Paket autoconf-2.69-29.el8.noarch ist bereits installiert.
Das Paket automake-1.16.1-7.el8.noarch ist bereits installiert.
Das Paket libtool-2.4.6-25.el8.x86_64 ist bereits installiert.
Abhängigkeiten sind aufgelöst.
Nichts zu tun.
Fertig.
[root@edomi ~]# cd /tmp
[root@edomi tmp]# git clone https://github.com/jonofe/lib_mysqludf_sys
fatal: Zielpfad 'lib_mysqludf_sys' existiert bereits und ist kein leeres Verzeic                                                                                                             hnis.
[root@edomi tmp]# cd lib_mysqludf_sys/
[root@edomi lib_mysqludf_sys]# ./install.sh
Compiling the MySQL UDF
gcc -DMYSQL_DYNAMIC_PLUGIN -fPIC -Wall -I/usr/include/mysql -I. -shared lib_mysq                                                                                                             ludf_sys.c -o /usr/lib64/mysql/plugin/lib_mysqludf_sys.so
lib_mysqludf_sys.c:40:10: schwerwiegender Fehler: my_global.h: No such file or d                                                                                                             irectory
 #include <my_global.h>
          ^~~~~~~~~~~~~
Kompilierung beendet.
make: *** [Makefile:4: install] Fehler 1
ERROR: You need libmysqlclient development software installed
to be able to compile this UDF, on Debian/Ubuntu just run:
apt-get install libmysqlclient15-dev
​

Diesen Befehl habe ich in einem anderen Beitrag gefunden und ausgeführt, aber auch ohne Besserung.

cd /usr/local/edomi/www/admin/include/php/influx-client

composer require php-http/guzzle7-adapter​

Hat jemand einen Tip für mich?
Liebe Grüße

[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);
   }
} 

[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");
}
... 

[jonofe]

Mit einem chmod 777 auf diese Datei.

[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?

[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.

[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]

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.)

[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]

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!

[stonie2oo4]

Perfekt, funktioniert.
Vielen Dank

[jonofe]

mach mal ein

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

danach sollte es funktionieren.

[stonie2oo4]

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


influx_log.jpg

[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.