Machen InfluxDB und Grafana heute noch Sinn?

Hallo zusammen,

ich möchte gern meine Langzeit Verbrauchsdaten sichern und grafisch darstellen. Dafür war ja bisher InfluxDB und Grafana das Mittel der Wahl.

Ist das heute auch noch so?

Hintergrund meiner Frage: Die meisten Tutorials zu InfluxDB und Grafana sind bereits älter. Dennoch habe ich versucht danach zu arbeiten, bekomme die Datenbank jedoch nicht so zum laufen wie in den Videos beschrieben.
Z.B. startet der Kapacitor nicht.
Im Log file steht: Using configuration at: /etc/kapacitor/kapacitor.conf
Im etc Folder gibt es aber gar keine subfolder kapacitor.
Evtl. auch daher die Fehlermeldung:
lvl=error msg="error while sending usage report on startup" service=reporting err="Post \"https://usage.influxdata.com/api/v1/usage/kapacitor\": dial tcp 0.0.0.0:443: connect: connection refused"

In die configuration.yaml habe ich folgendes eingetragen:

influxdb:
  host: localhost
  port: 8086
  database: homeassistant
  username: homeassistant
  password: homeassistant
  ssl: false
  verify_ssl: false
  max_retries: 3
  default_measurement: state
  include:
    domains:
     - sensor

Der User ist dementsrpechend angelegt und hat Read Write Zugriff.

Sollte ich da nun noch weiter graben oder gibt es mitlerweile bessere Tools?

Gruße aus Hamburg,
Poppa

Das musst du für dich selbst entscheiden. Ich nutze Grafana und behalte es da es traumhafte Dashboards ermöglicht. InfluxDb ist eine Timeseries Datenbank und hat Top Performance für diesen Anwendungsfall.

Wenn dir die Plots reichen die in Home Assistant möglich sind ist es natürlich nicht nötig zusätzliche Tools zu installieren.

Ich nutze sowohl Grafana als auch Influx in Docker. Kann dir nichts dazu sagen. Welche Version wird als Addon installiert? Die Links und auch die Konfiguration ist für V1. Kannst du da v1 und v2 auswählen?

Du hast in deiner Config oben den Parameter api_v1 nicht gesetzt. Denke das musst du auch setzen.

influxdb:
  api_version: 1
  host: influxdb
  port: 8086
  database: homeassistant
  username: !secret influxdb_user
  password: !secret influxdb_password

Edit, ich habe es mal auf einer VM getestet. Funktioniert problemlos wnen du die Anleitung befolgtst.


1 „Gefällt mir“

Hallo Poppa,

die Lösung mit InfluxDB und Grafana funktioniert nach meiner Erfahrung heute weiterhin problemlos. Die neue Version 3 von influxdb habe ich persönlich noch nicht ausprobiert. U.a. wegen der Lizenz-Einschränkungen.

Die Anforderung bzgl. Langzeitaspekte hat mehrere Seiten und man kann darüber viel diskutieren. Du muss für Dich festlegen, was Du genau nach den X-Jahren mit diesen Daten machen möchtest. Sollten die Daten z. B. dauerhaft bei den Dashboard verfügbar sein oder geht es nur um Archivierung den Daten.
Wenn sie immer als Dashboard verfügbar sein sollten, dann kommst Du ohne Abängigkeiten von irgeneine Software nicht weiter. Da hilft m.M. nur auf Standard-Formate für die gespeicherte Daten zu setzten. Ob z. B. SQL die Lösung ist, musst Du selber überlegen. Da muss man immer bereit sein, auf anderen Tool umzusteigen. Entscheiden sind aber die Daten und nicht deren Visualisierung. Dies läßt sich immer “neu gestallten”.
D. h. viel wichtiger ist in diesem Fall die influxdb. Die Grafana ist nur eine Visualisierung, die Du einfach durch andere Tool ersetzten kannst und sogar pararell zu grafana.

Hier noch paar Kriterien, die man festlegen musste, um richtige Richtungen/Entscheidungen festzulegen:

  1. Wiel lange welche Daten sollten verfügbar sein?
  2. Ist dauerhafte Zugriff gewünscht?
  3. Kann das bestehende System die (wachsende) Datenmenge händeln?
  4. Könen die Daten exportiert bzw. portiert werden?

Wenn Du die Infos hast, kannst Du es mit den Verfügbarkeit des Software und z. B. Intervall von neuen Software-Versionen etc. gegenüber legen und bewerten, ob es für Dich akzeptabel ist.
Jedes Tool hat im Bezug auf Verfügbarkeit und Sopport Risiken. Firmen werden geschlossen, OpenSource Projekte sterben, Hardware wird ohne Rückkompatäbilität weiterentwickelt usw.

Im professinellen Umfeld ist das Thema “Archivierung” auch komplex. Wenn ich Langzeitdaten speichern sollte werde ich immer aus etabilierte Standard-Formate der Daten setzten und in diesem Format die Daten speichern. Am besten sogar als Rohdaten, damit ich sie immer in neue Anwendung importieren kann.

Wovon ich persönlich abraten werde ist sowas:

Rohdaten → Speichern im geschlossen Format einer Anwendung → (Datenarchivierung) ->Visualisierung

Man kann auch immer gesamte Systeme inkl. Daten frieren und sie beim Bedarf aufrufen. Da spielen aber solche Aspekte wie Lizenzen, SW/HW Komptibilität spielen auch eine Rolle. Wird das Software nach X Jahren noch funktionieren/starten? Ist das Betriebssystem für die Behandlung der Daten noch verfügbar?

Vielleicht sind auch mehrere Lösungen möglich? Z. B. die Daten aus influxdb als SQL exportieren und archivieren und sonst weiterchin ganz normal die Daten im aktuellen System behalten?
Du kannst damit diese Daten versuchen z. B. in neue Umgebung einspielen/ausprobieren und gleichzeitig bestehende Umgebung weiterhin betreiben.

Vielleicht wird die KI in nöchsten Jahren ohnehin alles lesen können und hat sich das Problem (gegen monatliche Gebühr) gelöst :slight_smile:

VG, Bauherr

1 „Gefällt mir“

Was machst du dass du privat mehr als 2 CPU Core und 1 Node brauchst? Mit Enterprise als Home User kannst du alles machen was früher auch ging.

Influx3 funktionert mit HOmeassistant. Nur Migration ist noch nicht vom Influxdb Team fertig, lt. deren Posts arbeiten die grad dran. Export / Import im Lineprotokoll kannst aber jetzt schon machen.

1 „Gefällt mir“

@mostie @bauherr
Vielen Dank für Eure Beiträge. Dann werde ich mich einmal daran machen das alles zum fliegen zu bekommen.
Einen Fehler habe ich bereits gefunden. Beim Anlegen der Datenbank habe ich einen Buchstaben vergessen. Homassistant statt Homeassistant. In der configuration.yaml stand dann aber die korrekte Schreibweise.
Nun bekomme ich im Explore Tab der InfluxDB auf jeden Fall schon einmal Einträge.

Grüße aus Hamburg,
Poppa

Ich mache wahrscheinlich nicht viel mahr als andere Anwender. Die Hardware-Einschränkungen mit 2CPU Core sind für mich völlig ausreichend. 1 Node geht für mich auch noch. Schöner wäre kleinen Cluster zu haben, aber es lässt sich auch anders lösen. Ich gehe aber davon aus, dass technisch die neuere Version durch die architektonische Änderungen noch besser wird. Ich mag auch solche Lösungen möglich professionel zu betreiben, um mein Basiswissen damit aufrechtzuhalten.

Was mich aktuell an der “freie” V3 Version stört ist die Einschränkung auf 5 Datenbanken. Dies ist für mich persönlich zu wenig. Ich speichere/trenne meine Daten zweckgebunden und abhängig von den Aufbewahrungszeit. Z. B. stark volatile Daten wie Metriken von Systemwerten (RAM/CPU etc.) speichert man vielleicht mal nur paar Wochen.
Mit dieser Einschränkung kann ich also gerade 5 verschiedene Aufbewahrungszeiträume definieren. Und das Thema DB je Zweck oder einfache Einsatz von Staging etc. ist noch gar nicht mit dabei. Sicherlich findet man irgenwelche Wege es umzugehen, aber aktuell sehe ich dafür noch kein Bedarf.
Ich persönlich bin eher ein Fan von solchen Format wie beim Proxmox. Technisch praktisch keine Einschränkungen und eine Möglichkeit das gesamte Set zu lernen. Damit können wenig erfahrene ITler auch selbst durch rumspielen was lernen. Irgendwann werden sie so gut, dass deren Firma was davon hat und kann durch Lizenzkosten InfluxData dann unterstützen.

VG, Bauherr

Dafür hat du ja die Enterprise At-Home Edition die du kostenlos mit 2 Core und 1 Node nutzen kannst.

Dazu brauchst du nicht mehrere Node sondern separate Datenbanken mit unterschiedlichen Data retention policy.

Die Einschränkung auf 5 Tabellen gibt es in Enterprise at-home nicht

Da scheint dichg die Limits und Unterscheidung Datenbank, Retention, Node, Cluster der unterschiedlichen Produkte zu verwirren.

Zum Rumspielen kannst du dir eine Kopie machen und mit einer neuen Enterprise Installation 30 Tage ohne Einschränkung testen. Aber für ein Home Assistant brauchst du weder High Availability mit parallelen Nodes oder Scale out mit Partitionen über Node-Cluster Konzepte. Dazu reichen eigene Tabellen.

Da sind die aktuell nocht Welten entfernt. Irgendwo war mal ein Test wo 1.8 fast überall schneller war. Speicherverbrauch ist aktuell unterirdisch sonst wäre ich schon auf 3 aber mein 32 GB Server mit 16 CPU war nicht ausreichend um meine DBs über Line Protokoll zu migrieren.