第21章 Streams for Apache Kafka のメトリクスとダッシュボードの設定
メトリックを収集することは、Kafka デプロイメントの健全性とパフォーマンスを理解するために重要です。メトリックを監視することで、問題が重大になる前に積極的に特定し、リソースの割り当てとキャパシティープランニングについて情報に基づいた意思決定を行うことができます。メトリックがないと、Kafka デプロイメントの動作の可視性が制限される可能性があります。これによりトラブルシューティングがより困難になり、時間がかかる可能性があります。メトリックをセットアップすると、長期的には時間とリソースを節約でき、Kafka デプロイメントの信頼性を確保するのに役立ちます。
Streams for Apache Kafka の各コンポーネントにはメトリクスが用意されており、個々のパフォーマンスに関する有用な知見を得ることができます。他のコンポーネントではメトリクスの公開設定が必要ですが、Streams for Apache Kafka Operator はデフォルトで Prometheus メトリクスを自動的に公開します。これらのメトリクスには以下が含まれます。
- 調整数
- 処理中のカスタムリソース数
- 調整期間
- JVM メトリック
さらに、Kafka
リソースのリスナーまたは認可設定で enableMetrics
プロパティーを有効にして、oauth
認証と opa
または keycloak
認可に固有のメトリックを収集できます。同様に、KafkaBridge
、KafkaConnect
、KafkaMirrorMaker
、KafkaMirrorMaker2
などのカスタムリソースで oauth
認証のメトリックを有効にできます。
Streams for Apache Kafka Console は、Kafka クラスター内のメトリクスを監視するためのユーザーインターフェイスを提供します。Streams for Apache Kafka によって管理される Kafka クラスターを Streams for Apache Kafka Console に接続すると、ブローカー、トピック、パーティション、コンシューマーグループなどのコンポーネントに関する詳細情報にアクセスできます。
Streams for Apache Kafka Console は現在、テクノロジープレビューとして利用できます。
Prometheus と Grafana を使用して Streams for Apache Kafka を監視することもできます。Prometheus ルールが設定されている場合、Prometheus はクラスター内で実行中の Pod からのメトリックを消費します。Grafana はこれらのメトリックをダッシュボード上で視覚化し、監視のための直感的なインターフェイスを提供します。
メトリクスの統合を容易にするために、Streams for Apache Kafka には、Streams for Apache Kafka コンポーネント用のサンプルの Prometheus ルールと Grafana ダッシュボードが用意されています。Grafana ダッシュボードの例は、特定のデプロイメント要件に合わせてカスタマイズできます。ルールを使用して、特定のメトリックに基づいてアラートをトリガーする条件を定義できます。
監視要件に応じて、次のことを実行できます。
さらに、分散トレースを設定して メッセージをエンドツーエンドで追跡するようにデプロイメントを設定したり、診断ツール (report.sh
) を使用してトラブルシューティングデータを取得したりすることができます。
Streams for Apache Kafka には、Prometheus および Grafana のサンプルインストールファイルが用意されています。これらのファイルを出発点として使用して、Streams for Apache Kafka のデプロイメントを監視できます。さらにサポートが必要な場合は、Prometheus および Grafana の開発者コミュニティーに参加することを推奨します。
メトリクスおよびモニタリングツールのサポートドキュメント
メトリクスおよびモニタリングツールの詳細は、サポートドキュメントを参照してください。
- Prometheus
- Prometheus の設定
- Kafka Exporter
- Grafana Labs
- Apache Kafka Monitoring では、Apache Kafka により公開される JMX メトリクスについて解説しています。
- ZooKeeper JMX では、Apache Zookeeper により公開される JMX メトリックについて解説しています。
21.1. Kafka Exporter でのコンシューマーラグの監視
Kafka Exporter は、Apache Kafka ブローカーおよびクライアントの監視を強化するオープンソースプロジェクトです。Kafka クラスターで Kafka Exporter をデプロイ するように、Kafka
リソースを設定できます。Kafka Exporter は、オフセット、コンシューマーグループ、コンシューマーラグ、およびトピックに関連する Kafka ブローカーから追加のメトリックデータを抽出します。一例として、メトリクスデータを使用すると、低速なコンシューマーの識別に役立ちます。ラグデータは Prometheus メトリクスとして公開され、解析のために Grafana で使用できます。
Kafka Exporter は __consumer_offsets
トピックから読み取り、このトピックには、コミットされたオフセットに関するコンシューマーグループの情報が格納されます。Kafka Exporter が適切に機能できるようにするには、コンシューマーグループを使用する必要があります。
Kafka Exporter 用の Grafana ダッシュボードが、Streams for Apache Kafka に付属する多数の サンプル Grafana ダッシュボード に含まれています。
Kafka Exporter は、コンシューマーラグおよびコンシューマーオフセットに関連する追加のメトリクスのみを提供します。通常の Kafka メトリクスでは、Kafka ブローカー で、Prometheus メトリクスを設定する必要があります。
コンシューマーラグは、メッセージの生成と消費の差を示しています。具体的には、指定のコンシューマーグループのコンシューマーラグは、パーティションの最後のメッセージと、そのコンシューマーが現在ピックアップしているメッセージとの時間差を示しています。
ラグには、パーティションログの最後を基準とする、コンシューマーオフセットの相対的な位置が反映されます。
プロデューサーおよびコンシューマーオフセット間のコンシューマーラグ
この差は、Kafka ブローカートピックパーティションの読み取りと書き込みの場所である、プロデューサーオフセットとコンシューマーオフセットの間の デルタ とも呼ばれます。
あるトピックで毎秒 100 個のメッセージがストリーミングされる場合を考えてみましょう。プロデューサーオフセット (トピックパーティションの先頭) と、コンシューマーが読み取った最後のオフセットとの間のラグが 1000 個のメッセージであれば、10 秒の遅延があることを意味します。
コンシューマーラグ監視の重要性
可能な限りリアルタイムのデータの処理に依存するアプリケーションでは、コンシューマーラグを監視して、ラグが過度に大きくならないようにチェックする必要があります。ラグが大きくなるほど、プロセスはリアルタイム処理の目的から遠ざかります。
たとえば、コンシューマーラグは、パージされていない古いデータを大量に消費したり、計画外のシャットダウンが原因である可能性があります。
コンシューマーラグの削減
Grafana のチャートを使用して、ラグを分析し、ラグ削減の方法が対象のコンシューマーグループに影響しているかどうかを確認します。たとえば、ラグを減らすように Kafka ブローカーを調整すると、ダッシュボードには コンシューマーグループ別のラグ のチャートが下降し 毎分のメッセージ消費 のチャートが上昇する状況が示されます。
通常、ラグを削減するには以下を行います。
- 新規コンシューマーを追加してコンシューマーグループをスケールアップします。
- メッセージがトピックに留まる保持時間を延長します。
- ディスク容量を追加してメッセージバッファーを増やします。
コンシューマーラグを減らす方法は、基礎となるインフラストラクチャーや、Streams for Apache Kafka によりサポートされるユースケースによって異なります。たとえば、ラグが生じているコンシューマーでは、ディスクキャッシュからフェッチリクエストに対応できるブローカーを活用できる可能性は低いでしょう。場合によっては、コンシューマーの状態が改善されるまで、自動的にメッセージをドロップすることが許容されることがあります。