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.
Verbindungsprotokolle für Ihren Application Load Balancer
Elastic Load Balancing stellt Verbindungsprotokolle bereit, die detaillierte Informationen über Anfragen erfassen, die an Ihren Load Balancer gesendet wurden. Jedes Protokoll enthält Informationen wie die IP-Adresse und den Port des Clients, den Listener-Port, die verwendete TLS-Chiffre und das verwendete Protokoll, die TLS-Handshake-Latenz, den Verbindungsstatus und Details zum Client-Zertifikat. Sie können diese Verbindungsprotokolle verwenden, um Anforderungsmuster zu analysieren und Probleme zu beheben.
Verbindungsprotokolle sind eine optionale Funktion von Elastic Load Balancing, die standardmäßig deaktiviert ist. Nachdem Sie Verbindungsprotokolle für Ihren Load Balancer aktiviert haben, erfasst Elastic Load Balancing die Protokolle und speichert sie in dem von Ihnen angegebenen Amazon S3 S3-Bucket als komprimierte Dateien. Sie können Verbindungsprotokolle 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
Inhalt
Verbindungsprotokolldateien
Elastic Load Balancing veröffentlicht alle 5 Minuten eine Protokolldatei für jeden Load-Balancer-Knoten. Die Protokollbereitstellung ist letztendlich konsistent. Der Load Balancer kann mehrere Protokolle für denselben Zeitraum bereitstellen. Dies passiert in der Regel, wenn die Website hohen Datenverkehr aufweist.
Die Dateinamen der Verbindungsprotokolle verwenden das folgende Format:
bucket[/prefix]/AWSLogs/aws-account-id/elasticloadbalancing/region/yyyy/mm/dd/conn_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/conn_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/conn_log.123456789012_elasticloadbalancing_us-east-2_app.my-loadbalancer.1234567890abcdef_20220215T2340Z_172.160.001.192_20sg8hgm.log.gzSie 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.
Verbindungsprotokolleinträge
Jeder Verbindungsversuch hat einen Eintrag in einer Verbindungsprotokolldatei. Wie Client-Anfragen gesendet werden, hängt davon ab, ob die Verbindung persistent oder nicht persistent ist. Nicht persistente Verbindungen haben eine einzige Anfrage, wodurch ein einziger Eintrag im Zugriffs- und Verbindungsprotokoll erstellt wird. Persistente Verbindungen haben mehrere Anfragen, wodurch mehrere Einträge im Zugriffsprotokoll und ein einziger Eintrag im Verbindungsprotokoll erstellt werden.
Syntax
In der folgenden Tabelle werden die Felder eines Verbindungsprotokolleintrags der Reihe nach beschrieben. Alle Felder werden durch Leerzeichen voneinander getrennt. Wenn neue Felder eingeführt werden, werden sie am Ende des Protokolleintrags hinzugefügt. Sie sollten alle Felder am Ende des Protokolleintrags ignorieren, die Sie nicht erwartet haben.
| Feld | Beschreibung |
|---|---|
|
timestamp |
Der Zeitpunkt im ISO 8601-Format, zu dem der Load Balancer erfolgreich eine Verbindung hergestellt hat oder nicht. |
|
client_ip |
Die IP-Adresse des anfragenden Clients. |
|
client_port |
Der Port des anfragenden Clients. |
|
listener_port |
Der Port des Load Balancer-Listeners, der die Client-Anfrage empfängt. |
|
tls_protocol |
[HTTPS-Listener] Das SSL/TLS Protokoll, das bei Handshakes verwendet wird. Dieses Feld ist auf „Keine Anfragen“ gesetzt |
|
tls_cipher |
[HTTPS-Listener] Das bei SSL/TLS Handshakes verwendete Protokoll. Dieses Feld ist auf „Keine Anfragen“ gesetzt |
|
tls_handshake_latency |
[HTTPS-Listener] Die Gesamtzeit in Sekunden, mit einer Genauigkeit von Millisekunden, die beim Aufbau eines erfolgreichen Handshakes verstrichen ist. Dieses Feld ist auf Folgendes gesetzt:
|
|
leaf_client_cert_subject |
[HTTPS-Listener] Der Betreffname des Leaf-Client-Zertifikats. Dieses Feld ist auf Folgendes gesetzt
|
|
leaf_client_cert_validity |
[HTTPS-Listener] Die Gültigkeit des Leaf-Client-Zertifikats mit
|
|
leaf_client_cert_serial_number |
[HTTPS-Listener] Die Seriennummer des Leaf-Client-Zertifikats. Dieses Feld ist auf Folgendes gesetzt
|
|
tls_verify_status |
[HTTPS-Listener] Der Status der Verbindungsanfrage. Dieser Wert gibt an |
|
conn_trace_id |
Die Verbindungsrückverfolgbarkeits-ID ist eine eindeutige undurchsichtige ID, die zur Identifizierung jeder Verbindung verwendet wird. Nachdem eine Verbindung mit einem Client hergestellt wurde, enthalten nachfolgende Anfragen von diesem Client diese ID in ihren jeweiligen Zugriffsprotokolleinträgen. Diese ID fungiert als Fremdschlüssel, um eine Verbindung zwischen der Verbindung und den Zugriffsprotokollen herzustellen. |
Codes für die Fehlerursache
Wenn der Load Balancer keine Verbindung herstellen kann, speichert der Load Balancer einen der folgenden Ursachencodes im Verbindungsprotokoll.
| Code | Beschreibung |
|---|---|
|
|
Die maximale Tiefe der Client-Zertifikatskette wurde überschritten |
|
|
Die maximale Größe des Client-Zertifikats wurde überschritten |
|
|
Das Client-Zertifikat wurde von der CA gesperrt |
|
|
Fehler bei der CRL-Verarbeitung |
|
|
Das Client-Zertifikat ist nicht vertrauenswürdig |
|
|
Das Client-Zertifikat ist noch nicht gültig |
|
|
Das Client-Zertifikat ist abgelaufen |
|
|
Der Typ des Client-Zertifikats wird nicht unterstützt |
|
|
Das Client-Zertifikat ist ungültig |
|
|
Der Zweck des Client-Zertifikats ist ungültig |
|
|
Das Client-Zertifikat wurde durch die benutzerdefinierte Servervalidierung abgelehnt |
|
|
Fehler bei der Verbindung zur Laufzeit bei nicht zugeordneter Zuordnung |
Beispiel-Protokolleinträge
Im Folgenden finden Sie Beispiele für Verbindungsprotokolleinträge. Beachten Sie, dass der Beispieltext nur aus Gründen der besseren Lesbarkeit in mehreren Zeilen erscheint.
Im Folgenden finden Sie ein Beispiel für einen Protokolleintrag für eine erfolgreiche Verbindung mit einem HTTPS-Listener, bei dem der Modus für die gegenseitige TLS-Überprüfung auf Port 443 aktiviert ist.
2023-10-04T17:05:15.514108Z 203.0.113.1 36280 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 4.036
"CN=amazondomains.com,O=endEntity,L=Seattle,ST=Washington,C=US" NotBefore=2023-09-21T22:43:21Z;NotAfter=2026-06-17T22:43:21Z
FEF257372D5C14D4 Success TID_3180a73013c8ca4bac2f731159d4b0feIm Folgenden finden Sie ein Beispiel für einen Protokolleintrag für eine fehlgeschlagene Verbindung mit einem HTTPS-Listener, bei dem der gegenseitige TLS-Überprüfungsmodus auf Port 443 aktiviert ist.
2023-10-04T17:05:15.514108Z 203.0.113.1 36280 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 -
"CN=amazondomains.com,O=endEntity,L=Seattle,ST=Washington,C=US" NotBefore=2023-09-21T22:43:21Z;NotAfter=2026-06-17T22:43:21Z
FEF257372D5C14D4 Failed:ClientCertUntrusted TID_1c71a68d70587445ad5127ff8b2687d7Verbindungsprotokolldateien werden verarbeitet
Die Verbindungsprotokolldateien sind komprimiert. Wenn Sie die Dateien mithilfe der Amazon-S3-Konsole öffnen, werden sie dekomprimiert und die Informationen werden angezeigt. 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 Verbindungsprotokolle zu analysieren und zu verarbeiten:
-
Amazon Athena ist ein interaktiver Abfrageservice, der die Analyse von Daten in Amazon S3 mit Standard-SQL erleichtert.
