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 Ihre Application Load Balancer
Elastic Load Balancing bietet Zugriffsprotokolle, die detaillierte Informationen zu Anforderungen erfassen, die an Ihren Load Balancer gesendet werden. 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 ein optionales Feature von Elastic Load Balancing, das standardmäßig deaktiviert ist. Nachdem Sie die Zugriffsprotokolle für Ihren Load Balancer aktiviert haben, erfasst Elastic Load Balancing die Protokolle und speichert sie in dem von Ihnen angegebenen Amazon-S3-Bucket als komprimierte Dateien. Sie können die Zugriffsprotokolle 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
Zugriffsprotokolldateien
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 Zugriffsprotokolle verwenden das folgende Format:
bucket[/prefix]/AWSLogs/aws-account-id/elasticloadbalancing/region/yyyy/mm/dd/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://my-bucket/my-prefix/AWSLogs/123456789012/elasticloadbalancing/us-east-2/2022/05/01/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://my-bucket/AWSLogs/123456789012/elasticloadbalancing/us-east-2/2022/05/01/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 Objekt-Lebenszyklusmanagement im Benutzerhandbuch zu Amazon Simple Storage Service.
Zugriffsprotokolleinträge
Elastic Load Balancing protokolliert Anforderungen, die an den Load Balancer gesendet wurden, einschließlich Anforderungen, die nicht bei den Zielen ankamen. Wenn ein Client beispielsweise eine falsch formatierte Anfrage sendet oder keine fehlerfreien Ziele vorhanden sind, die auf die Anfrage reagieren können, wird die Anfrage dennoch protokolliert. Elastic Load Balancing protokolliert keine Zustandsprüfungsanforderungen.
Jeder Protokolleintrag enthält die Details einer einzelnen Anfrage (oder Verbindung im Fall von WebSockets), die an den Load Balancer gestellt wurde. Denn ein Eintrag wird erst geschrieben WebSockets, nachdem die Verbindung geschlossen wurde. Wenn die erweiterte Verbindung nicht hergestellt werden kann, entspricht der Eintrag dem für eine HTTP- oder HTTPS-Anfrage.
Wichtig
Elastic Load Balancing protokolliert Anforderungen nach bestmöglichem Bemühen. Wir empfehlen, dass Sie die Zugriffsprotokolle verwende, um die Art der Anforderungen zu verstehen, nicht als eine vollständige Buchführung aller Anforderungen.
Syntax
Die folgende Tabelle beschreibt die Felder eines Zugriffsprotokolleintrags der Reihe nach. 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 |
|---|---|
|
Typ |
Der Typ der Anfrage oder Verbindung. Die möglichen Werte sind wie folgt (alle anderen Werte ignorieren):
|
|
time |
Die Zeit, zu der der Load Balancer eine Antwort an den Client generiert hat, im Format ISO 8601. Denn dies ist die Zeit WebSockets, in der die Verbindung geschlossen wird. |
|
elb |
Die Ressourcen-ID des Load Balancer. Wenn Sie Zugriffsprotokolleinträge analysieren, beachten Sie, dass Ressourcen-IDs Schrägstriche (/) enthalten können. |
|
client:port |
Die IP-Adresse und den Port des anfordernden Clients. Wenn sich vor dem Load Balancer ein Proxy befindet, enthält dieses Feld die IP-Adresse des Proxys. |
|
target:port |
Die IP-Adresse und der Port des Ziels, das diese Anfrage verarbeitet hat. Wenn der Client keine vollständige Anfrage gesendet hat, kann der Load Balancer die Anfrage keinem Ziel zuteilen, und dieser Wert wird auf - festgelegt. Wenn das Ziel eine Lambda-Funktion ist, ist dieser Wert auf - einstellt. Wenn die Anfrage blockiert wird von AWS WAF, wird dieser Wert auf - und der Wert von elb_status_code auf 403 gesetzt. |
|
request_processing_time |
Die insgesamt verstrichene Zeit (in Sekunden, mit einer Genauigkeit in Millisekunden) ab dem Zeitpunkt, zu dem der Load Balancer die Anforderung erhalten hat, bis zu dem Zeitpunkt, zu dem er die Anforderung an ein Ziel gesendet hat. Dieser Wert wird auf -1 festgelegt, wenn der Load Balancer die Anfrage keinem Ziel zuteilen kann. Dies kann der Fall sein, wenn das Ziel die Verbindung vor dem Leerlaufzeitlimit schließt, oder wenn der Client eine falsch formatierte Anfrage sendet. Dieser Wert kann auch auf -1 gesetzt werden, wenn das registrierte Ziel nicht vor dem Timeoutwert für die Leerlaufzeit antwortet. Wenn für Ihren Application Load Balancer aktiviert AWS WAF ist oder der Zieltyp eine Lambda-Funktion ist, wird die Zeit, die der Client benötigt, um die erforderlichen Daten für POST-Anfragen zu senden, angerechnet. |
|
target_processing_time |
Die insgesamt verstrichene Zeit (in Sekunden, mit einer Genauigkeit in Millisekunden) ab dem Zeitpunkt, zu dem der Load Balancer die Anfrage an ein Ziel gesendet hat, bis zu dem Zeitpunkt, zu dem das Ziel begonnen hat, die Antwort-Header zu senden. Dieser Wert wird auf -1 festgelegt, wenn der Load Balancer die Anfrage keinem Ziel zuteilen kann. Dies kann der Fall sein, wenn das Ziel die Verbindung vor dem Leerlaufzeitlimit schließt, oder wenn der Client eine falsch formatierte Anfrage sendet. Dieser Wert kann auch auf -1 gesetzt werden, wenn das registrierte Ziel nicht vor dem Timeoutwert für die Leerlaufzeit antwortet. Wenn es für Ihren Application Load Balancer nicht aktiviert AWS WAF ist, wird die Zeit angerechnet |
|
response_processing_time |
Die insgesamt verstrichene Zeit (in Sekunden, mit einer Genauigkeit in Millisekunden) ab dem Zeitpunkt, zu dem der Load Balancer den Antwort-Header vom Ziel erhalten hat, bis zu dem Zeitpunkt, zu 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. Dieser Wert wird auf -1 gesetzt, wenn der Load Balancer keine Antwort von einem Ziel erhält. Dies kann der Fall sein, wenn das Ziel die Verbindung vor dem Leerlaufzeitlimit schließt, oder wenn der Client eine falsch formatierte Anfrage sendet. |
|
elb_status_code |
Der Statuscode der Antwort vom Load Balancer. |
|
target_status_code |
Der Statuscode der Antwort vom Ziel. Dieser Wert wird nur aufgezeichnet, wenn eine Verbindung zum Ziel hergestellt wurde und das Ziel eine Antwort gesendet hat. Andernfalls lautet der Wert –. |
|
received_bytes |
Die Größe der Anforderung, in Byte, die vom Client (Auftraggeber) eingegangen ist. Bei HTTP-Anfragen sind die Header eingeschlossen. Denn dies ist die Gesamtzahl der Byte WebSockets, die vom Client über die Verbindung empfangen wurden. |
|
sent_bytes |
Die Größe der Antwort, in Byte, die an den Client (Auftraggeber) gesendet wurde. Bei HTTP-Anfragen sind die Header eingeschlossen. Denn dies ist die Gesamtzahl der Byte WebSockets, die über die Verbindung an den Client gesendet wurden. |
|
„request“ |
Die Anfragezeile vom Client in Anführungszeichen und protokolliert mit folgendem Format: HTTP-Methode + Protokoll://Host:Port/URI + 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. |
|
„user_agent“ |
Eine User-Agent-Zeichenfolge, die den Client identifiziert, von dem die Anfrage stammt, in Anführungszeichen. Die Zeichenfolge besteht aus einem oder mehreren Produkt-IDs, Produkt[/Version]. Wenn die Zeichenfolge länger als 8 KB ist, wird sie gekürzt. |
|
ssl_cipher |
[HTTPS-Listener] Die SSL-Verschlüsselung. Dieser Wert ist auf „-“ festgelegt, wenn es sich bei dem Listener nicht um einen HTTPS-Listener handelt. |
|
ssl_protocol |
[HTTPS-Listener] Das SSL-Protokoll. Dieser Wert ist auf „-“ festgelegt, wenn es sich bei dem Listener nicht um einen HTTPS-Listener handelt. |
|
target_group_arn |
Der Amazon-Ressourcenname (ARN) der Zielgruppe. |
|
"trace_id" |
Der Inhalt des X-Amzn-Trace-Id-Headers in Anführungszeichen. |
|
"domain_name" |
[HTTPS-Listener] Die vom Client beim TLS-Handshake bereitgestellte SNI-Domain in Anführungszeichen. Dieser Wert wird auf - festgelegt, wenn der Client SNI nicht unterstützt oder die Domain keinem Zertifikat entspricht und dem Client das Standardzertifikat vorgelegt wird. |
|
"chosen_cert_arn" |
[HTTPS-Listener] Der ARN des Zertifikats, das dem Client vorgelegt wird, in Anführungszeichen. Dieser Wert ist auf |
|
matched_rule_priority |
Der Prioritätswert der Regel, die eine Übereinstimmung mit der Anforderung erzeugt. Wenn eine Regel eine Übereinstimmung erzeugt hat, ist dies ein Wert zwischen 1 und 50.000. Hat keine Regel eine Übereinstimmung erzeugt und die Standardaktion wurde ausgeführt, ist dieser Wert 0. Wenn während der Regelauswertung ein Fehler auftritt, beträgt der Wert -1. Für alle anderen Fehler lautet der Wert -. |
|
request_creation_time |
Die Uhrzeit, zu der der Load Balancer die Anforderung vom Client erhalten hat, im ISO 8601-Format. |
|
"actions_executed" |
Die bei der Verarbeitung der Anfrage ergriffenen Maßnahmen in Anführungszeichen. Dieser Wert ist eine durch Kommas getrennte Liste, die die in Ergriffene Maßnahmen beschriebenen Werte enthalten kann. Wenn keine Maßnahmen ergriffen wurden, beispielsweise bei einer falsch formatierten Anfrage, wird dieser Wert auf - festgelegt. |
|
"redirect_url" |
Die URL des Weiterleitungsziels für den Location-Header der HTTP-Antwort in doppelten Anführungszeichen. Wenn keine Weiterleitungsaktionen ausgeführt wurden, wird dieser Wert auf "-" eingestellt. |
|
"error_reason" |
Der Ursachencode in doppelten Anführungszeichen. Wenn die Anforderung fehlschlug, ist dies einer der in Codes für die Fehlerursache beschriebenen Fehlercodes. Wenn die durchgeführten Aktionen keine Authentifizierungsaktion umfassen oder das Ziel keine Lambda-Funktion ist, wird dieser Wert auf „-“ festgelegt. |
|
„target:port_list“ |
Eine durch Leerzeichen getrennte Liste von IP-Adressen und Ports für die Ziele, die diese Anforderung verarbeitet haben, eingeschlossen in doppelten Anführungszeichen. Derzeit kann diese Liste ein Element enthalten und es entspricht dem target:port-Feld. Wenn der Client keine vollständige Anfrage gesendet hat, kann der Load Balancer die Anfrage keinem Ziel zuteilen, und dieser Wert wird auf - festgelegt. Wenn das Ziel eine Lambda-Funktion ist, ist dieser Wert auf - einstellt. Wenn die Anfrage blockiert wird von AWS WAF, wird dieser Wert auf - und der Wert von elb_status_code auf 403 gesetzt. |
|
„target_status_code_list“ |
Eine durch Leerzeichen getrennte Liste von Statuscodes aus den Antworten der Ziele, die in doppelte Anführungszeichen eingeschlossen sind. Derzeit kann diese Liste ein Element enthalten und entspricht dem target_status_code-Feld. Dieser Wert wird nur aufgezeichnet, wenn eine Verbindung zum Ziel hergestellt wurde und das Ziel eine Antwort gesendet hat. Andernfalls lautet der Wert –. |
|
„classification“ |
Die Klassifikation für die desynchrone Mitigation in doppelten Anführungszeichen. Wenn die Anforderung nicht den Anforderungen von RFC 7230 entspricht, lauten die möglichen Werte „Acceptable“ (Akzeptabel), „Ambiguous“ (Mehrdeutig) und „Severe“ (Schwerwiegend). Wenn die Anforderung RFC 7230 entspricht, wird dieser Wert auf „-“ gesetzt. |
|
„classification_reason“ |
Der Ursachencode für die Klassifizierung steht in doppelten Anführungszeichen. Wenn die Anforderung nicht RFC 7230 entspricht, ist dies einer der unter Gründe für die Klassifizierung beschriebenen Klassifizierungscodes. Wenn die Anforderung RFC 7230 entspricht, wird dieser Wert auf „-“ gesetzt. |
|
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 den Verbindungs- und Zugriffsprotokollen herzustellen. |
Ergriffene Maßnahmen
Der Load Balancer speichert die ausgeführten Maßnahmen im Feld „actions_executed“ des Zugriffsprotokolls.
-
authenticate– Der Load Balancer hat die Sitzung validiert, den Benutzer authentifiziert und die Benutzerinformationen den Anforderungs-Headern hinzugefügt, wie in der Regelkonfiguration angegeben. -
fixed-response– Der Load Balancer hat eine feste Antwort ausgegeben, wie in der Regelkonfiguration angegeben. -
forward– Der Load Balancer hat die Anforderung an ein Ziel weitergeleitet, wie in der Regelkonfiguration angegeben. -
redirect– Der Load Balancer hat die Anforderung an eine andere URL weitergeleitet, wie in der Regelkonfiguration angegeben. -
waf– Der Load Balancer hat die Anforderung an AWS WAF weitergeleitet, um festzustellen, ob die Anforderung an das Ziel weitergeleitet werden sollte. Wenn dies die letzte Aktion ist, wurde AWS WAF festgestellt, dass die Anfrage abgelehnt werden sollte. -
waf-failed— Der Load Balancer hat versucht, die Anfrage weiterzuleiten AWS WAF, aber dieser Vorgang ist fehlgeschlagen.
Gründe für die Klassifizierung
Wenn eine Anforderung nicht RFC 7230 entspricht, speichert der Load Balancer einen der folgenden Codes im Feld „classification_reason“ des Zugriffsprotokolls. Weitere Informationen finden Sie unter Desynchroner Mitigationsmodus.
| Code | Beschreibung | Klassifizierung |
|---|---|---|
|
|
Der Anforderungs-URI enthält Steuerzeichen. |
Mehrdeutig |
|
|
Der Content-Length-Header enthält einen Wert, der nicht analysiert werden kann oder der keine gültige Zahl ist. |
Schwerwiegend |
|
|
Ein Header enthält ein Nullzeichen oder einen Zeilenumbuch. |
Schwerwiegend |
|
|
Der Transfer-Encoding-Header enthält einen ungültigen Wert. |
Schwerwiegend |
|
|
Die Anforderungs-URI enthält ein Nullzeichen oder ein Zeilenumkehrzeichen. |
Schwerwiegend |
|
|
Die Anforderungsmethode ist falsch formatiert. |
Schwerwiegend |
|
|
Die Anforderungsversion ist falsch formatiert. |
Schwerwiegend |
|
|
Die Anforderung enthält sowohl einen Transfer-Encoding-Header als auch einen Content-Length-Header. |
Mehrdeutig |
|
|
Es gibt mehrere Content-Length-Header mit demselben Wert. |
Mehrdeutig |
|
|
Eine Kopfzeile ist leer oder es gibt eine Zeile, die nur Leerzeichen enthält. |
Mehrdeutig |
|
|
Es gibt einen Content-Length-Header mit dem Wert 0 für eine GET- oder HEAD-Anforderung. |
Akzeptabel |
|
|
Es gibt mehrere Content-Length-Header mit verschiedenen Werten. |
Schwerwiegend |
|
|
Es gibt mehrere „Transfer-Encoding: chunked“-Header. |
Schwerwiegend |
|
|
Ein Header enthält ein Nicht-ASCII- oder Steuerzeichen. |
Akzeptabel |
|
|
Die Anforderungsversion enthält einen ungültigen Wert. |
Akzeptabel |
|
|
Die Anforderungs-URI enthält ein Leerzeichen, das nicht URL-codiert ist. |
Akzeptabel |
|
|
Es gibt einen Header, der mithilfe gängiger Textnormalisierungstechniken auf Transfer-Encoding oder Content-Length normalisiert werden kann. |
Mehrdeutig |
|
|
Für eine GET- oder HEAD-Anforderung ist ein Content-Length-Header definiert. |
Mehrdeutig |
|
|
Für eine GET- oder HEAD-Anforderung ist ein Transfer-Encoding-Header definiert. |
Mehrdeutig |
Codes für die Fehlerursache
Wenn der Load Balancer keine Authentifizierungsaktion abschließen kann, speichert er einen der folgenden Ursachencodes im Feld „error_reason“ im Aktionsprotokoll. Der Load Balancer erhöht auch die entsprechende Metrik. CloudWatch Weitere Informationen finden Sie unter Authentifizieren von Benutzern mithilfe eines Application Load Balancers.
| Code | Beschreibung | Metrik |
|---|---|---|
|
|
Das Authenitfizierungs-Cookie ist ungültig. |
|
|
|
Der Code zur Gewährung der Authentifizierungs vom Token-Endpunkt ist ungültig. |
|
|
|
Das ID-Token ist ungültig. |
|
|
|
Der Zustandsparameter ist ungültig. |
|
|
|
Die Antwort vom Token-Endpunkt ist ungültig. |
|
|
|
Die Antwort vom Benutzerinformationsendpunkt ist ungültig. |
|
|
|
Der Authentifizierungsantwort vom Authentifizierungsendpunkt fehlt ein Abfrageparameter namens „code“. |
|
|
|
Der Authentifizierungsantwort vom Authentifizierungsendpunkt fehlt ein Host-Header-Feld. |
|
|
|
Der Authentifizierungsantwort vom Authentifizierungsendpunkt fehlt ein Abfrageparameter namens „state“. |
|
|
|
Es liegt eine Fehlerantwort (non-2XX) vom Token-Endpunkt vor. |
|
|
|
Der Load Balancer kann nicht mit dem Token-Endpunkt kommunizieren. |
|
|
|
Der Load Balancer hat eine unbehandelte Ausnahme festgestellt. |
|
|
|
Es liegt eine Fehlerantwort (non-2XX) vom Identitätsanbieter-Benutzerinformationsendpunkt vor. |
|
|
|
Der Load Balancer kann nicht mit dem Identitätsanbieter-Benutzerinformationsendpunkt kommunizieren. |
|
|
|
Die Größe der vom Identitätsanbieter zurückgegebenen Ansprüche übersteigt 11 K Byte. |
|
Wenn eine Anforderung an eine gewichtete Zielgruppe fehlschlägt, speichert der Load Balancer einen der folgenden Fehlercodes im Feld „error_reason“ des Zugriffsprotokolls.
| Code | Beschreibung |
|---|---|
|
|
Das AWSALBTG Cookie, das bei gewichteten Zielgruppen verwendet wird, ist nicht gültig. Beispielsweise gibt der Load Balancer diesen Fehler zurück, wenn Cookie-Werte URL-codiert sind. |
|
|
Der Load Balancer hat eine unbehandelte Ausnahme festgestellt. |
Wenn eine Anforderung an eine Lambda-Funktion fehlschlägt, speichert der Load Balancer eine der folgenden Ursachencodes im Feld "error_reason" des Zugriffsprotokolls. Der Load Balancer erhöht auch die entsprechende CloudWatch Metrik. Weitere Informationen finden Sie unter der Lambda-Aktion Invoke.
| Code | Beschreibung | Metrik |
|---|---|---|
|
|
Der Load Balancer war nicht zum Aufrufen der Lambda-Funktion berechtigt. |
|
|
|
Der Lambda-Aufruf ist fehlgeschlagen, da die Clientanforderungsheader oder der Hauptteil nicht nur UTF-8-Zeichen enthalten. |
|
|
|
Der Load Balancer kann keine Verbindung mit Lambda herstellen. |
|
|
|
Bei dem Versuch, eine Verbindung mit Lambda herzustellen, ist eine Zeitüberschreitung aufgetreten. |
|
|
|
Amazon EC2 hat während der Initialisierung der Funktion den Zugriff auf Lambda abgelehnt. |
|
|
|
Amazon EC2 drosselte Lambda während der Initialisierung der Funktion. |
|
|
|
Bei Amazon EC2 trat während der Initialisierung der Funktion ein unerwarteter Fehler auf. |
|
|
|
Lambda konnte in der VPC, die in der Konfiguration der Lambda-Funktion angegeben wird, keine Netzwerkschnittstelle erstellen, da das Limit für Netzwerkschnittstellen überschritten wurde. |
|
|
|
Die Antwort von der Lambda-Funktion ist falsch formatiert oder enthält nicht alle erforderlichen Felder. |
|
|
|
Die angegebene Version der Lamda-Laufzeit wird nicht unterstützt. |
|
|
|
Die angegebene Sicherheitsgruppen-ID in der Konfiguration der Lambda-Funktion ist nicht gültig. |
|
|
|
Die angegebene Subnetz-ID in der Konfiguration der Lambda-Funktion ist nicht gültig. |
|
|
|
Lambda konnte die angegebene Funktions-Zip-Datei nicht entpacken. |
|
|
|
Lambda konnte die Umgebungsvariablen nicht entschlüsseln, da der Zugriff auf den KMS-Schlüssel abgelehnt wurde. Überprüfen Sie die KMS-Berechtigungen der Lambda-Funktion. |
|
|
|
Lambda konnte die Umgebungsvariablen nicht entschlüsseln, da der angegebene KMS-Schlüssel deaktiviert ist. Überprüfen Sie die Einstellungen des KMS-Schlüssels der Lambda-Funktion. |
|
|
|
Lambda konnte die Umgebungsvariablen nicht entschlüsseln, da der Zustand des KMS-Schlüssels nicht gültig ist. Überprüfen Sie die Einstellungen des KMS-Schlüssels der Lambda-Funktion. |
|
|
|
Lambda konnte die Umgebungsvariablen nicht entschlüsseln, da der KMS-Schlüssel nicht gefunden wurde. Überprüfen Sie die Einstellungen des KMS-Schlüssels der Lambda-Funktion. |
|
|
|
Die Größe des Anfragetextes überschritt 1 MB. |
|
|
|
Die Lambda-Funktion konnte nicht gefunden werden. |
|
|
|
Die Größe der Antwort überschritt 1 MB. |
|
|
|
Bei Lambda trat ein interner Fehler auf. |
|
|
|
Lambda konnte den VPC-Zugriff für die Lambda-Funktion nicht einrichten, da ein oder mehrere konfigurierte Subnetze keine verfügbaren IP-Adressen haben. |
|
|
|
Die Lambda-Funktion wurde gedrosselt, da es zu viele Anfragen gab. |
|
|
|
Bei der Lambda-Funktion trat eine unbehandelte Ausnahme auf. |
|
|
|
Der Load Balancer hat eine unbehandelte Ausnahme festgestellt. |
|
|
|
WebSockets werden von Lambda nicht unterstützt. |
|
Wenn der Load Balancer bei der Weiterleitung von Anfragen an einen Fehler AWS WAF feststellt, speichert er einen der folgenden Fehlercodes im Feld error_reason des Zugriffsprotokolls.
| Code | Beschreibung |
|---|---|
|
|
Der Load Balancer kann keine Verbindung zu herstellen. AWS WAF |
|
|
Bei der Verbindung wurde das AWS WAF Zeitlimit überschritten. |
|
|
Eine Anfrage zum AWS WAF Timeout. |
|
|
AWS WAF hat einen 5XX-Fehler zurückgegeben. |
|
|
Der Load Balancer hat eine unbehandelte Ausnahme festgestellt. |
Beispiel-Protokolleinträge
Es folgen beispielhafte Protokolleinträge. Beachten Sie, dass der Text nur aus Gründen der besseren Lesbarkeit auf mehrere Zeilen verteilt ist.
Beispiel für HTTP-Eintrag
Es folgt ein Beispiel für einen Protokolleintrag für einen HTTP-Listener (Port 80 zu Port 80):
http 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
192.168.131.39:2817 10.0.0.1:80 0.000 0.001 0.000 200 200 34 366
"GET http://www.example.com:80/ HTTP/1.1" "curl/7.46.0" - -
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337262-36d228ad5d99923122bbe354" "-" "-"
0 2018-07-02T22:22:48.364000Z "forward" "-" "-" "10.0.0.1:80" "200" "-" "-"Beispiel für HTTPS-Eintrag
Es folgt ein Beispiel für einen Protokolleintrag für einen HTTPS-Listener (Port 443 zu Port 80):
https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-" "10.0.0.1:80" "200" "-" "-" TID_123456Beispiel für HTTP/2-Eintrag
Es folgt ein Beispiel für einen Protokolleintrag für einen HTTP/2-Stream.
h2 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
10.0.1.252:48160 10.0.0.66:9000 0.000 0.002 0.000 200 200 5 257
"GET https://10.0.2.105:773/ HTTP/2.0" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337327-72bd00b0343d75b906739c42" "-" "-"
1 2018-07-02T22:22:48.364000Z "redirect" "https://example.com:80/" "-" "10.0.0.66:9000" "200" "-" "-"Beispiel für WebSockets einen Eintrag
Im Folgenden finden Sie ein Beispiel für einen Protokolleintrag für eine WebSockets Verbindung.
ws 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
10.0.0.140:40914 10.0.1.192:8010 0.001 0.003 0.000 101 101 218 587
"GET http://10.0.0.30:80/ HTTP/1.1" "-" - -
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337364-23a8c76965a2ef7629b185e3" "-" "-"
1 2018-07-02T22:22:48.364000Z "forward" "-" "-" "10.0.1.192:8010" "101" "-" "-"Beispiel für einen gesicherten WebSockets Eintrag
Im Folgenden finden Sie ein Beispiel für einen Protokolleintrag für eine sichere WebSockets Verbindung.
wss 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
10.0.0.140:44244 10.0.0.171:8010 0.000 0.001 0.000 101 101 218 786
"GET https://10.0.0.30:443/ HTTP/1.1" "-" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337364-23a8c76965a2ef7629b185e3" "-" "-"
1 2018-07-02T22:22:48.364000Z "forward" "-" "-" "10.0.0.171:8010" "101" "-" "-"Beispieleinträge für Lambda-Funktionen
Es folgt ein Beispiel eines Protokolleintrags für eine Anfrage an eine Lambda-Funktion, die erfolgreich war:
http 2018-11-30T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
192.168.131.39:2817 - 0.000 0.001 0.000 200 200 34 366
"GET http://www.example.com:80/ HTTP/1.1" "curl/7.46.0" - -
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337364-23a8c76965a2ef7629b185e3" "-" "-"
0 2018-11-30T22:22:48.364000Z "forward" "-" "-" "-" "-" "-" "-"Es folgt ein Beispiel eines Protokolleintrags für eine Anfrage an eine Lambda-Funktion, die fehlgeschlagen ist:
http 2018-11-30T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
192.168.131.39:2817 - 0.000 0.001 0.000 502 - 34 366
"GET http://www.example.com:80/ HTTP/1.1" "curl/7.46.0" - -
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337364-23a8c76965a2ef7629b185e3" "-" "-"
0 2018-11-30T22:22:48.364000Z "forward" "-" "LambdaInvalidResponse" "-" "-" "-" "-"Verarbeiten von Zugriffsprotokolldateien
Die Zugriffsprotokolldateien werden 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. Beispielsweise können Sie die folgenden analytischen Tools zum Analysieren und Verarbeiten von Zugriffsprotokollen verwenden:
-
Amazon Athena ist ein interaktiver Abfrageservice, der die Analyse von Daten in Amazon S3 mit Standard-SQL erleichtert. Weitere Informationen finden Sie unter Abfragen von Application-Load-Balancer-Protokollen im Benutzerhandbuch zu Amazon Athena.
