Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Prácticas recomendadas de Amazon MQ para RabbitMQ
Siga estas pautas de preparación para la producción para maximizar el rendimiento de los agentes y optimizar la eficiencia del procesamiento de mensajes cuando trabaje con agentes de Amazon MQ para RabbitMQ.
**importante**
Actualmente, Amazon MQ no admite [flujos](https://www.rabbitmq.com/streams.html), ni utiliza el registro estructurado en JSON, presentado en RabbitMQ 3.9.x.
**Topics**
+ [Prácticas recomendadas para la configuración de agentes y la gestión de conexiones en Amazon MQ para RabbitMQ](best-practices-broker-setup.md)
+ [Prácticas recomendadas de la durabilidad y fiabilidad de mensajes en Amazon MQ para RabbitMQ](best-practices-message-reliability.md)
+ [Prácticas recomendadas para lograr la eficiencia y optimización del rendimiento en Amazon MQ para RabbitMQ](best-practices-performance.md)
+ [Prácticas recomendadas de supervisión y resiliencia de la red en Amazon MQ para RabbitMQ](best-practices-network-resilience.md)
# Prácticas recomendadas para la configuración de agentes y la gestión de conexiones en Amazon MQ para RabbitMQ
La configuración y la gestión de las conexiones del agente son el primer paso para evitar problemas relacionados con el rendimiento de los mensajes del agente, la utilización de los recursos y la capacidad de gestionar las cargas de trabajo de producción. Al [crear y configurar un agente Amazon MQ para RabbitMQ](getting-started-rabbitmq.md#create-rabbitmq-broker), siga las siguientes prácticas recomendadas de selección de los tipos de instancias adecuados, gestionar las conexiones de forma eficaz y configurar la recuperación previa de mensajes para maximizar el rendimiento de su agente.
**importante**
Amazon MQ para RabbitMQ no admite el nombre de usuario “guest” y eliminará la cuenta de invitado predeterminada cuando cree un nuevo agente. Amazon MQ también eliminará periódicamente cualquier cuenta creada por el cliente con dicho nombre.
## Paso 1: Utilizar las implementaciones de clústeres
Para las cargas de trabajo de producción, recomendamos utilizar implementaciones en clústeres en lugar de agentes de instancia única para garantizar una alta disponibilidad y la resiliencia de los mensajes. Las implementaciones en clúster eliminan los puntos únicos de error y ofrecen una mejor tolerancia a errores.
Las implementaciones en clúster constan de tres nodos de agente de RabbitMQ distribuidos en tres zonas de disponibilidad, lo que proporciona una conmutación automática por error y garantiza que las operaciones continúen incluso si una zona de disponibilidad completa deja de estar disponible. Amazon MQ replica automáticamente los mensajes en todos los nodos para garantizar la disponibilidad durante las averías o el mantenimiento de los nodos.
Las implementaciones en clúster son esenciales en entornos de producción y están cubiertas por el [acuerdo de nivel de servicio de Amazon MQ](https://aws.amazon.com/amazon-mq/sla/).
Para obtener más información, consulte [Implementación de clústeres en Amazon MQ para RabbitMQ](rabbitmq-broker-architecture.md#rabbitmq-broker-architecture-cluster).
## Paso 2: Cómo elegir el tipo de instancia de agente correcto
El rendimiento de los mensajes de un tipo de instancia de agente depende del caso de uso de su aplicación. Se recomienda usar `M7g.medium` únicamente para probar el rendimiento de una aplicación. El uso de esta instancia menor antes de utilizar instancias mayores en producción puede mejorar el rendimiento de una aplicación. En los tipos de instancias `m7g.large` y superiores, puede usar implementaciones de clústeres para obtener una alta disponibilidad y durabilidad de los mensajes. En cambio, los tipos de instancias de agente más grandes pueden controlar clientes y colas, rendimientos altos, mensajes en memoria y mensajes redundantes a nivel de producción.
Para obtener más información sobre cómo elegir el tipo de instancia correcto, consulte [Directrices de dimensionamiento en Amazon MQ para RabbitMQ](rabbitmq-sizing-guidelines.md).
## Paso 3: Utilizar las colas de cuórum
Las colas de cuórum, con implementación en clústeres, deberían ser la opción predeterminada para los tipos de colas replicadas en los entornos de producción para los agentes de RabbitMQ a partir de la versión 3.13. Las colas de cuórum son un tipo de cola replicada moderna que proporciona alta fiabilidad, alto rendimiento y latencia estable.
Las colas de cuórum utilizan el algoritmo de consenso Raft para ofrecer una mejor tolerancia a errores. Cuando el nodo líder deja de estar disponible, las colas de cuórum eligen automáticamente a un nuevo líder por mayoría de votos, lo que garantiza que la entrega de mensajes continúe con las mínimas interrupciones. Como cada nodo se encuentra en una zona de disponibilidad diferente, su sistema de mensajería permanece disponible incluso si una zona de disponibilidad completa deja de estar disponible temporalmente.
Para declarar una cola de cuórum, defina el encabezado `x-queue-type` en `quorum` cuando cree las colas.
Para obtener más información sobre las colas de cuórum, incluidas las estrategias de migración y las prácticas recomendadas, consulte [Colas de cuórum en Amazon MQ para RabbitMQ](quorum-queues.md).
## Paso 4: Uso de múltiples canales
Para evitar la pérdida de conexiones, use varios canales a través de una sola conexión. Las aplicaciones deben evitar una relación de conexión individual con el canal. Recomendamos utilizar una conexión para cada proceso y, a continuación, un canal para cada subproceso. Evite el uso excesivo de los canales para evitar fugas en ellos.
# Prácticas recomendadas de la durabilidad y fiabilidad de mensajes en Amazon MQ para RabbitMQ
Antes de trasladar la aplicación a producción, siga las siguientes prácticas recomendadas para evitar la pérdida de mensajes y la sobreutilización de los recursos.
## Paso 1: Uso de mensajes persistentes y colas duraderas
Los mensajes persistentes pueden ayudar a proteger la durabilidad de los datos en situaciones en las que un agente se bloquea o se reinicia. Los mensajes persistentes se escriben en el disco tan pronto como llegan. Sin embargo, a diferencia de las colas perezosas, los mensajes persistentes se almacenan tanto en la memoria caché como en el disco, a menos que el agente necesite más memoria. En los casos en que se necesita más memoria, los mensajes se eliminan de la memoria mediante el mecanismo del agente de RabbitMQ que administra el almacenamiento de mensajes en el disco, comúnmente conocido como *capa de persistencia*.
Para habilitar la persistencia de mensajes, puede declarar las colas como `durable` y establecer el modo de entrega de mensajes en `persistent`. En el siguiente ejemplo, se muestra el uso de la [biblioteca de cliente Java de RabbitMQ](https://www.rabbitmq.com/java-client.html) para declarar una cola duradera. Al trabajar con el AMQP 0-9-1, puede marcar los mensajes como persistentes configurando el modo de entrega como “2”.
```
boolean durable = true;
channel.queueDeclare("my_queue", durable, false, false, null);
```
Una vez que haya configurado la cola como duradera, puede enviar un mensaje persistente a la cola estableciendo `MessageProperties` en `PERSISTENT_TEXT_PLAIN`, como se muestra en el siguiente ejemplo.
```
import com.rabbitmq.client.MessageProperties;
channel.basicPublish("", "my_queue",
MessageProperties.PERSISTENT_TEXT_PLAIN,
message.getBytes());
```
## Paso 2: Configuración de la confirmación del publicador y el acuse de recibo de la entrega al consumidor
Se denomina *confirmación del publicador* al proceso de confirmar que se ha enviado un mensaje al agente. Las confirmaciones del publicador permiten a la aplicación saber que los mensajes se han almacenado de forma fiable. También pueden ayudar a controlar el ritmo de los mensajes almacenados en el agente. Sin las confirmaciones del publicador, no es posible confirmar que un mensaje se haya procesado correctamente y puede que su agente descarte los mensajes que no pueda procesar.
Del mismo modo, cuando una aplicación cliente envía confirmación de entrega y consumo de mensajes de vuelta al agente, se conoce como *acuse de recibo del consumidor*. Tanto la confirmación como el acuse de recibo son esenciales para garantizar la seguridad de los datos cuando se trabaja con agentes de RabbitMQ.
El acuse de recibo de entrega del consumidor suele configurarse en la aplicación cliente. Cuando se trabaja con AMQP 0-9-1, el acuse de recibo se puede habilitar configurando el método `basic.consume`. Los clientes de AMQP 0-9-1 también pueden configurar las confirmaciones del publicador mediante el envío del método `confirm.select`.
Normalmente, el acuse de recibo de entrega se habilita en un canal. Por ejemplo, cuando se trabaja con la biblioteca de cliente Java de RabbitMQ, se puede utilizar `Channel#basicAck` para configurar un acuse de recibo positivo `basic.ack`, como se muestra en el siguiente ejemplo.
```
// 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);
}
});
```
**nota**
Los mensajes sin confirmar se deben almacenar en la memoria caché. Para limitar el número de mensajes que un consumidor captura previamente, puede establecer el parámetro [Pre-fetch](best-practices-performance.md#configure-prefetching) (Captura previa) para una aplicación cliente.
Puede configurar `consumer_timeout` para detectar cuándo los consumidores no confirman las entregas. Si el consumidor no envía un acuse de recibo dentro del tiempo de espera, el canal se cerrará y recibirá un `PRECONDITION_FAILED`. Para diagnosticar el error, usa la [UpdateConfiguration](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/configurations-configuration-id.html)API para aumentar el `consumer_timeout` valor.
## Paso 3: Mantener las colas cortas
En las implementaciones de clúster, las colas con un gran número de mensajes pueden provocar una sobreutilización de recursos. Cuando un agente está sobreutilizado, el reinicio de un agente de Amazon MQ para RabbitMQ puede degradar aún más el rendimiento. Si se reinicia, los agentes sobreutilizados podrían dejar de responder en el estado `REBOOT_IN_PROGRESS`.
Durante los [períodos de mantenimiento](amazon-mq-rabbitmq-editing-broker-preferences.md#rabbitmq-edit-current-configuration-console), Amazon MQ realiza todos los trabajos de mantenimiento de a un nodo por vez para garantizar que el agente permanezca operativo. Como resultado, es posible que las colas deban sincronizarse a medida que cada se vaya reanudando la operación de cada nodo. Durante la sincronización, los mensajes que deben replicarse en los espejos se cargan en la memoria del volumen correspondiente de Amazon Elastic Block Store (Amazon EBS) para procesarlos en lotes. El procesamiento de mensajes en lotes permite agilizar la sincronización de las colas.
Si las colas se mantienen cortas y los mensajes son pequeños, las colas se sincronizan correctamente y reanudan la operación según lo previsto. Sin embargo, si la cantidad de datos de un lote se acerca al límite de memoria del nodo, el nodo genera una alarma de memoria elevada y se pausa la sincronización de colas. Puede confirmar el uso de la memoria comparando las [métricas del `RabbitMemUsed` nodo `RabbitMqMemLimit` intermediario con las del nodo intermediario CloudWatch](amazon-mq-accessing-metrics.md). La sincronización no se puede completar hasta que se consuman o eliminen los mensajes, o se reduzca el número de mensajes del lote.
Si la sincronización de colas está en pausa por una implementación de clúster, recomendamos consumir o eliminar mensajes para reducir el número de mensajes en las colas. Una vez que se reduzca la profundidad de la cola y se complete su sincronización, el estado del agente cambiará a `RUNNING`. Para resolver una sincronización de cola en pausa, también puede aplicar una política para [reducir el tamaño del lote de sincronización de colas](rabbitmq-queue-sync.md).
También puedes definir políticas de eliminación automática y TTL para reducir de forma proactiva el uso de recursos y NACKs evitar que los consumidores lo hagan al mínimo. Poner los mensajes en cola en el bróker requiere un uso intensivo de la CPU, por lo que un número elevado de ellos puede afectar al rendimiento del bróker. NACKs
# Prácticas recomendadas para lograr la eficiencia y optimización del rendimiento en Amazon MQ para RabbitMQ
Puede optimizar el rendimiento de su agente Amazon MQ para RabbitMQ maximizando el rendimiento, minimizando la latencia y garantizando un uso eficiente de los recursos. Siga las siguientes prácticas recomendadas para optimizar el rendimiento de su aplicación.
## Paso 1: Mantenga el tamaño de los mensajes por debajo de 1 MB
Recomendamos mantener los mensajes en un tamaño inferior a 1 megabyte (MB) para obtener un rendimiento y una fiabilidad óptimos.
De forma predeterminada, RabbitMQ 3.13 admite mensajes de hasta 128 MB, pero los mensajes de gran tamaño pueden activar alarmas de memoria impredecibles que bloquean la publicación y pueden generar una gran presión de memoria al replicar los mensajes en los nodos. Los mensajes sobredimensionados también pueden afectar a los procesos de reinicio y recuperación de los agentes, lo que aumenta los riesgos para la continuidad del servicio y puede provocar una degradación del rendimiento.
**Almacene y recupere cargas útiles de gran tamaño mediante el patrón de verificación de notificaciones**
Para gestionar mensajes de gran tamaño, puede implementar el patrón de verificación de notificaciones almacenando la carga útil del mensaje en un almacenamiento externo y enviando únicamente el identificador de referencia de la carga útil a través de RabbitMQ. El consumidor utiliza el identificador de referencia de la carga útil para recuperar y procesar el mensaje de gran tamaño.
En el siguiente diagrama se muestra cómo utilizar Amazon MQ para RabbitMQ y Amazon S3 para implementar el patrón de verificación de notificaciones.
![\[Diagram showing data flow between Producer, Consumer, Amazon MQ broker, and AWS S3.\]](http://docs.aws.amazon.com/es_es/amazon-mq/latest/developer-guide/images/claim-check-pattern.png)
En el siguiente ejemplo, se muestra este patrón con Amazon MQ, el [AWS SDK para Java 2.x](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/home.html) y [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html):
1. En primer lugar, defina una clase de mensaje que contenga el identificador de referencia de Amazon S3.
```
class Message {
// Other data fields of the message...
public String s3Key;
public String s3Bucket;
}
```
1. Cree un método de publicación que almacene la carga útil en Amazon S3 y envíe un mensaje de referencia a través de 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. Implemente un método de consumo que recupere la carga útil de Amazon S3, la procese y elimine el objeto de 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());
}
```
## Paso 2: Uso `basic.consume` y consumo de larga duración
Usar `basic.consume` con un consumidor de larga duración es más eficiente que sondear los mensajes individuales utilizando `basic.get`. Para obtener más información, consulte [Sondeo de mensajes individuales](https://www.rabbitmq.com/docs/3.13/consumers#polling).
## Paso 3: Configurar la captura previa
Puede utilizar el valor de captura previa de RabbitMQ para optimizar la forma en que los consumidores consumen los mensajes. RabbitMQ implementa el mecanismo de captura previa de canales que proporciona AMQP 0-9-1 mediante la aplicación del recuento de captura previa a los consumidores en lugar de a los canales. El valor de captura previa se utiliza para especificar cuántos mensajes se envían al consumidor en un momento dado. De forma predeterminada, RabbitMQ establece un tamaño de búfer ilimitado para las aplicaciones cliente.
Hay varios factores a tener en cuenta al establecer un recuento de captura previa para los consumidores de RabbitMQ. Primero, considere el entorno y la configuración de los consumidores. Debido a que los consumidores necesitan mantener todos los mensajes en la memoria mientras se procesan, un alto valor de captura previa puede tener un impacto negativo en el rendimiento de los consumidores y, en algunos casos, puede provocar el bloqueo de todos los consumidores juntos. Del mismo modo, el propio agente de RabbitMQ guarda todos los mensajes que envía en la memoria caché hasta que recibe el acuse de recibo del consumidor. Un alto valor de captura previa puede hacer que el servidor de RabbitMQ se quede sin memoria rápidamente si el reconocimiento automático no está configurado para los consumidores y si los consumidores tardan un tiempo relativamente largo en procesar mensajes.
Teniendo en cuenta las consideraciones anteriores, recomendamos establecer siempre un valor de captura previa para evitar situaciones en las que un agente de RabbitMQ o sus consumidores se queden sin memoria debido a un gran número de mensajes sin procesar o sin reconocer. Si necesita optimizar sus agentes para que procesen grandes volúmenes de mensajes, puede probarlos junto con los consumidores utilizando un intervalo de recuentos de captura previa para determinar el valor en el que la sobrecarga de red se vuelve en gran medida insignificante en comparación con el tiempo que tarda un consumidor en procesar mensajes.
**nota**
Si las aplicaciones cliente se han configurado para confirmar automáticamente la entrega de mensajes a los consumidores, no servirá de nada establecer un valor de captura previa.
Todos los mensajes que capturados previamente se eliminan de la cola.
En el siguiente ejemplo, se muestra cómo establecer un valor de captura previa de `10` para un solo consumidor utilizando la biblioteca de clientes Java de 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);
```
**nota**
En la biblioteca de clientes Java de RabbitMQ, el valor predeterminado para el indicador `global` se establece en `false`, por lo que el ejemplo anterior se puede escribir simplemente como `channel.basicQos(10)`.
## Paso 4: Utilice Celery 5.5 o una versión posterior con las colas de cuórum
[Python Celery](https://docs.celeryq.dev/en/stable/index.html), un sistema de colas de tareas distribuidas, puede generar muchos mensajes no críticos cuando se experimenta una gran carga de tareas. Esta actividad adicional del agente puede provocar [Amazon MQ para RabbitMQ: alarma de memoria alta](troubleshooting-action-required-codes-rabbitmq-memory-alarm.md) y dar lugar a la falta de disponibilidad del agente. Para reducir la posibilidad de que se active una alarma de memoria, haga lo siguiente:
**Para todas las versiones de Celery**
1. Desactiva [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) para reducir la pérdida de colas.
1. A continuación, desactiva `worker_enable_remote_control` para detener la creación dinámica de colas `celery@...pidbox`. Esto reducirá la pérdida de colas en el agente.
```
worker_enable_remote_control = false
```
1. Para reducir aún más la actividad de mensajes no críticos, desactive Celery y no los incluya `-E` ni `--task-events` marque [worker-send-task-events](https://docs.celeryq.dev/en/stable/userguide/configuration.html#worker-send-task-events)al iniciar la aplicación Celery.
1. Inicie la aplicación Celery con los siguientes parámetros:
```
celery -A app_name worker --without-heartbeat --without-gossip --without-mingle
```
**Para las versiones 5.5 y superiores de Celery**
1. Actualice [Celery a la versión 5.5](https://docs.celeryq.dev/en/latest/changelog.html#version-5-5-0), la versión mínima que admite las colas de cuórum, o a una versión posterior. Para ver qué versión de Celery está usando, utilice `celery --version`. Para obtener más información sobre los cuórums, consulte [Colas de cuórum para RabbitMQ en Amazon MQ](quorum-queues.md).
1. Después de actualizar a Celery 5.5 o una versión posterior, configure `task_default_queue_type` en modo [“cuórum”](https://docs.celeryq.dev/en/stable/userguide/configuration.html#std-setting-task_default_queue_type).
1. A continuación, también debe activar la opción Publicar confirmaciones en [Broker Transport Options](https://docs.celeryq.dev/en/stable/userguide/configuration.html#std-setting-broker_transport_options):
```
broker_transport_options = {"confirm_publish": True}
```
# Prácticas recomendadas de supervisión y resiliencia de la red en Amazon MQ para RabbitMQ
La resiliencia de la red y las métricas de los agentes de supervisión son esenciales para mantener la fiabilidad de las aplicaciones de mensajería. Siga las siguientes prácticas recomendadas para implementar mecanismos de recuperación automática y estrategias de supervisión de recursos.
## Paso 1: Recuperación automática de fallas de red
Se recomienda habilitar siempre la recuperación automática de red para evitar un tiempo de inactividad significativo en caso de falla de las conexiones del cliente con los nodos de RabbitMQ. La biblioteca de cliente Java de RabbitMQ admite la recuperación automática de red de forma predeterminada, a partir de la versión `4.0.0`.
[La recuperación automática de la conexión se activa si se produce una excepción no controlada en el I/O bucle de la conexión, si se detecta el tiempo de espera de una operación de lectura del socket o si el servidor pierde un latido.](https://www.rabbitmq.com/heartbeats.html)
En caso de falla en la conexión inicial entre un cliente y un nodo de RabbitMQ, no se activará la recuperación automática. Recomendamos escribir el código de la aplicación para tener en cuenta los errores de conexión iniciales al volver a intentar la conexión. En el siguiente ejemplo, se muestran fallas al reintentar iniciar la red mediante la biblioteca de cliente Java de 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
}
```
**nota**
Si una aplicación cierra una conexión con el método `Connection.Close`, la recuperación automática de red no se activará ni se disparará.
## Paso 2: Supervise las métricas y las alarmas de los agentes
Le recomendamos que supervise periódicamente [CloudWatch las métricas](amazon-mq-accessing-metrics.md) y las alarmas de su agente de Amazon MQ for RabbitMQ para identificar y abordar posibles problemas antes de que afecten a su aplicación de mensajería. La supervisión proactiva es esencial para mantener una aplicación de mensajería flexible y garantizar un rendimiento óptimo.
Amazon MQ for RabbitMQ publica métricas CloudWatch que proporcionan información sobre el rendimiento de los corredores, la utilización de los recursos y el flujo de mensajes. Las métricas clave que se deben supervisar incluyen el uso de memoria y el uso del disco. Puede configurar [CloudWatch alarmas](https://docs.aws.amazon.com/Ihttps://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Metrics.html) para cuando su corredor se acerque a los límites de recursos o experimente una degradación del rendimiento.
Supervise las siguientes métricas esenciales:
**`RabbitMQMemUsed` y `RabbitMQMemLimit`**
Supervise el uso de la memoria para evitar que las alarmas de memoria puedan bloquear la publicación de mensajes.
**`RabbitMQDiskFree` y `RabbitMQDiskFreeLimit`**
Supervise el uso del disco para evitar problemas de espacio en disco que puedan provocar errores en el agente.
En el caso de las implementaciones de clústeres, supervise también las [métricas específicas de los nodos](rabbitmq-logging-monitoring.md#security-logging-monitoring-cloudwatch-destination-metrics-rabbitmq) para identificar problemas específicos de los nodos.
**nota**
Para obtener más información sobre cómo evitar una alarma de memoria excesiva, consulte [Abordar y evitar una alarma de memoria excesiva](troubleshooting-action-required-codes-rabbitmq-memory-alarm.md#address-prevent-high-memory-alarm).