Grafana und InfluxDB neben Edomi. Installation und Best Practice

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

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

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

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]

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

[jonofe]

Der LBS von jonofe steht doch schon in der neuen Version bereit, oder seh ich das falsch?

Das ist korrekt, die neue Version ist schon online.

[DJens]

Hallo zusammen,
ich stehe vor der gleichen Frage...

Ich habe zunächst EDOMI als Logikengine und Visu evaluiert und zu diesem Zwecke EDOMI als VM auf meinem Synology NAS laufen lassen. Ich finde EDOMI großartig und möchte es nun auf einer dedizierten Hardware bzw. auf jeden Fall getrennt vom NAS laufen lassen. Zudem möchte ich auch Daten zur performanten Diagrammdarstellung in EDOMI in eine Influx schreiben und die Diagramme über Grafana visualisieren.
Nun frage ich mich, ob es auch eine Lösung wäre, Edomi auf einem NUC/APU laufen zu lassen und auf der gleichen Hardware Influx+Grafana als Docker Container zu betreiben. Wäre das auch praktikable und ausreichen performante Möglichkeit?
Könnte man einzelne Komponenten auch auf nem Raspi oder einem Wiregate Server laufen lassen (beides schon da inkl. der elektrischen Verluste)?

Viele Grüße

DJens

[gibsonrocker]

Kurze Antwort: Ja zu allem. Geht alles.

Edomi sollte aber besser auf dem NUC sein.

[DJens]

Ok, vielen Dank. Ich denke ich werde dann die Lösung Edomi auf NUC und Grafana+Influx als Docker auf dem gleichen NUC laufen lassen.
Kann mir jemand eine konkrete Hardwareempfehlung für dieses Vorhaben geben? Hat das jemand schon so am laufen? Gibt es viel beim Edomi Image zu berücksichtigen?

[saegefisch]

ich persönlich würde edomi lieber echt dediziert laufen lassen ohne jeden Docker krams drauf (läuft bei mir auch auf NUC). So nah wie möglich dran am Design des Entwicklers. Da hängt mein Haus dran = keine Experimente
Ich würde an Deiner Stelle ehr den ganzen Docker-Krams auf dem Syn installieren oder für den gesamten Rest einen weiteren (z.B. NUC) mit Proxmox und darin InfluxDB, grafana, MQTT (mosquitto), edomi-Fallback, edomi-Entwicklung/test... siehe mein Antwort weiter oben in diesem Thema. Habe es genau so: 2x NUC an der Wand, daneben NAS.

Je mehr Du firm in Linux, Netzwerk, etc bist, desto eher kannst Du davon abweichen. Aber wenn Du es einfach willst, ist das mein Rat. Ich würde nix neben edomi installieren. Wenn schon alles auf 1, dann Proxmox und edomi komplett als LXC und den Rest daneben. Letztlich muss jeder für sich die richtige Lösung selber finden - es gibt da kein universelles richtig/falsch

[scw2wi]

Geht es bei deinem Rat eher um die Vermeidung von Fehlkonfigurationen und weniger um die reine Performance der HW?

[DJens]

saegefisch: Vielen Dank für deine ausführlichen Beiträge, die mir helfen, mich und mein Setup gedanklich zu sortieren

scw2wi: Deine Frage wirkt rhetorisch, was aber auch täuschen kann. Hast du eine ergänzende gute Lösung im Kopf, die du hier teilen kannst?

[saegefisch]

DJens : gerne, schön, wenn ich helfen und inspirieren kann


Es ist wie immer im Leben...eine Melange...

Was mir auf die schnelle in den Sinn kommt - es ist für mich eine Abwägung verschiedener Aspekte (man mag mir Unschärfe bei der Zuordnung der Kategorien nachsehen):

• primär die Anforderungen: Welche Dienste benötige ich?
• Fähigkeiten
  • Wie gut bin ich in IT und kann ich das auch noch warten, wenn es mal 1 Jahr gut lief ohne Maintanance. Wie dauerhaft sind meine Kenntnisse, um auch komplexe Systeme in Gang zu halten? Oder gar jemand anderes für meine Familie, wenn ich nach einem Unfall im KH liege.
  • Umfassendes Wiki für Installation (=Wiederherstellung) und laufenden Betrieb und Gesamtüberblick. Weil ich beruflich nicht täglich mit Linux arbeite und es nach Pausen immer eingerostet ist
• Energieverbrauch:
  • so wenig wie möglich HW > Virtualisierung möglichst vieler Dienste,
  • Sparsame HW (NUC liegt bei 5-7W)
• Komplexität:
  • möglichst gering und homogen = möglichst wenige verschiedene Lösungswege
  • Möglichst nicht vermischen, was nicht nötig ist, besonders bei kritischen Systemen. Für mich persönlich: edomi definitiv, NAS (aus beruflichen Gründen).
  • Keine Spezial-HW = leicht ersetzbar
• Stabilität:
  • Bei kritischen Themen rasche Wiederherstellbarkeit. Daher z.B. edomi so nah wie möglich an Christians Original und ohne weiteres chichi rasch wieder herstellbar (durch tägliches Backup auf NAS): Irgend ein PC, Grundinstallation, Backup drauf. Haus geht wieder. Docker, weitere Dienste auf edomi erschweren das. In der zwischenzeitlich LXC auf Proxmox als fallback.
  • Proxmox sehe ich stabil an und durch tägliche Backups ebenso rasch wieder herstellbar
  • Metriken/Status/Meldung: Rasche Info, wenn irgend etwas wichtiges nicht geht - Schaden: Erkennen > Begrenzung
• Verlässlichkeit:
  • Mehrstufige Backups-Strategie - geht nicht sinnvoll, wenn alles auf einer Kiste.
  • Umfassendes Wiki für Installation (=Wiederherstellung) und laufenden Betrieb und Gesamtüberblick
• Performance: Käuflich für jede gewählte Kombination. Muss erfüllt sein und entscheidet sich aus der Architektur für jedes System
• Erweiterbarkeit und Spieltrieb:
  • Welche Dienste will ich morgen mal testen oder brauche ich? Matter? Velux-GW, es kamen schon ein paar zuvor unbekannte Dinge, die stets einfach mal machbar waren.
  • Wie kann ich das schnell implementieren? Am besten immer Standards oder nah dran. LXC. Docker. Zur Not VM... alles Proxmox bei mir

Daher komme ich auf meine Abwägung - in meinen Posts weiter oben war ich zum Teil auch deutlich detaillierter (z.B: Proxmox und Docker):

• edomi dediziert auf eigener HW. HW-Bedarf überschaubar
• NAS (mehrere = mehrstufig, örtlich getrennt) dediziert und nicht genutzt für jedwede andere Anwendung (obwohl VM-fähig). Fokus auf Verlässlichkeit (RAID, mehrstufiges Backup). Von der Stange, leicht ersetzbar. Proaktiver Tausch der HDD nach ~2 Jahren
• Alles andere auf 1 Server mit für meine Zwecke angemessener HW (bei mir NUC core i5) mit Proxmox und darin ALLE anderen Dienste.

Das ist meine persönliche Abwägung - die mag für jeden anders aussehen durch Gewichtung der Kriterien. Ob durch Bedarfe, Fähigkeiten, Geldbeutel, Energiebedarf, Lust/Unlust auf Komplexität, Risiko-Affinität, Experimentierfreude, vorhandene Infrastruktur,...you name it!

Das tolle...jeder kann zu anderen Ergebnissen kommen und ist damit glücklicher als ich es bin. Klasse!

[scw2wi]

Deine Frage wirkt rhetorisch,

Ist sie aber nicht.

Deine Erklärung leuchtet mir ein, Danke dafür.

Mich würde noch etwas anderes interessieren, falls das jemand beantworten möchte.
Und auch das ist keine rhetorische Frage.
Ich finde zu Docker eine Menge an Literatur und zu Proxmox so gut wie gar nichts.
Hier im Forum wird offensichtlich beides recht gerne eingesetzt.
Suche ich nur falsch, oder gibt es zu Proxmox wirklich weniger zu finden.

[saegefisch]

Vielleicht weil Proxmox so einfach ist
Zumindest bei mir ging das meiste recht simpel und seit dem traumhaft stabil. Bei allem, was nicht ging, habe ich vorher die Doku nicht gelesen.... RTFM...kein Mitleid!

Aber Docker ist prinzipiell auch total einfach. Siehe oben mein Beitrag #10. In 15 min läuft influxDB und grafana. Das ist schon ziemlich geil und daher habe ich auch Docker in Proxmox. Ob's schlau ist? Keine Ahnung, ist mir auch egal. Bei mir geht es wunderbar. Bis auf die Details und Spezialitäten, dann wird es beliebig kompliziert - wie bei allem.Ist auch recht stabil, aber "handgeschnizter"

Spaß beiseite, meine Vermutung: Proxmox ist ein Hersteller auf Standard-HW. Standard-Lösungen für LXC und VM. Eher Professionelle Anwender mit Schulungen, weniger Community.

Docker: Eine Plattform, Myrriaden Container von Millionen Usern unterschiedlicher Fähigkeiten und Qualität. Eher SOHO ohne Schulung = viel Community. (weil sonst eher Kubernets?)
BTW: Und für Proxmox gibt es auch recht gute Foren und Doku von Proxmox selber