@peterthiemer fragte mich gerade, wie man die schönen Tagesdifferenzen macht, die als Balken zusätzlich zum normalen Liniendiagramm des Gewichts, etwa hier angezeigt werden:
Toll finde ich die Gewichtsprotokoll von Freiland Potsdam, wo die negativen und positiven Veränderungen angezeigt werden.
Zuerst sollte man das automatisch angelegte dashboard unter anderem Namen nochmals speichern.
In unserem Fall gehe ich auf das dashboard mit dem Namen
hiveeyes open-hive-peter automatic
und gehe über die dashboard-Konfiguration (bei Grafana am oberen Rand das Zahnrad-Icon) und wähle dort dann in der linken Spalte “save as” (aus unerfindlichen Gründen geht das nicht über den normalen “save”-Dialog mit dem Disketten-Icon) hier wähle ich als Namen z.B.
Open Hive: Peter
Im neuen Dashboard gehe ich nun beim Panel mit den Gewichtsdaten auf edit
… nach dem Wechsel auf die Karteikarte “Metrics” wähle ich “Add Query”. Bei “FROM” trage ich nun die gleiche Datenbank / “Tabelle” wie beim Gewicht ein, bei SELECT als field “Gewicht” oder “weight” - je nachdem wie es benannt wurde. mean() löscht man und trägt statt dessen als Selector “last()” ein, dann als weiteres Feld Transformation “derivative” und gibt händisch als Intervall 1d ein. In der nächsten Zeile gibt man bei GROUP BY ebenfalls 1d ein.
Nun geht man zurück aufs dashboard (Icon ganz oben rechts) und sieht nun schon eine zweite Linie, die wollen wir aber noch als Balken haben und mit einer zweiten y-Achse, die eine andere (geringere) Skalierung hat: Das Ganze kann man über das tab “Display” einstellen, dort generiert man eine Ausnahme unter “Series override” und zwar sollen für die Differenzen Balken (bars) statt Linien angezeigt werden und eben die zweite y-Achse, die wir vorher unter “Axes” noch aktivieren müssen.
Nachtrag: @weef weist noch darauf hin, dass es sich anbietet, die metric der Balken mit display / series overrides mittels “Z-index -1” hinter die Linie zu setzen, damit die Balken nicht willkürlich partiell die Linie überdecken. Beispiel hier (Peter): Grafana
Vielen Dank für die ausführliche Beschreibung!
Wollte noch darauf hinweisen, daß @thias und @einsiedlerkrebs verschiedene Verfahren für die Differenzbalken verwenden:
derivative(last("weight"), time) , unddifference(mean("weight"))
Beide fassen die Werte dann zusammen GROUP BY time(time), nicht als Variable, sondern explizit, z.B 30m oder 1d. Hier mal beide Verfahren zum Vergleich, gruppiert zu 1d, auf den selben Daten (Daten von @mhies) - hellgrün: difference, dunkelgrün: derivative
(ani-gif)
Der Effekt ist, daß unterschieden wird, z.B. bei 1d-grouping, welchem Tag ein Saldo zugeschrieben wird, da die linke obere Ecke des Balken immer links beim Beginn der entsp. Zeiteinheit anfängt (er läßt sich auch nicht anders positionieren). Man sieht dies gut am 30.3. aufgrund des Zuwachses in der zweiten Tageshälfte. Der Saldo beider Tabellen ist daher auch nicht ganz identisch, da vom letzten Zeitraum links und in dem angrenzenden Zeitraum rechts immer etwas ‘fehlt’ bzw. dazugeschlagen wird.
Was man nun verwendet, hängt von Geschmack und Vorlieben ab (außer, es erklärt jemand, daß eine Variante davon mathematisch Blödsinn ist). Stellt sich die Frage, was davon wir bei den automatic dashboards anlegen wollen…
Das ‘Problem’ haben wir bei den Wetterdaten auch gerade, z.B. bei nur täglich gelieferten Werten, die zur Tagesmitte kommen…
Ich würde für konstante Werte pro Tag plädieren, das andere ist zwar kein mathematischer Blödsinn aber aus Usability-Gründen denke ich ist die Erwartungskonformität, dass sich Differenzen pro Tag nicht nach einem Tag wieder ändern.
Na, sie ändern sich ja nicht einfach so. Es bleibt lediglich die Frage, wann sie wo angezeigt werden: Erwartungskonformität hin oder her, wenn ich das Ergebnis des jetzigen Tages sehen will, dann muß per Definition dieser schon beendet sein, damit dessen 24 Stunden dort voll zählen können.
Außerdem muß das Programm eine Annahme darüber haben, wo derart gewonnener Wert angezeigt wird: in jenem Tag, aus welchem die Werte stammen, oder erst am Ort des letzten Zeitstempel dieses Tages. Jede median-Linie über einen (1) Tag zeigt den dazugehörigen Wert erst am Ende des Tages an, und nicht als 24h oder 12h vorher.
Das Bild (ani gif) hier ist mit “last 7 days” erzeugt worden, da es vor 24 Uhr ist, wird in der FLUX-Version dieses queries der Wert von heute früher angezegt als eigentlich möglich.
(Daten von @peterthiemer, die hellgrünen bars sind auf @thias’ Methode (derivative(last(…), 1d) erzeugt worden, nach zuvor @einsiedlerkrebs’ Methode (diff(mean(), group (1d) - direkter Vergleich siehe oben). Derivative() einmal in InluxQL (hellgrün) und einmal in FLUX (die zweifarbigen; von @wtf hier beschrieben) gebaut:
derivative() ist in influxQL anders als in FLUX, und da das grouping ohnehin anders ist, haben wir’s noch nicht ganz identisch. - Den Unterschied am 1.4. zwischen den Ergebnissen der beiden queries kann ich noch nicht erklären…
Wichtigster Unterschied ist, daß wir im FLUX (noch?) nicht mit jenem derivative(last(…)… arbeiten, wir haben an der vergleichbaren Stelle ein mean(). Dafür können wir in FLUX nun dieses shift(shift: -1d) verwenden, welches den für den Tag ermittelten Saldo nun in jenen Tag schreibt, in welchem der entstanden ist, und nicht -nach dessen Beendigung- an den Tagesanfang des Folgetages.
An der FLUX-Variante gefällt mir (neben der Zweifarbigkeit ;) ) , daß man sieht, daß der letzte Tag des Zeitraums, nämlich heute, noch nicht zuende ist, dann zeigt Grafana den Tageswert früher an. Eine willkommene Funktion, oder ein Fehler… ;)
