Zugriffsprotokolle für Ihren Classic Load Balancer - ELB
ZugriffsprotokolldateienZugriffsprotokolleinträgeVerarbeiten von Zugriffsprotokollen

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.

Zugriffsprotokolle für Ihren Classic Load Balancer

ELB stellt Zugriffsprotokolle bereit, in denen detaillierte Informationen zu Anfragen erfasst werden, die an Ihren Load Balancer gesendet wurden. Jedes Protokoll enthält Informationen wie die Zeit, zu der die Anforderung einging, die Client-IP-Adresse, Latenzen, Anforderungspfade und Serverantworten. Sie können diese Zugriffsprotokolle für die Analyse von Datenverkehrsmustern und zur Problembehebung verwenden.

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

Jede Zugriffsprotokolldatei wird automatisch mit SSE-S3 verschlüsselt, bevor sie im S3-Bucket gespeichert und beim Zugriff auf die Datei entschlüsselt wird. Sie müssen keine Maßnahmen ergreifen. Ver- und Entschlüsselung werden transparent durchgeführt. Jede Protokolldatei ist mit einem eindeutigen Schlüssel verschlüsselt, der wiederum mit einem KMS-Schlüssel verschlüsselt wird, der regelmäßig rotiert wird. Weitere Informationen finden Sie unter Schützen von Daten mithilfe serverseitiger Verschlüsselung mit von Amazon S3 verwalteten Verschlüsselungsschlüsseln (SSE-S3) im Amazon S3 S3-Benutzerhandbuch.

Es fallen für die Zugriffsprotokolle keine zusätzlichen Gebühren an. 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.

Inhalt

Zugriffsprotokolldateien

ELB veröffentlicht in dem von Ihnen angegebenen Intervall eine Protokolldatei für jeden Load Balancer-Knoten. Sie können ein Veröffentlichungsintervall von entweder 5 Minuten oder 60 Minuten festlegen, wenn Sie das Zugriffsprotokoll für Ihren Load Balancer aktivieren. Standardmäßig veröffentlicht ELB Protokolle in einem 60-Minuten-Intervall. Wenn das Intervall 5 Minuten lang ist, werden die Protokolle um 1:05, 1:10, 1:15 usw. veröffentlicht. Der Start der Protokollbereitstellung verzögert sich um bis zu 5 Minuten, wenn das Intervall auf 5 Minuten eingestellt ist, und bis zu 15 Minuten, wenn das Intervall auf 60 Minuten eingestellt ist. Sie können das Veröffentlichungsintervall jederzeit ändern.

Der Load Balancer kann mehrere Protokolle für denselben Zeitraum bereitstellen. Dies passiert in der Regel, wenn die Website hohen Datenverkehr, mehrere Load Balancer-Knoten und ein kurzes Protokollveröffentlichungsintervall hat.

Die Dateinamen der Zugriffsprotokolle verwenden das folgende Format:

amzn-s3-demo-loadbalancer-logs[/logging-prefix]/AWSLogs/aws-account-id/elasticloadbalancing/region/yyyy/mm/dd/aws-account-id_elasticloadbalancing_region_load-balancer-name_end-time_ip-address_random-string.log
amzn-s-3 demo-loadbalancer-logs

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-name

Der Name des Load Balancers.

end-time

Das Datum und die Uhrzeit, an dem das Protokollierungsintervall endete. Beispiel: Eine Endzeit von 20140215T2340Z enthält Einträge für Anforderungen zwischen 23:35 und 23:40 Uhr, wenn das Veröffentlichungsintervall 5 Minuten beträgt.

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 dem Präfix „my-app“:

s3://amzn-s3-demo-loadbalancer-logs/my-app/AWSLogs/123456789012/elasticloadbalancing/us-west-2/2018/02/15/123456789012_elasticloadbalancing_us-west-2_my-loadbalancer_20180215T2340Z_172.160.001.192_20sg8hgm.log

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

s3://amzn-s3-demo-loadbalancer-logs/AWSLogs/123456789012/elasticloadbalancing/us-west-2/2018/02/15/123456789012_elasticloadbalancing_us-west-2_my-loadbalancer_20180215T2340Z_172.160.001.192_20sg8hgm.log

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.

Zugriffsprotokolleinträge

ELB protokolliert Anfragen, die an den Load Balancer gesendet wurden, einschließlich Anfragen, die es nie an die Back-End-Instances geschafft haben. Wenn beispielsweise ein Client eine falsch formatierte Anforderung sendet oder keine fehlerfreie Instance für die Antwort verfügbar ist, werden die Anforderungen trotzdem protokolliert.

Wichtig

ELB protokolliert Anfragen nach bestem Wissen und Gewissen. Wir empfehlen, dass Sie die Zugriffsprotokolle verwende, um die Art der Anforderungen zu verstehen, nicht als eine vollständige Buchführung aller Anforderungen.

Syntax

Jeder Protokolleintrag enthält die Details einer einzelnen Anforderung an den Load Balancer. Alle Felder im Protokolleintrag sind durch Leerzeichen getrennt. Jeder Eintrag in der Protokolldatei weist das folgende Format auf:

timestamp elb client:port backend:port request_processing_time backend_processing_time response_processing_time elb_status_code backend_status_code received_bytes sent_bytes "request" "user_agent" ssl_cipher ssl_protocol

Die folgende Tabelle beschreibt die Felder eines Zugriffsprotokolleintrags.

Feld Description

time

Die Uhrzeit, zu der der Load Balancer die Anforderung vom Client erhalten hat, im ISO 8601-Format.

elb

Der Name des Load Balancers

client:port

Die IP-Adresse und den Port des anfordernden Clients.

backend:port

Die IP-Adresse und der Port der registrierten Instance, die diese Anfrage verarbeitet hat.

Wenn der Load Balancer die Anforderung nicht an eine registrierte Instance senden kann oder die Instance die Verbindung schließt, bevor eine Antwort gesendet werden kann, ist dieser Wert -.

Dieser Wert kann auch auf - gesetzt werden, wenn die registrierte Instance nicht vor dem Timeoutwert für die Leerlaufzeit reagiert.

request_processing_time

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

[TCP-Listener] Die gesamte abgelaufene Zeit in Sekunden ab dem Zeitpunkt, zu dem der Load Balancer eine TCP/SSL-Verbindung von einem Client akzeptiert hat, bis zu dem Zeitpunkt, an dem der Load Balancer das erste Datenbyte an eine registrierte Instance gesendet hat.

Dieser Wert wird auf -1 festgelegt, wenn der Load Balancer die Anforderung nicht einer registrierten Instance zuteilen kann. Dies kann der Fall sein, wenn die registrierte Instance die Verbindung vor dem Leerlaufzeitlimit schließt oder wenn der Client eine falsch formatierte Anforderung sendet. Bei TCP-Listenern kann dies auch vorkommen, wenn der Client eine Verbindung mit dem Load Balancer herstellt, aber keine Daten sendet.

Dieser Wert kann auch auf -1 gesetzt werden, wenn die registrierte Instance nicht vor dem Timeoutwert für die Leerlaufzeit reagiert.

backend_processing_time

[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.

Dieser Wert wird auf -1 festgelegt, wenn der Load Balancer die Anforderung nicht einer registrierten Instance zuteilen kann. Dies kann der Fall sein, wenn die registrierte Instance die Verbindung vor dem Leerlaufzeitlimit schließt oder wenn der Client eine falsch formatierte Anforderung sendet.

Dieser Wert kann auch auf -1 gesetzt werden, wenn die registrierte Instance nicht vor dem Timeoutwert für die Leerlaufzeit reagiert.

response_processing_time

[HTTP-Listener] Die gesamte abgelaufene Zeit (in Sekunden) ab dem Zeitpunkt, zu dem der Load Balancer den Antwort-Header von der registrierten Instance erhalten hat, bis zu dem Zeitpunkt, an dem er begonnen hat, die Antwort an den Client zu senden. Dies umfasst sowohl die Wartezeit am Load Balancer als auch die Zeit für die Herstellung der Verbindung vom Load Balancer zum Client.

[TCP-Listener] Die gesamte abgelaufene Zeit in Sekunden ab dem Zeitpunkt, zu dem der Load Balancer das erste Byte von der registrierten Instance erhalten hat, bis zu dem Zeitpunkt, an dem er begonnen hat, die Antwort an den Client zu senden.

Dieser Wert wird auf -1 festgelegt, wenn der Load Balancer die Anforderung nicht einer registrierten Instance zuteilen kann. Dies kann der Fall sein, wenn die registrierte Instance die Verbindung vor dem Leerlaufzeitlimit schließt oder wenn der Client eine falsch formatierte Anforderung sendet.

Dieser Wert kann auch auf -1 gesetzt werden, wenn die registrierte Instance nicht vor dem Timeoutwert für die Leerlaufzeit reagiert.

elb_status_code

[HTTP-Listener] Der Statuscode der Antwort vom Load Balancer.

backend_status_code

[HTTP-Listener] Der Statuscode der Antwort von der registrierten Instance.

received_bytes

Die Größe der Anforderung, in Byte, die vom Client (Auftraggeber) eingegangen ist.

[HTTP-Listener] Der Wert enthält den Anforderungstext, jedoch nicht die Header.

[TCP-Listener] Der Wert enthält den Anforderungstext und den Header.

sent_bytes

Die Größe der Antwort, in Byte, die an den Client (Auftraggeber) gesendet wurde.

[HTTP-Listener] Der Wert enthält den Antworttext, jedoch nicht die Header.

[TCP-Listener] Der Wert enthält den Anforderungstext und den Header.

request

Die Anforderungszeile vom Client in Anführungszeichen und protokolliert im folgenden Format: HTTP-Methode + Protokoll://Host-Header:Port + Pfad + HTTP-Version. Der Load Balancer behält die vom Client gesendete URL bei der Aufnahme des Anforderungs-URI unverändert bei. Es wird kein Inhaltstyp für die Zugriffsprotokolldatei festgelegt. Berücksichtigen Sie bei der Verarbeitung des Feldes, wie der Client die URL gesendet hat.

[TCP-Listener] Die URL hat drei Bindestriche, jeweils durch ein Leerzeichen getrennt und endet mit einem Leerzeichen ("- - - ").

user_agent

[HTTP/HTTPS listener] A User-Agent string that identifies the client that originated the request. The string consists of one or more product identifiers, product[/version]. Wenn die Zeichenfolge länger als 8 KB ist, wird sie gekürzt.

ssl_cipher

[Die HTTPS/SSL listener] The SSL cipher. This value is recorded only if the incoming SSL/TLS Verbindung wurde nach einer erfolgreichen Verhandlung hergestellt. Andernfalls wird der Wert auf - festgelegt.

ssl_protocol

[Die HTTPS/SSL listener] The SSL protocol. This value is recorded only if the incoming SSL/TLS Verbindung wurde nach einer erfolgreichen Verhandlung hergestellt. Andernfalls wird der Wert auf - festgelegt.

Beispiele

Beispiel für HTTP-Eintrag

Es folgt ein Beispiel für einen Protokolleintrag für einen HTTP-Listener (Port 80 zu Port 80):

2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.000073 0.001048 0.000057 200 200 0 29 "GET http://www.example.com:80/ HTTP/1.1" "curl/7.38.0" - -
Beispiel für HTTPS-Eintrag

Es folgt ein Beispiel für einen Protokolleintrag für einen HTTPS-Listener (Port 443 zu Port 80):

2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.000086 0.001048 0.001337 200 200 0 57 "GET https://www.example.com:443/ HTTP/1.1" "curl/7.38.0" DHE-RSA-AES128-SHA TLSv1.2
Beispiel für TCP-Eintrag

Es folgt ein Beispiel für einen Protokolleintrag für einen TCP-Listener (Port 8080 zu Port 80):

2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.001069 0.000028 0.000041 - - 82 305 "- - - " "-" - -
Beispiel für SSL-Eintrag

Es folgt ein Beispiel für einen Protokolleintrag für einen SSL-Listener (Port 8443 zu Port 80):

2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.001065 0.000015 0.000023 - - 57 502 "- - - " "-" ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2

Verarbeiten von Zugriffsprotokollen

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. Beispielsweise können Sie die folgenden analytischen Tools zum Analysieren und Verarbeiten von Zugriffsprotokollen verwenden: