Whisper / Graphiteのディスク容量計画

データポイントごとにグラファイトが使用するディスク容量を見積もるのに役立つ数式や環境からのサンプルデータはありますか？

whisper-info.py ファイルのサイズなど、各ファイルがどのように、どのように集約されるかについて多くの洞察を与えます。

ただし、既存のウィスパーファイルにのみ役立ちます。

スキーマを適切な場所に配置する前に予測的なサイズ変更を確認したい場合は、https：//gist.github.com/jjmaestro/5774063で入手できるようなウィスパー電卓を試してください。

編集：

例が求められたら...

storage_schema：

{
    :catchall => {
      :priority   => "100",
      :pattern    => "^\.*",
      :retentions => "1m:31d,15m:1y,1h:5y"
    }
}

私のファイルを見てみるとapplied-in-last-hour.wsp、ls -l利回り

-rwxr-xr-x 1 root root 4415092 Sep 16 08:26 applied-in-last-hour.wsp

とwhisper-info.py ./applied-in-last-hour.wsp収量

maxRetention: 157680000
xFilesFactor: 0.300000011921
aggregationMethod: average
fileSize: 4415092

Archive 0
retention: 604800
secondsPerPoint: 10
points: 60480
size: 725760
offset: 52

Archive 1
retention: 2678400
secondsPerPoint: 60
points: 44640
size: 535680
offset: 725812

Archive 2
retention: 157680000
secondsPerPoint: 600
points: 262800
size: 3153600
offset: 1261492

したがって、基本的には、統計ごとに保持期間ごとに保持一致ごとにホストを組み合わせ、これも適用するシステムの係数を掛け、追跡する新しい統計の数を考慮します。次に、どんな容量のストレージを使用しても、少なくとも2倍にします（ストレージを購入し、使用することがわかっているため...）

statsd のドキュメントでは、データ保持ポリシーの例を示しています。

保持10s:6h,1min:7d,10min:5y期間は2160 + 10080 + 262800 = 275040データポイントであり、アーカイブサイズは3.2 MiBです。

線形関係を仮定すると、これはデータポイントあたり約12.2バイトになります。

Graphiteを直接使用した経験はありませんが、Cactiに使用したのと同じロジック、またはRRDまたはタイムロールオーバードリブンが適用されるものと同じだと思います（Graphiteは内部でRRDを使用しなくなりましたが、ストレージロジックは同等のようです）

簡単な答えは、「おそらくあなたが必要だと思うほど多くのスペースはない」ということです。

長い答えには、サイト固有の数学が含まれます。監視システム（InterMapper）では、保持期間、解像度、データポイントサイズを把握し、複数の乗算を行い、オーバーヘッドを追加します。

例として、ディスクスペースを使用します。30日間は5分間の精度、さらに60日間は15分間の精度、さらに300日間は1時間単位の精度で数値を保存し、64 -bit（8バイト）整数で保存します：

• 合計21600サンプル、以下のように分類されます。
  • 30日間の5分間の精度のための8640サンプル
  • 60日間15分の精度で5760サンプル
  • 300日1時間の精度で7200サンプル

サンプルあたり8バイトの約173KBに加えて、ストレージインデックス作成などの健全なオーバーヘッドにより、1つのパーティションのディスク使用量データに対して約200KBになります（過大評価の傾向があるエラー）。

基本メトリックから、「マシンあたりの」平均サイズ（10個のディスクパーティション、スワップ領域、RAM、負荷平均、ネットワーク転送など）を計算できます。マシンあたり約5MBになります。

また、最終的な数値の上に健全な10％を追加して切り上げたので、マシンごとに6MBのサイズにします。

次に、チャート用のメトリックデータを保存するために配置した1TBの​​スペースを見て、「ええ、私たちが大きく成長しない限り、おそらく一生の間にストレージを使い果たすことはないでしょう！」と言います。:-)

多くのデータを生成する70のノードがあります。Carbon / Whisperを使用して、1つのノードが91kファイルのみを作成しました（ノードは、選択可能な複数のカウンターと変数フィールドを持つ複数のスキーマを生成します。例：（nodename）。（schema）。（counter）。（subcounter）。（etc ）....等々）。

これにより、必要なグラフをプロットするために必要な粒度が提供されました。スクリプトを実行して残りの69ノードにデータを入力した後、ディスクに1.3Tbのデータがありました。そして、それはたった6時間分のデータ/ノードです。私が得るのは、6時間分のデータの実際のフラットなcsvファイルが約230MB /ノードであるということです。70ノードは、最大16Gbのデータです。私のストレージスキーマは120s：365dでした。

私はデータベースが比較的新しいので、何か間違ったことをしているかもしれませんが、それは各サンプルのすべてのオーバーヘッドだと推測しています。

それで楽しい実験でしたが、私が保存しているデータの種類にささやきを使うのは意味がないと思います。MongoDBはより良いソリューションのように思えますが、Grafanaのバックエンドとして使用する方法を理解する必要があります。