Wie bekomme ich konsistente Werte mit influxdb non_negative_derivative?
Mit grafana mit influxdb, ich versuche zu zeigen, die pro Sekunde von einigen Wert, ist ein Zähler. Wenn ich die non_negative_derivative(1s)
Funktion, der Wert der rate scheint sich dramatisch ändern, je nach der Zeit, die Breite der grafana-Ansicht. Ich bin mit der last
selector (könnte aber auch verwenden max
das ist der gleiche Wert, da es einen Zähler).
Speziell, ich bin mit:
SELECT non_negative_derivative(last("my_counter"), 1s) FROM ...
Entsprechend der influxdb docs nicht-negativ-Derivat:
InfluxDB berechnet die Differenz zwischen chronologischen Feld-Werte und wandelt diese Ergebnisse in der rate änderung pro Einheit.
So zu mir, das bedeutet, dass der Wert an einem bestimmten Punkt nicht geändert werden sollte, dass viel, wenn die Erweiterung der time-Ansicht, da der Wert sollte rate der änderung pro Einheit (1s-in meinem Beispiel-query oben).
In Graphit-Sie haben die spezifische perSecond
- Funktion, die funktioniert viel besser:
perSecond(consolidateBy(my_counter, 'max'))
Irgendwelche Ideen auf, was ich falsch mache mit dem Zustrom obige Abfrage?
Du musst angemeldet sein, um einen Kommentar abzugeben.
Wenn Sie möchten pro Sekunde, Ergebnisse, die nicht variieren, Sie wollen
GROUP BY time(1s)
. Dies wird Ihnen genaueperSecond
Ergebnisse.Betrachten Sie das folgende Beispiel:
Angenommen, dass der Wert des Zählers an jede Sekunde verpasst, wie so
Je nachdem, wie wir die Gruppe die Reihenfolge oben, sehen wir unterschiedliche Ergebnisse.
Betrachten wir den Fall, wo wir die Gruppe, die Dinge in
2s
Eimer.gegen die
1s
EimerAdressierung
Den
rate of change per unit
ist eine Normalisierung der Faktor, unabhängig von derGROUP BY
Zeiteinheit. Die Interpretation unserer vorherigen Beispiel, wenn wir ändern die Ableitung Intervall2s
bieten einige Einblicke.Die genaue Gleichung ist
Betrachten wir den Fall, wo wir die Gruppe, die Dinge in
1s
Eimer mit einem Derivat Intervall von2s
. Das Ergebnis, das wir sehen sollten, istDies mag ein wenig seltsam, aber wenn man bedenkt, was dieser sagt, es sollte Sinn machen. Wenn wir angeben, eine Ableitung Intervall von
2s
was wir Fragen, ist, was die2s
rate der änderung ist für die1s
GROUP BY
Eimer.Wenn wir ähnliche Argumentation auf den Fall von
2s
Eimer mit einem Derivat Intervall von2s
ist dannWas Fragen wir denn hier, ist was die
2s
rate der änderung ist für die2s
GROUP BY
Eimer und in der erste Intervall der2s
rate der änderung wäre4
und das zweite Intervall der2s
rate der änderung wäre6
.@Michael-Desa gibt eine ausgezeichnete Erklärung.
Möchte ich ergänzen, dass die Antwort mit einer Lösung zu einem Recht gängigen metrischen unser Unternehmen ist interessiert an: "Was ist der maximale "operation pro Sekunde" - Wert auf einem bestimmten Messbereich?".
Werde ich ein real-life Beispiel aus unserem Unternehmen.
Szenario Hintergrund
Senden wir eine Menge von Daten von einem RDBMS zu redis. Bei der übertragung von Daten verfolgen wir 5 Zähler:
TipTrgUp
-> Updates von einem business-trigger (stored procedure)TipTrgRm
-> Entfernt von einem business-trigger (stored procedure)TipRprUp
-> Updates von einem unbeaufsichtigten auto-Reparatur-batch-ProzessTipRprRm
-> Entfernt von einem unbeaufsichtigten auto-Reparatur-batch-ProzessTipDmpUp
-> Updates durch ein bulk-dump-ProzessMachten wir eine Metrik-Collectors, sendet den aktuellen Zustand dieser Zähler auf InfluxDB, mit einem Intervall von 1 Sekunde (einstellbar).
Grafana Grafik 1: niedrige Auflösung, nicht wahr max ops
Hier ist die grafana-Abfrage, die nützlich ist, aber nicht die wahre max ops beim verkleinern (wir wissen, es geht um rund 500 ops an einem normalen Werktag, wenn keine speziellen Deponien oder Wartung stattfindet - sonst geht es in die Tausende):
Sidenotes:
$rp
ist der name der Aufbewahrungsrichtlinie, Vorlagen in grafana. Wir verwenden CQ ' s zur Neuberechnung von Aufbewahrungsfristen mit einer größeren Dauer. Beachten Sie auch die1s
als abgeleitete parameter: es ist erforderlich, da der Standard unterscheidet bei der Verwendung von GROUP BY. Dies kann leicht übersehen werden in der InfluxDB Dokumentation.Diagramm, gesehen von 24 Stunden sieht so aus:
Wenn wir einfach nur verwenden Sie eine Auflösung von 1s (vorgeschlagen von @Michael-Desa), eine enorme Menge von Daten übertragen von influxdb an den client. Es funktioniert auch Recht gut (über 10 Sekunden), aber zu langsam für uns.
Grafana Grafik 2: niedrige und hohe Auflösung, true max-ops, langsam
Wir können jedoch Unterabfragen hinzufügen, um die wahre maxops zu dieser graph, das ist eine leichte Verbesserung. Viel weniger Daten an den client übertragen, aber die InfluxDB-server zu tun hat, eine Menge Zahlenverarbeitung durchführen. Serie B (mit
maxops
vorangestellt, in der alias):Gibt:
Grafana Grafik 3: niedriger und hoher Auflösung, true max-ops, high-performance, pre-Berechnung von CQ
Unsere endgültige Lösung für diese Art von Metriken (aber nur, wenn wir müssen eine live-Ansicht, die Unterabfrage Ansatz funktioniert gut für ad-hoc-Diagramme) ist: verwenden Sie eine Kontinuierliche Abfrage, pre-Berechnung der wahren maxops. Wir generieren CQ ist wie diese:
Ab hier ist es trivial, diese zu verwenden, maxops Messungen in grafana. Beim downsampling auf einem RP mit längerer Verweildauer, die wir wieder verwenden
max()
als Selektor-Funktion.Serie B (mit
.maxops
angehängt in der alias -)Gibt:
Wenn vergrößert 1s Präzision, können Sie sehen, dass die Diagramme identisch sind:
Hoffe, das hilft, TW
Hier das problem, dass die
$__interval
Breite ändert sich je nach den zeitlichen Rahmen, die Sie anzeigen, in Grafana.Dem Weg dann um konsistente Ergebnisse zu erhalten, ist eine Probe aus jedem Intervall (
mean()
,median()
odermax()
alle funktionieren gleich gut) und wandeln sich dann durchderivative($__interval)
. Damit ist Ihre Ableitung änderungen übereinstimmen, das Intervall Länge, wie Sie zoom in/out.Also, deine Abfrage Aussehen könnte: