

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.

# ¿Qué métricas debo monitorear?
<a name="metrics.whichshouldimonitor"></a>

Las siguientes métricas de CloudWatch ofrecen datos útiles sobre el rendimiento de MemoryDB. En la mayoría de los casos, recomendamos que configure alarmas de CloudWatch para estas métricas con el fin de poder emprender acciones correctivas antes de que se produzca el problema de rendimiento.

**Topics**
+ [CPUUtilization](#metrics-cpu-utilization)
+ [EngineCPUUtilization](#metrics-engine-cpu-utilization)
+ [SwapUsage](#metrics-swap-usage)
+ [Evictions](#metrics-evictions)
+ [CurrConnections](#metrics-curr-connections)
+ [Memoria](#metrics-memory)
+ [Network](#metrics-network)
+ [Latencia](#metrics-latency)
+ [Replicación](#metrics-replication)

## CPUUtilization
<a name="metrics-cpu-utilization"></a>

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](metrics.HostLevel.md).

 En los tipos de nodos pequeños que tienen dos CPU virtuales o menos, utilice la métrica `CPUUtilization ` para monitorear la 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 de CPUUtilization sería de 90/2, es decir, el 45 %. Para encontrar el número de núcleos (vCPU) que tiene su tipo de nodo, consulte [Precios de MemoryDB](https://aws.amazon.com/memorydb/pricing/?p=ps).

Deberá determinar su propio umbral en función del número de núcleos del nodo que use. Si supera este umbral y su carga de trabajo principal es de solicitudes de lectura, escale el clúster de forma ascendente agregando réplicas de lectura. Si la carga de trabajo principal es de solicitudes de escritura, recomendamos que agregue 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 nivel de host `CPUUtilization`, puede utilizar la métrica `EngineCPUUtilization`, que indica el porcentaje de uso del 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 MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).

Es posible que, en los tipos de nodos con cuatro o más CPU virtuales, desee utilizar la métrica `EngineCPUUtilization`, que indica el porcentaje de uso del 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 MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).

## EngineCPUUtilization
<a name="metrics-engine-cpu-utilization"></a>

Es posible que, en los tipos de nodos con cuatro o más CPU virtuales, desee utilizar la métrica `EngineCPUUtilization`, que indica el porcentaje de uso del 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 MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).

## SwapUsage
<a name="metrics-swap-usage"></a>

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](metrics.HostLevel.md).

Si la métrica de CloudWatch `FreeableMemory` está cerca de 0 (es decir, por debajo de 100 MB) o la métrica `SwapUsage` es mayor que la métrica `FreeableMemory`, un nodo podría estar bajo presión de memoria.

## Evictions
<a name="metrics-evictions"></a>

Es una métrica del motor. Recomendamos que determine su propio umbral de alarma para esta métrica en función de las necesidades de su aplicación.

## CurrConnections
<a name="metrics-curr-connections"></a>

Es una métrica del motor. 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 de *CurrConnections* cada vez mayor puede indicar que existe un problema con la aplicación. Por lo tanto, deberá investigar el comportamiento de la aplicación antes de abordar este problema. 

## Memoria
<a name="metrics-memory"></a>

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](https://valkey.io/commands/info).

## Network
<a name="metrics-network"></a>

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 del nodo, consulte [Precios de Amazon MemoryDB](https://aws.amazon.com/memorydb/pricing/).

## Latencia
<a name="metrics-latency"></a>

La latencia mide `SuccessfulWriteRequestLatency` y `SuccessfulReadRequestLatency` mide el tiempo total que MemoryDB para el motor Valkey tarda en responder a una solicitud.

**nota**  
Cuando se utiliza la canalización de Valkey con CLIENT REPLY habilitado en el cliente de Valkey, pueden generarse valores y métricas se inflen para `SuccessfulWriteRequestLatency` y `SuccessfulReadRequestLatency`. 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 que se inflen los valores, recomendamos configurar el cliente Redis para que canalice los comandos con [CLIENT REPLY OFF](https://valkey.io/commands/client-reply/).

## Replicación
<a name="metrics-replication"></a>

El volumen de datos que se replican es visible a través de la métrica `ReplicationBytes`. Puede realizar un seguimiento del rendimiento de la capacidad de replicación de `MaxReplicationThroughput`. Se recomienda agregar más particiones cuando se alcance el rendimiento máximo de la capacidad de replicación.

`ReplicationDelayedWriteCommands` también puede indicar si la carga de trabajo supera el rendimiento máximo de la capacidad de replicación. Para obtener más información sobre cómo replicar en MemoryDB, consulte [Descripción de cómo replicar en MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/replication.html)