Damit Sie das Versionsdurcheinander von v1 bis v3 zu Beginn unseres Artikels nicht allzu sehr verwirrt, starten wir mit einem kurzen Rückblick. Dieser verdeutlicht auch, warum gerade zum Launch von v3 ein Workshop zum Update von v1 auf v2 Sinn ergibt. InfluxDB hat die Version 1 der quelloffenen und in Go geschriebenen Time-Series-Datenbank 2013 auf den Markt gebracht [1]. Diese etablierte sich zügig als Datenspeicher für Metriken und kommt dabei sehr häufig zusammen mit der Datenvisualisierung von Grafana zum Einsatz. Viele Administratoren sammeln Metriken wie CPU-Belastungen, Server- und Raumtemperaturen oder Netzwerkdurchsätze in InfluxDB und visualisieren diese Daten in Grafana-Dashboards.

InfluxDB v1 verwendet eine an SQL angelehnte Abfragesprache namens InfluxQL und organisiert die Datenbestände tabellarisch. Grafana offeriert einen simplen grafischen Query-Editor für InfluxDB v1, was Anwendern sehr entgegenkommt. Die Datenbank arbeitet im Push-Verfahren, ist daher also auf externe Tools wie Telegraf oder collectd angewiesen, die Metriken zu ihr senden. Allerdings liefert v1 nur die TSDB (Time Series Data Base) und sonst nichts. Der Hersteller InfluxData erweiterte in den folgenden Jahren seine Palette an Tools. Telegraf sammelt Metriken und sendet sie an InfluxDB. Kapacitor kann Livedaten auswerten und daraus Alerts generieren, während Chronograf als Visualisierungsplattform ähnlich wie Grafana arbeitet.

Ende 2021 kam dann das große Versionsupdate auf InfluxDB 2 mit einer Fülle von Änderungen. InfluxData integrierte die Funktionalität von Kapacitor und Chronograf direkt in InfluxDB. Der Hersteller fügte eine Reihe von Sicherheitsfunktionen ein, da InfluxDB v1 ohne Änderungen am Default-Setup einfach ohne Authentisierung oder Verschlüsselung läuft. Ferner führt die Version 2 eine schnellere und effizientere Methode der Datenspeicherung ein und organisiert die Daten in Buckets. Die Datenbank sollte dabei auch besser in Scale-Out-Umgebungen wie Kubernetes laufen, wie es auch die direkte Konkurrenz Prometheus kann. Zu guter Letzt – und dabei nicht zur Freude aller Anwender – führt Influx mit "Flux" eine neue Abfragesprache ein, die nicht mehr ganz so viel Gemeinsamkeiten mit InfluxQL oder SQL aufweist.

Parallel zu v2 startete InfluxData ein weiteres Open-Source-Projekt namens "Influx IOx" [2]. Die Abkürzung "IOx" steht dabei für "Iron Oxide", also Rost, in Anlehnung an die neue Programmiersprache "Rust", die für IOx zum Einsatz kommt. IOx liefert ein gänzlich überarbeitetes TSDB-Backend für InfluxDB, das dessen Betrieb auf Scale-Out-Plattformen wie Kubernetes noch einmal wesentlich verbessern soll. Dazu gehören dann auch Funktionen wie In-Memory-Tabellen, ein Object-Storage-Backend, synchrone und asynchrone Datenspiegelung und Echtzeit-Datenanalyse. Am Frontend hingegen soll sich bei IOx wenig gegenüber v2 ändern. Die Abfragesprachen Flux und InfluxQL bleiben erhalten. Hier wird InfluxDB IOx sogar noch eine weitere Abfragemethode hinzufügen: Standard SQL.

Was InfluxData aktuell vorerst nur als kommerziellen Service "InfluxDB v3" offeriert, ist also nichts anderes als eine "as-a-service"-Variante von IOx mit Chronograf und Kapacitor und einer v2-kompatiblen API. Wer sich mit dem neuen Backend auseinandersetzen möchte, kann IOx aus den Sourcen kompilieren oder als binary/Container-Image laden. Dank Rust (statisch gelinkt) ist "iox" tatsächlich nur ein einzelnes Binary ohne Abhängigkeiten zu irgendwelchen Bibliotheken. Allerdings enthält das iox-Binary dann tatsächlich nur das TSDB-Backend, wie das bei v1 der Fall war. Die komplette Integration mit Chronograf und Kapacitor gibt es aktuell nur in der kostenpflichtigen v3-Variante.

Wer mit der Open-Source-Version von InfluxDB arbeiten möchte, bekommt mit InfluxDB v2 (zum Zeitpunkt des Artikels: 2.7.1) den vollen Funktionsumfang. Dennoch betreibt eine große Zahl von Admins in ihren Umgebungen nach wie vor InfluxDB v1 und sperrt sich gegen ein Update. Das führt unausweichlich zu Problemen:

- Version 1 wird nicht mehr gepflegt.

- Große Datenbanken verlangsamen InfluxDB-v1-Installationen zunehmend.

- InfluxDB v1 verfügt im standardmäßigen Setup über keinen oder nur einen unzureichenden Zugangsschutz.

Warum aber scheuen die Anwender dann aber das Update? Die Antwort ist vergleichsweise simpel: Viele Admins arbeiten lieber mit Grafana als Frontend anstatt mit Chronograf. Grafana wiederum liefert nur für InfluxQL einen grafischen Query-Editor – der seit langem versprochene grafische Flux-Editor fehlt nach wie vor. Die Anwender fürchten daher, sie müssen bei einem Update alle bestehenden InfluxQL-Queries in Flux neu schreiben und bleiben daher lieber gleich bei v1. Allerdings gibt es vergleichsweise simple Methoden, um einerseits die alten InfluxQL-Queries auch mit v2 zu nutzen und diese andererseits in Flux zu übersetzen.

Wer von v1 auf v2 updaten möchte, macht das am besten mit parallelen Installationen. Ein klassisches "In-Place"-Update ist viel zu aufwendig und riskant. Einen eigenen Host oder eine eigene VM benötigen Sie nicht, für InfluxDB v2 genügt ein Container. Wie Sie ein InfluxDB-Setup auf Podman laufen lassen, haben wir zwar in der der Ausgabe 1/2023 im Artikel " Hilfreiche Messdaten" ab Seite 42 schon vorgestellt. Dabei blieb jedoch eine wichtige Kleinigkeit außen vor: Wenn Sie einen InfluxDB-Container mit v2 anstatt v1 ausrollen, müssen Sie den persistenten Speicher des Containers in das Verzeichnis "/var/lib/influxdb2" mounten und nicht in "/var/lib/influxdb" wie bei v1.

Dasselbe gilt für das Konfigurationsverzeichnis "/etc/influxdb2", wobei Sie auf dieses mit v2 komplett verzichten können. Wenn sie InfluxDB via GUI konfigurieren, legt das Programm seine "running config" im Datenverzeichnis ab. Und natürlich laden Sie entweder das Image "influxdb:latest" oder "influxdb:2.7" und nicht mehr 2.4. Im Kasten "InfluxDB 2 im Container" finden Sie den Podman-Aufruf.

InfluxDB v2 arbeitet auch sehr zuverlässig auf Kubernetes. Jedoch pflegt Influx weder den InfluxDB-Operator noch die Helm-Charts. Beide Kubernetes-Installer existieren, sind jedoch veraltet. Ein Beispiel für ein simples Kubernetes-Stateful-Set mit InfluxDB v2 entnehmen Sie dem Kasten "InfluxDB auf Kubernetes".

Sie könnten Ihren InfluxDB-v2-Container beim ersten Mal mit Umgebungsvariablen für den Default-Benutzernamen und -Passwort starten, aber das geht auch ohne ganz gut. Direkt nach dem Start rufen Sie die URL der InfluxDB-Instanz auf, etwa "http://flux2.<FQDN>:8086/" (oder via Kubernetes-Route), legen dort das Admin-Passwort sowie die Default-Organisation fest und erstellen den ersten Bucket. Sehr viel komfortabler als bei v1 verwalten Sie dann auch die Retention-Policies der Buckets. Dieses Verfallsdatum der Metrikdaten lässt sich individuell für jeden Bucket einstellen und auch im laufenden Betrieb ändern.

InfluxDB generiert automatisch ein Admin-Token, das Sie umgehend an einem geschützten Ort sichern sollten. Alle Kommunikation mit der neuen InfluxDB-Instanz benötigt künftig eine Token-Authentisierung. Für jeden eigenen Dienst (Telegraf, Grafana) können und sollen Sie dann auch eigene Tokens anlegen. Ein Rechtesystem schränkt die Zugriffsmöglichkeiten der Applikationen weiter ein. Ein Grafana-Instanz beispielsweise braucht lediglich Lese-, aber keine Schreibrechte.

Die Web-UI von InfluxDB v2 offeriert zudem weitere Konfigurationsoptionen. Im Tab "Sources" finden Sie eine Seite namens "Telegraf". Hier können Sie nicht nur verschiedene Konfigurationsdateien für Telegraf erstellen und verwalten. InfluxDB v2 kann diese auch an ihre Telegraf-Clients übermitteln, sodass diese Installationen gar keine lokale Konfigurationsdatei mehr benötigen. Stattdessen starten Sie auf den Systemen, deren Metriken Sie einsammeln möchten, den Telegraf-Dienst mit einem Token und der API-URL des v2-Servers, der die Konfigurationsdatei parat hält. Diese Option ist sehr praktisch, da Sie künftig die Telegraf-Konfigurationen aller angebundenen Systeme zentral verwalten können. Allerdings hat die Funktion einen kleinen Haken: Ändern Sie die zentrale Telegraf-Konfiguration, startet der angebundene Dienst nicht automatisch, um die Änderungen anzuwenden. Hier müssen Sie wahlweise

- die Telegraf-Clients per cron-Job regelmäßig neu starten,

- den Telegraf-Dienst auf den Clients per Remote-Managemnent etwa via Ansible neu laden oder

- in der Telegraf-Konfiguration ein "exec"-Statement einfügen, das den Dienst via HUP-Signal regelmäßig neu lädt.

In der Web-UI finden Sie auch den Data-Explorer, mit dessen Hilfe Sie grafisch Flux-Queries erstellen und in Chronograf nutzen können. Dazu später mehr. Im Tab "Notebooks, Alerts und Tasks" erstellen Sie automatisierte Datenauswertung. Dies ist die integrierte Kapacitor-Funktionalität. Hier legen Sie dann beispielsweise auch Tasks an, die die Metriken in Ihren Buckets downsampeln. Ein wichtiges Konzept einer TSDB ist ja, Daten über die Zeit zu reduzieren. Hier können Sie beispielsweise bei Metriken, die älter als einen Monat sind, nur noch die stündlichen Mittelwerte behalten, anstatt der alle 30 Sekunden eingesammelten Daten.

Für unser Beispielszenario gehen wir davon aus, dass Sie bereits über eine Reihe von Systemen verfügen, die ihre Metriken via Telegraf zu einer bestehenden InfluxDB-v1-Datenbank senden. Auf der neuen v2-Instanz erzeugen Sie für die Telegraf-Daten zunächst einen Token mit Schreibrechten und einen passenden Bucket. Zudem erstellen Sie einen Read-Only-Token für Grafana.

Dann erweitern Sie die bestehende Telegraf-Konfiguration ihrer Hosts mit der neuen Output-Zeile. Zu der bestehenden v1-Output-Angabe, wie beispielsweise

kommt die v2-Datenbank als der zweite Output hinzu:

Nach einem Neustart des Telegraf-Agenten sendet dieser künftig die Metriken parallel an beide Datenbanken. Übrigens eignet sich an dieser Stelle ein simples Ansible-Playbook mit einem "ansible.builtin.lineinfile"-Task recht gut, um automatisiert auf mehreren Zielsystemen die bestehende "telegraf.conf" zu erweitern und den Dienst neu zu starten. Oder Sie stellen an dieser Stelle gleich die Telegraf-Konfiguration der Zielsysteme von der lokalen Datei auf die zentral in InfluxDB verwaltete Variante um.

Im nächsten Schritt richten Sie die Verbindung der neuen Datenbank in Grafana ein. Hier empfehlen sich zwei Verbindungen für die neue Datenbank: Die erste via InfluxQL, um die bestehenden Queries von v1 unverändert zu übernehmen. Die zweite Verbindung nutzt dann Flux, sodass Sie neue Dashboards mit der verbesserten Query-Language erstellen können.

Um Grafana via InfluxQL an einen v2-Server anzubinden, gibt es einen recht einfachen Trick: Legen Sie eine neue Verbindung an, wählen Sie InfluxQL als Query-Language aus und geben die URL des v2 Servers an. Die Auth-Optionen bleiben abgeschaltet und auch bei den DB-Details geben Sie weder Usernamen noch Password an. Stattdessen klicken Sie im Abschnitt "Custom HTTP-Headers" auf den Button "Add Header". In dem neu erscheinenden Feld "Header" tragen Sie das Wort "Authorization" ein. Als "Value" geben Sie "Token" gefolgt von einem Leerzeichen und dem zuvor erstellten Telegraf-Token ein. Im Feld "Database" tragen Sie den Bucketnamen ein. Klicken Sie auf "Save & test" und die InfluxQL-Verbindung zu Ihrer v2-Datenbank steht.

Da InfluxDB v2 "Buckets" und "Orgs" zur Adressierung der Datenbestände verwendet anstatt eines Datenbanknamens, wie ihn v1 verlangt, braucht es ein entsprechendes Mapping von DB-Name zu Bucket. Wenn Sie die Buckets neu erstellen, geschieht das in der Regel automatisch. Sollte es jedoch zu Zugriffsproblemen via InfluxQL kommen, müssen Sie gegebenenfalls die Mappings prüfen und neu erstellen. Das funktioniert am besten auf der Kommandozeile des Influxdb2-Servers mit dem Befehl influx v1 dbrp. Die CLI ihres InfluxDB-Containers erhalten Sie bei Podman via:

Oder bei Kubernetes via

Oder Sie installieren den passenden influx-CLI-Client auf Ihrer Arbeitsstation. Zudem erstellen Sie eine Datenquelle mit Flux und geben dort die zuvor festgelegten Daten wie Org, Bucket und Token ein.

Um nun die Daten Ihrer v2-Datenbank zu visualisieren, können Sie ganz einfach die bestehenden v1-Dashboards duplizieren und in den Paneelen die Datenquelle von v1 auf die via InfluxQL angebundene v2 umstellen, das war's. Dann fahren Sie einfach die Paneele für eine bestimmte Zeit parallel, bis Sie die historischen v1-Daten nicht mehr benötigen. In der Regel müssen Sie die gesammelten Metriken nicht unbegrenzt archivieren. Es dürfte Sie heute kaum noch interessieren, wie heiß der sechste CPU-Kern des siebten Servers im Juli 2022 war und wie schnell daher der CPU-Ventilator drehte.

Falls Sie dennoch Langzeitdaten in InfluxDB sammeln, können Sie diese natürlich von v1 nach v2 übertragen. Dazu begeben Sie sich auf die CLI Ihres InfluxDB-v1-Servers und exportieren Ihre Metriken in eine simple CSV-Datei:

Mit den optionalen Switches "--start" und "--end" geben Sie das Zeitfenster des Exports an. Die Sache hat nur einen Haken: Je nachdem, wie fleißig ihre Clients Informationen in die InfluxDB füttern, kann dieser Textexport recht groß ausfallen. In unserem Beispiel, wo fünf Server ausführliche Metriken von Hard- und Software liefern, belegt die Influx-v1-Datenbank 15 GByte auf der Festplatte. Der CSV-Export der Metriken erzeugt dann ein 450 GByte großes Textfile. Exportieren Sie daher lieber mehrere kleinere Dateien.

Die dritte Zeile Ihres Influx-Exports enthält, ähnlich wie in SQL-Dumps, die InfluxQL-Anweisung zum Erstellen der Datenbank:

Dann folgen die Metriken mit jeweils einem Wert und dem passenden Zeitstempel pro Zeile. Kommentieren oder entfernen Sie die "Create Database"-Zeile aus dem Dump. Dann können Sie die CSV-Datei in ein Verzeichnis Ihres v2-Servers verschieben. Sollten Sie InfluxDB im Container laufen lassen und beide Datenbankversionen auf demselben Host betreiben, erzeugen Sie einfach ein gemeinsam genutztes Verzeichnis "/export" und geben beiden Containern darauf Zugriff. Auf der Kommandozeile des v2-Server importieren Sie dann den Dump via:

Anders als bei einem SQL-Dump ist hier jedoch die Reihenfolge irrelevant, in der Sie die Dump-Dateien importieren. Alle Metriken bringen ihren Zeitstempel mit. Der Export sowie Import lässt sich natürlich mit einem passenden Skript automatisieren, das die Daten in kleinen Portionen extrahiert und beispielsweise via | grep -v "CREATE DATABASE" gleich das SQL-Statement aus dem Export entfernt.

Falls Sie sich von InfluxQL lösen und Ihre Queries auf Flux umstellen möchten, stehen Ihnen mehrere Optionen offen. Einfache Queries kann Ihnen tatsächlich die freie Variante des AI-Tools ChatGPT übersetzen. Eine simple Anfrage in Stil von "Convert the following InfluxQL Query to Flux: ...." reicht in den meisten Fällen aus, um eine funktionierende Flux-Query passend zur ursprünglichen InfluxQL-Query zu erhalten. Da Sie in der Regel keine Firmengeheimnisse in InfluxQL-Queries sichern, dürfte es auch kein Problem darstellen, dass OpenAI die Anfragen aufzeichnet. Von TwentyFiveSoftware gibt es zudem einen freien Open-Source-Konverter in Typescript [3]. Den können Sie auf Ihrer Arbeitsstation oder einem Server via Node-JS lokal ausführen. Alternativ nutzen Sie einfach den freien Webdienst von TwentyFiveSoftware auf [4].

Der nach wie vor beste Weg ist jedoch, Flux-Queries in einem grafischen Query-Builder zu bauen. Der fehlt zwar nach wie vor bei Grafana, aber das mit InfluxDB v2 installierte Chronograf hat einen. Bauen Sie sich einfach die gewünschten Queries in Chronograf. Wenn die Abfrage passt, klicken Sie auf "Script Editor". Von dort können Sie die Flux-Query via Copy und Paste von Chronograf zu Grafana kopieren. Möchten Sie sich etwas näher mit Flux befassen, vermittelt Ihnen der Kurzworkshop auf der InfluxData-Seite die nötigen Grundlagen [5].

Der Umstieg von InfluxDB v1 auf v2 fällt deutlich unproblematischer aus, als viele Admins befürchten. Die Übergangsphase mit beiden Versionen sorgt dafür, dass keine historischen Daten verlorengehen. Der Parallelbetrieb mit beiden Query-Languages auf der neuen Datenbank wiederum gibt dem Administrator die Möglichkeit, ohne Zeitdruck bestehende Paneele und Dashboards Stück für Stück von InfluxQL zu Flux umzubauen.