問題タブ [graphite-carbon]

60 秒後にグラファイトに転送するアグリゲータとして statsd を使用します。

「stats.timers」バケットにグラファイトが入っているのがわかります。しかし、期待されるもののすべてではありません。

グラファイトマシンで：

statsd ソース コード ( https://github.com/etsy/statsd/blob/master/lib/process_metrics.js ) を見ると、時間ごとに次のメトリックが (それぞれ独自のバケットとして) 表示されることが期待されます。

ソース：

一部の人は「count_ps」しか取得せず、他の人は「upper」を取得する理由は誰でもわかります。グラファイトが内部統計キューを処理するのに時間がかかりますか?

statsd ログには、約 500 個の numstats/分が送信されていることが示されています。

どんな助けでも大歓迎

乾杯マルセル

私は2つの実サーバーをセットアップしました。

1 つの Statsite (StatsD の代替) が 1 つの「Graphite Stack」 (Carbon および Graphite Webapp) の前にあります。

統計情報は、UDP 経由で Statsite から正しく収集されます。そして、10秒ごとにカーボンキャッシュ（カーボンリレーのTCPポート2013）に転送します。

私のカーボン サーバーでは、3 つのカーボン キャッシュ インスタンス (a、b、および c) が 1 つのカーボン リレーの背後で実行されています (コンシステント ハッシュ)。

3 つの cache:[a, b, c] セクションがあり、すべてが異なるポートでリッスンしています。リレー セクションは、これらの 3 つのキャッシュ インスタンスを宛先 configkey 内に取得しました。オプション --instance=[a, b, c] を使用して Python スクリプトを介して各カーボン キャッシュを開始し、独自の Python スクリプトを使用してカーボン リレーも開始しました。3 つのインスタンスすべてが接続されていることも、リレー ログ内で確認できます。

しかし、Graphite Webapp 内では、carbon.agents.XXXXX-[a, b, c].metricsCount3 つのインスタンスすべてが互いに同じカウント率になっていることがわかります。

カーボン リレーのメトリクス フォルダーが恋しいcarbon.relay.XXXX.metricsCountです。

私はすべて正しくやっていますか???

過去数時間、グラファイトをスケーリングしようとしてきましたが、何らかの理由で、カーボンリレーがカーボンキャッシュエンドポイントにデータを渡していないようです. 各ホストでカーボンキャッシュを実行し、それらのポートを介してデータを送信すると、すべてが期待どおりに機能します。アイデアはありますか?

明らかなことを割り引くには：

• 関連するポートのホスト間で ssh を実行できます

carbon.conf

リレールール.conf

各ホストで次のことを行います。

/opt/graphite/bin/carbon-cache.py 開始 /opt/graphite/bin/carbon-relay.py 開始

各ホストのポート 2013 にデータを個別に送信すると、問題なく動作します。つまり、すべてが whisper ディレクトリの下に作成されます。

同じデータをポート 2003 に送信すると、カーボン リレー サービスの listen.log に次のように表示されますが、そのサーバーのカーボン キャッシュ ログには何も表示されません。

どんな助けでも大歓迎です。

Graphite のインストール後、次のフォルダー構造が/opt/graphiteディレクトリに作成されます。

rrd フォルダーの場所の下に、すべての rrd ファイルをコピーしました

そして出力は

グラファイト Web サーバーにアクセスすると、何も表示されません。これは、アーカイブされた rrd データを rrd の場所にロードする正しい方法ですか?

Carbon と Apache の httpd サーバーを再起動しましたが、UI にこのデータのメトリックが表示されません。何が問題なのですか?

私は最近、再設計しなければならない同僚からカーボン/グラファイトのセットアップを「継承」しました。現在のセットアップは次のとおりです。

• データセンター 1 (DC1): 1 つのカーボン リレーと 4 つのカーボン キャッシュを備えた 2 つのサーバー (サーバー DC1-1 およびサーバー DC1-2)
• データセンター 2 (DC2): 1 つのカーボン リレーと 4 つのカーボン キャッシュを備えた 2 つのサーバー (サーバー DC2-1 およびサーバー DC2-2)

4 つのカーボン リレーはすべて、REPLICATION_FACTOR が 2、一貫性のあるハッシュ、およびすべてのカーボン キャッシュ (2(DC) * 2(サーバー) * 4(キャッシュ)) で構成されています。これにより、一部のメトリックが 1 つのサーバーにのみ存在するという影響がありました (それらはおそらく同じサーバー上の別のキャッシュにハッシュされていました)。100 万を超えるメトリクスでは、この問題はすべてのメトリクスの約 8% に影響します。

私がやりたいのは、冗長性を備えた多層セットアップです。これにより、データセンター全体ですべてのメトリックをミラーリングし、データセンター内では一貫したハッシュを使用してメトリックを 2 台のサーバーに均等に分散させます。

このためには、リレーの構成 (主に) について助けが必要です。ここに私が考えているものの写真があります：

クライアントはそれぞれのデータセンターのtier1relayにデータを送信します(「負荷分散」はクライアント側で発生するため、たとえば、ホスト名に偶数の番号を持つすべてのクライアントはtier1relay-DC1-1に送信され、奇数のクライアントはtier1relay-DC1-1 に送信されます)。 number はtier1relay-DC1-2に送信されます)。

tier2relayはコンシステント ハッシュを使用して、データセンターのデータを 2 台のサーバーに均等に分散します。たとえば、tier2relay-DC1-1の「疑似」構成は次のようになります。

• RELAY_METHOD = コンシステント ハッシュ
• 宛先 = server-DC1-1:cache-DC1-1-a、server-DC1-1:cache-DC1-1-b、(...)、server-DC1-2:cache-DC1-2-d

私が知りたいこと: tier1relay-DC1-1とtier1relay-DC1-2に、すべてのメトリックをDC1 と DC2のtier2relayに送信し (DC 間でメトリックを複製する) 、何らかの「tier2relay-DC1-1とtier2relay- DC1-2の間の負荷分散」。

別のメモ: コンシステント ハッシュを使用する場合、カーボン リレー内で何が起こるかを知りたいのですが、1 つ以上の宛先に到達できません (サーバーがダウンしています) - メトリックが再度ハッシュされますか (到達可能なキャッシュに対して) またはそれらは当面の間、単にドロップされますか？(または、別の角度から同じ質問をする: リレーがメトリックを受信すると、構成されたすべての宛先のリストに基づいて、または現在使用可能な宛先に基づいて、メトリックのハッシュを行いますか?)

複数のホストからメトリックを収集するために Graphite+Carbon をインストールしました。これらのホストは、Apache Spark および Java メトリックを送信します。Graphite 側の異なるホストからのメトリックを区別できません。正しいアプローチは何ですか？ホストごとにメトリクスをグループ化したい。

「マスター」はリモート ホストにあり、「ワーカー」は 3 つのリモート ホストにあり、着信番号を区別できません。ホスト決定要因をメトリックに追加する正しい方法を理解していません。

グラファイトを使用してデータを保存およびプロットしていますが、1 年以上前のデータ ポイントをカーボン デーモンに送信したいと考えています (最初のデータ ポイントは 2013 年 12 月 12 日のもので、最後は 2015 年 1 月 12 日のものです)。 (少なくとも、私の現在の設定では) 24 時間以上前の値を受け入れることができるようにします。

1 年以上前のメトリクスをカーボンに (プレーン テキスト プロトコルを使用して) 送信するたびに、単にドロップします。*.wsp ファイルで whisper-fetch.py​​ を実行すると、過去 24 時間のタイムスタンプが表示され、そのすべてにデータが含まれていないことがわかります。ただし、同じデータを (同じプロトコルを使用して) 現在のタイムスタンプ (または過去 24 時間以内の任意のタイムスタンプ) で送信すると、値が保持され、*.wsp ファイルで whisper-fetch.py​​ を実行したときに表示されます。

私は未加工のデータ ポイントにのみ関心があり、次のように保持を設定しているため、集計ルールの設定はありません。

これにより 2 年間、毎分データ ポイントが保存されることは理解していますが、過去のデータ ポイントを受け入れることはできません。

過去 24 時間より前のタイムスタンプを持つ履歴データを保存する適切な保持はありますか? または、*.config ファイルのどこかに、過去 24 時間より前のデータのインポートを許可する設定がありますか? それとも、この「機能」はウィスパー/カーボンの制限ですか?

アップデート

私が送信しているメトリックの形式は次のとおりです。

"pos.amps (data here) (unix timestamp here)"

従来のフォーマットを使用するなど、いくつかの異なる保持ポリシーを試しました。

120 秒ごとに 1 つのデータ ポイントを収集し、500 のデータ ポイントを保存することを意味しますが、まだ運がありません。私はここ（ https://serverfault.com/questions/593157/graphite-shows-none-for-all-data-points-even-though-i-send-it-data）で、ささやきにはある種のクエリ期間があることを読みましたこれはデフォルトの 24 時間に設定されています。それは私が変更したい値ですが、どこを変更すればよいかわかりません!

私はここのほとんどすべての指示に従うことができます

しかし、私が着いたとき

なぜこのエラーが発生するのかわからないのですか?

これらの手順も試してみましたが、ほぼ同じ場所でハングアップします

https://www.digitalocean.com/community/tutorials/how-to-keep-effective-historical-logs-with-graphite-carbon-and-collectd-on-centos-7

PYTHONPATH をエコーすると、

それで私はそれから作成しました

内容とともに

新しいシェルを作成しましたが、エコーは正しいようです

今、私は走ります

ImportError:設定 'graphite.settings' をインポートできませんでした (sys.path にありますか?):graphite.settings という名前のモジュールはありません