翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# トラブルシューティング: 一般的な Amazon MQ
このセクションの情報を使用して、ブローカーへの接続問題、またはブローカーの再起動などの、Amazon MQ ブローカーの使用時に発生する可能性がある一般的な問題の診断に役立てます。
**Contents**
+ [ブローカーのウェブコンソールまたはエンドポイントに接続できません。](#issues-connecting-to-console-or-endpoint)
+ [ブローカーが実行中であり、`telnet` を使用して接続を検証できますが、クライアントは接続できず、SSL 例外を返しています。](#issues-ssl-certificate-exception)
+ [ブローカーを作成しましたが、ブローカーの作成に失敗しました。](#issues-creating-a-broker)
+ [ブローカーが再起動したのですが、その理由がよくわかりません。](#w2aac40b9c13)
## ブローカーのウェブコンソールまたはエンドポイントに接続できません。
ウェブコンソールまたはワイヤレベルのエンドポイントを使用したブローカーへの接続で問題が発生する場合は、以下の手順が推奨されます。
1. ファイアウォールの内側からブローカーに接続しようとしているかどうかをチェックします。ブローカーへのアクセスを許可するようにファイアウォールを設定する必要がある場合があります。
1. [FIPS](https://aws.amazon.com/compliance/fips/) エンドポイントを使用して、ブローカーに接続しようとしているかどうかをチェックしてください。Amazon MQ では、API オペレーションを使用する場合のみ FIPS エンドポイントがサポートされ、ブローカーインスタンス自体へのワイヤレベルの接続はサポートされません。
1. ブローカーの [**Public Accessibility**] (パブリックアクセシビリティ) オプションが [**Yes**] (はい) に設定されているかどうかをチェックします。これが [**No**] (いいえ) に設定されている場合は、サブネットのネットワーク[アクセスコントロールリスト (ACL)](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) ルールをチェックしてください。カスタムネットワーク ACL を作成した場合は、ブローカーへのアクセス権を提供するようにネットワーク ACL ルールを変更する必要がある場合があります。Amazon VPC ネットワークの詳細については、「*Amazon VPC ユーザーガイド*」の「[インターネットアクセスを有効にする](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access)」を参照してください。
1. ブローカーのセキュリティグループルールをチェックします。以下のポートへの接続が許可されていることを確認してください。
**注記**
Amazon MQ の ActiveMQ と Amazon MQ の RabbitMQ は接続に異なるポートを使用するため、以下のポートはエンジンタイプ別に分類されています。
**Amazon MQ の ActiveMQ**
+ ウェブコンソール – ポート `8162`
+ OpenWire – ポート `61617`
+ AMQP – ポート `5671`
+ STOMP — ポート `61614`
+ MQTT – ポート `8883`
+ WSS – ポート `61619`
**Amazon MQ の RabbitMQ**
+ ウェブコンソールおよび Management API – ポート ` 443` および `15671`
+ AMQP – ポート `5671`
1. ブローカーエンジンタイプに対して、以下のネットワーク接続テストを実行します。
**注記**
パブリックアクセシビリティがないブローカーの場合は、Amazon MQ ブローカーと同じ Amazon VPC 内の Amazon EC2 インスタンスからテストを実行して、レスポンスを評価してください。
------
#### [ ActiveMQ on Amazon MQ ]
**Amazon MQ の ActiveMQ ブローカーのネットワーク接続をテストする**
1. 新規のターミナルまたはコマンドラインウィンドウを開きます。
1. 以下の `nslookup` コマンドを実行して、ブローカー DNS レコードをクエリします。[アクティブ/スタンバイ](amazon-mq-broker-architecture.md#active-standby-broker-deployment)デプロイの場合は、アクティブエンドポイントとスタンバイエンドポイントの両方をテストします。アクティブ/スタンバイエンドポイントは、一意のブローカー ID に追加された `-1` または `-2` サフィックスで特定されます。エンドポイントを独自の情報に置き換えます。
```
$ nslookup b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com
```
クエリが正常に完了すると、以下のような出力が表示されます。
```
Non-authoritative answer:
Server: dns-resolver-corp-sfo-1.sfo.corp.amazon.com
Address: 172.10.123.456
Name: ec2-12-345-123-45.us-west-2.compute.amazonaws.com
Address: 12.345.123.45
Aliases: b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com
```
解決された IP アドレスが、Amazon MQ コンソールで指定した IP アドレスと一致している必要があります。これは、ドメイン名が DNS サーバーで正しく解決されていることを示すので、次のステップに進むことができます。
1. 以下の `telnet` コマンドを実行して、ブローカーのネットワークパスをテストします。エンドポイントを独自の情報に置き換えます。必要に応じて、*port* をウェブコンソールのポート番号 `8162`、またはその他のワイヤレベルのポートに置き換えて、追加のプロトコルをテストします。
**注記**
アクティブ/スタンバイデプロイの場合、スタンバイエンドポイントで `telnet` を実行すると、`Connect failed` エラーメッセージが返されます。スタンバイインスタンス自体は実行されていますが、ActiveMQ プロセスは実行されておらず、ブローカーの Amazon EFS ストレージボリュームへのアクセス権がないため、これは期待どおりの動作です。アクティブインスタンスとスタンバイインスタンスの両方をテストできるように、`-1` および `-2` 両方のエンドポインにこのコマンドを実行してください。
```
$ telnet b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com port
```
アクティブインスタンスには、以下のような出力が表示されます。
```
Connected to b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com.
Escape character is '^]'.
```
1. 以下のいずれかを行ってください。
+ `telnet` コマンドが正常に完了する場合は、[`EstablishedConnectionsCount`](activemq-logging-monitoring.md#security-logging-monitoring-cloudwatch-metrics) メトリクスをチェックして、ブローカーが[ワイヤレベル接続の上限](amazon-mq-limits.md)に到達していないことを確認します。ブローカーの `General` ログを調べて、上限に到達したかどうかを確認することも可能です。このメトリクスがゼロより大きい場合は、現在少なくとも 1 つのクライアントがブローカーに接続されています。メトリクスがゼロ個の接続を示している場合は、`telnet` パステストを再度実行し、少なくとも 1 分待ってから接続を切断してください (ブローカーメトリクスは毎分発行されるため)。
+ `telnet` コマンドが失敗する場合は、ブローカーの [Elastic Network Interface](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) のステータスをチェックして、ステータスが `in-use` になっていることを確認します。各インスタンスのネットワークインターフェイスに関する [Amazon VPC フローログを作成](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-flow-logs.html#create-flow-log)して、生成されたフローログを検証します。`telnet` コマンドを実行したときのブローカーの IP アドレスを調べて、応答パケットを含む接続パケットが `ACCEPTED` であることを確認します。フローログの詳細と例については、*Amazon VPC デベロッパーガイド*の「[フローログレコードの例](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-records-examples.html)」を参照してください。
1. 以下の `curl` コマンドを実行して、ActiveMQ の管理ウェブコンソールへの接続をチェックします。
```
$ curl https://b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com:8162/index.html
```
コマンドが正常に完了すると、出力は以下のような HTML ドキュメントになります。
```
Apache ActiveMQ
...
```
------
#### [ RabbitMQ on Amazon MQ ]
**Amazon MQ の RabbitMQ ブローカーのネットワーク接続をテストする**
1. 新規のターミナルまたはコマンドラインウィンドウを開きます。
1. 以下の `nslookup` コマンドを実行して、ブローカー DNS レコードをクエリします。エンドポイントを独自の情報に置き換えます。
```
$ nslookup b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com
```
クエリが正常に完了すると、以下のような出力が表示されます。
```
Non-authoritative answer:
Server: dns-resolver-corp-sfo-1.sfo.corp.amazon.com
Address: 172.10.123.456
Name: rabbit-broker-1c23e456ca78-b9000123b4ebbab5.elb.us-west-2.amazonaws.com
Addresses: 52.12.345.678
52.23.234.56
41.234.567.890
54.123.45.678
Aliases: b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com
```
1. 以下の `telnet` コマンドを実行して、ブローカーのネットワークパスをテストします。エンドポイントを独自の情報に置き換えます。*port* をウェブコンソールのポート `443` に置き換える、および `5671` に置き換えてワイヤレベルの AMQP 接続をテストすることができます。
```
$ telnet b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com port
```
コマンドが正常に完了する場合は、以下のような出力が表示されます。
```
Connected to b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com.
Escape character is '^]'.
```
**注記**
Telnet 接続は、数秒後に自動的に終了します。
1. 以下のいずれかを行ってください。
+ `telnet` コマンドが正常に完了する場合は、[`ConnectionCount`](rabbitmq-logging-monitoring.md#security-logging-monitoring-cloudwatch-metrics-rabbitmq) メトリクスをチェックして、[`max-connections`](rabbitmq-resource-limits-configuration.md) デフォルトポリシーで設定されている値にブローカーが到達していないことを確認します。ブローカーの `Connection.log` ロググループを調べて、上限に到達したかどうかを確認することも可能です。このメトリクスがゼロより大きい場合は、現在少なくとも 1 つのクライアントがブローカーに接続されています。メトリクスがゼロ個の接続を示している場合は、`telnet` パステストを再度実行します。ブローカーが新しい接続メトリクスを CloudWatch に発行する前に接続が終了する場合は、このプロセスを繰り返す必要がある場合があります。メトリクスは毎分発行されます。
+ パブリックアクセシビリティがないブローカーで `telnet` コマンドが失敗する場合は、ブローカーの [Elastic Network Interface](https://docs.aws.amazon.com/UserGuide/using-eni.html?icmpid=docs_ec2_console) のステータスをチェックして、ステータスが `in-use` になっていることを確認します。各ネットワークインターフェイスに関する [Amazon VPC フローログを作成](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-flow-logs.html#create-flow-log)して、生成されたフローログを検証します。`telnet` コマンドが呼び出されたときのブローカーのプライベート IP アドレスを調べて、応答パケットを含む接続パケットが `ACCEPTED` であることを確認します。フローログの詳細と例については、*Amazon VPC デベロッパーガイド*の「[フローログレコードの例](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-records-examples.html)」を参照してください。
**注記**
このステップは、パブリックアクセシビリティがある Amazon MQ の RabbitMQ ブローカーには適用されません。
1. 以下の `curl` コマンドを実行して、RabbitMQ の管理ウェブコンソールへの接続をチェックします。
```
$ curl https://b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com:443/index.html
```
コマンドが正常に完了すると、出力は以下のような HTML ドキュメントになります。
```
RabbitMQ Management
...
```
------
## ブローカーが実行中であり、`telnet` を使用して接続を検証できますが、クライアントは接続できず、SSL 例外を返しています。
ブローカーのエンドポイント証明書がブローカーの[メンテナンスウィンドウ](maintaining-brokers.md)中に更新されている可能性があります。Amazon MQ ブローカー証明書は定期的にローテーションされ、ブローカーの可用性とセキュリティが引き続き維持されます。
[Amazon Trust Services](https://www.amazontrust.com/repository/) で Amazon ルート認証局 (CA) を使用して、クライアントのトラストストアで認証することをお勧めします。すべての Amazon MQ ブローカーの証明書は、このルート CA で署名されています。Amazon ルート CA を使用することで、ブローカーで証明書が更新されるたびに、新しい Amazon MQ ブローカーの証明書をダウンロードする必要がなくなります。
## ブローカーを作成しましたが、ブローカーの作成に失敗しました。
ブローカーが `CREATION_FAILED` ステータスになっている場合は、以下の手順を実行します。
+ IAM 許可をチェックします。ブローカーを作成するには、 AWS マネージド IAM ポリシーを使用するか、カスタム IAM ポリシーに正しい Amazon EC2 アクセス許可のセット`AmazonMQFullAccess`が必要です。必要な Amazon EC2 許可の詳細については、「[Amazon MQ ブローカーの作成に必要な IAM 許可](security-api-authentication-authorization.md#security-permissions-required-to-create-broker)」を参照してください。
+ ブローカー用に選択しているサブネットが、共有 Amazon Virtual Private Cloud (VPC) 内にあるかどうかをチェックします。共有 Amazon VPC 内で Amazon MQ ブローカーを作成するには、その Amazon VPC を所有するアカウントでブローカーを作成する必要があります。
## ブローカーが再起動したのですが、その理由がよくわかりません。
ブローカーが自動的に再起動した場合は、以下の理由のいずれかが原因で再起動した可能性があります。
+ スケジュールされた毎週のメンテナンスウィンドウが原因でブローカーが再起動した可能性があります。Amazon MQ は、ハードウェア、オペレーティングシステム、またはメッセージブローカーのエンジンソフトウェアに対して定期的にメンテナンスを実行します。メンテナンスの所要時間はさまざまですが、メッセージブローカーに対してスケジュールされている操作によっては、最長 2 時間継続することがあります。ブローカーは、この 2 時間のメンテナンスウィンドウのどの時点でも再起動する可能性があります。ブローカーのメンテナンスウィンドウの詳細については、「[Amazon MQ ブローカーのメンテナンスウィンドウのスケジュール](maintaining-brokers.md)」を参照してください。
+ ブローカーのインスタンスタイプがアプリケーションワークロードに適していない可能性があります。例えば、`mq.t3.micro` で実稼働ワークロードを実行すると、ブローカーのリソースが不足する原因になる場合があります。CPU 使用率が高い、またはブローカーのメモリ使用率が高いと、ブローカーが予期せず再起動する原因になる場合があります。ブローカーが使用する CPU とメモリの量を確認するには、エンジンタイプに対応する以下の CloudWatch メトリクスを使用してください。
+ **Amazon MQ の ActiveMQ **– 割り当てられた Amazon EC2 コンピューティングユニットのうち、ブローカーが現在使用している割合について `CpuUtilization` をチェックします。ActiveMQ JVM メモリ制限のうち、ブローカーが現在使用している割合について `HeapUsage` をチェックします。
+ **Amazon MQ の RabbitMQ **– 割り当てられた Amazon EC2 コンピューティングユニットのうち、ブローカーが現在使用している割合について `SystemCpuUtilization` をチェックします。使用済みの RAM の量 (バイト単位) について `RabbitMQMemUsed` をチェックし、それを `RabbitMQMemLimit` で除算して、RabbitMQ ノードが使用したメモリの割合を算出します。
ブローカーのインスタンスタイプ、およびワークロードに適したインスタンスタイプを選択する方法の詳細については、「[Broker instance types](broker-instance-types.md)」を参照してください。