1

statsdを使用し、グラファイトの carbon-cacheで構成flushInterval: 1000および通信します。ごくまれにカウンターが見られるといいのですが。

カーボンには次の構成があります。

storage-schemas.conf:

[carbon]
pattern = ^carbon\.
retentions = 60:90d

[default_30s_for_1day]
pattern = .*
retentions = 30s:1d

そのように一意のカウンターを送信します。

$ echo "foobar:1|c" > /dev/udp/127.0.0.1/8125

statsdによって受信されたパケットを確認できます。

9 Jul 14:43:05 - DEBUG: foobar:1|c

Carbon-cache に送信されたデータ (tcpdump 抽出):

stats.foobar 1 1404909785

グラファイトで「foobar」のデータを見ると、その瞬間に何かが起こったことがわかります (細い線、図の赤い円を参照)、結果は常に「0」です。

ここに画像の説明を入力

何か不足していますか？

より頻繁な結果があれば、正しいように見える数値を確認できます。

考慮されるために送信される統計の最小量はありますか? 設定可能ですか？

注: このような時折のデータの場合、StatsD/Graphite は価値がないかもしれませんが、同じプロジェクトで非常に頻繁に収集されるデータが他にもあるため、いずれにせよそれらが使用され、稀なカウンターであっても 1 つの独自のソリューションを使用できることを願っています。

4

1 に答える 1

3

私のセットアップの問題は、flushInterval(1 秒) が最小の保持 (30 秒) よりも低かったことです。

毎秒 (私の場合: 30 秒)、 carbon-cache は結果を保存しますが、たとえば、秒 "10" でfoobarキーのカウント "1" が送信された場合、statsd はカウント "0" を毎秒送信します (より正確に言うと、すべての flushInterval) 後。これは、秒 "30" で、foobarの最後の値が "0" であることを意味します。値「1」が考慮される唯一の可能性は、それが秒「30」の直前の最新の瞬間に送信された場合です。

「0」を送信しないように statsddeleteIdleStatsまたはdeleteCounters設定を使用しなかったことを私が非難する可能性があります。しかし、そうすると、同じ 30 秒間に 2 回カウンターが「1」に設定されます。スロットは最初のカウンターに失敗し、「2」ではなく「1」のカウントが登録されます。

本当の解決策は、statsdflushIntervalを炭素の最小保持に合わせることです。

statsd config.js:

flushInterval: 10000

炭素の storage-schemas.conf:

retentions = 10s:1d,1m:30d,5m:90d
于 2014-07-09T16:18:50.240 に答える