グラファイトはランダムにデータを収集しなくなります

collectd、statsd、JMXTransを介してデータを収集するためのGraphiteサーバーがあります...数日以来、私たちは頻繁にデータに穴を開けています。まだ保持しているデータを掘り下げてみると、カーボンキャッシュサイズが増加しています（50Kから4Mに）。収集されるメトリックの数は増加していません（metricsReceivedは約300Kで安定しています）。クエリの数が平均で1000から1500に増加しています。

奇妙なことに、キャッシュサイズが大きくなると、cpuUsageは100％（4 CPU）から50％にわずかに減少します。

不思議なことに、ディスクから読み取ったオクテットの数が増加し、書き込まれたオクテットの数が減少しています。

ほとんどの場合、デフォルト値でカーボンを構成します。

• MAX_CACHE_SIZE = inf
• MAX_UPDATES_PER_SECOND = 5000
• MAX_CREATES_PER_MINUTE = 2000

明らかに、システムで何かが変更されましたが、何が原因であるか、どのようにしてこの原因を見つけることができるのかわかりません...

何か助け？

これは、グラファイトスタックのバグではなく、IOボトルネックです。おそらく、ストレージに十分なIOPSがないためです。このため、キューは増え続け、4Mでオーバーフローします。その時点で、キューに入れられた多くのデータが失われます。これは後でグラフにランダムな「ギャップ」として反映されます。システムは、メトリックを受信するスケールに対応できません。それはいっぱいになり、溢れ続けます。

奇妙なことに、キャッシュサイズが大きくなると、cpuUsageは100％（4 CPU）から50％にわずかに減少します。

これは、IO待機のため、システムがスワッピングを開始し、CPUが多くの「アイドル時間」を取得するためです。

コンテキストを追加するために、40Kのメトリックをいくつか受け取ったシステムで、awsに500のプロビジョニングされたIOPSがあります。キューは50Kで安定しています。

他の回答者は、ディスクI / Oのボトルネックについて言及しました。別の原因として、ネットワークのボトルネックについて説明します。

私の環境では、フロントエンドUIサーバー（httpd、memcached）のクラスターを実行しています。中間層リレーの別のクラスター（転送と集約を実行するcarbon-c-relay）。バックエンドレイヤー（httpd、memcached、carbon-c-relay、およびcarbon-cache）。これらの各クラスターは、EC2の複数のインスタンスで構成され、プロセス全体で1分あたり1,500万メトリックです。

集計「合計」関数によって生成されたメトリックのギャップがあり、集計値が正しくない（低すぎる）場合に問題がありました。中間層でCarbon-C-Relayを再起動することで問題は緩和されますが、ギャップは数時間後に再び現れ始めます。

中間層とバックエンド層の両方で集約が行われました（バックエンド層は、中間層から渡された集約メトリックを集約しました）。

中間層のホストは、CPUにバインドされておらず、ディスクにバインドされておらず、メモリにも制約がありませんでした。これは、問題がリレープロセスを再起動してから数時間後に現れるという事実と相まって、ネットワークのボトルネックがあったことを意味しました。私たちのソリューションは、単に中間層にホストを追加することでした。これを即座に実行すると、集計されたメトリックが正しく実行され、ギャップが発生しなくなりました。

ボトルネックとなったネットワークスタックの正確な場所は？言えませんでした。Linuxホスト上にあった可能性があります。それはアマゾン側にあったかもしれません。