influxdb で grafana を使用して、カウンターである値の 1 秒あたりのレートを表示しようとしています。関数を使用するとnon_negative_derivative(1s)、レートの値は grafana ビューの時間幅に応じて大幅に変化するようです。セレクターを使用していますlast(ただし、カウンターなので同じ値を使用することもできますmax)。
具体的には、以下を使用しています:
SELECT non_negative_derivative(last("my_counter"), 1s) FROM ...
InfluxDB は時系列フィールド値の差を計算し、その結果を単位あたりの変化率に変換します。
つまり、私にとっては、時間ビューを拡大しても、特定の時点での値はそれほど変化しないはずです。単位あたりの変化率(上記の例のクエリでは 1 です)。
グラファイトでは、それらは特定のperSecond機能を持ち、より効果的に機能します。
perSecond(consolidateBy(my_counter, 'max'))
上記の流入クエリで何が間違っているのか、何かアイデアはありますか?
ベストアンサー1
変化しない 1 秒あたりの結果が必要な場合は、 を実行しますGROUP BY time(1s)。これにより、正確な結果が得られますperSecond。
次の例を考えてみましょう。
毎秒のカウンターの値が次のように変化すると仮定します。
0s → 1s → 2s → 3s → 4s
1 → 2 → 5 → 8 → 11
上記のシーケンスをどのようにグループ化するかに応じて、異なる結果が表示されます。
2s物事をバケットにグループ化する場合を考えてみましょう。
0s-2s → 2s-4s
(5-1)/2 → (11-5)/2
2 → 3
1sバケツとの比較
0s-1s → 1s-2s → 2s-3s → 3s-4s
(2-1)/1 → (5-2)/1 → (8-5)/1 → (11-8)/1
1 → 3 → 3 → 3
アドレッシング
つまり、私にとっては、値は単位あたりの変化率 (上記の私のサンプルクエリでは 1 秒) であるはずなので、時間ビューを拡大しても特定のポイントの値はそれほど変化しないはずです。
はrate of change per unit正規化係数であり、GROUP BY時間単位に依存しません。導関数の間隔を に変更した場合の前の例を解釈すると、2s何らかの洞察が得られる可能性があります。
正確な式は
∆y/(∆x/tu)
1s導関数区間が のバケットにグループ化する場合を考えてみましょう2s。結果は次のようになります。
0s-1s → 1s-2s → 2s-3s → 3s-4s
2*(2-1)/1 → 2*(5-2)/1 → 2*(8-5)/1 → (11-8)/1
2 → 6 → 6 → 6
これは少し奇妙に思えるかもしれませんが、これが何を言っているかを考えれば、意味がわかるはずです。微分間隔を指定する場合、2s私たちが求めているのはバケット2sの変化率です1s GROUP BY。
2s同様の推論を、導関数区間が であるバケットの場合に適用すると2s、
0s-2s → 2s-4s
2*(5-1)/2 → 2*(11-5)/2
4 → 6
ここで求めているのは、バケット2sの変化率がいくらであるかであり2s GROUP BY、最初の間隔では2s変化率は で4、2 番目の間隔で2sは変化率は になります6。