Grafana und InfluxDB neben Edomi. Installation und Best Practice

[stonie2oo4]

Durch den coolen LBS http://service.knx-user-forum.de/?co...ad&id=19002576 von jonofe spiel ich auch mit der Überlegung meine Mess-Daten in Influx zu speichern. Einfach weil die Edomi Aktivierung mit großen Datenarchiven viel zu träge wird.
Nun hab ich aber noch einige Wissenslücken. Ich hoffe ihr könnt mit vielleicht ein bisschen Licht ins Dunkle bringen.

Ich fang mal mit den grundlegenden Fragen an.

1. Wo sollte man die Installation von Influx und Grafana durchführen, auf extra Hardware oder kann man es ohne Probleme auf der Edomi Maschine laufen lassen. Was hat welche Vor- und Nachteile, bzw. was würdet ihr empfehlen?

2. Habt ihr vielleicht einen Link für eine gute Installationsanleitung? Bzw. ist die Installation wie ich gesehen habe recht simpel, gibt es in Hinsicht auch Edomi etwas spezielles zu beachten?


Glaub das reicht mal für den Start. Ich hätte noch 2-3 weitere Fragen 😅, aber eins nach dem anderen.

[uzi10]

Also die meisten hier haben proxmox laufen und edomi und grafana/ influx auf verschiedenen lxc containern. Wird dann einfach verlinkt. Ist top zum warten. Man kann allen die Ressourcen zuteilen. Wenn man mist baut, ladet man einen Snapshot von vorher. Backup ist super usw.

[vento66]

Woher denn diese Weisheit, das die meisten proxmox einsetzen? Ich kenne schon mindestens 10 bare Metal Installationen, die dürften wohl deine 1 schon mal locker hinten an setzten. Dann noch die ganzen Docker Installationen. Da hängt sich einer aber weit aus dem Fenster.

[jolt19]

Ich bin kein Experte und viele von euch wissen sicher sehr gut was und warum sie es so tun, aber ich mache es genau so wie von uzi10 beschrieben aus den vom ihm genannten Gründen.

Einfaches Setup, Performance (natürlich Hardwareabhängig) ist kein Problem, Einfache Backups/Snapshots und damit ziemlich einfach selbst gebauten Mist wieder rückgängig zu machen.

[philipp900]

Wenn du sowieso mit Null anfängst würde ich auch eine virtualisierte Lösung vorschlagen.
Ob jetzt Docker oder Proxmox ist geschmacksache.
Lässt sich deutlich einfacher updaten und warten.
Auch die Einrichtung ist dank vorgefertigter templates/images in wenigen Minuten erledigt.

[rdeckard]

Mein neuer Proxmox Server läuft schon. Edomi (aktuell physisch APU) wird dann bald auf Proxmox migriert (versuche es mit dem tollen Container von Yves). Und dann wird endlich auch der Punkt InfluxDB in Arbeit genommen (als separate VM/Container).

Dabei kommen mir zu diesem Thema zwei weitere, wichtige Fragen in den Sinn:

1. Welche Version von InfluxDB verwenden (1.x oder 2.x)? Mit 1.x macht man sich wohl das Leben einfacher, da viele Beispiele und Scripte auf 1.x basieren. Andererseits ist es fragwürdig, ob man bei einer Neuinstallation wirklich auf eine alte Version setzen sollte, da man früher oder später vermutlich um 2.x nicht herum kommt. (Ich beziehe mich jetzt nicht nur auf Edomi mit InfluxDB, sondern evtl. auch für andere Quellen im Home Lab.)
2. Wie migriert man sicher und schnell die bereits bestehenden MySQL Archivdaten zu InfluxDB? Mit kürzester Downzeit, weil man ggf. seine Sensordaten ohne grosse Lücken migrieren möchte.

[jonofe]

Welche Version von InfluxDB verwenden (1.x oder 2.x)?

2.x

Auch der LBS19002576 setzt v2 voraus.

Wie migriert man sicher und schnell die bereits bestehenden MySQL Archivdaten zu InfluxDB?

Mit dem LBS19002576.

Es kommt allerdings bald eine neue Version, die direkt den ms-Timestamp von EDOMI berücksichtigt und diesen nicht als Tag in der InfluxDB speichert.
Wenn man vorher den aktuellen InfluxDB Archiv LBS einsetzt, dann ist eine Migration notwendig. Dazu gab es bereits eine Diskussion in einem anderen InfluxDB Thread. Ein Migrationsskript wird dann vermutlich auch enthalten sein.

[stonie2oo4]

Also so wie ich das jetzt rauslese betreiben die meisten ihre Influx und Grafana Installation auf einem separaten System, ob jetzt virtualisiert oder klassisch auf bare metal.
Dann werd ich das auch mal so umsetzen. Bei mir läuft Edomi separat auf einem APU. Ich werde dann Influx und Grafana mal auf einem weiteren APU installieren.
Ist außer Influx 2.x noch etwas spezielles für Edomi zu beachten?

[DiJai]

Servus Ben,
es wäre grandios, wenn Du Deine Erfahrungen und Installationsschritte hier teilen könntest. Ich will auch diesen Weg beschreiten und weiß auch nicht so recht, wie und wo ich ansetzen soll.
Herzlichen Dank und besten Gruß

[saegefisch]

Hej Ben "stonie2oo4", zu Deinen beiden Fragen... Ich möchte über eine weitere Alternative berichten, die sicher etwas unkonventionell ist und man ganz sicher sehr unterschiedlicher Meinung dazu sein kann, aber bei mir seit langem gut funktioniert.

Grundsätzlich würde ich persönlich edomi so unangetastet lassen wie möglich und so nah an Christians Konzept bleiben wie möglich. Daher betreibe ich edomi bare metal. und alles andere auf einem 2. Server - bei mir HW: 2x NUC. Geht auch anderes, aber mir persönlich scheint das ein sinnvoller Kompromiss von Sicherheit und Virtualisierung. Muss jeder für sich, seine Bedürfnisse und Fähigkeiten/Erfahrung abwägen.

• Früher hatte ich einen bare metal Docker Server laufen, Die Einrichtung von InfluxDB und grafana war damals einfach (und war es auch mit influxDB 2.x)
• Wegen weiterer Anforderungen und Hinweisen hier im Forum, wollte ich auf Proxmox umsteigen.
  • Docker war so schön einfach für viele Dienste und wollte ich weiter nutzen. Nun habe ich die Docker-Dienste quasi doppelt virtualisiert: In Proxmox läuft ein Ubuntu-Server mit Docker, darin u.a. MQTT(Mosquitto), Wiki, 2x InfluxDB, Grafana, Portainer, Watchtower, nextcloud, Webtrees,... einzig TVheadend (TVH) verliert mal ein Frame, daher zieht das demnächst aus und wird ein eigens LXC.
    Für InfluxDB und grafana war mir LXC viel zu viel Aufwand im Vergleich zu Docker und funktioniert völlig problemlos (siehe unten)
    Verzeichnis (für Service und getrennt für Daten) anlegen, Docker-compose-file erstellen, ausführen, fertig.
  • 2 edomi-Instanzen (Prod-Fallback und Entwicklung) als LXC (ich persönlich halte die LXC-Lösung für Christians Konzept von Verknüpfung von edomi und BS für besser als eine Docker-Lösung. Denn edomi ist mehr, als ein Dienst - aber dazu darf man auch unterschiedlicher Meinung sein edomi als Docker betreiben. Und auch wenn ich mir damals selber ein LXC für mich gebaut habe; Yves "starwarsfan" hat ja seit dem eines bereit gestellt (Danke!) - damit würde ich das nächste mal starten.
  • Weitere Ubuntu-Server für non-Docker-Dienste (z.B. OWFS/1-wire + push auf MQTT, telegraf,...)
  • piHole (LXC)
  • ...

Für mich und meine Bedürfnisse ist das das beste aus zwei Welten (Proxmox und Docker). Proxmox ist ein Traum der Stabilität und Wartung. LXC für alles, was man sonst bare metal installieren würde (z.B. piHole oder edomi-fallback oder Docker). Docker ist ein Traum von Einfachheit für die Einrichtung von Diensten und mit riesiger Community und vielen Hilfen und Beispielen im WWW
edomi würde ich allerdings NICHT doppelt virtualisieren, weil das sicher die Wahrscheinlichkeit von verlorenen KNX-Paketen erhöht. Das wäre mir zu wichtig. Daher entweder edomi bare metal oder als LXC oder wenn Docker, dann Docker auf bare metal, aber nicht Docker in einem LXC-Container.

Ich rate Dir, direkt auf influxDB 2.x zu gehen. Flux ist weniger schwer, als es aussieht. Wenn man anfängt sowieso. Ich habe die für mich weiterhin wichtigen Teile meiner 1.x Dashboards im wesentlichen in ein paar Stunden für mich übersetzt. Ist ja irgendwann alles ähnlich und systematisch. Ein paar Sachen stehen noch aus, auf anderes verzichte ich (simplify my life). Nachteilig ist, dass für 2.x noch viel weniger fertige Dashboards zum herunter laden gibt.Aber das wird. MIt 1.x würde ich nicht mehr einsteigen.

Mit folgenden docker-compose-Files kommst Du schon mal an. Danach kannst Du daran feile. z.B. Deine Volumes (für Daten) magst Du mehr oder weniger oder anderes haben). Man kann das auch noch mit einem init-Script etwas ausfeilen, damit man gleich ein paar weitere Buckets angelegt bekommt, aber das ist nur Kür. Entweder brauchst Du nicht mehr oder legst sie manuell in influxDB gui danach an oder fuchst Dich in so ein init-Script ein - ist letztlich auch einfach und gut dokumentiert (influxDB-Doku!)
Info zu Bucket: Wie eine Datenbank mit gemeinsamer Retention-Dauer. Alle Daten mit gleicher Vorhaltezeit können in ein Bucket. Du brauchst technisch mehrere, wenn Du unterschiedliche Vorhaltezeiten willst. Bei gleicher Vorhaltezeit sind mehrerer Buckets optional, den Daten in influxDB werden üblicherweise über tags differenziert, nicht über Buckets.

Der Docker-Server: Ubuntu-Server in LTS-Version so pur wie möglich installiert. Danach Docker und docker-compose installiert und falls fehlt nano und so'n Gedöns.
Dann habe ich mich für diese Struktur entschieden als Idee:

/app/influxdb2/ >> hier liegt das docker-compose.yml
/app/grafana/ >> hier liegt das docker-compose.yml
/app/<was auch immer du noch als Docker haben möchtest>
/app/volumes/influxdb2 >> hier werden die Daten abgelegt
/app/volumes/grafana >> hier werden die Daten abgelegt
/app/volumes/<weitere >> hier werden die Daten abgelegt

Per Script kann man dann /app komplett regelmäßig (z.B. alle 10 min) auf den NAS syncen. Schön einfach und Backup enthält app und Daten gleichermaßen.

version: "3"

services:
influxdb2_technik:
image: influxdb:latest
container_name: influxDB2_technik
hostname: influxdb2_technik
restart: always
ports:
# hier DEINEN gewünschten Port einsetzen
- "9926:8086"
volumes:
- /app/volumes/influxdb2:/var/lib/influxdb2:rw
- /etc/localtime:/etc/localtime:ro
- /etc/ssl/meineca/certs/<deinzertifikat>:/etc/ssl/influxdb-selfsigned.crt:ro
- /etc/ssl/meineca/private/<deinzertifikat>:/etc/ssl/influxdb-selfsigned.key:ro
environment:
- "TZ=Europe/Berlin"
- INFLUXD_TLS_CERT=/etc/ssl/influxdb-selfsigned.crt
- INFLUXD_TLS_KEY=/etc/ssl/influxdb-selfsigned.key
- DOCKER_INFLUXDB_INIT_MODE=setup
- DOCKER_INFLUXDB_INIT_USERNAME=<DEIN_admin-User-Name>
- DOCKER_INFLUXDB_INIT_PASSWORD=<DEIN_admin-PW>
- DOCKER_INFLUXDB_INIT_ORG=<Deine_Orga_zB_Dein Hausname..ist nötig, aber inhaltlich völlig egal für daheim>
- DOCKER_INFLUXDB_INIT_BUCKET=technik
- DOCKER_INFLUXDB_INIT_ADMIN_TOKEN=<irgendeine_lange_generierte_GUID>

version: '3'

services:
grafana:
image: grafana/grafana:latest
container_name: grafana
hostname: grafana
restart: always
ports:
# hier DEINEN gewünschten Port einsetzen
- "9920:3000"
volumes:
- /etc/localtime:/etc/localtime:ro
- /etc/ssl/meineca:/etc/grafana/ssl:ro
- /app/volumes/grafana/data:/var/lib/grafana
- /app/volumes/grafana/grafana.ini:/etc/grafana/grafana.ini
environment:
- "TZ=Europe/Berlin"
- GF_INSTALL_PLUGINS=grafana-piechart-panel,grafana-simple-json-datasource,grafana-clock-panel
- GF_SECURITY_ALLOW_EMBEDDING=true
- GF_AUTH_ANONYMOUS_ENABLED=true

Danach Aufruf (ggf. Port an Deinen anpassen!) mit:
https://<IP_Docker_Server>:9926
und
https://<IP_Docker-Server>:9920

Da proxmox und influxDB, Grafana zentraler Teil Deiner Infrastruktur werden, lohnt es sicher in edomi danach per ping und hostcheck die Verfügbarkeit von Server und Dienst regelmäßig zu prüfen und Dich ggf. mit Mail informieren zu lassen, wenn etwas down ist.

Viel Spaß und Erfolg bei der Wahl und Umsetzung Deiner für Dich besten Lösung - wie auch immer sie aussieht

[gibsonrocker]

Hallo an alle Influx´er...

Eine "Best-Practice" Frage an Euch.

Ich komme aus der LAMP-Welt und bin es gewohnt in MySQL mit vielen einzelnen Tabellen zu arbeiten. Irgendwie "stört" es mich viele "unterschiedliche" Daten in ein Bucket zu schieben. Wieviele Buckets habt ihr so am laufen?

z.B:
1. Bucket für Temperaturen
2. Bucket für Wetterwerte (Regen, Niederschlag)

Oder macht ihr das Bucket wirklich nur von der Aufbewahrung abhängig:

1. Bucket für 1 Jahr
2. Bucket für 2 Jahre
usw....

Wie habt ihr das so für Euch gelöst? Sollte ich mich ggf. von meinen MySQL Gedanken mit Influx verabschieden (reine Kopfsache)?

vg, Bernd

[jonofe]

Ich komme aus der LAMP-Welt und bin es gewohnt in MySQL mit vielen einzelnen Tabellen zu arbeiten.

Mein Verständnis ist, das die Influx Buckets vergleichbar sind mit den Databases in mySQL und die Measurements mit den Tabellen. Im wesentlichen entscheidet die Retention Policy, ob ein neuer Bucket notwendig ist, denn die Retention Policy ist hart an den Bucket gebunden.

Ich verwende einen Bucket. Granulare Retention Policies verwende ich nur in EDOMI. Aber der Ansatz von Buckets mit 1, 2, 3, etc. Jahren Retention Policy ist sicher auch eine gute Idee. Individuelle Retentions je Measurement kann man auch recht Einfach per Flux Query umsetzen.

Influx beschreibt auch Limits bzgl. der Anzahl von Buckets:

Bucket limits
A single InfluxDB 2.2 OSS instance supports approximately 20 buckets actively being written to or queried across all organizations depending on the use case. Any more than that can adversely affect performance.

Daher würde ich vermutlich nicht je Measurement einen Bucket definieren. In EDOMI sind ja auch alle Datenarchiveinträge in einer Tabelle.

[gibsonrocker]

Danke Dir für Deinen Rat!

Auch in EDOMI macht es mich immer fertig wenn ich sehe das alle Datenarchive in einer Tabelle sind. Als ich das erste mal mit PHPMyAdmin reingeschaut habe bin ich etwas grün im Gesicht geworden.


Das spricht gegen mein Ordnungsverständnis mit vielen einzelnen Tabellen.

[saegefisch]

Time Series DB != SQL-DB

ich stimme André fast komplett, wie buckets und measurements zu verstehen sind

Neben Rentention trenne ich aber auch strukturell nicht zueinander passende Daten.
Habe selber daher 3 Buckets, werde vielleicht am Ende max. 5 sein; ist bei mir noch im Aufbau.

[gibsonrocker]

Also bei Dir eher mein erster Punkt mit "passenden" Daten. Darf ich fragen wie die heißen bzw. was Deine Gedanken waren?