Influxdb LBS19002576 Zeitzonen Problem und InfluxDB2\Model\WritePrecision

[marhal]

Wenn ich versuche mit dem composer ""psr/http-client-implementation"" zu installieren, sagt er das er das packet nicht findet .. mhhh hast du da vielleicht eine Idee jonofe ?

[rdeckard]

Hi
Das braucht es nicht. Die ersten beiden Punkte der Installationsanleitung kannst Du überspringen, da das von Andrė's anderen Bausteinen schon installiert ist. jonofe korrigiere mich bitte falls dem nicht so ist.

Kurze Frage: Meinst du mit den "ersten beiden Punkte" diese hier? MySQL Tools und Composer
D.h. man müsste nur den PHP Influx Client durchführen?

Installations needed
====================

MySQL Tools
===========
yum -y install php-process git gcc make mysql-devel php-devel
yum -y install autoconf automake libtool
cd /tmp
git clone https://github.com/jonofe/lib_mysqludf_sys
cd lib_mysqludf_sys/
./install.sh
cd /tmp
rm -rf lib_mysqludf_sys/
git clone https://github.com/mysqludf/lib_mysqludf_log
cd lib_mysqludf_log
autoreconf -i
./configure
make
make install
mysql < installdb.sql

Composer
========
cd /tmp
wget --no-check-certificate https://getcomposer.org/installer
php installer
mv -f composer.phar /usr/local/bin/composer

PHP Influx Client
=================
cd /usr/local/edomi/www/admin/include/php/
mkdir influx-client
cd influx-client/
composer require influxdata/influxdb-client-php

[jonofe]

siehe HIER

[marhal]

Ahhh Vielen Dank euch beiden

soweit habe ich das hinbekommen, jedoch steht im Log folgende Meldung

2022-12-15 16:52:31 CET INSERT : archiveName: Testarchiv, archiveId: 76, value: 22.14, timestamp: 1671119551213958
2022-12-15 16:52:31 CET INSERT-EXCEPTION
2022-12-15 16:52:31 CET EXCEPTION Message: No PSR-18 clients found. Make sure to install a package providing "psr/http-client-implementation". Example: "php-http/guzzle7-adapter".​

Gruß
Marhal

[jonofe]

Das braucht es nicht. Die ersten beiden Punkte der Installationsanleitung kannst Du überspringen, da das von Andrė's anderen Bausteinen schon installiert ist. jonofe korrigiere mich bitte falls dem nicht so ist.

Stimmt, wenn die Installationen des MQTT Publish Servers bereits im LXC Image enthalten sind, dann sollte das nicht notwendig sein.

[starwarsfan]

Hi

Ich nutze EDOMI unter dem Proxmox LXC Container aus dem Forum hier.
Bei der Installation im Linux bekomme ich folgende Fehlermeldung wenn ich dein make ausführe. Bis ./configure komme ich soweit gut durch. Es kommt folgender Fehler

[root@edomi lib_mysqludf_log]# make
...

Das braucht es nicht. Die ersten beiden Punkte der Installationsanleitung kannst Du überspringen, da das von Andrė's anderen Bausteinen schon installiert ist. jonofe korrigiere mich bitte falls dem nicht so ist.

[jonofe]

Mit proxmox und LXC kenne ich mich nicht aus. Das ganze sollte idealerweise natürlich unter centos7 kompiliert werden. Dort sollte es funktionieren.

[marhal]

Hallo jonofe,

vielleicht kannst du mir helfen, ich versuche den Baustein zum laufen zu bekommen. Ich nutze EDOMI unter dem Proxmox LXC Container aus dem Forum hier.
Bei der Installation im Linux bekomme ich folgende Fehlermeldung wenn ich dein make ausführe. Bis ./configure komme ich soweit gut durch. Es kommt folgender Fehler

[root@edomi lib_mysqludf_log]# make
make  all-recursive
make[1]: Entering directory '/tmp/lib_mysqludf_log'
Making all in test
make[2]: Entering directory '/tmp/lib_mysqludf_log/test'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/tmp/lib_mysqludf_log/test'
make[2]: Entering directory '/tmp/lib_mysqludf_log'
/bin/sh ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.    -DSTANDARD -DMYSQL_SERVER -I/usr/include/mysql -m64  -g -O2 -MT lib_mysqludf_log_la-lib_mysqludf_log.lo -MD -MP -MF .deps/lib_mysqludf_log_la-lib_mysqludf_log.Tpo -c -o lib_mysqludf_log_la-lib_mysqludf_log.lo `test -f 'lib_mysqludf_log.c' || echo './'`lib_mysqludf_log.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -DSTANDARD -DMYSQL_SERVER -I/usr/include/mysql -m64 -g -O2 -MT lib_mysqludf_log_la-lib_mysqludf_log.lo -MD -MP -MF .deps/lib_mysqludf_log_la-lib_mysqludf_log.Tpo -c lib_mysqludf_log.c  -fPIC -DPIC -o .libs/lib_mysqludf_log_la-lib_mysqludf_log.o
lib_mysqludf_log.c:86:1: error: unknown type name ‘my_bool’; did you mean ‘bool’?
 my_bool lib_mysqludf_log_info_init(
 ^~~~~~~
 bool
lib_mysqludf_log.c:113:1: error: unknown type name ‘my_bool’; did you mean ‘bool’?
 my_bool log_error_init(
 ^~~~~~~
 bool
make[2]: *** [Makefile:548: lib_mysqludf_log_la-lib_mysqludf_log.lo] Error 1
make[2]: Leaving directory '/tmp/lib_mysqludf_log'
make[1]: *** [Makefile:577: all-recursive] Error 1
make[1]: Leaving directory '/tmp/lib_mysqludf_log'
make: *** [Makefile:420: all] Error 2​

kannst du mir da weiterhelfen ?

Gruß
Marhal

[dhb2002]

Ich habe jetzt inzwischen ein Skript zur Migration der bisherigen Influx Daten mit Sekunden-Precision gebaut und werde den aktuellen Baustein jetzt austauschen und mit der Mikrosekunden Precision ersetzen.

Vielen Dank. Da kann ich ja dann wieder auf den offiziellen LBS von Dir umsteigen.

[jonofe]

[saegefisch]

zwischen 01.01.1970 und

…ach damals…als edomi noch ein rundes Panel im admin hatte… dann der Aufschrei in den späten achtzigern, als Christian es eckig machte, weil Platz her musste…

<schwelg>

[jonofe]

Hast du einen Tipp wie ich den aktuellen Bucket mit einem Kommando leeren kann?

influx delete --host http(s)://<DEIN-INFLUX-HOSTS>:8086 --org <DEINE-ORG> --bucket <DEIN-BUCKET> --start 1970-01-01T00:00:00Z --stop 2023-01-01T00:00:00Z --skip-verify --token <DEIN TOKEN>

Das --skip-verify kannst du weglassen, wenn dein Influx Hosts http und nicht https verwendet.

Danach sollte dein Bucket wieder leer sein (zumindest zwischen 01.01.1970 und 01.01.2023, ansonsten --start bzw. --stop anpassen)

[ThorstenGehrig]

Hi Jonofe
Anfängerfrage: wenn ich nur Umstellen will auf den neuen Baustein - und auf alle Daten in Influx verzichten kann - Edomi stoppen / Influx (aktueller Bucket) löschen / Edomi Updaten und starten...
Müsste ja so funktionieren, oder? Hast du einen Tipp wie ich den aktuellen Bucket mit einem Kommando leeren kann? Oder ist es einfacher/sinnvoller einen neuen Bucket anzulegen und den kompletten alten Bucket zu löschen.
(eigentlich will ich verhindern mich nochmal bei der Bucket-Einrichtung und Token einzulesen... 😎)

Gruß
Thorsten

[jonofe]

Ich habe jetzt inzwischen ein Skript zur Migration der bisherigen Influx Daten mit Sekunden-Precision gebaut und werde den aktuellen Baustein jetzt austauschen und mit der Mikrosekunden Precision ersetzen. Man kann dann alte Daten entweder direkt mit dem LBS erneut migrieren (falls alle Daten noch in EDOMI verfügbar sind) oder man kann die Daten von einem Influx Bucket in einen neuen migrieren und dabei auf Mikrosekunden Precision umstellen.

Vorgehen ist wie folgt:

1. InfluxDB updaten, falls notwendig. Es sollte mindestens Version 2.4.x sein, damit eine aktuelle Version von Flux (Skriptsprache) vorhanden ist
2. Neuen Bucket in Influx anlegen und Access Token generieren (Target-Bucket)
3. Edomi anhalten
4. LBS updaten und auf neuen Bucket konfigurieren
5. EDOMI aktivieren
6. Ab jetzt werden Datenarchiveinträge mit Mikrosekunden Precision nach Influx kopiert
7. Falls noch alle Daten in EDOMI vorhanden sind, dann können über E10 ('all') des LBS die Daten in den neue Bucket kopiert werden und man ist fertig. Ansonsten kann die Migration mit Schritt 8 und 9 vorgenommen werden.
8. Migrationsskript (s.u.) konfigurieren (URL, ORG, Source-Bucket, Target-Bucket, Token mit Leserechte auf Source-Bucket und Schreibrechte auf Target-Bucket)
9. Migrationsskript auf dem EDOMI Server starten: Es werden nun alle alten Einträge (Source-Bucket) in den neuen Bucket (Target-Bucket) kopiert und dabei wir der Mikrosekundenanteil in den Timestamp eingerechnet. Bei sehr großen Datenarchiven sollte man die Speicherauslastung des Influx Servers im Auge behalten. Im Zweifel benötigt der Influx Server für diese Aktion mehr Ressourcen oder man hält das Skript mit <Strg>+z an, bis sich die Auslastung normalisiert hat und lässt es mit dem Befehl 'fg' dann weiterlaufen.

Hier das Skript dazu:

<?php

// ##### Change according to your needs #####

$url = 'http://<YOUR-INFLUX-URL>:8086>';
$org = '<YOUR-ORG>';
$source_bucket = '<YOUR-OLD-BUCKET-WITH-PRECISION_S>';
$target_bucket = '<YOUR-NEW-BUCKET-WITH-PRECISION_US>';
$token = '<YOUR-ACCESS-TOKEN-FOR_BOTH-BUCKETS>';

// ##### Do not change below #####

require_once "/usr/local/edomi/www/admin/include/php/influx-client/vendor/autoload.php";
set_time_limit(0);

use InfluxDB2\Client;
use InfluxDB2\Model\DeletePredicateRequest;
use InfluxDB2\Point;
use InfluxDB2\Date;
use InfluxDB2\Service\DeleteService;
use InfluxDB2\Schema;

$started=true;
if ($argc>1) {
$started = false;
$start_measurement = $argv[1];
}

$client = new Client([
"url" => $url,
"token" => $token,
"org" => $org,
"precision" => InfluxDB2\Model\WritePrecision::US,
"timeout" => 0
]);

$queryApi = $client->createQueryApi();


$result = $queryApi->query(
'import "array"
import "runtime"
array.from(rows: [{version: runtime.version()}])'
);
echo json_encode($result, JSON_PRETTY_PRINT);

$result = $queryApi->query('
import "influxdata/influxdb/schema"
schema.measurements(bucket: "'.$source_bucket.'")
');

$result = json_decode(json_encode($result),true);

echo "STARTING MIGRATION".PHP_EOL.PHP_EOL;

foreach ($result[0]['records'] as $record) {
$measurement = $record['values']['_value'];
if (!$started && $measurement != $start_measurement) continue;
$started = true;
echo "MIGRATING measurement $measurement" . PHP_EOL;

$result = $queryApi->query(
'import "date"
from(bucket: "' . $source_bucket . '")
|> range(start: -365d)
|> filter(fn: (r) => r["_measurement"] == "' . $measurement . '")
|> set(key: "_measurement", value: "' . $measurement . '")
|> map(fn: (r) => ({ r with _time: date.add(d: duration(v: (r.us +"us")), to: r._time)}))
|> drop(columns: ["us"])
|> to(bucket: "' . $target_bucket . '", tagColumns: ["id"])'
);

}

$client->close();

echo PHP_EOL.'MIGRATION COMPLETED'.PHP_EOL.PHP_EOL;

?>


​

[dhb2002]

Hab heute mal ein wenig getestet und das funktioniert ganz gut.
dhb2002 Ist mein Verständnis korrekt, dass man die alten Daten eigentlich gar nicht migrieren muss? Nach Einspielen der neuen LBS Version wird doch einfach mit Mikrosekunden Timestamp und ohne Tag "us" ins gleiche Measurement geschrieben, richtig?
Gibt es da ein Problem, wenn Einträge mit unterschiedlicher Timestamp Precision oder unterschiedlicher Anzahl von Tags in einem Measurement sind?

Beim Schreiben gibt es keine Probleme. Beim Löschen aber schon. Sobald auf den Baustein mit echter Mikrosekundenzeit umgestellt wird, werden die alten Einträge mit Sekundenzeit und Mikrosekunden Tag nicht gelöscht. Das könnte man nun zwar hinbiegen, aber schön ist das sicher nicht.

Bei der Verwendung der Mikrosekunden Timestamps braucht es ja auch bei den Queries die Group Statements nicht mehr. Damit sind die wirklich viel schneller. Jeder der Umsteigt sollte da auf jeden Fall die Queries ändern. Von daher ist es vielleicht am sinnvollsten, einfach einen neuen Baustein zum machen? Dein Baustein ist ansonsten ja sehr stabil. Ich persönlich würde den Zeitzonen Fix in den originalen Baustein einpflegen und parallel den neuen mit Mikrosekundenzeit mit neuer Nummer veröffentlichen. Da kann dann jeder entscheiden wie er weitermacht.