Kafkaの組み込みコマンドを使用した健全性監視のベストプラクティス

Kafkaの組み込みコマンドは、基本的なインシデントの質問に迅速に答える最速の方法です：パーティションにリーダーがいるか、レプリカが同期しているか、コンシューマーが遅れているか。これらはPrometheus、JMX、または管理された監視プラットフォームを置き換えるものではありませんが、踏み台ホストや管理コンテナからの迅速な確認に優れています。

以下の例では、Kafka管理コマンドの現在のクライアントパスである --bootstrap-server を使用しています。

クリーンなコマンド環境を設定する

ブローカーリストを変数に保持することで、すべてのコマンドを繰り返し実行可能にします：

export KAFKA_HOME=/opt/kafka
export BOOTSTRAP_SERVER="kafka1:9092,kafka2:9092,kafka3:9092"
cd "$KAFKA_HOME/bin"

クラスターがTLSまたはSASLを使用している場合は、クライアント設定をプロパティファイルに保存し、--command-config で渡します：

./kafka-topics.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --command-config /etc/kafka/admin-client.properties \
  --list

トピックとパーティションの健全性を確認する

kafka-topics.sh --describe から始めます。健全なトピックは、各パーティションにリーダーが存在し、同期レプリカリストが期待されるレプリケーションファクターと一致している必要があります。

./kafka-topics.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --describe \
  --topic orders

以下のフィールドに注目してください：

Leader：none であってはなりません。
Replicas：パーティションに割り当てられたブローカー。
Isr：リーダーと現在同期しているレプリカ。

Replicas に3つのブローカーがあるのに Isr が1つしかない場合、トピックはレプリカ不足です。これは通常、ブローカーのダウンタイム、ディスクプレッシャー、ネットワークの問題、または追いつけないレプリカを示しています。

レプリカ不足のパーティションを迅速に見つける

クラスター全体の迅速なチェックが必要な場合は、組み込みフィルターを使用します：

./kafka-topics.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --describe \
  --under-replicated-partitions

出力がないのは良いニュースです。出力がある場合は調査が必要であり、特に min.insync.replicas が設定されているトピックでは、より強力な耐久性が求められます。

コンシューマーラグを監視する

コンシューマーラグは、コンシューマーグループが生成されたレコードに追いついているかどうかを示します。

./kafka-consumer-groups.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --describe \
  --group payments-worker

重要な列は次のとおりです：

CURRENT-OFFSET：グループがコミットした進行状況。
LOG-END-OFFSET：パーティションの最新オフセット。
LAG：両者の差。
CONSUMER-ID、HOST、CLIENT-ID：パーティションを所有するコンシューマー。

短いスパイクは、デプロイやトラフィックの急増時に正常な場合があります。持続的なラグは、グループに注意が必要であることを意味します：処理の遅さ、コンシューマー不足、パーティションの不均衡、ダウンストリーム依存関係の遅延、またはブローカー側のフェッチ遅延。

アクティブなコンシューマーグループを一覧表示する

グループ名がわからない場合は、まずグループを一覧表示します：

./kafka-consumer-groups.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --list

次に、影響を受けるアプリケーションに対応するグループを調査します。

ブローカーAPIの到達可能性を確認する

kafka-broker-api-versions.sh は、クライアントがブローカーに到達し、メタデータ/APIハンドシェイクを完了できることを確認する簡単な方法です。

./kafka-broker-api-versions.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER"

これが失敗した場合は、DNS、セキュリティグループまたはファイアウォール、TLS/SASL設定、およびアドバタイズされたリスナーアドレスがコマンドを実行する場所から到達可能かどうかを確認します。

インシデント時にCLIチェックを使用する

実用的なトリアージフローは次のようになります：

kafka-broker-api-versions.sh を実行して接続性を確認します。
kafka-topics.sh --describe --under-replicated-partitions を実行してレプリケーションの健全性を確認します。
影響を受けるトピックを記述し、リーダーとISRを確認します。
影響を受けるコンシューマーグループを記述し、パーティションごとのラグを確認します。
遅いパーティションをブローカー、ディスク、アプリケーションのログと比較します。

まとめ

Kafkaの組み込みコマンドは、クラスターの健全性を信頼性高く最初に確認する手段を提供します。管理クライアントの設定を準備し、--bootstrap-server を使用し、リーダー、ISR、レプリカ不足のパーティション、コンシューマーラグに焦点を当ててください。CLIが問題の場所を示したら、より深いブローカーメトリクスとログの解釈がはるかに容易になります。