Verwenden Sie Echtzeit-Logs - Amazon CloudFront
Erstellen und verwenden Sie Echtzeit-ProtokollkonfigurationenMachen Sie sich mit Echtzeit-Protokollkonfigurationen vertrautEinen Kinesis Data Streams Streams-Consumer erstellenBeheben Sie Probleme mit Echtzeitprotokollen

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.

Verwenden Sie Echtzeit-Logs

Mit CloudFront Echtzeitprotokollen können Sie Informationen über Anfragen an eine Distribution in Echtzeit abrufen (Protokolle werden innerhalb von Sekunden nach Eingang der Anfragen zugestellt). Sie können Echtzeitprotokolle verwenden, um basierend auf der Leistung der Bereitstellung von Inhalten Überwachungsaktionen und Analysen auszuführen und Maßnahmen zu ergreifen.

CloudFront Echtzeitprotokolle sind konfigurierbar. Sie können wählen:

  • Die Abtastrate für Ihre Echtzeit-Protokolle – d. h. der Prozentsatz der Anforderungen, für die Sie Echtzeit-Protokolldatensätze erhalten möchten.

  • Die spezifischen Felder, die Sie in den Protokolldatensätzen empfangen möchten.

  • Das spezifische Cache-Verhalten (Pfadmuster), für das Sie Echtzeit-Protokolle erhalten möchten.

CloudFront Echtzeitprotokolle werden an den Datenstream Ihrer Wahl in Amazon Kinesis Data Streams übermittelt. Sie können Ihren eigenen Kinesis Data Stream Consumer erstellen oder Amazon Data Firehose verwenden, um die Protokolldaten an Amazon Simple Storage Service (Amazon S3), Amazon Redshift, Amazon OpenSearch Service (Service) oder einen OpenSearch Protokollverarbeitungsservice eines Drittanbieters zu senden.

CloudFront Gebühren für Echtzeitprotokolle, zusätzlich zu den Gebühren, die Ihnen für die Nutzung von Kinesis Data Streams entstehen. Weitere Informationen zu den Preisen finden Sie unter CloudFront Amazon-Preise und Amazon Kinesis Data Streams-Preise.

Wichtig

Wir empfehlen Ihnen, die Protokolle zu verwenden, um die Art der Anfragen nach Ihren Inhalten zu verstehen, und nicht, um alle Anfragen vollständig zu erfassen. CloudFront liefert Protokolle in Echtzeit nach bestem Wissen und Gewissen. Der Protokolleintrag für eine bestimmte Anfrage wird möglicherweise viel später übermittelt, als die Anfrage tatsächlich verarbeitet wurde; in seltenen Fällen kann es auch sein, dass ein Protokolleintrag gar nicht übermittelt wird. Wenn ein Protokolleintrag in den Echtzeitprotokollen weggelassen wird, entspricht die Anzahl der Einträge in den Echtzeitprotokollen nicht der Nutzung, die in den AWS Abrechnungs- und Nutzungsberichten angegeben ist.

Erstellen und verwenden Sie Echtzeit-Protokollkonfigurationen

Um Informationen über Anfragen an eine Distribution in Echtzeit zu erhalten, können Sie Protokollkonfigurationen in Echtzeit verwenden. Protokolle werden innerhalb von Sekunden nach Eingang der Anfragen zugestellt. Sie können eine Echtzeit-Protokollkonfiguration in der CloudFront Konsole, mit der AWS Command Line Interface (AWS CLI) oder mit der CloudFront API erstellen.

Um eine Echtzeit-Protokollkonfiguration zu verwenden, hängen Sie sie an ein oder mehrere Cache-Verhaltensweisen in einer CloudFront Distribution an.

Console
Um eine Echtzeit-Protokollkonfiguration zu erstellen

  1. Melden Sie sich bei der an AWS Management Console und öffnen Sie die Seite Logs in der CloudFront Konsole unterhttp://console.aws.amazon.com/cloudfront/v4/home?#/logs.

  2. Wählen Sie den Tab Echtzeitkonfigurationen.

  3. Wählen Sie Create configuration (Konfiguration erstellen).

  4. Geben Sie unter Name einen Namen für die Konfiguration ein.

  5. Geben Sie unter Samplingrate den Prozentsatz der Anfragen ein, für die Sie Protokolldatensätze erhalten möchten.

  6. Wählen Sie unter Felder die Felder aus, die Sie in den Echtzeitprotokollen erhalten möchten.

    • Um alle CMCD-Felder in Ihre Logs aufzunehmen, wählen Sie CMCD all keys aus.

  7. Wählen Sie für Endpoint einen oder mehrere Kinesis-Datenstreams aus, um Echtzeitprotokolle zu erhalten.

    Anmerkung

    CloudFront Echtzeitprotokolle werden an den Datenstrom übermittelt, den Sie in Kinesis Data Streams angeben. Um Ihre Echtzeit-Logs zu lesen und zu analysieren, können Sie Ihren eigenen Kinesis Data Stream Consumer erstellen. Sie können Firehose auch verwenden, um die Protokolldaten an Amazon S3, Amazon Redshift, Amazon OpenSearch Service oder einen Protokollverarbeitungsdienst eines Drittanbieters zu senden.

  8. Wählen Sie für die IAM-Rolle die Option Neue Servicerolle erstellen oder wählen Sie eine bestehende Rolle aus. Sie müssen über die Berechtigung zum Erstellen von IAM-Rollen verfügen.

  9. (Optional) Wählen Sie für CloudFrontVerteilung ein Verteilungs- und Cache-Verhalten aus, das an die Echtzeit-Protokollkonfiguration angehängt werden soll.

  10. Wählen Sie Create configuration (Konfiguration erstellen).

Bei erfolgreicher Ausführung zeigt die Konsole die Details der soeben erstellten Echtzeit-Protokollkonfiguration an.

Weitere Informationen finden Sie unter Machen Sie sich mit Echtzeit-Protokollkonfigurationen vertraut.

AWS CLI

Verwenden Sie den aws cloudfront create-realtime-log-config Befehl AWS CLI, um eine Echtzeit-Protokollkonfiguration mit dem zu erstellen. Sie können die Eingabeparameter des Befehls in einer Eingabedatei bereitstellen, anstatt jeden einzelnen Parameter als Befehlszeileneingabe anzugeben.

So erstellen Sie eine Echtzeit-Protokollkonfiguration (CLI mit Eingabedatei):

  1. Verwenden Sie den folgenden Befehl, um eine Datei mit dem Namen rtl-config.yaml zu erstellen, die alle Eingabeparameter für den create-realtime-log-config-Befehl enthält.

    
aws cloudfront create-realtime-log-config --generate-cli-skeleton yaml-input > rtl-config.yaml

  2. Öffnen Sie die Datei mit dem Namen rtl-config.yaml, die Sie gerade erstellt haben. Bearbeiten Sie die Datei, um die gewünschten Einstellungen für die Echtzeit-Protokollkonfiguration anzugeben, und speichern Sie die Datei. Beachten Sie Folgendes:

    • Für StreamType ist der einzige gültige Wert Kinesis.

    Weitere Informationen zu den Echtzeit-Konfigurationseinstellungen im Langformat finden Sie unter Machen Sie sich mit Echtzeit-Protokollkonfigurationen vertraut.

  3. Verwenden Sie den folgenden Befehl, um die Echtzeit-Protokollkonfiguration mithilfe von Eingabeparametern aus der rtl-config.yaml-Datei zu erstellen.

    
aws cloudfront create-realtime-log-config --cli-input-yaml file://rtl-config.yaml

Bei erfolgreicher Ausführung zeigt die Ausgabe des Befehls die Details der soeben erstellten Echtzeit-Protokollkonfiguration an.

So fügen Sie eine Echtzeit-Protokollkonfiguration an eine vorhandene Verteilung an (CLI mit Eingabedatei):

  1. Verwenden Sie den folgenden Befehl, um die Verteilungskonfiguration für die CloudFront Distribution zu speichern, die Sie aktualisieren möchten. Ersetzen Sie distribution_ID durch die ID der Verteilung.

    
aws cloudfront get-distribution-config --id distribution_ID --output yaml > dist-config.yaml

  2. Öffnen Sie die Datei mit dem Namen dist-config.yaml, die Sie gerade erstellt haben. Bearbeiten Sie die Datei, indem Sie die folgenden Änderungen an jeder Cache-Verhaltensweise vornehmen, die Sie aktualisieren, um eine Echtzeit-Protokollkonfiguration zu verwenden.

    • Fügen Sie in der Cache-Verhaltensweise ein Feld mit dem Namen hinz RealtimeLogConfigArn. Verwenden Sie für den Wert des Feldes den ARN der Echtzeit-Protokollkonfiguration, die Sie dieser Cache-Verhaltensweise anfügen möchten.

    • Benennen Sie das Feld ETag in IfMatch um, ändern Sie jedoch nicht den Wert des Feldes.

    Speichern Sie die Datei, wenn Sie fertig sind.

  3. Verwenden Sie den folgenden Befehl, um die Verteilung so zu aktualisieren, dass die Echtzeit-Protokollkonfiguration verwendet wird. Ersetzen Sie distribution_ID durch die ID der Verteilung.

    
aws cloudfront update-distribution --id distribution_ID --cli-input-yaml file://dist-config.yaml

Wenn dies erfolgreich ist, zeigt die Ausgabe des Befehls die Details der gerade aktualisierten Verteilung an.

API

Verwenden Sie den API-Vorgang, um eine Echtzeit-Protokollkonfiguration mit der CloudFront CreateRealtimeLogConfigAPI zu erstellen. Weitere Informationen zu den Parametern, die Sie in diesem API-Aufruf angeben, finden Sie in Machen Sie sich mit Echtzeit-Protokollkonfigurationen vertraut und in der API-Referenzdokumentation für Ihr AWS SDK oder einen anderen API-Client.

Nachdem Sie eine Echtzeit-Protokollkonfiguration erstellt haben, können Sie sie mithilfe einer der folgenden API-Operationen an ein Cache-Verhalten anhängen:

  • Um es an ein Cache-Verhalten in einer vorhandenen Distribution anzuhängen, verwenden Sie UpdateDistribution.

  • Um es an ein Cache-Verhalten in einer neuen Distribution anzuhängen, verwenden Sie CreateDistribution.

Geben Sie für diese beiden API-Operationen den ARN der Echtzeit-Protokollkonfiguration vor RealtimeLogConfigArn Ort innerhalb eines Cache-Verhaltens an. Weitere Informationen zu den anderen Feldern, die Sie in diesen API-Aufrufen angeben, finden Referenz zu Verteilungseinstellungen Sie in der API-Referenzdokumentation für Ihr AWS SDK oder einen anderen API-Client.

Machen Sie sich mit Echtzeit-Protokollkonfigurationen vertraut

Um CloudFront Echtzeitprotokolle zu verwenden, erstellen Sie zunächst eine Echtzeit-Protokollkonfiguration. Die Echtzeit-Protokollkonfiguration enthält Informationen darüber, welche Protokollfelder Sie empfangen möchten, die Abtastrate für Protokolldatensätze und den Kinesis-Datenstrom, in den Sie die Protokolle bereitstellen möchten.

Insbesondere enthält eine Echtzeit-Protokollkonfiguration die folgenden Einstellungen:

Name

Ein Name zur Identifizierung der Echtzeit-Protokollkonfiguration.

Abtastrate

Die Abtastrate ist eine ganze Zahl zwischen 1 und 100 (einschließlich), die den Prozentsatz der Viewer-Anfragen bestimmt, die an Kinesis Data Streams als Echtzeit-Protokolldatensätze gesendet werden. Um jede Viewer-Anforderung in Ihre Echtzeit-Protokolle aufzunehmen, geben Sie 100 für die Abtastrate an. Sie können eine niedrigere Abtastrate wählen, um die Kosten zu senken, während Sie dennoch eine repräsentative Stichprobe von Anforderungsdaten in Ihren Echtzeit-Protokollen erhalten.

Felder

Eine Liste der Felder, die in jedem Echtzeit-Protokolldatensatz enthalten sind. Jeder Protokolldatensatz kann bis zu 40 Felder enthalten und Sie können auswählen, ob alle verfügbaren Felder empfangen werden, oder nur die Felder, die Sie für die Überwachung und Analyse der Leistung benötigen.

Die folgende Liste enthält jeden Feldnamen und eine Beschreibung der Informationen in diesem Feld. Die Felder werden in der Reihenfolge aufgelistet, in der sie in den Protokolldatensätzen angezeigt werden, die an Kinesis Data Streams übermittelt werden.

Die Felder 46-63 sind Common Media Client Data (CMCD), an die Media Player-Clients CDNs bei jeder Anfrage senden können. Sie können diese Daten verwenden, um jede Anfrage zu verstehen, z. B. den Medientyp (Audio, Video), die Wiedergabegeschwindigkeit und die Streaming-Länge. Diese Felder erscheinen nur dann in Ihren Echtzeitprotokollen, wenn sie an gesendet werden CloudFront.

  1. timestamp

    Die Angabe zu Datum und Uhrzeit, an der der Edge-Server die Reaktion auf die Anforderung abgeschlossen hat.

  2. c-ip

    Die IP-Adresse des Betrachters, die der Anfrage gestellt hat, z. B. 192.0.2.183 oder 2001:0db8:85a3::8a2e:0370:7334. Wenn der Viewer einen HTTP-Proxy oder eine Load Balancer verwendet hat, um die Anforderung zu senden, entspricht der Wert dieses Feldes der IP-Adresse des Proxys bzw. des Load Balancers. Siehe auch das Feld x-forwarded-for.

  3. s-ip

    Die IP-Adresse des CloudFront Servers, der die Anfrage bearbeitet hat, z. B. 192.0.2.183 oder2001:0db8:85a3::8a2e:0370:7334.

  4. time-to-first-byte

    Die Anzahl der Sekunden zwischen dem Empfangen der Anforderung und dem Schreiben des ersten Bytes der Antwort, gemessen auf dem Server.

  5. sc-status

    Den HTTP-Statuscode der Antwort des Servers (z. B. 200).

  6. sc-bytes

    Die Gesamtzahl der Bytes, die der Server als Antwort auf die Anforderung an den Viewer übermittelt hat, einschließlich Headern. Für WebSocket und gRPC-Verbindungen ist dies die Gesamtzahl der Byte, die vom Server über die Verbindung an den Client gesendet werden.

  7. cs-method

    Die vom Viewer empfangene HTTP-Anforderungsmethode.

  8. cs-protocol

    Das Protokoll der Viewer-Anforderung (http, http, grpcs, ws oder wss).

  9. cs-host

    Der Wert, den der Viewer in den Host-Header der Anforderung eingefügt hat. Wenn Sie den CloudFront Domainnamen in Ihrem Objekt verwenden URLs (z. B. d111111abcdef8.cloudfront.net), enthält dieses Feld diesen Domainnamen. Wenn Sie alternative Domainnamen (CNAMEs) in Ihrem Objekt verwenden URLs (z. B. www.example.com), enthält dieses Feld den alternativen Domainnamen.

  10. cs-uri-stem

    Die gesamte Anforderungs-URL, einschließlich der Abfragezeichenfolge (falls vorhanden), jedoch ohne den Domänennamen. Beispiel, /images/cat.jpg?mobile=true.

    Anmerkung

    In Standardprotokollen enthält der cs-uri-stem-Wert nicht die Abfragezeichenfolge.

  11. cs-bytes

    Die Gesamtzahl der Bytes an Daten, die in der Anforderung des Viewers einschließlich Headern enthalten sind. Für WebSocket und gRPC-Verbindungen ist dies die Gesamtzahl der Byte, die vom Client an den Server über die Verbindung gesendet wurden.

  12. x-edge-location

    Der Edge-Standort, an dem die Anfrage verarbeitet wurde. Jeder Edge-Standort wird durch einen aus drei Buchstaben bestehenden Code und eine willkürlich zugewiesene Zahl identifiziert (z. B.). DFW3 Der Code aus drei Buchstaben entspricht in der Regel dem Code der International Air Transport Association (IATA) für einen Flughafen in der Nähe des Edge-Standorts. (Diese Abkürzungen ändern sich möglicherweise in der Zukunft.)

  13. x-edge-request-id

    Eine undurchsichtige Zeichenfolge, die eine Anfrage eindeutig identifiziert. CloudFront sendet diese Zeichenfolge auch im x-amz-cf-id Antwort-Header.

  14. x-host-header

    Der Domainname der CloudFront Distribution (z. B. d111111abcdef8.cloudfront.net).

  15. time-taken

    Die Anzahl der Sekunden (auf die Tausendstelsekunde genau, z. B. 0,082) ab dem Zeitpunkt, an dem der Server die Anforderung des Viewers empfängt, bis zu dem Zeitpunkt, an dem der Server das letzte Byte der Antwort in die Ausgabewarteschlange schreibt, wie auf dem Server gemessen. Aus der Perspektive der Viewers vergeht bis zum Empfang der gesamten Antwort aufgrund der Netzwerklatenz und des TCP-Puffervorgangs insgesamt mehr Zeit, als mit diesem Wert angegeben wird.

  16. cs-protocol-version

    Die HTTP-Version, die der Viewer in der Anfrage angegeben hat: Mögliche Werte sind HTTP/0.9, HTTP/1.0, HTTP/1.1, HTTP/2.0 und HTTP/3.0.

  17. c-ip-version

    Die IP-Version der Anfrage (oder). IPv4 IPv6

  18. cs-user-agent

    Der Wert für den User-Agent-Header in der Anfrage. Der User-Agent-Header bezeichnet die Quelle für die Anforderung, z. B. den Gerätetyp und den Browser, der die Anforderung abgesendet hat, oder die Suchmaschine, wenn die Anforderung von einer Suchmaschine stammt.

  19. cs-referer

    Der Wert für den Referer-Header in der Anfrage. Der Name der Domäne, von der die Anforderung ausgegangen ist. Häufig vorkommende Referrer sind Suchmaschinen, andere Websites, die direkt auf Ihre Objekte verlinken, und Ihre eigene Website.

  20. cs-cookie

    Der Cookie-Header in der Anforderung einschließlich der Name-Wert-Paaren und zugehörigen Attributen.

    Anmerkung

    Dieses Feld wird auf 800 Bytes abgeschnitten.

  21. cs-uri-query

    Der Teil der Anforderungs-URL mit der Abfragezeichenfolge, wenn vorhanden.

  22. x-edge-response-result-type

    Die Art, wie der Server die Antwort direkt vor der Rücksendung der Antwort an den Viewer klassifiziert hat. Siehe auch das Feld x-edge-result-type. Mögliche Werte sind:

    • Hit – Der Server hat das Objekt aus dem Cache für den Betrachter bereitgestellt.

    • RefreshHit – Der Server hat das Objekt im Edge-Zwischenspeicher gefunden, es war jedoch abgelaufen. Daher nahm der Server Kontakt mit dem Ursprung auf, um zu überprüfen, ob der Zwischenspeicher die neueste Version des Objekts enthalten hatte.

    • Miss – Die Anforderung konnte nicht durch ein Objekt im Zwischenspeicher bedient werden. Daher hat der Server die Anforderung an den Ursprungs-Server weitergeleitet und das Ergebnis an den Betrachter ausgegeben.

    • LimitExceeded— Die Anfrage wurde abgelehnt, weil ein CloudFront Kontingent (früher als Limit bezeichnet) überschritten wurde.

    • CapacityExceeded – Der Server hat den Fehler 503 zurückgegeben, da er zum Zeitpunkt der Anforderung nicht über genügend Kapazitäten verfügte, um das Objekt bereitzustellen.

    • Error – In der Regel bedeutet dies, dass die Anforderung zu einem Client-Fehler (d. h. der Wert des Felds sc-status liegt im 4xx-Bereich) oder zu einem Serverfehler geführt hat (d. h. der Wert des Felds sc-status liegt im 5xx-Bereich).

      Wenn der Wert des Felds x-edge-result-type Error ist und der Wert dieses Felds nicht Error ist, wurde die Verbindung vor dem Abschluss des Downloads durch den Client getrennt.

    • Redirect – Der Server hat den Betrachter entsprechend den Verteilungseinstellungen von HTTP zu HTTPS umgeleitet.

  23. x-forwarded-for

    Wenn der Viewer einen HTTP-Proxy oder Load Balancer verwendet hat, um die Anforderung zu senden, entspricht der Wert des Felds c-ip der IP-Adresse des Proxys oder Load Balancers. In diesem Fall stellt dieses Feld die IP-Adresse des Viewers dar, von dem die Anfrage stammt. Dieses Feld kann mehrere durch Kommas getrennte IP-Adressen enthalten. Jede IP-Adresse kann eine IPv4 Adresse (zum Beispiel192.0.2.183) oder eine IPv6 Adresse (zum Beispiel) sein. 2001:0db8:85a3::8a2e:0370:7334

  24. ssl-protocol

    Wenn die Anfrage HTTPS verwendet hat, enthält dieses Feld die SSL/TLS protocol that the viewer and server negotiated for transmitting the request and response. For a list of possible values, see the supported SSL/TLS Protokolle inUnterstützte Protokolle und Chiffren zwischen Zuschauern und CloudFront.

  25. ssl-cipher

    Wenn die Anfrage HTTPS verwendet hat, enthält dieses Feld die SSL/TLS cipher that the viewer and server negotiated for encrypting the request and response. For a list of possible values, see the supported SSL/TLS Chiffren in. Unterstützte Protokolle und Chiffren zwischen Zuschauern und CloudFront

  26. x-edge-result-type

    Art der Klassifizierung der Antwort durch den Server, nachdem das letzte Byte den Server verlassen hat. Manchmal wird der Ergebnistyp zwischen dem Zeitpunkt, an dem Server zum Senden der Antwort bereit ist, und dem Zeitpunkt, an dem er das Senden der Antwort abgeschlossen hat, geändert. Siehe auch das Feld x-edge-response-result-type.

    Angenommen, im HTTP-Streaming findet der Server ein Segment des Streams im Cache. In diesem Szenario würde der Wert dieses Feldes normalerweise sei Hit. Wenn der Viewer jedoch die Verbindung schließt, bevor der Server das ganze Segment übermittelt hat, ist der endgültige Ergebnistyp (und damit der Wert dieses Felds) Error.

    WebSocket und gRPC-Verbindungen haben Miss für dieses Feld den Wert von, da der Inhalt nicht zwischengespeichert werden kann und direkt an den Ursprung weitergeleitet wird.

    Mögliche Werte sind:

    • Hit – Der Server hat das Objekt aus dem Cache für den Betrachter bereitgestellt.

    • RefreshHit – Der Server hat das Objekt im Edge-Zwischenspeicher gefunden, es war jedoch abgelaufen. Daher nahm der Server Kontakt mit dem Ursprung auf, um zu überprüfen, ob der Zwischenspeicher die neueste Version des Objekts enthalten hatte.

    • Miss – Die Anforderung konnte nicht durch ein Objekt im Zwischenspeicher bedient werden. Daher hat der Server die Anforderung an den Ursprung weitergeleitet und das Ergebnis an den Betrachter ausgegeben.

    • LimitExceeded— Die Anfrage wurde abgelehnt, weil ein CloudFront Kontingent (früher als Limit bezeichnet) überschritten wurde.

    • CapacityExceeded – Der Server hat den HTTP-Statuscode 503 zurückgegeben, da er zum Zeitpunkt der Anforderung nicht über genügend Kapazitäten für die Bereitstellung des Objekts verfügte.

    • Error – In der Regel bedeutet dies, dass die Anforderung zu einem Client-Fehler (d. h. der Wert des Felds sc-status liegt im 4xx-Bereich) oder zu einem Serverfehler geführt hat (d. h. der Wert des Felds sc-status liegt im 5xx-Bereich). Wenn der Wert des Felds sc-status 200 oder wenn der Wert dieses Felds Error ist und der Wert des Felds x-edge-response-result-type nicht Error ist, war die HTTP-Anforderung erfolgreich. Die Client-Verbindung wurde jedoch getrennt, bevor alle Bytes empfangen wurden.

    • Redirect – Der Server hat den Betrachter entsprechend den Verteilungseinstellungen von HTTP zu HTTPS umgeleitet.

  27. fle-encrypted-fields

    Die Anzahl der Felder für die Verschlüsselung auf Feldebene, die der Server verschlüsselt und an den Ursprung weitergeleitet hat. CloudFront Server streamen die verarbeitete Anfrage an den Ursprung, während sie Daten verschlüsseln, sodass dieses Feld auch dann einen Wert haben kann, wenn der Wert von ein Fehler fle-status ist.

  28. fle-status

    Wenn die Verschlüsselung auf Feldebene für eine Verteilung konfiguriert ist, enthält dieses Feld einen Code, der angibt, ob der Anforderungstext erfolgreich verarbeitet wurde. Wenn der Server den Anforderungstext erfolgreich verarbeitet, Werte in den angegebenen Feldern verschlüsselt und die Anforderung an den Ursprung weiterleitet, ist der Wert dieses Felds Processed. Der Wert von x-edge-result-type kann in diesem Fall immer noch auf einen clientseitigen oder serverseitigen Fehler hinweisen.

    Mögliche Werte für dieses Feld sind:

    • ForwardedByContentType – Der Server hat die Anforderung ohne Parsing oder Verschlüsselung an den Ursprung weitergeleitet, da kein Content-Typ konfiguriert wurde.

    • ForwardedByQueryArgs – Der Server hat die Anforderung ohne Parsing oder Verschlüsselung an den Ursprung weitergeleitet, da die Anforderung ein Abfrageargument enthält, das nicht in der Konfiguration für die Verschlüsselung auf Feldebene enthalten war.

    • ForwardedDueToNoProfile – Der Server hat die Anforderung ohne Parsing oder Verschlüsselung an den Ursprung weitergeleitet, da in der Konfiguration für die Verschlüsselung auf Feldebene kein Profil angegeben wurde.

    • MalformedContentTypeClientError – Der Server hat die Anforderung zurückgewiesen und einen HTTP-400-Statuscode an den Betrachter zurückgegeben, da der Wert des Content-Type-Headers ein ungültiges Format hatte.

    • MalformedInputClientError – Der Server hat die Anforderung zurückgewiesen und einen HTTP 400-Statuscode an den Betrachter zurückgegeben, da der Anforderungstext ein ungültiges Format hatte.

    • MalformedQueryArgsClientError – Der Server hat die Anforderung zurückgewiesen und einen HTTP-400-Statuscode an den Betrachter zurückgegeben, weil ein Abfrageargument leer war oder ein ungültiges Format hatte.

    • RejectedByContentType – Der Server hat die Anforderung zurückgewiesen und einen HTTP-400-Statuscode an den Betrachter zurückgegeben, da in der Konfiguration für die Verschlüsselung auf Feldebene kein Content-Typ angegeben wurde.

    • RejectedByQueryArgs – Der Server hat die Anforderung zurückgewiesen und einen HTTP-400-Statuscode an den Betrachter zurückgegeben, da in der Konfiguration für die Verschlüsselung auf Feldebene kein Abfrageargument angegeben wurde.

    • ServerError – Der Ursprungs-Server hat einen Fehler zurückgegeben.

    Wenn die Anforderung das Kontingent für die Verschlüsselung auf Feldebene überschreitet (früher als Limit bezeichnet), enthält dieses Feld einen der folgenden Fehlercodes und der Server gibt dem Viewer den HTTP-Statuscode 400 zurück. Eine Liste der aktuellen Kontingente für die Verschlüsselung auf Feldebene finden Sie unter Kontingente für Verschlüsselung auf Feldebene.

    • FieldLengthLimitClientError – Ein Feld, das für die Verschlüsselung konfiguriert ist, hat die maximal zulässige Länge überschritten.

    • FieldNumberLimitClientError – Eine Anforderung, die die Verteilung verschlüsseln soll, enthält mehr Felder als zulässig.

    • RequestLengthLimitClientError – Die Länge des Anfragetexts hat die maximal zulässige Länge, wenn die Verschlüsselung auf Feldebene konfiguriert ist, überschritten.

  29. sc-content-type

    Der Wert des HTTP Content-Type-Headers der Antwort.

  30. sc-content-len

    Der Wert des HTTP Content-Length-Headers der Antwort.

  31. sc-range-start

    Wenn die Antwort den HTTP Content-Range-Header enthält, enthält dieses Feld den Bereichsstartwert.

  32. sc-range-end

    Wenn die Antwort den HTTP Content-Range-Header enthält, enthält dieses Feld den Bereichsendwert.

  33. c-port

    Die Portnummer der Anforderung des Viewers.

  34. x-edge-detailed-result-type

    Dieses Feld enthält den gleichen Wert wie der Wert für das x-edge-result-type-Feld, außer in den folgenden Fällen:

    • Wenn das Objekt dem Viewer aus der Origin-Shield-Ebene bereitgestellt wurde, enthält dieses Feld OriginShieldHit.

    • Wenn sich das Objekt nicht im CloudFront Cache befand und die Antwort von einer Lambda @Edge -Funktion für die ursprüngliche Anfrage generiert wurde, enthält MissGeneratedResponse dieses Feld.

    • Wenn der Wert des x-edge-result-type-Felds Error lautet, enthält dieses Feld einen der folgenden Werte mit weiteren Informationen zum Fehler:

      • AbortedOrigin – Der Server hat ein Problem mit dem Ursprung festgestellt.

      • ClientCommError – Die Antwort auf den Betrachter wurde aufgrund eines Kommunikationsproblems zwischen dem Server und dem Betrachter unterbrochen.

      • ClientGeoBlocked – Die Verteilung ist so konfiguriert, dass Anforderungen vom geografischen Standort des Viewers abgelehnt werden.

      • ClientHungUpRequest — Der Betrachter wurde beim Senden der Anfrage vorzeitig gestoppt.

      • Error – Es ist ein Fehler aufgetreten, dessen Fehlertyp zu keiner der anderen Kategorien passt. Dieser Fehlertyp kann auftreten, wenn der Server eine Fehlerantwort aus dem Cache ausgibt.

      • InvalidRequest – Der Server hat eine ungültige Anforderung vom Betrachter erhalten.

      • InvalidRequestBlocked — Der Zugriff auf die angeforderte Ressource ist blockiert.

      • InvalidRequestCertificate – Die Verteilung stimmt nicht mit dem SSL/TLS-Zertifikat überein, für das die HTTPS-Verbindung hergestellt wurde.

      • InvalidRequestHeader – Die Anforderung enthielt einen ungültigen Header.

      • InvalidRequestMethod — Die Verteilung ist nicht für eine Verarbeitung der verwendeten HTTP-Anforderungsmethode konfiguriert. Dies kann vorkommen, wenn die Verteilung nur Anforderungen unterstützt, die zwischengespeichert werden können.

      • OriginCommError – Bei der Anforderung ist eine Zeitüberschreitung aufgetreten, während eine Verbindung mit dem Ursprung hergestellt wurde oder Daten aus dem Ursprung gelesen wurden.

      • OriginConnectError – Der Server konnte keine Verbindung zum Ursprung herstellen.

      • OriginContentRangeLengthError – Der Content-Length-Header in der Antwort des Ursprungs stimmt nicht mit der Länge im Content-Range-Header überein.

      • OriginDnsError – Der Server konnte den Domänennamen des Ursprungs nicht auflösen.

      • OriginError — Der Ursprung gab eine falsche Antwort zurück.

      • OriginHeaderTooBigError – Ein vom Ursprung zurückgegebener Header ist für eine Verarbeitung durch den Edge-Server zu groß.

      • OriginInvalidResponseError — Der Ursprung gab eine ungültige Antwort zurück.

      • OriginReadError – Der Server konnte nicht vom Ursprung lesen.

      • OriginWriteError – Der Server konnte nicht in den Ursprung schreiben.

      • OriginZeroSizeObjectError — Ein Nullgrößenobjekt, das vom Ursprung gesendet wurde, führte zu einem Fehler.

      • SlowReaderOriginError — Der Betrachter hat die Nachricht, die den Ursprungsfehler verursacht hat, nur langsam gelesen.

  35. c-country

    Ein Ländercode, der den geografischen Standort des Viewers darstellt, der von der IP-Adresse des Viewers festgelegt wird. Die Liste der Ländercodes finden Sie unter ISO 3166-1 alpha-2.

  36. cs-accept-encoding

    Der Wert für den Accept-Encoding-Header in der Viewer-Anforderung.

  37. cs-accept

    Der Wert für den Accept-Header in der Viewer-Anforderung.

  38. cache-behavior-path-pattern

    Das Pfadmuster, das das Cache-Verhalten identifiziert, das der Viewer-Anforderung entspricht.

  39. cs-headers

    Die HTTP-Header (Namen und Werte) in der Viewer-Anforderung.

    Anmerkung

    Dieses Feld wird auf 800 Bytes abgeschnitten.

  40. cs-header-names

    Die Namen der HTTP-Header (keine Werte) in der Viewer-Anforderung.

    Anmerkung

    Dieses Feld wird auf 800 Bytes abgeschnitten.

  41. cs-headers-count

    Die Anzahl der HTTP-Header in der Viewer-Anforderung.

  42. primary-distribution-id

    Wenn Continuous Deployment aktiviert ist, identifiziert diese ID, welche Distribution in der aktuellen Distribution die primäre ist.

  43. primary-distribution-dns-name

    Wenn Continuous Deployment aktiviert ist, zeigt dieser Wert den primären Domainnamen an, der sich auf die aktuelle CloudFront Distribution bezieht (z. B. d111111abcdef8.cloudfront.net).

  44. origin-fbl

    Die Anzahl der Sekunden der First-Byte-Latenz zwischen und Ihrem Ursprung. CloudFront

  45. origin-lbl

    Die Anzahl der Sekunden der Latenz im letzten Byte zwischen CloudFront und Ihrem Ursprung.

  46. asn

    Die autonome Systemnummer (ASN) des Viewers.

    CMCD-Felder in Echtzeitprotokollen

    Weitere Informationen zu diesen Feldern finden Sie im Dokument CTA Specification Web Application Video Ecosystem — Common Media Client Data CTA-5004.

  47. cmcd-encoded-bitrate

    Die kodierte Bitrate des angeforderten Audio- oder Videoobjekts.

  48. cmcd-buffer-length

    Die Pufferlänge des angeforderten Medienobjekts.

  49. cmcd-buffer-starvation

    Ob der Puffer irgendwann zwischen der vorherigen Anforderung und der Objektanforderung ausgelaugt wurde. Dies kann dazu führen, dass sich der Player in einem Pufferstatus befindet, was die Video- oder Audiowiedergabe zum Erliegen bringen kann.

  50. cmcd-content-id

    Eine eindeutige Zeichenfolge, die den aktuellen Inhalt identifiziert.

  51. cmcd-object-duration

    Die Wiedergabedauer des angeforderten Objekts (in Millisekunden).

  52. cmcd-deadline

    Der Stichtag ab dem Zeitpunkt der Anforderung, zu dem das erste Beispiel dieses Objekts verfügbar sein muss, damit ein Unterlauf des Puffers oder andere Wiedergabeprobleme vermieden werden.

  53. cmcd-measured-throughput

    Der vom Client gemessene Durchsatz zwischen dem Client und dem Server.

  54. cmcd-next-object-request

    Der relative Pfad des nächsten angeforderten Objekts.

  55. cmcd-next-range-request

    Wenn es sich bei der nächsten Anfrage um eine teilweise Objektanforderung handelt, gibt diese Zeichenfolge den Bytebereich an, der angefordert werden soll.

  56. cmcd-object-type

    Der Medientyp des aktuell angeforderten Objekts.

  57. cmcd-playback-rate

    1 bei Echtzeit, 2 bei doppelter Geschwindigkeit, 0 bei Nichtwiedergabe.

  58. cmcd-requested-maximum-throughput

    Der angeforderte maximale Durchsatz, den der Kunde für die Bereitstellung von Ressourcen für ausreichend hält.

  59. cmcd-streaming-format

    Das Streaming-Format, das die aktuelle Anfrage definiert.

  60. cmcd-session-id

    Eine GUID, die die aktuelle Wiedergabesitzung identifiziert.

  61. cmcd-stream-type

    Token, das die Verfügbarkeit von Segmenten identifiziert. v= alle Segmente sind verfügbar. l= Segmente werden im Laufe der Zeit verfügbar.

  62. cmcd-startup

    Der Schlüssel wird ohne Wert angegeben, wenn das Objekt beim Start, bei der Suche oder bei der Wiederherstellung nach einem Ereignis, bei dem der Puffer leer ist, dringend benötigt wird.

  63. cmcd-top-bitrate

    Die Wiedergabeversion mit der höchsten Bitrate, die der Client abspielen kann.

  64. cmcd-version

    Die Version dieser Spezifikation, die für die Interpretation der definierten Schlüsselnamen und Werte verwendet wird. Wenn dieser Schlüssel weggelassen wird, müssen der Client und der Server die Werte so interpretieren, als ob sie in Version 1 definiert sind.

  65. r-host

    Dieses Feld wird für ursprüngliche Anfragen gesendet und gibt die Domäne des Ursprungsservers an, der für die Bereitstellung des Objekts verwendet wird. Im Fehlerfall können Sie dieses Feld verwenden, um den letzten Quellserver zu finden, der versucht wurde, zum Beispiel:cd8jhdejh6a.mediapackagev2.us-east-1.amazonaws.com.

  66. sr-reason

    Dieses Feld gibt einen Grund an, warum der Ursprung ausgewählt wurde. Es ist leer, wenn eine Anfrage an den primären Ursprung erfolgreich ist.

    Wenn ein Ursprungs-Failover auftritt, enthält das Feld den HTTP-Fehlercode, der zum Failover geführt hat, z. B. oder. Failover:403 Failover:502 Wenn im Fall eines ursprünglichen Failovers auch die wiederholte Anfrage fehlschlägt und Sie keine benutzerdefinierten Fehlerseiten konfiguriert haben, wird die Antwort des r-status zweiten Ursprungs angezeigt. Wenn Sie jedoch benutzerdefinierte Fehlerseiten zusammen mit dem ursprünglichen Failover konfiguriert haben, enthält dies die Antwort des zweiten Ursprungs, falls die Anfrage fehlgeschlagen ist und stattdessen eine benutzerdefinierte Fehlerseite zurückgegeben wurde.

    Wenn kein Ursprungs-Failover, sondern eine Auswahl des Ursprungs (Media Quality-Aware Resilience, MQAR) erfolgt, wird dies protokolliert als. MediaQuality Weitere Informationen finden Sie unter Resilienz im Hinblick auf Medienqualität.

  67. x-edge-mqcs

    Dieses Feld gibt den Media Quality Confidence Score (MQCS) (Bereich: 0 — 100) für Mediensegmente an, die in den CMSD-Antwort-Headern von v2 CloudFront abgerufen wurden. MediaPackage Dieses Feld ist für Anfragen verfügbar, die einem Cache-Verhalten entsprechen, das über eine MQAR-fähige Ursprungsgruppe verfügt. CloudFront protokolliert dieses Feld für Mediensegmente, die zusätzlich zu den ursprünglichen Anfragen auch aus dem Cache bedient werden. Weitere Informationen finden Sie unter Resilienz im Hinblick auf Medienqualität.

Endpunkt (Kinesis Data Streams)

Der Endpunkt enthält Informationen zu den Kinesis Data Streams, an die Sie Echtzeitprotokolle senden möchten. Sie stellen den Amazon-Ressourcennamen (ARN) des Streams oder der Funktion bereit.

Weitere Informationen zum Erstellen von Kinesis Data Streams finden Sie in den folgenden Themen im Amazon Kinesis Data Streams Developer Guide.

Wenn Sie einen Datensteam erstellen, müssen Sie die Anzahl der Shards angeben. Verwenden Sie die folgenden Informationen, um die Anzahl der benötigten Shards zu schätzen.

So schätzen Sie die Anzahl der Shards für Ihren Kinesis-Datenstream:

  1. Berechnen (oder schätzen) Sie die Anzahl der Anforderungen pro Sekunde, die Ihre CloudFront-Verteilung erhält.

    Sie können die CloudFrontNutzungsberichte (in der CloudFront Konsole) und die CloudFront Metriken (in den CloudWatch Konsolen CloudFront und Amazon) verwenden, um Ihre Anfragen pro Sekunde zu berechnen.

  2. Bestimmen Sie die typische Größe eines einzelnen Echtzeit-Protokolldatensatzes.

    Im Allgemeinen ist ein einzelner Protokolldatensatz etwa 500 Byte groß. Ein typischer Datensatz, der alle verfügbaren Felder enthält, ist in der Regel etwa 1 KB groß.

    Wenn Sie Ihre Protokoll-Datensatzgröße nicht genau kennen, können Sie Echtzeitprotokolle mit einer niedrigen Abtastrate (z. B. 1 %) aktivieren und dann die durchschnittliche Datensatzgröße anhand von Überwachungsdaten in Kinesis Data Streams berechnen (Gesamtzahl der eingehenden Bytes dividiert durch die Gesamtzahl der Datensätze).

  3. Wählen Sie auf der Preisseite für Amazon Kinesis Data Streams unter AWS -PreisrechnerJetzt Ihren individuellen Kostenvoranschlag erstellen aus.

    • Geben Sie im Rechner die Anzahl der Anfragen (Datensätze) pro Sekunde ein.

    • Geben Sie die durchschnittliche Datensatzgröße eines einzelnen Protokolldatensatzes ein.

    • Wählen Sie Berechnungen anzeigen.

    Der Preisrechner zeigt Ihnen die Anzahl der benötigten Shards und die geschätzten Kosten.

IAM-Rolle

Die AWS Identity and Access Management (IAM-) Rolle, die die CloudFront Erlaubnis erteilt, Echtzeitprotokolle an Ihren Kinesis-Datenstrom zu übermitteln.

Wenn Sie mit der CloudFront Konsole eine Echtzeit-Protokollkonfiguration erstellen, können Sie Neue Servicerolle erstellen wählen, damit die Konsole die IAM-Rolle für Sie erstellt.

Wenn Sie eine Echtzeit-Protokollkonfiguration mit AWS CloudFormation oder der CloudFront API (AWS CLI oder dem SDK) erstellen, müssen Sie die IAM-Rolle selbst erstellen und den Rollen-ARN angeben. Verwenden Sie die folgenden Richtlinien, um die IAM-Rolle selbst zu erstellen:

IAM-Rollen-Vertrauensrichtlinie

Um die folgende Vertrauensrichtlinie für IAM-Rollen zu verwenden, 111122223333 ersetzen Sie sie durch Ihre AWS-Konto Nummer. Das Condition Element in dieser Richtlinie trägt dazu bei, das Problem des verwirrten Stellvertreters zu vermeiden, da CloudFront Sie diese Rolle nur im Namen einer Abteilung in Ihrem AWS-Konto Unternehmen übernehmen können.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "111122223333"
                }
            }
        }
    ]
}

IAM-Rollen-Berechtigungsrichtlinie für einen unverschlüsselten Daten-Stream

Um die folgende Richtlinie zu verwenden, arn:aws:kinesis:us-east-2:123456789012:stream/StreamName ersetzen Sie sie durch den ARN Ihres Kinesis-Datenstroms.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kinesis:DescribeStreamSummary",
                "kinesis:DescribeStream",
                "kinesis:PutRecord",
                "kinesis:PutRecords"
            ],
            "Resource": [
                "arn:aws:kinesis:us-east-2:123456789012:stream/StreamName"
            ]
        }
    ]
}

IAM-Rollen-Berechtigungsrichtlinie für einen verschlüsselten Daten-Stream

Um die folgende Richtlinie zu verwenden, arn:aws:kinesis:us-east-2:123456789012:stream/StreamName ersetzen Sie sie durch den ARN Ihres Kinesis-Datenstreams und arn:aws:kms:us-east-2:123456789012:key/e58a3d0b-fe4f-4047-a495-ae03cc73d486 durch den ARN Ihres AWS KMS key.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kinesis:DescribeStreamSummary",
                "kinesis:DescribeStream",
                "kinesis:PutRecord",
                "kinesis:PutRecords"
            ],
            "Resource": [
                "arn:aws:kinesis:us-east-2:123456789012:stream/StreamName"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "kms:GenerateDataKey"
            ],
            "Resource": [
                "arn:aws:kms:us-east-2:123456789012:key/e58a3d0b-fe4f-4047-a495-ae03cc73d486"
            ]
        }
    ]
}

Einen Kinesis Data Streams Streams-Consumer erstellen

Um Ihre Echtzeit-Protokolle zu lesen und zu analysieren, erstellen oder verwenden Sie einen Kinesis Data Streams--Verbraucher. Wenn Sie einen Consumer für CloudFront Echtzeit-Logs erstellen, ist es wichtig zu wissen, dass die Felder in jedem Echtzeit-Protokolldatensatz immer in der gleichen Reihenfolge übermittelt werden, wie im Felder Abschnitt aufgeführt. Stellen Sie sicher, dass Sie Ihren Verbraucher für diese feste Reihenfolge erstellen.

Betrachten Sie beispielsweise eine Echtzeit-Protokollkonfiguration, die nur die folgenden drei Felder enthält: time-to-first-byte, sc-status und c-country. In diesem Szenario ist das letzte Feld, c-country, immer Feld Nummer 3 in jedem Protokolldatensatz. Wenn Sie der Echtzeit-Protokollkonfiguration jedoch später Felder hinzufügen, kann sich die Platzierung jedes Feldes in einem Datensatz ändern.

Wenn Sie beispielsweise die Felder sc-bytes und time-taken zur Echtzeit-Protokollkonfiguration hinzufügen, werden diese Felder entsprechend der im Felder-Abschnitt angezeigten Reihenfolge in jeden Protokolldatensatz eingefügt. Die resultierende Reihenfolge aller fünf Felder lautet dann time-to-first-byte, sc-status, sc-bytes, time-taken und c-country. Das Feld c-countryhatte ursprünglich die Feldnummer 3, hat jetzt jedoch Feldnummer 5. Stellen Sie sicher, dass Ihre Verbraucheranwendung Felder verarbeiten kann, die die Position in einem Protokolldatensatz ändern, falls Sie Felder zu Ihrer Echtzeit-Protokollkonfiguration hinzufügen.

Beheben Sie Probleme mit Echtzeitprotokollen

Nachdem Sie eine Echtzeit-Protokollkonfiguration erstellt haben, stellen Sie möglicherweise fest, dass keine Datensätze (oder nicht alle Datensätze) an Kinesis Data Streams übermittelt werden. In diesem Fall sollten Sie zunächst überprüfen, ob Ihre CloudFront -Verteilung Viewer-Anforderungen empfängt. Wenn dies der Fall ist, können Sie die folgende Einstellung überprüfen, um die Fehlerbehebung fortzusetzen.

IAM-Rollenberechtigungen

CloudFront Verwendet die IAM-Rolle in der Echtzeit-Protokollkonfiguration, um Echtzeit-Protokolldatensätze für Ihren Kinesis-Datenstrom bereitzustellen. Stellen Sie sicher, dass die Rollen-Vertrauensrichtlinie und die Rollen-Berechtigungsrichtlinie mit den in angezeigten Richtlinien übereinstimme IAM-Rolle.

Kinesis Data Streams-Drosselung

Wenn Echtzeit-Protokolldatensätze schneller in Ihren Kinesis-Datenstream CloudFront geschrieben werden, als der Stream verarbeiten kann, drosselt Kinesis Data Streams möglicherweise die Anfragen von. CloudFront In diesem Fall können Sie die Anzahl der Shards in Ihrem Kinesis-Datenstream erhöhen. Jeder Shard unterstützt Schreibvorgänge von bis zu 1.000 Datensätzen pro Sekunde bis zu einem maximalen Datenschreibvolumen von 1 MB pro Sekunde.