NEWS

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

@marc-berg said in InfluxDB 2.0 und wieder Measurement löschen nicht möglich:

@accuface sagte in InfluxDB 2.0 und wieder Measurement löschen nicht möglich:

Nun die eigentlich Frage, Warum und vor allem welche Alias ID (in deinem Foto markiert) soll/muss ich da angeben?

Du musst da gar keine ID angeben. Wenn die leer bleibt, heißt das Measurement genauso wie der jeweilige Datenpunkt. Hier wird nur der Measurement-Name überschreiben, falls gesetzt.

Bei mir wurde ein Neuer measurement zum bestehenden angelegt. Sieht man im letzten Code-Tag

Beim Rest des Textes kann ich dir im Moment leider nicht folgen.

Und bitte noch für die Nachwelt: Mit welcher Shell gab es jetzt die Umlaut-Probleme und mit welcher hat es dann funktioniert?

Nicht funktioniert hat es mit Windoof Powershell
Funktioniert hat es mit Putty

@hady

Error: authorization failed

Deine Zugangsdaten sind falsch.

@master_jo1

Wenn du loglevel auf debug gesetzt hast ist das klar, das die Logs so groß werden.
Lass von syslog und daemon.log die Finger. Reinschauen, aber nix löschen.