Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Fehlerbehebung: Allgemeines Amazon MQ
Verwenden Sie die Informationen in diesem Abschnitt, um häufige Probleme zu diagnostizieren, die beim Arbeiten mit Amazon MQ-Brokern auftreten können, z. B. Probleme beim Herstellen der Verbindung mit Ihrem Broker und Neustarts von Broker.
**Contents**
+ [Ich kann keine Verbindung zu meiner Broker-Webkonsole oder -Endpunkten herstellen.](#issues-connecting-to-console-or-endpoint)
+ [Mein Broker läuft und ich kann die Konnektivität mit `telnet` bestätigen, aber meine Clients können keine Verbindung herstellen und geben SSL-Ausnahmen zurück.](#issues-ssl-certificate-exception)
+ [Ich habe einen Broker erstellt, aber die Brokererstellung ist fehlgeschlagen.](#issues-creating-a-broker)
+ [Mein Broker wurde neu gestartet und ich bin mir nicht sicher, warum.](#w2aac40b9c13)
## Ich kann keine Verbindung zu meiner Broker-Webkonsole oder -Endpunkten herstellen.
Wenn Probleme beim Herstellen einer Verbindung mit Ihrem Broker über die Webkonsole oder Wire-Level-Endpunkte auftreten, empfehlen wir die folgenden Schritte.
1. Überprüfen Sie, ob Sie versuchen, sich hinter einer Firewall mit Ihrem Broker zu verbinden. Möglicherweise müssen Sie die Firewall so konfigurieren, dass der Zugriff auf Ihren Broker gewährt wird.
1. Prüfen Sie, ob Sie versuchen, eine Verbindung zu Ihrem Broker über einen [FIPS](https://aws.amazon.com/compliance/fips/)-Endpunkt zu erstellen. Amazon MQ unterstützt FIPS-Endpunkte nur bei Verwendung von API-Operationen und nicht für Verbindungen auf Wire-Level mit der Broker-Instance selbst.
1. Überprüfen Sie, ob die Option **Public Accessibility** (öffentliche Zugänglichkeit) für Ihren Broker auf **Yes** (Ja) gestellt ist. Wenn dies auf **Nein** gestellt ist, überprüfen Sie das Netzwerk Ihres Subnetzes[Zugriffskontrolllisten (ACL)](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)-Regeln. Wenn Sie ein benutzerdefiniertes Netzwerk erstellt haben ACLs, müssen Sie möglicherweise die Netzwerk-ACL-Regeln ändern, um Zugriff auf Ihren Broker zu gewähren. Weitere Informationen zum Amazon VPC-Netzwerk finden Sie unter [Aktivieren des Internetzugangs](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access) im *Amazon VPC-Benutzerhandbuch*.
1. Überprüfen Sie die Sicherheitsgruppenregeln Ihres Brokers. Stellen Sie sicher, dass Sie Verbindungen zu den folgenden Ports zulassen:
**Anmerkung**
Die folgenden Ports sind nach Engine-Typen gruppiert, da ActiveMQ auf Amazon MQ und RabbitMQ auf Amazon MQ unterschiedliche Ports für Verbindungen verwenden.
**ActiveMQ auf Amazon MQ**
+ Webkonsole — Port`8162`
+ OpenWire — Hafen `61617`
+ AMQP — Port`5671`
+ STOMP – Portierung von `61614`
+ MQT-Port`8883`
+ WSS — Port`61619`
**RabbitMQ auf Amazon MQ**
+ Webkonsole und Verwaltungs-API — Port` 443`und`15671`
+ AMQP — Port`5671`
1. Führen Sie die folgenden Netzwerkkonnektivitätstests für Ihren Broker-Engine-Typ .
**Anmerkung**
Führen Sie für Broker ohne öffentliche Zugänglichkeit die Tests von einer Amazon EC2 Instance innerhalb derselben Amazon VPC aus wie Ihr Amazon MQ-Broker aus und bewerten Sie die Antworten.
------
#### [ ActiveMQ on Amazon MQ ]
**Um die Netzwerkkonnektivität Ihres ActiveMQ on Amazon MQ Brokers zu testen**
1. Öffnen Sie ein Terminal-Fenster oder eine Eingabeaufforderung.
1. Führen Sie Folgendes aus:`nslookup`, um Ihren Broker-DNS-Eintrag abzufragen. Für[aktive/Standby-Funktion](amazon-mq-broker-architecture.md#active-standby-broker-deployment)-Bereitstellungen verwenden, testen Sie sowohl die aktiven als auch die Standby-Endpunkte. Die active/standby Endpunkte werden mit einem Suffix identifiziert `-1` oder der eindeutigen `-2` Broker-ID hinzugefügt. Ersetzen Sie den Endpunkt durch Ihre Informationen.
```
$ nslookup b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com
```
Wird der Befehl erfolgreich ausgeführt, wird Ihnen eine Ausgabe ähnlich der folgenden angezeigt:
```
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
```
Die aufgelöste IP-Adresse sollte mit den in der Amazon MQ Konsole angegebenen IP-Adressen übereinstimmen. Dies bedeutet, dass der Domänenname auf dem DNS-Server korrekt aufgelöst wird, und Sie können mit dem nächsten Schritt fortfahren.
1. Führen Sie Folgendes aus:`telnet`, um den Netzwerkpfad für Ihren Broker zu testen. Ersetzen Sie den Endpunkt durch Ihre Informationen. *port*Ersetzen Sie diese durch die Portnummer `8162` für die Webkonsole oder durch andere Anschlüsse auf Kabelebene, um bei Bedarf weitere Protokolle zu testen.
**Anmerkung**
Bei active/standby Bereitstellungen erhalten Sie eine `Connect failed` Fehlermeldung, wenn Sie den Standby-Endpunkt `telnet` verwenden. Dies wird erwartet, da die Standby-Instance selbst ausgeführt wird, der ActiveMQ Prozess jedoch nicht ausgeführt wird und keinen Zugriff auf das Amazon EFS Speichervolume des Brokers hat. Führen Sie den Befehl für`-1`und`-2`-Endpunkte, um sicherzustellen, dass Sie sowohl die aktive als auch die Standby-Instance testen.
```
$ telnet b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com port
```
Für die aktive Instance wird eine Ausgabe ähnlich der folgenden angezeigt.
```
Connected to b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com.
Escape character is '^]'.
```
1. Führen Sie eine der folgenden Aufgaben aus.
+ Wenn der Befehl `telnet` erfolgreich ist, überprüfen Sie die Metrik [`EstablishedConnectionsCount`](activemq-logging-monitoring.md#security-logging-monitoring-cloudwatch-metrics) und bestätigen Sie, dass der Broker die maximale [Grenze für Wire-Limits](amazon-mq-limits.md) nicht erreicht hat. Sie können auch bestätigen, ob das Limit erreicht wurde, indem Sie den Broker`General`-Protokolle. Wenn diese Metrik größer als Null ist, ist derzeit mindestens ein Client mit dem Broker verbunden. Wenn die Metrik keine Verbindungen anzeigt, führen Sie die`telnet`-Pfadtest erneut und warten Sie mindestens eine Minute, bevor Sie die Verbindung trennen, da Broker-Metriken jede Minute veröffentlicht werden.
+ Wenn das Symbol`telnet`-Befehl fehlschlägt, überprüfen Sie den Status Ihrer[Elastic Network-Schnittstelle](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html), und bestätigen Sie, dass der Status`in-use` ist. [Erstellen eines Amazon VPC Flow-Protokolls](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-flow-logs.html#create-flow-log)für die Netzwerkschnittstelle jeder Instance und überprüfen Sie die generierten Flow-Protokolle. Suchen Sie nach den IP-Adressen des Brokers, wenn Sie die`telnet`und vergewissern Sie sich, dass die Verbindungspakete`ACCEPTED`, einschließlich eines Rücksendepakets. Weitere Informationen und ein Beispiel für ein Flow Log finden Sie unter[Beispiele für Flow-Protokolldatensätze](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-records-examples.html)im*Entwicklerhandbuch für Amazon VPC*.
1. Führen Sie Folgendes aus:`curl`, um die Konnektivität zur ActiveMQ -Admin-Webkonsole zu überprüfen.
```
$ curl https://b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com:8162/index.html
```
Wird der Befehl erfolgreich ausgeführt, sollte es sich bei der Ausgabe um ein HTML-Dokument handeln, das dem folgenden ähnelt.
```
Apache ActiveMQ
...
```
------
#### [ RabbitMQ on Amazon MQ ]
**Um die Netzwerkkonnektivität Ihres RabbitMQ auf dem Amazon MQ-Broker zu testen**
1. Öffnen Sie ein Terminal-Fenster oder eine Eingabeaufforderung.
1. Führen Sie Folgendes aus:`nslookup`, um Ihren Broker-DNS-Eintrag abzufragen. Ersetzen Sie den Endpunkt durch Ihre Informationen.
```
$ nslookup b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com
```
Wird der Befehl erfolgreich ausgeführt, wird Ihnen eine Ausgabe ähnlich der folgenden angezeigt:
```
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. Führen Sie Folgendes aus:`telnet`, um den Netzwerkpfad für Ihren Broker zu testen. Ersetzen Sie den Endpunkt durch Ihre Informationen. Sie können ihn durch einen Port `443` für die Webkonsole *port* ersetzen und die AMQP-Verbindung `5671` auf Wire-Level testen.
```
$ telnet b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com port
```
Wird der Befehl erfolgreich ausgeführt, wird Ihnen eine Ausgabe ähnlich der folgenden angezeigt:
```
Connected to b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com.
Escape character is '^]'.
```
**Anmerkung**
Die Telnet-Verbindung wird nach einigen Sekunden automatisch geschlossen.
1. Führen Sie eine der folgenden Aufgaben aus.
+ Wenn der `telnet`-Befehl erfolgreich ist, überprüfen Sie die [`ConnectionCount`](rabbitmq-logging-monitoring.md#security-logging-monitoring-cloudwatch-metrics-rabbitmq)-Metrik und bestätigen Sie, dass der Broker den Wert nicht erreicht hat, der in der [`max-connections`](rabbitmq-resource-limits-configuration.md)-Standardrichtlinie eingestellt ist. Sie können auch bestätigen, ob das Limit erreicht wurde, indem Sie den Broker`Connection.log`-Protokollgruppe. Wenn diese Metrik größer als Null ist, ist derzeit mindestens ein Client mit dem Broker verbunden. Wenn die Metrik keine Verbindungen anzeigt, führen Sie die`telnet`-Pfadtest erneut. Möglicherweise müssen Sie diesen Vorgang wiederholen, wenn die Verbindung geschlossen wird, bevor Ihr Broker neue Verbindungsmetriken veröffentlicht hat. CloudWatch Metriken werden alle fünf Minuten veröffentlicht.
+ Für Broker ohne öffentliche Zugänglichkeit, wenn die`telnet`-Befehl fehlschlägt, überprüfen Sie den Status Ihrer[Elastic Network-Schnittstellen](https://docs.aws.amazon.com/UserGuide/using-eni.html?icmpid=docs_ec2_console), und bestätigen Sie, dass der Status`in-use`. [Erstellen eines Amazon VPC Flow-Protokolls](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-flow-logs.html#create-flow-log)für jede Netzwerkschnittstelle und überprüfen Sie die generierten Flussprotokolle. Suchen Sie nach den privaten IP-Adressen des Brokers, wenn der`telnet`-Befehl aufgerufen wurde, und bestätigen Sie, dass die Verbindungspakete`ACCEPTED`, einschließlich eines Rücksendepakets. Weitere Informationen und ein Beispiel für ein Flow Log finden Sie unter[Beispiele für Flow-Protokolldatensätze](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-records-examples.html)im*Entwicklerhandbuch für Amazon VPC*.
**Anmerkung**
Dieser Schritt gilt nicht für öffentlich zugängliche RabbitMQ on Amazon MQ-Broker.
1. Führen Sie Folgendes aus:`curl`, um die Konnektivität zur RabbitMQ Admin-Webkonsole zu überprüfen.
```
$ curl https://b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-west-2.amazonaws.com:443/index.html
```
Wird der Befehl erfolgreich ausgeführt, sollte es sich bei der Ausgabe um ein HTML-Dokument handeln, das dem folgenden ähnelt.
```
RabbitMQ Management
...
```
------
## Mein Broker läuft und ich kann die Konnektivität mit `telnet` bestätigen, aber meine Clients können keine Verbindung herstellen und geben SSL-Ausnahmen zurück.
Ihr Broker-Endpunktzertifikat wurde möglicherweise während des [Wartungsfensters](maintaining-brokers.md) des Brokers aktualisiert. Amazon MQ-Brokerzertifikate werden regelmäßig rotiert, um die fortgesetzte Verfügbarkeit und Sicherheit von Brokern zu gewährleisten.
Wir empfehlen die Verwendung der Amazon-Root-Zertifizierungsstelle (CA) in [Amazon Trust Services](https://www.amazontrust.com/repository/), um sich im Vertrauensspeicher Ihrer Clients zu authentifizieren. Alle Amazon-MQ-Brokerzertifikate sind mit dieser Root-CA signiert. Durch die Verwendung einer Amazon-Root-CA müssen Sie das neue Amazon-MQ-Brokerzertifikat nicht mehr jedes Mal herunterladen, wenn ein Zertifikatupdate für den Broker vorliegt.
## Ich habe einen Broker erstellt, aber die Brokererstellung ist fehlgeschlagen.
Wenn sich Ihr Broker in einem`CREATION_FAILED`-Status haben, gehen Sie wie folgt vor.
+ Überprüfen Sie Ihre IAM-Berechtigungen. Um einen Broker zu erstellen, müssen Sie entweder die AWS verwaltete IAM-Richtlinie verwenden `AmazonMQFullAccess` oder über die richtigen Amazon EC2 EC2-Berechtigungen in Ihrer benutzerdefinierten IAM-Richtlinie verfügen. Weitere Informationen zu den erforderlichen Amazon EC2 Berechtigungen finden Sie unter[IAM-Berechtigungen erforderlich, um einen Amazon MQ-Broker zu erstellen](security-api-authentication-authorization.md#security-permissions-required-to-create-broker)aus.
+ Überprüfen Sie, ob sich das Subnetz, das Sie für Ihren Broker auswählen, in einer freigegebenen Amazon Virtual Private Cloud (VPC) befindet. Um einen Amazon MQ-Broker in einer freigegebenen Amazon VPC zu erstellen, müssen Sie ihn in dem Konto erstellen, das Eigentümer der Amazon VPC ist.
## Mein Broker wurde neu gestartet und ich bin mir nicht sicher, warum.
Wird Ihr Broker automatisch neu gestartet, kann dies auf einen der folgenden Gründe zurückzuführen sein:
+ Ihr Broker wurde möglicherweise aufgrund eines geplanten wöchentlichen Wartungsfensters neu gestartet. In regelmäßigen Abständen führt Amazon MQ Wartungsarbeiten an der Hardware, dem Betriebssystem oder der Engine-Software eines Nachrichtenbrokers durch. Die Dauer der Wartung variiert, kann jedoch bis zu zwei Stunden dauern, abhängig von den Vorgängen, die für den Nachrichtenbroker geplant sind. Broker können jederzeit während des zweistündigen Wartungsfensters neu starten. Weitere Informationen zu den Wartungsfenstern für Broker finden Sie unter. [Planung des Wartungsfensters für einen Amazon MQ-Broker](maintaining-brokers.md)
+ Ihr Broker-Instance-Typ ist möglicherweise nicht für Ihre Anwendungs-Workload geeignet. Beispiel: Ausführen eines Produktions-Workloads auf einem `mq.t3.micro` kann dazu führen, dass dem Broker keine Ressourcen mehr zur Verfügung stehen. Eine hohe CPU-Auslastung oder eine hohe Broker-Speicherauslastung kann dazu führen, dass ein Broker unerwartet neu gestartet wird. Verwenden Sie die folgenden CloudWatch Messwerte für Ihren Engine-Typ, um zu sehen, wie viel CPU und Arbeitsspeicher von Ihrem Broker genutzt werden.
+ **ActiveMQ auf Amazon MQ** — Prüfen Sie `CpuUtilization` den Prozentsatz der zugewiesenen Amazon EC2 EC2-Recheneinheiten, die der Broker derzeit verwendet. Überprüfen `HeapUsage`Sie den Prozentsatz des ActiveMQ JVM-Speicherlimits, den der Broker derzeit verwendet.
+ **RabbitMQ auf Amazon MQ** — Prüfen Sie `SystemCpuUtilization` den Prozentsatz der zugewiesenen Amazon EC2 EC2-Recheneinheiten, die der Broker derzeit verwendet. Check`RabbitMQMemUsed`für das Volumen des in Bytes verwendeten RAM und dividieren durch`RabbitMQMemLimit`für den Prozentsatz des Speichers, der vom RabbitMQ-Knoten verwendet wird.
Weitere Informationen zu Broker-Instance-Typen und zur Auswahl des richtigen Instance-Typs für Ihren Workload finden Sie unter. [Broker instance types](broker-instance-types.md)