CloudWatch Metriken für Ihren Classic Load Balancer - Elastic Load Balancing
Metriken zu Classic Load BalancerMetrik-Dimensionen für Classic Load BalancerStatistiken für Classic-Load-Balancer-Metriken CloudWatch Metriken für Ihren Load Balancer anzeigen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

CloudWatch Metriken für Ihren Classic Load Balancer

Elastic Load Balancing veröffentlicht Datenpunkte CloudWatch für Ihre Load Balancer und Ihre Back-End-Instances auf Amazon. CloudWatch ermöglicht es Ihnen, Statistiken über diese Datenpunkte in Form eines geordneten Satzes von Zeitreihendaten, sogenannten Metriken, abzurufen. Sie können sich eine Metrik als eine zu überwachende Variable und die Datenpunkte als die Werte dieser Variable im Laufe der Zeit vorstellen. Sie können beispielsweise die Gesamtzahl der fehlerfreien EC2 Instances für einen Load Balancer über einen bestimmten Zeitraum überwachen. Jeder Datenpunkt verfügt über einen zugewiesenen Zeitstempel und eine optionale Maßeinheit.

Mit den Metriken können Sie überprüfen, ob Ihr System die erwartete Leistung zeigt. Sie können beispielsweise einen CloudWatch Alarm erstellen, um eine bestimmte Metrik zu überwachen und eine Aktion einzuleiten (z. B. das Senden einer Benachrichtigung an eine E-Mail-Adresse), wenn die Metrik außerhalb des für Sie akzeptablen Bereichs liegt.

Elastic Load Balancing meldet Metriken CloudWatch nur dann, wenn Anfragen durch den Load Balancer fließen. Wenn Anforderungen über den Load Balancer erfolgen, misst Elastic Load Balancing diese und sendet seine Metriken in 60-Sekunden-Intervallen. Wenn es keine Anfragen über den Load Balancer gibt oder keine Daten für eine Metrik vorliegen, wird die Metrik nicht gemeldet.

Weitere Informationen zu Amazon CloudWatch finden Sie im CloudWatch Amazon-Benutzerhandbuch.

Metriken zu Classic Load Balancer

Der AWS/ELB-Namespace enthält die folgenden Metriken.

Metrik Beschreibung
BackendConnectionErrors

Die Zahl der Verbindungen, die zwischen dem Load Balancer und den registrierten Instances nicht erfolgreich hergestellt wurden. Da der Load Balancer den Verbindungsversuch bei Fehlern wiederholt, kann diese Zahl die Anforderungsrate übersteigen. Diese Zahl umfasst außerdem Verbindungsfehler im Zusammenhang mit Zustandsprüfungen.

Berichtkriterien: Ein Wert ungleich Null

Statistiken: Die nützlichste Statistik ist Sum. Hinweis: Average, Minimum und Maximum werden pro Load Balancer-Knoten gemeldet und sind nicht immer nützlich. Der Unterschied zwischen dem Mindest- und dem Höchstwert (oder zwischen dem Spitzen- und dem Durchschnittswert bzw. zwischen dem Durchschnitts- und dem Durchsatzwert) kann nützlich sein, um zu bestimmen, ob ein Load Balancer-Knoten ein Ausreißer ist.

Beispiel: Angenommen, Ihr Load Balancer verfügt über zwei Instances in us-west-2a und zwei Instances in us-west-2b und Verbindungsversuche mit einer Instance in us-west-2a führen zu Backend-Verbindungsfehlern. Die Summe für us-west-2a umfasst diese Verbindungsfehler, während die Summe für us-west-2b diese nicht enthält. Daher entspricht die Summe für den Load Balancer der Summe für us-west-2a.
DesyncMitigationMode_NonCompliant_Request_Count

[HTTP-Listener] Die Anzahl der Anfragen, die nicht RFC 7230 entsprechen.

Berichtkriterien: Ein Wert ungleich Null

Statistiken: Die nützlichste Statistik ist Sum.
HealthyHostCount

Die Zahl der fehlerfreien Instances, die mit Ihrem Load Balancer registriert sind. Eine neu registrierte Instance wird als fehlerfrei betrachtet, nachdem sie die erste Zustandsprüfung bestanden hat. Wenn zonenübergreifendes Load Balancing aktiviert ist, wird die Zahl der fehlerfreien Instances für die Dimension LoadBalancerName für alle Availability Zones berechnet. Andernfalls wird sie je Availability Zone berechnet.

Berichtkriterien: Registrierte Instances

Statistiken: Die nützlichsten Statistiken sind Average und Maximum. Diese Statistiken werden durch die Load Balancer-Knoten bestimmt. Hinweis: Einige Load Balancer-Knoten können feststellen, dass eine Instance für einen kurzen Zeitraum nicht fehlerfrei ist, während andere Knoten ihre Fehlerfreiheit bestätigen.

Beispiel: Angenommen, Ihr Load Balancer verfügt über zwei Instances in us-west-2a und zwei Instances in us-west-2b; us-west-2a hat eine nicht fehlerfreie Instance und in us-west-2b sind alle Instances fehlerfrei. Mit der Dimension AvailabilityZone ergibt sich ein Durchschnitt von einer fehlerfreien und einer nicht fehlerfreien Instance in us-west-2a sowie ein Durchschnitt von zwei fehlerfreien und null nicht fehlerfreien Instances in us-west-2b.

HTTPCode_Backend_2XX, HTTPCode_Backend_3XX, HTTPCode_Backend_4XX, HTTPCode_Backend_5XX

[HTTP-Listener] Die Zahl der HTTP-Antwortcodes, die von registrierten Instances generiert wurden. Diese Zahl umfasst keine Antwortcodes, die vom Load Balancer generiert wurden.

Berichtkriterien: Ein Wert ungleich Null

Statistiken: Die nützlichste Statistik ist Sum. Hinweis: Minimum, Maximum und Average sind alle 1.

Beispiel: Angenommen, Ihr Load Balancer verfügt über zwei Instances in us-west-2a und zwei Instances in us-west-2b und Anfragen, die an eine Instance in us-west-2a gesendet wurden, führen zu HTTP-500-Antworten. Die Summe für us-west-2a umfasst diese Fehlerantworten, während die Summe für us-west-2b diese nicht enthält. Daher entspricht die Summe für den Load Balancer der Summe für us-west-2a.
HTTPCode_ELB_4XX

[HTTP-Listener] Die Anzahl der vom Load Balancer generierten HTTP 4XX-Client-Fehlercodes Client-Fehler werden generiert, wenn eine Anforderung das falsche Format hat oder unvollständig ist.

Berichtkriterien: Ein Wert ungleich Null

Statistiken: Die nützlichste Statistik ist Sum. Hinweis: Minimum, Maximum und Average sind alle 1.

Beispiel: Angenommen, für Ihren Load Balancer sind us-west-2a und us-west-2b aktiviert und Client-Anforderungen umfassen eine falsch formatierte Anforderungs-URL. Dies führt zu einem Client-Fehleranstieg in allen Availability Zones. Die Summe für den Load Balancer ist die Summe der Werte für die Availability Zones.
HTTPCode_ELB_5XX

[HTTP-Listener] Die Anzahl der vom Load Balancer generierten HTTP 5XX-Server-Fehlercodes Diese Zahl umfasst keine Antwortcodes, die von den registrierten Instances generiert wurden. Die Metrik wird gemeldet, wenn für den Load Balancer keine fehlerfreien Instances registriert sind oder wenn die Anforderungsrate die Kapazität der Instances (Überlauf) oder des Load Balancers überschreitet.

Berichtkriterien: Ein Wert ungleich Null

Statistiken: Die nützlichste Statistik ist Sum. Hinweis: Minimum, Maximum und Average sind alle 1.

Beispiel: Angenommen, für Ihren Load Balancer sind us-west-2a und us-west-2b aktiviert und für Ihre Instances in us-west-2a besteht eine hohe Latenz, sodass sie nur langsam auf Anforderungen antworten. Das führt dazu, dass sich die Anstiegswarteschlange für die Load Balancer-Knoten in us-west-2a füllt und die Clients den Fehler 503 erhalten. Wenn us-west-2b weiterhin normal antwortet, entspricht die Summe für den Load Balancer der Summe für us-west-2a.
Latency

[HTTP-Listener] Die gesamte abgelaufene Zeit in Sekunden ab dem Zeitpunkt, zu dem der Load Balancer die Anforderung an eine registrierte Instance gesendet hat, bis zu dem Zeitpunkt, an dem die Instance begann, die Antwort-Header zu senden.

[TCP-Listener] Die gesamte abgelaufene Zeit in Sekunden, bis der Load Balancer erfolgreich eine Verbindung zu einer registrierten Instance hergestellt hat.

Berichtkriterien: Ein Wert ungleich Null

Statistiken: Die nützlichste Statistik ist Average. Verwenden Sie Maximum, um zu bestimmen, ob einige Anforderungen wesentlich länger dauern als der Durchschnitt. Hinweis: Minimum ist in der Regel nicht nützlich.

Beispiel: Angenommen, Ihr Load Balancer verfügt über zwei Instances in us-west-2a und zwei Instances in us-west-2b und Anforderungen, die an eine Instance in us-west-2a gesendet wurden, weisen eine höhere Latenz auf. Der Durchschnitt für us-west-2a weist einen höheren Wert auf als der Durchschnitt für us-west-2b.
RequestCount

Die Zahl der abgeschlossenen Anforderungen oder hergestellten Verbindungen während des angegebenen Intervalls (eine oder fünf Minuten).

[HTTP-Listener] Die Zahl der erhaltenen und weitergeleiteten Anforderungen, einschließlich HTTP-Fehlerantworten von den registrierten Instances.

[TCP-Listener] Die Zahl der hergestellten Verbindungen mit den registrierten Instances.

Berichtkriterien: Ein Wert ungleich Null

Statistiken: Die nützlichste Statistik ist Sum. Beachten Sie, dass sowohl Minimum und Maximum als auch Average 1 zurückgeben.

Beispiel: Angenommen, Ihr Load Balancer verfügt über zwei Instances in us-west-2a und zwei Instances in us-west-2b und 100 Anforderungen werden an den Load Balancer gesendet. 60 Anforderungen werden an us-west-2a gesendet, wobei jede Instance 30 Anforderungen erhält, und 40 Anforderungen an us-west-2b, sodass auf jede Instance 20 Anforderungen entfallen. Mit der Dimension AvailabilityZone ergibt sich eine Summe von 60 Anforderungen in us-west-2a und 40 Anforderungen in us-west-2b. Mit der Dimension LoadBalancerName beträgt die Summe 100 Anforderungen.
SpilloverCount

Die Gesamtanzahl der Anforderungen, die abgelehnt wurden, weil die Anstiegswarteschlange voll ist.

[HTTP-Listener] Der Load Balancer gibt einen HTTP 503-Fehlercode zurück.

[TCP-Listener] Der Load Balancer schließt die Verbindung.

Berichtkriterien: Ein Wert ungleich Null

Statistiken: Die nützlichste Statistik ist Sum. Hinweis: Average, Minimum und Maximum werden pro Load Balancer-Knoten gemeldet und sind nicht immer nützlich.

Beispiel: Angenommen, für Ihren Load Balancer sind us-west-2a und us-west-2b aktiviert und für Ihre Instances in us-west-2a besteht eine hohe Latenz, sodass sie nur langsam auf Anforderungen antworten. Das führt dazu, dass sich die Anstiegswarteschlange für den Load Balancer-Knoten in us-west-2a füllt und ein Überlauf auftritt. Wenn us-west-2b weiterhin normal antwortet, entspricht die Summe für den Load Balancer der Summe für us-west-2a.
SurgeQueueLength

Die Gesamtzahl der Anforderungen (HTTP-Listener) oder Verbindungen (TCP-Listener), deren Weiterleitung an eine fehlerfreie Instance aussteht. Die maximale Größe der Warteschlange beträgt 1.024. Zusätzliche Anforderungen oder Verbindungen werden abgewiesen, wenn die Warteschlange voll ist. Weitere Informationen finden Sie unter SpilloverCount.

Berichtkriterien: Ein Wert ungleich Null.

Statistiken: Die nützlichste Statistik ist Maximum, da sie die Spitze der in der Warteschlange befindlichen Anforderungen darstellt. Die Average-Statistik kann in Kombination mit Minimum und Maximum nützlich sein, um den Bereich der in der Warteschlange befindlichen Anforderungen zu bestimmen. Hinweis: Sum ist nicht nützlich.

Beispiel: Angenommen, für Ihren Load Balancer sind us-west-2a und us-west-2b aktiviert und für Ihre Instances in us-west-2a besteht eine hohe Latenz, sodass sie nur langsam auf Anforderungen antworten. Das führt dazu, dass sich die Anstiegswarteschlange für die Load Balancer-Knoten in us-west-2a füllt und sich die Reaktionszeiten der Clients wahrscheinlich verlängern. Wenn diese Situation anhält, treten beim Load Balancer wahrscheinlich Überläufe auf (siehe Metrik SpilloverCount). Wenn us-west-2b weiterhin normal antwortet, entspricht max für den Load Balancer dem Wert max für us-west-2a.
UnHealthyHostCount

Die Zahl der nicht fehlerfreien Instances, die mit Ihrem Load Balancer registriert sind. Eine Instance wird als nicht fehlerfrei betrachtet, sobald sie den für Zustandsprüfungen konfigurierten Unhealthy Threshold (Schwellenwert für anormalen Zustand) überschreitet. Eine nicht fehlerfreie Instance wird wieder als fehlerfrei betrachtet, sobald sie dem für Zustandsprüfungen konfigurierten Healthy Threshold (Schwellenwert für normalen Zustand) entspricht.

Berichtkriterien: Registrierte Instances

Statistiken: Die nützlichsten Statistiken sind Average und Minimum. Diese Statistiken werden durch die Load Balancer-Knoten bestimmt. Hinweis: Einige Load Balancer-Knoten können feststellen, dass eine Instance für einen kurzen Zeitraum nicht fehlerfrei ist, während andere Knoten ihre Fehlerfreiheit bestätigen.

Beispiel: Siehe HealthyHostCount.

Die folgenden Metriken ermöglichen eine Kostenschätzung für die Migration eines Classic Load Balancer auf einen Application Load Balancer. Diese Messwerte sind nur zu Informationszwecken bestimmt, nicht zur Verwendung mit CloudWatch Alarmen. Hinweis: Wenn Ihr Classic Load Balancer über mehrere Listener verfügt, werden diese Metriken über alle Listener hinweg aggregiert.

Diese Schätzungen basieren auf einem Load Balancer mit einer Standardregel und einem Zertifikat mit einer Größe von 2 K. Bei Verwendung eines Zertifikats mit einer Größe von 4 K oder größer empfehlen wir, eine Kostenschätzung wie folgt vorzunehmen: Erstellen Sie einen Application Load Balancer basierend auf Ihrem Classic Load Balancer mit dem Migrationstool und überwachen Sie die Metrik ConsumedLCUs für den Application Load Balancer. Weitere Informationen finden Sie unter Migrieren eines Classic Load Balancers im Benutzerhandbuch für Elastic Load Balancing.

Metrik Beschreibung
EstimatedALBActiveConnectionCount

Die geschätzte Zahl gleichzeitiger TCP-Verbindungen, die zwischen Clients und Load Balancer und zwischen Load Balancer und Zielen aktiv sind.
EstimatedALBConsumedLCUs

Die geschätzte Zahl der von einem Application Load Balancer verwendeten Load-Balancer-Kapazitätseinheiten (LCU). Sie zahlen für die Anzahl dieser Geräte LCUs , die Sie pro Stunde nutzen. Weitere Informationen finden Sie unter Elastic Load Balancing Pricing.
EstimatedALBNewConnectionCount

Die geschätzte Zahl neuer TCP-Verbindungen, die zwischen Clients und Load Balancer und zwischen Load Balancer und Zielen hergestellt wurden.
EstimatedProcessedBytes

Die geschätzte Zahl der von einem Application Load Balancer verarbeiteten Byte.

Metrik-Dimensionen für Classic Load Balancer

Verwenden Sie die nachstehenden Dimensionen, um die Metriken für Ihren Classic Load Balancer zu filtern.

Dimension Beschreibung
AvailabilityZone

Filtert die Metrikdaten nach der angegebenen Availability Zone.
LoadBalancerName

Filtert die Metrikdaten nach dem angegebenen Load Balancer.

Statistiken für Classic-Load-Balancer-Metriken

CloudWatch stellt Statistiken bereit, die auf den von Elastic Load Balancing veröffentlichten metrischen Datenpunkten basieren. Statistiken sind Metrikdaten-Aggregationen über einen bestimmten Zeitraum. Wenn Sie Statistiken anfordern, wird der zurückgegebene Datenstrom durch den Metriknamen und die Dimension identifiziert. Eine Dimension ist ein name/value Paar, das eine Metrik eindeutig identifiziert. Sie können beispielsweise Statistiken für alle fehlerfreien EC2 Instances anfordern, die hinter einem Load Balancer stehen, der in einer bestimmten Availability Zone gestartet wurde.

Die Minimum- und Maximum-Statistiken geben die Minimum- und Maximalwerte an, die von den einzelnen Load Balancer-Knoten gemeldet werden. Angenommen, es gibt zwei Load Balancer-Knoten. Ein Knoten hat HealthyHostCount mit dem Minimum-Wert 2, dem Maximum-Wert 10 und dem Average-Wert 6, während der andere Knoten HealthyHostCount mit dem Minimum-Wert 1, dem Maximum-Wert 5 und dem Average-Wert 3 aufweist. Somit weist der Load Balancer den Minimum-Wert 1, den Maximum-Wert 10 und den Average-Wert von etwa 4 auf.

Die Sum-Statistik stellt den Gesamtwert aller Load Balancer-Knoten dar. Da Metriken mehrere Berichte pro Zeitraum umfassen, gilt Sum nur für Metriken, die über alle Load Balancer-Knoten aggregiert werden, wie RequestCount, HTTPCode_ELB_XXX, HTTPCode_Backend_XXX, BackendConnectionErrors und SpilloverCount.

Die SampleCount-Statistik ist die Zahl der gemessenen Stichproben. Da Metriken basierend auf Erfassungsintervallen und Ereignissen erfasst werden, ist diese Statistik in der Regel nicht nützlich. Bei HealthyHostCount basiert SampleCount z. B. auf der Anzahl der Stichproben, die jeder Load Balancer-Knoten meldet, nicht auf der Anzahl fehlerfreier Hosts.

Ein Perzentil gibt die relative Stelle eines Wertes in einem Datensatz an. Sie können ein beliebiges Perzentil mit bis zu zwei Dezimalstellen (z. B. p95,45) angeben. Ein 95. Perzentil bedeutet, dass 95 Prozent der Daten unter diesem Wert und 5 Prozent darüber liegen. Perzentile werden häufig genutzt, um Anomalien zu isolieren. Angenommen, eine Anwendung bedient die meisten Anforderungen aus einem Cache in 1-2 ms, aber benötigt 100 bis 200 ms, wenn der Cache leer ist. Das Maximum spiegelt den langsamsten Fall wider, etwa 200 ms. Der Durchschnitt gibt nicht die Verteilung der Daten an. Perzentile bieten eine aussagekräftigere Darstellung der Anwendungs-Performance. Indem Sie das 99. Perzentil als Auto Scaling-Trigger oder CloudWatch Alarm verwenden, können Sie festlegen, dass die Verarbeitung von nicht mehr als 1 Prozent der Anfragen länger als 2 ms dauert.

CloudWatch Metriken für Ihren Load Balancer anzeigen

Sie können die CloudWatch Metriken für Ihre Load Balancer mithilfe der EC2 Amazon-Konsole anzeigen. Diese Metriken werden in Überwachungsdiagrammen dargestellt. Die Überwachungsdiagramme zeigen Datenpunkte, wenn der Load Balancer aktiv ist und Anforderungen erhält.

Alternativ können Sie die Metriken für Ihren Load Balancer über die CloudWatch Konsole anzeigen.

So zeigen Sie Metriken mithilfe der -Konsole an

  1. Öffnen Sie die EC2 Amazon-Konsole unter https://console.aws.amazon.com/ec2/.

  2. Wählen Sie im Navigationsbereich unter LOAD BALANCING die Option Load Balancers aus.

  3. Wählen Sie den Namen des Load Balancers aus, um die Detailseite zu öffnen.

  4. Wählen Sie die Registerkarte Überwachung.

  5. Um eine größere Ansicht einer einzelnen Kennzahl zu erhalten, bewegen Sie den Mauszeiger über das Diagramm und wählen Sie das Maximize-Symbol. Die folgenden Metriken sind verfügbar:

    • Fehlerfreie Hosts – HealthyHostCount

    • Fehlerhafte Hosts – UnHealthyHostCount

    • Durchschnittliche Latenz – Latency

    • Anforderungen – RequestCount

    • Backend-Verbindungsfehler – BackendConnectionErrors

    • Anstiegswarteschlangenlänge – SurgeQueueLength

    • Überlaufanzahl – SpilloverCount

    • HTTP 2 XXs — HTTPCode_Backend_2XX

    • HTTP 3 XXs — HTTPCode_Backend_3XX

    • HTTP 4 XXs — HTTPCode_Backend_4XX

    • HTTP 5 XXs — HTTPCode_Backend_5XX

    • ELB HTTP 4 XXs — HTTPCode_ELB_4XX

    • ELB HTTP 5 XXs — HTTPCode_ELB_5XX

    • Geschätzte verarbeitete Byte – EstimatedProcessedBytes

    • Geschätzter ALB-Verbrauch — LCUs EstimatedALBConsumedLCUs

    • Geschätzte Anzahl aktiver ALB-Verbindungen – EstimatedALBActiveConnectionCount

    • Geschätzte Anzahl neuer ALB-Verbindungen – EstimatedALBNewConnectionCount

Um Metriken mit der CloudWatch Konsole anzuzeigen

  1. Öffnen Sie die CloudWatch Konsole unter https://console.aws.amazon.com/cloudwatch/.

  2. Wählen Sie im Navigationsbereich Metriken aus.

  3. Wählen Sie den ELB-Namespace.

  4. Führen Sie eine der folgenden Aktionen aus:

    • Wählen Sie eine Metrikdimension zum Anzeigen von Metriken nach Load Balancer, nach Availability Zone oder von allen Load Balancern.

    • Um eine Metrik für alle Dimensionen anzuzeigen, geben Sie den Namen in das Suchfeld ein.

    • Um die Metriken für einen einzelnen Load Balancer anzuzeigen, geben Sie den Namen in das Suchfeld ein.

    • Um die Metriken für eine einzelne Availability Zone anzuzeigen, geben Sie den Namen in das Suchfeld ein.