Frage, Ausgabe von Grafana beschleunigen

Domi83

Rear Admiral
Registriert
Feb. 2010
Beiträge
5.307
Hallo in die Runde... Ich denke mal, dass Topic ist schon mal ein guter Ansatz und verrät ungefähr was ich möchte.

Ich versuche mal aufzuschlüsseln was ich habe und was genau ich mache...

Es gibt einen Server bei mir im Keller, auf dem läuft Proxmox als Basis.

Als virtuelle Maschine ist ein Volkszähler installiert, der mir die Daten meines Stromzählers mittels IR-Lesekopf aufließt und mittels seiner Middleware in seine MySQL Datenbank schreibt.

In einem separaten Container (Debian 10) ist der ioBroker, dort senden meine ganzen MQTT Geräte (Tasmota etc.) sowie Homematic und Fritz Geräte ihre ausgelesenen Werte hin. Der ioBroker schreibt das alles in eine MySQL Datenbank die in einem anderen Container liegt!

Nun holt Grafana (weiterer Container) alle Daten aus der MySQL Datenbank raus und generiert mir hier und da eine paar Auswertungen.

Ich habe also schöne Linien Diagramme (Time Series) für den Netzbezug in Watt, dann habe ich den Netzbezug noch einmal einzeln als Wert, genauso wie den Zählerstand (Gauge). Ebenfalls rufe ich die Ampere Werte von L1, L2 und L3 ab! Das alles kommt aus der MySQL Datenbank vom Volkszähler selbst.

Dazu kommt dann noch ein Diagramm (Time Series) von meinem PV Modul aus der MySQL Datenbank wo der ioBroker hinein schreibt.

Wenn ich nun "refresh dashboard" mache, kommt es oft vor dass die Aktualisierung der Werte bis zu 40 Sekunden dauert.

Irgendwo habe ich gelesen, dass das auslesen der Daten mittels MySQL schon mal länger dauern kann, aber 40 Sekunden empfinde ich nun als sehr lang. Zumal ich bis Sommer vergangenes Jahr in einem kleinen Unternehmen gearbeitet habe, wo wir MySQL Datenbanken für Webseiten haben die um einiges voller sind als meine paar Daten und die Ausgabe geht ruck zuck.

Wie kann man denn so etwas nun eventuell "tunen", vielleicht doch Grafana zwecks Auswertung inkl. der MySQL Datenbank in den gleichen Container und ioBroker sowie den Volkszähler dort hinein schreiben lassen, oder gibt es da noch andere Tipps / Ideen?

Gruß, Domi
 
Ich würde eher drüber nachdenken genau solche Zeitreihen in eine Zeitreihendatenbank wie InfluxDB zu stecken. Nutze InfluxDB und Grafana auf der Arbeit als kleines Test-Monitoring-Projekt für nen gutes Dutzend Server (also wesentlich mehr Daten als bei dir anfallen) und lasse das ganze auf nem Pi laufen. Grafana zeigt die Graphen quasi instant an.
 
  • Gefällt mir
Reaktionen: Skysnake, Der Lord, madmax2010 und eine weitere Person
Mysql ist dafür nicht das richtige DBMS, wie @kamanu schon schrieb: InfluxDB. Grafana bringt nicht umsonst Influx selber mit.

Domi83 schrieb:
Wie kann man denn so etwas nun eventuell "tunen",
Ja kann man, aber das ist halt dann nix für 0815.
 
  • Gefällt mir
Reaktionen: kamanu
Domi83 schrieb:
Irgendwo habe ich gelesen, dass das auslesen der Daten mittels MySQL schon mal länger dauern kann, aber 40 Sekunden empfinde ich nun als sehr lang. Zumal ich bis Sommer vergangenes Jahr in einem kleinen Unternehmen gearbeitet habe, wo wir MySQL Datenbanken für Webseiten haben die um einiges voller sind als meine paar Daten und die Ausgabe geht ruck zuck.
Das kann schon sein, dass MySQL in deinem Anwendungsfall "lahm" ist, weil die DB dafür nicht ausgelegt ist. Bei Messwerten hast du ja keine wirklich strukturierte Datenbank mit mehreren Tabellen, Beziehungen untereinander und auch keine passenden Indizes, sondern einfach nur ne Liste von Messwerten. Da geht MySQL im ungünstigsten Fall alle Einträge durch, um die gewünschten rauszusuchen.
 
  • Gefällt mir
Reaktionen: Skysnake, madmax2010 und kamanu
Wie definierst du denn "0815" :D

Was die InfluxDB angeht, ich habe mich für MySQL entschieden, da ich dort (durch meine anderen Anwendungen mit Homepages) dank HeidiSQL mal eben dort hinein schalten kann, Daten sichern oder Datensätze komplett entfernen kann die nicht benötigt werden oder weil ich einen Datenstrang neu anfangen möchte.

Gibt es so etwas auch für InfluxDB? Also so etwas wie einen PHP Client (phpMyAdmin) oder auch ein Programm wie HeidiSQL?

Spricht denn was dagegen, dass man dann die InfluxDB in einem separaten Container laufen lässt?

Ich müsste dann nur noch gucken, ob man eventuell die Daten vom Volkszähler ebenfalls in so eine InfluxDB bekommt, wenn das ganz dann performanter läuft.
 
Es spricht nix dagegen, die influx DB in einem eigenen Container laufen zu lassen.

Bei influx DB kannst du dann mit retention policies auch den Platzverbrauch fixieren und mittels continuous queries für unterschiedliche Zeiteinheiten (zb Tag, Woche, Monat, Jahr, ...) automatisch die Daten downsamplen lassen (min, max, avg, ...).

Und es scheint eine Konfiguration für Volkszahler und Influxdb zu geben.
 
Zuletzt bearbeitet:
ich habe Jahre lang Grafana mit influxdb genutzt ohne irgend einen plan von InfluxDB zu haben.
nimm die fertige config und gut ist :)
mySQL ist nicht was du fuer Zeitserien haben willst.
 
  • Gefällt mir
Reaktionen: Skysnake und playerthreeone
Ach... stimmt, jetzt wo ich das mit der InfluxDB und Volkszähler sehe, fällt mir ein dass ich das auch schon mal gesehen habe, aber weiterhin von MySQL angetan bin, weil ich das System halt schon kenne...

Aber ich kann ja noch mal einen Container für InfluxDB aufsetzen, diesen füttern lasen und schauen ob die Ausgabe dann "flotter" läuft. Das ganze würde ich dann aber wohl erst am Wochenende umsetzen, da ich diese Woche zeitlich ziemlich voll "geballert" bin :)

Wie gesagt... so an sich spricht nichts gegen InfluxDB, ich bin halt von MySQL so angetan, weil ich dank HeidiSQL "mal eben" hinein schauen kann um Datensetze daraus zu löschen, weil ich halt noch mal von vorne mit der Auswertung mit irgendwas starten will :D

Wobei, wenn es dann erst einmal läuft, kann das System da so lange hinein schreiben bis die DB platzt... Ich würde eventuell das ganze auf 2 Jahre begrenzen (das reicht wohl), aber pauschal sollte es passen, so dass ich viele viele Daten zur Verfügung habe.

Vielleicht mache ich es auch länger... da bin ich noch unentschlossen.
 
  • Gefällt mir
Reaktionen: kamanu
Domi83 schrieb:
Wie definierst du denn "0815"
Speziell aufs "Tuning" bezogen: du musst schon genau Queries analysieren können.
Und Mysql ist generell schlecht bei vielen Inserts. Dafür ist das einfach nicht gedacht.

Und da ich auch grad an solchen Geschichten (HoneyPi) für meinen Cheffe rumbastle. Hier ist PHP (so sehr ich es mag) einfach die falsche Sprache.

Domi83 schrieb:
einen Container für InfluxDB aufsetzen,
Wozu??? Eine Standard Grafana Install bringt Influx mit.

Domi83 schrieb:
so dass ich viele viele Daten zur Verfügung habe.
Sorry, aber du hast nicht die geringste Ahnung was "viele Daten" sind. So ein paar Zeitreihen jedenfalls nicht.

edit:
Aber grundsätzlich: wenn ein Query 1sec+ läuft: das Query ist schlecht, die Indizies sind schlecht, die DB ist schlecht (geplant), die grundlegende Idee ist schlecht.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: madmax2010
Wenn Du eine Frage zu MySQL stellst und dabei Zeitreihen im Spiel sind, wird im Forum die Antwort immer InfluxDB lauten. Und die könnte sogar in den meisten Fällen richtig sein.

Schön dass Du einen Zugriff mit HeidiSQL hast.
Nicht selten liegt mangelnde Performance an einer inadäquaten Indizierung (weil die MySQL-Defaults für Caching für kleine DBs selten zu geizig sind).
Öffne Deine Datenbank und schreib show status like 'slow_queries%' in einen Query Tab.

Falls die Antwort grösser als Null ist, hast Du vllt. schon die Antwort. Schalte slow queries logging ein, falls noch nicht geschehen; findest online alles dazu, wie die slow queries ausgewertet/interpretiert werden können (hint: explain select dings from bums).
Oft reicht es, den einen oder anderen Index zu tweaken oder hinzuzufügen, damit ein ausschlaggebender Select ausschliesslich auf Indizes arbeitet und schlagartig in Sekundenbruchteilen abläuft, während er vorher einen "full stroke" auf eine oder mehrere Tabellen machen musste und dabei viel Zeit verschwendet hat.
 
  • Gefällt mir
Reaktionen: Der Lord und madmax2010
Phrasendreher schrieb:
Öffne Deine Datenbank und schreib show status like 'slow_queries%' in einen Query Tab.
Yupp... bringt nur gar nix, wenn man slow query log nicht an hat (und Standard ist off).
Bitte...

Phrasendreher schrieb:
Oft reicht es, den einen oder anderen Index zu tweaken oder hinzuzufügen
Wenn man nicht weiß was man tut, erhöht man damit nur die DB-Last.
 
Domi83 schrieb:
aber weiterhin von MySQL angetan bin, weil ich das System halt schon kenne...
ist aber halt das falsche fuer den job

Domi83 schrieb:
Gibt es so etwas auch für InfluxDB? Also so etwas wie einen PHP Client (phpMyAdmin) oder auch ein Programm wie HeidiSQL?
pls dont. phpmyadmin nackt im netz ist eine schlechte Idee.
Und schau auch, dass mysql nicht ohne weiteres aus dem Internet erreichbar ist. Pack das bitte in wireguard o.ae.

Du lässt aber schon sudo mysql_secure_installation laufen wenn du irgendwo mysql installierst?

Domi83 schrieb:
Wobei, wenn es dann erst einmal läuft, kann das System da so lange hinein schreiben bis die DB platzt...
Die db platzt nicht einmal wenn du ein paar Jahre Lang hunderttausende writes per second hast. bei dir sind es ja wohl eher wenige writes pro minute?

Wenn wir eh schonmal bei Influx unterwegs sind:
eigentlich brauchst du mit Influx 2.x auch kein Grafana mehr. Chronograf ist das Webfrontend für Influx. Inklusive Dashboard.

playerthreeone schrieb:
PHP (so sehr ich es mag)
Bis eben mochte ich dich :P
playerthreeone schrieb:
(HoneyPi) für meinen Cheffe
Hier wirds interessant :)
 
  • Gefällt mir
Reaktionen: playerthreeone
playerthreeone schrieb:
Wozu??? Eine Standard Grafana Install bringt Influx mit.
Hab ich doch schon erwähnt... Vzlogger (Volkszähler) schreibt in eine Datenbank, ioBroker schreibt in eine Datenbank, Grafana ruft das alles ab. Insgesamt sind es vier Container im Proxmox.

Ja, ein "Standard Grafana" bringt das mit... hört sich mein Setup nach "Standard" an? ;)

Phrasendreher schrieb:
Wenn Du eine Frage zu MySQL stellst und dabei Zeitreihen im Spiel sind, wird im Forum die Antwort immer InfluxDB lauten. Und die könnte sogar in den meisten Fällen richtig sein.
Du, ich sagte auch nicht dass ich mich gegen InfluxDB stelle! Ich erklärte nur, warum ICH MySQL gewählt habe und nicht InfluxDB :)

madmax2010 schrieb:
ist aber halt das falsche fuer den job
Ich haue in meinen Datenbank Container noch mal ne InfluxDB rein, lasse diese füttern (hab ich eben schon für ioBroker erledigt), am Wochenende soll Vzlogger noch dort rein schreiben, dann baue ich mir das mit Grafana ohne MySQL auf und schaue mal wie die Ladezeiten sind :)

madmax2010 schrieb:
pls dont. phpmyadmin nackt im netz ist eine schlechte Idee.
Zu viel hinein interpretiert oder beim Lesen Brücken gebaut wo keine sind... hier steht nichts "nackt" im Netz, von daher alles gut ;) Und was MySQL im Netz angeht, meine Server in den Rechenzentren (nein, nicht mein Proxmox Server, der steht im Keller) sind "abgehärtet" (schönes Wort) :D

Bis hierhin schon mal vielen Dank für die Ideen, Tipps und Anregungen an alle... wie gesagt, hab InfluxDB schon mal vorbereitet... und wie gesagt, MySQL hatte ich gewählt weil ich dort dank HeidiSQL mal eben meine Daten über eine GUI bearbeiten kann, aufräumen etc.

Nachtrag1:
playerthreeone schrieb:
Sorry, aber du hast nicht die geringste Ahnung was "viele Daten" sind. So ein paar Zeitreihen jedenfalls nicht.
Interessant dass du das so behaupten / feststellen kannst. Ich glaube ich kann sehr gut behaupten was "viele" Daten sind. Es ist immer eine Relation! Ich habe in meinem alten Unternehmen mit "vielen" Daten gearbeitet (MySQL Datenbanken) und da wo ich jetzt bin, habe ich mit "noch mehr" Daten zu tun :D

Es ist aber halt immer eine Relation :D

Nachtrag2: Moin, nun sind zwar erst knapp 17 Std. rum, bis zu einem bestimmten Zeitpunkt liefen ja die MySQL Abfragen auch noch recht schnell / zügig, aber die InfluxDB scheint die Daten irgendwie anders abzulegen. Vielleicht schaue ich mir am Wochenende (oder bei nächster Gelegenheit) auch mal InfluxDB2... aber alleine InfluxDB hat schon einen ordentlichen Schubs gebracht. Ein weiteres Update gibt es dann in ein paar Tagen bezüglich der Performance, vielleicht interessiert das auch andere User.
 
Zuletzt bearbeitet:
madmax2010 schrieb:
Wenn wir eh schonmal bei Influx unterwegs sind:
eigentlich brauchst du mit Influx 2.x auch kein Grafana mehr. Chronograf ist das Webfrontend für Influx. Inklusive Dashboard.
Chronograf gibt es auch bei der ersten Influxdb Generation schon. Grafana hat aber schon das Alerting dabei, das man beim 1er Influx über Kapacitor erledigen muss. Zudem kann Grafana viele Quellen und auch bezüglich der Visualisierung ist es netter. Ganz zu schweigen, das man bei Grafana direkt sicheren Zugriff und sogar Multitenant bekommt. Bei Kapacitor ist erstes ein Krampf und zweites unmöglich ohne Influxdb Geld in den Rachen zu werfen. Es gibt also gute Gründe für Grafana.

Ich würde Chronograf aber zum Debuggen und administrieren weiter laufen lassen. Man sieht z.b. die querries in einem Tab.

Wenn Indluxdb dann aber bitte gleich auf Influxd2 gehen und FLUX als querry language verwenden. Influx1 wird zwar noch lange supported, aber nicht ewig und die neue Version ist inzwischen lang genug abgehangen das man es nutzen kann. Meiner Meinung nach zumindest.

@Domi83 ich arbeite mit Influxdb Instanzen die TB groß sind. Und selbst eine einzelne DB hat da durchaus hunderte GB. Das geht trotzdem so schnell die ne 10MB DB, so lange man den gleichen Zeitraum betrachtet. Influxdb als ZeitserienDB arbeitet da einfach anders als ne relationale DB.

Selbst wenn die Querries machst die über Monate für tausende von Inputs mit alle paar Sekunden nen neuen Wert, bist du in unter einer Minute durch. Selbst bei voller Auflösung für Grafana. Die Anzeige dauert dann aber schon mal 5 Minuten. Das liegt aber nicht an der DB sondern Single core Last vonChronograf oder Grafana...
 
  • Gefällt mir
Reaktionen: Domi83 und madmax2010
Ist Chronograf somit ein phpmyadmin mit Dashboard feature? Gibt es für Influxdb ein phpmyadmin?
 
Andi_bz schrieb:
Ist Chronograf somit ein phpmyadmin mit Dashboard feature? Gibt es für Influxdb ein phpmyadmin?
Chronograf ist das vollständige Frontend für influx. Ja, gehen queries drin, aber auch noch viel mehr.
Administrations Features gibts aber auch erst seit 2.X
Und wie immer: bitte kein PHPMyAdmin nackt ans Netz. Laufende Sicherheitslücke.

Skysnake schrieb:
Chronograf gibt es auch bei der ersten Influxdb Generation schon. Grafana hat aber schon das Alerting dabei, das man beim 1er Influx über Kapacitor erledigen muss. Zudem kann Grafana viele Quellen und auch bezüglich der Visualisierung ist es netter. Ganz zu schweigen, das man bei Grafana direkt sicheren Zugriff und sogar Multitenant bekommt. Bei Kapacitor ist erstes ein Krampf und zweites unmöglich ohne Influxdb Geld in den Rachen zu werfen. Es gibt also gute Gründe für Grafana.
Joa. das alerting finde ich in grafana im Handling.. urgh :D In Chronograf mag ich es ganz gern, habe aber eig. alles in Prometheus liegen :D.
Kapacitor: Full ack. Hach Influx ist schon sehr Enterprise geworden :/
Grafana Multitenant: mega angenehm :)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Andi_bz
Skysnake schrieb:
@Domi83 ich arbeite mit Influxdb Instanzen die TB groß sind.
Joa... Das ist mal ne Hausnummer :D Ich glaube im TB Bereich (auf MySQL Basis) bin ich noch nicht, aber das Thema MySQL ist ja nun erst einmal vom Tisch. Aktuell schreibt der ioBroker noch in meine MySQL Datenbank UND in meine InfluxDB (aktuell noch Version 1, weil die Repos vom Debian 11 Container den angeboten hatten), aber ich kann mir ja die Tage neue Quellen hinterlegen und InfluxDB in der Version 2.x installieren. Dass sollte auch klappen :)

madmax2010 schrieb:
Und wie immer: bitte kein PHPMyAdmin nackt ans Netz.
PHPMyAdmin sollte auch nur irgend so ein Beispiel sein, weil es das erste Programm war welches mir eingefallen war :D Auf meinen root Servern hab ich PHPMyAdmin entweder gar nicht drauf oder auf den Boxen wo ich zu faul war mir alles schön zu machen, hab ich es durch irgend ein Leitfaden mit installiert und anschließend via httpd.conf vom Apache für alle IP's auf "deny" gesetzt damit dort Ruhe ist. Es gibt ja auch zig Anleitung zum härten von Servern.

Mein Proxmox Server steht im Keller (Home Office) und der einzige Port der von Extern in das Netz kommt, ist der VPN Port. Dürfte für den haushaltsüblichen Anschluss ausreichend sein.

Joa... mehr fällt mir gerade nicht ein :D
 
  • Gefällt mir
Reaktionen: kamanu
Also, einmal ein Feedback... Ja, mit der InfluxDB läuft das alles wesentlich zügiger. Ich hab zwar ab und an mal das Phänomen, dass Grafana "no data" sagt, sobald ich dann aber einfach dieses "refresh" Symbol drücke, sind die Werte wieder da.

ioBroker schreibt in eine InfluxDB und für den Vzlogger vom Volkszähler habe ich eine separate InfluxDB (oder Tabelle) erstellt.

Jetzt wäre allerdings noch eine Sache interessant, die aber Off-Topic wäre, vielleicht weiß das einer (falls das geht)... der Volkszähler (Vzlogger) schreibt ja immer den Momentanverbrauch sowie den Zählerstand in meine InfluxDB... kann ich mir mit diesen Daten nicht sogar ein Balkendiagram in Grafana erzeugen, welches mir im Stunden, 12 Std., oder sogar Tages Zyklus den Verbrauch zeigt?!

So dass ich nach einer Zeit von X dann mal gucken kann "ah, im Mai habe ich an den Tagen pro Tag X kWh verbraucht", dass müsste doch gehen... oder irre ich mich?!

p.s. Ich hab noch was vergessen... ich wollte mit InfluxDB2 arbeiten... als ich dann aber Grafana gesagt habe "hey, lies mal aus", hätte ich wieder ganze SQL Query bauen müssen. Das wollte ich dann aber auch nicht. InfluxDB Version 1 tut es, dass reicht. Und ja, ich möchte das alles im Grafana haben, weil ich darin ja noch andere Dinge als den Verbrauch oder Einspeisung des BKW visualisiere.
 
Zurück
Oben