Monitoring Kafka with Prometheus

Kafka について

Kafka とは

Kafka は、分散型で高スループットかつスケーラブルなリアルタイムデータストリームプラットフォームです。

Kafka は、ログ収集、監視データの集約、ストリームデータ処理、オンラインおよびオフライン分析など、ビッグデータ分野で広く使用されており、ビッグデータエコシステムに不可欠な存在となっています。

Producer：プッシュモードで Kafka Broker にメッセージを送信します。送信されるメッセージには、Web サイトのページアクセス、サーバーログ、CPU やメモリに関連するシステムリソース情報などがあります。

Kafka Broker：メッセージを保存するサーバーです。Kafka Broker は水平スケーリングをサポートしており、Kafka Broker ノード数が増えるほどクラスターのスループットが向上します。

Group：プルモードで Kafka Broker からメッセージをサブスクライブして消費します。

ZooKeeper：クラスター設定の管理、リーダーパーティションの選出、グループ変更時の負荷分散を実行します。

Kafka の特徴

利点

1. 通信モード：キューイングとパブリッシュ/サブスクライブの 2 つの通信モードをサポートしています。

2. 高スループットと低レイテンシ：コスト効率の高いハードウェア上でも、Kafka は毎秒数十万のメッセージを処理でき、最小レイテンシは数ミリ秒に抑えられます。

3. 永続化：Kafka はメッセージをディスクに永続化できます。

4. スケーラビリティ：Kafka クラスターはホット拡張をサポートしており、クラスターに動的に新しいノードを追加できます。

5. フォールトトレランス：クラスター内のノード障害を許容します（レプリカ数が n の場合、n-1 台のノード障害を許容）。

注意事項

1. トピック/パーティションの過多によるパフォーマンス低下：Kafka のトピック/パーティションが多すぎると（たとえば、通常のディスクで 1 台あたり 500 以上のトピック/パーティションがある場合）、ストレージの断片化が進み、負荷が大幅に増加します。トピック/パーティションが多いほど負荷が高くなり、メッセージ送信の応答時間も長くなります。

2. メッセージの欠落：以下の 2 つのシナリオでメッセージが失われる可能性があるため、ビジネスシナリオに応じて回避策を講じる必要があります。

• メッセージの送信時：acks=All の設定、またはメッセージのレプリカ数が 1 以下の場合、Kafka Broker のマシンが異常停止した際にメッセージが失われる可能性があります。

• メッセージの受信時：Consumer がメッセージの処理を完了する前にオフセットをコミットすると、Consumer の異常時に一部のメッセージが失われる可能性があります。

3. 重複消費：何らかの理由（ネットワークジッターや Kafka Broker の停止など）により、Producer が Kafka Broker からの送信成功確認を受信できず、メッセージを繰り返し送信することで、Consumer が同じビジネスメッセージを複数受信してしまう場合があります。このようなシナリオでは、Consumer 側でメッセージのべき等性を確保する必要があります。

4. メッセージ順序の乱れ：Kafka は同じパーティション内でのみメッセージの順序を保証でき、異なるパーティション間では順序が保証されません。

5. トランザクションはサポートされていません

Kafka の代表的なユースケース

1. ビッグデータ：Web サイトの行動分析、ログ集約、アプリケーション監視、ストリームデータ処理、オンラインおよびオフラインデータ分析など。

2. データ連携：MaxCompute、OSS、RDS、Hadoop、HBase などのオフラインデータウェアハウスにメッセージをインポートします。

3. ストリーム処理との統合：StreamCompute、E-MapReduce、Spark、Storm などのストリーム処理エンジンとの統合。

Kafka の基本概念

Broker：Kafka のサーバーノードです。

Cluster：複数の Broker の集合体です。

Message：Record とも呼ばれ、Kafka における情報伝達の媒体です。メッセージには、Web サイトのページアクセス、サーバーログ、CPU やメモリに関連するシステムリソース情報などがあります。メッセージキューの Kafka バージョンでは、メッセージはバイト配列です。

Producer：Kafka にメッセージを送信するアプリケーションです。

Consumer：Kafka からメッセージを受信するアプリケーションです。

Consumer Group：同じ Group ID を持つ Consumer のグループです。同じグループ内の複数の Consumer が 1 つのトピックを消費する場合、各メッセージは 1 つの Consumer のみに配信され、消費の負荷分散を実現します。グループを利用することで、トピックのメッセージを並列に消費し、Kafka のスループットを向上させることができます。

トピック：メッセージの分類に使用されるテーマです。各 Broker 上に複数のトピックを作成できます。

Replica：各パーティションには複数のレプリカがあります。プライマリパーティション（Leader）に障害が発生した場合、スタンバイパーティション（Follower）からリーダーが選出されます。Kafka では、デフォルトの最大レプリカ数は 10 で、レプリカ数は Broker 数を超えることはできません。Follower と Leader は異なるマシン上に配置され、同じマシンは同一パーティションに対して 1 つのレプリカのみ保存できます。

Partition：メッセージを保存するための順序付けられた不変のメッセージシーケンスです。1 つのトピックは 1 つ以上のパーティションで構成され、各パーティションのメッセージは 1 つ以上の Broker 上に保存されます。パーティション内のメッセージ順序は、Producer がメッセージを送信する順序です。

Offset：パーティション内の各メッセージの位置情報で、単調に増加する不変の値です。

Consumption Site：現在の Consumer が消費したメッセージの最大オフセット位置です。

Stacking Amount：現在のパーティションの合計メッセージ滞留量で、最大オフセット位置から消費オフセット位置を引いた値です。滞留は重要な指標です。滞留量が多い場合、Consumer がブロックされているか、消費速度が生産速度に追いついていない可能性があります。このような場合、Consumer の稼働状況を分析し、消費速度の改善を図る必要があります。滞留メッセージをすべてクリアする、最大オフセット位置から消費を開始する、またはタイムスタンプでオフセット位置をリセットするといった対応が可能です。

Rebalance：Consumer グループ内の Consumer インスタンスに障害が発生した後、他の Consumer インスタンスがサブスクリプションのトピックパーティションを自動的に再分配します。リバランスは、Kafka Consumer が高可用性を実現するための重要な手段です。

Zookeeper：Kafka クラスターは ZooKeeper に依存してクラスターのメタ情報を保存し、システムの可用性を確保します。

Kafka の主要バージョン概要

• 0.x：初期のインキュベーションバージョン。

• 1.x：Streams API の最適化、可観測性とデバッグ機能の強化、Java 9 のサポート、SASL 認証の最適化、Controller 管理の最適化など。

• 2.x：パフォーマンスの大幅な向上、ACL サポートの強化、OAuth2 ベアラートークンのサポート、動的 SSL 更新のサポート、可観測性の向上、Java 11 のサポート（Java 7 のサポート終了）、インクリメンタルな協調リバランスのサポートなど。

• 3.x：ZooKeeper への依存が排除され、Java 17 がサポートされました（Java 8 と Scala 12 のサポート終了）。v0 および v1 のメッセージはサポート対象外となり、パフォーマンスが大幅に向上しています。

2.x および 3.x のバージョンが推奨されます。

Kafka メトリック監視リファレンスモデル

Kafka のアーキテクチャーとユースケースに基づき、メトリック収集、監視ダッシュボード、アラームインジケーターの 3 つの観点から、Kafka メトリック監視のリファレンスモデルを定義します。

• メトリックの取得

ビジネス監視を完了するために収集すべき Kafka 関連メトリックについて、Producer、Broker、Consumer の観点から議論します。

1. Producer のインジケーター

Producer は Broker のトピックにメッセージをプッシュするアプリケーションです。Producer に障害が発生すると、Consumer は新しい情報を取得できなくなります。Producer の以下の主要インジケーターに注目することを推奨します。

2. Broker のインジケーター

すべてのメッセージは Kafka Broker を介してのみ利用されるため、クラスター内の Broker を監視することが核心となります。以下の主要インジケーターに注目することを推奨します。

3. Consumer のインジケーター

Consumer は Kafka メッセージの最終受け取り手です。以下の主要インジケーターに注目することを推奨します。

4. ZooKeeper のインジケーター

ZooKeeper は Kafka（v3.x より前）の重要なコンポーネントです。ZooKeeper の停止は Kafka の停止を意味します。

• Kafka 監視ダッシュボード

デフォルトの監視ダッシュボードには、少なくとも以下のインジケーターパネルを含めることを推奨します。

1. Producer

• トピックのメッセージ生産量の時間変化：トラフィックソースを迅速に特定し、インフラ設定の変更の根拠を提供します。

• リクエスト/レスポンスレートの時間変化：ピークと低下に注意を払うことは、サービスの継続的な可用性を確保するために重要です。

• 平均リクエストレイテンシの時間変化：レイテンシはスループットと密接に関連しているため、この変化を観察することで batch.size パラメーターの修正が必要かどうかを判断できます。

• IO 待ち時間の変化：待ち時間が長すぎる場合、Producer が十分に速くデータを取得できていないことを示しています。

2. Broker

• 無効なレプリカを持つパーティション数の変化：このインジケーターが急増した場合、Broker に異常が発生している可能性が高いです。

• ISR 数の変化：Broker やパーティション数の変更以外で ISR 数が変化した場合、注意が必要です。

• 有効 Broker 数の変化。

• アクティブな Controller 数の変化。

• オフラインパーティション数の変化：このインジケーターが 0 より大きい場合、そのパーティションは利用不可であり、このパーティションの Consumer と Producer はブロックされます。

• リーダー選出率と選出時間の変化：選出はリーダーの消失を意味します。選出に時間がかかりすぎると、その期間中にメッセージの受信や Consumer リクエストの処理ができません。

• リクエスト消費時間：一般的に、この値は安定しており、変動が少ないはずです。

• ネットワークトラフィック：潜在的なボトルネックの位置に関する情報を提供し、エンドツーエンドのメッセージ圧縮が必要かどうかを判断する根拠となります。

• Purgatory メッセージの生産/プル数：Purgatory メッセージの数を観察することで、メッセージ生産やプルに時間がかかる理由を特定できます。

3. Broker JVM

Full GC の頻度と消費時間：GC 頻度が高い、または GC 時間が長いと、Broker のパフォーマンスに大きな影響を与えます。これに基づき、メモリの増設が必要かどうかを判断できます。

4. Consumer

• グループ消費遅延数の変化：このインジケーターが大きいほど、メッセージの滞留が多いことを示します。

• 消費トラフィックの変化：消費メッセージのネットワークトラフィック/メッセージトラフィックのサイズの変化を表示します。

• プルデータレートの変化：Consumer が健全かどうかの重要なインジケーターです。

5. ZooKeeper

• 処理待ちリクエスト数の変化。

• 平均リクエスト応答時間の変化：消費時間が急増した場合、Kafka クラスター全体の連携メカニズムがブロックされる可能性があります。

• クライアント接続数の変化：接続数の急激な変化は、通常、Broker の参加、退出、または消失を伴います。

• オープンファイルハンドル数と残存数の変化：残存数が不足すると、Broker が ZooKeeper に接続できなくなる可能性があります。

• 待機同期リクエスト数の変化。

• Kafka アラームルール

以下のアラームルールの設定を推奨します。

1. Producer

• メッセージ送信失敗数：送信失敗メッセージ数が一定数に達したときにアラームを発報します。

• メッセージ送信再試行数：ユニット時間あたりの送信再試行メッセージ数がしきい値に達したときにアラームを発報します。

• 送信時間の長期化：送信時間が x ミリ秒を超えた場合。

2. Broker

• Controller が正常：有効 Controller の数が 1 でない。

• オフラインパーティションなし：オフラインパーティションの数が 0 より大きい。

• Unclean Leader 選出なし：Unclean Leader の選出率が 0 より大きい。

• Broker の利用不可：有効 Broker の数が減少。

• ISR 縮小：トピックパーティションの ISR 数が n 未満。

• パーティションの利用不可：トピックパーティションが Under Replicated 状態。

• トピック/パーティション容量：トピック/パーティションの数が n より大きい。

• インスタンスのメッセージ流入/流出：現在のインスタンストラフィックがしきい値を超えるか下回る場合にアラーム。

• トピックのメッセージ流入/流出：現在のトピックトラフィックが指定されたしきい値を超えるか下回る場合にアラーム。

• ディスク容量：ディスク使用率が x% より大きい（参考値：85%）。

• CPU 使用率：80% 以上。

3. Broker JVM：

FullGC 頻度：頻繁な FGC のアラーム。

4. Consumer

メッセージ滞留：グループ消費遅延数が n より大きい（n の大きさはビジネスフローに応じて適切に設定）。

5. ZooKeeper

待機同期リクエストの数が n より大きい。

Kafka の典型的な問題シナリオとトラブルシューティング/解決策

• トピックメッセージの送信遅延と同時実行性の低さ

1. シナリオの説明

1 つまたはいくつかのトピックの同時メッセージ送信パフォーマンスが低い状態です。インジケーター上では、Producer の平均リクエストレイテンシが大きく、平均生産スループットが小さいことを示します。

2. 原因

メッセージ送信が遅い理由には、いくつかの典型的な原因があります。

• ネットワーク帯域幅の不足による IO 待ち。

• メッセージが圧縮されていないため、ネットワークトラフィックが過負荷になっている。

• メッセージがバッチで送信されていない、またはバッチしきい値が適切に設定されていないため、送信速度が遅い。

• トピックパーティション数の不足により、Broker の受信メッセージが滞留している。

• Broker のディスク性能が低いため、ディスク同期が遅い。

• Broker のパーティション総数が大きすぎるため、断片化とディスク読み書きの過負荷が発生している。

3. トラブルシューティング

上記の考えられる原因に基づき、対応する監視インジケーター/ダッシュボードを 1 つずつ確認して問題を特定し、解決します。

• Producer の「メッセージ生産」インジケーターが大幅に増加しているか確認します。増加がある場合は、Consumer の数をそれに応じて増やす必要があります。

• Consumer の「メッセージ消費トラフィック」インジケーターが大幅に低下しているか確認します。低下がある場合、Consumer のビジネス処理の消費時間が増加していることを示します。ビジネス消費を確認するか、Consumer の数を増やす必要があります。

• Kafka Broker のコマンドを使用して、トピックに対応する Consumer の数が実際の Consumer の数と一致しているか確認します。一致していない場合、一部の Consumer が Broker に正しく接続されていないことを意味します。Consumer が正常に稼働しているか確認する必要があります。

• Consumer の数が頻繁に変化して、リバランスが繰り返されていないか観察します。該当する場合は、各 Consumer が正常に稼働しているか確認する必要があります。

• ネットワークやその他の理由により、Consumer と Broker の接続が不安定になる場合があります。Consumer はメッセージを消費し続けることができますが、Broker は常にメッセージが未確認と判断し、同じ消費オフセットのままになります。この場合、Consumer と Broker 間のネットワーク安定性を確認する、または Consumer を再起動する必要がある可能性があります。

4. 自己構築 Prometheus で Kafka を監視する際の課題

自己構築 Prometheus で Kafka を監視する際に直面する典型的な問題は以下のとおりです。

• セキュリティや組織管理などの要因により、ユーザーのビジネスは通常、相互に隔離された複数の VPC にデプロイされます。Prometheus も複数の VPC に個別にデプロイする必要があるため、デプロイメントと運用保守コストが高くなります。

• 各監視システム一式には、Prometheus、Grafana、AlertManager などの個別インストールと設定が必要です。プロセスが複雑で、実装期間が長くなります。

• オープンソースの Kafka JMX Agent は特定のシナリオで CPU 使用率が高く、自己構築 Kafka サービスに干渉する可能性があります。

• Alibaba Cloud メッセージキュー Kafka（以下、ApsaraMQ for Kafka）に対して、自己構築 Prometheus では監視できず、グローバルな視点からのワンストップ監視が実現できません。

• ECS 上にデプロイされた自己構築 Kafka に対して、自己構築 Prometheus には Alibaba Cloud ECS とシームレスに統合されたサービス検出メカニズムが不足しており、ECS タグに基づいてターゲットを柔軟に定義・捕捉できません。同様の機能を独自に実装するには、Go 言語でコード開発（Alibaba Cloud ECS POP インターフェイスの呼び出し）を行い、オープンソース Prometheus コードと統合し、コンパイル、パッケージ化、デプロイする必要があります。ハードルが高く、プロセスが複雑で、バージョンアップも困難です。

• オープンソースの Grafana Kafka ダッシュボードは専門性が不十分で、Kafka の原理/特徴やベストプラクティスに基づく深い最適化が欠けています。

• Kafka のアラームインジケーターテンプレートが不足しており、ユーザーが独自にアラームルールを研究して設定する必要があります。作業量が多く、Kafka 分野の専門知識が不足している可能性があります。

比較

Alibaba Cloud Prometheus モニタリングは、オープンソース Prometheus エコシステムと完全に連携しており、幅広いコンポーネントの観測をサポートし、すぐに使える複数のプリセット監視ダッシュボードを提供し、完全マネージド型のハイブリッドクラウド/マルチクラウド Prometheus サービスを提供します。Alibaba Cloud Container Service、自己構築 Kubernetes、Remote Write をサポートするだけでなく、ハイブリッドクラウド + マルチクラウド ECS アプリケーションのメトリック観測機能も提供します。また、マルチインスタンスの集約観測機能により、Prometheus インジケーターの統一クエリ、Grafana データソースの統一、アラームの統一を実現します。

Alibaba Cloud Prometheus は、Alibaba Cloud Kafka と自己構築 Kafka の両方を完全にサポートします。

Alibaba Cloud Prometheus を使用した Kafka の監視

以下では、Alibaba Cloud Prometheus を使用して Alibaba Cloud Kafka と自己構築 Kafka を監視する方法について説明します。

• Alibaba Cloud Prometheus を使用した Alibaba Cloud Kafka の監視

Alibaba Cloud Kafka は、オープンソース Apache Kafka の課題を解決するフルマネージドサービスです。ユーザーはデプロイメントや保守を気にせず、ビジネス開発に集中できます。オープンソース Apache Kafka と比較して、ApsaraMQ for Kafka はより低いコスト、高い弾力性、高い信頼性を実現しています。

Alibaba Cloud Kafka には、現在、Alibaba Cloud Prometheus モニタリングがデフォルトで統合されています。Alibaba Cloud Kafka はユーザーによるデプロイメントと運用保守が不要なため、Prometheus モニタリングは「Kafka の利用」シナリオに焦点を当てており、以下のインジケーターを対象とします。

• インスタンス/グループ/トピックレベルのトラフィックインジケーター

• グループおよびトピックのメッセージ滞留インジケーター

• インスタンスのディスク使用率インジケーター

• グループのリバランスインジケーター

• Alibaba Cloud Kafka 監視ダッシュボードの表示

Alibaba Cloud Kafka には、インスタンス、グループ、トピックの 3 つの監視ダッシュボードが用意されています。これらのダッシュボードを通じて、ユーザーは Kafka メッセージの生産と消費状況を迅速かつ明確に把握し、Alibaba Cloud Kafka の使用中に遭遇する問題をすばやく特定できます。

ユーザーは Alibaba Cloud Kafka コンソールにログインし、Kafka インスタンス詳細画面の「Prometheus モニタリング」メニューまたはタブページから表示できます。

https://kafka.console.aliyun.com/

Alibaba Cloud Kafka インスタンス監視ダッシュボード

Alibaba Cloud Kafka コンシューマーグループ監視ダッシュボード

Alibaba Cloud Kafka トピック監視ダッシュボード

• Alibaba Cloud Prometheus を使用した Alibaba Cloud Kafka アラートの設定

ユーザーは Alibaba Cloud Prometheus コンソールにログインし、「クラウドサービスモニタリング」インスタンスの「統合センター」インターフェイスに入り、「クラウドプロダクト自己監視統合」タブを選択し、「Message Queue Kafka」をクリックすると、ポップアップウィンドウの「アラーム」タブページが表示され、Alibaba Cloud Kafka の Prometheus アラームを表示および追加できます。Prometheus アラーム作成の詳細な手順は、Prometheus アラームルールのドキュメントを参照してください。

https://help.aliyun.com/document_detail/331981.html

Alibaba Cloud Prometheus は、13 のデフォルトアラームインジケーター（継続的に更新中）を提供しており、インスタンス、グループ、トピックの主要インジケーターをカバーしているため、ユーザーは一般的なアラームルールをすばやく設定できます。

• Alibaba Cloud Prometheus を使用した自己構築 Kafka の監視

Alibaba Cloud Kafka に加え、Alibaba Cloud Prometheus は自己構築 Kafka の監視アクセス機能も提供します。コンテナサービス環境（ACK、ASK、登録済みクラスターを含む）と ECS 環境の Kafka 監視をサポートし、Basic Edition と Advanced Edition の 2 つのバージョンを提供します。

• Basic Edition：Broker 数、トピックパーティション数、メッセージグループ Lag などの基本インジケーターを収集します。Kafka サーバーの設定変更や再起動は不要です。

• Advanced Edition：Basic Edition の機能に加えて、JMX Agent を通じて Producer、サーバー、Consumer およびその内部モジュールの重要なインジケーターを収集し、フルリンクで統合されたエキスパートレベルの Kafka 監視を実現します。ただし、JMX Agent の注入とプロセスの再起動が必要です。

Alibaba Cloud Kafka の監視シナリオとは異なり、自己構築 Kafka では「Kafka の利用」に関する通常のインジケーターに加え、「Kafka の運用保守」に関する内部インジケーターにも注意を払う必要があります。そのため、Kafka の Producer、サーバー、Consumer およびその内部モジュールの重要なインジケーターを深く捕捉し、Kafka 自体の各リンクで発生する可能性のある問題を分析・トラブルシューティングする必要があります。そのため、Advanced Edition の使用を推奨し、自己構築 Kafka の稼働状況を全面的に把握できるようにします。

ZooKeeper およびその他の基本監視（ディスク、ネットワークなど）については、Prometheus による ZooKeeper および Node Exporter コンポーネントのアクセスと設定に関する関連ドキュメントを参照してください。

https://help.aliyun.com/document_detail/161845.html

https://help.aliyun.com/document_detail/445268.html

• Alibaba Cloud Prometheus を使用した自己構築 Kafka の基本監視

1. 自己構築 Kafka の基本監視をデプロイ

Alibaba Cloud Prometheus コンソールにログインし、ARMS アクセスセンターにアクセスして、コンポーネントアプリケーション「Kafka (Basic Edition)」の「追加」ボタンをクリックします。ポップアップインターフェイスで Kafka のデプロイ環境を選択し（現在は「Alibaba Cloud Container Service 環境」と「Alibaba Cloud ECS 環境」をサポート）、Kafka が配置されている Prometheus インスタンスを選択してから、設定情報を入力します。

Kafka への接続に必要な情報を設定します。

Exporter 名：現在の Kafka 監視の一意な名前です。

Kafka アドレス：Kafka Broker の接続先アドレスを入力します。複数の Broker アドレスはカンマまたはセミコロンで区切ります。

• コンテナサービスでは、Kafka Broker の IP アドレスまたはサービスアドレスを使用できます。

• ECS 環境では、Kafka Broker の IP アドレスまたは DNS アドレスを使用できます。

メトリック収集間隔（秒）：監視データの収集間隔です。

Kafka バージョン：Kafka サーバーのバージョン番号を選択します。現在、最大で 3.2.0 までサポートしています。

SASL の有効化：Kafka サーバーが SASL を使用しているか確認して選択します。

SASL ユーザー名：SASL が有効な場合、対応するユーザー名を入力します。

SASL パスワード：SASL が有効な場合、対応するパスワードを入力します。

SASL 方式：SASL 方式を選択します。現在、plain、scram-sha512、scram-sha256 をサポートしています。

TLS の有効化：Kafka サーバーが TLS を使用しているか確認して選択します。

TLS セキュリティチェックの無視：Kafka サーバーが TLS を有効にしており、自己署名証明書の場合、TLS セキュリティチェックを無視することを選択できます。

2. 自己構築 Kafka の基本監視ダッシュボードの確認

Prometheus インスタンスの統合センターに入り、「Kafka (Basic Edition)」をクリックして、ポップアップインターフェイスの「ダッシュボード」タブページを選択し、ダッシュボードのサムネイルをクリックして対応する Grafana ダッシュボードを表示します。基本監視ダッシュボードには主に以下が表示されます。

• Kafka Broker の数。

• 各トピックのパーティション数。

• 各トピックのメッセージ流入数/流出数/滞留数。

• 各トピックの ISR (In Sync Replicas) 数。

3. 自己構築 Kafka の基本監視アラームの設定

Prometheus インスタンスの統合センターに入り、「Kafka (Basic Edition)」をクリックして、ポップアップインターフェイスの「アラーム」タブページを選択すると、現在の Prometheus インスタンスの Kafka Basic Edition アラームルールを表示/追加できます。Prometheus アラーム作成の詳細な手順は、Prometheus アラームルールのドキュメントを参照してください。

https://help.aliyun.com/document_detail/331981.html

現在、Kafka Basic Edition モニタリングは 4 つのアラームインジケーターを提供しています。ユーザーは実際の状況に応じてアラームルールをインスタンス化できます。

• Consumer トピックのメッセージ滞留。

• パーティション数の過多：Kafka Broker の保護アラームを定義し、パーティション数の過多による急激なパフォーマンス低下を回避します。

• Under Replicated パーティションの存在。

• 有効 Broker 数の減少。

Alibaba Cloud Prometheus を使用した自己構築 Kafka の Advanced Edition 監視

• 自己構築 Kafka の Advanced Edition 監視をデプロイ

まず、ユーザーは JMX Agent のデプロイメントおよび設定ドキュメントに従って、Kafka の Producer、Broker、Consumer 側に JMX Agent をインストール・設定し、Kafka メトリックを Alibaba Cloud Prometheus に公開する必要があります。

次に、ARMS アクセスセンターにアクセスして、コンポーネントアプリケーション「Kafka (Advanced Edition)」の「追加」ボタンをクリックし、ポップアップインターフェイスで Kafka のデプロイ環境を選択し（現在は「Alibaba Cloud Container Service 環境」と「Alibaba Cloud ECS 環境」をサポート）、Kafka が配置されている Prometheus インスタンスを選択して、監視アクセス用の設定情報を入力します。

• Exporter 名：現在の Kafka 監視の一意な名前。

• Kafka インスタンス名：Kafka インスタンス名。これを通じて Kafka の Producer、Broker、Consumer が関連付けられ、トピック全体のフルリンク表示を実現します。

• JMX Agent リッスンポート：JMX Agent のデプロイ時に設定したリッスンポート。

• メトリック収集パス：Prometheus が JMX Agent のメトリックを収集する HTTP パス。デフォルトは /metrics です。

• メトリック収集間隔（秒）：監視データの収集間隔。

• Pod/ECS タグ/タグ値：JMX Agent のデプロイ時に、Prometheus がサービス検出に使用する Pod/ECS に設定されたタグとタグ値。

• Advanced Edition 監視ダッシュボードの表示

Prometheus インスタンスの統合センターに入り、「Kafka (Advanced Edition)」をクリックして、ポップアップインターフェイスの「ダッシュボード」タブページを選択し、ダッシュボードのサムネイルをクリックして対応する Grafana ダッシュボードを表示します。Advanced Edition の監視は、Instance とトピックの 2 つの視点を提供します。

• 自己構築 Kafka インスタンスダッシュボード

Kafka Broker の内部インジケーターを表示します。

• コアインジケーター：Broker 数、オフラインパーティション、Under Replicated パーティション、Controller 数、CPU/ネットワークなどの重要情報。

• JVM インジケーター：JVM のメモリと GC の重要情報を表示します。

• パーティションインジケーター：パーティション数、ISR、Clean Leader 選出、レプリカ遅延、オフラインパーティション、Under Replicated パーティションなどの詳細情報を表示します。

• 時間インジケーター：Produce、Request、Fetch などの各環境の時間インジケーターを表示します。

• クラスタートラフィックインジケーター：クラスター全体のトラフィックインジケーターを表示します。

• Broker トラフィックインジケーター：Broker ごとのトラフィックインジケーターを表示します。

• 自己構築 Kafka トピックダッシュボード

各 Kafka トピックのフルリンクインジケーターを表示します。

• Producer：メッセージ送信速度、メッセージ圧縮率、送信遅延など、Producer 側の主要インジケーターを表示します。

• Server（Kafka Broker）：トピックに対応するパーティション数、流入/流出メッセージレート、流入/流出メッセージトラフィックを表示します。

• Consumer：メッセージ消費速度、消費遅延、リバランスなどを表示します。

• 自己構築 Kafka の Advanced Edition 監視アラームの設定

Prometheus インスタンスの統合センターに入り、「Kafka (Advanced Edition)」をクリックして、ポップアップインターフェイスの「アラーム」タブページを選択すると、現在の Prometheus インスタンスの Kafka Advanced Edition アラームルールを表示/追加できます。Kafka Advanced Edition は、Producer、Instance、Consumer のアラームインジケーターを提供し、ユーザーが選択・設定できます。Prometheus アラーム作成の詳細な手順は、Prometheus アラームルールのドキュメントを参照してください。

• 自己構築 Kafka Producer：メッセージ送信失敗率、メッセージ送信消費時間、メッセージ送信リトライ率の 3 つのアラームインジケーターを提供し、Producer 側の異常に対してアラームを設定できます。

• 自己構築 Kafka インスタンス：パーティション数の過多、オフラインパーティションの存在、Unclean Leader 選出の存在、Under Replicated パーティションの存在、有効 Broker 数の減少、有効 Controller 数、インスタンスのメッセージ拒否数、インスタンスのメッセージ流入/流出量、トピックのメッセージ流入/流出量など、13 のアラームインジケーターを提供し、Kafka Broker の異常のあらゆる側面をカバーします。

• 自己構築 Kafka Consumer：メッセージ消費滞留のアラームインジケーターを提供します。このアラームルールにより、ユーザーは消費異常を即座に把握できます。

まとめ

Alibaba Cloud Prometheus の Kafka 監視は、ApsaraMQ for Kafka の豊富な運用保守実績に基づき、Kafka コミュニティの運用保守提案と組み合わせた、Alibaba Cloud Kafka と自己構築 Kafka の監視のための統合ソリューションを提供します。

自己構築 Kafka のシナリオ特性に応じて、Basic Edition と Advanced Edition の監視アクセスを提供し、異なるシナリオと深さの Kafka 監視ニーズに対応します。同時に、コンテナサービス環境と ECS 環境の Kafka デプロイメントをサポートし、異なる環境のユーザーの監視ニーズに対応します。Kafka Advanced Edition は、200 以上の有効なメトリック、10 以上の主要ダッシュボードパネル、60 以上の補助ダッシュボードパネル、17 のアラームインジケーター（継続的に更新中）を提供し、フルリンクで統合されたエキスパートレベルの Kafka 監視サポートにより、ビジネスの安定稼働を確保します。

今後は、自己構築 Kafka Advanced Edition のデプロイメントの利便性を継続的に最適化し、ユーザーの JMX Agent デプロイ操作をさらに簡素化していきます。同時に、JMX Agent のパフォーマンスをさらに最適化し、自己構築 Kafka Broker の CPU 消費を削減する予定です。