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 Systemdiagnose
Elastic Load Balancing bietet Integritätsprüfungsprotokolle, in denen detaillierte Informationen über den Status Ihrer registrierten Ziele erfasst werden, einschließlich der Fehlerursachen, wenn Integritätsprüfungen fehlschlagen. 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 zur Integritätsprüfung, den Zeitstempel, die Zieladresse, die Zielgruppen-ID, den Gesundheitsstatus und den Ursachencode. Sie können diese Integritätsprüfungsprotokolle verwenden, um die Gesundheitsmuster der Ziele zu analysieren, Zustandsübergänge zu überwachen und Probleme zu beheben.
Integritätsprüfungsprotokolle sind eine optionale Funktion, die standardmäßig deaktiviert ist. Nachdem Sie die Integritätsprüfungsprotokolle für Ihren Load Balancer aktiviert haben, erfasst Elastic Load Balancing die Protokolle und speichert sie als komprimierte Dateien in dem von Ihnen angegebenen Amazon S3-Bucket. Sie können die Integritätsprüfungsprotokolle jederzeit deaktivieren.
Sie zahlen Speicherkosten für Amazon S3, aber Sie zahlen nicht für die Bandbreite, die von Elastic Load Balancing zum Senden von Protokolldateien an Amazon S3 verwendet wird. Weitere Information zu Speicherkosten finden Sie unter Amazon S3 – Preise
Wichtig
Während herkömmliche „Legacy“ -Protokolle (in diesem Abschnitt beschrieben) weiterhin verfügbar sind, bietet Application Load Balancer jetzt erweiterte Protokollierungsoptionen über CloudWatch Logs. CloudWatch Logs bieten flexiblere Lieferoptionen, unter anderem an Amazon CloudWatch Logs, Amazon Data Firehose und Amazon Simple Storage Service. Um diese verbesserten Protokollierungsoptionen zu konfigurieren, besuchen Sie den Tab Integrationen Ihres Load Balancers. Weitere Informationen zu CloudWatch Protokollen finden Sie unter. CloudWatch Protokolle für Ihren Application Load Balancer
Inhalt
Protokolldateien für den Systemstatus
Elastic Load Balancing 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 angehängt ist oder ein kleines Intervall für die Integritätsprüfung konfiguriert ist (z. B. alle 5 Sekunden).
Die Dateinamen der Integritätsprüfungsprotokolle verwenden 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
AWSLogsnicht enthalten. Weitere Informationen finden Sie unter Organisieren von Objekten mit Präfixen. AWSLogs-
Wir fügen den Teil des Dateinamens hinzu, der mit
AWSLogsnach 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.gzIm 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.gzSie können Protokolldateien auf unbestimmte Zeit in Ihrem Bucket speichern. Außerdem können Sie Amazon-S3-Lebenszyklusregeln definieren, um Protokolldateien automatisch zu archivieren oder zu löschen. Weitere Informationen finden Sie unter Object Lifecycle Management im Amazon S3-Benutzerhandbuch.
Protokolleinträge zur Integritätsprüfung
Elastic Load Balancing protokolliert die Ergebnisse der Zielzustandsprüfungen, einschließlich der Fehlerursachen für alle registrierten Ziele dieses Load Balancers. Jeder Logeintrag enthält die Details eines einzelnen Integritätsprüfungsergebnisses, das für das registrierte Ziel durchgeführt wurde.
Syntax
In der folgenden Tabelle werden die Felder eines Integritätsprüfungsprotokolleintrags 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 auf die Veröffentlichung eines neuen Felds vorbereiten, sehen Sie möglicherweise ein zusätzliches abschließendes „-“, bevor das Feld freigegeben wird. Stellen Sie sicher, dass Sie die Protokollanalyse so konfigurieren, dass sie nach dem letzten dokumentierten Feld endet, und aktualisieren Sie die Protokollanalyse, nachdem wir ein neues Feld veröffentlicht haben.
| Feld (Position) | Description |
|---|---|
|
typ (1) |
Die Art der Integritätsprüfungsanfrage oder Verbindung. Die möglichen Werte sind wie folgt (alle anderen Werte ignorieren):
|
|
Zeit (2) |
Zeitstempel, wann die Integritätsprüfung auf einem Ziel eingeleitet wird, im ISO 8601-Format. |
|
Latenz (3) |
Gesamtzeit (in Sekunden), die verstrichen ist, um die aktuelle Systemdiagnose abzuschließen. |
|
target_addr (4) |
IP-Adresse und Port des Ziels im Format,. IP:Port Der ARN von Lambda, wenn das Ziel eine Lambda-Funktion ist. |
|
Zielgruppe_ID (5) |
Name der Zielgruppe, der das Ziel zugeordnet ist. |
|
Status (6) |
Der Status des Gesundheitschecks. Dieser Wert gibt an |
|
status_code (7) |
Der Antwortcode, den das Ziel für die Integritätsprüfungsanforderung erhalten hat. |
|
Ursachencode (8) |
Der Grund für das Scheitern, falls die Systemdiagnose fehlschlägt. Siehe Codes für die Fehlerursache |
|
gelb (9) |
Die Ressourcen-ID des Load Balancer. Wenn Sie Zugriffsprotokolleinträge analysieren, beachten Sie, dass Ressourcen-IDs Schrägstriche (/) enthalten können. |
|
ip_adresse (10) |
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. |
Codes für die Fehlerursache
Schlägt die Systemdiagnose des Ziels fehl, protokolliert der Load Balancer einen der folgenden Ursachencodes im Systemdiagnoseprotokoll.
| Code | Description |
|---|---|
|
|
Die Integritätsprüfung ist fehlgeschlagen, weil beim Verbindungsversuch zum Ziel ein Timeout aufgetreten ist oder das Ziel nicht innerhalb des konfigurierten Timeout-Zeitraums für die Integritätsprüfung reagiert hat. Dies kann auftreten, wenn die Sicherheitsgruppe des Ziels eingehenden Datenverkehr auf dem Health Check-Port blockiert, das Ziel nur langsam reagiert oder der TLS-Handshake nicht rechtzeitig abgeschlossen wurde |
|
|
Die Integritätsprüfung ist fehlgeschlagen, weil das Ziel die Verbindung zurückgesetzt oder ordnungsgemäß geschlossen hat, bevor eine gültige Antwort zurückgegeben wurde |
|
|
Der HTTP-Statuscode der Antwort des Ziels auf die Integritätsprüfungsanforderung stimmte nicht mit dem konfigurierten Statuscode überein |
|
|
Der vom Ziel zurückgegebene Antworttext enthielt nicht die in der Konfiguration der Zielgruppen-Integritätsprüfung konfigurierte Zeichenfolge |
|
|
Interner Load Balancer-Fehler |
|
|
Target gibt als Antwort auf die Integritätsprüfungsanforderung den Fehlercode 5xx zurück |
|
|
Die GRPC-Zielantwort hat einen Grpc-Status-Header ohne Wert |
|
|
Das GRPC-Ziel reagiert mit einem unerwarteten Grpc-Status |
Anmerkung
Der neue TimedOut Fehlerursachencode ersetzt die RequestTimedOut Ursachencodes und. ConnectionTimedOut
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 Systemdiagnose.
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 Systemdiagnose.
http 2025-10-31T12:44:58.901409Z 1.121980746 172.31.31.9:80 HCLogsTestIPs FAIL 502 TargetErrorKonfigurieren Sie Benachrichtigungen über die Protokollzustellung
Um Benachrichtigungen zu erhalten, wenn Elastic Load Balancing Protokolle an Ihren S3-Bucket übermittelt, verwenden Sie Amazon S3 Event Notifications. Elastic Load Balancing verwendet PutObject CreateMultipartUpload, und ein POST-Objekt, um Protokolle an Amazon S3 zu übermitteln. Um sicherzustellen, dass Sie alle Benachrichtigungen zur Protokollzustellung erhalten, sollten Sie all diese Ereignisse zur Objekterstellung in Ihre Konfiguration aufnehmen.
Weitere Informationen finden Sie unter Amazon S3-Ereignisbenachrichtigungen im Amazon Simple Storage Service-Benutzerhandbuch.
Verarbeitung der Protokolldateien für die Integritätsprüfung
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. Sie können eine solch große Menge an Daten wahrscheinlich nicht zeilenweise 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 die Protokolle der 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.
