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 dem AWS Command Line Interface (AWS CLI) oder mit dem erstellen CloudFront API.

Um eine Echtzeit-Protokollkonfiguration zu verwenden, fügen Sie sie einem oder mehreren Cache-Verhalten in einer CloudFront Distribution hinzu.

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 unterhttps://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 CMCDFelder für Ihre Protokolle einzubeziehen, wählen Sie CMCDAlle Schlüssel 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 IAMals Rolle die Option Neue Servicerolle erstellen oder wählen Sie eine bestehende Rolle aus. Sie benötigen die Berechtigung, IAM Rollen zu erstellen.

  9. (Optional) Wählen Sie unter 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.

Um eine Echtzeit-Protokollkonfiguration (CLImit Eingabedatei) zu erstellen

  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.

Um eine Echtzeit-Protokollkonfiguration an eine bestehende Distribution anzuhängen (CLImit Eingabedatei)

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

    
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 Feldwert die Konfiguration ARN des Echtzeitprotokolls, die Sie diesem Cache-Verhalten zuordnen 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 distribution_ID mit der ID der Distribution.

    
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 CreateRealtimeLogConfigAPIVorgang CloudFront API, um eine Echtzeit-Protokollkonfiguration mit dem zu erstellen. Weitere Informationen zu den Parametern, die Sie in diesem API Aufruf angeben, finden Sie unter Machen Sie sich mit Echtzeit-Protokollkonfigurationen vertraut und in der API Referenzdokumentation für Ihren 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 beide API Operationen die ARN 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 Ihren 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 allgemeine Medienclient-Daten (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 Betrachter zum Senden der Anfrage einen HTTP Proxy oder einen Load Balancer verwendet hat, entspricht der Wert dieses Felds der IP-Adresse des Proxys oder Load Balancers. Siehe auch das Feld x-forwarded-for.

  3. s-ip

    Die IP-Adresse des CloudFront Servers, der die Anfrage bearbeitet hat, 192.0.2.183 z. B. oder. 2001: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

    Der HTTP Statuscode der Serverantwort (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. Bei WebSocket Verbindungen ist dies die Gesamtzahl der Byte, die über die Verbindung vom Server an den Client gesendet wurden.

  7. cs-method

    Die vom Viewer empfangene HTTP Anforderungsmethode.

  8. cs-protocol

    Das Protokoll der Viewer-Anforderung (http, https, 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 AnfrageURL, einschließlich der Abfragezeichenfolge (falls vorhanden), jedoch ohne den Domainnamen. 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. Bei WebSocket Verbindungen ist dies die Gesamtzahl der Byte, die über die Verbindung vom Client an den Server 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 (z. B.DFW3) identifiziert. Der aus drei Buchstaben bestehende Code entspricht in der Regel dem Flughafencode der International Air Transport Association (IATA) für einen Flughafen in der Nähe der geografischen Lage des Randstandorts. (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 Sicht des Betrachters wird die Gesamtzeit bis zum Erhalt der vollständigen Antwort aufgrund von Netzwerklatenz und Pufferung länger als dieser Wert sein. TCP

  16. cs-protocol-version

    Die HTTP Version, die der Betrachter 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 (IPv4oderIPv6).

  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 Anfrage mit der AbfragezeichenfolgeURL, falls 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 Viewer HTTPS gemäß den Verteilungseinstellungen von HTTP zu umgeleitet.

  23. x-forwarded-for

    Wenn der Viewer zum Senden der Anfrage einen HTTP Proxy oder einen Load Balancer verwendet hat, entspricht der Wert des c-ip Felds 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 verwendet HTTPS wurde, 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 verwendet wurdeHTTPS, 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.

    Nehmen wir zum Beispiel beim HTTP Streaming an, dass der Server ein Segment des Streams im Cache findet. 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 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 Statuscode HTTP 503 zurückgegeben, weil er zum Zeitpunkt der Anfrage nicht über genügend Kapazität verfügte, um das Objekt zu bedienen.

    • 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 sc-status Felds ist 200 oder wenn der Wert dieses Felds ist Error und der Wert des x-edge-response-result-type Felds nichtError, bedeutet dies, dass die HTTP Anfrage erfolgreich war, der Client jedoch die Verbindung unterbrochen hat, bevor er alle Bytes empfangen hat.

    • Redirect— Der Server hat den Viewer HTTPS gemäß den Verteilungseinstellungen von HTTP zu 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 Anfrage zurückgewiesen und dem Viewer den Statuscode HTTP 400 zurückgegeben, da der Wert des Content-Type Headers ein ungültiges Format hatte.

    • MalformedInputClientError— Der Server lehnte die Anfrage ab und gab einen HTTP 400-Statuscode an den Viewer zurück, da der Anfragetext ein ungültiges Format hatte.

    • MalformedQueryArgsClientError— Der Server hat die Anfrage zurückgewiesen und dem Viewer den Statuscode HTTP 400 zurückgegeben, weil ein Abfrageargument leer war oder ein ungültiges Format hatte.

    • RejectedByContentType— Der Server lehnte die Anfrage ab und gab einen HTTP 400-Statuscode an den Viewer zurück, da in der Konfiguration für die Verschlüsselung auf Feldebene kein Inhaltstyp angegeben wurde.

    • RejectedByQueryArgs— Der Server lehnte die Anfrage ab und gab einen HTTP 400-Statuscode an den Viewer zurück, 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 ein Verschlüsselungskontingent auf Feldebene (früher als Limit bezeichnet) überschreitet, enthält dieses Feld einen der folgenden Fehlercodes, und der Server gibt den HTTP Statuscode 400 an den Viewer 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 Startwert des Bereichs.

  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 TLS ZertifikatSSL/überein, für das die HTTPS Verbindung hergestellt wurde.

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

      • InvalidRequestMethod— Die Distribution ist nicht für die 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. Eine Liste der Ländercodes finden Sie unter ISO3166-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-Anfrage.

    Anmerkung

    Dieses Feld wird auf 800 Bytes abgeschnitten.

  40. cs-header-names

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

    Anmerkung

    Dieses Feld wird auf 800 Bytes abgeschnitten.

  41. cs-headers-count

    Die Anzahl der HTTP Header in der Viewer-Anfrage.

  42. origin-fbl

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

  43. origin-lbl

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

  44. asn

    Die autonome Systemnummer (ASN) des Viewers.

  45. primary-distribution-id

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

  46. 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).

    CMCDFelder in Echtzeitprotokollen

    Weitere Informationen zu diesen Feldern finden Sie im Dokument CTASpecification 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 Client und 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 erachtet.

  59. cmcd-streaming-format

    Das Streaming-Format, das die aktuelle Anfrage definiert.

  60. cmcd-session-id

    Eine GUID Identifizierung der aktuellen Wiedergabesitzung.

  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.

Endpunkt (Kinesis Data Streams)

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

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 Anfragen pro Sekunde, die Ihre CloudFront Distribution 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 Pricing CalculatorJetzt 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.

IAMRolle

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

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 dem CloudFront API (AWS CLI oderSDK) erstellen, müssen Sie die IAM Rolle selbst erstellen und die Rolle angebenARN. Verwenden Sie die folgenden Richtlinien, um die IAM Rolle selbst zu erstellen.

IAM- Rollenvertrauensrichtlinie

Um die folgende IAM Rollenvertrauensrichtlinie zu verwenden, ersetzen Sie 111122223333 mit Ihrer AWS-Konto Nummer. Das Condition Element in dieser Richtlinie trägt dazu bei, das Problem des verwirrten Stellvertreters zu vermeiden, da diese Rolle nur im Namen einer Verteilung in Ihrem Unternehmen übernommen werden CloudFront kann AWS-Konto.

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

IAMRichtlinie für Rollenberechtigungen für einen unverschlüsselten Datenstrom

Um die folgende Richtlinie zu verwenden, ersetzen Sie arn:aws:kinesis:us-east-2:123456789012:stream/StreamName mit dem 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"
            ]
        }
    ]
}

IAMRichtlinie für Rollenberechtigungen für einen verschlüsselten Datenstrom

Um die folgende Richtlinie zu verwenden, ersetzen Sie arn:aws:kinesis:us-east-2:123456789012:stream/StreamName mit dem ARN Ihres Kinesis-Datenstroms und arn:aws:kms:us-east-2:123456789012:key/e58a3d0b-fe4f-4047-a495-ae03cc73d486 mit dem ARN von dir 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 Distribution Zuschaueranfragen erhält. Wenn dies der Fall ist, können Sie die folgende Einstellung überprüfen, um die Fehlerbehebung fortzusetzen.

IAMRollenberechtigungen

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

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.