Influxdb + Grafana: Nur Datenpunkte von heute

[Martin S. (sirnails)]

Hallo zusammen,

ich kämpfe mich gerade durch influxdb und grafana. Man kommt zwar 
schnell zu einem ersten Ergebnis, aber dann wird es auch sehr schnell 
sehr zäh.

Seit gestern abend kämpfe ich damit, dass ich mir aus den 
Leistungswerten des Zählers die Tagesmenge an negativem Strom aufzeigen 
möchte.

SELECT CUMULATIVE_SUM(mean) * -1 AS sum
FROM (
    SELECT MEAN("value") AS mean 
    FROM "Leistung (aktuell)"
    WHERE "value" < 0
    GROUP BY time(60m) fill(0)
)

Das tut zwar, was es soll, aber es fängt nicht bei 0 an (einerseits), 
und rechnet den Verbrauchswert zusammen im eingestellten Anzeigeinterval 
(andererseits).

Zumindest möchte ich dei Messwerte auf "Today so far" einschränken, was 
ja in den Anzeigenfiltern geht, aber scheinbar mit der influxql 
unmöglich scheint.

Die Funktion "today()" gibt es in der influxql nicht.

Ich hab mir die Finger wund gesucht, aber komme zu keinem Ergebnis. Ich 
kann aber auch nicht glauben, dass ich der erste bin, der etwas derart 
profanes umsetzen will.

Hat mir jemand eine Idee?

Vielen Dank.

[Martin S. (sirnails)]

Hab's aufgegeben. Das ganze Linux Zeug ist und bleibt immer irgendwie 
eine ziemliche Frickelei. Schade.

[Εrnst B. (ernst)]

Dann installier dir Influx und Grafana eben unter Windows.
Wird nicht weniger Gefrickel.

Von Influx lass ich die Finger nachdem die inzwischen gefühlt die fünfte 
Query-Sprache rausgebracht haben. Jede komplett anders und inkompatibel 
zur vorherigen...

[Ob S. (Firma: 1984now) (observer)]

Εrnst B. schrieb:

> Von Influx lass ich die Finger nachdem die inzwischen gefühlt die fünfte
> Query-Sprache rausgebracht haben. Jede komplett anders und inkompatibel
> zur vorherigen...

Zumal man alle mächtigen RDBMS heutzutage problemlos dazu bringen kann, 
das zu leisten, was Influx verspricht. Und das, ohne sich mit ständig 
neuen Abfragesprachen beschäftigen zu müssen.

Aber natürlich muss man sich mit dem jeweils verwendeten RDBMS 
beschäftigen. Das aber eben nur einmal. Danach kümmert sich das RDBMS 
selber um die Anpassungen, wenn es neue Versionen gibt (falls 
Optimierungen der Queries nötig werden). Die Anwenderseite, also 
insbesondere auch die Queries bleiben gleich.

[S. M. (lichtmensch)]

Today so far gibt es tatsächlich leider nicht. Hab ich auch versucht.
Lösung: bastel dir eigene Zähler in zb node-red die dann nur die zahl 
deiner wahl aufs dashoard sendet über last. so rechne ich auch die % 
autarkie aus und ähnliche dinge

[Ob S. (Firma: 1984now) (observer)]

S. M. schrieb:

> Today so far gibt es tatsächlich leider nicht.

Mein Gott, in jeder üblichen RDBMS drückt man das halt (sinngemäß) mit 
der Bedingung aus: Datensatz-Zeitstempel >= Datum(Jetzt).

Hängt natürlich vom RDBMS ab, wie genau das zu formulieren ist, aber 
wenn's einmal formuliert ist, wird es auch in zehn Jahren noch die 
erwarteten Ergebnisse liefern.

[Ein T. (ein_typ)]

Εrnst B. schrieb:
> Dann installier dir Influx und Grafana eben unter Windows.
> Wird nicht weniger Gefrickel.
>
> Von Influx lass ich die Finger nachdem die inzwischen gefühlt die fünfte
> Query-Sprache rausgebracht haben. Jede komplett anders und inkompatibel
> zur vorherigen...

...zumal das auf PostgreSQL aufbauende Timescaledb nach meinen 
Erfahrungen auch eine viel bessere Performance hat -- und man kann 
natürlich die ganze riesige Bandbreite dessen (weiter)nutzen, die 
PostgreSQL bietet.

[Andreas B. (bitverdreher)]

Ich frage mich auch was den TO dazu bringt, so eine exotische DB engine 
zu verwenden.
Was ist an MySQL oder PostgreSQL so schlecht?

[Vanye R. (vanye_rijan)]

> Hab's aufgegeben. Das ganze Linux Zeug ist und bleibt immer irgendwie
> eine ziemliche Frickelei. Schade.

Tut mir leid da widersprechen zu muessen, aber ich bin schon sehr frueh 
auf Linux umgestiegen, gleich damals als es nur 2-4Disketten gab. Also 
hab ich nun ueber 30Jahre Erfahrung damit. Es gibt nix bessers als Linux 
obwohl auch ich da durchaus was kritisiere wenn notwendig!

Aber Influx und ganz besonders Telegraf ist der Bodensatz der 
Programmierkunst. Selten hab ich etwas schlimmer zusammengebasteltes und 
so mies dokumentiertes gesehen. Das ist einfach eine Schande ohne 
gleichen. So zufrieden ich sonst mit Linux bin, aber bei dem Zeug 
bekomme ich Schaum vor dem Mund.

Also daraus nicht auf den Rest schliessen. .-)

Vanye

[Uwe B. (boerge)]

Moin,

Andreas B. schrieb:
> Was ist an MySQL oder PostgreSQL so schlecht?
...sind beide relationale Datenbanken; InfluxDB ist eine 
Zeitreihen-Datenbank --> also jede ist für das vorgesehene 
Anwendungsgebiet optimiert.

Vanye R. schrieb:
> aber ich bin schon sehr frueh
> auf Linux umgestiegen, gleich damals als es nur 2-4Disketten gab.

...27 Disketten

Vanye R. schrieb:
> Aber Influx und ganz besonders Telegraf ist der Bodensatz der
> Programmierkunst. Selten hab ich etwas schlimmer zusammengebasteltes und
> so mies dokumentiertes gesehen.

Also Influx ist, wie ich finde, sehr gut dokumentiert!
Bei Telegraf stimme ich dir, in punkto Doku, teilweise zu. Aber trotzdem 
finde ich das Ding, bezogen auf das Anwendungsgebiet, genial und erspart 
oft das Schreiben von eigenen Programmen oder irgendwelchen Flowes in 
NodeRed o.ä..

Grüße Uwe

[Andreas B. (bitverdreher)]

Uwe B. schrieb:
> InfluxDB ist eine
> Zeitreihen-Datenbank --> also jede ist für das vorgesehene
> Anwendungsgebiet optimiert.

Ja, und für alles andere fehlen scheinbar die Funktionen. ;-)

[Vanye R. (vanye_rijan)]

> Bei Telegraf stimme ich dir, in punkto Doku, teilweise zu. Aber trotzdem
> finde ich das Ding, bezogen auf das Anwendungsgebiet, genial und erspart
> oft das Schreiben von eigenen Programmen oder irgendwelchen Flowes in
> NodeRed

Ne, ich hatte irgendwann die Nase voll und pipe alles durch ein
C++ programm das ich selber geschrieben habe. Das ist einfacher!

Vanye

[Ein T. (ein_typ)]

Andreas B. schrieb:
> Ich frage mich auch was den TO dazu bringt, so eine exotische DB engine
> zu verwenden.

InfluxDB und Prometheus sind die meistgenutzten Backends für Grafana, 
und wenn das so viele benutzen, muß es doch die beste Lösung sein.

> Was ist an MySQL oder PostgreSQL so schlecht?

Naja, die haben einen anderen Fokus, in diesem Zusammenhang insbesondere 
die relationale Transaktionssicherheit, das drückt auf Ressourcen und 
Performanz. Für den Anwendungsfall eines Write-Append-Log, bei dem 
relationale Sicherheit keine Rolle spielt, sind Zeitseriendatenbanken, 
für analytische Anwendungen sind Columnar Stores (oder hybride) meistens 
besser geeignet. Nichtsdestotrotz läßt sich PostgreSQL ja mit einem 
hybriden Columnar Store aufrüsten, nämlich Timescale [1], so daß man das 
Beste aus beiden Welten erhält.

[1] https://www.timescale.com/

[Martin S. (sirnails)]

Andreas B. schrieb:
> Ich frage mich auch was den TO dazu bringt, so eine exotische DB engine
> zu verwenden.

Ganz einfach. Ich will Daten von meinem Tasmota Lesekopf visualisieren.

Was macht man also? Man googelt. Dann stolpert man über tausend Seiten 
und Youtube Videos, die entweder ioBroker oder Home Assistant empfehlen 
und dann ist man im Rabbit Hole, und bekommt gesagt, dass man die Daten 
per MQTT an ioBroker schicken soll, und der soll das dann an InfluxDB 
schicken und dort soll sich Grafana dann das Zeug holen.

Und ehe man sich versieht, hat man sich diese halbgaren Krücken an die 
Backe labern lassen und stellt fest, dass das alles doch irgendwie 
ziemlicher Murks ist.

Warum ich das Kasperle-Theater überhaupt mache?

Weil ich wissen will, wieviel Stom-Überschuss meine kleine 1,7kWp Solar 
macht, wieviel Strom jeden Tag ins Netz geht und was mir ein 2 kWh Akku 
bringen würde. Ob's sich jemals rentiert, ist für mich zweitrangig, aber 
ich möchte keinen Speicher hinstellen, der niemals voll wird.

Also brauche ich jetzt Daten und Fakten und die wollte ich mir halt auf 
diesem Weg für unseren Anwendungsfall beschaffen.

Im zweiten Schritt soll das Ding dann natürlich auch dafür tauglich 
sein, den Wechselrichter und/oder Akku zu steuern. Denn auch wenn wir 
"nurnoch" 32ct. pro kWh bezahlen, ist das immernoch weit mehr, als die 0 
ct., die ich für die Einspeisung bekomme, nur um dann kurz danach wieder 
zu beziehen.

Jetzt merke ich, dass selbst ein Pi5 mit InfluxDB und Grafana an seine 
Leistungsgrenze kommt und bin regelrecht enttäuscht davon, wie etwas 
überall so hochgelobt werden kann, wenn es dann doch so mies ist.

[Uwe B. (boerge)]

Moin,

Martin S. schrieb:
> Und ehe man sich versieht, hat man sich diese halbgaren Krücken an die
> Backe labern lassen und stellt fest, dass das alles doch irgendwie
> ziemlicher Murks ist.

Was ist denn Murks an InfluxDB und Telegraf?

Nebenbei, dein today()-Problem würde sich lösen, wenn du InfluxDB V2 
benutzen würdest:
--> https://docs.influxdata.com/flux/v0/stdlib/universe/today/

Martin S. schrieb:
> Jetzt merke ich, dass selbst ein Pi5 mit InfluxDB und Grafana an seine
> Leistungsgrenze kommt und bin regelrecht enttäuscht davon

Performance kannst du jetzt aber nicht meinen, oder hast du belastbare 
Zahlen. Mein "Telegraf-Influx-Grafana-Schrott" läuft hervorragend auf 
einem RPi4, auf dem auch noch anderes Zeugs läuft (sogar eine MariaDB 
;-)).

Grüße Uwe

[Ein T. (ein_typ)]

Martin S. schrieb:
> Was macht man also? Man googelt. Dann stolpert man über tausend Seiten
> und Youtube Videos, die entweder ioBroker oder Home Assistant empfehlen
> und dann ist man im Rabbit Hole, und bekommt gesagt, dass man die Daten
> per MQTT an ioBroker schicken soll, und der soll das dann an InfluxDB
> schicken und dort soll sich Grafana dann das Zeug holen.
>
> Und ehe man sich versieht, hat man sich diese halbgaren Krücken an die
> Backe labern lassen und stellt fest, dass das alles doch irgendwie
> ziemlicher Murks ist.

Wenn man das richtig macht, funktioniert das zweifellos sehr zuverlässig 
und wird...

> Jetzt merke ich, dass selbst ein Pi5 mit InfluxDB und Grafana an seine
> Leistungsgrenze kommt und bin regelrecht enttäuscht davon, wie etwas
> überall so hochgelobt werden kann, wenn es dann doch so mies ist.

... sicherlich weder einen RasPi 3, und erst Recht nicht einen RasPi 4 
oder 5, an seine Grenzen bringen. Da Dein Urteil allerdings schon 
festzustehen scheint und ich außerdem den Eindruck habe, daß Du mit 
Linux ähnlich inkompatibel bist wie mit mir, sollten wir uns Analysen 
und Lösungsansätze lieber sparen. Viel Erfolg beim Erarbeiten Deiner 
windowsbasierten Lösung.

[Martin S. (sirnails)]

Uwe B. schrieb:
> Nebenbei, dein today()-Problem würde sich lösen, wenn du InfluxDB V2
> benutzen würdest:
> --> https://docs.influxdata.com/flux/v0/stdlib/universe/today/

https://github.com/influxdata/influxdb/issues/22870

Ich nutze v2.

Uwe B. schrieb:
> Performance kannst du jetzt aber nicht meinen, oder hast du belastbare
> Zahlen.

Meinst Du den Lüfter vom PI, der hochdreht, während Firefox mit 15 
offenen Tabs auf dem PI5 mit 4GB noch funktioniert?

Ein T. schrieb:
> Wenn man das richtig macht, funktioniert das zweifellos sehr zuverlässig
> und wird...

Ja, dann sag mal, wieso today() mit influxql nicht funktioniert?

Ein T. schrieb:
> sollten wir uns Analysen
> und Lösungsansätze lieber sparen.

Weil Du selbst keine kennst?

Hau raus: Wie macht mit influxql die Abfrage der Daten des gleichen 
Tages (nicht der letzten 24 Stunden)?

[Εrnst B. (ernst)]

Martin S. schrieb:
> Wie macht mit influxql die Abfrage der Daten des gleichen
> Tages

Problem: Wann fängt ein Tag an? -> Zeitzone setzen.

Läuft so bei mir in "Flux", sammelt die Bezug/Einspeise-Summen pro Tag 
über den letzten Monat ($timespan).
Aber aus den Zählerständen, deshalb die "difference()"

            import "date"
            import "timezone"
    
            option location = timezone.location(name: "Europe/Berlin")

            from(bucket: "solar")
                |> range(start: date.truncate(t: -${timespan}, unit: 1d))
                |> filter(fn: (r) => ....)
                |> window(every: 1d)

                |> difference(nonNegative: true, columns: ["_value"])
                |> cumulativeSum(columns: ["_value"])

                |> last()
                |> duplicate(column: "_start", as: "_time")
                |> window(every: inf)
                |> pivot(columnKey: ["_measurement"], valueColumn: "_value", rowKey:["_time"])

Aber: "Flux is going into maintenance mode."... d.H. EOL.

Beim nächsten Projekt oder wenn ein größeres Rewrite ansteht, fliegt 
InfluxDB bei mir raus.

[Uwe B. (boerge)]

Martin S. schrieb:
> https://github.com/influxdata/influxdb/issues/22870
>
> Ich nutze v2.

...mit Flux oder mit FluxQl?
Siehe auch den einen Kommentar in dem Bug-Report ;-)

Martin S. schrieb:
>> Performance kannst du jetzt aber nicht meinen, oder hast du belastbare
>> Zahlen.
>
> Meinst Du den Lüfter vom PI, der hochdreht, während Firefox mit 15
> offenen Tabs auf dem PI5 mit 4GB noch funktioniert?

...ein "hochdrehender Lüfter" ist keine belastbare Zahl...; na dann 
erzähle mal, warum du meinst, dass der "hochdrehende Lüfter" von 
Influx/Telegraf verursacht wird...


Martin S. schrieb:
> Ja, dann sag mal, wieso today() mit influxql nicht funktioniert?

...weil es nicht für FluxQL implementiert wurde oder hast du dies in den 
entsprechenden Abschnitten der Doku so gelesen!

Grüße Uwe

[Martin S. (sirnails)]

Εrnst B. schrieb:
> Beim nächsten Projekt oder wenn ein größeres Rewrite ansteht, fliegt
> InfluxDB bei mir raus.

Und was würdest du stattdessen nehmen?

[Martin S. (sirnails)]

Uwe B. schrieb:
> Martin S. schrieb:
>> https://github.com/influxdata/influxdb/issues/22870
>>
>> Ich nutze v2.
>
> ...mit Flux oder mit FluxQl?
> Siehe auch den einen Kommentar in dem Bug-Report ;-)

InfluxQL, wie im Ausgangsbeitrag geschrieben.

> Martin S. schrieb:
>>> Performance kannst du jetzt aber nicht meinen, oder hast du belastbare
>>> Zahlen.
>>
>> Meinst Du den Lüfter vom PI, der hochdreht, während Firefox mit 15
>> offenen Tabs auf dem PI5 mit 4GB noch funktioniert?
>
> ...ein "hochdrehender Lüfter" ist keine belastbare Zahl...; na dann
> erzähle mal, warum du meinst, dass der "hochdrehende Lüfter" von
> Influx/Telegraf verursacht wird...

Nicht influx, sondern von Grafana. Das knüppelt mit den paar Anzeigen 
schon ordentlich aus.

> Martin S. schrieb:
>> Ja, dann sag mal, wieso today() mit influxql nicht funktioniert?
>
> ...weil es nicht für FluxQL implementiert wurde oder hast du dies in den
> entsprechenden Abschnitten der Doku so gelesen!

Genau. Aber warum nicht? Wie kann ein so wichtiger Befehl nicht 
implementiert sein?

[Uwe B. (boerge)]

Martin S. schrieb:
> Nicht influx, sondern von Grafana. Das knüppelt mit den paar Anzeigen
> schon ordentlich aus.

* Bei wieviel Panels pro Dashboard (bei dem er "ordentlich" 
ausknüppelt)?
* Bei wieviel Datenpunkten pro Panel auf dem Dashboard im gewählten 
Zeitintervall?
* Mit welchen Aggregatfunktionen werden die Daten in den Panels pro 
Anzeigeinterval zusammengefasst?

Und, aus deinen Bemerkungen höre ich raus, dass du alles (auch den 
Browser, mit dem du Dashboards des Grafana-Servers anzeigst; und damit 
incl. X-Umgebung, Desktop-Manager etc.) auf einem RPi betreibst. Kann 
man machen, sollte sich aber dann nicht beschweren, warum der Lüfter 
anspringt. Influx/Telegraf/Grafana(-Server) wird es höchstwahrscheinlich 
nicht sein...!

Martin S. schrieb:
> Genau. Aber warum nicht? Wie kann ein so wichtiger Befehl nicht
> implementiert sein?

...weil vielleicht die Influx-Entwickler die Notwendigkeit (in FluxQL) 
als nicht gegeben gesehen haben:
* (z.B.) Grafana könnte es ja...
* die Funktion today() in den "Nachfolge-Abfragesprachen" (Flux, ...) 
zur Verfügung steht

Grüße Uwe

[Ein T. (ein_typ)]

Martin S. schrieb:
> Ein T. schrieb:
>> Wenn man das richtig macht, funktioniert das zweifellos sehr zuverlässig
>> und wird...
>
> Ja, dann sag mal, wieso today() mit influxql nicht funktioniert?

Weil es diese Funktion in der Sprache InfluxQL für InfluxDB OSS Version 
2 nicht gibt. Die gibt es für diese Version nur im Cloud-Angebot.

>> sollten wir uns Analysen
>> und Lösungsansätze lieber sparen.
>
> Weil Du selbst keine kennst?

Mir sind mehrere sinnvolle Lösungsansätze bekannt, und einen habe ich in 
diesem Thread auch schon ausdrücklich erwähnt.

[Martin S. (sirnails)]

Gut dann wechsle ich zu Flux. Mal sehen, was das für einen Unterschied 
macht.

[Ein T. (ein_typ)]

Martin S. schrieb:
> Gut dann wechsle ich zu Flux. Mal sehen, was das für einen Unterschied
> macht.

Auch wenn es zur InfluxDB drölfzig Empfehlungen und Tutorials im Netz 
gibt, ist nicht ganz klar, wie sich das in Zukunft entwickeln wird. Die 
aktuelle Version 3 gibt es nur als "InfluxDB Core" mit deutlichen 
Einschränkungen. Wikipedia [1] berichtet dementsprechend, daß die neuen 
OpenSource-Angebote "limitiert" und keine vollständige 
Zeitseriendatenbank sei.

Mein ganz persönlicher Eindruck ist, daß die Investoren von InfluxDB 
jetzt langsam gerne einen ROI realisieren wollen und das 
OpenSource-Modell dafür keinen ausreichenden Gewinn abwirft. Auf den 
Webseiten von Influxdata wird möglicherweise deswegen sehr nachdrücklich 
dafür geworben, die Cloud- oder Managed-Angebote zu nutzen.

Ich ganz persönlich würde daher zumindest aktuell bei Neuentwicklungen 
nicht (mehr) auf InfluxDB setzen, sondern entweder auf die 
PostgreSQL-Erweiterung TimescaleDB setzen -- die den Vorzug hätte, daß 
vorhandene Kenntnisse in SQL und / oder PostgreSQL weiter genutzt werden 
können, und trotzdem Grafana für die Visualisierung weiterverwendet 
werden kann -- oder auf eine Kombination von Elasticsearch + Kibana oder 
OpenSearch + OpenSearch-Dashboards setzen.

[1] 
https://en.wikipedia.org/wiki/InfluxDB#InfluxDB_3_Limits_Open_Source_Offerings