InfluxDB – Alte Daten automatisch löschen

InfluxDB – YouTube Video

InfluxDB – Alte Daten automatisch löschen – Vorbereitungen

Ich gehe davon aus, dass du dein InfluxDB in einem Docker Container laufen lässt. Sollte dies nicht der Fall sein, kannst du dennoch weiterlesen. Du musst dann lediglich die Docker-Befehle weglassen und direkt die influxDB Kommandos nutzen.

Weiterhin benötigst du eine SSH-Verbindung in deine InfluxDB. Entweder über Portainer – sofern du von dort die Console starten kannst, oder direkt über deinen Host mit zum Beispiel MobaXterm oder Putty.

Für die InfluxDB 2.x benötigst du auch deinen Admin-Token aus der InfluxDB Konfiguration. Du kannst diesen NICHT mehr in der Web-GUI sehen. Höchstens einen weiteren Erstellen. Solltest du ihn also vergessen haben, gibt es zwei Möglichkeiten:

• einen ganz Neuen über die InfluxDB Web-GUI erstellen
• aus einem Skript auslesen, sofern du so etwas bereits nutzt

Token für InfluxDB vergessen – Auslesen aus Telegraf

Sofern du bereits meine anderen Tutorials verfolgt hast, wirst du sicherlich auch Telegraf nutzen, um die überwachten Daten an deine InfluxDB zu senden.

In diesem Fall wirst du deinen Token dort hinterlegt haben (oder in eine .env Datei?!).
Ich gehe von einer direkten Konfiguration in der telegraf.conf Datei aus.
Mit der Hilfe von folgendem Code kannst du dir deinen Token von dort auslesen. Dazu musst du dich mit deinem Host (wo Telegraf läuft) per SSH verbinden und Folgendes eingeben:

grep token /etc/telegraf/telegraf.conf

Jetzt erhältst du eine Rückmeldung, wie zum Beispiel:

token = "hJUGFkkokKJDHU_43JJDHJOJE982m-PxHZ29dkotrt=="

Diesen jetzt notieren, speichern, PostIt erstellen, unter die Tastatur kleben, an die Pinnwand heften, in den Arm tätowieren (mhh… wäre ne Idee….) 😛

Na auf jeden Fall irgendwie speichern, da wir diesen gleich benötigen werden.
Ok, ein Tattoo wäre demnach doch nicht so perfekt…copy & paste funktioniert dabei so schlecht…

Mein Raspberry System

Da ich schon öfters gefragt wurde, was ich für meine Labor oder Produktions Umgebung so benutze, hier ein kurzer Überblick. Die SSD sowie das Gehäuse und das Adapter-Kabel wurden bereits mit mehreren Raspberry´s erfolgreich getestet, so dass ich diese Kombination bedenkenlos empfehlen kann:

Werbung

Vorschau	Produkt	Preis
	Raspberry Pi 4 Modelo B 4GB	64,93 EUR	Bei Amazon kaufen
	Raspberry Pi Raspberry Fuente de Alimentación USB-C…	9,99 EUR 9,31 EUR	Bei Amazon kaufen
	Miuzei Gehäuse für Raspberry Pi 4 mit Lüfter, 5.1V…	17,99 EUR	Bei Amazon kaufen
	SD kartenleser 5 in 1 USB 3.0, Aluminiumlegierung mit…		Bei Amazon kaufen
	Samsung MZ-76E1T0B/EU 860 EVO 1 TB SATA 2,5″ Interne…	136,37 EUR 127,00 EUR	Bei Amazon kaufen
	UGREEN Festplattengehäuse 2,5 Zoll USB C 3.2 Gen 2 auf…	19,99 EUR 13,99 EUR	Bei Amazon kaufen
	JSAUX Adapter		Bei Amazon kaufen

Letzte Aktualisierung am 16.05.2025 (Preise können abweichen) / Infos zu Affiliate Links / Bilder von der Amazon Product Advertising API

Affiliate – Links

DarkWolfCave.de ist Teilnehmer des Amazon-Partnerprogramm, das zur Bereitstellung eines Mediums für Webseiten konzipiert wurde, mittels dessen durch die Platzierung von Partner-Links zu Amazon.de Entgelte verdient werden können.

Weitere Infos zu Affiliate-Links

Alte Daten automatisch löschen – Was ist Retention

Stell dir vor, dass die InfluxDB wie ein digitales Tagebuch ist, in dem du verschiedene Messungen und Daten speichern kannst, zum Beispiel Temperatur, Feuchtigkeit und andere Messwerte.

Die „Retention Policy“ (oder „Retention“, auf Deutsch Aufbewahrungsrichtlinie) ist im Prinzip eine Regel. Mit dieser wird bestimmt, wie lange die Einträge in deiner influxDB aufbewahrt werden sollen, bevor sie dann gelöscht werden.

Angenommen, du möchtest deine Messungen für 30 Tage behalten, dann legst du eine Retention Policy von 30 Tagen fest. Nach Ablauf dieser 30 Tage werden die ältesten Einträge in deiner Datenbank automatisch gelöscht, um Platz für die neuesten Messungen zu schaffen.

Retention Policies sind nützlich, um sicherzustellen, dass deine InfluxDB nicht mit unnötigen Daten überladen wird und du immer genügend Platz für aktuelle Informationen hast. Du kannst verschiedene Retention Policies für unterschiedliche Arten von Messungen festlegen, je nachdem, wie lange du diese Daten aufbewahren möchtest.

Seit InfluxDB 2.x gibt es hier auch Änderungen. Es gibt keine eigentlichen Policies mehr, es wird eher alles über die Buckets eingerichtet. Dennoch ist eine Mapping-Table vorhanden, in der Richtlinien wie in V1.8 hinterlegt sind. Default werden deine neu erstellten Datenbanken direkt eine „infinite“ (auf deutsch: unendlich) Policy erhalten (genau genommen heißt die Policy dahinter autogen). Also deine Daten werden ohne Limit dauerhaft gespeichert.
Du kannst dir sicher vorstellen, dass je nach „Sammelwut“ deine SD-Karte dann schnell an ihr Limit stoßen wird.

Retention Time bei InfluxDB 2.x schnell umstellen

Solltest du eine InfluxDB Version 2.x betreiben, kannst du die Retention Zeit – also die Zeit, nachdem deine alten Daten gelöscht werden – sehr einfach über die Web-GUI ändern.

Logge dich dazu entsprechend ein und wechsle zu „Load Data – Buckets“:

Rechts siehst du jetzt alle eingerichteten Buckets und deren Retention Zeiten.
Über „Settings“ kannst du diese jetzt direkt ändern:

Einfach den entsprechenden Wert auswählen und save changes klicken, um deine alten Daten automatisch zu löschen.
In dem gezeigten Beispiel werden die Daten nur noch 30 Tage gespeichert.

Retention Time InfluxDB 2.x über die CLI umstellen

Ja es gibt auch die etwas umständlichere Methode. Aber immer gut zu wissen, wie man etwas über die CLI abfragen / ändern kann.
Nebenbei konnte ich bei mir über die WebGUI, nachdem ich eine andere Zeit eingestellt hatte, dann auch nicht mehr auf „never“ zurück umstellen. Dies gelang mir nur auf folgendem Weg.

Fangen wir an uns mit dem Host zu verbinden, auf dem der InfluxDB Container läuft.
Sobald diese Verbindung steht, schauen wir uns erstmal unsere laufenden Docker-Container an:

docker ps --format "{{.ID}} : {{.Names}} : {{.Image}} : {{.State}}"

Als Ausgabe erhältst du deine Container. Suche nach deiner InfluxDB und nimm die ID am Anfang für folgenden Befehl. Hier lassen wir uns die aktuellen Buckets und Retention Policy dazu anzeigen.
Solltest du deinen ORG Namen nicht mehr wissen, kicke auf den zweiten TAB in dem Code-Highlighting Block: Du musst natürlich immer deine ContainerID und TOKEN nutzen.

docker exec -it DEINE-CONTAINER-ID influx bucket list -o DEINE-ORG -t DEIN-INFLUXDB-TOKEN

docker exec -it DEINE-CONTAINER-ID influx org list -t DEIN-INFLUXDB-TOKEN

Ein Beispiel wie eine mögliche Ausgabe aussehen könnte. Hier sieht man die ID, den Namen, die Retention-Zeit, die Shard group duration, OrganizationID und das Schema.
Für uns aktuell interessant ist lediglich der Name und die Retention-Zeit:

Kopiere dir die ID des Buckets, bei dem du die Retention Zeit ändern möchtest. In meinem Fall wäre es die a85194f7a89abe88.
Mit dem nächsten Befehl kannst du jetzt für diese ID entsprechend die Zeit anpassen:
–id DEINE-ID und –retention die Zeit ( z.b 14d / 30d / 0s für unendlich )

docker exec -it DEINE-CONTAINER-ID influx bucket update -t DEIN-INFLUXDB-TOKEN \
--id a85194f7a89abe88 --retention 14d 

Du erhältst nach Ausführen des Befehls direkt eine Rückmeldung mit der neuen Retention Zeit.
Das bedeutet, dass deine alten Daten automatisch außerhalb dieses Zeitraumes gelöscht werden.
In diesem Beispiel sind es 336h, was 14 Tagen entspricht:

Retention Policy InfluxDB 1.8 über die CLI ändern

Bei der älteren Version 1.8 verhält es sich ein wenig anders. Hier gibt es keine Buckets und wir müssen etwas anders vorgehen.
Wir starten auch hier mit einem Befehl, der uns die ID der laufenden Docker Container zurückgibt.
Suche und kopiere dir die ID von deinem influxdb(v1.8) Container:

docker ps --format "{{.ID}} : {{.Names}} : {{.Image}} : {{.State}}"

Jetzt starten wir die influxdb shell in dem Docker Container:

docker exec -it DEINE-CONTAINER-ID influx

Prüfen wir welche Datenbanken es gibt und verbinden uns dann mit derjenigen, bei der wir die Retention Policy ändern wollen:

show databases
use NAME_DER_DATENBANK

Bevor wir jetzt wild drauflos ändern, schauen wir uns die aktuell hinterlegte Policy an:

show retention policies

In diesem Beispiel sehen wir, dass die Policy „autogen“ mit einer Zeit von „0s“ (also unendlich) genutzt wird und für die Datenbank als default gilt.

Erstellen wir uns einfach eine neue Policy bei der die Daten maximal 30 Tage gespeichert werden sollen. Danach prüfen wir nochmal unsere retention policies:

CREATE RETENTION POLICY "30_days" ON "NAME_DEINER_DATENBANK" DURATION 30d REPLICATION 1
show retention policies

In meinem Beispiel siehst du jetzt zwei Retention Policies. Aber nur die mit default true wird auch für die aktuelle Datenbank verwendet.
Damit unsere neu erstellte Policy jetzt auch angewendet wird, setzen wir diese als default und schauen danach erneut auf die retention policies:

ALTER RETENTION POLICY "30_days" ON "NAME_DEINER_DATENBANK" DEFAULT
show retention policies

Wie du siehst, steht bei default jetzt der Wert true hinter unserer neu angelegten Policy.
Das war es auch schon. Du kannst weitere Retention Policies mit verschiedenen Zeiten anlegen und für unterschiedliche Datenbanken verwenden. So kannst du selbst entscheiden, wann deine alten Daten automatisch gelöscht werden sollen.

Mit dem ALTER RETENTION POLICY Befehl kannst du dann zwischen den einzelnen Policies schnell umschalten, indem du die gewünschte auf „default“ setzt.