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.
# Best Practices für Amazon MQ for RabbitMQ
Folgen Sie diesen Richtlinien zur Produktionsreife, um die Broker-Leistung zu maximieren und die Effizienz des Nachrichtendurchsatzes zu optimieren, wenn Sie mit Amazon MQ for RabbitMQ Brokern arbeiten.
**Wichtig**
Derzeit unterstützt Amazon MQ keine [Streams](https://www.rabbitmq.com/streams.html) oder die Verwendung der strukturierten Protokollierung in JSON, die in RabbitMQ 3.9.x eingeführt wurde.
**Topics**
+ [Bewährte Methoden für die Brokereinrichtung und das Verbindungsmanagement in Amazon MQ für RabbitMQ](best-practices-broker-setup.md)
+ [Bewährte Methoden für die Beständigkeit und Zuverlässigkeit von Nachrichten in Amazon MQ für RabbitMQ](best-practices-message-reliability.md)
+ [Bewährte Methoden für Leistungsoptimierung und Effizienz in Amazon MQ für RabbitMQ](best-practices-performance.md)
+ [Bewährte Methoden für Netzwerkstabilität und Überwachung in Amazon MQ für RabbitMQ](best-practices-network-resilience.md)
# Bewährte Methoden für die Brokereinrichtung und das Verbindungsmanagement in Amazon MQ für RabbitMQ
Broker-Setup und Verbindungsmanagement sind der erste Schritt, um Probleme mit dem Broker-Nachrichtendurchsatz, der Ressourcennutzung und der Fähigkeit, Produktionsworkloads zu bewältigen, zu vermeiden. Beachten Sie bei der [Erstellung und Konfiguration eines Amazon MQ for RabbitMQ-Brokers](getting-started-rabbitmq.md#create-rabbitmq-broker) die folgenden bewährten Methoden zur Auswahl geeigneter Instance-Typen, zur effizienten Verwaltung von Verbindungen und zur Konfiguration des Vorabrufs von Nachrichten, um die Leistung Ihres Brokers zu maximieren.
**Wichtig**
Amazon MQ for RabbitMQ unterstützt den Benutzernamen „guest“ nicht und löscht das Standard-Gastkonto, wenn Sie einen neuen Broker erstellen. Amazon MQ löscht außerdem regelmäßig alle vom Kunden erstellten Konten mit dem Namen „Gast“.
## Schritt 1: Verwenden Sie Cluster-Bereitstellungen
Für Produktionsworkloads empfehlen wir die Verwendung von Clusterbereitstellungen anstelle von Einzelinstanz-Brokern, um eine hohe Verfügbarkeit und Nachrichtenstabilität zu gewährleisten. Clusterbereitstellungen beseitigen einzelne Fehlerquellen und bieten eine bessere Fehlertoleranz.
Clusterbereitstellungen bestehen aus drei RabbitMQ-Broker-Knoten, die auf drei Availability Zones verteilt sind. Sie bieten einen automatischen Failover und stellen sicher, dass der Betrieb auch dann fortgesetzt wird, wenn eine gesamte Availability Zone nicht verfügbar ist. Amazon MQ repliziert Nachrichten automatisch auf allen Knoten, um die Verfügbarkeit bei Knotenausfällen oder Wartungsarbeiten sicherzustellen.
Cluster-Bereitstellungen sind für Produktionsumgebungen unerlässlich und werden durch das [Amazon MQ Service Level](https://aws.amazon.com/amazon-mq/sla/) Agreement unterstützt.
Weitere Informationen finden Sie unter [Cluster-Bereitstellung in Amazon MQ für RabbitMQ](rabbitmq-broker-architecture.md#rabbitmq-broker-architecture-cluster).
## Schritt 2: Wählen Sie den richtigen Broker-Instance-Typ
Der Nachrichtendurchsatz eines Broker-Instance-Typs hängt von Ihrem Anwendungsfall ab. `M7g.medium`sollte nur zum Testen der Anwendungsleistung verwendet werden. Wenn Sie diese kleinere Instanz verwenden, bevor Sie größere Instanzen in der Produktion verwenden, kann dies die Anwendungsleistung verbessern. Bei Instance-Typen `m7g.large` und höher können Sie Cluster-Bereitstellungen für hohe Verfügbarkeit und Nachrichtenbeständigkeit verwenden. Größere Broker-Instance-Typen können das Produktionsniveau von Clients und Warteschlangen, einen hohen Durchsatz, Nachrichten im Speicher und redundante Nachrichten bewältigen.
Weitere Informationen zur Auswahl des richtigen Instance-Typs finden Sie [in den Größenrichtlinien von Amazon MQ für RabbitMQ](rabbitmq-sizing-guidelines.md).
## Schritt 3: Verwenden Sie Quorum-Warteschlangen
Quorum-Warteschlangen sollten bei Cluster-Bereitstellung die Standardwahl für replizierte Warteschlangentypen in Produktionsumgebungen für RabbitMQ-Broker auf Version 3.13 und höher sein. Quorum-Warteschlangen sind moderne replizierte Warteschlangenarten, die eine hohe Zuverlässigkeit, einen hohen Durchsatz und eine stabile Latenz bieten.
Quorum-Warteschlangen verwenden den Raft-Konsensusalgorithmus, um eine bessere Fehlertoleranz zu gewährleisten. Wenn der Leader-Knoten nicht mehr verfügbar ist, wählen die Quorum-Warteschlangen mit Stimmenmehrheit automatisch einen neuen Leiter, sodass die Nachrichtenzustellung mit minimaler Unterbrechung fortgesetzt wird. Da sich jeder Knoten in einer anderen Availability Zone befindet, bleibt Ihr Messaging-System auch dann verfügbar, wenn eine gesamte Availability Zone vorübergehend nicht verfügbar ist.
Um eine Quorum-Warteschlange zu deklarieren, setzen Sie den Header `x-queue-type` `quorum` beim Erstellen Ihrer Warteschlangen auf.
Weitere Informationen zu Quorum-Warteschlangen, einschließlich Migrationsstrategien und Best Practices, finden Sie unter [Quorum-Warteschlangen in Amazon](quorum-queues.md) MQ für RabbitMQ.
## Schritt 4: Verwenden Sie mehrere Kanäle
Verwenden Sie mehrere Kanäle über eine einzige Verbindung, um Verbindungsabwanderungen zu vermeiden. Anwendungen sollten ein Verhältnis von Verbindung zu Kanal von 1:1 vermeiden. Wir empfehlen, für jeden Prozess eine Verbindung und anschließend für jeden Thread einen Kanal zu verwenden. Vermeiden Sie eine übermäßige Kanalnutzung, um Kanallecks zu vermeiden.
# Bewährte Methoden für die Beständigkeit und Zuverlässigkeit von Nachrichten in Amazon MQ für RabbitMQ
Bevor Sie Ihre Anwendung in die Produktionsumgebung überführen, sollten Sie sich an die folgenden bewährten Methoden halten, um Nachrichtenverlust und Ressourcenüberlastung zu verhindern.
## Schritt 1: Verwenden Sie persistente Nachrichten und dauerhafte Warteschlangen
Dauerhafte Nachrichten können dazu beitragen, die Datenbeständigkeit in Situationen zu schützen, in denen ein Broker abstürzt oder neu startet. Persistente Nachrichten werden auf die Festplatte geschrieben, sobald sie eintreffen. Im Gegensatz zu Lazy Queues werden jedoch persistente Nachrichten sowohl im Arbeitsspeicher als auch auf der Festplatte zwischengespeichert, es sei denn, der Broker benötigt mehr Speicher. In Fällen, in denen mehr Speicher benötigt wird, werden Nachrichten vom RabbitMQ-Broker-Mechanismus aus dem Speicher entfernt, der das Speichern von Nachrichten auf der Festplatte verwaltet, allgemein als*Sitzungspersistenz* bezeichnet.
Um die Nachrichtenpersistenz zu aktivieren, können Sie Ihre Warteschlangen als`durable` erklären und den Nachrichtenübermittlungsmodus auf`persistent` stellen. Das folgende Beispiel veranschaulicht die Verwendung der [RabbitMQ-Java-Client-Bibliothek](https://www.rabbitmq.com/java-client.html), um eine dauerhafte Warteschlange zu deklarieren. Wenn Sie mit AMQP 0-9-1 arbeiten, können Sie Nachrichten als persistent kennzeichnen, indem Sie den Übermittlungsmodus „2" einstellen.
```
boolean durable = true;
channel.queueDeclare("my_queue", durable, false, false, null);
```
Nachdem Sie die Warteschlange als dauerhaft konfiguriert haben, können Sie eine dauerhafte Nachricht an Ihre Warteschlange senden, indem Sie`MessageProperties` auf `PERSISTENT_TEXT_PLAIN` stellen, wie im folgenden Beispiel gezeigt.
```
import com.rabbitmq.client.MessageProperties;
channel.basicPublish("", "my_queue",
MessageProperties.PERSISTENT_TEXT_PLAIN,
message.getBytes());
```
## Schritt 2: Konfigurieren Sie die Bestätigung durch den Herausgeber und die Empfangsbestätigung für Endverbraucher
Der Vorgang der Bestätigung, dass eine Nachricht an den Broker gesendet wurde, wird als Bestätigung durch den *Herausgeber* bezeichnet. Durch Bestätigungen des Herausgebers wird Ihre Anwendung darüber informiert, wann Nachrichten zuverlässig gespeichert wurden. Mithilfe von Bestätigungen durch den Herausgeber können Sie auch kontrollieren, wie viele Nachrichten auf dem Broker gespeichert werden. Ohne Bestätigung durch den Herausgeber gibt es keine Bestätigung dafür, dass eine Nachricht erfolgreich verarbeitet wurde, und Ihr Broker kann Nachrichten löschen, die er nicht verarbeiten kann.
Wenn eine Kundenanwendung eine Bestätigung über die Zustellung und den Empfang von Nachrichten an den Broker zurücksendet, wird dies auch als *Empfangsbestätigung für Verbraucher* bezeichnet. Sowohl Bestätigung als auch Bestätigung sind für die Gewährleistung der Datensicherheit bei der Zusammenarbeit mit RabbitMQ-Brokern unerlässlich.
Die Bestätigung der Verbraucherzustellung wird in der Regel in der Clientanwendung konfiguriert. Bei der Arbeit mit AMQP 0-9-1 kann die Bestätigung durch Konfiguration der Methode aktiviert werden. `basic.consume` AMQP 0-9-1-Clients können auch Herausgeberbestätigungen konfigurieren, indem sie die Methode senden. `confirm.select`
In der Regel ist die Zustellungsbestätigung in einem Kanal aktiviert. Wenn Sie beispielsweise mit der RabbitMQ Java-Client-Bibliothek arbeiten, können Sie die`Channel#basicAck` verwenden, um eine einfache`basic.ack`Bestätigungsaufforderung erstellen, wie im folgenden Beispiel gezeigt.
```
// this example assumes an existing channel instance
boolean autoAck = false;
channel.basicConsume(queueName, autoAck, "a-consumer-tag",
new DefaultConsumer(channel) {
@Override
public void handleDelivery(String consumerTag,
Envelope envelope,
AMQP.BasicProperties properties,
byte[] body)
throws IOException
{
long deliveryTag = envelope.getDeliveryTag();
// positively acknowledge a single delivery, the message will
// be discarded
channel.basicAck(deliveryTag, false);
}
});
```
**Anmerkung**
Nicht bestätigte Nachrichten müssen im Speicher zwischengespeichert werden. Sie können die Anzahl der Nachrichten einschränken, die ein Konsumenten vorabruft, indem Sie[Vorabruf](best-practices-performance.md#configure-prefetching)-Einstellungen für eine Client-Anwendung konfigurieren.
Sie können die Konfiguration so konfigurieren`consumer_timeout`, dass erkannt wird, wenn Verbraucher Lieferungen nicht bestätigen. Wenn der Kunde innerhalb des Timeout-Werts keine Empfangsbestätigung sendet, wird der Kanal geschlossen und Sie erhalten eine. `PRECONDITION_FAILED` Um den Fehler zu diagnostizieren, verwenden Sie die [UpdateConfiguration](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/configurations-configuration-id.html)API, um den Wert zu erhöhen. `consumer_timeout`
## Schritt 3: Halten Sie die Warteschlangen kurz
In Clusterbereitstellungen können Warteschlangen mit einer großen Anzahl von Nachrichten zu einer Überlastung der Ressourcen führen. Wenn ein Broker übermäßig ausgelastet ist, kann ein Neustart eines Amazon MQ für RabbitMQ Brokers zu weiteren Leistungseinbußen führen. Wenn ein Neustart durchgeführt wird, reagieren überlastete Broker möglicherweise nicht im `REBOOT_IN_PROGRESS` Zustand.
Während dem [Wartungsfenster](amazon-mq-rabbitmq-editing-broker-preferences.md#rabbitmq-edit-current-configuration-console) führt Amazon MQ alle Wartungsarbeiten jeweils einen Knoten aus, um sicherzustellen, dass der Broker betriebsbereit bleibt. Daher müssen Warteschlangen möglicherweise synchronisiert werden, wenn jeder Knoten den Vorgang fortsetzt. Während der Synchronisierung werden Nachrichten, die auf Spiegelungen repliziert werden müssen, vom entsprechenden Amazon Elastic Block Store (Amazon EBS) -Volume in den Speicher geladen, um in Batches verarbeitet zu werden. Durch die Verarbeitung von Nachrichten in Batches können Warteschlangen schneller synchronisiert werden.
Wenn Warteschlangen kurz gehalten werden und Nachrichten klein sind, werden die Warteschlangen erfolgreich synchronisiert und wie erwartet fortgesetzt. Wenn sich die Datenmenge in einem Batch jedoch dem Speicherlimit des Knotens nähert, löst der Knoten einen Alarm mit hohem Speicher aus, der die Warteschlangen-Synchronisierung pausiert. Sie können die Speichernutzung überprüfen, indem Sie die [Metriken der Knoten `RabbitMemUsed` und des `RabbitMqMemLimit` Brokerknotens](amazon-mq-accessing-metrics.md) unter vergleichen. CloudWatch Die Synchronisierung kann erst abgeschlossen werden, wenn Nachrichten verbraucht oder gelöscht oder die Anzahl der Nachrichten im Batch reduziert wird.
Wenn die Warteschlangensynchronisierung für eine Clusterbereitstellung angehalten wird, wird empfohlen, Nachrichten zu verwenden oder zu löschen, um die Anzahl der Nachrichten in Warteschlangen zu verringern. Sobald die Warteschlangentiefe reduziert und die Warteschlangensynchronisierung abgeschlossen ist, ändert sich der Broker-Status zu`RUNNING`. Um eine angehaltene Warteschlangensynchronisierung aufzulösen, können Sie eine Richtlinie auch auf[Reduzierung der Batch-Größe der Warteschlangensynchronisation](rabbitmq-queue-sync.md) anwenden.
Sie können auch Richtlinien für automatisches Löschen und TTL definieren, um den Ressourcenverbrauch proaktiv zu reduzieren und die Anzahl der Benutzer auf ein NACKs Minimum zu reduzieren. Das Warteschleifen von Nachrichten auf dem Broker ist CPU-intensiv, sodass eine hohe Anzahl von Nachrichten die Leistung des Brokers beeinträchtigen kann. NACKs
# Bewährte Methoden für Leistungsoptimierung und Effizienz in Amazon MQ für RabbitMQ
Sie können die Leistung Ihres Amazon MQ for RabbitMQ-Brokers optimieren, indem Sie den Durchsatz maximieren, die Latenz minimieren und eine effiziente Ressourcennutzung sicherstellen. Gehen Sie wie folgt vor, um die Leistung Ihrer Anwendung zu optimieren.
## Schritt 1: Halten Sie die Nachrichtengröße unter 1 MB
Wir empfehlen, Nachrichten unter 1 Megabyte (MB) zu halten, um optimale Leistung und Zuverlässigkeit zu gewährleisten.
RabbitMQ 3.13 unterstützt standardmäßig Nachrichtengrößen von bis zu 128 MB, aber große Nachrichten können unvorhersehbare Speicheralarme auslösen, die die Veröffentlichung blockieren und bei der knotenübergreifenden Replikation von Nachrichten potenziell zu hohem Speicherdruck führen. Zu große Nachrichten können sich auch auf die Neustart- und Wiederherstellungsprozesse des Brokers auswirken, was das Risiko für die Servicekontinuität erhöht und zu Leistungseinbußen führen kann.
**Speichern und Abrufen großer Payloads mithilfe des Schemas für die Schadensüberprüfung**
Um große Nachrichten zu verwalten, können Sie das Muster der Anspruchsprüfung implementieren, indem Sie die Nachrichtennutzdaten in einem externen Speicher speichern und nur die Nutzlast-Referenz-ID über RabbitMQ senden. Der Verbraucher verwendet die Nutzlast-Referenz-ID, um die umfangreiche Nachricht abzurufen und zu verarbeiten.
Das folgende Diagramm zeigt, wie Amazon MQ für RabbitMQ und Amazon S3 zur Implementierung des Antragsprüfungsmusters verwendet wird.
![\[Diagram showing data flow between Producer, Consumer, Amazon MQ broker, and AWS S3.\]](http://docs.aws.amazon.com/de_de/amazon-mq/latest/developer-guide/images/claim-check-pattern.png)
Das folgende Beispiel demonstriert dieses Muster mit Amazon MQ, dem [AWS SDK for Java 2.x](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/home.html) und [Amazon](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) S3:
1. Definieren Sie zunächst eine Message-Klasse, die die Amazon S3 S3-Referenz-ID enthalten soll.
```
class Message {
// Other data fields of the message...
public String s3Key;
public String s3Bucket;
}
```
1. Erstellen Sie eine Publisher-Methode, die die Payload in Amazon S3 speichert und eine Referenznachricht über RabbitMQ sendet.
```
public void publishPayload() {
// Store the payload in S3.
String payload = PAYLOAD;
String prefix = S3_KEY_PREFIX;
String s3Key = prefix + "/" + UUID.randomUUID();
s3Client.putObject(PutObjectRequest.builder()
.bucket(S3_BUCKET).key(s3Key).build(),
RequestBody.fromString(payload));
// Send the reference through RabbitMQ.
Message message = new Message();
message.s3Key = s3Key;
message.s3Bucket = S3_BUCKET;
// Assign values to other fields in your message instance.
publishMessage(message);
}
```
1. Implementieren Sie eine Consumer-Methode, die die Payload von Amazon S3 abruft, die Payload verarbeitet und das Amazon S3 S3-Objekt löscht.
```
public void consumeMessage(Message message) {
// Retrieve the payload from S3.
String payload = s3Client.getObjectAsBytes(GetObjectRequest.builder()
.bucket(message.s3Bucket).key(message.s3Key).build())
.asUtf8String();
// Process the complete message.
processPayload(message, payload);
// Delete the S3 object.
s3Client.deleteObject(DeleteObjectRequest.builder()
.bucket(message.s3Bucket).key(message.s3Key).build());
}
```
## Schritt 2: Nutzung und langlebige Verbraucher `basic.consume`
Die Verwendung `basic.consume` bei einem langlebigen Verbraucher ist effizienter als die Abfrage einzelner Nachrichten mithilfe von. `basic.get` Weitere Informationen finden Sie unter [Abfragen einzelner Nachrichten](https://www.rabbitmq.com/docs/3.13/consumers#polling).
## Schritt 3: Konfigurieren Sie den Vorabruf
Sie können den RabbitMQ-Prefetch-Wert verwenden, um zu optimieren, wie Ihre Verbraucher Nachrichten konsumieren. RabbitMQ implementiert den Channel-Prefetch-Mechanismus, der von AMQP 0-9-1 bereitgestellt wird, indem die Prefetch-Anzahl auf Verbraucher im Gegensatz zu Kanälen angewendet wird. Der Prefetch-Wert wird verwendet, um anzugeben, wie viele Nachrichten an den Verbraucher zu einem bestimmten Zeitpunkt gesendet werden. Standardmäßig legt RabbitMQ eine unbegrenzte Puffergröße für Clientanwendungen fest.
Es gibt eine Vielzahl von Faktoren zu berücksichtigen, wenn Sie eine Pre-Fetch-Anzahl für Ihre RabbitMQ-Verbraucher festlegen. Berücksichtigen Sie zunächst die Umgebung und Konfiguration Ihrer Verbraucher. Da Verbraucher alle Nachrichten während der Verarbeitung im Speicher behalten müssen, kann ein hoher Pre-Fetch-Wert negative Auswirkungen auf die Leistung Ihrer Verbraucher haben und in einigen Fällen dazu führen, dass ein Verbraucher alle zusammen abstürzt. Ebenso behält der RabbitMQ-Broker selbst alle Nachrichten, die er im Speicher sendet, zwischengespeichert, bis er die Verbraucherbestätigung erhält. Ein hoher Prefetch-Wert kann dazu führen, dass Ihr RabbitMQ-Server schnell über den Arbeitsspeicher verfügt, wenn die automatische Bestätigung nicht für Verbraucher konfiguriert ist und wenn Verbraucher relativ lange Zeit benötigen, um Nachrichten zu verarbeiten.
In Anbetracht der obigen Überlegungen empfehlen wir, immer einen Pre-Fetch-Wert festzulegen, um Situationen zu vermeiden, in denen ein RabbitMQ-Broker oder seine Verbraucher aufgrund einer großen Anzahl von unverarbeiteten oder nicht bestätigten Nachrichten nicht genügend Arbeitsspeicher auslaufen. Wenn Sie Ihre Broker optimieren müssen, um große Mengen von Nachrichten zu verarbeiten, können Sie Ihre Broker und Verbraucher mit einer Reihe von Pre-Fetch-Zählungen testen, um den Wert zu bestimmen, an dem der Netzwerk-Overhead im Vergleich zu der Zeit, die ein Verbraucher benötigt, um Nachrichten zu verarbeiten, weitgehend unbedeutend wird.
**Anmerkung**
Wenn Ihre Clientanwendungen so konfiguriert haben, dass die Zustellung von Nachrichten an Verbraucher automatisch bestätigt wird, hat das Festlegen eines Pre-Fetch-Werts keine Auswirkungen.
Alle vorab abgerufenen Nachrichten werden aus der Warteschlange entfernt.
Das folgende Beispiel demonstriert das Festlegen eines Vorabruf-Werts von`10`für einen einzelnen Verbraucher mit der RabbitMQ Java-Client-Bibliothek.
```
ConnectionFactory factory = new ConnectionFactory();
Connection connection = factory.newConnection();
Channel channel = connection.createChannel();
channel.basicQos(10, false);
QueueingConsumer consumer = new QueueingConsumer(channel);
channel.basicConsume("my_queue", false, consumer);
```
**Anmerkung**
In der RabbitMQ-Java-Client-Bibliothek wird der Standardwert für die`global`-Flag auf`false` gestellt, so dass das obige Beispiel einfach als`channel.basicQos(10)` ausgeschrieben werden kann.
## Schritt 4: Verwenden Sie Celery 5.5 oder höher mit Quorum-Warteschlangen
[Python Celery](https://docs.celeryq.dev/en/stable/index.html), ein verteiltes Aufgabenwarteschlangensystem, kann bei hoher Aufgabenlast viele unkritische Meldungen generieren. Diese zusätzliche Broker-Aktivität kann die Nichtverfügbarkeit des Brokers auslösen [Amazon MQ für RabbitMQ: Alarm über hohe Speicherauslastung](troubleshooting-action-required-codes-rabbitmq-memory-alarm.md) und dazu führen. Gehen Sie wie folgt vor, um die Wahrscheinlichkeit zu verringern, dass ein Speicheralarm ausgelöst wird:
**Für alle Celery-Versionen**
1. Schalten Sie [https://docs.celeryq.dev/en/stable/userguide/configuration.html#std-setting-task_create_missing_queues](https://docs.celeryq.dev/en/stable/userguide/configuration.html#std-setting-task_create_missing_queues)es aus, um die Abwanderung in der Warteschlange zu verringern.
1. Schalten Sie es dann aus, `worker_enable_remote_control` um die dynamische Erstellung von `celery@...pidbox` Warteschlangen zu beenden. Dadurch wird die Abwanderung von Warteschlangen auf dem Broker reduziert.
```
worker_enable_remote_control = false
```
1. Um die Aktivität unkritischer Nachrichten weiter zu reduzieren, schalten Sie Celery aus, [worker-send-task-events](https://docs.celeryq.dev/en/stable/userguide/configuration.html#worker-send-task-events)indem Sie beim Starten Ihrer Celery-Anwendung Celery entweder nicht einschließen `-E` oder `--task-events` kennzeichnen.
1. Starten Sie Ihre Cellery-Anwendung mit den folgenden Parametern:
```
celery -A app_name worker --without-heartbeat --without-gossip --without-mingle
```
**Für Celery Versionen 5.5 und höher**
1. Führen Sie ein Upgrade [auf Celery Version 5.5](https://docs.celeryq.dev/en/latest/changelog.html#version-5-5-0) durch, die Mindestversion, die Quorum-Warteschlangen unterstützt, oder auf eine neuere Version. Um zu überprüfen, welche Version von Celery Sie verwenden, verwenden Sie. `celery --version` Weitere Informationen zu Quorumwarteschlangen finden Sie unter. [Quorum-Warteschlangen für RabbitMQ auf Amazon MQ](quorum-queues.md)
1. Nach dem Upgrade auf Celery 5.5 oder höher konfigurieren Sie die Konfiguration `task_default_queue_type` auf [„Quorum“](https://docs.celeryq.dev/en/stable/userguide/configuration.html#std-setting-task_default_queue_type).
1. Anschließend müssen Sie in den [Broker-Transportoptionen](https://docs.celeryq.dev/en/stable/userguide/configuration.html#std-setting-broker_transport_options) auch „Bestätigungen veröffentlichen“ aktivieren:
```
broker_transport_options = {"confirm_publish": True}
```
# Bewährte Methoden für Netzwerkstabilität und Überwachung in Amazon MQ für RabbitMQ
Netzwerkstabilität und Überwachung von Broker-Metriken sind für die Aufrechterhaltung zuverlässiger Messaging-Anwendungen unerlässlich. Führen Sie die folgenden bewährten Methoden durch, um automatische Wiederherstellungsmechanismen und Strategien zur Ressourcenüberwachung zu implementieren.
## Schritt 1: Automatische Wiederherstellung nach Netzwerkausfällen
Es wird empfohlen, die automatische Netzwerkwiederherstellung immer zu aktivieren, um erhebliche Ausfallzeiten zu vermeiden, wenn Clientverbindungen zu RabbitMQ-Knoten fehlschlagen. Die RabbitMQ Java-Client-Bibliothek unterstützt standardmäßig automatische Netzwerkwiederherstellung, beginnend mit Version`4.0.0`.
[Die automatische Verbindungswiederherstellung wird ausgelöst, wenn eine unbehandelte Ausnahme in der I/O Verbindungsschleife ausgelöst wird, wenn ein Timeout für den Socket-Lesevorgang erkannt wird oder wenn der Server einen Heartbeat verpasst.](https://www.rabbitmq.com/heartbeats.html)
In Fällen, in denen die anfängliche Verbindung zwischen einem Client und einem RabbitMQ-Knoten fehlschlägt, wird die automatische Wiederherstellung nicht ausgelöst. Wir empfehlen, Ihren Anwendungscode zu schreiben, um anfängliche Verbindungsfehler zu berücksichtigen, indem Sie die Verbindung erneut versuchen. Das folgende Beispiel veranschaulicht den erneuten Versuch von anfänglichen Netzwerkfehlern mithilfe der RabbitMQ-Java-Client-Bibliothek.
```
ConnectionFactory factory = new ConnectionFactory();
// enable automatic recovery if using RabbitMQ Java client library prior to version 4.0.0.
factory.setAutomaticRecoveryEnabled(true);
// configure various connection settings
try {
Connection conn = factory.newConnection();
} catch (java.net.ConnectException e) {
Thread.sleep(5000);
// apply retry logic
}
```
**Anmerkung**
Wenn eine Anwendung eine Verbindung mit der`Connection.Close`-Methode wird die automatische Netzwerkwiederherstellung nicht aktiviert oder ausgelöst.
## Schritt 2: Überwachen Sie die Metriken und Alarme von Brokern
Wir empfehlen, die [CloudWatch Kennzahlen](amazon-mq-accessing-metrics.md) und Alarme für Ihren Amazon MQ for RabbitMQ-Broker regelmäßig zu überwachen, um potenzielle Probleme zu identifizieren und zu beheben, bevor sie sich auf Ihre Messaging-Anwendung auswirken. Eine proaktive Überwachung ist für die Aufrechterhaltung einer stabilen Messaging-Anwendung und die Sicherstellung einer optimalen Leistung unerlässlich.
Amazon MQ for RabbitMQ veröffentlicht dazu Kennzahlen, die Einblicke in CloudWatch die Leistung des Brokers, die Ressourcennutzung und den Nachrichtenfluss bieten. Zu den wichtigsten zu überwachenden Kennzahlen gehören die Speicherauslastung und die Festplattennutzung. Sie können [CloudWatch Alarme](https://docs.aws.amazon.com/Ihttps://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Metrics.html) einrichten, wenn Ihr Broker an Ressourcengrenzen stößt oder Leistungseinbußen auftreten.
Überwachen Sie die folgenden wichtigen Kennzahlen:
**`RabbitMQMemUsed` und `RabbitMQMemLimit`**
Überwachen Sie die Speichernutzung, um Speicheralarme zu verhindern, die die Nachrichtenveröffentlichung blockieren könnten.
**`RabbitMQDiskFree` und `RabbitMQDiskFreeLimit`**
Überwachen Sie die Festplattennutzung, um Speicherplatzprobleme zu vermeiden, die zu Brokerausfällen führen können.
Überwachen Sie bei Clusterbereitstellungen auch [knotenspezifische Messwerte, um knotenspezifische Probleme](rabbitmq-logging-monitoring.md#security-logging-monitoring-cloudwatch-destination-metrics-rabbitmq) zu identifizieren.
**Anmerkung**
Weitere Informationen dazu, wie Sie einen Alarm bei hohem Speicherverbrauch verhindern können, finden Sie unter Alarme bei hohem Speicherbedarf [beheben und](troubleshooting-action-required-codes-rabbitmq-memory-alarm.md#address-prevent-high-memory-alarm) verhindern.