web-dev-qa-db-ja.com

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

データポイントごとにグラファイトによって使用されるディスク領域の量を推定するのに役立つ、数式や環境からのサンプルデータがありますか？

monitoringgraphite
14
Kyle Brandt

whisper-info.pyを使用すると、ファイルのサイズを含め、各ファイルを何がどのように集約するかについて多くの洞察を得ることができます。

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

スキーマを配置する前に、そのサイズを予測したい場合は、 https://Gist.github.com/jjmaestro/577406 にあるようなウィスパー計算機を試してください。

編集：

例を尋ねられたら...

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倍にします（ストレージを購入しているので、使用することはわかっているので...）

7
gWaldo

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

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

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

2
AndreKR

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

簡単な答えは、「おそらく、必要だと思うほどのスペースではありません」です。

長い答えには、サイト固有の計算が含まれます。私たちの監視システム（InterMapper）については、保持期間、解像度、およびデータポイントサイズを計算し、いくつかの乗算を行い、オーバーヘッドを追加します。

例として、ディスクスペースを使用します。5分の精度で30日間、15分の精度でさらに60日間、1時間ごとの精度でさらに300日間格納し、64を使用しています。 -ビット（8バイト）を格納する整数：

  • 合計21600サンプル、次のように分類：
    • 30日間の5分の精度の8640サンプル
    • 60日15分の精度の5760サンプル
    • 300日1時間精度の7200サンプル

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

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

また、最終的な数値の上に健全な10％を追加して切り上げるため、1台のマシンあたり6MBのサイズにしています。

次に、グラフ用のメトリックデータを保存するために用意している1TBのスペースを見て、「そうです、私がずっと成長していなければ、私のライフタイムでおそらくストレージが不足することはないでしょう！」 :-)

1
voretaq7

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

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

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

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

0
musca999