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.
# Surveillance de l'utilisation à l'aide de CloudWatch métriques
ElastiCache fournit des métriques qui vous permettent de surveiller vos clusters. Vous pouvez accéder à ces statistiques via CloudWatch. Pour plus d'informations CloudWatch, consultez la [CloudWatch documentation.](https://aws.amazon.com/documentation/cloudwatch/)
ElastiCache fournit à la fois des métriques au niveau de l'hôte (par exemple, l'utilisation du processeur) et des métriques spécifiques au logiciel du moteur de cache (par exemple, les mises en cache et les erreurs de cache). Ces mesures sont mesurées et publiées pour chaque nœud de cache à intervalles de 60 secondes.
**Important**
Vous devriez envisager de définir des CloudWatch alarmes pour certains indicateurs clés, afin d'être averti si les performances de votre cluster commencent à se dégrader. Pour plus d’informations, consultez [Quelles métriques dois-je surveiller ?](CacheMetrics.WhichShouldIMonitor.md) dans ce guide.
**Topics**
+ [Métriques au niveau de l'hôte](CacheMetrics.HostLevel.md)
+ [Métriques pour Valkey et Redis OSS](CacheMetrics.Redis.md)
+ [Métriques pour Memcached](CacheMetrics.Memcached.md)
+ [Quelles métriques dois-je surveiller ?](CacheMetrics.WhichShouldIMonitor.md)
+ [Choix des périodes et des statistiques de métriques](CacheMetrics.ChoosingStatisticsAndPeriods.md)
+ [Surveillance des métriques des CloudWatch clusters et des nœuds](CloudWatchMetrics.md)
# Métriques au niveau de l'hôte
L'espace de noms `AWS/ElastiCache` inclut les métriques au niveau de l'hôte suivantes pour les nœuds de cache individuels. Ces métriques sont mesurées et publiées pour chaque nœud de cache toutes les 60 secondes.
**Voir aussi**
+ [Métriques pour Valkey et Redis OSS](CacheMetrics.Redis.md)
| Métrique | Description | Unit |
| --- | --- | --- |
| CPUUtilization | Le pourcentage d'utilisation de l'UC pour l'hôte entier. Valkey et Redis OSS étant à thread unique, nous vous recommandons de surveiller les EngineCPUUtilization métriques pour les nœuds contenant 4 v. ou plus. CPUs | Pourcentage |
| CPUCreditBalance | Nombre de crédits UC gagnés qu’une instance a accumulés depuis son lancement ou son démarrage. Pour T2 Standard, le CPUCredit solde inclut également le nombre de crédits de lancement accumulés. Les crédits sont accumulés dans le solde de crédits quand ils sont gagnés et supprimés du solde de crédits lorsqu’ils sont dépensés. Le solde de crédits présente une limite maximum qui est déterminée par la taille de l’instance. Une fois que la limite est atteinte, tous les nouveaux crédits gagnés sont rejetés. Pour les instances T2 Standard, les crédits de lancement ne sont pas comptés dans la limite. Les crédits figurant dans le CPUCredit solde peuvent être dépensés par l'instance pour dépasser son taux d'utilisation du processeur de base. Les métriques de crédits UC sont disponibles uniquement toutes les 5 minutes. Cette métrique n'est pas disponible pour les instances de performance à capacité extensible T2. | Crédits (minutes vCPU) |
| CPUCreditUsage | Nombre de crédits UC dépensés par l’instance pour l’utilisation de l’UC. Un crédit de processeur équivaut à un vCPU fonctionnant à 100 % d'utilisation pendant une minute ou une combinaison équivalente de vCPUs, d'utilisation et de temps (par exemple, un vCPU fonctionnant à 50 % d'utilisation pendant deux minutes ou deux vCPU CPUs fonctionnant à 25 % d'utilisation pendant deux minutes). Les métriques de crédits UC sont disponibles uniquement toutes les 5 minutes. Si vous spécifiez une période supérieure à cinq minutes, utilisez la statistique Sum au lieu de la statistique Average. Cette métrique n'est pas disponible pour les instances de performance à capacité extensible T2. | Crédits (minutes vCPU) |
| FreeableMemory | Espace mémoire disponible sur l'hôte. Ceci est dérivé des tampons de RAM et de cache que le SE affiche comme libérables. | Octets |
| NetworkBytesIn | Nombre d'octets lus par l'hôte à partir du réseau. | Octets |
| NetworkBytesOut | Nombre d'octets envoyés par l'instance sur toutes les interfaces réseau. | Octets |
| NetworkPacketsIn | Nombre de paquets reçus par l'instance sur toutes les interfaces réseau. Cette métrique identifie le volume du trafic entrant en ce qui concerne le nombre de paquets sur une seule instance. | Nombre |
| NetworkPacketsOut | Nombre de paquets envoyés par l'instance sur toutes les interfaces réseau. Cette métrique identifie le volume du trafic sortant en ce qui concerne le nombre de paquets sur une seule instance. | Nombre |
| NetworkBandwidthInAllowanceExceeded | Nombre de paquets mis en file d’attente ou ignorés flottee que la bande passante agrégée entrante a dépassé le maximum de l’instance. | Nombre |
| NetworkConntrackAllowanceExceeded | Nombre de paquets ignorés flottee que le suivi des connexions a dépassé le maximum de l’instance et que de nouvelles connexions n’ont pas pu être établies. Cela peut entraîner une perte de paquets pour le trafic vers ou en provenance de l’instance. | Nombre |
| NetworkBandwidthOutAllowanceExceeded | Nombre de paquets mis en file d’attente ou ignorés flottee que la bande passante agrégée sortante a dépassé le maximum de l’instance. | Nombre |
| NetworkPacketsPerSecondAllowanceExceeded | Le nombre de paquets mis en file d'attente ou abandonnés parce que les paquets bidirectionnels par seconde ont dépassé le maximum pour l'instance. | Nombre |
| NetworkMaxBytesIn | Nombre maximal d'octets reçus par seconde par minute. | Octets |
| NetworkMaxBytesOut | Nombre maximal d'octets transmis par seconde par minute. | Octets |
| NetworkMaxPacketsIn | Nombre maximal de paquets reçus par seconde par rafale par minute. | Nombre |
| NetworkMaxPacketsOut | Nombre maximal de paquets transmis par seconde par minute. | Nombre |
| SwapUsage | Nombre de permutations utilisées sur l'hôte. | Octets |
# Métriques pour Valkey et Redis OSS
L'espace de `Amazon ElastiCache` noms inclut les métriques Valkey et Redis OSS suivantes. Ces métriques sont les mêmes lorsque vous utilisez le moteur Valkey.
À l'exception de`ReplicationLag`, `EngineCPUUtilization``SuccessfulWriteRequestLatency`, et`SuccessfulReadRequestLatency`, ces métriques sont dérivées de la **info** commande. Chaque métrique est calculée au niveau du nœud de cache.
Pour une documentation complète de la **info** commande, consultez [http://valkey. io/commands/info](https://valkey.io/commands/info).
**Voir aussi**
+ [Métriques au niveau de l'hôte](CacheMetrics.HostLevel.md)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/CacheMetrics.Redis.html)
**CPUUtilization Disponibilité du moteur**
AWS Les régions répertoriées ci-dessous sont disponibles sur tous les types de nœuds pris en charge.
| Région | Nom de la région |
| --- | --- |
| us-east-2 | USA Est (Ohio) |
| us-east-1 | USA Est (Virginie du Nord) |
| us-west-1 | USA Ouest (Californie du Nord) |
| us-west-2 | USA Ouest (Oregon) |
| ap-northeast-1 | Asie Pacifique (Tokyo) |
| ap-northeast-2 | Asie-Pacifique (Séoul) |
| ap-northeast-3 | Asie-Pacifique (Osaka) |
| ap-east-1 | Asie-Pacifique (Hong Kong) |
| ap-south-1 | Asie-Pacifique (Mumbai) |
| ap-southeast-1 | Asie-Pacifique (Singapour) |
| ap-southeast-2 | Asie-Pacifique (Sydney) |
| ap-southeast-3 | Asie-Pacifique (Jakarta) |
| ca-central-1 | Canada (Centre) |
| cn-north-1 | Chine (Pékin) |
| cn-northwest-2 | Chine (Ningxia) |
| me-south-1 | Middle East (Bahrain) |
| eu-central-1 | Europe (Francfort) |
| eu-west-1 | Europe (Irlande) |
| eu-west-2 | Europe (Londres) |
| eu-west-3 | UE (Paris) |
| eu-south-1 | Europe (Milan) |
| af-south-1 | Afrique (Le Cap) |
| eu-north-1 | Europe (Stockholm) |
| sa-east-1 | Amérique du Sud (São Paulo) |
| us-gov-west-1 | AWS GovCloud (US-Ouest) |
| us-gov-east-1 | AWS GovCloud (USA Est) |
Voici des regroupements de certains types de commandes, dérivés de **info commandstats**. La section commandstats fournit des statistiques basées sur le type de commande, y compris le nombre d'appels, le temps CPU total consommé par ces commandes et le CPU moyen consommé par exécution de commande. Pour chaque type de commande, la ligne suivante est ajoutée : `cmdstat_XXX: calls=XXX,usec=XXX,usec_per_call=XXX`.
[Les mesures de latence répertoriées ci-dessous sont calculées à l'aide des statistiques de commande d'INFO.](https://valkey.io/commands/info) Elles sont calculées de la manière suivante : `delta(usec)/delta(calls)`. `delta` est calculé comme la diff. dans une minute. La latence est définie comme le temps nécessaire au processeur ElastiCache pour traiter la commande. Notez que pour les clusters utilisant la hiérarchisation des données, le temps nécessaire à la récupération des éléments à partir du SSD n’est pas inclus dans ces mesures.
Pour une liste complète des commandes disponibles, consultez les [commandes](https://valkey.io/commands) dans la documentation de Valkey.
| Métrique | Description | Unit |
| --- | --- | --- |
| ClusterBasedCmds | Nombre total de commandes basées sur un cluster. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur un cluster (cluster slot,cluster info, etc.). | Nombre |
| ClusterBasedCmdsLatency | Latence des commandes basées sur un cluster. | Microsecondes |
| EvalBasedCmds | Nombre total de commandes pour les commandes basées sur eval. Ceci est dérivé de la commandstats statistique en additionnanteval,. evalsha | Nombre |
| EvalBasedCmdsLatency | Latence des commandes basées sur Eval. | Microsecondes |
| GeoSpatialBasedCmds | Nombre total de commandes pour les commandes basées sur la géolocalisation. Ceci est dérivé de la commandstats statistique. Il est dérivé en additionnant tous les types de commandes géo : geoadd, geodist, geohash, geopos, georadius et georadiusbymember. | Nombre |
| GeoSpatialBasedCmdsLatency | Latence des commandes basées sur la géolocalisation. | Microsecondes |
| GetTypeCmds | Le nombre total de commandes basées sur les types de commandes read-only. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes de read-only type (gethget,scard,lrange,, etc.) | Nombre |
| GetTypeCmdsLatency | Latence des commandes de lecture. | Microsecondes |
| HashBasedCmds | Nombre total de commandes basées sur le hachage. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur un ou plusieurs hachages (hget,,,hkeys, hvalshdel, etc.). | Nombre |
| HashBasedCmdsLatency | Latence des commandes basées sur le hachage. | Microsecondes |
| HyperLogLogBasedCmds | Nombre total de commandes basées sur HyperLogLog. Ceci est dérivé de la commandstats statistique en additionnant tous les pf types de commandes (pfaddpfcount,pfmerge,, etc.). | Nombre |
| HyperLogLogBasedCmdsLatency | Latence des commandes HyperLogLog basées. | Microsecondes |
| JsonBasedCmds | Nombre total de commandes JSON, y compris les commandes de lecture et d'écriture. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes JSON qui agissent sur les clés JSON. | Nombre |
| JsonBasedCmdsLatency | Latence de toutes les commandes JSON, y compris les commandes de lecture et d'écriture. | Microsecondes |
| JsonBasedGetCmds | Nombre total de commandes en lecture seule JSON. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes de lecture JSON qui agissent sur les clés JSON. | Nombre |
| JsonBasedGetCmdsLatency | Latence des commandes en lecture seule JSON. | Microsecondes |
| JsonBasedSetCmds | Nombre total de commandes d'écriture JSON. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes d'écriture JSON qui agissent sur les clés JSON. | Nombre |
| JsonBasedSetCmdsLatency | Latence des commandes d'écriture JSON. | Microsecondes |
| KeyBasedCmds | Nombre total de commandes basées sur une clé. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur une ou plusieurs touches dans plusieurs structures de données (delexpire,rename,, etc.). | Nombre |
| KeyBasedCmdsLatency | Latence des commandes basées sur les clés. | Microsecondes |
| ListBasedCmds | Nombre total de commandes basées sur une liste. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur une ou plusieurs listes (lindex,lrange,lpush,ltrim, etc.). | Nombre |
| ListBasedCmdsLatency | Latence des commandes basées sur la liste. | Microsecondes |
| NonKeyTypeCmds | Nombre total de commandes non basées sur des clés. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui n'agissent pas sur une touche, par exempleacl, dbsize ou. info | Nombre |
| NonKeyTypeCmdsLatency | Latence des non-key-based commandes. | Microsecondes |
| PubSubBasedCmds | Nombre total de commandes pour les pub/sub fonctionnalités. Ceci est dérivé des commandstats statistiques en additionnant toutes les commandes utilisées pour les pub/sub fonctionnalités : psubscribepublish,pubsub,punsubscribe,ssubscribe,sunsubscribe, spublishsubscribe, etunsubscribe. | Nombre |
| PubSubBasedCmdsLatency | Latence des commandes basées sur pub/sub. | Microsecondes |
| SetBasedCmds | Nombre total de commandes basées sur un ensemble. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur un ou plusieurs ensembles (scard,sdiff,sadd,sunion, etc.). | Nombre |
| SetBasedCmdsLatency | Latence des commandes basées sur des ensembles. | Microsecondes |
| SetTypeCmds | Le nombre total de commandes de type write. Ceci est dérivé de la commandstats statistique en additionnant tous les mutative types de commandes qui opèrent sur les données (sethset,sadd,lpop,, etc.) | Nombre |
| SetTypeCmdsLatency | Latence des commandes d'écriture. | Microsecondes |
| SortedSetBasedCmds | Nombre total de commandes qui sont triées en fonction d'un ensemble. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur un ou plusieurs ensembles triés (zcount,zrange,zrank,zadd, etc.). | Nombre |
| SortedSetBasedCmdsLatency | Latence des commandes basées sur le tri. | Microsecondes |
| StringBasedCmds | Nombre total de commandes basées sur une chaîne. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur une ou plusieurs chaînes (strlen,setex,setrange, etc.). | Nombre |
| StringBasedCmdsLatency | Latence des commandes basées sur des chaînes | Microsecondes |
| StreamBasedCmds | Nombre total de commandes basées sur un flux. Ceci est dérivé de la commandstats statistique en additionnant toutes les commandes qui agissent sur un ou plusieurs types de données de flux (xrange,xlen,xadd,xdel, etc.). | Nombre |
| StreamBasedCmdsLatency | Latence des commandes basées sur des flux. | Microsecondes |
| SearchBasedCmds | Le nombre total de commandes de recherche, y compris les commandes de lecture et d'écriture. Ceci est dérivé de la statistique commandstats en additionnant toutes les commandes de recherche. | Nombre |
| SearchBasedCmdsLatency | Latence de toutes les commandes de recherche, y compris les commandes de lecture et d'écriture. | Microsecondes |
| SearchBasedGetCmds | Nombre total de commandes de recherche en lecture seule. Ceci est dérivé de la statistique commandstats en additionnant toutes les commandes de lecture de recherche. | Nombre |
| SearchBasedGetCmdsLatency | Latence des commandes de recherche en lecture seule. | Microsecondes |
| SearchBasedSetCmds | Nombre total de commandes d'écriture de recherche. Ceci est dérivé de la statistique commandstats en additionnant toutes les commandes d'écriture de Search. | Nombre |
| SearchBasedSetCmdsLatency | Latence des commandes d'écriture Search. | Microsecondes |
# Métriques pour Memcached
L'espace de noms `AWS/ElastiCache` inclut les métriques Memcached suivantes.
L'espace de ElastiCache noms AWS/inclut les métriques suivantes qui sont dérivées de la commande Memcached stats. Chaque métrique est calculée au niveau du nœud de cache.
**Voir aussi**
+ [Métriques au niveau de l'hôte](CacheMetrics.HostLevel.md)
| Métrique | Description | Unit |
| --- | --- | --- |
| BytesReadIntoMemcached | Nombre d'octets lus par le nœud de cache à partir du réseau. | Octets |
| BytesUsedForCacheItems | Nombre d'octets utilisés pour stocker les éléments de cache. | Octets |
| BytesWrittenOutFromMemcached | Nombre d'octets écrits par le nœud de cache sur le réseau. | Octets |
| CasBadval | Nombre de requêtes CAS (vérification et définition) reçues par le cache dans lesquelles la valeur CAS ne correspondait pas à la valeur CAS stockée. | Nombre |
| CasHits | Nombre de requêtes CAS reçues par le cache dans lesquelles la clé demandée a été trouvée et la valeur CAS correspondait. | Nombre |
| CasMisses | Nombre de requêtes CAS reçues par le cache dans lesquelles la clé demandée était introuvable. | Nombre |
| CmdFlush | Nombre de commandes flush reçues par le cache. | Nombre |
| CmdGet | Nombre de commandes get reçues par le cache. | Nombre |
| CmdSet | Nombre de commandes set reçues par le cache. | Nombre |
| CurrConnections | Nombre de connexions connectées au cache à un instant donné. ElastiCache utilise 2 à 3 connexions pour surveiller le cluster. En plus de ce qui précède, Memcached crée un nombre de connexions internes égal à deux fois celui des threads utilisés pour ce type de nœud. Le nombre de threads pour les différents types de nœuds figure dans le paramètre `Nodetype Specific Parameters` du groupe de paramètres applicable. Le nombre total de connexions est la somme des connexions client, des connexions à superviser et des connexions internes mentionnées ci-dessus. | Nombre |
| CurrItems | Nombre d’éléments actuellement stockés dans le cache. | Nombre |
| DecrHits | Nombre de requêtes decrement reçues par le cache dans lesquelles la clé demandée a été trouvée. | Nombre |
| DecrMisses | Nombre de requêtes decrement reçues par le cache dans lesquelles la clé demandée était introuvable. | Nombre |
| DeleteHits | Nombre de requêtes delete reçues par le cache dans lesquelles la clé demandée a été trouvée. | Nombre |
| DeleteMisses | Nombre de requêtes delete reçues par le cache dans lesquelles la clé demandée était introuvable. | Nombre |
| Evictions | Nombre d'éléments non arrivés à expiration que le cache a expulsés pour libérer de l'espace pour les nouvelles écritures. | Nombre |
| GetHits | Nombre de requêtes get reçues par le cache dans lesquelles la clé demandée a été trouvée. | Nombre |
| GetMisses | Nombre de requêtes get reçues par le cache dans lesquelles la clé demandée était introuvable. | Nombre |
| IncrHits | Nombre de requêtes increment reçues par le cache dans lesquelles la clé demandée a été trouvée. | Nombre |
| IncrMisses | Nombre de requêtes increment reçues par le cache dans lesquelles la clé demandée était introuvable. | Nombre |
| Reclaimed | Nombre d'éléments arrivés à expiration que le cache a expulsés pour libérer de l'espace pour les nouvelles écritures. | Nombre |
Pour Memcached 1.4.14, les métriques supplémentaires suivantes sont fournies.
| Métrique | Description | Unit |
| --- | --- | --- |
| BytesUsedForHash | Nombre d'octets actuellement utilisés par les tables de hachage. | Octets |
| CmdConfigGet | Nombre cumulé de demandes config get. | Nombre |
| CmdConfigSet | Nombre cumulé de demandes config set. | Nombre |
| CmdTouch | Nombre cumulé de demandes touch. | Nombre |
| CurrConfig | Nombre actuel de configurations stockées. | Nombre |
| EvictedUnfetched | Nombre d’éléments valides expulsés du cache récemment utilisé qui n'ont jamais été touchés après leur définition. | Nombre |
| ExpiredUnfetched | Nombre d’éléments arrivés à expiration récupérés du cache récemment utilisé qui n'ont jamais été touchés après leur définition. | Nombre |
| SlabsMoved | Nombre total de pages de la section qui ont été déplacées. | Nombre |
| TouchHits | Nombre de clés qui ont été touchées et auxquelles une nouvelle date d'expiration a été affectée. | Nombre |
| TouchMisses | Nombre d’éléments qui ont été touchés, mais sont introuvables. | Nombre |
L'espace de ElastiCache noms AWS/inclut les métriques calculées suivantes au niveau du cache.
| Métrique | Description | Unit |
| --- | --- | --- |
| NewConnections | Nombre de nouvelles connexions reçues par le cache. Celui-ci est dérivé de la statistique Memcached total\$1connections en enregistrant la modification de total\$1connections sur une période de temps. Ce sera toujours au moins 1, en raison d'une connexion réservée à un ElastiCache. | Nombre |
| NewItems | Nombre de nouveaux éléments stockés par le cache. Celui-ci est dérivé de la statistique Memcached total\$1items en enregistrant la modification de total\$1items sur une période de temps. | Nombre |
| UnusedMemory | Quantité de mémoire non utilisée par les données. Celle-ci est dérivée des statistiques Memcached limit\$1maxbytes et bytes en soustrayant bytes de limit\$1maxbytes. Étant donné que la surcharge de Memcached utilise de la mémoire en plus de celle utilisée par les données, elle ne UnusedMemory doit pas être considérée comme la quantité de mémoire disponible pour des données supplémentaires. Vous pouvez être confronté à des expulsions, même si vous disposez encore de mémoire inutilisée. Pour de plus amples informations, veuillez consulter [Memcached item memory usage](https://web.archive.org/web/20190422040715/https://www.deplication.net/2016/02/memcached-item-memory-usage/). | Octets |
# 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).
# Choix des périodes et des statistiques de métriques
Bien que CloudWatch vous puissiez choisir n'importe quelle statistique et période pour chaque métrique, toutes les combinaisons ne seront pas utiles. Par exemple, les statistiques moyenne, minimale et maximale pour CPUUtilization sont utiles, mais pas la statistique Sum.
Tous les ElastiCache exemples sont publiés pendant 60 secondes pour chaque nœud de cache individuel. Pour toute période de 60 secondes, une métrique de nœud de cache ne contiendra qu'un seul échantillon.
Pour plus d'informations sur la façon de récupérer des métriques pour vos nœuds de cache, consultez [Surveillance des métriques des CloudWatch clusters et des nœuds](CloudWatchMetrics.md).
# Surveillance des métriques des CloudWatch clusters et des nœuds
ElastiCache et CloudWatch sont intégrés afin que vous puissiez recueillir une variété de mesures. Vous pouvez surveiller ces indicateurs à l'aide de CloudWatch.
**Note**
Les exemples suivants nécessitent les outils de ligne de CloudWatch commande. Pour plus d'informations sur CloudWatch les outils de développement et pour les télécharger, consultez la [page CloudWatch du produit](https://aws.amazon.com/cloudwatch).
Les procédures suivantes vous montrent comment collecter des statistiques CloudWatch d'espace de stockage pour un cluster au cours de la dernière heure.
**Note**
Les valeurs `StartTime` et `EndTime` fournies dans les exemples ci-dessous sont communiquées à des fins d'illustration. Vous devez les remplacer par les valeurs adaptées à nœuds de cache.
Pour plus d'informations sur ElastiCache les limites, consultez la section [Limites de AWS service](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_elasticache) pour ElastiCache.
## Surveillance des métriques des CloudWatch clusters et des nœuds (console)
**Pour collecter les statistiques d'utilisation de l'UC d'un cluster de cache**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Sélectionnez les nœuds de cache dont vous voulez afficher les métriques.
**Note**
L'affichage des métriques sur la console est désactivé si vous sélectionnez plus de 20 nœuds.
1. Sur la page **Clusters de cache** de la console de AWS gestion, cliquez sur le nom d'un ou de plusieurs clusters.
La page détaillée du cluster apparaît.
1. Cliquez sur l'onglet **Nodes** en haut de la fenêtre.
1. Sur l'onglet **Nodes** de la fenêtre des détails, sélectionnez les nœuds de cache dont vous souhaitez afficher les métriques.
La liste des CloudWatch métriques disponibles apparaît en bas de la fenêtre de console.
1. Cliquez sur la métrique **CPU Utilization**.
La CloudWatch console s'ouvre et affiche les statistiques que vous avez sélectionnées. Vous pouvez utiliser les zones de liste déroulantes **Statistic** et **Period** et l'onglet **Time Range** pour modifier les métriques affichées.
## Surveillance des métriques des CloudWatch clusters et des nœuds à l'aide de la CloudWatch CLI
**Pour collecter les statistiques d'utilisation de l'UC d'un cluster de cache**
+ Pour Linux, macOS ou Unix :
```
aws cloudwatch get-metric-statistics \
--namespace AWS/ElastiCache \
--metric-name CPUUtilization \
--dimensions='[{"Name":"CacheClusterId","Value":"test"},{"Name":"CacheNodeId","Value":"0001"}]' \
--statistics=Average \
--start-time 2018-07-05T00:00:00 \
--end-time 2018-07-06T00:00:00 \
--period=3600
```
Pour Windows :
```
aws cloudwatch get-metric-statistics ^
--namespace AWS/ElastiCache ^
--metric-name CPUUtilization ^
--dimensions='[{"Name":"CacheClusterId","Value":"test"},{"Name":"CacheNodeId","Value":"0001"}]' ^
--statistics=Average ^
--start-time 2018-07-05T00:00:00 ^
--end-time 2018-07-06T00:00:00 ^
--period=3600
```
## Surveillance des métriques des CloudWatch clusters et des nœuds à l'aide de l' CloudWatch API
**Pour collecter les statistiques d'utilisation de l'UC d'un cluster de cache**
+ Appelez l' CloudWatch API `GetMetricStatistics` avec les paramètres suivants (notez que les heures de début et de fin ne sont indiquées qu'à titre d'exemple ; vous devrez les remplacer par vos propres heures de début et de fin appropriées) :
+ `Statistics.member.1``=Average`
+ `Namespace``=AWS/ElastiCache`
+ `StartTime``=2013-07-05T00:00:00`
+ `EndTime``=2013-07-06T00:00:00`
+ `Period``=60`
+ `MeasureName``=CPUUtilization`
+ `Dimensions``=CacheClusterId=mycachecluster,CacheNodeId=0002`
**Example**
```
1. http://monitoring.amazonaws.com/
2. ?Action=GetMetricStatistics
3. &SignatureVersion=4
4. &Version=2014-12-01
5. &StartTime=2018-07-05T00:00:00
6. &EndTime=2018-07-06T23:59:00
7. &Period=3600
8. &Statistics.member.1=Average
9. &Dimensions.member.1="CacheClusterId=mycachecluster"
10. &Dimensions.member.2="CacheNodeId=0002"
11. &Namespace=&AWS;/ElastiCache
12. &MeasureName=CPUUtilization
13. &Timestamp=2018-07-07T17%3A48%3A21.746Z
14. &AWS;AccessKeyId=<&AWS; Access Key ID>
15. &Signature=
```