Protokolle zur Gesundheitsprüfung - ELB

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.

Protokolle zur Gesundheitsprüfung

ELB stellt Integritätsprüfungsprotokolle bereit, in denen detaillierte Informationen zum Status der Integritätsprüfungen Ihrer registrierten Ziele erfasst werden, einschließlich der Gründe für fehlgeschlagene Zustandsprüfungen. Health Check-Logs werden für EC2 Instances, IP-Adressen und Lambda-Funktionsziele unterstützt. Jeder Protokolleintrag enthält Informationen wie den Anforderungstyp oder die Verbindung, den Zeitstempel, die Zieladresse, die Zielgruppen-ID, den Gesundheitsstatus und den Ursachencode. Sie können diese Integritätsprüfungsprotokolle verwenden, um bestimmte Zustandsmuster zu analysieren, Zustandsübergänge zu überwachen und Probleme zu beheben.

Health Check-Logs sind eine optionale Funktion, die standardmäßig deaktiviert ist. Nachdem Sie die Health Check-Logs für Ihren Load Balancer aktiviert haben, erfasst ELB die Protokolle und speichert sie als komprimierte Dateien in dem von Ihnen angegebenen Amazon S3 S3-Bucket. Sie können die Health Check-Logs jederzeit deaktivieren.

Ihnen werden Speicherkosten für Amazon S3 berechnet, nicht jedoch die Bandbreite, die ELB zum Senden von Protokolldateien an Amazon S3 verwendet. Weitere Information zu Speicherkosten finden Sie unter Amazon S3 – Preise.

Protokolldateien zur Integritätsprüfung

ELB veröffentlicht alle 5 Minuten eine Protokolldatei für jeden Load Balancer-Knoten. Der Load Balancer kann mehrere Protokolle für denselben Zeitraum bereitstellen, wenn eine große Anzahl von Zielen an den Load Balancer angeschlossen ist oder ein kleines Intervall für die Integritätsprüfung konfiguriert ist (z. B. alle 5 Sekunden).

Die Dateinamen der Integritätsprüfungsprotokolle haben das folgende Format:

bucket[/prefix]/AWSLogs/aws-account-id/elasticloadbalancing/region/yyyy/mm/dd/health_check_log_aws-account-id_elasticloadbalancing_region_app.load-balancer-id_end-time_ip-address_random-string.log.gz
bucket

Der Name des S3-Buckets.

prefix

(Optional) Das Präfix (logische Hierarchie) für den Bucket. Das von Ihnen angegebene Präfix darf die Zeichenfolge AWSLogs nicht enthalten. Weitere Informationen finden Sie unter Organisieren von Objekten mit Präfixen.

AWSLogs

Wir fügen den Teil des Dateinamens hinzu, der mit AWSLogs nach dem von Ihnen angegebenen Bucket-Namen und dem optionalen Präfix beginnt.

aws-account-id

Die AWS Konto-ID des Besitzers.

Region

Die Region für Ihren Load Balancer und den S3-Bucket.

JJJJ/MM/TT

Das Datum, an dem das Protokoll übermittelt wurde.

load-balancer-id

Die Ressourcen-ID des Load Balancer. Wenn die Ressourcen-ID Schrägstriche (/) enthält, werden sie durch Punkte (.) ersetzt.

end-time

Das Datum und die Uhrzeit, an dem das Protokollierungsintervall endete. Beispiel: Die Endzeit 20140215T2340Z enthält Einträge für Anforderungen, die zwischen 23:35 und 23:40 in UTC- oder Zulu-Zeit durchgeführt wurden.

ip-address

Die IP-Adresse des Load Balancer-Knotens, der die Anforderung verarbeitet hat. Für einen internen Load Balancer handelt es sich hierbei um eine private IP-Adresse.

random-string

Eine vom System generierte zufällige Zeichenfolge.

Im Folgenden finden Sie ein Beispiel für einen Protokolldateinamen mit Präfix:

s3://amzn-s3-demo-logging-bucket/logging-prefix/AWSLogs/123456789012/elasticloadbalancing/us-east-2/2022/05/01/health_check_log_123456789012_elasticloadbalancing_us-east-2_app.my-loadbalancer.1234567890abcdef_20220215T2340Z_172.160.001.192_20sg8hgm.log.gz

Im Folgenden finden Sie ein Beispiel für einen Protokolldateinamen ohne Präfix:

s3://amzn-s3-demo-logging-bucket/AWSLogs/123456789012/elasticloadbalancing/us-east-2/2022/05/01/health_check_log_123456789012_elasticloadbalancing_us-east-2_app.my-loadbalancer.1234567890abcdef_20220215T2340Z_172.160.001.192_20sg8hgm.log.gz

Sie können Ihre Protokolldateien beliebig lange im Bucket speichern. Sie können aber auch Amazon S3-Lebenszyklusregeln aufstellen, anhand derer die Protokolldateien automatisch archiviert oder gelöscht werden. Weitere Informationen finden Sie unter Object Lifecycle Management im Amazon S3 S3-Benutzerhandbuch.

Protokolleinträge zur Integritätsprüfung

ELB protokolliert die Ergebnisse der Zielzustandsprüfungen einschließlich der Fehlergründe für alle registrierten Ziele dieses Load Balancers. Jeder Protokolleintrag enthält die Details eines einzelnen Ergebnisses einer Integritätsprüfung, die für das registrierte Ziel durchgeführt wurde.

Syntax

In der folgenden Tabelle werden die Felder eines Protokolleintrags für die Integritätsprüfung der Reihe nach beschrieben. Alle Felder werden durch Leerzeichen voneinander getrennt. Wenn wir ein neues Feld hinzufügen, fügen wir es am Ende des Protokolleintrags hinzu. Während wir uns darauf vorbereiten, ein neues Feld zu veröffentlichen, wird Ihnen möglicherweise ein zusätzliches „-“ am Ende angezeigt, bevor das Feld freigegeben wird. Stellen Sie sicher, dass Sie die Protokollanalyse so konfigurieren, dass sie nach dem letzten dokumentierten Feld beendet wird, und aktualisieren Sie die Protokollanalyse, sobald wir ein neues Feld veröffentlichen.

Feld (Position) Description

Typ (1)

Die Art der Anfrage oder Verbindung zur Zustandsprüfung. Die möglichen Werte sind wie folgt (alle anderen Werte ignorieren):

  • http-- HTTP

  • https-- HTTP über TLS

  • h2-- HTTP/2 über TLS

  • grpc-- gRPC

  • lambda-- Lambda-Funktion

Zeit (2)

Zeitstempel, zu dem die Integritätsprüfung für ein Ziel eingeleitet wird, im Format ISO 8601.

Latenz (3)

Gesamtzeit (in Sekunden), die bis zum Abschluss der aktuellen Zustandsprüfung verstrichen ist.

target_addr (4)

IP-Adresse und Port des Ziels im Format IP:Port. Der ARN von Lambda, wenn das Ziel eine Lambda-Funktion ist.

target_group_id (5)

Name der Zielgruppe, der das Ziel zugeordnet ist.

Status (6)

Der Status des Gesundheitschecks. Dieser Wert gibt anPASS, ob die Integritätsprüfung erfolgreich ist. Bei einer erfolglosen Zustandsprüfung ist der Wert FAIL

status_code (7)

Der Antwortcode, der vom Ziel für die Health Check-Anfrage empfangen wurde.

reason_code (8)

Der Grund für das Scheitern, wenn die Zustandsprüfung fehlschlägt. Siehe Codes für die Fehlerursache

Codes für die Fehlerursache

Wenn die Zustandsprüfung des Ziels fehlschlägt, protokolliert der Load Balancer einen der folgenden Ursachencodes im Protokoll der Integritätsprüfung.

Code Description

RequestTimedOut

Beim Warten auf eine Antwort wurde das Zeitlimit für die Anfrage zur Gesundheitsprüfung überschritten

ConnectionTimedOut

Die Integritätsprüfung ist fehlgeschlagen, da das Zeitlimit für den TCP-Verbindungsversuch überschritten wurde

ConnectionReset

Die Integritätsprüfung ist aufgrund eines Verbindungsresets fehlgeschlagen

ResponseCodeMismatch

Der HTTP-Statuscode der Antwort des Ziels auf die Integritätsprüfanfrage stimmte nicht mit dem konfigurierten Statuscode überein

ResponseStringMismatch

Der vom Ziel zurückgegebene Antworttext enthielt nicht die Zeichenfolge, die in der Konfiguration für die Zustandsprüfung der Zielgruppe konfiguriert wurde

InternalError

Interner Load Balancer-Fehler

TargetError

Target gibt als Antwort auf die Health Check-Anfrage den Fehlercode 5xx zurück

GRPCStatusHeaderEmpty

Die GRPC-Zielantwort hat einen grpc-status-Header ohne Wert

GRPCUnexpectedStatus

Das GRPC-Ziel reagiert mit einem unerwarteten GRPC-Status

Beispiel-Protokolleinträge

Im Folgenden finden Sie Beispiele für Protokolleinträge zur Integritätsprüfung. Beachten Sie, dass der Beispieltext nur aus Gründen der besseren Lesbarkeit in mehreren Zeilen angezeigt wird.

Im Folgenden finden Sie ein Beispiel für einen Protokolleintrag für eine erfolgreiche Zustandsprüfung.

http 2025-10-31T12:44:59.875678Z 0.019584011 172.31.20.97:80 HCLogsTestIPs PASS 200 -

Im Folgenden finden Sie ein Beispiel für einen Protokolleintrag für eine fehlgeschlagene Integritätsprüfung.

http 2025-10-31T12:44:58.901409Z 1.121980746 172.31.31.9:80 HCLogsTestIPs FAIL 502 TargetError

Konfigurieren Sie Benachrichtigungen zur Protokollzustellung

Verwenden Sie Amazon S3 Event Notifications, um Benachrichtigungen zu erhalten, wenn ELB Protokolle an Ihren S3-Bucket übermittelt. ELB verwendet PutObject, CreateMultipartUpload, und das POST-Objekt, um Protokolle an Amazon S3 zu übermitteln. Um sicherzustellen, dass Sie alle Benachrichtigungen zur Protokollzustellung erhalten, nehmen Sie all diese Ereignisse zur Objekterstellung in Ihre Konfiguration auf.

Weitere Informationen finden Sie unter Amazon S3 S3-Ereignisbenachrichtigungen im Amazon Simple Storage Service-Benutzerhandbuch.

Protokolldateien zur Integritätsprüfung werden verarbeitet

Die Protokolldateien der Integritätsprüfung sind komprimiert. Wenn Sie die Dateien herunterladen, müssen Sie sie dekomprimieren, um die Informationen anzuzeigen.

Falls es viele Zugriff auf Ihre Website gibt, kann der Load Balancer Protokolldateien mit mehreren Gigabyte an Daten generieren. Möglicherweise sind Sie nicht in der Lage, eine so große Datenmenge mithilfe von line-by-line Processing zu verarbeiten. Daher müssen Sie möglicherweise Tools zur Datenanalyse verwenden, die parallele Verarbeitungslösungen bieten. Sie können beispielsweise die folgenden Analysetools verwenden, um Protokolle von Integritätsprüfungen zu analysieren und zu verarbeiten:

  • Amazon Athena ist ein interaktiver Abfrageservice, der die Analyse von Daten in Amazon S3 mit Standard-SQL erleichtert.

  • Loggly

  • Splunk

  • Sumo Logic