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 indicateurs suivants offrent un bon aperçu ElastiCache des performances. 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 (Valkey et Redis OSS)](#metrics-swap-usage) + [Evictions](#metrics-evictions) + [CurrConnections](#metrics-curr-connections) + [Mémoire (Valkey et Redis OSS)](#metrics-memory) + [Réseau](#metrics-network) + [Latence](#metrics-latency) + [Réplication](#metrics-replication) + [Gestion du trafic (Valkey et Redis OSS)](#traffic-management) ## 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](CacheMetrics.HostLevel.md). **Valkey et Redis OSS** 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 tous deux à thread unique, 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 %. Vous devez déterminer votre propre seuil, en fonction du nombre de cœurs dans le nœud de cache 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 principale charge de travail provient de demandes d'écriture, selon la configuration de votre cluster, nous vous recommandons de : + **Clusters Valkey ou Redis OSS (mode cluster désactivé) :** augmentez votre capacité en utilisant un type d'instance de cache plus important. + **Clusters Valkey ou Redis OSS (mode cluster activé) :** ajoutez des partitions supplémentaires pour répartir la charge d'écriture sur un plus grand nombre de nœuds principaux. **Astuce** Au lieu d'utiliser la métrique au niveau de l'hôte`CPUUtilization`, les utilisateurs de Valkey et Redis OSS peuvent 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 Valkey and Redis OSS](CacheMetrics.Redis.md). 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 Redis OSS](CacheMetrics.Redis.md). **Memcached** Puisque Memcached est multi-thread, cette métrique peut atteindre jusqu'à 90 %. Si vous dépassez ce seuil, augmentez votre cluster en utilisant un type de nœud de cache plus important ou augmentez la taille en ajoutant d'autres nœuds de cache. ## 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 Redis OSS. Pour savoir si cette métrique est disponible sur vos nœuds et pour plus d'informations, consultez [Metrics for Valkey and Redis OSS](CacheMetrics.Redis.md). Pour plus d'informations, consultez la **CPUs**section consacrée à la [surveillance des meilleures pratiques avec Amazon ElastiCache pour Redis OSS à l'aide d'Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/). ## SwapUsage (Valkey et Redis OSS) 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](CacheMetrics.HostLevel.md). Si la `FreeableMemory` CloudWatch métrique est proche de 0 (c'est-à-dire inférieure à 100 Mo) ou supérieure à la `SwapUsage` `FreeableMemory` métrique, cela indique qu'un nœud est soumis à une pression de mémoire. Si cela se produit, consultez les rubriques suivantes : + [S'assurer que vous disposez de suffisamment de mémoire pour créer un instantané Valkey ou Redis OSS](BestPractices.BGSAVE.md) + [Gestion de la mémoire réservée pour Valkey et Redis OSS](redis-memory-management.md) ## Evictions Il s'agit d'une métrique de moteur de cache. Nous vous recommandons de choisir votre propre seuil d'alarme pour cette métrique en fonction des besoins de votre application. Si vous utilisez Memcached et que vous dépassez le seuil que vous avez choisi, augmentez votre cluster en utilisant un type de nœud plus grand ou augmentez la taille en ajoutant de nouveaux nœuds. ## CurrConnections Il s'agit d'une métrique de moteur de cache. 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. Pour plus d'informations, consultez la section **Connexions** sur [Surveillance des meilleures pratiques avec Amazon ElastiCache pour Redis OSS à l'aide d'Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/). ## Mémoire (Valkey et Redis OSS) La mémoire est un aspect essentiel de Valkey et 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). Pour plus d'informations, consultez la section **Mémoire** de la section [Surveillance des meilleures pratiques avec Amazon ElastiCache pour Redis OSS à l'aide d'Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/). ## 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 les [ ElastiCache tarifs Amazon](https://aws.amazon.com/elasticache/pricing/). Pour plus d'informations, consultez la section **Réseau** sur la section [Surveillance des meilleures pratiques avec Amazon ElastiCache pour Redis OSS à l'aide d'Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/). ## Latence La mesure du temps de réponse ElastiCache pour une instance for Valkey peut être abordée de différentes manières en fonction du niveau de granularité requis. Les étapes clés qui contribuent au temps de réponse global côté serveur ElastiCache pour Valkey sont le prétraitement des commandes, l'exécution des commandes et le post-traitement des commandes. Les métriques de latence spécifiques à la commande dérivées de la commande Valkey [INFO](https://valkey.io/commands/info), telles que GetTypeCmdsLatency les SetTypeCmdsLatency métriques, se concentrent spécifiquement sur l'exécution de la logique de commande de base pour la commande Valkey. Ces mesures seront utiles si votre cas d'utilisation consiste à déterminer le temps d'exécution des commandes ou les latences agrégées par structure de données. Les métriques `SuccessfulWriteRequestLatency` de latence `SuccessfulReadRequestLatency` mesurent le temps total nécessaire au moteur ElastiCache for Valkey pour répondre à une demande. **Note** Des valeurs `SuccessfulWriteRequestLatency` et des `SuccessfulReadRequestLatency` métriques gonflées peuvent se produire 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 Valkey pour qu'il achemine les commandes avec [CLIENT REPLY OFF.](https://valkey.io/commands/client-reply/) Pour plus d'informations, consultez la section **Latence** de la section [Surveillance des meilleures pratiques avec Amazon à ElastiCache l'aide d'Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/). ## Réplication Le volume de données en cours de réplication est visible via le métrique `ReplicationBytes`. Bien que cette métrique soit représentative de la charge d'écriture sur le groupe de réplication, elle ne fournit pas d'informations sur l'intégrité de la réplication. Pour ce faire, vous pouvez utiliser la métrique `ReplicationLag`. Pour plus d'informations, consultez la section **Réplication** sur [Surveillance des meilleures pratiques avec Amazon ElastiCache pour Redis OSS à l'aide d'Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/). ## Gestion du trafic (Valkey et Redis OSS) ElastiCache for Redis OSS gère automatiquement le trafic vers un nœud lorsque le nombre de commandes entrantes envoyées au nœud est supérieur à ce qui peut être traité par Valkey ou Redis OSS. Cela vise à maintenir un fonctionnement et une stabilité optimaux du moteur. Lorsque le trafic est géré activement sur un nœud, la métrique `TrafficManagementActive` émet des points de données de valeur 1. Cela indique que le nœud est peut-être sous-dimensionné pour la charge de travail fournie. Si cette métrique reste à 1 sur de longues périodes, évaluez le cluster pour décider s'il est nécessaire de procéder à une augmentation ou à une montée en puissance. Pour en savoir plus, consultez la métrique `TrafficManagementActive` sur la page [Métriques](CacheMetrics.Redis.md).