NEWS

Mir ist das Funktionsprinzip von influx und der Sinn der doppelten Werte nun auch klar. Wenn ich einen Sensor x mal abfrage, der Echzeitdaten liefert, und erst nach der 50. Abfrage kommt ein neuer Wert, dann möchte ich quasi Abfrage 49 auch nochmal mit dem alten Wert abspeichern, damit der Übergang möglichst zeitlich korrekt sichtbar wird.

Da mein Plenticore aber nur alle +-5 Minuten seine ausgelieferten Werte aktualisiert, ist diese Herangehensweise bei diesen Werten sinnlos, da der entstehende, gedoppelte "letzte alte" Wert schon von vornherein nichts mit der Realität zum Abfragezeitpunkt zu tun hatte.

Von daher alles gut. Bleibt einzig das Rätsel, ob ich den Plenticore irgendwie überreden kann, seine ausgelieferten Werte in kleineren Intervallen zu aktualisieren. In der Web-UI sehe ich dazu jedenfalls keine Möglichkeit. Wahrscheinlich loggt er einfach fix im 5-Minuten-Takt. Schade, aber nicht weiter schlimm.

@int17 sagte in influxdb2 Retention Time:

Wo hast du deinen Hinweis gelesen?

Hier

@agrippinenser sagte in InfluxDB 2.0 Measurement löschen:

Das muss beim Update auf 2.7.10 automatisch passiert sein

Genau, das passiert bei Upgrades "von selbst".

@marc-berg said in Influx2 DB - retentiontime ändert sich "von alleine":

@cocomp sagte in Influx2 DB - retentiontime ändert sich "von alleine":

Das ist eine 2.2.1, die auf meiner Synolgy in einem Docker arbeitet.

Die Version ist fast drei Jahre alt. Ein Update wäre sicher eine Überlegung Wert.

Den Gedanken hatte ich auch schon....aber bisher galt "never touch a running system" 😉
Denke aber nicht, dass da der Fehler herkommt, weil es eben nur das eine Bucket betrifft. Ein Versuch wäre es wert...

@thomas-braun hier mal ein Beispiel (aus der Influx- Hilfe-Datei):

Change your password Use influx command line interface (CLI) to update your password. User passwords cannot be updated in the InfluxDB UI. Change your password using the influx CLI Use the influx user password command to update a password for a user. Provide the following: An operator token using your influx CLI connection configuration, INFLUX_TOKEN environment variable, or the --token, -t flag. The username (with the --name, -n flag) or the user ID (with the --id, -i flag). View usernames and IDs in the output of influx user list. Optional: the --password, -p flag and the new password. If you don’t provide a password flag, enter the new password when prompted. Update a password influx user password \ --name USERNAME \ --password PASSWORD Replace the following: USERNAME: The username to change the password for PASSWORD: The new password Was this page helpful?

Das Passwort konnte ich aber mit diesem Befehl ändern (user = username):
influx user password -n admin --password 12345678 -t <der notierte Token>

Mit der Influx Hilfe kam ich niemals auf diese Befehlseingabe. Man braucht schon sehr viel Phantasie...

@marc-berg sagte in influxdb 1.x restore auf neues System Schritt-für-Schritt:

("Alte Influx-DB ...löschen" anklicken)

Das gibt es garnicht in der Influx-Instanz (v4.0.2) ...oder meintest Du "Alle Daten in Datenbank löschen"?

c53effe3-9193-4559-a270-293284c52bf3-grafik.png

Ist auch "ausgegraut", also nicht anwählbar....weil die Instanz noch im Stop ist ?!

@hant0r sagte in temporärer timeout bei influxdb:

Das die Hardware an der Grenze arbeitet kann natülich zwischenzeitlich mal vorkommen, aber wenn ich schaue, liegt die CPU meist bei 20% und der RAM bei 55%, sollte also noch Luft sein.

Hier ist weniger die CPU- als die Festplattenperformance entscheidend. Du könntest versuchen, den Parameter

storage-wal-fsync-delay = "5s"

zu setzen. Damit wird nicht mehr jede Schreiboperation sofort zur Festplatte weitergeleitet. Nachteil: es können bei Stromausfall ein paar Daten (max. 5 Sekunden in diesem Beispiel) verloren gehen.

Aber wie gesagt, das ist rumdoktern an Symptomen. Ursache wird aller Wahrscheinlichkeit das schlechte Verhältnis "Menge der Daten" zu "Performance des Gesamtsystems" sein. Vielleicht setzen ja auch andere Prozesse außerhalb der InfluxDB deine Festplatte in dieser Zeit der Timeouts Schachmatt.

EDIT: sinnvolle Zeit auf 5 Sekunden gesetzt

@marc-berg Habe deine Abfrage aus dem Forum genommen. Jetzt sehe ich die ganzen Scarper-Daten. Das löschen bringt jetzt auch was.
Danke!

@franz-delcuve sagte in Gültigkeitsdauer von All Access API Tokens:

Natürlich hab ich die Logs nicht gesichert

das macht iob automatisch! für 7 Tag3

@martinschm ich würde es dabei belassen und langfristig eine Migraiton auf eine andere Datenbank planen (zb Victoria Metrics). Nach aktuellen Stand wird Influx "Core" (open source version) nur noch 72 Stunden speichern => für Smarthome eher unbrauchbar.

@dukle sagte in Installation Influx-CLI auf einer Syno in Dockerumgebung:

Weist Du, wofür das benötigt wird

Das ist lediglich ein Verweis auf die URLs, von denen du die Installationsrotine manuell herunterladen und installieren kannst. Im Ergebnis würde exakt das Gleiche bei rauskommen wie hier mit der Umgebungsvariable. Für einen Container aber unerheblich bzw. unpraktisch, da du das bei jedem Neuerstellen des Containers machen müsstest.

@marc-berg

Den Browser Cache hatte ich schon gelöscht.
Irgendwo hatte ich gelesen, das an den Chrome Sicherheitseinstellungen etwas geändert werden muss.
Aber was weiß der Fuchs 😧 .
Daher war das öffnen über einen Zweitbrowser am einfachsten. In Firefox funktioniert es problemlos.

@marc-berg Habe jetzt alles gleich gesetzt und den Token nach einem erneuten Restore in die Instanzen eingepflegt - läuft - war eine schwere Geburt, die ohne deine Hilfe und Anregungen mir nicht gelungen wären. Vielen Dank, ich werde mich jetzt an die Schritte 4.-10. machen.
Dann geht es weiter mit dem Restore von Grafana, ich hoffe, das gelingt mir dann schneller.

Zu dem "Hidden Feature"

das gibt es natürlich nicht, ich meinte den Token aus den ioB-Instanzen!

@ro75 Versteh die Frage leider nicht.

@marc-berg

Der Objekt-Typ stand auf "String". Habe ihn auf "Number" umgestellt und siehe da, das Diagramm ist vorhanden.

Vielen Dank.

@simatec

Also das hatte ich vorhin hier eigentlich auch gepostet.

Wenn ich wie in der Anleitung den Befehl:

find / -name influxd.bolt

abschicke kommt eine riesen Liste heraus, die ich hier nicht posten kann, weil sie zu lang ist.

ich habe mal nach influx in der Ausgabe gesucht und es kommen nur zwei Treffer:

find: ‘/var/log/influxdb’: Permission denied find: ‘/var/cache/private’: Permission denied find: ‘/var/cache/apt/archives/partial’: Permission denied find: ‘/var/cache/ldconfig’: Permission denied find: ‘/var/lib/NetworkManager’: Permission denied find: ‘/var/lib/private’: Permission denied find: ‘/var/lib/grafana/csv’: Permission denied find: ‘/var/lib/grafana/plugins’: Permission denied find: ‘/var/lib/grafana/pdf’: Permission denied find: ‘/var/lib/grafana/grafana-apiserver’: Permission denied find: ‘/var/lib/grafana/png’: Permission denied find: ‘/var/lib/influxdb’: Permission denied find: ‘/var/lib/apt/lists/partial’: Permission denied find: ‘/var/lib/polkit-1’: Permission denied find: ‘/var/lib/bluetooth’: Permission denied find: ‘/var/spool/cron/crontabs’: Permission denied

@marc-berg sagte in Fehlermeldung Influx DB User Passwort ändern:

Und das admin-Passwort für Grafana hast du auch nicht mehr?

Das ist eine komplett Neuinstallation auf einem anderen System. Ich benutze dafür meine Notizen von vorher. Den User admin habe ich jetzt gar nicht angelegt, nur grafana mit admin Rechten.
Ich versuche admin anzulegen und mit dem mich anzumelden.

@marc-berg Das habe ich getan.

Ergebnis: /etc/influxdb/influxdb.conf

Also liegt sie richtig und ich habe auch in der richtigen Datei geschaut - zumindest würde ich das so interpretieren 😉

@accuface sagte in 100er von Warnmeldungen, was ist jetzt wieder?:

gibts glaub auch erst seid dem 5er

Na ja, bis zum 4er hab ich schon geschafft 😂

@legro sagte in InfluxDB 2.x = gelöst 😉:

InfluxQL

Wenn ich mir das so anschaue, kamen die dann zum Schluß das SQL dann doch nicht so schlecht ist bzw die meisten verstehen, wenn sie bereits mit Datenbanken gearbeitet haben?