Prometheus Monitoring RocketMQ Best Practices

Prometheus が統合する 50 以上のクラウドプロダクトの中で、RocketMQ は特に代表的なクラウドプロダクトであり、可観測性において非常に完成度の高い機能を実現しています。

RocketMQ の Prometheus 連携方法

RocketMQ は Alibaba の内部コア E コマースシステムから生まれ、ビジネスメッセージ向けの MQ プラットフォームとして選ばれています。上図は RocketMQ 5.0 システムの全体像を示しています。アクセス層、コアコンポーネント、基盤の運用保守において大幅な改善が行われ、多様な機能、高性能、高信頼性、可観測性、運用保守の容易さなど、多くの利点を備えています。

メトリック、トレース、ログは可観測性の 3 つの柱です。

1. メトリック：RocketMQ は、オープンソース分野で広く使用されている Prometheus + Grafana のプロダクトポートフォリオに基づく、すぐに使えるダッシュボードをユーザーに提供します。メトリックはメッセージ量、滞留量、各段階の処理時間などをカバーしています。このダッシュボードは、RocketMQ チームがメッセージング分野で長年の研究開発と運用保守の経験を通じて磨き上げたベストプラクティステンプレートを組み合わせており、継続的な反復更新機能を提供します。

2. トレース：RocketMQ は、オープンソース標準の OpenTelemetry Tracing を初めて導入し、メッセージディメンションに沿って抽象スパントポロジーを再構成しました。

3. ログ：ログの面では、クライアントログの一部が標準化され、ログを使用した問題の特定が容易になりました。

RocketMQ のすべての可観測性データは、プロデューサー側とサーバー側のメッセージの処理と消費の各段階を中心に構成されています。メッセージのライフサイクル図から、プロデューサーから MQ サーバーへのメッセージ送信にかかる時間が確認できます。スケジュールメッセージの場合は、Ready 時刻からスケジュール時刻を把握できます。コンシューマーの観点からは、メッセージのプル開始からクライアントへの到着までのネットワーク処理時間がわかります。クライアントへの到着からメッセージ処理開始までの処理リソース待機時間、そしてメッセージ処理開始から最終的な ACK 応答までの処理時間も把握できます。メッセージはライフサイクルのどの段階でも明確に定義され、観測可能です。これが RocketMQ の可観測性の中核概念です。

RocketMQ チームが貢献した RocketMQ exporter は、Prometheus の公式オープンソース exporter エコシステムに登録されており、ブローカー、プロデューサー、コンシューマーの各段階に豊富なモニタリングメトリックを提供します。Exporter の基本的な仕組みは、内部で複数のスケジュールタスクを起動して MQ クラスターから定期的にデータを取得し、正規化後にエンドポイントを通じて Prometheus にデータを公開するというものです。MQAdminExt クラスは、MQAdmin が公開するさまざまなインターフェースロジックをカプセル化しています。構造的な観点から見ると、RocketMQ の Exporter は第三者視点のオブザーバーであり、すべてのメトリックは MQ クラスター内部から取得されます。

Prometheus でアプリケーションのモニタリングメトリックを公開する際、次の 2 点に注意する必要があります。

1. Exporter のデプロイモードは、Prometheus クライアントをアプリケーションに埋め込む直接観測モードと、アプリケーション外部の独立 Exporter モードに分けられます。直接観測モードは、主流言語のサポート、優れたパフォーマンス、メンテナンスフリーという利点がある一方、コードの結合が欠点です。Exporter モードは、疎結合と豊富なオープンソースエコシステムが利点ですが、別途 Exporter コンポーネントの運用保守が必要なのが最大の欠点です。クラウドネイティブマイクロサービスのアーキテクチャでは、複数の Exporter のデプロイが運用保守に大きな負担をかけます。デプロイモードに優劣はなく、アプリケーションコードを制御できる場合は直接観測モードを、制御できない場合は Exporter モードを選択することが一般的に推奨されます。

2. メトリックのディメンション拡散による高カーディナリティの問題を回避するよう努めてください。Prometheus のメトリックモデルのディメンション拡張にラベルを 1 つ追加するだけでよいため、多くのユーザーが必要なだけディメンションを追加します。これにより、userid、url、email、IP など、列挙不可能なディメンションが必然的に導入されます。Prometheus の時系列データの総数は、メトリックとディメンションの組み合わせで計算されます。そのため、高カーディナリティの問題はストレージコストの大幅な増加だけでなく、瞬間的に返されるデータ量が膨大になることでクエリ側にも重大なパフォーマンス課題をもたらし、ディメンションの過度な拡散はメトリック自体の統計的意義を失わせます。したがって、使用プロセスではメトリックディメンションの拡散を可能な限り回避する必要があります。

Prometheus Client の使用時に高カーディナリティの問題に直面します。特に RocketMQ のメトリックは、アカウント、インスタンス、Topic、コンシューマーグループ ID など複数のディメンションの組み合わせを提供するため、時系列データの総数が高い水準にあります。実践の過程で、Prometheus ネイティブクライアントに対して 2 つの最適化を実施し、Exporter の高カーディナリティによる潜在的なメモリ問題を効果的に抑制しました。

RocketMQ の本番環境では、販売テナントの顧客レベルモニタリングが必要です。各顧客の RocketMQ リソースはテナントごとに厳密に分離されています。各テナントに Exporter のセットをデプロイすると、プロダクトアーキテクチャと運用保守に大きな課題が生じます。そのため、RocketMQ は本番環境で Prometheus にアクセスする別の方法を選択しました。

RocketMQ 5.0 のアーキテクチャは大幅に改善されました。軽量な多言語クライアント基盤層は、gRPC プロトコルを使用してサーバーにデータを送信するよう統一されました。同時に、MQ サーバーも CBroker (プロキシ) と SBroker の 2 つのロールに分割され、分離と組み合わせが可能です。アーキテクチャの変更に合わせ、RocketMQ 5.0 はクライアントとサーバーの両側に OpenTelemetry トレース標準の計装ポイント仕様を導入しました。

フルリンクトレース

1. クライアントに組み込まれた OpenTelemetry Exporter が、トレースデータをバッチでプロキシに送信します。

2. プロキシ自体がコレクターとして機能し、クライアントから報告されたトレースデータと自身のデータを統合します。

3. トレースストレージは、ユーザー定義のコレクター、商用ホスティングストレージ、オープンソースストレージに対応し、各自のプラットフォームにレポートできます。

4. メッセージのライフサイクルに合わせて、スパントポロジーモデルを再設計しました。

正確で多様なメトリック

1. サーバー側で受信したトレースデータに対して二次集計計算を実行し、計算されたメトリックは OpenMetrics 仕様に準拠します。

2. Prometheus ストレージおよび Grafana のダッシュボード表示とシームレスに統合できます。

RocketMQ のスパントポロジーモデルでは、Prod、Recv、Await、Proc、ACK/Back の各フェーズの計装ポイントを再正規化し、OpenTelemetry トレースモデルの属性部分を OpenTelemetry 仕様組織に提出して採用されました。

上記の改善により、メッセージトレース機能が大幅に向上しました。メッセージの基本情報に基づく関連トレースの照会だけでなく、メッセージライフサイクルの各段階も明確に把握できます。トレース ID をクリックすると、詳細なトレース情報や、プロデューサー、コンシューマー、マシン情報などの関連リソースの表示を確認できます。

なぜ RocketMQ のメトリックデータを Prometheus に連携すべきなのでしょうか。Prometheus はクラウドネイティブアーキテクチャに自然に適合し、オープンソース分野でメトリックのデファクトスタンダードの地位を確立しているからです。Prometheus はネイティブクラウドアーキテクチャであり、Kubernetes と自然に統合され、自動検出、多段収集、強力なエコシステム、汎用マルチモーダルメトリックモデル、強力な PromQL クエリ構文などの機能を備えています。

RocketMQ はトレースデータに基づいて二次計算を実行し、メトリックを生成して Prometheus と連携します。前述の通り、RocketMQ 5.0 は OpenTelemetry トレースの計装ポイントを導入しました。クライアントとサーバーから報告されるトレースデータを Alibaba Cloud のログシステムに一元保存します。トレースデータに基づき、複数のディメンションで二次集計を実行して、Prometheus メトリック仕様に準拠した時系列データを生成します。ARMS チーム内で、リアルタイム ETL ツールを通じてログデータがメトリックに変換され、テナントごとに Prometheus システムに保存されます。RocketMQ コンソールは Grafana のダッシュボードやアラートモジュールと深く統合されています。ユーザーは RocketMQ のインスタンス監視ページで Prometheus を有効化するだけで、独自のダッシュボードとアラート情報をワンクリックで入手できます。

ARMS Prometheus は、多くのクラウドプロダクトのモニタリングメトリックを統合し、クラウドプロダクトのマルチテナント要件に対する包括的なソリューションを提供します。Alibaba Cloud のクラウドプロダクトは、プロダクト自体のメトリック監視に加えて、プロダクト販売先のテナントメトリックも監視する必要があります。

クラウドプロダクトはテナントリソースの形態によって分類され、主にテナント専用リソースモードとテナント共有リソースモードがあります。テナント専用リソースモードは、テナントがデプロイリソースを独立して占有し、高い分離性を持つことが特徴です。メトリックを識別するテナント情報は、テナントメトリックにマーキングするだけで済みます。テナント共有リソースモードは、テナントがデプロイリソースを共有する形態で、メトリックを識別するテナント情報はクラウドプロダクト側で追加する必要があります。

オープンソース Prometheus と比較して、ARMS Prometheus モニタリングは収集とストレージを分離したアーキテクチャを採用しています。収集側はマルチテナントの識別と配信機能を備え、ストレージ側はマルチテナント構築機能を備え、テナント間のリソースは完全に分離されています。

ARMS Prometheus は、各 Alibaba Cloud ユーザーに対して Prometheus クラウドサービスのインスタンスを作成し、ユーザーの対応する Alibaba Cloud プロダクトメトリックを保存します。これにより、監視システムデータの分散によるデータアイランドの問題を真に解決し、各クラウドプロダクトに深いカスタマイズ、すぐに使えるダッシュボード、アラート機能を提供します。

上図は RocketMQ のデフォルト統合 Grafana ダッシュボードの例です。このダッシュボードは、概要、Topic メッセージ送信、グループ ID メッセージ消費などのきめ細かいモニタリングデータサポートを提供します。オープンソース実装と比較して、より多くて正確なメトリックデータを提供し、RocketMQ チームがメッセージング分野で長年の運用保守経験を通じて磨き上げたベストプラクティステンプレートを組み合わせて、継続的な反復更新機能を提供します。

RocketMQ の可観測性ベストプラクティス

メッセージシステムが提供する観測可能なデータだけに注目しても、一部の問題しか発見できません。実際のマイクロサービスシステムでは、アクセス層、業務アプリケーション、ミドルウェア、コンテナ、基盤 IaaS など、全体のテクノロジースタックにおける観測可能なデータに注目することで、正確に問題を特定できます。上図はメッセージングシステムの非常に典型的な上流・下流アプリケーション構造を示しています。上流の注文システムがメッセージを送信し、下流の在庫システムとマーケティングシステムがメッセージをサブスクライブして、上流と下流のデカップリングを実現します。このような複雑な業務システムで問題を発見し解決するには、システム全体の可観測性を包括的に見直す必要があります。

まず、システムの各コンポーネントの観測可能なデータを収集する必要があり、メトリック、トレース、ログの 3 つの柱が不可欠です。メトリックはアプリケーションステータスを計測し、メトリックアラートを通じて迅速に問題を発見できます。トレースデータはリクエストレベルで全サイクルのパスを追跡し、コールチェーンを確認して迅速に問題を特定できます。ログデータはシステムが生成するイベントを詳細に記録し、ログ分析を通じて迅速にトラブルシューティングを行えます。

上図は ARMS Kubernetes モニタリングの診断経験を示しています。テクノロジースタックのエンドツーエンドかつトップダウンの全スタック相関を通じて、水平方向と垂直方向の観測可能な問題の診断と特定に実用的なアプローチを提供します。業務関連コンポーネントにはユーザーエクスペリエンスに影響する RED メトリック (Request, Error, Duration) に注目し、リソースレベルではリソース飽和に関連するメトリックにより注目する必要があります。同時に、水平方向でログ、イベント、コールチェーンの関連性にも注意を払う必要があります。多方向的で包括的な観測によってのみ、問題の所在をより明確に特定できます。

上図はメッセージ滞留シナリオの例を示しています。

まず、メッセージ滞留のメトリックの意味を理解する必要があります。Producer が送信したメッセージは、メッセージキューでの処理と Consumer による消費の 3 つのフェーズ、すなわち Ready、InFlight、Received を経ます。注目すべき 2 つのメトリックがあります。Ready メッセージは準備完了メッセージの数を示し、その大きさで未消費メッセージの量を把握できます。コンシューマーに異常がある場合、Ready メッセージのデータ量が増加します。メッセージキュー滞留時間は、最も古い Ready メッセージの ready 時刻と現在時刻の差を示し、この時間の大きさで未処理メッセージの遅延時間を把握できます。時間に敏感なビジネスにとって非常に重要なメトリックです。

メッセージ滞留の主な原因は 2 つあります。コンシューマーの障害または消費能力不足、あるいは上流の生産側のメッセージ量過多と下流の消費能力不足です。

生産側では、メッセージ送信の健全性により注目し、送信成功率についてアラート設定を行えます。アラート発生時には、負荷、送信時間、メッセージ量などのメトリックを確認して、メッセージ量の急激な変化がないかを判断する必要があります。コンシューマーが注目すべき消費のタイムリー性については、Ready メッセージのキュー滞留時間についてアラート設定を行えます。アラート発生時には、メッセージ処理時間、消費成功率、メッセージ量、負荷などの関連メトリックを確認し、メッセージ量の変化や消費処理時間を判断し、エラーログやトレースなどの関連情報を照会する必要があります。

上記のトラブルシューティングプロセスをより容易かつ迅速に処理するために、Alibaba Cloud ARMS プロダクトを活用できます。

アラート情報を受信した後、ビジネストポロジーの変化、例外ラベル、ビジネス指標のクエリを通じて、関連するコールチェーン情報を確認できます。ビジネス処理の各段階の処理時間や例外の有無などの関連情報をコールチェーン上で取得できます。コールチェーンの各スパンノードからドリルダウンして、リアルタイムでコールスタックと処理時間の割合をクエリし、ビジネスコードレベルまで問題を特定できます。ユーザーがログに接続した traceID が ARMS 仕様に従ってコールチェーンに関連付けられていれば、ワンクリックで対応するログの詳細を確認し、最終的に問題の根本原因を特定できます。

問題発生時には、便利で迅速な問題特定プロセスに加えて、アラートに対する比較的完全なアラート処理と緊急対応メカニズムを提供する必要があります。ARMS アラートは、アラート設定、アラートスケジューリング、アラート処理の全プロセス機能をユーザーに提供し、緊急対応、事後レビュー、メカニズム最適化の確立を容易にします。

同時に、ARMS のインテリジェントアラートプラットフォームは 10 以上のモニタリングデータソースの統合とマルチチャンネルデータプッシュをサポートします。DingTalk ベースの ChatOps により、アラートの協調性、追跡可能性、統計性を確保します。例外検出やインテリジェントノイズ低減などのアルゴリズム機能も提供し、無効なアラートを効果的に削減し、アプリケーションコンテキストに基づいたアラートの根本原因分析を提供します。

Alibaba Cloud ARMS モニタリングは、ユーザーの端末、アプリケーション、クラウドサービス / サードパーティコンポーネント、コンテナ、インフラストラクチャを上下にカバーし、包括的で立体的な統合モニタリング・統合アラート機能を提供します。エンタープライズ向けのワンストップ可観測性ベストプラクティスプラットフォームです。