すべてのプロダクト
Search
ドキュメントセンター

ApsaraMQ for RocketMQ:リスク警告のモニタリングとアラート機能の設定

最終更新日:Jan 24, 2025

ApsaraMQ for RocketMQでは、CloudMonitorを使用してアラートルールを設定できます。 これにより、インスタンスのステータスと主要なメトリックをリアルタイムで監視でき、実稼働環境でリスク警告を実装するための最も早い機会に例外通知を受け取ることができます。

背景情報

ApsaraMQ for RocketMQは、インスタンスエディションごとにフルマネージドメッセージングサービスとサービスレベルアグリーメント (SLA) を提供します。 ApsaraMQ for RocketMQインスタンスを購入すると、1秒あたりのメッセージングトランザクション (TPS) やメッセージストレージ機能など、インスタンスの機能が保証されます。

インスタンスのパフォーマンスについて心配する必要はありません。 ただし、本番環境でインスタンスの使用状況を監視して、インスタンスに指定されているしきい値を超えないようにする必要があります。 ApsaraMQ for RocketMQCloudMonitorと統合され、モニタリングおよびアラートサービスを無料で提供し、すぐに使用できます。 サービスを使用して, 次の项目を监视できます。

  • インスタンスの使用状況

    実際のインスタンス使用量が仕様の制限を超えている場合、ApsaraMQ for RocketMQはインスタンスを強制的にスロットルします。 インスタンススロットリングによって引き起こされる障害を防ぐために、事前にインスタンス使用アラートを設定し、過剰な使用リスクが検出されたときにインスタンス設定をアップグレードできます。

  • ビジネス論理エラー

    メッセージの送受信時にエラーが発生することがあります。 呼び出しエラーアラートを設定して、エラーを検出および修正し、ビジネスへの悪影響を防ぐことができます。

  • パフォーマンスメトリクス

    応答時間 (RT) やメッセージ遅延などのパフォーマンスメトリックがメッセージシステムに必要な場合は、ビジネスリスクを防ぐために、対応するメトリックアラートを事前に設定できます。

アラートを設定するためのルール

ApsaraMQ for RocketMQは、さまざまなメトリクスとモニタリングおよびアラート項目を提供します。 詳細については、「ダッシュボード」および「モニタリングとアラート」をご参照ください。 監視項目は、リソース使用量、メッセージングパフォーマンス、およびメッセージングエラーのカテゴリに分類できます。

本番環境で蓄積されたベストプラクティスに基づいて、次の表に記載されているルールに従ってアラートを設定することをお勧めします。

説明

以下のモニタリング項目は、Alibaba Cloudが推奨する基本設定です。 ApsaraMQ for RocketMQには、その他のモニタリング項目もあります。 ビジネス要件に基づいてきめ細かいアラートを設定できます。 詳細については、「モニタリングとアラート」をご参照ください。

カテゴリ

モニタリングアイテム

設定のタイミングと理由

関连担当者

リソース使用量

インスタンスのAPI呼び出し

  • インスタンスの作成直後にこの項目を設定することを推奨します。

  • インスタンスのリソース使用量は、1つのトピックまたはグループによって決定されません。 インスタンスの全体的なリソース使用量を考慮する必要があります。

リソース演算子

メッセージングのパフォーマンス

  • トピックでTPSを送信するメッセージ

  • コンシューマーグループでTPSを受信するメッセージ

  • コンシューマーグループでのメッセージの蓄積

  • コンシューマグループの消費遅延時間

  • ビジネスの開始直後にこれらの項目を設定することを推奨します。

  • ビジネスの開始後、ビジネスのメッセージングパフォーマンスを見積もる必要があります。

  • リソース演算子

  • ビジネス开発者

メッセージングエラー

  • デッドレターメッセージの生成

  • スロットリングが発生する回数

  • ビジネスの開始直後にこれらの項目を設定することを推奨します。

  • ビジネスの立ち上げ後、メッセージの作成中に発生する可能性のある障害を予測する必要があります。 これは問題のトラブルシューティングに役立ちます。

  • リソース演算子

  • ビジネス开発者

アラートを設定する手順

  1. ApsaraMQ for RocketMQコンソールにログインします。 左側のナビゲーションウィンドウで、インスタンス数 をクリックします。

  2. 上部のナビゲーションバーで、中国 (杭州) などのリージョンを選択します。 [インスタンス] ページで、管理するインスタンスの名前をクリックします。

  3. 左側のナビゲーションウィンドウでモニタリングおよびアラート をクリックします。 表示されるページの左上隅にある アラートルールの作成 をクリックします。

ベストプラクティス

インスタンスのAPI呼び出し数に関するアラートの設定

  • 背景: ApsaraMQ for RocketMQでは、インスタンスでメッセージを送受信するために開始できるAPI呼び出しの数は、TPSのメッセージングによって測定されます。 ピークメッセージングTPSは、各インスタンスに対して指定される。 インスタンスのメッセージングTPSが仕様の制限を超えた場合、インスタンスはスロットルされます。 たとえば、Standard Editionインスタンスの場合、5,000のピークTPSが指定されます。 制限を超えた場合、インスタンスはスロットルされます。

  • アラートを設定しないことによるリスク: アラートを設定しない場合、API呼び出しの数が仕様の制限を超える前にアラートを受信することはできません。 その結果、インスタンスが抑制され、特定のメッセージの送受信に失敗します。

  • 設定のタイミング: インスタンスの作成後にアラートを設定することを推奨します。

image

  • 推奨しきい値: アラートしきい値をインスタンスのピークメッセージングTPSの70% に設定することを推奨します。 たとえば、購入したインスタンスのピークメッセージングTPSが10,000の場合、アラートしきい値を7,000に設定します。 ApsaraMQ for RocketMQコンソールの [インスタンスの詳細] ページで、ApsaraMQ for RocketMQインスタンスのピークメッセージングTPSを確認できます。

  • アラート処理: API呼び出しの数に関するアラートを受け取った後、次の手順を実行してアラートを処理することを推奨します。

    1. [インスタンスの詳細] ページで、[ダッシュボード] タブをクリックします。

    2. [インスタンスメッセージ量の概要] セクションで、[TPS最大値] の曲線を [インスタンスのリクエスト時間 (運用と消費) に関するメトリック] に表示します。

    3. [Message Business Metricsの概要] セクションで、[Message production rate top20 Topics (bar/minute)] および [message consumption rate top20 GroupID (per minute)] の曲線を表示します。 次に、データが異常なトピックとグループを見つけ、ビジネスの変化が正常かどうかを分析します。

    4. ビジネスの変化が異常な場合は、ユーザーに連絡してさらに分析してください。

    5. ビジネスの変更が正常な場合、インスタンスのコンピューティング仕様は正常なビジネス操作を維持するには不十分です。 この場合、インスタンス設定をアップグレードすることを推奨します。 詳細については、「インスタンス設定のアップグレードまたはダウングレード」をご参照ください。

プロデューサーが送信したメッセージ数またはコンシューマーが1分あたりに受信したメッセージ数に関するアラートの設定

  • 背景: ApsaraMQ for RocketMQは、トピックおよび消費者グループごとにメッセージングTPSを監視するためのメトリックを提供します。 メトリックを使用して、特定のビジネスアイテムのメッセージングTPSを監視し、ビジネス規模を把握できます。

  • アラートを設定しないことによるリスク: トピック内のメッセージングTPSは、トピック内のメッセージを送受信するために開始できるAPI呼び出しの数を指定します。 アラートを設定しない場合、トラフィックがゼロになるまで、またはトラフィックのスパイクが発生するまで、アラートを受信できません。 これは予期しないリスクを引き起こす可能性があります。

  • 設定のタイミング: ビジネスが安定した後にアラートを設定することを推奨します。

プロデューサーが1分あたりに送信するメッセージ数に関するアラートの設定

image

  • 推奨しきい値: ビジネスが安定した後のトラフィック量に基づいてしきい値を設定することを推奨します。

  • アラート処理: 1分あたりにプロデューサーから送信されたメッセージ数に関するアラートを受信した後、次の手順を実行してアラートを処理することを推奨します。

    1. [トピック] ページで、アラートルールで設定されたトピックの名前をクリックします。

    2. [トピックの詳細] ページで、[ダッシュボード] タブをクリックします。

    3. メッセージボリューム (ピース /分)プロダクションカーブを表示します。 次に、ビジネスモデルに基づいて変更が正常かどうかを判断します。

コンシューマーが1分あたりに受信したメッセージ数に関するアラートの設定

image

  • 推奨しきい値: ビジネスが安定した後のトラフィック量に基づいてしきい値を設定することを推奨します。

  • アラート処理: コンシューマが1分あたりに受信したメッセージ数に関するアラートを受信した後、次の手順を実行してアラートを処理することを推奨します。

    1. [グループ] ページで、アラートルールで設定されたグループのIDをクリックします。

    2. [グループの詳細] ページで、[ダッシュボード] タブをクリックします。

    3. メッセージの生成と消費率 (バー /分)消費曲線を表示します。 次に、ビジネスモデルに基づいて変更が正常かどうかを判断します。

メッセージ蓄積アラートの設定

説明

変動およびエラーは、メッセージ蓄積に関する統計に存在し得る。 蓄積されたメッセージのしきい値を100未満に設定しないことを推奨します。 蓄積されたメッセージの数が少なくてもビジネスに影響がある場合は、メッセージの蓄積を監視するように消費遅延時間アラートを設定することを推奨します。

  • 背景: ApsaraMQ for RocketMQでは、コンシューマーグループごとにメッセージの蓄積を監視できます。 メッセージ蓄積アラートを使用して、メッセージ蓄積によって引き起こされる障害を防ぐことができます。

  • アラートを設定しないことによるリスク: メッセージの蓄積は、ApsaraMQ for RocketMQの典型的なシナリオと機能です。 メッセージをリアルタイムで処理する必要があるシナリオでは、メッセージの蓄積によるビジネスへの悪影響を防ぐために、蓄積されたメッセージの数を監視および管理する必要があります。

  • 設定のタイミング: ビジネスが安定した後にアラートを設定することを推奨します。

image

  • 推奨しきい値: ビジネスの実際のパフォーマンスに基づいてしきい値を設定することを推奨します。

  • アラート処理: メッセージ蓄積アラートを受信した後、次の手順を実行してアラートを処理することを推奨します。

    1. [グループ] ページで、アラートルールで設定されたグループのIDをクリックします。

    2. [グループの詳細] ページで、[ダッシュボード] タブをクリックします。

    3. スタック関連インジケーター (バー)累積曲線を表示します。 次に、蓄積されたメッセージの変化傾向を分析し、メッセージ蓄積の開始時間を見つけます。

    4. ビジネスの変更とアプリケーションログに基づいて、メッセージの蓄積の原因を分析します。 詳細については、「蓄積されたメッセージをどのように処理できますか?」をご参照ください。

    5. メッセージの蓄積の原因に基づいて、コンシューマアプリケーションをスケールアウトするか、消費ロジックの欠陥を修正するかを決定します。

消費遅延時間アラートの設定

説明

消費遅延時間は、消費者グループ内の最初の消費されていないメッセージの遅延時間に基づいて計算される。 消費遅延時間は累積的であり、ビジネスの変化に敏感です。 消費遅延時間アラートを受信した後、少数のメッセージまたはすべてのメッセージが遅延しているかどうかを判断する必要があります。

  • 背景: ApsaraMQ for RocketMQでは、消費者グループごとに消費遅延を監視できます。 消費遅延時間アラートは、メッセージ蓄積を分析するための詳細なメトリックを提供します。

  • アラートを設定しないことによるリスク: メッセージの蓄積は、ApsaraMQ for RocketMQの典型的なシナリオと機能です。 メッセージをリアルタイムで処理する必要があるシナリオでは、メッセージの蓄積によるビジネスへの悪影響を防ぐために、蓄積されたメッセージの数を監視および管理する必要があります。

  • 設定のタイミング: ビジネスが安定した後にアラートを設定することを推奨します。

image

  • 推奨しきい値: ビジネスの実際のパフォーマンスに基づいてしきい値を設定することを推奨します。

  • アラート処理: メッセージ蓄積アラートを受信した後、次の手順を実行してアラートを処理することを推奨します。

    1. [グループ] ページで、アラートルールで設定されたグループのIDをクリックします。

    2. [グループの詳細] ページで、[ダッシュボード] タブをクリックします。

    3. スタック関連インジケーター (バー)累積曲線を表示します。 次に、蓄積されたメッセージの変化傾向を分析し、メッセージ蓄積の開始時間を見つけます。

    4. ビジネスの変更とアプリケーションログに基づいて、メッセージの蓄積の原因を分析します。 詳細については、「蓄積されたメッセージをどのように処理できますか?」をご参照ください。

    5. メッセージの蓄積の原因に基づいて、コンシューマアプリケーションをスケールアウトするか、消費ロジックの欠陥を修正するかを決定します。

無効メッセージアラートの設定

  • 背景: ApsaraMQ for RocketMQは、着信メッセージをサポートしています。 指定された最大リトライ回数に達した後に消費されないメッセージは、デットレターキューに送信されます。 デッドレターメッセージを管理できます。 デッドレターメッセージの数を監視して、ビジネスの予期しない問題や例外を検出することができます。

  • アラートを設定しないことによるリスク: デッドレターメッセージは、コンシューマーが正しく処理できないメッセージです。 消費アプリケーションは、デットレターメッセージを処理する必要があります。 無効メッセージのアラートを設定しないと、メッセージの消費が不完全になる可能性があります。

  • 設定のタイミング: ビジネスが安定した後にアラートを設定することを推奨します。

image

  • 推奨しきい値: ビジネスが安定した後のトラフィック量に基づいてしきい値を設定することを推奨します。

  • アラートの処理: 無効メッセージに関するアラートを受信した後、次の手順を実行してアラートを処理することを推奨します。

    1. デッドレターメッセージを照会し、元のメッセージを分析します。 詳細については、「Dead-letterキュー」をご参照ください。

    2. メッセージの消費トレースを照会し、トピックとメッセージIDに基づいて消費失敗の原因を分析します。 詳細については、「メッセージトレースの照会」をご参照ください。

    3. メッセージ消費失敗の原因に基づいて、適切なソリューションを決定します。

スロットリングの発生回数に関するアラートの設定

  • 背景: ApsaraMQ for RocketMQでは、特定のインスタンスでスロットルをトリガーするイベントをアラートメトリックとして使用できます。 これは、ビジネスへの悪影響を理解するのに役立ちます。

  • アラートを設定しないことによるリスク: スロットリングが発生する回数が多い場合は、トラフィック使用量が仕様の制限を頻繁に超えていることを示します。 この場合、インスタンス設定をアップグレードすることを推奨します。

  • 設定のタイミング: ビジネスが安定した後にアラートを設定することを推奨します。

    • インスタンスの作成後にインスタンスでスロットリングが発生する回数に関するアラートを設定することを推奨します。

    • ビジネスが安定した後、トピックまたはコンシューマーグループでスロットリングが発生する回数に関するアラートを構成することをお勧めします。

image

  • 推奨しきい値: ビジネスの実際のパフォーマンスに基づいてしきい値を設定することを推奨します。

  • アラート処理: スロットリングの発生回数に関するアラートを受信した後、次の手順を実行してアラートを処理することを推奨します。

    1. [インスタンスの詳細] ページで、[ダッシュボード] タブをクリックします。

    2. [インスタンスメッセージ量の概要] セクションで、[スロットリングリクエスト数] の曲線を表示します。 次に、スロットリングが発生する時間とスロットリングのルールを分析します。

    3. [Message Business Metricsの概要] セクションで、[Message production rate top20 Topics (bar/minute)] の曲線を表示します。 次に、スロットリングが発生した時間とスロットリングのルールに基づいてデータが異常なトピックを見つけ、トピックの曲線を表示して、トラフィックの増加がビジネス要件を満たしているかどうかを判断します。

    4. トラフィックの増加がビジネス要件を満たしている場合は、インスタンス設定をアップグレードします。 それ以外の場合は、問題のトラブルシューティングを行います。