Amazon MQ での ActiveMQ のトラブルシューティング Amazon MQ - Amazon MQ
CloudWatch Logs の取得再起動後にブローカーに接続する一部のクライアントは接続できませんウェブコンソールでの JSP 例外

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon MQ での ActiveMQ のトラブルシューティング Amazon MQ

このセクションの情報を使用して、Amazon MQ ブローカーで ActiveMQ を使用する際に発生する可能性がある一般的な問題の診断と解決に役立ててください。

ロギングをアクティブにしているにもかかわらず、CloudWatch Logs にブローカーの一般ログまたは監査ログが表示されません。

CloudWatch Logs でブローカーのログを表示できない場合は、以下の手順を実行します。

  1. ブローカーを作成または再起動するユーザーに logs:CreateLogGroup アクセス許可があるかどうかを確認します。ユーザーがブローカーの作成または再起動を行う前に CreateLogGroup 許可をユーザーに追加しなければ、Amazon MQ はロググループを作成しません。

  2. Amazon MQ が CloudWatch Logs にログを発行することを許可するリソースベースポリシーが設定されているかどうかをチェックします。CloudWatch Logs ロググループへのログの発行を Amazon MQ に許可するには、以下の CloudWatch Logs API アクションに対するアクセス権を Amazon MQ に付与するリソースベースポリシーを設定します。

    • CreateLogStream – 指定したロググループの CloudWatch Logs ログストリームを作成します。

    • PutLogEvents – 指定された CloudWatch Logs ログストリームにイベントを配信します。

CloudWatch Logs にログを発行するように Amazon MQ で ActiveMQ を設定する方法の詳細については、「ログ記録の設定」を参照してください。 Amazon MQ

ブローカーの再起動またはメンテナンスウィンドウ後、ステータスが RUNNING であってもブローカーに接続できない。なぜですか?

開始したブローカーの再起動後、スケジュールされたメンテナンスウィンドウの完了後、またはスタンバイインスタンスがアクティブ化された障害イベントで、接続の問題が発生する可能性があります。いずれの場合も、ブローカーの再起動後の接続の問題は、ブローカーの Amazon EFS または Amazon EBS ストレージボリュームに保持されるメッセージが異常に多数であることが原因である可能性が最も高いです。再起動中、Amazon MQ は永続化されたメッセージをストレージからブローカメモリに移動します。この診断を確認するには、CloudWatch で Amazon MQ for ActiveMQ ブローカーの次のメトリクスを監視します。

  • StoragePercentUsage — 100% に近づくほど割合が大きいと、ブローカーは接続を拒否する可能性があります。

  • JournalFilesForFullRecovery — クリーンでないシャットダウンおよび再起動後に再生されるジャーナルファイルの数を示します。値が増加する、または常に高い値は、再起動後に接続の問題を引き起こす可能性のある未解決のトランザクションを示します。

  • OpenTransactionCount — 再起動後にゼロより大きい数字は、ブローカーが以前に消費されたメッセージを保存しようとし、その結果、接続の問題が発生することを示します。

この問題を解決するには、XA トランザクションを rollback() または commit() で解決することをお勧めします。詳細および rollback() を使用して XA トランザクションを解決するコード例を確認するには、「XAトランザクションの回復」を参照してください。

一部のクライアントはブローカーに接続していますが、他のクライアントは接続できません。

ブローカーが RUNNING ステータスであり、一部のクライアントはブローカーに正常に接続できますが、他のクライアントは正常に接続できません。ブローカーのワイヤレベル接続の上限に達している可能性があります。ワイヤレベルの接続制限に達したことを確認するには、次の手順を実行します。

  • CloudWatch Logs で Amazon MQ ブローカーの ActiveMQ の一般的なブローカーログを確認します。 Amazon MQ 上限に達した場合は、ブローカーログに Reached Maximum Connections が表示されます。Amazon MQ ブローカーでの ActiveMQ の CloudWatch Logs の詳細については、「」を参照してくださいCloudWatch Logs でのロギングの構造を理解する。

ワイヤレベルの接続制限に達すると、ブローカーは追加の着信接続を積極的に拒否します。この問題を解決するには、ブローカーインスタンスタイプをアップグレードすることをお勧めします。ワークロードに最適なインスタンスタイプの選択の詳細については、「Broker instance types」を参照してください。

ワイヤレベル接続の数がブローカー接続制限を下回っていることを確認できた場合、問題はクライアントの再起動に関連している可能性があります。ブローカーのログで、... Inactive for longer than 600000 ms - removing ... の多数で頻繁なエントリを確認してください。ログエントリは、クライアントの再起動または接続の問題を示しています。この影響は、頻繁にブローカーを切断して再接続するクライアントと Network Load Balancer (NLB) を介してブローカーに接続する場合に顕著になります。これは通常、コンテナベースのクライアントで観察されます。

詳細については、クライアント側のログを確認してください。ブローカーは 600000 ミリ秒後に非アクティブな TCP 接続をクリーンアップし、接続ソケットを解放します。

オペレーションを実行すると、ActiveMQ コンソールに例外 org.apache.jasper.JasperException: An exception occurred processing JSP page が表示されます。

簡易認証を使用していて、キューとトピックの認可に AuthorizationPlugin を設定している場合は、XML 設定ファイルで AuthorizationEntries 要素を使用し、activemq-webconsole グループにすべてのキューとトピックへのアクセス許可を付与してください。これにより、ActiveMQ ウェブコンソールが ActiveMQ ブローカーと通信できるようになります。

次のサンプルの AuthorizationEntry は、activemq-webconsole グループにすべてのキューとトピックの読み取りおよび書き込みの許可を付与します。

<authorizationEntries>
    <authorizationEntry admin="activemq-webconsole,admins,users" topic=">" read="activemq-webconsole,admins,users" write="activemq-webconsole,admins,users" />
    <authorizationEntry admin="activemq-webconsole,admins,users" queue=">" read="activemq-webconsole,admins,users" write="activemq-webconsole,admins,users" />
</authorizationEntries>

同様に、ブローカーを LDAP に統合する場合は、必ず amazonmq-console-admins グループに許可を付与してください。LDAP 統合の詳細については、LDAP 統合の仕組み を参照してください。