Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Bonnes pratiques Amazon MQ for RabbitMQ Suivez ces directives de préparation à la production pour optimiser les performances des courtiers et optimiser l'efficacité du débit des messages lorsque vous travaillez avec Amazon MQ pour les courtiers RabbitMQ. **Important** Actuellement, Amazon MQ ne prend pas en charge des [flux](https://www.rabbitmq.com/streams.html), ni l'utilisation de la journalisation structurée dans JSON, introduite dans RabbitMQ 3.9.x. **Topics** + [ # Meilleures pratiques pour la configuration des courtiers et la gestion des connexions dans Amazon MQ pour RabbitMQ ](best-practices-broker-setup.md) + [ # Meilleures pratiques en matière de durabilité et de fiabilité des messages dans Amazon MQ pour RabbitMQ ](best-practices-message-reliability.md) + [ # Meilleures pratiques en matière d'optimisation des performances et d'efficacité dans Amazon MQ pour RabbitMQ ](best-practices-performance.md) + [ # Meilleures pratiques en matière de résilience et de surveillance du réseau dans Amazon MQ pour RabbitMQ ](best-practices-network-resilience.md) # Meilleures pratiques pour la configuration des courtiers et la gestion des connexions dans Amazon MQ pour RabbitMQ Configuration du courtier La configuration du broker et la gestion des connexions constituent la première étape pour éviter les problèmes liés au débit des messages du broker, à l'utilisation des ressources et à la capacité à gérer les charges de travail de production. Lors de la [création et de la configuration d'un courtier Amazon MQ pour RabbitMQ, suivez](getting-started-rabbitmq.md#create-rabbitmq-broker) les bonnes pratiques suivantes pour sélectionner les types d'instances appropriés, gérer efficacement les connexions et configurer le préchargement des messages afin d'optimiser les performances de votre courtier. **Important** Amazon MQ pour RabbitMQ ne prend pas en charge le nom d'utilisateur « invité » et supprimera le compte invité par défaut lorsque vous créerez un nouveau courtier. Amazon MQ supprimera également régulièrement tout compte créé par un client appelé « invité ». ## Étape 1 : Utiliser les déploiements de clusters Pour les charges de travail de production, nous recommandons d'utiliser des déploiements en cluster plutôt que des courtiers à instance unique afin de garantir la haute disponibilité et la résilience des messages. Les déploiements en cluster suppriment les points de défaillance uniques et offrent une meilleure tolérance aux pannes. Les déploiements de clusters se composent de trois nœuds de courtage RabbitMQ répartis sur trois zones de disponibilité, ce qui permet un basculement automatique et garantit la continuité des opérations même si une zone de disponibilité complète devient indisponible. Amazon MQ réplique automatiquement les messages sur tous les nœuds pour garantir la disponibilité en cas de panne ou de maintenance des nœuds. Les déploiements de clusters sont essentiels pour les environnements de production et sont pris en charge par le contrat de [niveau de service Amazon MQ](https://aws.amazon.com/amazon-mq/sla/). Pour plus d'informations, consultez [Déploiement de clusters dans Amazon MQ pour RabbitMQ](rabbitmq-broker-architecture.md#rabbitmq-broker-architecture-cluster). ## Étape 2 : Choisissez le type d'instance de courtier approprié Le débit de messages d'un type d'instance de courtier dépend du cas d'utilisation de votre application. `M7g.medium`ne doit être utilisé que pour tester les performances de l'application. L'utilisation de cette petite instance avant d'utiliser des instances plus grandes en production peut améliorer les performances des applications. Sur les types d'instance `m7g.large` et supérieurs, vous pouvez utiliser des déploiements de clusters pour garantir une haute disponibilité et une durabilité des messages. Les types d'instances de broker de plus grande taille peuvent gérer les niveaux de production des clients et des files d'attente, le haut débit, les messages en mémoire et les messages redondants. Pour plus d'informations sur le choix du type d'instance approprié, consultez les [directives de dimensionnement dans Amazon MQ pour RabbitMQ](rabbitmq-sizing-guidelines.md). ## Étape 3 : Utiliser les files d'attente du quorum Les files d'attente de quorum, associées au déploiement en cluster, devraient être le choix par défaut pour les types de files d'attente répliqués dans les environnements de production pour les courtiers RabbitMQ sur 3.13 et versions ultérieures. Les files d'attente de quorum sont un type de file d'attente répliqué moderne qui offre une fiabilité élevée, un débit élevé et une latence stable. Les files d'attente de quorum utilisent l'algorithme de consensus Raft pour améliorer la tolérance aux pannes. Lorsque le nœud leader devient indisponible, les files d'attente du quorum élisent automatiquement un nouveau leader par un vote majoritaire, garantissant ainsi la transmission des messages avec un minimum de perturbations. Comme chaque nœud se trouve dans une zone de disponibilité différente, votre système de messagerie reste disponible même si une zone de disponibilité complète devient temporairement indisponible. Pour déclarer une file d'attente de quorum, définissez l'en-tête sur `quorum` lors `x-queue-type` de la création de vos files d'attente. Pour plus d'informations sur les files d'attente de quorum, y compris les stratégies de migration et les meilleures pratiques, consultez la section [Queues de quorum dans Amazon MQ pour RabbitMQ](quorum-queues.md). ## Étape 4 : Utiliser plusieurs canaux Pour éviter toute perte de connexion, utilisez plusieurs canaux sur une seule connexion. Les applications doivent éviter un rapport connexion/canal 1:1. Nous recommandons d'utiliser une connexion pour chaque processus, puis un canal pour chaque thread. Évitez l'utilisation excessive des canaux pour éviter les fuites. # Meilleures pratiques en matière de durabilité et de fiabilité des messages dans Amazon MQ pour RabbitMQ Fiabilité des messages Avant de passer votre application en production, suivez les bonnes pratiques suivantes pour éviter la perte de messages et la surutilisation des ressources. ## Étape 1 : Utiliser des messages persistants et des files d'attente durables Les messages persistants peuvent contribuer à protéger la durabilité des données en cas de panne ou de redémarrage d'un broker. Les messages persistants sont écrits sur le disque dès leur arrivée. Cependant, contrairement aux files d'attente paresseuses, les messages persistants sont mis en cache à la fois dans la mémoire et dans le disque, sauf si l'agent a besoin de plus de mémoire. Dans les cas où plus de mémoire est nécessaire, les messages sont supprimés de la mémoire par le mécanisme d'agent RabbitMQ qui gère le stockage des messages sur disque, communément appelé *couche de persistance*. Pour activer la persistance des messages, vous pouvez déclarer vos files d'attente comme `durable` et définissez le mode de remise des messages sur `persistent`. L'exemple suivant illustre l'utilisation de la [bibliothèque client Java RabbitMQ](https://www.rabbitmq.com/java-client.html) pour déclarer une file d'attente durable. Lorsque vous travaillez avec AMQP 0-9-1, vous pouvez marquer les messages comme persistants en définissant le mode de livraison « 2 ». ``` boolean durable = true; channel.queueDeclare("my_queue", durable, false, false, null); ``` Une fois que vous avez configuré votre file d'attente comme durable, vous pouvez envoyer un message persistant à votre file d'attente en définissant `MessageProperties` sur `PERSISTENT_TEXT_PLAIN` illustré dans l'exemple suivant. ``` import com.rabbitmq.client.MessageProperties; channel.basicPublish("", "my_queue", MessageProperties.PERSISTENT_TEXT_PLAIN, message.getBytes()); ``` ## Étape 2 : Configuration des confirmations de l'éditeur et de l'accusé de réception du client Le processus de confirmation de l'envoi d'un message au courtier est appelé *confirmation de l'éditeur*. L'éditeur confirme que votre application est informée lorsque les messages ont été stockés de manière fiable. Les confirmations de l'éditeur peuvent également aider à contrôler le taux de messages stockés auprès du courtier. Sans la confirmation de l'éditeur, il n'y a aucune confirmation qu'un message a été traité correctement, et votre courtier peut supprimer les messages qu'il ne peut pas traiter. De même, lorsqu'une application cliente envoie une confirmation de livraison et de consommation de messages au courtier, on parle d'*accusé de réception pour le consommateur*. La confirmation et l'accusé de réception sont essentiels pour garantir la sécurité des données lorsque vous travaillez avec des courtiers RabbitMQ. L'accusé de réception de livraison du consommateur est généralement configuré sur l'application client. Lorsque vous travaillez avec AMQP 0-9-1, l'accusé de réception peut être activé en configurant la méthode. `basic.consume` Les clients AMQP 0-9-1 peuvent également configurer les confirmations de l'éditeur en envoyant la méthode. `confirm.select` En règle générale, l'accusé de réception de livraison est activé dans un canal. Par exemple, lorsque vous travaillez avec la bibliothèque client Java RabbitMQ, vous pouvez utiliser l'`Channel#basicAck` pour mettre en place une confirmation positive `basic.ack` comme illustré dans l'exemple suivant. ``` // 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); } }); ``` **Note** Les messages sans accusé de réception doivent être mis en cache en mémoire. Vous pouvez limiter le nombre de messages qu'un consommateur récupère à l'avance en configurant les paramètres de [pré-extraction](best-practices-performance.md#configure-prefetching) pour une application client. Vous pouvez configurer `consumer_timeout` pour détecter les cas où les consommateurs n'accusent pas réception des livraisons. Si le consommateur n'envoie pas d'accusé de réception dans le délai imparti, le canal sera fermé et vous recevrez un. `PRECONDITION_FAILED` Pour diagnostiquer l'erreur, utilisez l'[UpdateConfiguration](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/configurations-configuration-id.html)API pour augmenter la `consumer_timeout` valeur. ## Étape 3 : Réduisez les files d'attente Dans les déploiements en cluster, les files d'attente comportant un grand nombre de messages peuvent entraîner une surexploitation des ressources. Lorsqu'un agent est surutilisé, le redémarrage d'un agent Amazon MQ for RabbitMQ peut entraîner une dégradation supplémentaire des performances. En cas de redémarrage, les agents surexploités risquent de ne plus répondre dans l'état `REBOOT_IN_PROGRESS`. Durant les [fenêtres de maintenance](amazon-mq-rabbitmq-editing-broker-preferences.md#rabbitmq-edit-current-configuration-console), Amazon MQ effectue tous les travaux de maintenance un nœud à la fois pour s'assurer que l'agent reste opérationnel. Par conséquent, les files d'attente peuvent devoir se synchroniser à mesure que chaque nœud reprend l'opération. Pendant la synchronisation, les messages qui doivent être répliqués en miroirs sont chargés en mémoire à partir du volume Amazon Elastic Block Store (Amazon EBS) correspondant à traiter par lots. Le traitement des messages par lots permet aux files d'attente de se synchroniser plus rapidement. Si les files d'attente sont courtes et que les messages sont petits, les files d'attente se synchronisent et reprennent le fonctionnement comme prévu. Toutefois, si la quantité de données dans un lot approche de la limite de mémoire du nœud, le nœud déclenche une alarme de mémoire élevée, mettant en pause la synchronisation de la file d'attente. Vous pouvez confirmer l'utilisation de la mémoire en comparant les [métriques du nœud `RabbitMemUsed` et du nœud `RabbitMqMemLimit` broker dans CloudWatch](amazon-mq-accessing-metrics.md). La synchronisation ne peut pas se terminer tant que les messages ne sont pas consommés ou supprimés, ou que le nombre de messages dans le lot est réduit. Si la synchronisation des files d'attente est interrompue pour un déploiement en cluster, nous vous recommandons de consommer ou de supprimer des messages afin de réduire le nombre de messages dans les files d'attente. Une fois la profondeur de la file d'attente réduite et la synchronisation de la file d'attente terminée, l'état de l'agent passe à `RUNNING`. Pour résoudre une synchronisation de file d'attente interrompue, vous pouvez également appliquer une politique pour [réduire la taille du lot de synchronisation des files d'attente](rabbitmq-queue-sync.md). Vous pouvez également définir des politiques de suppression automatique et de TTL afin de réduire de manière proactive l'utilisation des ressources et NACKs de limiter au maximum la communication avec les consommateurs. La mise en file d'attente de messages sur le courtier consomme beaucoup de ressources processeur, de sorte qu'un nombre élevé de messages peut affecter les performances du NACKs courtier. # Meilleures pratiques en matière d'optimisation des performances et d'efficacité dans Amazon MQ pour RabbitMQ Optimisation des performances Vous pouvez optimiser les performances de votre Amazon MQ pour les courtiers RabbitMQ en maximisant le débit, en minimisant la latence et en garantissant une utilisation efficace des ressources. Suivez les meilleures pratiques suivantes pour optimiser les performances de votre application. ## Étape 1 : maintenez la taille des messages en dessous de 1 Mo Nous recommandons de conserver les messages à moins de 1 mégaoctet (Mo) pour des performances et une fiabilité optimales. RabbitMQ 3.13 prend en charge des tailles de message allant jusqu'à 128 Mo par défaut, mais les messages volumineux peuvent déclencher des alarmes de mémoire imprévisibles qui bloquent la publication et peuvent créer une pression mémoire élevée lors de la réplication des messages sur les nœuds. Les messages surdimensionnés peuvent également affecter les processus de redémarrage et de restauration des courtiers, ce qui augmente les risques pour la continuité du service et peut entraîner une dégradation des performances. **Stockez et récupérez des charges utiles importantes à l'aide du modèle de vérification des sinistres** Pour gérer les messages volumineux, vous pouvez implémenter le modèle de vérification des réclamations en stockant la charge utile du message dans un stockage externe et en envoyant uniquement l'identifiant de référence de la charge utile via RabbitMQ. Le consommateur utilise l'identifiant de référence de charge utile pour récupérer et traiter le message volumineux. Le schéma suivant montre comment utiliser Amazon MQ pour RabbitMQ et Amazon S3 pour implémenter le modèle de vérification des réclamations. ![\[Diagram showing data flow between Producer, Consumer, Amazon MQ broker, and AWS S3.\]](http://docs.aws.amazon.com/fr_fr/amazon-mq/latest/developer-guide/images/claim-check-pattern.png) [L'exemple suivant illustre ce modèle à l'aide d'Amazon MQ, du [AWS SDK pour Java 2.x et](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/home.html) d'Amazon S3 :](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) 1. Définissez d'abord une classe de message qui contiendra l'identifiant de référence Amazon S3. ``` class Message { // Other data fields of the message... public String s3Key; public String s3Bucket; } ``` 1. Créez une méthode d'éditeur qui stocke la charge utile dans Amazon S3 et envoie un message de référence via RabbitMQ. ``` 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. Implémentez une méthode consommateur qui récupère la charge utile d'Amazon S3, la traite et supprime l'objet Amazon S3. ``` 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()); } ``` ## Étape 2 : Utilisation `basic.consume` et longue durée de vie des consommateurs L'utilisation `basic.consume` auprès d'un consommateur de longue date est plus efficace que le sondage pour des messages individuels. `basic.get` Pour plus d'informations, consultez la section [Sondage de messages individuels](https://www.rabbitmq.com/docs/3.13/consumers#polling). ## Étape 3 : Configuration de la pré-extraction Vous pouvez utiliser la valeur de pré-extraction RabbitMQ pour optimiser la façon dont vos consommateurs consomment les messages. RabbitMQ implémente le mécanisme de pré-extraction des canaux fourni par AMQP 0-9-1 en appliquant le nombre de pré-extraction aux consommateurs plutôt qu'aux canaux. La valeur de pré-extraction est utilisée pour spécifier le nombre de messages envoyés au consommateur à un moment donné. Par défaut, RabbitMQ définit une taille de tampon illimitée pour les applications client. Il existe une variété de facteurs à prendre en compte lors de la définition d'un nombre de pré-extraction pour vos consommateurs RabbitMQ. Tout d'abord, considérez l'environnement et la configuration de vos clients. Étant donné que les consommateurs doivent conserver tous les messages en mémoire au fur et à mesure qu'ils sont traités, une valeur de pré-extraction élevée peut avoir un impact négatif sur les performances de vos consommateurs et, dans certains cas, peut entraîner un blocage potentiel d'un consommateur. De même, l'agent RabbitMQ conserve lui-même tous les messages qu'il envoie mis en mémoire cache jusqu'à ce qu'il reçoive l'accusé de réception du consommateur. Une valeur de pré-extraction élevée peut entraîner une perte de mémoire rapide de votre serveur RabbitMQ si l'accusé de réception automatique n'est pas configuré pour les consommateurs et si les consommateurs prennent un temps relativement long pour traiter les messages. En prenant en compte les considérations ci-dessus, nous vous recommandons de toujours définir une valeur de pré-extraction afin d'éviter les situations où un agent RabbitMQ ou ses consommateurs manquent de mémoire en raison d'un grand nombre de messages non traités ou sans accusés de réception. Si vous avez besoin d'optimiser vos agents pour traiter de grands volumes de messages, vous pouvez tester vos agents et vos consommateurs à l'aide d'une plage de comptes de pré-extraction afin de déterminer la valeur à laquelle les frais généraux du réseau deviennent largement insignifiants par rapport au temps nécessaire au traitement des messages par un consommateur. **Note** Si vos applications client ont été configurées pour reconnaître automatiquement la remise des messages aux consommateurs, la définition d'une valeur de pré-extraction n'aura aucun effet. Tous les messages pré-extraits sont supprimés de la file d'attente. L'exemple suivant montre la définition d'une valeur de pré-extraction de `10` pour un seul consommateur utilisant la bibliothèque client Java RabbitMQ. ``` 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); ``` **Note** Dans la bibliothèque client Java RabbitMQ, la valeur par défaut de la propriété `global`est définie sur `false`, donc l'exemple ci-dessus peut être écrit simplement comme `channel.basicQos(10)`. ## Étape 4 : Utiliser Celery 5.5 ou version ultérieure avec les files d'attente du quorum [Python Celery](https://docs.celeryq.dev/en/stable/index.html), un système de file d'attente de tâches distribué, peut générer de nombreux messages non critiques en cas de charge de tâches élevée. Cette activité supplémentaire du courtier peut déclencher [Amazon MQ pour RabbitMQ : alarme de mémoire élevée](troubleshooting-action-required-codes-rabbitmq-memory-alarm.md) et entraîner une indisponibilité du courtier. Pour réduire le risque de déclenchement d'une alarme mémoire, procédez comme suit : **Pour toutes les versions de Celery** 1. Désactivez-le [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)pour réduire le taux de désabonnement des files d'attente. 1. Ensuite, désactivez-le `worker_enable_remote_control` pour arrêter la création dynamique de `celery@...pidbox` files d'attente. Cela réduira le taux de désabonnement des files d'attente chez le courtier. ``` worker_enable_remote_control = false ``` 1. Pour réduire davantage l'activité des messages non critiques, désactivez Celery [worker-send-task-events](https://docs.celeryq.dev/en/stable/userguide/configuration.html#worker-send-task-events)en ne les incluant pas `-E` ou en les `--task-events` signalant au démarrage de votre application Celery. 1. Démarrez votre application Celery en utilisant les paramètres suivants : ``` celery -A app_name worker --without-heartbeat --without-gossip --without-mingle ``` **Pour les versions 5.5 et supérieures de Celery** 1. Passez à la [version 5.5 de Celery](https://docs.celeryq.dev/en/latest/changelog.html#version-5-5-0), la version minimale qui prend en charge les files d'attente de quorum, ou à une version ultérieure. Pour vérifier quelle version de Celery vous utilisez, utilisez`celery --version`. Pour plus d'informations sur les files d'attente pour le quorum, consultez[Files d'attente de quorum pour RabbitMQ sur Amazon MQ](quorum-queues.md). 1. Après la mise à niveau vers Celery 5.5 ou version ultérieure, configurez `task_default_queue_type` sur [« quorum »](https://docs.celeryq.dev/en/stable/userguide/configuration.html#std-setting-task_default_queue_type). 1. Ensuite, vous devez également activer Publier les confirmations dans les [options de transport des courtiers](https://docs.celeryq.dev/en/stable/userguide/configuration.html#std-setting-broker_transport_options) : ``` broker_transport_options = {"confirm_publish": True} ``` # Meilleures pratiques en matière de résilience et de surveillance du réseau dans Amazon MQ pour RabbitMQ Résilience du réseau La résilience du réseau et la surveillance des métriques des courtiers sont essentielles pour garantir la fiabilité des applications de messagerie. Suivez les meilleures pratiques suivantes pour mettre en œuvre des mécanismes de restauration automatique et des stratégies de surveillance des ressources. ## Étape 1 : restauration automatique en cas de défaillance du réseau Nous vous recommandons de toujours activer la récupération automatique du réseau pour éviter les temps d'arrêt importants en cas d'échec des connexions client aux nœuds RabbitMQ. La bibliothèque client Java RabbitMQ prend en charge la récupération automatique du réseau par défaut, en commençant par la version `4.0.0`. [La restauration automatique de la connexion est déclenchée si une exception non gérée est émise dans la I/O boucle de connexion, si le délai d'expiration d'une opération de lecture du socket est détecté ou si le serveur rate un battement de cœur.](https://www.rabbitmq.com/heartbeats.html) Dans les cas où la connexion initiale entre un client et un nœud RabbitMQ échoue, la récupération automatique ne sera pas déclenchée. Nous vous recommandons d'écrire votre code d'application pour tenir compte des échecs de connexion initiaux en tentant de nouveau la connexion. L'exemple suivant illustre la nouvelle tentative d'échec réseau initial à l'aide de la bibliothèque client Java RabbitMQ. ``` 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 } ``` **Note** Si une application ferme une connexion à l'aide de la méthode `Connection.Close`, la récupération automatique du réseau ne sera ni activée ni déclenchée. ## Étape 2 : Surveiller les métriques et les alarmes des courtiers Nous vous recommandons de surveiller régulièrement [CloudWatch les métriques et les](amazon-mq-accessing-metrics.md) alarmes de votre courtier Amazon MQ pour RabbitMQ afin d'identifier et de résoudre les problèmes potentiels avant qu'ils n'affectent votre application de messagerie. La surveillance proactive est essentielle pour maintenir une application de messagerie résiliente et garantir des performances optimales. Amazon MQ pour RabbitMQ publie des statistiques CloudWatch qui fournissent des informations sur les performances des courtiers, l'utilisation des ressources et le flux de messages. Les indicateurs clés à surveiller incluent l'utilisation de la mémoire et l'utilisation du disque. Vous pouvez configurer des [CloudWatch alarmes](https://docs.aws.amazon.com/Ihttps://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Metrics.html) lorsque votre courtier approche des limites de ressources ou subit une dégradation des performances. Surveillez les indicateurs essentiels suivants : **`RabbitMQMemUsed` et `RabbitMQMemLimit`** Surveillez l'utilisation de la mémoire pour éviter les alarmes susceptibles de bloquer la publication des messages. **`RabbitMQDiskFree` et `RabbitMQDiskFreeLimit`** Surveillez l'utilisation du disque pour éviter les problèmes d'espace disque susceptibles de provoquer des défaillances du broker. Pour les déploiements de clusters, surveillez également les [métriques spécifiques aux nœuds afin d'identifier les problèmes spécifiques](rabbitmq-logging-monitoring.md#security-logging-monitoring-cloudwatch-destination-metrics-rabbitmq) aux nœuds. **Note** Pour plus d'informations sur la façon de prévenir une alarme de mémoire trop importante, voir [Corriger et empêcher une alarme de mémoire trop importante](troubleshooting-action-required-codes-rabbitmq-memory-alarm.md#address-prevent-high-memory-alarm).