Problembehandlung bei Amazon MQ für ActiveMQ - Amazon MQ
Protokolle werden abgerufen CloudWatch Herstellen einer Verbindung zum Broker nach einem NeustartEinige Clients können keine Verbindung herstellenJSP-Ausnahme auf der Webkonsole

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.

Problembehandlung bei Amazon MQ für ActiveMQ

Verwenden Sie die Informationen in diesem Abschnitt, um häufige Probleme zu diagnostizieren und zu lösen, die beim Arbeiten mit Amazon MQ for ActiveMQ Broker auftreten können.

Ich kann in CloudWatch Logs keine allgemeinen Logs oder Audit-Logs für meinen Broker sehen, obwohl ich die Protokollierung aktiviert habe.

Wenn Sie in CloudWatch Logs keine Logs für Ihren Broker einsehen können, gehen Sie wie folgt vor.

  1. Überprüfen Sie, ob der Benutzer, der den Broker erstellt oder neu startet, über die logs:CreateLogGroup-Berechtigung verfügt. Wenn Sie die CreateLogGroup-Berechtigung nicht zu einem Benutzer hinzufügen, bevor der Benutzer den Broker erstellt oder neu startet, wird die Protokollgruppe nicht von Amazon MQ erstellt.

  2. Prüfen Sie, ob Sie eine ressourcenbasierte Richtlinie konfiguriert haben, die es Amazon MQ ermöglicht, Protokolle in Logs zu veröffentlichen. CloudWatch Damit Amazon MQ Protokolle in Ihrer Logs-Protokollgruppe veröffentlichen kann, konfigurieren Sie eine ressourcenbasierte Richtlinie, um Amazon MQ Zugriff auf die folgenden CloudWatch Logs-Aktionen zu gewähren: CloudWatch API

    • CreateLogStream— Erstellt einen CloudWatch Logs-Log-Stream für die angegebene Protokollgruppe.

    • PutLogEvents— Liefert Ereignisse in den angegebenen CloudWatch Log-Log-Stream.

Weitere Informationen zur Konfiguration von Amazon MQ für ActiveMQ zur Veröffentlichung von Protokollen in Logs finden Sie unter CloudWatch Protokollierung konfigurieren.

Nach dem Neustart oder dem Wartungsfenster des Brokers kann ich keine Verbindung zu meinem Broker herstellen, obwohl der Status RUNNING lautet. Warum?

Es treten möglicherweise Verbindungsprobleme auf, nachdem Sie den Neustart eines Brokers eingeleitet haben, nachdem ein geplantes Wartungsfenster abgeschlossen wurde, oder in einem Fehlerereignis, bei dem die Standby-Instance aktiviert ist. In beiden Fällen werden Verbindungsprobleme nach einem Neustart des Brokers höchstwahrscheinlich durch eine ungewöhnlich große Anzahl von Nachrichten verursacht, die auf dem Amazon EFS - oder EBS Amazon-Speichervolumen Ihres Brokers gespeichert sind. Während eines Neustarts verschiebt Amazon MQ persistente Nachrichten vom Speicher in den Broker-Speicher. Um diese Diagnose zu bestätigen, können Sie die folgenden Messwerte CloudWatch für Ihren Amazon MQ for ActiveMQ-Broker überwachen:

  • StoragePercentUsage – Große Prozentsätze bei oder nahe 100 % können dazu führen, dass der Broker Verbindungen ablehnt.

  • JournalFilesForFullRecovery – Gibt die Anzahl der Journaldateien an, die nach einem unreinen Shutdown und Neustart erneut abgespielt werden. Ist der Wert zunehmend bzw. konstant höher als Eins, weist dies auf ungelöste Transaktionen hin, die nach dem Neustart Verbindungsprobleme verursachen können.

  • OpenTransactionCount –Eine Zahl größer als Null nach einem Neustart zeigt an, dass der Broker versucht, zuvor verbrauchte Nachrichten zu speichern, was zu Verbindungsproblemen führt.

Um dieses Problem zu beheben, empfehlen wir Ihnen, Ihre XA-Transaktionen mit einem rollback() oder commit() zu lösen. Weitere Informationen sowie ein Codebeispiel zum Lösen von XA-Transaktionen mit rollback(), finden Sie unter Wiederherstellen von XA-Transaktionen.

Ich sehe, dass einige meiner Clients eine Verbindung zum Broker herstellen, während andere keine Verbindung herstellen können.

Wenn Ihr Broker im RUNNING-Status ist und einige Clients sich erfolgreich mit dem Broker verbinden können, während andere dies nicht tun können, haben Sie möglicherweise das Limit an Wire-Level-Verbindungen für den Broker erreicht. Gehen Sie wie folgt vor, um zu überprüfen, ob Sie das Wire-Level-Verbindungslimit erreicht haben:

  • Überprüfen Sie die allgemeinen Broker-Protokolle für Ihren Amazon MQ for ActiveMQ-Broker unter Logs. CloudWatch Wenn das Limit erreicht wurde, sehen Sie Reached Maximum Connections in den Broker-Protokollen. Weitere Informationen zu CloudWatch Protokollen für Amazon MQ für ActiveMQ-Broker finden Sie unter. Grundlegendes zur Struktur der Protokollierung von Protokollen CloudWatch

Sobald das Limit für Wire-Level-Verbindungen erreicht ist, lehnt der Broker aktiv zusätzliche eingehende Verbindungen ab. Um dieses Problem zu lösen, empfehlen wir, den Broker-Instance-Typ zu aktualisieren. Weitere Informationen zur Auswahl des besten Instance-Typs für Ihre Workload finden Sie unter Broker instance types.

Wenn Sie bestätigt haben, dass die Anzahl Ihrer Wire-Level-Verbindungen unter dem Verbindungslimit des Brokers liegt, kann das Problem mit dem Neustart von Clients zusammenhängen. Überprüfen Sie Ihre Broker-Protokolle auf zahlreiche und häufige Einträge von ... Inactive for longer than 600000 ms - removing .... Der Protokolleintrag weist auf einen Neustart von Clients oder Konnektivitätsprobleme hin. Dieser Effekt tritt deutlicher zutage, wenn Clients über einen Network Load Balancer (NLB) eine Verbindung zum Broker herstellen, wobei die Clients häufig die Verbindung zum Broker trennen und erneut herstellen. Dies wird typischerweise bei containerbasierten Clients beobachtet.

Weitere Informationen finden Sie in Ihren clientseitigen Protokollen. Der Broker bereinigt inaktive TCP Verbindungen nach 600000 ms und gibt den Verbindungs-Socket frei.

Ich sehe beim Ausführen von Operationen die Ausnahme org.apache.jasper.JasperException: An exception occurred processing JSP page auf der ActiveMQ-Konsole.

Wenn Sie die einfache Authentifizierung und Konfiguration AuthorizationPlugin für die Warteschlangen- und Themenautorisierung verwenden, stellen Sie sicher, dass Sie das AuthorizationEntries Element in Ihrer XML Konfigurationsdatei verwenden und der activemq-webconsole Gruppe Zugriff auf alle Warteschlangen und Themen gewähren. Dies stellt sicher, dass die ActiveMQ-Webkonsole mit dem ActiveMQ-Broker kommunizieren kann.

Das folgende Beispiel-AuthorizationEntry erteilt Lese- und Schreibberechtigungen für alle Warteschlangen und Themen an die activemq-webconsole-Gruppe. 

<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>

Achten Sie auch bei der Integration Ihres Brokers daraufLDAP, der amazonmq-console-admins Gruppe die entsprechenden Berechtigungen zu erteilen. Weitere Informationen zur LDAP Integration finden Sie unterWie funktioniert LDAP die Integration.