Grafana und InfluxDB neben Edomi. Installation und Best Practice

[scw2wi]

Dann werd ich mal die vorhandene Doku als Einstieg nutzen.

[DJens]

saegefisch: Vielen Dank für deine Ausführungen! Das klingt alles sehr durchdacht. Ich habe noch ein paar Fragen zu deinem Setup bzw. zu Post 10

Du schreibst:

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.

D.h. du würdest edomi dann als LXC unter Proxmox laufen lassen? Auf der selben Hardware wie die ganzen anderen Dinge? Oder würdest du auch dann einen zeiten NUC kaufen, auf dem dann der edomi LXC Container als einziger unter Proxmox läuft?

In Proxmox läuft ein Ubuntu-Server mit Docker

Also als LXC Container in dem dann Docker läuft?

darin u.a. MQTT(Mosquitto), Wiki, 2x InfluxDB, Grafana, Portainer, Watchtower, nextcloud, Webtrees,...

Bzgl. Hardwareanforderung habe ich derzeit nur 1x Influx und Grafana auf dem Schirm. Gut möglich, dass da noch was dazu kommt, was ich heute noch nicht auf dem Schirm habe. Daher wollte ich mal fragen, für was du die einzelnen Docker Container nutzt?

• MQTT = als Schnittstelle zwischen 1wire und edomi? (klingt interessant, wenn ich das so richtig verstanden habe)
• Wiki = Doku des ganzen Setups, damit andere im Fall der Fälle mit der Hausinstallation klar kommen können?
• 1. Influx = Als Datenbank zum Speichern von Werten vom KNX-Bus/Edomi und anschließender Visualisierung durch Grafana (klar)
• 2. Influx = Für telegraf?
• Grafana = siehe 1. Influx
• Portainer = Docker Container Verwaltung - liegt dieser Docker Container parallel zu den anderen und über diesen bekommst du ein UI zur Verwaltung der anderen Container? (klingt interessant, wenn ich das so richtig verstanden habe)
• Watchtower = Auch parallel zu den anderne Docker Containern zum dynamischen und automatisch? updaten aller Docker Container, um alles auf Stand zu halten? (klingt interessant, wenn ich das so richtig verstanden habe)
• nextcloud = ?
• Webtrees = Web based family history software?
• TVheadend = TV streaming server and recorder for Linux?

Edomi läuft ja bei dir bare metal auf einem ersten NUC und der ganze Rest auf einem zweiten NUC. Wenn ich mir deine Posts aufmerksam durchlese, hast du auf dem zweiten dann eine ganze Reihe an LXC Containern laufen:

- Docker Server
- Edomi Fallback
- Edomi Entwicklung
- OWFS/1-wire
- telegraf - für welchen konkreten Zweck nutzt du es in deiner Installation?
- piHole - für welchen konkreten Zweck nutzt du es in deiner Installation?


Ich finde den Gedanken Edomi in einer Entwicklungsinstanz weiter zu entwickeln bzw. zu konfigurieren charmant. Aber was ist, wenn parallel ein anderes Edomi (die Produktivinstanz) parallel läuft? Kommen die sich nicht gegenseitig ins Gehege mit den KNX-Telegrammen? Ich nehme an, Fallback startest du nur, wenn Produktiv, warum auch immer, nicht mehr läuft und sich nichts ins Gehege kommen kann oder?

Frage: Hast du das Fallback mal laufen lassen? War das alles noch schnell genug (bzw. hast du einen Unterschied zum Produktiv edomi auf bare metal gespürt? Diese Variante entspräche ja der Variante alles auf einem NUC laufen zu lassen. Also Influx, Grafana als Docker in einem LXC und Edomi in einem zweiten LXC und beides orchestriert durch Proxmox als Hypervisor oder? Wenn das alles noch gut funktioniert was für einen NUC hast du genau als Proxmox Server in Betrieb? Du schreibst ja einen NUC iCore 5 - aber die NUCs werden ja in NUC 7, 8, 9, ... in unterschiedlichen Konfigurationen angeboten, die sich teilweise erheblich preislich unterscheiden. Und welchen NUC nutzt du als edomi bare metal Hardware?

Fragen über Fragen - sorry!!!
Im Grunde stehe ich vor der Kaufentscheidung eines oder zweier NUCs und frage mich was die heute (und morgen) können müssen, sodass ich sinnvoll auswähle...

[saegefisch]

Hi Jens,
Ein nach dem anderen... und ist jetzt auch arg OT. Es ging hier um influxDB und grafana

An meiner Wand im KG neben 19" hängen gut gelüftet zwei NUCs. Test ohne Lüfter habe ich auch schon gemacht und vor sehr langer Zeit hier auch dokumentiert. Die sterben nicht, laufen gedrosselt weiter. Für mich ok. Standardware und die Wandaufhängung ist seit vielen Jahren unverändert = NUC jederzeit austauschbar. Fein.

NUC unterscheiden sich in intel-Generation 7,8,9... und cpu i3, i5, i7 und mit oder ohne platz für hdd.
Ich nutze nur ohne hdd, also kaufen, RAM rein, M2-NVMe rein, los gehts.

edomi:
Primär dediziert auf eigener HW, z.B. bei mir "model name : Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz" mit 4GB RAM. Reicht mir.
Da ich edomi bei mir als zentral ansehe, habe ich mehrere Fallback: Im Sinne meiner Reduzierung von Einfachheit, nutze ich neben Laptop und Gaming-PC im Haus ausschließlich NUC und genau auch aus diesem Grund - sparsam und austauschbar und über Jahre vermutlich verfügbar (stimmt bisher): So steht bei jedem TV/Beamer ein NUC für LibreELec/Kodi. Die kann ich jederzeit kanibalisieren und in 1-2h als Ersatz aufsetzen. Bereits getestet. Gelegentlich tausche ich mal einen gegen was neues aus. Bisschen Spielkind bleibt immer

Als weitere Fallback-Ebene den LXC-Container. Halte ich aktuell, aber ansonsten leer, bereit Backup einzuspielen und in edomi darin dann IP anpassen zu müssen. Einspielen bisher noch nicht getestet, steht auf todo-Liste. Sollte auch in 1-2h laufen. Ist eher ein Versuchsballon, weil ich genug NUCs habe.

Für Entwicklung und Test LXC-Container - vor allem für meinen eigenen LBS. Jeder Reboot ist in wenigen Sekunden gemacht, weil keinerlei Datenarchive, so macht entwickeln Spaß. Das DEV-Projekt hat nur den ETS-Import bekommen, sonst nichts. Wofür auch? Minimale Visu zum probieren. Für jeden LBS eine Logik-Seite mit allen Testvarianten (Regressionstest), damit ich auch gleich sehe, ob ein eine Änderung irgend eine Anwendungsvariante stört. Aber auch für Tests mit fremden LBS, z.B. um MQTT oder JSON-Krams zu probieren - das ist ja nicht immer einfach.

Wichtig: Stets nur eine aktive Instanz von edomi mit Logiken, etc! Mein DEV-Instanz will nur spielen (= nur lesend), die fallback-Instanz wird nur genutzt, wenn PROD ausfällt. Habe keine Lust auf Chaos.
Info, falls es Dich interessiert: Es gibt Threads hier zum Thema automatisches Fallback mit 2. aktiver Instanz. Das habe ich nie verfolgt, fand ich für mich zu kompliziert und potentielles Risiko von Interferenzen - im Vergleich zu einem NUC, der irgendwo herumsteht und als Ersatz dienen kann.

Daher würde ich NICHT "edomi in LXC weiter entwicken". Ich baue an meinem PROD eodmi direkt - habe ja tägliche Backups davon und kann zurück, wenn ich's versemmle. Aber LBS-Entwicklung mache ich im LXC. Und ja, vor einer Weile hatte ich edomi mal in LXC laufen (Umstieg PROD edomi 1.x auf NUC, neues edomi 2.x auf LXC). Parallelbetrieb will sehr gut bedacht sein! Lesend nie ein Thema. Visu auch nie (habe über längere Zeit komplett neue Visu für 2.x gebaut, die Logik lief noch in 1.x), aber schreiben und Logiken...aufpassen! Ich habe den Logik-Teil an einem WE in einer konstertierten Aktion umgezogen. LXC war ok von performance.

Aber das ist für mich NIE der Antrieb für eine Architektur-Entscheidung. Ich entscheide aus anderen Gründen (siehe Gedanken letzte Nachricht) und kaufe dann die Performance die nötig ist. Würde ich edomi dauerhaft in LXC auf Proxmox laufen lassen WOLLEN, um einen NUC zu sparen, würde ich mir vermutlich eine i7 gönnen. Nötig? Keine Ahnung, ist mir egal.

"Alles andere"...Proxmox: Dachte, es wäre ein i5, ist es aber gar nicht, bei mir "Intel(R) Core(TM) i3-8109U CPU @ 3.00GHz" mit 32 GB. würde mir jetzt wohl eher einen i5 kaufen. Aber letztlich brauchen die Dienste alle fast nix bis nicht so wahnsinnig viel, außer TVH. der i3 reicht, RAM ist wichtiger für Proxmox.

Ja, tatsächlich habe in Proxmox einen LXC, in dem Docker läuft und darin die Container. Die laufen also doppelt virtualisert. Nicht dass das nötig oder sinnvoll wäre, aber ich kannte Docker und wollte das weiter verwenden. Und ich wollte Proxmox, weil extrem stabil und mein alter "nur-Docker"-Server irgendwie das nicht so war. Daher Docker in LXC.
Docker ist für bestimmte Zwecke grandios einfach und es gibt eine starke Community. z.B. influxDB und Grafana ist in Minuten aufgesetzt und - ich nutze zumeist "official" oder "verified" Container - sie sind gut dokumentiert und sinnvoll von Profis eingerichtet. Würde ich das als LXC selber machen für jeden Dienst, wäre das mMn mehr Arbeit und als Laie für den Dienst vermutlich schlechter eingerichtet. So mache ich mir nur Gedanken, dass meine Volumes sinnvoll sind und mehrfach täglich auf den NAS gesynct weren bzw. direkt per mount auf den NAS gehen (TVHeadend wegen der großen Dateien). Das alles einmal eingerichtet und gut. Weitere Container sind dan easy.
Alles was nicht sinnvoll gedockert werden sollte als weitere LXC. Es gibt z.B. Dienste, die es nicht als Docker gibt ode keinen Sinn ergeben, weil wie z.B: piHole ein etabliertes System-Setup sind, wie eodmi auch.

LXC Docker (alles was geht in Docker)
LXC edomi fallback
LXC eodmi DEV
LXC TVheadend (weil doppelt virtualisert öfter mal Netzwerk-Latenzen mit Bildausetzern)
LXC piHole
LXC AVAHI (nur sinnvoll, wenn Du mehrere VLAN hast)
VM (Ubuntu) für alles, was mit LXC und Docker nicht gut geht, wie OWFS/1-wire (1-wire-USB-Adapter hängt am Proxmox und wird an VM durchgereicht)

ZU den Diensten:
MQTT: Ich halte MQTT für wichtiger als influxDB und Grafana und rate Dir unbedingt zur Einrichtung. Gehe davon aus, dass Du früher oder später Anwendungen dafür haben wirst. Wenn es nicht ein wirklich verlässliches Interface für etwa in edomi gibt, verbinde ich es über MQTT. Das macht es auch einfach und MQTT als Data-Broker ist genau für diese Zwecke gebaut. z.B. mein ESP8266-Datensammler (Lüftung, Pool,...) oder eben alles von 1-wire (vom OWFS-Server per MQTT gepusht) und auch non-Standard-Teile von telegraf - alles über MQTT.

InfluxDB: 1x haus-Instanz, 1x IT/Infrastruktur incl. telegraf (Metriken/Überwachung aller Systeme) -> beide für Grafana. Ansonsten zu telegraf selber informieren.

Wiki: bewusst ein nicht-DB-basiertes-Wiki, weil alle Informationen zur not als Text lesbar, ich habe mich für DokuWiki entschieden - selber informieren. Und andere und meine Gedanken hier: https://knx-user-forum.de/forum/proj...us#post1615380
Watchtower und Portainer: Sinnvoll, wenn man dockert - selber informieren

TVheadend: Sat-Schüssel > SAT-IP-Server (setzt TV-Signal auf LAN um) > TVheadend (backend für EPG, Aufnahmen,...) >>> beliebig viele Clients, z.B. LibreElec (basiert auf Kodi) an jedem TV. TV /Beamer sind bei mir alle dumme Monitore, dafür überall gleiche Oberfläche, gleiche Fernbedienung, gleiche Sender, gleiche Aufnahmen (weil zentral im backend) -> selber einlesen: Kodi, LibreELEC, tvh. Aber wenn Du mit Deinen Smart-TVs zufrieden bist, dann ist das vielleicht nichts für Dich.
Webtrees, Nextcloud - ganz einfach selber informieren
piHole - als zentraler DNS filtert Werbung und Tracker zentral für alle Clients im LAN heraus. Durch den zentralen Ansatz wunderbar einfach - ganz einfach selber informieren und schnell installiert.

Du brauchst: edomi, MQTT.
Du möchtest: influxDB, grafana.
Ich rate allgemein zu: piHole, Wiki.
Das kann Spaß machen: tvheadend, WebTrees, Nextcloud.
Aber das ist für Dich vielleicht chchi und liegt ganz an Deinen Interessen und Spieltrieb und Bedarfen Deines Hauses, Deiner Familie und Dir.

Mehr mag ich hier nicht mehr dazu schreiben und sollte auch reichen -> bitte zurück zum Thema InlfuxDB + grafana

[starwarsfan]

Hallo miteinander

und ist jetzt auch arg OT. Es ging hier um influxDB und grafana

Auch wenn's ein wirklich cooles Posting ist: Warum schreibst Du dann hier so ein Monster-Posting anstatt einen neuen Thread aufzumachen und dahin zu verweisen?

[saegefisch]

Recht du hast! Der junge Padawan seine Disziplin er verlor

Es war spät, wollte erst kurz antworten (ja, das kann ich auch - selten), wurde dann immer größer für eine finale Antwort und irgendwann abgesendet. Dann schaute ich drauf und fragte mich das gleiche... aber um nachts um 2 hatte ich keine Lust mehr zum aufräumen. Soll ich? Dann mach' ich.

[DJens]

Habe gerade deine Antwort gelesen saegefisch ! Vielen Dank! Ich denke, ich werde die Tage mal zunächst einen NUC bestellen und dann nach und nach alles (Edomi auf LXC, Grafana und Influx) aufsetzen. Eine SSD als Influx Datengrab ist noch da.
Ich bin zutiefst beeindruckt von deinem Setup. Im ersten Schritt ging es mir darum, Edomi vom NAS wegzubekommen und Zeitreihen außerhalb von Edomi zu speichern und vernünftig visualisieren zu können und mir dabei etwas Luft für weitere Dinge zu lassen.
Vielen Dank nochmal 🙏
Und soo OT fand ich es vor diesem Hintergrund gar nicht. 😊

[marhal]

Hallo alle zusammen,

ich wollte gerade den LBS Influx Data Archives in betrieb nehmen, und war dabei die Anleitung durchzugehen. Dabei muss ich ja noch ein was nach installieren.
Leider bleibe ich bei dem ersten install.sh script hängen, da er folgende modul nicht findend l"ibmysqlclient15-dev". Ich nutze EDOMI auf einem Proxmox LCX Container mit RockyLinux. Da habe ich das abt-get nicht. Und wenn ich mit yum das Paket installieren will, findet er es nicht . Hat jemand eine Idee wie ich da weiter komme ?

Gruß
Marhal

[baumhaus123]

Da habe ich das abt-get nicht.

Versuch‘s mal mit hartem „b“. 😉

[marhal]

baumhaus123 habe ich ja. War ein Schreibfehler meinerseits. Aber im Rockylinux gibt es kein apt-get, da er sich ja auf yum stützt.

[stonie2oo4]

So, ich bin wieder einen kleinen Schritt weiter. Hab jetzt mal zwischenzeitlich den LBS von jonofe installiert. Vielen Dank dafür 😁.
Hatte nur ein kleines Problem bei der Installation, aber nach ausführen von folgendem Tipp hat es dann auch wie gewollt funktioniert:
https://knx-user-forum.de/forum/proj...63#post1805463

Davor hab ich mir mal Gedanken gemacht wie ich das ganze mit dem Backup gestalte. Ich wollte eigentlich erst mal klein anfangen und probieren das ganze auf nem USB-Stick zu machen und später dann evtl. in eine cloud schieben. Während meiner Findungsphase 😅 bin ich dann auf folgendes tolles gestoßen: https://rclone.org/
Hiermit ist es möglich per shell Dateien zu verschiedenen cloud Anbietern zu sichern. Ebenso lässt sich das cloud-drive im Dateisystem mounten ( was ich aber in dem Fall glaube ich nicht benötige )
Ich hab mich dann kurzerhand für googledrive entschieden, da ich damit schon ein bisschen Erfahrung habe und es recht angenehm zu bedienen ist, außerdem gibt es 15GB kostenlos und selbst falls das nicht mehr reichen sollte sind die Preise doch recht human.

Die Installation war total easy, bloß die Einrichtung war ein bisschen fummelig da man bei google-api eine client-id erstellen muss und später bei rclone während der Einrichtung verwenden muss. Das problematischste war das mein Server headless ist, aber während der Installation automatisch der Browser geöffnet werden sollte wo man da bei google die Erlaubnis für den Zugriff erteilen muss. Es gibt dafür einen Workaround indem man den generierten key mit einem anderen PC mit rclone ausführt.
Da es rclone auch für Windows gibt hab ich das dann kurzerhand hier erledigt. Bis ich aber die ganzen Infos zusammen hatte hab ich schon paar Stunden gesucht 😅.

Falls jemand Interesse hat, dann kann ich gern mal eine kleine Anleitung zusammen schreiben wie das ganze funktioniert.


Jetzt bin ich grad dran mir ein, oder mehrere ( bin noch am testen ) Backup script/e zusammen zu schreiben /suchen.
Was schon funktioniert: Ich hab 3 Verzeichnisse in /tmp angelegt. backup_influx, backup_grafana, backup_mariadb ( hab noch zufällig meine Kodi Datenbank auf dem Server ).
Nun hab ich folgenden script gefunden und ein bisschen umgebaut:

#!/bin/bash

listOfDirs=(/backup_influx /backup_grafana /backup_mariadb)

rcloneConfig=/root/.config/rclone/rclone.conf
rcloneOptions="-v --ignore-checksum --ignore-size --local-no-check-updated"

echo  $(date +"%Y-%m-%d %H:%M:%S") : backup started

for dir in "${listOfDirs[@]}"
do
   :
   echo  $(date +"%Y-%m-%d %H:%M:%S") :  backup of $dir
   rclone $rcloneOptions --config=$rcloneConfig sync $dir googledrive:/backup/$dir
done

echo  $(date +"%Y-%m-%d %H:%M:%S") :  backup complete​

Ob der script funktioniert weiß ich noch nicht, aber wenn ich folgenden Befehl in der shell ausführe ( also ohne Variablen ):

rclone $rcloneOptions --config=$rcloneConfig sync $dir googledrive:/backup/$dir

Dann schiebt er mir das komplette Verzeichnis auf google-drive. Soweit so gut.
Ziel soll es sein ein tägliches Backup von influxdb, grafana und mariadb zu erstellen und nach erfolgreicher Erstellung hochzuladen in die cloud.
Am schönsten wäre, wenn man immer so 5-10 Backups behalten könnte und dann immer das letzte löschen.
Und was ich auch zufällig gefunden habe, für Grafana gibt es sogar ein Dashboard für rclone, womit ich mich bisher aber noch nicht weiter beschäftigt habe.
https://grafana.com/grafana/dashboar...hboard-rclone/


Nun bin ich grad noch dabei rauszufinden wie ich die einzelnen backups erstelle. Ich hab mal mit influx angefangen, aber iwie will das ganze nicht so richtig wie in der influxdb Anleitung beschrieben funktionieren. Hat sich schon mal jemand hierzu Gedanken gemacht, bzw. schon ein backup davon umgesetzt?


Ich probier es momentan mit diesem Befehl in der shell:

influx backup /tmp/backup_influxdb_$(date '+%Y-%m-%d_%H-%M') -t "api admin token"

Daraufhin kommt folgender Fehler:

2022/11/25 19:08:16 INFO: Downloading metadata snapshot
Error: failed to backup metadata: failed to download metadata snapshot: 401 Unauthorized: read:authorizations is unauthorized
​

Wenn ich das ganze noch mit dem -u flag mit user angebe:

influx backup /tmp/backup_influxdb_$(date '+%Y-%m-%d_%H-%M') -u admin -t "api admin token"

Dann kommt ein anderer Fehler:

Error: backup path must be specified as a single positional argument

Jemand eine Idee woran das liegen kann?

[jonofe]

Zunächst finde ich, dass das Thema Backup einen eigenen Thread verdient hätte.

Zum Problem: Sicher, dass das Token ausreichende Berechtigung hat?
Ein Option -u gibt es bei "influx backup" nicht.

[stonie2oo4]

Zunächst finde ich, dass das Thema Backup einen eigenen Thread verdient hätte.

Hab ich gemacht, war mir beim Schreiben auch nicht so ganz schlüssig ob hierhin oder extra 😅.
Hier gehts dann weiter mit dem Backup-Thema:
https://knx-user-forum.de/forum/proj...db-und-grafana

[beauty]

Hier mal eine Zwischenfrage.... sollte man Proxmox eher auf bare Metal oder Virtualisiert z.b. als Docker etc. betreiben?

[knxheu]

Proxmox ist selbst eine Virtualisierungsplattform. So gesehen ergibt die Frage nicht soo viel Sinn.

[beauty]

Na gibt doch einen Proxmox Docker-Container.... und ich hätte eine Synology NAS mit Docker... meine Frage zielt eher auf die Performance ab...