Grafana und InfluxDB neben Edomi. Installation und Best Practice

[stonie2oo4]

Ok, dann lass ich das mal so laufen und beobachte einfach mal die Datenbankgröße.
Danke für die Info das man die Retention auch später verändern kann 👍.

Backup ist ein Thema das noch ansteht, hier muss ich mich mal einlesen.
Am einfachsten wird es wohl sein, einmal täglich ein Backup auf nen Stick zu ziehen, dann hätt ich wenigstens mal einen Hardwareausfall abgedeckt. Aber hier müsste man wohl auch mehrere Backups halten und irgendwann ältere automatisch löschen 😬.
Hat zufällig jemand ne einfache Lösung parat? 😅😂

Der LBS von jonofe steht doch schon in der neuen Version bereit, oder seh ich das falsch?
https://knx-user-forum.de/forum/proj...09#post1814109

[rdeckard]

Kann dir selber leider auch noch keine eigenen InfluxDB-Praxiserfahrungen mitteilen. Grundsätzlich ist aber InfluxDB speziell für sehr grosse Datenmengen in sehr hoher Performance ausgelegt. Sie kann nicht "viel", aber das kann sie besonders gut.

Aber natürlich kommt auch InfluxDB irgendwann an seine Grenzen. Ob das mit unseren typischen Sensordaten im Heimbereich in absehbarer Zeit spürbar wird, würde ich mal bezweifeln. Hängt aber natürlich auch von der Rechenleistung des InfluxDB-Servers ab. 60 GB Platte sollte sicher länger halten. (An Backup noch denken!)

Man kann eine eigene Retention definieren. Ob es da auch eine Verdichtungsmöglichkeit gibt, weiss ich grad nicht. Auf das (durchaus komplexe) Retention-Thema kannst du aber ja später mal zurückkommen, wenn es vielleicht nötig wird.
Wie immer bei einem solchen System solltest du die DB überwachen. Dann weisst du früh genug, ob dir langsam der Speicher ausgeht oder die DB zu langsam wird.

Bezüglich dem LBS von jonofe würde ich noch mit dem produktiven Einsatz warten, da er ja von einer verbesserten Version geschrieben hat. Würde sich vermutlich lohnen, alle Datensätze grad mit der neuen Version zu schreiben. (Falls diese "demnächst" mal rauskommt)

[stonie2oo4]

Erstmal Danke saegefisch für deine ausführlichen Infos.
Hat ein bisschen gedauert aber ich kam jetzt endlich mal dazu Influx und Grafana zu installieren.

Hab mich jetzt dank eurem Input dazu entschieden dies auf einem extra Server unabhängig von Edomi zu installieren.
Es handelt sich dabei um ein Debian 11. Falls jemand eine einfache Anleitung benötigt, bin ich hier fündig geworden:
https://computingforgeeks.com/how-to...-debian-linux/
https://computingforgeeks.com/how-to...-debian-linux/

Eigentlich recht simpel die ganze Installation. Buckets hab ich jetzt auch erst mal einen erstellt (haus) für die ganzen Messwerte der Temp, usw. Sensoren und Stromzähler, Wetter und was noch so alles an Datenmüll abfällt vom Bus 😂.

Die erste Schwierigkeit hatte ich beim verbinden von Grafana und Influx. Hab mich hier für die Query Language Flux entschieden. Bekam dann immer ein Access Fehler.
Dieser Link hat mir dann bei dem Problem geholfen:
https://community.grafana.com/t/trou...ource/36490/29
Man muss die Parameter für Header und Value hinzufügen mit den richtigen Werten, dann klappt die Verbindung.


Ich hab jetzt bei dem Bucket: haus eingestellt das er nie die Daten löschen soll. Jetzt ist natürlich schwer abzuschätzen wie groß die Datenbank irgendwann wird.
Kann man hier irgend etwas einstellen das die Daten nach einer bestimmten Zeit, also z.B. 3 Jahre zurückliegend verdichtet werden?
Bzw. ist das überhaupt nötig?
Ich mein ich hab noch 60Gigabyte auf der Platte frei, bis ich die voll hab raucht eher die Platte ab 😅. Oder macht es aus Performance Sicht Sinn hier irgendwann mal ein bisschen aufräumen zu lassen?

Ich hab jetzt ja nur mal die Basis Installation, sollte ich sonst irgend was besonderes beachten, oder kann man das so laufen lassen?

So, für heute ist jetzt erst mal Schluss, als nächstes leg ich mal alle Datenarchive in Edomi an und dann wird endlich der LBS von jonofe getestet 😁.
Gute Nacht.

[rdeckard]

telegraf:
Retention: Hier lasse ich mich vom Zweck und Datenmenge leiten... wenn ich ein Technik-Thema habe, ist das meist rasch zu sehen (Server geht nicht, etc), lange Vergleichszeiten sind mMn nicht nötig. Was soll ich mit der CPU-Last von vor 1 Jahr um 18:52? (proxmox, telegraf). Technik schon ggf. etwas länger. Anderes bei haus-Daten, die mag ich deutlich länger haben.

Sehe ich genauso. Man muss zwischen Kurzzeit- und Langzeitdaten unterscheiden.
Natürlich ich es immer eine persönliche Präferenz. Aber für mich sind Daten, welche über eine längere Zeit eine ZUSATZINFORMATION ermöglichen, sehr wichtig. Weil diese Zusatzinformation ist sonst nicht erreichbar und auch später nicht mehr zu erhalten.
Gerade Sensor- oder Messdaten (Wetterdaten, Stromverbrauch, PVA-Produktion etc.) gehören für mich in diese Kategorie. Klar ist es nicht wichtig zu wissen, wieviel Strom ich vor 4 Jahren am Tag X genau verbraucht habe. Aber die Kurve über all diese Jahre ist dann eben wichtig und für mich interessant. Solange ich technisch die Möglichkeit habe und meine Datenbank dies sinnvoll verträgt, behalte ich diese Detailinformationen lieber auf. (Oder konsolidiere es zumindest auf eine sinnvolle Menge.)

Gewisse Veränderungen sind oft schleichend und wir Menschen übersehen gerne schleichende Veränderungen. Mir fällt z.B. nicht gross auf, dass ich am Tag evtl. nicht mehr ganz soviel Strom via PVA produziere, weil hier natürlich das tägliche Wetter eine Rolle spielt. Schaue ich aber die Stromproduktion mal über die letzten 5 Jahre an, dann sehe ich evtl. eine Tendenz, dass meine PVA nie mehr an den Peak von vor 5 Jahren rankommt und evtl. durchschnittlich (unabhängig vom Wetter, soweit das möglich ist) 10% weniger Strom produziert. Das kann dann normal sein oder auf eine Verschmutzung der Panels hinweisen.

Auch die Luftfeuchtigkeit im Haus wäre so eine interessante Langzeitinformation. Müsste ja eigentlich (übers Jahr gemittelt) ungefähr gleich bleiben. Aber gerade bei einem Neubau ist in der ersten Zeit viel Restfeuchtigkeit im Haus gespeichert, die mit der Zeit entweicht. Über längere Zeit gemessen, müsste man das auch in der durchschnittlichen Raum-Luftfeuchtigkeit ablesen können.

Also sich immer zuerst die Fragen stellen, was möchte ich mit diesen Daten anfangen und ergeben sie einen zusätzlichen Nutzen über eine lange Zeit.

[saegefisch]

telegraf: Telegraf-Metriken von allem, was sinnvoll geht. Schema wird von Telegraf bestimmt und passt über alle Geräte. Recht hohe Frequenz und Datenmenge.
proxmox: System-eigenes Schema, die nur bedingt zu telegraf passen; führe ich wohl möglich aber doch noch zusammen. Recht hohe Frequenz und Datenmenge.
technik: Alles im Haus, was nicht fest verbunden ist: Hier mache ich eigene Krams, wie anstehende Updates der Server, etc. aber auch Speedtest, ping-checks, FritzBox,... Schema von mir. Meist auch deutlich niedrigere Zeit-Granularität. Könnte man aber auch zusammen führen (selbes bucket, eigene tags/maesurments) mit telegraf und proxmox
haus: alle Haus- und Umwelt-Metriken (inkl. WW, Lüftung,...): Verbrauch, Temperaturen,... Schema von mir.
dazu kommt vermutlich noch fluentd: Logs - völlig anderes Schema.

Retention: Hier lasse ich mich vom Zweck und Datenmenge leiten... wenn ich ein Technik-Thema habe, ist das meist rasch zu sehen (Server geht nicht, etc), lange Vergleichszeiten sind mMn nicht nötig. Was soll ich mit der CPU-Last von vor 1 Jahr um 18:52? (proxmox, telegraf). Technik schon ggf. etwas länger. Anderes bei haus-Daten, die mag ich deutlich länger haben.

[gibsonrocker]

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

[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]

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.

[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]

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

[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

[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ß

[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?

[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.

[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.