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.
Métriques pour la surveillance
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.
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épasserez ce seuil, et que les demandes de lecture constituent votre principale charge de travail, ajustez votre cluster de cache en ajoutant des réplicas en 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ôteCPUUtilization, les utilisateurs de Valkey et Redis OSS peuvent utiliser la métriqueEngineCPUUtilization, 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.
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.
Memcached
Puisque Memcached est multi-thread, cette métrique peut atteindre jusqu'à 90 %. Si vous dépassez ce seuil, augmentez votre cluster de cache 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.
Pour plus d'informations, consultez la CPUssection consacrée à la surveillance des meilleures pratiques avec Amazon ElastiCache pour Redis OSS à l'aide d'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.
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 :
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 CurrConnectionschiffres 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
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
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
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
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
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
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.
Pour plus d'informations, consultez la section Latence de la section Surveillance des meilleures pratiques avec Amazon à ElastiCache l'aide d'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
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.
