グラファイトはランダムにデータの収集を停止します
Collectd、statsd、JMXTransを介してデータを収集するためのGraphiteサーバーがあります...数日以来、データに穴が開いていることがよくあります。まだ持っているデータを掘り下げると、カーボンキャッシュサイズが増加していることがわかります（50Kから4M）。収集されるメトリックの数の増加は見られません（metricsReceivedは約300Kで安定しています）。クエリの数は平均して1000から1500に増加しています。
不思議なことに、キャッシュサイズが大きくなると、cpuUsageは100％（CPUが4つあります）から50％にわずかに減少します。
不思議なことに、ディスクからオクテットを読み取ると数が増加し、書き込まれるオクテットの数が減少します。
カーボンは主にデフォルト値で構成されています。
- MAX_CACHE_SIZE = inf
- MAX_UPDATES_PER_SECOND = 5000
- MAX_CREATES_PER_MINUTE = 2000
明らかに、私たちのシステムで何かが変更されましたが、私たちは何を理解しておらず、この原因を見つける方法もわかりません...
何か助けはありますか？
これはグラファイトスタックのバグではなく、IOボトルネックです。おそらく、ストレージのIOPSが十分に高くないためです。このため、キューが蓄積され続け、4Mでオーバーフローします。 。その時点で、あなたloseキューに入れられたデータの量は、後でグラフにランダムな「ギャップ」として反映されます。システムはkeep-upスケールがメトリックを受信しています。保持しますいっぱいになり、オーバーフローします。
不思議なことに、キャッシュサイズが大きくなると、cpuUsageは100％（CPUが4つあります）から50％にわずかに減少します。
これは、IO待機のため、システムがスワッピングを開始し、CPUが多くの「アイドル時間」を取得するためです。
コンテキストを追加するために、40Kのメトリックを受信するシステムのawsに500のプロビジョニングされたIOPSがあります。キューは50Kで安定しています。
他の回答者は、ディスクI/Oのボトルネックについて言及しました。このもう1つの原因として、ネットワークのボトルネックについて説明します。
私の環境では、フロントエンドUIサーバーのクラスター（httpd、memcached）を実行します。中間層リレーの別のクラスター（転送と集約を実行するcarbon-c-relay）。バックエンドレイヤー（httpd、memcached、carbon-c-relay、carbon-cache）。これらの各クラスターは、EC2の複数のインスタンスで構成され、合計で1分あたり1,500万メトリックを処理します。
集計「合計」関数によって生成されたメトリックのギャップが表示され、集計値が正しくない（低すぎる）という問題がありました。中間層でカーボンcリレーを再起動することで問題は軽減されますが、数時間後にギャップが再び現れ始めます。
中間層とバックエンド層の両方で集約が行われました（バックエンド層は、中間層から渡された集約されたメトリックを集約しました）。
中間層のホストは、CPUにバインドされておらず、ディスクにバインドされておらず、メモリに制約もありませんでした。これは、リレープロセスを再開してから数時間後に問題が発生するという事実と相まって、ネットワークのボトルネックがあったことを意味します。私たちの解決策は、単に中間層にホストを追加することでした。これを即座に実行すると、集約されたメトリックが正しく実行され、ギャップが発生しなくなりました。
ボトルネックがあったネットワークスタックの正確な場所は？私はあなたに言うことができませんでした。 Linuxホスト上にあった可能性があります。それはアマゾン側にあった可能性があります。