Grafana und InfluxDB neben Edomi. Installation und Best Practice

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

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

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

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

[scw2wi]

Dann werd ich mal die vorhandene Doku als Einstieg nutzen.

[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

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

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!

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

[scw2wi]

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

[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

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

[gibsonrocker]

Kurze Antwort: Ja zu allem. Geht alles.

Edomi sollte aber besser auf dem NUC sein.

[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

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