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
Wichtig
Während herkömmliche „Legacy“ -Logs (in diesem Abschnitt beschrieben) weiterhin verfügbar sind, bietet Application Load Balancer jetzt erweiterte Logging-Optionen wie CloudWatch Protokolle. CloudWatch Protokolle bieten flexiblere Lieferoptionen, auch an Amazon CloudWatch Logs, Amazon Data Firehose und Amazon Simple Storage Service. Um diese verbesserten Protokollierungsoptionen zu konfigurieren, besuchen Sie die Website Ihres Load Balancers Integrationen Tab. Für weitere Informationen über CloudWatch Protokolle finden Sie unter CloudWatch Protokolle für Ihren Application Load Balancer.
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
-
Das 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/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/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 Verwaltung des Objektlebenszyklus in der Amazon S3-Benutzerhandbuch.
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.
Jeder Logeintrag enthält die Details einer einzelnen Anfrage (oder Verbindung im Fall von WebSockets) an den Load Balancer gesendet. Für WebSockets, ein Eintrag wird erst geschrieben, 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.
Inhalt
Syntax
Die folgende Tabelle beschreibt die Felder eines Zugriffsprotokolleintrags der Reihe nach. Alle Felder werden durch Leerzeichen voneinander getrennt. Wenn wir ein neues Feld hinzufügen, fügen wir es am Ende des Logeintrags 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) |
Der Typ der Anfrage oder Verbindung. Die möglichen Werte sind wie folgt (alle anderen Werte ignorieren):
|
|
Zeit (2) |
Die Zeit, zu der der Load Balancer eine Antwort an den Client generiert hat, im Format ISO 8601. Für WebSockets, das ist die Zeit, in der die Verbindung geschlossen wird. |
|
gelb (3) |
Die Ressourcen-ID des Load Balancer. Wenn Sie Zugriffsprotokolleinträge analysieren, beachten Sie, dass Ressourcen-IDs Schrägstriche (/) enthalten können. |
|
Kunde: port (4) |
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. |
|
Ziel: port (5) |
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, dieser Wert ist auf - gesetzt. |
|
request_processing_time (6) |
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, falls keine TCP-Verbindung mit dem Ziel hergestellt werden kann, bevor der 10-Sekunden-TCP-Timeout erreicht ist. Wenn AWS WAF für Ihren Application Load Balancer aktiviert 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, darauf angerechnet |
|
angestrebte_Bearbeitungszeit (7) |
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 AWS WAF ist für Ihren Application Load Balancer nicht aktiviert, wird die Zeit, die der Client benötigt, um die erforderlichen Daten für POST-Anfragen zu senden, darauf angerechnet |
|
Bearbeitungszeit der Antwort (8) |
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 (9) |
Der Statuscode der vom Load Balancer generierten Antwort, feste Antwortregel oder AWS WAF benutzerdefinierter Antwortcode für Blockaktionen. Wenn HTTP/2 RST_STREAM-Fehler beim Weiterleiten eines Ziels |
|
target_status_code (10) |
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 –. |
|
empfangen_Bytes (11) |
Die Größe der Anforderung, in Byte, die vom Client (Auftraggeber) eingegangen ist. Bei HTTP-Anfragen sind die Header eingeschlossen. Für WebSockets, das ist die Gesamtzahl der Byte, die vom Client auf der Verbindung empfangen wurden. |
|
sendet_bytes (12) |
Die Größe der Antwort, in Byte, die an den Client (Auftraggeber) gesendet wurde. Bei HTTP-Anfragen schließt dies die Header und den Text der Antwort ein. Für WebSockets, dies ist die Gesamtzahl der Byte, die über die Verbindung an den Client gesendet wurden. Die TCP-Header und die TLS-Handshake-Nutzlast sind nicht enthalten in |
|
„Anforderungszeile“ (13) |
Die Anforderungszeile des Clients, in doppelte Anführungszeichen eingeschlossen und im folgenden Format protokolliert: 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. |
|
„Benutzeragent“ (14) |
EIN User-Agent Zeichenfolge, die den Client identifiziert, von dem die Anfrage stammt, eingeschlossen in doppelte 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 (15) |
[HTTPS-Listener] Die SSL-Verschlüsselung. Dieser Wert ist auf „-“ festgelegt, wenn es sich bei dem Listener nicht um einen HTTPS-Listener handelt. |
|
ssl_protokoll (16) |
[HTTPS-Listener] Das SSL-Protokoll. Dieser Wert ist auf „-“ festgelegt, wenn es sich bei dem Listener nicht um einen HTTPS-Listener handelt. |
|
Zielgruppe_ARN (17) |
Der Amazon-Ressourcenname (ARN) der Zielgruppe. |
|
„Trace-ID“ (18) |
Der Inhalt der X-Amzn-Trace-Id Kopfzeile, in doppelten Anführungszeichen eingeschlossen. |
|
„Domänenname“ (19) |
[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. |
|
„ausgewählt_cert_arn“ (20) |
[HTTPS-Listener] Der ARN des Zertifikats, das dem Client vorgelegt wird, in Anführungszeichen. Dieser Wert ist auf |
|
übereinstimmen_Regel_Priorität (21) |
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 -. |
|
Anforderung_Erstellungszeit (22) |
Die Uhrzeit, zu der der Load Balancer die Anforderung vom Client erhalten hat, im ISO 8601-Format. |
|
„Aktionen_ausgeführt“ (23) |
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. |
|
„Weiterleitung_URL“ (24) |
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. |
|
„Fehler_Grund“ (25) |
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. |
|
„Ziel: port_list“ (26) |
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 ist von AWS WAF, dieser Wert ist auf - gesetzt. |
|
„target_status_code_list“ (27) |
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 –. |
|
„Klassifizierung“ (28) |
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. |
|
„Grund für die Klassifizierung“ (29) |
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 (30) |
Die ID für die Rückverfolgbarkeit der Verbindung ist eindeutige undurchsichtige ID wird verwendet, um jede Verbindung zu identifizieren. Nachdem eine Verbindung mit einem Client hergestellt wurde, enthalten nachfolgende Anfragen von diesem Client diese ID in ihren jeweiligen Zugriffsprotokolleinträgen. Diese ID dient als Fremdschlüssel, um eine Verbindung zwischen der Verbindung und den Zugriffsprotokollen herzustellen. |
|
„transformed_host“ (31) |
Der Host-Header, nachdem er durch eine Transformation zum Umschreiben des Host-Headers geändert wurde. Wenn einer der folgenden Punkte zutrifft, wird dieser Wert auf - gesetzt.
|
|
„transformierte_URI“ (32) |
Der URI, nachdem er durch eine URL-Rewrite-Transformation geändert wurde. Wenn einer der folgenden Punkte zutrifft, wird dieser Wert auf - gesetzt.
|
|
„request_transform_status“ (33) |
Der Status der Rewrite-Transformation. Wenn keine Rewrite-Transformation angewendet wurde, wird dieser Wert auf - gesetzt. Andernfalls ist dieser Wert einer der Statuswerte, die unter beschrieben werden Transformieren Sie Statuscodes. |
|
ip_adresse (34) |
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. |
|
Ziel_Fehlercode (35) |
Der HTTP/2 |
|
elb_fehlercode (36) |
Das HTTP/2 |
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. -
rewrite— Der Load Balancer hat die Anforderungs-URL neu geschrieben, 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, AWS WAF entschied, dass der Antrag abgelehnt werden sollte. Standardmäßig werden Anfragen abgelehnt von AWS WAF wird als „403" im protokolliertelb_status_codeFeld. Wann AWS WAF ist so konfiguriert, dass Anfragen mit einem benutzerdefinierten Antwortcode abgelehnt werden, derelb_status_codeDas Feld wird den konfigurierten Antwortcode wiedergeben. -
waf-failed— Der Load Balancer hat versucht, die Anfrage weiterzuleiten an 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 | Description | Klassifizierung |
|---|---|---|
|
|
Der Anforderungs-URI enthält Steuerzeichen. |
Mehrdeutig |
|
|
Der Content-Length Header enthält einen Wert, der nicht analysiert werden kann, oder ist keine gültige Zahl. |
Schwerwiegend |
|
|
Ein Header enthält ein Nullzeichen oder einen Zeilenumbuch. |
Schwerwiegend |
|
|
Der Transfer-Encoding Header enthält einen schlechten 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 Anfrage enthält sowohl eine Transfer-Encoding Header und a Content-Length Kopfzeile. |
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 eine Content-Length Header mit dem Wert 0 für eine GET- oder HEAD-Anfrage. |
Akzeptabel |
|
|
Es gibt mehrere Content-Length Header mit unterschiedlichen Werten. |
Schwerwiegend |
|
|
Es gibt mehrere Transfer-Encoding: Aufgeteilte 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 normalisiert werden kann Transfer-Encoding oder Content-Length unter Verwendung gängiger Techniken zur Textnormalisierung. |
Mehrdeutig |
|
|
Die Anfrage enthält sowohl eine Transfer-Encoding Header und a Content-Length Header, wobei mindestens einer von ihnen verdächtig ist. |
Schwerwiegend |
|
|
Es gibt eine Content-Length Header, der für eine GET- oder HEAD-Anfrage definiert ist. |
Mehrdeutig |
|
|
Es gibt einen Transfer-Encoding Header, der für eine GET- oder HEAD-Anfrage definiert ist. |
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 den entsprechenden Wert CloudWatch metrisch. Weitere Informationen finden Sie unter Authentifizieren von Benutzern mithilfe eines Application Load Balancers.
| Code | Description | 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, oder der Token-Endpunkt reagiert nicht innerhalb von 5 Sekunden. |
|
|
|
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 IdP-Benutzerinfo-Endpunkt kommunizieren, oder der Endpunkt für Benutzerinformationen reagiert nicht innerhalb von 5 Sekunden. |
|
|
|
Die Größe der vom Identitätsanbieter zurückgegebenen Ansprüche übersteigt 11 K Byte. |
|
Wenn der Load Balancer eine JWT-Validierungsaktion nicht abschließen kann, speichert der Load Balancer einen der folgenden Ursachencodes im Feld error_reason des Zugriffsprotokolls. Der Load Balancer erhöht auch den entsprechenden Wert CloudWatch metrisch. Weitere Informationen finden Sie unter Überprüfen Sie JWTs mithilfe eines Application Load Balancers.
| Code | Description | Metrik |
|---|---|---|
|
|
Die Anfrage enthält keinen Autorisierungsheader. |
|
|
|
Das Token in der Anfrage ist falsch formatiert oder es fehlen obligatorische Teile (Header, Payload oder Signatur), Header enthält kein „Bearer“ -Präfix, Header enthält einen anderen Authentifizierungstyp wie „Basic“, der Autorisierungsheader ist vorhanden, aber das Token ist nicht vorhanden, wenn die Anfrage mehrere Token enthält |
|
|
|
Der Load Balancer kann nicht mit dem JWKS-Endpunkt kommunizieren, oder der JWKS-Endpunkt reagiert nicht innerhalb von 5 Sekunden. |
|
|
|
Die Größe der vom JWKS-Endpunkt zurückgegebenen Antwort übersteigt 150 KB oder die Anzahl der vom JWKS-Endpunkt zurückgegebenen Schlüssel übersteigt 10. |
|
|
|
Es gibt eine Fehlerantwort (nicht 2XX) vom JWKS-Endpunkt. |
|
|
|
Die JWKS-Antwort weist eines oder mehrere der folgenden Probleme auf: Non-JSON Format, Ungültige Zeichen, Ungültiges JWKS-Format, Missing/invalid obligatorische JWKS-Attribute, Der Algorithmus für den öffentlichen Schlüssel wird nicht unterstützt, der öffentliche Schlüssel konnte nicht in einen Dekodierungsschlüssel konvertiert werden, die Größe des öffentlichen Schlüssels betrug nicht 2 K |
|
|
|
Die Token-Signatur konnte aus irgendeinem Grund nicht validiert werden, auch wenn die Signatur nicht übereinstimmt, das Token ist mit einem nicht unterstützten Algorithmus signiert, Die KID im Token ist im JWKS-Endpunkt nicht vorhanden. |
|
|
|
JWT in der Client-Anfrage enthält keinen Anspruch, der für die Validierung erforderlich ist |
|
|
|
Das Format des Anspruchswerts im JWT entspricht nicht dem in der Konfiguration angegebenen Format |
|
|
|
Der Wert des Anspruchs im JWT ist ungültig. |
|
|
|
Der Load Balancer ist bei der Validierung des JWT in der Client-Anfrage auf einen unerwarteten Fehler gestoßen. |
|
Wenn eine Anforderung an eine gewichtete Zielgruppe fehlschlägt, speichert der Load Balancer einen der folgenden Fehlercodes im Feld „error_reason“ des Zugriffsprotokolls.
| Code | Description |
|---|---|
|
|
Das AWSALBTG-Cookie, das mit gewichteten Zielgruppen verwendet wird, ist ungü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 den entsprechenden CloudWatch metrisch. Weitere Informationen finden Sie unter der Lambda-Aktion Invoke.
| Code | Description | Metrik |
|---|---|---|
|
|
Der Load Balancer war nicht zum Aufrufen der Lambda-Funktion berechtigt. |
|
|
|
Der Lambda-Aufruf ist fehlgeschlagen, weil die Header oder der Hauptteil der Client-Anfrage nicht nur Folgendes enthielten UTF-8 Zeichen. |
|
|
|
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 beim Weiterleiten von Anfragen an einen Fehler feststellt AWS WAF, speichert es einen der folgenden Fehlercodes im Feld error_reason des Zugriffsprotokolls.
| Code | Description |
|---|---|
|
|
Der Load Balancer kann keine Verbindung herstellen zu AWS WAF. |
|
|
Die Verbindung zu AWS WAF das Zeitlimit ist abgelaufen. |
|
|
Eine Anfrage an AWS WAF eine Zeitüberschreitung. |
|
|
AWS WAF hat einen 5XX-Fehler zurückgegeben. |
|
|
Der Load Balancer hat eine unbehandelte Ausnahme festgestellt. |
Transformieren Sie Statuscodes
| Code | Description |
|---|---|
|
|
Das Umschreiben der Transformation ist fehlgeschlagen, da das Ergebnis die Größe eines internen Puffers überschritten hat. Versuchen Sie, den regulären Ausdruck weniger komplex zu gestalten. |
|
|
Die Kompilierung des regulären Ausdrucks ist fehlgeschlagen. |
|
|
Der kompilierte reguläre Ausdruck war zu groß. Versuchen Sie, den regulären Ausdruck weniger komplex zu machen. |
|
|
Die Transformation zum Umschreiben des Host-Headers ist fehlgeschlagen, da der resultierende Host nicht gültig ist. |
|
|
Die Transformation zum Umschreiben der URL ist fehlgeschlagen, da der resultierende Pfad nicht gültig ist. |
|
|
Der reguläre Ausdruck enthielt einen Syntaxfehler. |
|
|
Das Ersetzen der Transformation ist fehlgeschlagen. |
|
|
Die Neuschreibtransformation wurde erfolgreich abgeschlossen. |
Beispiel-Protokolleinträge
Es folgen beispielhafte Protokolleinträge. Beachten Sie, dass der Beispieltext nur aus Gründen der besseren Lesbarkeit in mehreren Zeilen angezeigt wird.
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" "-" "-"
TID_1234abcd5678ef90 "-" "-" "-"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_1234abcd5678ef90 "m.example.com" "-" "TransformSuccess"Beispiel HTTP/2 Eintrag
Das Folgende ist ein Beispiel für einen Protokolleintrag HTTP/2 streamen.
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" "-" "-"
TID_1234abcd5678ef90 "-" "-" "-"Beispiel WebSockets Eintrag
Das Folgende ist ein Beispiel für einen Protokolleintrag 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" "-" "-"
TID_1234abcd5678ef90 "-" "-" "-"Beispiel: Gesichert WebSockets Eintrag
Das Folgende ist ein Beispiel für einen Protokolleintrag für einen gesicherten 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" "-" "-"
TID_1234abcd5678ef90 "-" "-" "-"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" "-" "-" "-" "-" "-" "-"
TID_1234abcd5678ef90 "-" "-" "-"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" "-" "-" "-" "-"
TID_1234abcd5678ef90 "-" "-" "-"Konfigurieren 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 POST-Objekt um Protokolle an Amazon S3 zu liefern. Um sicherzustellen, dass Sie alle Benachrichtigungen zur Protokollübermittlung erhalten, sollten Sie all diese Ereignisse zur Objekterstellung in Ihre Konfiguration aufnehmen.
Weitere Informationen finden Sie unter Amazon S3-Ereignisbenachrichtigungen in der Amazon Simple Storage Service-Benutzerhandbuch.
Verarbeiten von Zugriffsprotokolldateien
Die Zugriffsprotokolldateien werden 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. 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.
