問題タブ [graphite-carbon]

Web アプリケーションの統計情報を取得するために、Graphite と statsd をインストールしました。すでにデータを追跡していますが、Graphite Web アプリケーションのツリー内にあまりにも多くのノードを生成しています。添付の画像を参照してください: 忙しい猫 http://mmeg-de.gefaellt-mir.me/media/hm.PNG

私はすでにグーグルで検索しましたが、これについての説明は見つかりませんでした。インデックス ページがアクセスされた回数を追跡したいだけです。次のコマンドを使用して、Python でこれを行います。

誰かこれについて説明がありますか？なぜこんなに多くの (異なる) グラフがあるのですか? 時間の経過とともにインデックス ページがアクセスされた回数を示すグラフが 1 つだけあると思っていました。

私はこれを隅々まで調べましたが、セットアップと構成の方法StatsD、およびGraphite別のサーバーでの通信について話している人を見つけられませんでした。現在、すべてを 1 つで実行していますが、それらを分離しようとして失敗しました。

これが私がセットアップする方法ですStatsD exampleConfig.js

他のボックスにセットアップするために私が考えることができる他の唯一のものはexample-client.py.

同じサーバー上のウィスパーまたはグラファイトと通信するには、ローカルホストのままにする必要があると思います。をリッスンするようにファイアウォールをセットアップしまし2003た。パケットダンプを使用すると、サーバーは statsd から UDP を取得します。炭素とグラファイトによって消費されないようです。

私は何が欠けていますか？
また、statsd グラファイト セットアップのスケーリングには何が推奨されますか? 現在、statsd を単独で使用しており、別のサーバーでグラファイト + カーボン + ウィスパーを使用しています。statsd は実行に最も多くの電力を消費しますか、それともグラファイト ボックスですか? テストのために毎日数百万ビットのデータをサーバーに送信することになるため、これについて疑問に思っています。

ストレージ方法としてカーボンとセレスを使用して、グラファイトの監視を行っています。不良データの修正に問題があります。（さまざまな問題により）ファイルが重複してしまったようです。つまり、Carbon / Ceres はデータを timestamp@interval.slice として保存するため、時間範囲が重複する 2 つ以上のファイルを持つことができます。

オーバーラップには次の 2 種類があります。

これは、利用可能な既存のツール (ceres-maintenance デフラグおよびロールアップ) がこれらの重複に対処できないため、問題を引き起こしています。代わりに、ディレクトリをスキップして先に進みます。これは明らかに問題です。

私はbackbone.js'app'を作成しており、グラファイト/カーボンのjson出力をいくつかのバックボーンモデル/コレクションに直接マッピングしたいと思います。

一般に、jsonの出力は次のようになります。

私は次のような単純なモデルとコレクションを定義しました：

ご覧のとおり、IDをオーバーロードして各測定のタイムスタンプにし、特定の「メトリック」のすべての測定値をMeasurementsというコレクションに保存します。

また、ハードコーディングしたので、実際には1つのMeasurementsコレクション（つまり、jsonの「ターゲット」）でのみ機能します。

私の質問は、1回の呼び出しで複数の測定値の収集（コレクション）を実装するのに最適/エレガント/柔軟性があるかどうかに関するものです。つまり、graphiteは「ターゲット」にワイルドカードを使用することをサポートしているため、ajaxリクエスト/?target=some.string.*は一致するすべてのターゲットとデータポイントを返します（jsonの例のように）。次に、これをビューに表示し、累積データをレンダリングするか、すべての測定値を時間に対してプロットします。

多くの測定値を含む別のコレクション（セットと呼びましょう）を使用することを考えていました。Set.fetch()サーバーから一致するすべての測定値を取得し、1つのajaxリクエストからセットに多くの測定値コレクションを作成させるようなことをしたいと思います。

誰かがこれを実装する方法の提案がありますか？または、このモデル/コレクションレイヤーを表すより良い方法はありますか？

以下を使用して接続された 2 ノードの Graphite クラスターをセットアップしましたcarbon-relay。

cluster-test-500約 1 分間、約 60/10 秒で、メトリクス用に 500 個のカウンターを送信しました。

私の集計ルールに基づいて：

データは両方のノードの Whisper DB に表示されました。

次に、summarize関数を使用してグラファイトにクエリを実行すると、過去 1 日間で次のようになります。

同じクエリを再実行するだけで、一貫性のない結果が返されます。

これは、WhisperDB ファイル内のタイム セグメントが一見ランダムに合計された結果のようです。一体何がこれを引き起こしているのでしょうか？

(ほぼ) リアルタイムのグラフ Web システムに Graphite を使用しようとしています。ただし、グラファイトを 1 秒の更新レートよりも高速化することはできないようです。最終的には 100 ミリ秒の更新が必要です

FAQ を読むと、グラファイトが高速のように聞こえますが、これは非常に誤解を招くものであるか、グラファイトを高速化する方法を理解していません。

ウィスパーのタイミング情報は UNIX タイムスタンプを使用しているようです

Graphite はどの程度スケーラブルですか?

CPU の観点から見ると、Graphite はフロントエンドとバックエンドの両方で水平方向にスケーリングします。つまり、ミックスにマシンを追加するだけでスループットを向上させることができます。また、バックエンド マシンが失われても最小限の量のデータが失われ (そのマシンがメモリにキャッシュしていたものは何でも)、負荷を処理するのに十分な容量が残っていればシステムが中断されないという意味で、フォールト トレラントです。

I/O の観点から見ると、負荷がかかると、Graphite は多数の異なるファイルに対して多数の小さな I/O 操作を非常に高速に実行します。これは、Graphite に送信された個別の各メトリックが独自のデータベース ファイルに格納されているためです。これは、RRD の上に構築されたツール (draraw、Cacti、Centreon など) の数と同様です。実際、Graphite は当初、ストレージに RRD を使用していましたが、根本的な制限が発生して新しいストレージ エンジンが必要になりました。

大容量 (数千の個別のメトリックが分刻みで更新される) には、優れた RAID アレイが必要です。発生する多数の小さな書き込み操作にディスクが追いつかない場合、Graphite のバックエンドは着信データをキャッシュします (各データ ポイントは数バイトにすぎませんが、ほとんどのディスクは 1 秒あたり数千回を超える I/O 操作を実行できません彼らは小さいです）。これが発生すると、Graphite のデータベース エンジンである whisper により、carbon は一度に複数のデータ ポイントを書き込むことができるため、書き込み可能になるまで余分なデータをメモリにキャッシュしておくという犠牲を払って全体のスループットを向上させることができます。

グラフはどのくらいリアルタイムですか?

とても。各時間間隔で受信するメトリックの数が、ストレージ システムが I/O 操作を実行できるレートよりもはるかに多く、大量のデータ ポイントがストレージ パイプラインにキャッシュされている場合でも、負荷が高くなります (説明については、前の質問を参照してください)。 )、Graphite は引き続きリアルタイム グラフを描画します。秘訣は、Graphite webapp がグラフを描画する要求を受け取ると、ディスクと事前保存キャッシュ (複数のバックエンド サーバーがある場合は分散される可能性があります) から同時にデータを取得し、2 つのソースを結合することです。リアルタイムグラフを作成するためのデータ。

また、ここでは秒数のみが表示され、小数点以下のポイントは表示されません: http://graphite.readthedocs.org/en/latest/config-carbon.html および from and until must be a time specification conforming to the AT-STYLE time specification describedここ: http://oss.oetiker.ch/rrdtool/doc/rrdfetch.en .html . http://graphite.wikidot.com/url-api-reference

それで、それは何ですか？グラファイトは速いですか？それとも、大規模なデータセットを処理するのが速いだけですか - 視覚的に表示するためのパケット データの簡単に使用できる Web レシーバーを探しています - グラファイトは優れたソリューションのように思えましたが、すべてを構成して実行したので、たくさんの時間

ありがとう！

古い炭素データを一定期間後に自動的に削除する設定はありますか?

私はそれを検索しようとしましたが、それについて何も見つけることができませんでした。

提案と回答をお寄せいただきありがとうございます。

1. ここでは 1 つのデータ ポイントが必要ですが、2 つ取得します

   /li>

2. ここでは 24 のデータ ポイントが期待されますが、過去 24 時間で 25 になります。

   /li>

ここuntilは常に現在の時刻を指します。なぜそうなのか誰か説明できますか？データポイントを私の期待どおりに制限する方法は?

uwsgi 1.9.20 を皇帝モードで実行し、家臣の統計をすべてカーボン/グラファイト サーバーに送信しています。docs%nで指定されているように、魔法の変数が「拡張子のないファイル名」を返さず、ソケット設定を返すことを除いて、よさそうです。または、少なくともそれがグラファイトで見られるものです。127_0_0_1:14002

皇帝は次のように始まります：

従属構成の例:

も試しましたが、グラファイトvassal-set = carbon-id=%nだけで表示されます。uwsgiここでマジック変数の何が間違っていますか?

参考までに、CentOS 6.4 では Python のバージョンは 2.7.3 です。