Verwenden Sie Zugriffsprotokolle in Echtzeit - Amazon CloudFront
Erstellen und verwenden Sie Konfigurationen für Echtzeit-ZugriffsprotokolleMachen Sie sich mit den Konfigurationen der Echtzeit-Zugriffsprotokolle vertrautErstellen eines Kinesis-DatenstromverbrauchersBeheben Sie Probleme mit Zugriffsprotokollen in Echtzeit

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 Zugriffsprotokolle in Echtzeit

Mit CloudFront Echtzeit-Zugriffsprotokollen können Sie Informationen über Anfragen an eine Distribution in Echtzeit abrufen (Protokolle werden innerhalb von Sekunden nach Eingang der Anfragen zugestellt). Mithilfe von Zugriffsprotokollen in Echtzeit können Sie die Leistung der Inhaltsbereitstellung überwachen, analysieren und Maßnahmen ergreifen.

CloudFront Echtzeit-Zugriffsprotokolle sind konfigurierbar. Sie können wählen:

  • Die Stichprobenrate für Ihre Echtzeitprotokolle, d. h. der Prozentsatz der Anfragen, für die Sie Zugriffsprotokolldatensätze in Echtzeit 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 Echtzeit-Zugriffsprotokolle 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 Echtzeit-Zugriffsprotokolle, 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 Zugriffsprotokolle 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 Echtzeit-Zugriffsprotokollen weggelassen wird, entspricht die Anzahl der Einträge in den Echtzeit-Zugriffsprotokollen nicht der Nutzung, die in den AWS Abrechnungs- und Nutzungsberichten angegeben ist.

Erstellen und verwenden Sie Konfigurationen für Echtzeit-Zugriffsprotokolle

Um Informationen über Anfragen an eine Distribution in Echtzeit zu erhalten, können Sie Zugriffs-Log-Konfigurationen in Echtzeit verwenden. Die Protokolle werden innerhalb von Sekunden nach Eingang der Anforderungen zugestellt. Sie können eine Konfiguration für das Echtzeit-Zugriffsprotokoll in der CloudFront Konsole, mit AWS Command Line Interface (AWS CLI) oder mit der CloudFront API erstellen.

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

Console
Um eine Konfiguration für das Echtzeit-Zugriffsprotokoll zu erstellen

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

  2. Wählen Sie die Registerkarte Echtzeitkonfigurationen aus.

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

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

  5. Geben Sie unter Abtastrate den Prozentsatz der Anforderungen ein, für die Sie Echtzeit-Protokolldatensätze erhalten möchten.

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

    • Um alle CMCD-Felder in Ihre Protokolle aufzunehmen, wählen Sie CMCD alle Schlüssel aus.

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

    Anmerkung

    CloudFront Echtzeit-Zugriffsprotokolle werden an den Datenstream übermittelt, den Sie in Kinesis Data Streams angeben. Um Ihre Echtzeit-Zugriffsprotokolle 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 unter IAM-Rolle die Option Neue Servicerolle erstellen oder eine vorhandene 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 Konfiguration des Echtzeit-Zugriffsprotokolls angehängt werden soll.

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

Bei Erfolg zeigt die Konsole die Details der Konfiguration des Echtzeit-Zugriffsprotokolls an, die Sie gerade erstellt haben.

Weitere Informationen finden Sie unter Machen Sie sich mit den Konfigurationen der Echtzeit-Zugriffsprotokolle vertraut.

AWS CLI

Verwenden Sie den aws cloudfront create-realtime-log-config Befehl, um eine Konfiguration für das AWS CLI Echtzeit-Zugriffsprotokoll 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-Zugriffsprotokollkonfiguration zu erstellen (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 Konfigurationseinstellungen für das Echtzeit-Zugriffsprotokoll anzugeben, und speichern Sie dann 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 den Konfigurationen der Echtzeit-Zugriffsprotokolle vertraut.

  3. Verwenden Sie den folgenden Befehl, um die Konfiguration des Echtzeit-Zugriffsprotokolls 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 Erfolg werden in der Ausgabe des Befehls die Details der Konfiguration des Echtzeit-Zugriffsprotokolls angezeigt, die Sie gerade erstellt haben.

Um eine Echtzeit-Zugriffsprotokollkonfiguration an eine bestehende Distribution anzuhängen (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 und nehmen Sie die folgenden Änderungen an jedem Cache-Verhalten vor, das Sie aktualisieren, um eine Konfiguration für das Echtzeit-Zugriffsprotokoll zu verwenden.

    • Fügen Sie in der Cache-Verhaltensweise ein Feld mit dem Namen RealtimeLogConfigArn hinzu. Verwenden Sie für den Feldwert den ARN der Echtzeit-Zugriffs-Log-Konfiguration, 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 sie die Konfiguration des Echtzeit-Zugriffsprotokolls verwendet. 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 CloudFront API-Vorgang, um eine Konfiguration für das Echtzeit-Zugriffsprotokoll mit der CreateRealtimeLogConfigAPI zu erstellen. Weitere Informationen zu den Parametern, die Sie in diesem API-Aufruf angeben, finden Machen Sie sich mit den Konfigurationen der Echtzeit-Zugriffsprotokolle vertraut Sie in der API-Referenzdokumentation für Ihr AWS SDK oder einen anderen API-Client.

Nachdem Sie eine Konfiguration für das Echtzeit-Zugriffsprotokoll 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-Zugriffsprotokollkonfiguration vor RealtimeLogConfigArn Ort innerhalb eines Cache-Verhaltens an. Weitere Informationen zu den anderen Feldern, die Sie in diesen API-Aufrufen angeben, finden Sie in Referenz für alle Distributionseinstellungen und in der API-Referenzdokumentation für Ihr AWS SDK oder einen anderen API-Client.

Machen Sie sich mit den Konfigurationen der Echtzeit-Zugriffsprotokolle vertraut

Um CloudFront Echtzeit-Zugriffsprotokolle zu verwenden, erstellen Sie zunächst eine Konfiguration für Echtzeit-Zugriffsprotokolle. Die Konfiguration des Echtzeit-Zugriffsprotokolls enthält Informationen darüber, welche Protokollfelder Sie empfangen möchten, die Samplingrate für Protokolldatensätze und den Kinesis-Datenstream, an den Sie die Protokolle übermitteln möchten.

Insbesondere enthält eine Konfiguration für das Echtzeit-Zugriffsprotokoll die folgenden Einstellungen:

Name

Ein Name zur Identifizierung der Konfiguration des Echtzeit-Zugriffsprotokolls.

Abtastrate

Die Samplingrate ist eine ganze Zahl zwischen 1 und 100 (einschließlich), die den Prozentsatz der Zuschaueranfragen bestimmt, die als Echtzeit-Zugriffsprotokolldatensätze an Kinesis Data Streams gesendet werden. Um jede Zuschaueranfrage in Ihre Echtzeit-Zugriffsprotokolle aufzunehmen, geben Sie 100 als Samplingrate an. Sie können eine niedrigere Samplerate wählen, um die Kosten zu senken und gleichzeitig eine repräsentative Stichprobe von Anforderungsdaten in Ihren Echtzeit-Zugriffsprotokollen zu erhalten.

Felder

Eine Liste der Felder, die in jedem Datensatz des Echtzeit-Zugriffsprotokolls 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.

Bei den Feldern 46-63 handelt es sich um Common Media Client Data (CMCD), an die Media Player-Clients CDNs bei jeder Anfrage senden können. Sie können mithilfe dieser Daten jede Anforderung besser verstehen, z. B. den Medientyp (Audio, Video), die Wiedergabegeschwindigkeit und die Streaming-Länge. Diese Felder erscheinen nur dann in Ihren Echtzeit-Zugriffsprotokollen, 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, https, 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.

    • LambdaExecutionError— Die der Distribution zugeordnete Lambda @Edge -Funktion wurde aufgrund einer fehlerhaften Zuordnung, eines Funktionstimeouts, eines AWS Abhängigkeitsproblems oder eines anderen allgemeinen Verfügbarkeitsproblems nicht abgeschlossen.

  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 für die Anfrage HTTPS verwendet wurde, enthält dieses Feld das SSL/TLS Protokoll, das der Betrachter und der Server für die Übertragung der Anfrage und Antwort ausgehandelt haben. Eine Liste der möglichen Werte finden Sie unter den unterstützten SSL/TLS ProtokollenUnterstützte Protokolle und Chiffren zwischen Zuschauern und CloudFront.

  25. ssl-cipher

    Wenn für die Anfrage HTTPS verwendet wurde, enthält dieses Feld die SSL/TLS Chiffre, die der Betrachter und der Server für die Verschlüsselung der Anfrage und Antwort ausgehandelt haben. Eine Liste der möglichen Werte finden Sie unter den unterstützten SSL/TLS Verschlüsselungen. 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.

    • LambdaExecutionError— Die der Distribution zugeordnete Lambda @Edge -Funktion wurde aufgrund einer fehlerhaften Zuordnung, eines Funktionstimeouts, eines AWS Abhängigkeitsproblems oder eines anderen allgemeinen Verfügbarkeitsproblems nicht abgeschlossen.

  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 die kontinuierliche Bereitstellung 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.

  47. CMCD-Felder in Echtzeit-Zugriffsprotokollen

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

  48. cmcd-encoded-bitrate

    Die kodierte Bitrate des angeforderten Audio- oder Videoobjekts.

  49. cmcd-buffer-length

    Die Pufferlänge des angeforderten Medienobjekts.

  50. cmcd-buffer-starvation

    Ob der Puffer irgendwann zwischen der vorherigen Anforderung und der Objektanforderung verbraucht wurde. Dies kann dazu führen, dass sich der Player in einem Neupufferungsstatus befindet, was die Video- oder Audiowiedergabe stoppen kann.

  51. cmcd-content-id

    Eine eindeutige Zeichenfolge, die den aktuellen Inhalt identifiziert.

  52. cmcd-object-duration

    Die Wiedergabedauer des angeforderten Objekts (in Millisekunden).

  53. cmcd-deadline

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

  54. cmcd-measured-throughput

    Der vom Client gemessene Durchsatz zwischen Client und Server.

  55. cmcd-next-object-request

    Der relative Pfad des nächsten angeforderten Objekts.

  56. cmcd-next-range-request

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

  57. cmcd-object-type

    Der Medientyp des aktuell angeforderten Objekts.

  58. cmcd-playback-rate

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

  59. cmcd-requested-maximum-throughput

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

  60. cmcd-streaming-format

    Das Streaming-Format, das die aktuelle Anforderung definiert.

  61. cmcd-session-id

    Eine GUID, die die aktuelle Wiedergabesitzung identifiziert.

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

  63. cmcd-startup

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

  64. cmcd-top-bitrate

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

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

  66. r-host

    Dieses Feld wird für Ursprungsanforderungen gesendet und gibt die Domain des Ursprungsservers an, der für die Bereitstellung des Objekts verwendet wird. Wenn Fehler auftreten, können Sie dieses Feld verwenden, um den Ursprung des letzten Verbindungsversuchs zu finden, zum Beispiel: cd8jhdejh6a.mediapackagev2.us-east-1.amazonaws.com.

  67. sr-reason

    Dieses Feld gibt einen Grund an, warum der Ursprung ausgewählt wurde. Es ist leer, wenn eine Anforderung 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. Failover:403 oder Failover:502. Wenn im Fall eines Ursprungs-Failovers auch die wiederholte Anforderung fehlschlägt und Sie keine benutzerdefinierten Fehlerseiten konfiguriert haben, zeigt r-status die Antwort des zweiten Ursprungs an. Wenn Sie jedoch bei der Konfiguration des Ursprungs-Failovers benutzerdefinierte Fehlerseiten konfiguriert haben, enthält dieses Feld die Antwort des zweiten Ursprungs, wenn die Anforderung fehlgeschlagen ist und stattdessen eine benutzerdefinierte Fehlerseite zurückgegeben wurde.

    Wenn kein Ursprungs-Failover, sondern eine Auswahl des Ursprungs anhand von Media Quality-Aware Resilience (MQAR) erfolgt, wird dies als MediaQuality protokolliert. Weitere Informationen finden Sie unter Media Quality-Aware Resiliency.

  68. 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 Media Quality-Aware Resiliency.

  69. distribution-tenant-id

    Die ID des Distributionsmandanten.

  70. connection-id

    Eine eindeutige Kennung für die TLS-Verbindung.

    Sie müssen mTLS für Ihre Distributionen aktivieren, bevor Sie Informationen für dieses Feld abrufen können. Weitere Informationen finden Sie unter Mutual TLS (mTLS) -Viewer.

Endpunkt (Kinesis Data Streams)

Der Endpunkt enthält Informationen über die Kinesis-Datenströme, an die Sie Echtzeit-Protokolle senden möchten. Sie stellen den Amazon-Ressourcennamen (ARN) des Streams oder der Funktion bereit.

Weitere Informationen zum Erstellen eines Kinesis-Datenstroms finden Sie in den folgenden Themen im Entwicklerhandbuch für Amazon Kinesis Data Streams.

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. Ermitteln Sie die typische Größe eines einzelnen Echtzeit-Zugriffsprotokolldatensatzes.

    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 Anforderungen (Datensätze) pro Sekunde ein.

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

    • Wählen Sie dann Berechnungen anzeigen aus.

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

IAM role (IAM-Rolle)

Die AWS Identity and Access Management (IAM-) Rolle, die die CloudFront Erlaubnis erteilt, Echtzeit-Zugriffsprotokolle für Ihren Kinesis-Datenstream bereitzustellen.

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

Wenn Sie eine Echtzeit-Zugriffsprotokollkonfiguration 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.

JSON
{
    "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.

JSON
{
    "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.

JSON
{
    "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"
            ]
        }
    ]
}

Erstellen eines Kinesis-Datenstromverbrauchers

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

Stellen Sie sich beispielsweise eine Konfiguration für ein Echtzeit-Zugriffsprotokoll vor, die nur diese drei Felder enthält: time-to-first-bytesc-status, undc-country. In diesem Szenario ist das letzte Feld, c-country, immer Feld Nummer 3 in jedem Protokolldatensatz. Wenn Sie jedoch später Felder zur Konfiguration des Echtzeit-Zugriffsprotokolls hinzufügen, kann sich die Platzierung der einzelnen Felder in einem Datensatz ändern.

Wenn Sie beispielsweise die Felder sc-bytes und time-taken zur Konfiguration des Echtzeit-Zugriffsprotokolls hinzufügen, werden diese Felder in jeden Protokolldatensatz in der im Felder Abschnitt angegebenen Reihenfolge 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, deren Position in einem Protokolldatensatz geändert wird, falls Sie Felder zu Ihrer Konfiguration für das Echtzeit-Zugriffsprotokoll hinzufügen.

Beheben Sie Probleme mit Zugriffsprotokollen in Echtzeit

Nachdem Sie eine Konfiguration für das Echtzeit-Zugriffsprotokoll 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

Um Echtzeit-Zugriffsprotokolldatensätze für Ihren Kinesis-Datenstrom bereitzustellen, CloudFront verwendet die IAM-Rolle in der Konfiguration des Echtzeit-Zugriffsprotokolls. Stellen Sie sicher, dass die Rollen-Vertrauensrichtlinie und die Rollen-Berechtigungsrichtlinie mit den in angezeigten Richtlinien übereinstimme IAM role (IAM-Rolle).

Kinesis Data Streams-Drosselung

Wenn Echtzeit-Zugriffsprotokolldatensä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.