2017-12-07 10 views
2

私は4台のカフカクラスタのメトリックを監視しています。私は入力アプリケーションを使ってKafkaにメッセージを書いています。そして、Kafka Streamsアプリケーションはそれらのメッセージを処理し、それらをジオロケーション変数で区切られた新しいKafkaトピックに書き戻します。Kafkaのブローカがキューのスパイクを要求し、ストリームのタイムアウト例外が発生しました

不確定な時間(通常2〜3日)はクラスタが問題なく実行され、メトリックでは何も不審なものは報告されず、メトリックkafka.network:type=RequestChannel,name=RequestQueueSizeは最大値noからスパイクされません50件または60件のリクエストに対する10件以上のリクエストが、1つのブローカ上にのみ存在します。これにより、最終的にKafka Streamsのプロデューサリクエストキューが数分で構築され、タイムアウトになります(トピックを複製していない瞬間)。

さらに、Streamsアプリケーションを再起動すると、ブローカ要求キューがすぐに再構築されます。それは(2秒程度) kafka.network:type=RequestMetrics,name=RequestQueueTimeMsための高い99パーセンタイルに基づいて、それらのすべての特定の要求を必要とするではなく、同じように見えます

が、低い平均(0.3ミリ秒のオーダー)。

CPU使用率は正常です。つまり、ハード制限値に達していません。

このようにブローカが不健全になる理由は何ですか?私が見なければならない追加の測定基準がありますか?

答えて

1

パフォーマンスが急激に低下したり、CPUのスペアタイムアウトが発生している場合は、おそらくIOの問題が発生している可能性があります。

ご覧になる最良の指標の1つは、kafka.log:type=LogFlushStats,name=LogFlushRateAndTimeMsです。ログフラッシュレートまたはログフラッシュ待ち時間が増えると、Kafkaはディスクへの書き込みに問題があることを意味します。

私たちの場合、私たちのページキャッシュはあまりにも頻繁にフラッシュされていました。私たちの平均IO要求サイズは減少しましたが、書き込みiopsが急増しました。バースト残高を持つEBSインスタンスを使用していたため、繰り返しバーストバケットが排除され、リクエストキューが構築されました。

関連する問題