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.
Las siguientes CloudWatch métricas ofrecen una buena visión ElastiCache del rendimiento. En la mayoría de los casos, le recomendamos que configure CloudWatch alarmas para estas métricas, de modo que pueda tomar medidas correctivas antes de que se produzcan problemas de rendimiento.
Métricas que se van a monitorear
CPUUtilization
Se trata de una métrica de nivel de host que muestra un valor como un porcentaje. Para obtener más información, consulte Métricas de nivel de host.
Valkey y Redis OSS
Para los tipos de nodos más pequeños con 2 V CPUs o menos, usa la CPUUtilization métrica para monitorear tu carga de trabajo.
En general, sugerimos que establezca el umbral en el 90 % del ancho de banda de la CPU disponible. Debido a que Valkey y Redis OSS usan un único subproceso, el valor del umbral real se debe calcular como una fracción de la capacidad total del nodo. Por ejemplo, supongamos que está usando un tipo de nodo con dos núcleos. En este caso, el umbral CPUUtilization sería de 90/2, es decir, del 45%.
Deberá determinar su propio umbral en función del número de núcleos del nodo de caché que use. Si supera este umbral y su carga de trabajo principal es de solicitudes de lectura, escale el clúster de caché de forma ascendente agregando réplicas de lectura. Si la carga de trabajo principal es de solicitudes de escritura, en función de la configuración del clúster, recomendamos que:
-
Clústeres de Valkey o Redis OSS (modo de clúster deshabilitado): escale verticalmente mediante un tipo de instancia con una caché de mayor tamaño.
-
Clústeres de Valkey o Redis OSS (modo de clúster habilitado): añada más particiones para distribuir la carga de trabajo de escritura entre más nodos principales.
sugerencia
En lugar de utilizar la métrica de host CPUUtilization, los usuarios de Valkey y Redis OSS podrían utilizar la métrica EngineCPUUtilization, que informa del porcentaje de uso en el núcleo del motor de Valkey o Redis OSS. Para ver si esta métrica está disponible en sus nodos y para obtener más información, consulte Métricas de Valkey y Redis OSS.
Para los tipos de nodos más grandes con 4 V CPUs o más, puede utilizar la EngineCPUUtilization métrica, que indica el porcentaje de uso en el núcleo del motor OSS de Valkey o Redis. Para ver si esta métrica está disponible en sus nodos y para obtener más información, consulte Metrics for Redis OSS.
Memcached
Como Memcached usa múltiples subprocesos, esta métrica puede llegar hasta el 90 %. Si supera este umbral, escale verticalmente su clúster de caché con un tipo de nodo de caché de mayor tamaño, o bien escálelo horizontalmente añadiendo más nodos de caché.
Motor CPUUtilization
Para los tipos de nodos más grandes con 4 V CPUs o más, puede utilizar la EngineCPUUtilization métrica, que indica el porcentaje de uso en el núcleo del motor OSS de Redis. Para ver si esta métrica está disponible en sus nodos y para obtener más información, consulte Métricas de Valkey y Redis OSS.
Para obtener más información, consulte la CPUssección Supervisión de las mejores prácticas con Amazon ElastiCache para Redis OSS mediante Amazon CloudWatch
SwapUsage (Valkey y Redis OSS)
Se trata de una métrica de nivel de host que muestra un valor en bytes. Para obtener más información, consulte Métricas de nivel de host.
Una FreeableMemory CloudWatch métrica cercana a 0 (es decir, inferior a 100 MB) o una SwapUsage métrica superior a la FreeableMemory métrica indica que un nodo está bajo presión de memoria. Si esto sucede, consulte los siguientes temas:
Evictions
Es una métrica del motor de la caché Recomendamos que determine su propio umbral de alarma para esta métrica en función de las necesidades de su aplicación.
Si está utilizando Memcached y supera el umbral elegido, escale verticalmente su clúster utilizando un tipo de nodo mayor o escálelo horizontalmente añadiendo más nodos.
CurrConnections
Es una métrica del motor de la caché Recomendamos que determine su propio umbral de alarma para esta métrica en función de las necesidades de su aplicación.
Un número creciente de CurrConnectionspodría indicar un problema con la aplicación; tendrá que investigar el comportamiento de la aplicación para solucionar este problema.
Para obtener más información, consulte la sección Conexiones en Supervisión de prácticas recomendadas con Amazon ElastiCache for Redis OSS mediante Amazon CloudWatch
Memoria (Valkey y Redis OSS)
La memoria es un aspecto central de Valkey y Redis OSS. Es necesario comprender la utilización de la memoria de un clúster para evitar la pérdida de datos y adaptarse al crecimiento futuro del conjunto de datos. Las estadísticas sobre el uso de memoria de un nodo se encuentran disponibles en la sección de memoria del comando INFO
Para obtener más información, consulte la sección Memoria en Supervisión de prácticas recomendadas con Amazon ElastiCache for Redis OSS mediante Amazon CloudWatch
Network
Uno de los factores determinantes de la capacidad de la banda ancha de red del clúster es el tipo de nodo seleccionado. Para obtener más información sobre la capacidad de red de tu nodo, consulta los ElastiCache precios de Amazon
Para obtener más información, consulte la sección Red en Supervisión de prácticas recomendadas con Amazon ElastiCache for Redis OSS mediante Amazon CloudWatch
Latencia
La medición del tiempo de respuesta ElastiCache de una instancia de Valkey se puede abordar de varias maneras en función del nivel de granularidad requerido. Las etapas clave que contribuyen al tiempo de respuesta general del servidor ElastiCache para Valkey son el preprocesamiento de los comandos, la ejecución y el posprocesamiento de los comandos.
Las métricas de latencia específicas de los comandos derivadas del comando INFO
Las métricas SuccessfulWriteRequestLatency de latencia SuccessfulReadRequestLatency miden el tiempo total que tarda el motor ElastiCache de Valkey en responder a una solicitud.
nota
Se pueden producir valores SuccessfulWriteRequestLatency y SuccessfulReadRequestLatency métricas exagerados cuando se utiliza la canalización de Valkey con la RESPUESTA DE CLIENTE habilitada en el cliente de Valkey. La canalización de Valkey es una técnica para mejorar el rendimiento mediante la emisión de varios comandos a la vez, sin esperar a que se responda a cada comando individual. Para evitar valores exagerados, te recomendamos configurar tu cliente de Valkey para que canalice comandos con la respuesta de cliente desactivada.
Para obtener más información, consulta la sección Latencia en Monitorización de las mejores prácticas con Amazon ElastiCache mediante Amazon CloudWatch
Replicación
El volumen de datos que se replican es visible a través de la métrica ReplicationBytes. Aunque esta métrica representa la carga de escritura del grupo de replicación, no proporciona información acerca del estado de replicación. Para este propósito, puede utilizar la métrica ReplicationLag.
Para obtener más información, consulte la sección Replicación en Supervisión de las mejores prácticas con Amazon ElastiCache para Redis OSS mediante Amazon CloudWatch
Administración del tráfico (Valkey y Redis OSS)
ElastiCache para Redis, OSS gestiona automáticamente el tráfico de un nodo cuando se envían al nodo más comandos entrantes de los que pueden procesar Valkey o Redis OSS. Esto se hace para mantener un funcionamiento y una estabilidad óptimos del motor.
Cuando el tráfico se administra activamente en un nodo, la métrica TrafficManagementActive emite puntos de datos de 1. Esto indica que el nodo ha disminuido la escala para la carga de trabajo que se proporciona. Si esta métrica sigue siendo 1 durante largos periodos de tiempo, evalúe el clúster para decidir si es necesario escalar verticalmente o escalar horizontalmente.
Para obtener más información, consulte la métrica TrafficManagementActive en la página Métricas.
