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.
# Quelles métriques dois-je surveiller ?
Les CloudWatch mesures suivantes offrent un bon aperçu des performances de MemoryDB. Dans la plupart des cas, nous vous recommandons de définir des CloudWatch alarmes pour ces mesures afin de pouvoir prendre des mesures correctives avant que des problèmes de performances ne surviennent.
**Topics**
+ [CPUUtilization](#metrics-cpu-utilization)
+ [Moteur CPUUtilization](#metrics-engine-cpu-utilization)
+ [SwapUsage](#metrics-swap-usage)
+ [Evictions](#metrics-evictions)
+ [CurrConnections](#metrics-curr-connections)
+ [Mémoire](#metrics-memory)
+ [Réseau](#metrics-network)
+ [Latence](#metrics-latency)
+ [Réplication](#metrics-replication)
## CPUUtilization
Il s'agit d'une métrique au niveau de l'hôte représentée en pourcentage. Pour de plus amples informations, veuillez consulter [Métriques au niveau de l'hôte](metrics.HostLevel.md).
Pour les types de nœuds plus petits avec 2 V CPUs ou moins, utilisez la `CPUUtilization ` métrique pour surveiller votre charge de travail.
En général, nous vous suggérons de définir votre seuil à 90 % de votre UC disponible. Valkey et Redis OSS étant monothread, la valeur de seuil réelle doit être calculée en tant que fraction de la capacité totale du nœud. Supposons par exemple que vous utilisiez un type de nœud comportant deux cœurs. Dans ce cas, le seuil CPUUtilization serait de 90/2, soit 45 %. Pour connaître le nombre de cœurs (vCPUs) de votre type de nœud, consultez la section Tarification de [MemoryDB](https://aws.amazon.com/memorydb/pricing/?p=ps).
Vous devrez déterminer votre propre seuil, en fonction du nombre de cœurs du nœud que vous utilisez. Si vous dépassez ce seuil et que votre charge de travail principale provient des demandes de lecture, agrandissez votre cluster en ajoutant des répliques de lecture. Si la charge de travail principale provient de demandes d'écriture, nous vous recommandons d'ajouter des partitions supplémentaires afin de répartir la charge de travail d'écriture sur un plus grand nombre de nœuds principaux.
**Astuce**
Au lieu d'utiliser la métrique Host-Level`CPUUtilization`, vous pouvez peut-être utiliser la métrique`EngineCPUUtilization`, qui indique le pourcentage d'utilisation sur le cœur du moteur Valkey ou Redis OSS. Pour savoir si cette métrique est disponible sur vos nœuds et pour plus d'informations, consultez [Metrics for MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
Pour les types de nœuds plus grands avec 4 V CPUs ou plus, vous pouvez utiliser la `EngineCPUUtilization` métrique, qui indique le pourcentage d'utilisation sur le cœur du moteur Valkey ou Redis OSS. Pour savoir si cette métrique est disponible sur vos nœuds et pour plus d'informations, consultez [Metrics for MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
## Moteur CPUUtilization
Pour les types de nœuds plus grands avec 4 V CPUs ou plus, vous pouvez utiliser la `EngineCPUUtilization` métrique, qui indique le pourcentage d'utilisation sur le cœur du moteur Valkey ou Redis OSS. Pour savoir si cette métrique est disponible sur vos nœuds et pour plus d'informations, consultez [Metrics for MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
## SwapUsage
Il s'agit d'une métrique au niveau de l'hôte, publiée en octets. Pour de plus amples informations, veuillez consulter [Métriques au niveau de l'hôte](metrics.HostLevel.md).
Si la `FreeableMemory` CloudWatch métrique est proche de 0 (c'est-à-dire inférieure à 100 Mo) ou si elle est supérieure à la `SwapUsage` `FreeableMemory` métrique, il se peut qu'un nœud soit soumis à une pression de mémoire.
## Evictions
Il s'agit d'une métrique du moteur. Nous vous recommandons de choisir votre propre seuil d'alarme pour cette métrique en fonction des besoins de votre application.
## CurrConnections
Il s'agit d'une métrique du moteur. Nous vous recommandons de choisir votre propre seuil d'alarme pour cette métrique en fonction des besoins de votre application.
Un nombre croissant de *CurrConnections*chiffres peut indiquer un problème avec votre application ; vous devrez étudier le comportement de l'application pour résoudre ce problème.
## Mémoire
La mémoire est au cœur de Valkey et de Redis OSS. Il est nécessaire de comprendre l'utilisation de la mémoire de votre cluster afin d'éviter la perte de données et de tenir compte de la croissance future de votre jeu de données. Les statistiques relatives à l'utilisation de la mémoire d'un nœud sont disponibles dans la section mémoire de la commande [INFO](https://valkey.io/commands/info).
## Réseau
L'un des facteurs déterminants de la capacité de bande passante réseau de votre cluster est le type de nœud que vous avez sélectionné. Pour plus d'informations sur la capacité réseau de votre nœud, consultez la tarification d'[Amazon MemoryDB](https://aws.amazon.com/memorydb/pricing/).
## Latence
Les métriques `SuccessfulWriteRequestLatency` de latence `SuccessfulReadRequestLatency` mesurent le temps total nécessaire à MemoryDB pour le moteur Valkey pour répondre à une demande.
**Note**
Des valeurs `SuccessfulWriteRequestLatency` et des `SuccessfulReadRequestLatency` métriques gonflées peuvent survenir lors de l'utilisation du pipeline Valkey avec CLIENT REPLY activé sur le client Valkey. Le pipeline Valkey est une technique permettant d'améliorer les performances en émettant plusieurs commandes à la fois, sans attendre la réponse à chaque commande individuelle. Pour éviter les valeurs exagérées, nous vous recommandons de configurer votre client Redis pour qu'il achemine les commandes avec [CLIENT REPLY OFF.](https://valkey.io/commands/client-reply/)
## Réplication
Le volume de données en cours de réplication est visible via le métrique `ReplicationBytes`. Vous pouvez effectuer une surveillance `MaxReplicationThroughput` par rapport au débit de la capacité de réplication. Il est recommandé d'ajouter des partitions supplémentaires lorsque le débit de capacité de réplication maximal est atteint.
`ReplicationDelayedWriteCommands`peut également indiquer si la charge de travail dépasse le débit maximal de capacité de réplication. Pour plus d'informations sur la réplication dans MemoryDB, voir [Comprendre](https://docs.aws.amazon.com/memorydb/latest/devguide/replication.html) la réplication MemoryDB