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.

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 nœuds vCPUs ou moins, utilisez la CPUUtilization métrique pour surveiller votre charge de travail.

D'une manière générale, nous vous suggérons de fixer votre seuil à 90 % de votre disponibilitéCPU. 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 Host-LevelCPUUtilization, les OSS utilisateurs de Valkey et Redis 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 Métriques pour Valkey et Redis OSS.

Pour les types de nœuds plus importants avec 4 nœuds vCPUs ou plus, vous pouvez utiliser la EngineCPUUtilization métrique, qui indique le pourcentage d'utilisation sur le cœur du OSS moteur Valkey ou Redis. 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.

E ngineCPUUtilization

Pour les types de nœuds plus importants avec 4 nœuds vCPUs ou plus, vous pouvez utiliser la EngineCPUUtilization métrique, qui indique le pourcentage d'utilisation sur le cœur du OSS moteur Redis. Pour savoir si cette métrique est disponible sur vos nœuds et pour plus d'informations, consultez Métriques pour Valkey et Redis OSS.

Pour plus d'informations, consultez la CPUssection Surveillance des meilleures pratiques avec Amazon ElastiCache (RedisOSS) à l'aide d'Amazon CloudWatch.

SwapUsage (Valkey et RedisOSS)

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 :

• S'assurer que vous disposez de suffisamment de mémoire pour créer un instantané Valkey ou Redis OSS

• Gestion de la mémoire réservée pour Valkey et Redis OSS

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 de la section Surveillance des meilleures pratiques avec Amazon ElastiCache (RedisOSS) à l'aide d'Amazon CloudWatch.

Mémoire (Valkey et RedisOSS)

La mémoire est au cœur de Valkey et RedisOSS. 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 INFOcommande.

Pour plus d'informations, consultez la section Mémoire de la section Surveillance des meilleures pratiques avec Amazon ElastiCache (RedisOSS) à 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 le suivi des meilleures pratiques avec Amazon ElastiCache (RedisOSS) à l'aide d'Amazon CloudWatch.

Latence

Vous pouvez mesurer la latence d'une commande à l'aide d'un ensemble de CloudWatch mesures fournissant des latences agrégées par structure de données. Ces mesures de latence sont calculées à l'aide des commandstats statistiques de la commande Valkey INFO.

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 de la section Surveillance des meilleures pratiques avec Amazon ElastiCache (RedisOSS) à l'aide d'Amazon CloudWatch.

Gestion du trafic (Valkey et RedisOSS)

ElastiCache (RedisOSS) 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.