CloudWatch statistiques pour votre Classic Load Balancer

Elastic Load Balancing publie des points de données sur Amazon CloudWatch pour vos équilibreurs de charge et vos instances principales. CloudWatch vous permet de récupérer des statistiques sur ces points de données sous la forme d'un ensemble ordonné de séries chronologiques, appelées métriques. Considérez une métrique comme une variable à surveiller, et les points de données comme les valeurs de cette variable au fil du temps. Par exemple, vous pouvez surveiller le nombre total d'instances EC2 saines pour un équilibreur de charge sur une période spécifiée. Un horodatage et une unité de mesure facultative sont associés à chaque point de données.

Vous pouvez utiliser les métriques pour vérifier que le système fonctionne comme prévu. Par exemple, vous pouvez créer une CloudWatch alarme pour surveiller une métrique spécifiée et lancer une action (telle que l'envoi d'une notification à une adresse e-mail) si la métrique dépasse ce que vous considérez comme une plage acceptable.

Elastic Load Balancing communique les métriques CloudWatch uniquement lorsque les demandes transitent par l'équilibreur de charge. Si des demandes passent par l'équilibreur de charge, Elastic Load Balancing mesure et envoie ses métriques au cours d'intervalles de 60 secondes. Si aucune demande ne passe par l'équilibreur de charge ou s'il n'existe pas de données pour une métrique, cette dernière n'est pas présentée.

Pour plus d'informations sur Amazon CloudWatch, consultez le guide de CloudWatch l'utilisateur Amazon.

Métriques Classic Load Balancer

L'espace de noms AWS/ELB inclut les métriques suivantes.

Métrique	Description
BackendConnectionErrors	Nombre de connexions qui n'ont pas pu être établies entre l'équilibreur de charge et les instances enregistrées. Étant donné que l'équilibreur de charge essaie de relancer la connexion lorsque des erreurs se produisent, ce nombre peut dépasser le taux de demande. Notez que ce nombre inclut également les erreurs de connexion associées à des vérifications de l'état. Critères de notification : il existe une valeur différente de zéro Statistics : la statistique la plus utile est Sum. Notez que Average, Minimum et Maximum sont présentés par nœud d'équilibreur de charge et ne sont généralement pas utiles. Toutefois, la différence entre le minimum et le maximum (ou pic par rapport à la moyenne ou moyenne par rapport au seuil) peut être utile pour déterminer si un nœud de l'équilibreur de charge représente un cas particulier. Exemple : supposons que votre équilibreur de charge comporte 2 instances dans us-west-2a et 2 instances dans us-west-2b, et que les tentatives de connexion à une instance dans us-west-2a génèrent des erreurs de connexion back-end. La somme pour us-west-2a inclut ces erreurs de connexion, contrairement à la somme pour us-west-2b. Par conséquent, la somme pour l'équilibreur de charge est égale à celle pour us-west-2a.
DesyncMitigationMode_NonCompliant_Request_Count	[Écouteur HTTP] Nombre de demandes qui ne sont pas conformes à la RFC 7230. Critères de notification : il existe une valeur différente de zéro Statistics : la statistique la plus utile est Sum.
HealthyHostCount	Nombre d'instances saines enregistrées auprès de votre équilibreur de charge. Une instance récemment enregistrée est considérée comme saine si elle a réussi la première vérification de l'état. Si l’équilibrage de charge entre zones est activé, le nombre d'instances saines pour la dimension LoadBalancerName est calculé sur toutes les zones de disponibilité. Sinon, il est calculé par zone de disponibilité. Critères de notification : il s'agit d'instances enregistrées Statistiques : les statistiques les plus utiles sont Average et Maximum. Ces statistiques sont déterminées par les nœuds de l'équilibreur de charge. Notez que certains nœuds de l'équilibreur de charge peuvent déterminer qu'une instance est défectueuse pendant une brève période, tandis que d'autres nœuds la considèrent comme saine. Exemple : supposons que votre équilibreur de charge comporte 2 instances dans us-west-2a et 2 instances dans us-west-2b ; us-west-2a contient une instance défectueuse, tandis que us-west-2b n'en contient pas. Avec la dimension AvailabilityZone, la moyenne est d'une instance saine et une instance défectueuse dans us-west-2, et de 2 instances saines et 0 instance défectueuse dans us-west-2 b.
HTTPCode_Backend_2XX, HTTPCode_Backend_3XX, HTTPCode_Backend_4XX, HTTPCode_Backend_5XX	[Écouteur HTTP] Nombre de codes de réponse HTTP générés par les instances enregistrées. Ce nombre n'inclut pas les codes de réponse générés par l'équilibreur de charge. Critères de notification : il existe une valeur différente de zéro Statistics : la statistique la plus utile est Sum. Notez que Minimum, Maximum et Average ont chacun la valeur 1. Exemple : supposons que votre équilibreur de charge comporte 2 instances dans us-west-2a et 2 instances dans us-west-2b, et que les demandes envoyées à une instance dans us-west-2a génèrent des réponses HTTP 500. La somme pour us-west-2a inclut ces réponses d'erreur, contrairement à la somme pour us-west-2b. Par conséquent, la somme pour l'équilibreur de charge est égale à celle pour us-west-2a.
HTTPCode_ELB_4XX	[Écouteur HTTP] Nombre de codes d'erreur client HTTP 4XX générés par l'équilibreur de charge. Des erreurs client sont générées lorsqu'une demande est mal formulée ou incomplète. Critères de notification : il existe une valeur différente de zéro Statistics : la statistique la plus utile est Sum. Notez que Minimum, Maximum et Average ont chacun la valeur 1. Exemple : supposons que votre équilibreur de charge ait activé us-west-2a et us-west-2b, et que les demandes du client incluent une URL de demande incorrecte. Les erreurs client risquent donc d'augmenter dans toutes les zones de disponibilité. La somme pour l'équilibreur de charge est la somme des valeurs pour les zones de disponibilité.
HTTPCode_ELB_5XX	[Écouteur HTTP] Nombre de codes d'erreur serveur HTTP 5XX générés par l'équilibreur de charge. Ce nombre n'inclut pas les codes de réponse générés par les instances enregistrées. Cette métrique est présentée si aucune instance saine n'est enregistrée sur l'équilibreur de charge, ou si le taux de demande dépasse la capacité des instances (débordement) ou de l'équilibreur de charge. Critères de notification : il existe une valeur différente de zéro Statistics : la statistique la plus utile est Sum. Notez que Minimum, Maximum et Average ont chacun la valeur 1. Exemple : supposons que votre équilibreur de charge ait activé us-west-2a et us-west-2b, et que les instances dans us-west-2a connaissent une latence élevée et mettent du temps à répondre aux demandes. Par conséquent, la file d'attente des hausses pour les nœuds de l'équilibreur de charge dans us-west-2a se remplit et les clients reçoivent une erreur 503. Si us-west-2b continue à répondre normalement, la somme pour l'équilibreur de charge est égale à celle pour us-west-2a.
Latency	[Écouteur HTTP] Durée totale écoulée, en secondes, du moment où l'équilibreur de charge a envoyé la demande à une instance enregistrée au moment où l'instance a commencé à envoyer les en-têtes de réponse. [Écouteur TCP] Délai total, en secondes, avant que l'équilibreur de charge parvienne à établir une connexion à une instance enregistrée. Critères de notification : il existe une valeur différente de zéro Statistics : la statistique la plus utile est Average. Utilisez Maximum pour déterminer si des demandes prennent beaucoup plus de temps que la moyenne. Notez que Minimum n'est généralement pas utile. Exemple : supposons que l'équilibreur de charge comporte 2 instances dans us-west-2a et 2 instances dans us-west-2b, et que les demandes envoyées à une instance dans us-west-2a aient une latence plus élevée. La moyenne pour us-west-2a est supérieure à la moyenne pour us-west-2b.
RequestCount	Nombre de demandes terminées ou de connexions effectuées au cours de l'intervalle spécifié (1 ou 5 minutes). [Écouteur HTTP] Nombre de demandes reçues et acheminées, y compris les réponses d'erreur HTTP provenant des instances enregistrées. [Écouteur TCP] Nombre de connexions effectuées aux instances enregistrées. Critères de notification : il existe une valeur différente de zéro Statistics : la statistique la plus utile est Sum. Notez que Minimum, Maximum et Average retournent tous la valeur 1. Exemple : supposons que votre équilibreur de charge comporte 2 instances dans us-west-2a et 2 instances dans us-west-2b, et que 100 demandes soient envoyées à l’équilibreur de charge. 60 demandes sont envoyées à us-west-2a, chaque instance recevant 30 demandes, et 40 demandes sont envoyées à us-west-2b, chaque instance recevant 20 demandes. Avec la dimension AvailabilityZone, us-west-2a contient une somme de 60 demandes et us-west-2b, une somme de 40 demandes. Avec la dimension LoadBalancerName, la somme est de 100 demandes.
SpilloverCount	Nombre total de demandes qui ont été rejetées en raison de la saturation de la file d'attente des hausses. [Écouteur HTTP] L'équilibreur de charge renvoie un code d'erreur HTTP 503. [Écouteur TCP] L'équilibreur de charge ferme la connexion. Critères de notification : il existe une valeur différente de zéro Statistics : la statistique la plus utile est Sum. Notez que Average, Minimum et Maximum sont présentés par nœud d'équilibreur de charge et ne sont généralement pas utiles. Exemple : supposons que votre équilibreur de charge ait activé us-west-2a et us-west-2b, et que les instances dans us-west-2a connaissent une latence élevée et mettent du temps à répondre aux demandes. Par conséquent, la file d'attente des hausses pour le nœud d'équilibreur de charge dans us-west-2a se remplit, ce qui entraîne un débordement. Si us-west-2b continue à répondre normalement, la somme pour l'équilibreur de charge sera la même que celle pour us-west-2a.
SurgeQueueLength	Nombre total de demandes (écouteur HTTP) ou de connexions (écouteur TCP) qui sont en attente de routage vers une instance saine. La taille maximale de la file d'attente est 1 024. Les demandes ou connexions supplémentaires sont rejetées lorsque la file d'attente est saturée. Pour plus d’informations, consultez SpilloverCount. Critères de notification : il existe une valeur différente de zéro. Statistiques : la statistique la plus utile est Maximum, car elle représente le pic des demandes placées en file d'attente. La statistique Average peut être utile, associée à Minimum et Maximum, pour déterminer la plage des demandes placées en file d'attente. Notez que Sum n'est pas utile. Exemple : supposons que votre équilibreur de charge ait activé us-west-2a et us-west-2b, et que les instances dans us-west-2a connaissent une latence élevée et mettent du temps à répondre aux demandes. Par conséquent, la file d'attente des hausses pour les nœuds de l'équilibreur de charge dans us-west-2a se remplit et les clients connaîtront probablement une augmentation des temps de réponse. Si le problème persiste, l'équilibreur de charge présentera certainement des débordements (voir la métrique SpilloverCount). Si us-west-2b continue à répondre normalement, max pour l'équilibreur de charge sera le même que max pour us-west-2a.
UnHealthyHostCount	Nombre d'instances défaillantes enregistrées auprès de votre équilibreur de charge. Une instance est considérée comme défectueuse une fois qu'elle a dépassé le seuil de défectuosité configuré pour les vérifications de l'état. Une instance défectueuse est considérée comme à nouveau saine lorsqu'elle atteint le seuil de bonne santé configuré pour les vérifications de l'état. Critères de notification : il s'agit d'instances enregistrées Statistiques : les statistiques les plus utiles sont Average et Minimum. Ces statistiques sont déterminées par les nœuds de l'équilibreur de charge. Notez que certains nœuds de l'équilibreur de charge peuvent déterminer qu'une instance est défectueuse pendant une brève période, tandis que d'autres nœuds la considèrent comme saine. Exemple : voir HealthyHostCount.

Les métriques suivantes vous permettent d'estimer vos coûts si vous migrez un Classic Load Balancer vers un Application Load Balancer. Ces mesures sont destinées à un usage informatif uniquement, et non à être utilisées avec des CloudWatch alarmes. Notez que si votre Classic Load Balancer possède plusieurs Écouteurs, ces métriques sont agrégées parmi les Écouteurs.

Ces estimations sont basées sur un équilibreur de charge équipé d'une règle par défaut et d'un certificat d'une taille de 2K. Si vous utilisez un certificat d'une taille de 4K ou supérieure, nous vous recommandons d'estimer vos coûts de la manière suivante : créez un Application Load Balancer basé sur votre Classic Load Balancer à l'aide de l'outil de migration et surveillez la métrique ConsumedLCUs pour l'Application Load Balancer. Pour de plus amples informations, consultez Migrer d'un Classic Load Balancer vers un Application Load Balancer dans le Guide de l'utilisateur Elastic Load Balancing.

Métrique	Description
EstimatedALBActiveConnectionCount	Estimation du nombre de connexions TCP simultanées et actives entre les clients et l'équilibreur de charge et entre l'équilibreur de charge et les cibles.
EstimatedALBConsumedLCUs	Estimation du nombre d'unités de capacité d'équilibreur de charge (LCU) utilisées par un Application Load Balancer. Vous ne payez que pour les unités LCU que vous utilisez par heure. Pour plus d'informations, consultez Tarification Elastic Load Balancing.
EstimatedALBNewConnectionCount	Estimation du nombre de nouvelles connexions TCP établies entre les clients et l'équilibreur de charge et entre l'équilibreur de charge et les cibles.
EstimatedProcessedBytes	Estimation du nombre d'octets traités par un Application Load Balancer.

Dimensions de métriques pour les Classic Load Balancers

Pour filtrer les métriques pour votre Classic Load Balancer, utilisez les dimensions ci-dessous.

Dimension	Description
AvailabilityZone	Filtre les données des métriques par la zone de disponibilité spécifiée.
LoadBalancerName	Filtre les données des métriques par l'équilibreur de charge spécifié.

Statistiques pour les métriques Classic Load Balancer

CloudWatch fournit des statistiques basées sur les points de données métriques publiés par Elastic Load Balancing. Les statistiques sont des regroupements de données de métrique sur une période donnée. Lorsque vous demandez des statistiques, le flux de données renvoyé est identifié par le nom et la dimension de la métrique. Une dimension est une paire nom/valeur qui identifie une métrique de manière unique. Par exemple, vous pouvez demander des statistiques pour toutes les instances EC2 saines derrière un équilibreur de charge, lancées dans une zone de disponibilité spécifique.

Le statistiques Minimum et Maximum reflètent les valeurs minimum et maximum signalées par les différents nœuds d'équilibreur de charge. Par exemple, supposons qu'il existe 2 nœuds d'équilibreur de charge. Un nœud a HealthyHostCount avec 2 pour Minimum, 10 pour Maximum et 6 pour Average, tandis que l'autre nœud a HealthyHostCount avec 1 pour Minimum, 5 pour Maximum et 3 pour Average. Par conséquent, l'équilibreur de charge a 1 pour Minimum, 10 pour Maximum et environ 4 pour Average.

La statistique Sum est la valeur regroupée pour tous les nœuds d'équilibreur de charge. Étant donné que les métriques incluent plusieurs rapports par période, Sum ne s'applique qu'aux métriques qui sont regroupées pour tous les nœuds d'équilibreur de charge, comme RequestCount, HTTPCode_ELB_XXX, HTTPCode_Backend_XXX, BackendConnectionErrors et SpilloverCount.

La statistique SampleCount est le nombre d'échantillons mesurés. Étant donné que les métriques sont collectées selon des intervalles de prélèvement et des événements, cette statistique n'est généralement pas utile. Par exemple, avec HealthyHostCount, SampleCount est basé sur le nombre d'échantillons que chaque nœud d'équilibreur de charge signale, et non sur le nombre d'hôtes sains.

Un centile indique la position relative d'une valeur dans un ensemble de données. Vous pouvez spécifier un centile en utilisant jusqu’à deux décimales (par exemple, p95.45). Par exemple, le 95e centile signifie que 95 % des données sont inférieures à cette valeur et que 5 % des données lui sont supérieures. Les centiles sont souvent utilisés pour isoler les anomalies. Par exemple, supposons qu'une application sert la majorité des demandes à partir d'un cache en 1 à 2 ms, mais en 100 à 200 ms si le cache est vide. Le valeur maximale reflète le cas plus lent, environ 200 ms. La moyenne n'indique pas la distribution des données. Les percentiles offrent une vue plus descriptive de performances de l'application. En utilisant le 99e percentile comme déclencheur ou CloudWatch alarme Auto Scaling, vous pouvez faire en sorte que le traitement de 1 % des demandes ne prenne pas plus de 2 ms.

Afficher CloudWatch les statistiques de votre équilibreur de charge

Vous pouvez consulter les CloudWatch métriques de vos équilibreurs de charge à l'aide de la console Amazon EC2. Ces métriques s’affichent sous forme de graphiques de surveillance. Les graphiques de surveillance affichent des points de données si l'équilibreur de charge est actif et reçoit des demandes.

Vous pouvez également consulter les métriques de votre équilibreur de charge à l'aide de la CloudWatch console.

Pour afficher des métriques à l'aide de la console

1. Ouvrez la console Amazon EC2 à l'adresse https://console.aws.amazon.com/ec2/.

2. Dans le panneau de navigation, sous Load Balancing (Équilibrage de charge), choisissez Load Balancers (Équilibreurs de charge).

3. Choisissez le nom de l'équilibreur de charge afin d'ouvrir sa page détaillée.

4. Sélectionnez l'onglet Monitoring (Surveillance).

5. Pour obtenir une vue plus grande d'une seule métrique, passez le curseur sur son graphique, puis choisissez l'icône Maximize. Les mesures suivantes sont disponibles :

   • Hôtes sains — HealthyHostCount

   • Hôtes non sains — UnHealthyHostCount

   • Latence moyenne — Latency

   • Requêtes — RequestCount

   • Erreurs de connexion backend — BackendConnectionErrors

   • Longueur de file d'attente des hausses — SurgeQueueLength

   • Décompte de débordement — SpilloverCount

   • HTTP 2XXs — HTTPCode_Backend_2XX

   • HTTP 3XXs — HTTPCode_Backend_3XX

   • HTTP 4XXs — HTTPCode_Backend_4XX

   • HTTP 5XXs — HTTPCode_Backend_5XX

   • ELB HTTP 4XXs — HTTPCode_ELB_4XX

   • ELB HTTP 5XXs — HTTPCode_ELB_5XX

   • Nombre estimé d'octets traités — EstimatedProcessedBytes

   • Estimation des LCU consommées par ALB — EstimatedALBConsumedLCUs

   • Nombre estimé de connexions actives ALB — EstimatedALBActiveConnectionCount

   • Nombre estimé de nouvelles connexions ALB — EstimatedALBNewConnectionCount

Pour afficher les métriques à l'aide de la CloudWatch console

1. Ouvrez la CloudWatch console à l'adresse https://console.aws.amazon.com/cloudwatch/.

2. Dans le panneau de navigation, sélectionnez ‎Métriques.

3. Sélectionnez l'espace de noms ELB.

4. Effectuez l’une des actions suivantes :

   • Sélectionnez une dimension de métrique pour afficher les métriques par équilibreur de charge, par zone de disponibilité ou pour l'ensemble des équilibreurs de charge.

   • Pour afficher une métrique pour toutes les dimensions, saisissez son nom dans le champ de recherche.

   • Pour afficher les métriques pour un seul équilibreur de charge, saisissez son nom dans le champ de recherche.

   • Pour afficher les métriques pour une seule zone de disponibilité, saisissez son nom dans le champ de recherche.