19.4. トラブルシューティングのための Kafka JMX メトリックの分析

最適なパフォーマンスを得るには、バランスのとれた Kafka クラスターが重要です。バランスの取れたクラスターでは、パーティションとリーダーがすべてのブローカーに均等に分散され、I/O メトリックはこれを反映します。メトリックを使用するだけでなく、kafka-topics.sh ツールを使用して、レプリケーションが不十分なパーティションのリストを取得し、問題のあるブローカーを特定することもできます。レプリケーションが不十分なパーティションの数が変動している場合、または多くのブローカーが高いリクエスト遅延を示している場合、これは通常、調査が必要なクラスター内のパフォーマンスの問題を示しています。一方、クラスター内の多くのブローカーによって報告される、レプリケーションが不十分なパーティションの安定した (変化しない) 数は、通常、クラスター内のブローカーの 1 つがオフラインであることを示します。

kafka-topics.sh ツールの describe --under-replicated-partitions オプションを使用して、クラスター内で現在アンダーレプリケートされているパーティションに関する情報を表示します。これらは、設定されたレプリケーション係数よりも少ないレプリカを持つパーティションです。

出力が空白の場合、Kafka クラスターには不十分にレプリケートされたパーティションはありません。それ以外の場合、出力には、同期していないか、使用できないレプリカが表示されます。

次の例では、各パーティションで 3 つのレプリカのうち 2 つだけが同期しており、ISR からレプリカが欠落しています (同期レプリカ)。

bin/kafka-topics.sh --bootstrap-server :9092 --describe --under-replicated-partitions

Topic: topic-1 Partition: 0 Leader: 4 Replicas: 4,2,3 Isr: 4,3
Topic: topic-1 Partition: 1 Leader: 3 Replicas: 2,3,4 Isr: 3,4
Topic: topic-1 Partition: 2 Leader: 3 Replicas: 3,4,2 Isr: 3,4

I/O およびレプリケーションが不十分なパーティションをチェックするためのいくつかのメトリックを次に示します。

kafka.server:type=ReplicaManager,name=PartitionCount 1
kafka.server:type=ReplicaManager,name=LeaderCount 2
kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec 3
kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec 4
kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions 5
kafka.server:type=ReplicaManager,name=UnderMinIsrPartitionCount 6

トピック設定が高可用性向けに設定されており、トピックのレプリケーション係数が少なくとも 3 で、同期レプリカの最小数がレプリケーション係数より 1 少ない場合は、レプリケーションが不十分なパーティションも引き続き使用できます。逆に、最小 ISR を下回るパーティションでは可用性が低下します。これらは、kafka.server:type=ReplicaManager,name=UnderMinIsrPartitionCount メトリクスと、kafka -topics.sh ツールの under-min-isr-partitions オプションを使用して監視できます。

クラスターメトリックのスパイクは、ブローカーの問題を示している可能性があります。これは、多くの場合、ストレージデバイスの低速または障害、または他のプロセスからのコンピューティング制限に関連しています。オペレーティングシステムまたはハードウェアレベルに問題がない場合は、同じ Kafka トピック内の他のパーティションと比較して、一部のパーティションが不均衡なトラフィックを受信し、Kafka クラスターの負荷が不均衡になっている可能性があります。

Kafka クラスターのパフォーマンスの問題を予測するには、RequestHandlerAvgIdlePercent メトリックを監視すると便利です。RequestHandlerAvgIdlePercent は、クラスターがどのように動作しているかを総合的に示す優れた指標となります。このメトリックの値は 0 から 1 です。0.7 未満の値は、スレッドが時間の 30% でビジー状態であり、パフォーマンスが低下し始めていることを示します。値が 50% を下回ると、特にクラスターのスケーリングや再バランスが必要な場合に問題が発生する可能性があります。30% では、クラスターはほとんど使用できません。

もう 1 つの便利なメトリクスは kafka.network:type=Processor,name=IdlePercent です。これを使用すると、Kafka クラスター内のネットワークプロセッサーがアイドル状態になっている範囲 (パーセンテージとして) を監視できます。このメトリクスは、プロセッサーが過剰に使用されているか、十分に使用されていないかを識別するのに役立ちます。

最適なパフォーマンスを確保するには、num.io.threads プロパティーをシステム内のプロセッサー (ハイパースレッドプロセッサーを含む) の数に設定します。クラスターのバランスは取れているが、単一のクライアントが要求パターンを変更して問題を引き起こしている場合は、クラスターの負荷を軽減するか、ブローカーの数を増やしてください。

単一ブローカー上の単一ディスク障害がクラスター全体のパフォーマンスに重大な影響を与える可能性があることに注意することが重要です。プロデューサークライアントは、トピックのパーティションをリードするすべてのブローカーに接続し、それらのパーティションはクラスター全体に均等に分散されているため、ブローカーのパフォーマンスが低下すると、プロデュースリクエストが遅くなり、プロデューサーにバックプレッシャーが発生し、すべてのブローカーへのリクエストが遅くなります。複数の物理ディスクドライブを 1 つの論理ユニットに結合する RAID (Redundant Array of Inexpensive Disks) ストレージ設定は、この問題を防ぐのに役立ちます。

Kafka クラスターのパフォーマンスをチェックするためのいくつかのメトリックを次に示します。

kafka.server:type=KafkaRequestHandlerPool,name=RequestHandlerAvgIdlePercent 1
# attributes: OneMinuteRate, FifteenMinuteRate
kafka.server:type=socket-server-metrics,listener=([-.\w]+),networkProcessor=([\d]+) 2
# attributes: connection-creation-rate
kafka.network:type=RequestChannel,name=RequestQueueSize 3
kafka.network:type=RequestChannel,name=ResponseQueueSize 4
kafka.network:type=Processor,name=IdlePercent,networkProcessor=([-.\w]+) 5
kafka.server:type=KafkaServer,name=TotalDiskReadBytes 6
kafka.server:type=KafkaServer,name=TotalDiskWriteBytes 7

Kafka コントローラーは、ブローカーの登録、パーティションの再割り当て、トピック管理など、クラスターの全体的な状態の管理を担当します。Kafka クラスター内のコントローラーの問題は診断が難しく、多くの場合、Kafka 自体のバグのカテゴリーに分類されます。コントローラーの問題は、ブローカーのメタデータが同期していない、ブローカーが正常に見えてもレプリカがオフラインになっている、トピックの作成などのトピックに対するアクションが正しく行われていないなどとして現れる可能性があります。

コントローラーを監視する方法はそれほど多くありませんが、アクティブなコントローラー数とコントローラーキューサイズを監視できます。これらのメトリックを監視すると、問題がある場合に大まかな指標が得られます。キューサイズの急増が予想されますが、この値が継続的に増加するか、高い値で安定して低下しない場合は、コントローラーがスタックしている可能性があることを示しています。この問題が発生した場合は、コントローラーを別のブローカーに移動できます。その場合、現在コントローラーであるブローカーをシャットダウンする必要があります。

Kafka コントローラーのパフォーマンスをチェックするためのメトリックをいくつか示します。

kafka.controller:type=KafkaController,name=ActiveControllerCount 1
kafka.controller:type=KafkaController,name=OfflinePartitionsCount 2
kafka.controller:type=ControllerEventManager,name=EventQueueSize 3

RequestHandlerAvgIdlePercent メトリクスを使用して、リクエストが遅いかどうかを判断できます。さらに、リクエストメトリクスにより、どの特定のリクエストで遅延やその他の問題が発生しているかを特定できます。

Kafka リクエストを効果的に監視するには、カウントと 99 パーセンタイルレイテンシー (テイルレイテンシーとも呼ばれます) という 2 つの主要なメトリックを収集することが重要です。

count メトリクスは、特定の時間間隔で処理されるリクエストの数を表します。これは、Kafka クラスターによって処理されるリクエストの量に関する洞察を提供し、トラフィックの急増または低下を特定するのに役立ちます。

99 パーセンタイルレイテンシーメメトリクスは、リクエストの処理にかかる時間であるリクエストレイテンシーを測定します。これは、リクエストの 99% が処理される期間を表します。ただし、残りの 1% のリクエストの正確な期間に関する情報は提供されません。つまり、99 パーセンタイルの遅延メトリックは、リクエストの 99% が特定の期間内に処理され、残りの 1% にはさらに時間がかかる可能性があることを示しています。ただし、この残り 1% の正確な期間は不明です。99 パーセンタイルの選択は、主にリクエストの大部分に焦点を当て、結果を歪める可能性のある外れ値を除外することを目的としています。

このメトリクスは、大部分のリクエストに関連するパフォーマンスの問題やボトルネックを特定するのに特に役立ちますが、リクエストのごく一部で発生する最大レイテンシーの全体像を示すものではありません。

カウントと 99 パーセンタイルレイテンシーメトリクスの両方を収集して分析することで、Kafka クラスターの全体的なパフォーマンスと健全性、および処理中のリクエストのレイテンシーを把握できます。

Kafka リクエストのパフォーマンスをチェックするためのいくつかのメトリックを次に示します。

# requests: EndTxn, Fetch, FetchConsumer, FetchFollower, FindCoordinator, Heartbeat, InitProducerId,
# JoinGroup, LeaderAndIsr, LeaveGroup, Metadata, Produce, SyncGroup, UpdateMetadata 1
kafka.network:type=RequestMetrics,name=RequestsPerSec,request=([\w]+) 2
kafka.network:type=RequestMetrics,name=RequestQueueTimeMs,request=([\w]+) 3
kafka.network:type=RequestMetrics,name=TotalTimeMs,request=([\w]+) 4
kafka.network:type=RequestMetrics,name=LocalTimeMs,request=([\w]+) 5
kafka.network:type=RequestMetrics,name=RemoteTimeMs,request=([\w]+) 6
kafka.network:type=RequestMetrics,name=ThrottleTimeMs,request=([\w]+) 7
kafka.network:type=RequestMetrics,name=ResponseQueueTimeMs,request=([\w]+) 8
kafka.network:type=RequestMetrics,name=ResponseSendTimeMs,request=([\w]+) 9
# attributes: Count, 99thPercentile 10

クライアントメトリックを分析することで、ブローカーに接続されている Kafka クライアント (プロデューサーとコンシューマー) のパフォーマンスを監視できます。これは、コンシューマーグループから頻繁に除外されるコンシューマー、高いリクエスト失敗率、頻繁な切断など、ブローカーログで強調表示される問題を特定するのに役立ちます。

Kafka クライアントのパフォーマンスをチェックするためのいくつかのメトリックを次に示します。

kafka.consumer:type=consumer-metrics,client-id=([-.\w]+) 1
# attributes: time-between-poll-avg, time-between-poll-max
kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+) 2
# attributes: heartbeat-response-time-max, heartbeat-rate, join-time-max, join-rate, rebalance-rate-per-hour
kafka.producer:type=producer-metrics,client-id=([-.\w]+) 3
# attributes: buffer-available-bytes, bufferpool-wait-time, request-latency-max, requests-in-flight
# attributes: txn-init-time-ns-total, txn-begin-time-ns-total, txn-send-offsets-time-ns-total, txn-commit-time-ns-total, txn-abort-time-ns-total
# attributes: record-error-total, record-queue-time-avg, record-queue-time-max, record-retry-rate, record-retry-total, record-send-rate, record-send-total

トピックとパーティションのメトリックは、Kafka クラスターの問題の診断にも役立ちます。また、クライアントメトリクスを収集できない場合に、特定のクライアントに関する問題をデバッグするためにこれらを使用することもできます。

特定のトピックとパーティションのパフォーマンスをチェックするためのいくつかのメトリックを次に示します。

#Topic metrics
kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec,topic=([-.\w]+) 1
kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec,topic=([-.\w]+) 2
kafka.server:type=BrokerTopicMetrics,name=FailedFetchRequestsPerSec,topic=([-.\w]+) 3
kafka.server:type=BrokerTopicMetrics,name=FailedProduceRequestsPerSec,topic=([-.\w]+) 4
kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec,topic=([-.\w]+) 5
kafka.server:type=BrokerTopicMetrics,name=TotalFetchRequestsPerSec,topic=([-.\w]+) 6
kafka.server:type=BrokerTopicMetrics,name=TotalProduceRequestsPerSec,topic=([-.\w]+) 7
#Partition metrics
kafka.log:type=Log,name=Size,topic=([-.\w]+),partition=([\d]+)) 8
kafka.log:type=Log,name=NumLogSegments,topic=([-.\w]+),partition=([\d]+)) 9
kafka.log:type=Log,name=LogEndOffset,topic=([-.\w]+),partition=([\d]+)) 10
kafka.log:type=Log,name=LogStartOffset,topic=([-.\w]+),partition=([\d]+)) 11