Utilisez des journaux en temps réel - Amazon CloudFront
Création et utilisation de configurations de journaux en temps réelComprendre les configurations des journaux en temps réelCréez un client Kinesis Data StreamsRésolution des problèmes liés aux journaux en temps réel

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisez des journaux en temps réel

Avec les journaux CloudFront en temps réel, vous pouvez obtenir des informations sur les demandes adressées à une distribution en temps réel (les journaux sont livrés quelques secondes après réception des demandes). Vous pouvez utiliser des journaux en temps réel pour surveiller, analyser et prendre des mesures en fonction de la performance de diffusion de contenu.

CloudFront les journaux en temps réel sont configurables. Vous pouvez choisir :

  • Vous pouvez choisir le taux d'échantillonnage des journaux en temps réel, c'est-à-dire le pourcentage de demandes pour lesquelles vous souhaitez recevoir des journaux en temps réel.

  • Champs spécifiques que vous souhaitez recevoir dans les enregistrements de journal.

  • Comportements de cache spécifiques (modèles de chemin) pour lesquels vous souhaitez recevoir des journaux en temps réel.

CloudFront les journaux en temps réel sont transmis au flux de données de votre choix dans Amazon Kinesis Data Streams. Vous pouvez créer votre propre consommateur de flux de données Kinesis ou utiliser Amazon Data Firehose pour envoyer les données de journal à Amazon Simple Storage Service (Amazon S3), Amazon Redshift, OpenSearch Amazon Service OpenSearch (Service) ou à un service de traitement des journaux tiers.

CloudFront des frais pour les journaux en temps réel, en plus des frais que vous devez payer pour utiliser Kinesis Data Streams. Pour plus d'informations sur les tarifs, consultez les rubriques Amazon CloudFront Pricing et Amazon Kinesis Data Streams.

Important

Nous vous recommandons d'utiliser les journaux pour comprendre la nature des demandes concernant votre contenu, et non comme un compte rendu complet de toutes les demandes. CloudFront fournit des journaux en temps réel dans les meilleures conditions. L’entrée du journal pour une demande particulière peut être fournie bien après le traitement réel de la demande et, dans de rares cas, une entrée du journal peut ne pas être fournie du tout. Lorsqu'une entrée de journal est omise dans les journaux en temps réel, le nombre d'entrées dans les journaux en temps réel ne correspond pas à l'utilisation indiquée dans les rapports AWS de facturation et d'utilisation.

Création et utilisation de configurations de journaux en temps réel

Pour obtenir des informations sur les demandes adressées à une distribution en temps réel, vous pouvez utiliser une configuration de journal en temps réel. Les journaux sont livrés dans les secondes qui suivent la réception des demandes. Vous pouvez créer une configuration de journal en temps réel dans la CloudFront console, avec le AWS Command Line Interface (AWS CLI) ou avec le CloudFront API.

Pour utiliser une configuration de journal en temps réel, vous devez l'associer à un ou plusieurs comportements de cache dans une CloudFront distribution.

Console
Pour créer une configuration de journal en temps réel

  1. Connectez-vous à la page Logs AWS Management Console et ouvrez-la dans la CloudFront console à l'adressehttps://console.aws.amazon.com/cloudfront/v4/home?#/logs.

  2. Choisissez l'onglet Configurations en temps réel.

  3. Choisissez Create configuration (Créer une configuration).

  4. Dans Nom, entrez le nom de la configuration.

  5. Pour Taux d'échantillonnage, entrez le pourcentage de demandes pour lesquelles vous souhaitez recevoir des enregistrements de journal.

  6. Pour les champs, choisissez les champs à recevoir dans les journaux en temps réel.

    • Pour inclure tous les CMCDchamps de vos journaux, choisissez CMCDtoutes les clés.

  7. Pour Endpoint, choisissez un ou plusieurs flux de données Kinesis pour recevoir des journaux en temps réel.

    Note

    CloudFront les journaux en temps réel sont transmis au flux de données que vous spécifiez dans Kinesis Data Streams. Pour lire et analyser vos journaux en temps réel, vous pouvez créer votre propre consommateur de flux de données Kinesis. Vous pouvez également utiliser Firehose pour envoyer les données du journal à Amazon S3, Amazon Redshift, Amazon Service ou à un service de traitement des journaux tiers. OpenSearch

  8. Pour IAMle rôle, choisissez Créer un nouveau rôle de service ou choisissez un rôle existant. Vous devez être autorisé à créer des IAM rôles.

  9. (Facultatif) Pour Distribution, choisissez un comportement CloudFront de distribution et de cache à associer à la configuration du journal en temps réel.

  10. Choisissez Create configuration (Créer une configuration).

En cas de réussite, la console affiche les détails de la configuration du journal en temps réel que vous venez de créer.

Pour de plus amples informations, veuillez consulter Comprendre les configurations des journaux en temps réel.

AWS CLI

Pour créer une configuration de journal en temps réel avec le AWS CLI, utilisez la aws cloudfront create-realtime-log-config commande. Vous pouvez utiliser un fichier d'entrée pour fournir les paramètres d'entrée de la commande, plutôt que de spécifier chaque paramètre individuel comme entrée de ligne de commande.

Pour créer une configuration de journal en temps réel (CLIavec fichier d'entrée)

  1. Utilisez la commande suivante pour créer un fichier nommé rtl-config.yaml qui contient tous les paramètres d’entrée de la commande create-realtime-log-config.

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

  2. Ouvrez le fichier nommé rtl-config.yaml que vous venez de créer. Modifiez le fichier pour spécifier les paramètres de configuration du journal en temps réel que vous souhaitez, puis enregistrez le fichier. Remarques :

    • Pour StreamType, la seule valeur valide est Kinesis.

    Pour de plus amples informations sur les paramètres de configuration longue durée en temps réel, veuillez consulter Comprendre les configurations des journaux en temps réel.

  3. Utilisez la commande suivante pour créer la configuration du journal en temps réel à l'aide des paramètres d'entrée du fichier rtl-config.yaml.

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

En cas de réussite, la sortie de la commande affiche les détails de la configuration du journal en temps réel que vous venez de créer.

Pour associer une configuration de journal en temps réel à une distribution existante (CLIavec fichier d'entrée)

  1. Utilisez la commande suivante pour enregistrer la configuration de distribution pour la CloudFront distribution que vous souhaitez mettre à jour. Remplacez distribution_ID avec l'identifiant de la distribution.

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

  2. Ouvrez le fichier nommé dist-config.yaml que vous venez de créer. Modifiez le fichier en apportant les modifications suivantes à chaque comportement de cache que vous mettez à jour pour utiliser une configuration de journal en temps réel.

    • Dans le comportement du cache, ajoutez un champ nommé RealtimeLogConfigArn. Pour la valeur du champ, utilisez la configuration ARN du journal en temps réel que vous souhaitez associer à ce comportement de cache.

    • Renommez le champ ETag en IfMatch, mais ne modifiez pas la valeur du champ.

    Enregistrez le fichier lorsque vous avez terminé.

  3. Utilisez la commande suivante pour mettre à jour la distribution afin d'utiliser la configuration du journal en temps réel. Remplacez distribution_ID avec l'identifiant de la distribution.

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

En cas de réussite, la sortie de la commande affiche les détails de la distribution que vous venez de mettre à jour.

API

Pour créer une configuration de journal en temps réel avec le CloudFront API, utilisez l'CreateRealtimeLogConfigAPIopération. Pour plus d'informations sur les paramètres que vous spécifiez dans cet API appel, consultez la documentation Comprendre les configurations des journaux en temps réel de API référence pour votre client AWS SDK ou pour un autre API client.

Après avoir créé une configuration de journal en temps réel, vous pouvez l'associer à un comportement de cache en effectuant l'une des API opérations suivantes :

  • Pour l'associer à un comportement de cache dans une distribution existante, utilisez UpdateDistribution.

  • Pour l'associer à un comportement de cache dans une nouvelle distribution, utilisez CreateDistribution.

Pour ces deux API opérations, indiquez la configuration ARN du journal en temps réel sur le RealtimeLogConfigArn terrain, dans le cadre d'un comportement de cache. Pour plus d'informations sur les autres champs que vous spécifiez dans ces API appels, consultez la documentation Référence des paramètres de distribution de API référence pour votre client AWS SDK ou pour un autre API client.

Comprendre les configurations des journaux en temps réel

Pour utiliser les journaux CloudFront en temps réel, vous devez commencer par créer une configuration de journal en temps réel. La configuration du journal en temps réel contient des informations sur les champs de journal que vous souhaitez recevoir, la fréquence d'échantillonnage des enregistrements de journaux et le flux de données Kinesis où vous souhaitez distribuer les journaux.

Plus précisément, une configuration de journal en temps réel contient les paramètres suivants :

Nom

Nom permettant d'identifier la configuration du journal en temps réel.

Taux d'échantillonnage

Le taux d'échantillonnage est un nombre entier compris entre 1 et 100 (inclus) qui détermine le pourcentage de demandes de l'utilisateur envoyées à Kinesis Data Streams sous forme d'enregistrements de journal en temps réel. Pour inclure chaque demande d'utilisateur dans vos journaux en temps réel, spécifiez 100 pour la fréquence d'échantillonnage. Vous pouvez choisir un taux d'échantillonnage inférieur pour réduire les coûts tout en recevant un échantillon représentatif des données de demande dans vos journaux en temps réel.

Champs

Liste des champs inclus dans chaque enregistrement de journal en temps réel. Chaque enregistrement de journal peut contenir jusqu’à 40 champs ; vous pouvez choisir de recevoir tous les champs disponibles ou uniquement les champs dont vous avez besoin pour surveiller et analyser les performances.

La liste suivante contient chaque nom de champ et une description des informations contenues dans ce champ. Les champs sont répertoriés dans l'ordre dans lequel ils apparaissent dans les enregistrements de journal qui sont distribués à Kinesis Data Streams.

Les champs 46 à 63 sont des données de client multimédia courantes (CMCD) auxquelles les clients du lecteur multimédia peuvent envoyer CDNs avec chaque demande. Vous pouvez utiliser ces données pour comprendre chaque demande, notamment le type de média (audio, vidéo), le taux de lecture et la durée de diffusion. Ces champs n'apparaîtront dans vos journaux en temps réel que s'ils sont envoyés à CloudFront.

  1. timestamp

    Date et heure auxquelles le serveur Edge a fini de répondre à la demande.

  2. c-ip

    Adresse IP de la visionneuse qui a émis la demande, par exemple, 192.0.2.183 ou 2001:0db8:85a3::8a2e:0370:7334. Si l'utilisateur a utilisé un HTTP proxy ou un équilibreur de charge pour envoyer la demande, la valeur de ce champ est l'adresse IP du proxy ou de l'équilibreur de charge. Voir aussi le champ x-forwarded-for.

  3. s-ip

    L'adresse IP du CloudFront serveur qui a répondu à la demande, par exemple, 192.0.2.183 ou2001:0db8:85a3::8a2e:0370:7334.

  4. time-to-first-byte

    Nombre de secondes entre la réception de la demande et l’écriture du premier octet de la réponse, tel que mesuré sur le serveur.

  5. sc-status

    Le code d'HTTPétat de la réponse du serveur (par exemple,200).

  6. sc-bytes

    Nombre total d’octets envoyés par le serveur à l’utilisateur en réponse à la demande, en-têtes inclus. Pour WebSocket les connexions, il s'agit du nombre total d'octets envoyés par le serveur au client via la connexion.

  7. cs-method

    Méthode de HTTP demande reçue du spectateur.

  8. cs-protocol

    Protocole de la demande de l'utilisateur (http, https, ws ou wss).

  9. cs-host

    Valeur que l'utilisateur a incluse dans l'en-tête Host de la demande. Si vous utilisez le nom de CloudFront domaine dans votre objet URLs (par exemple d111111abcdef8.cloudfront.net), ce champ contient ce nom de domaine. Si vous utilisez des noms de domaine alternatifs (CNAMEs) dans votre objet URLs (par exemple www.exemple.com), ce champ contient le nom de domaine alternatif.

  10. cs-uri-stem

    La demande complèteURL, y compris la chaîne de requête (s'il en existe une), mais sans le nom de domaine. Par exemple, /images/cat.jpg?mobile=true.

    Note

    Dans les journaux standard, la valeur cs-uri-stem n'inclut pas la chaîne de requête.

  11. cs-bytes

    Nombre total d’octets de données que l’utilisateur a inclus dans la demande, en-têtes inclus. Pour WebSocket les connexions, il s'agit du nombre total d'octets envoyés par le client au serveur lors de la connexion.

  12. x-edge-location

    Emplacement périphérique ayant servi la demande. Chaque position périphérique est identifiée par un code à trois lettres et un numéro attribué arbitrairement (par exemple,DFW3). Le code à trois lettres correspond généralement au code d'aéroport de l'Association du transport aérien international (IATA) pour un aéroport proche de l'emplacement géographique de la périphérie. (Ces abréviations peuvent changer à l'avenir.)

  13. x-edge-request-id

    Chaîne opaque qui identifie une demande de manière unique. CloudFront envoie également cette chaîne dans l'en-tête de x-amz-cf-id réponse.

  14. x-host-header

    Le nom de domaine de la CloudFront distribution (par exemple, d111111abcdef8.cloudfront.net).

  15. time-taken

    Nombre de secondes (au millième de seconde, par exemple 0,082) entre le moment où le serveur reçoit la demande de l’utilisateur et le moment où le serveur écrit le dernier octet de la réponse à la file d’attente de sortie, tel que mesuré sur le serveur. Du point de vue du spectateur, le temps total nécessaire pour obtenir la réponse complète sera plus long que cette valeur en raison de la latence du réseau et de la mise en TCP mémoire tampon.

  16. cs-protocol-version

    HTTPVersion spécifiée par le visualiseur dans la demande. Les valeurs possibles incluent HTTP/0.9, HTTP/1.0, HTTP/1.1, HTTP/2.0 et HTTP/3.0.

  17. c-ip-version

    Version IP de la demande (IPv4ouIPv6).

  18. cs-user-agent

    Valeur de l’en-tête User-Agent dans la demande. L'en-tête User-Agent identifie la source de la demande, comme le type d'appareil et le navigateur ayant envoyé la demande et, si la demande provenait d'un moteur de recherche, le moteur utilisé.

  19. cs-referer

    Valeur de l'en-tête Referer dans la demande. Nom du domaine à l’origine de la demande. Les référents courants incluent des moteurs de recherche, d'autres sites Web contenant des liens directs vers vos objets ou encore votre propre site web.

  20. cs-cookie

    En-tête Cookie de la demande, y compris les paires nom-valeur et les attributs associés.

    Note

    Ce champ est tronqué à 800 octets.

  21. cs-uri-query

    La partie de la requête sous forme de chaîne de requêteURL, le cas échéant.

  22. x-edge-response-result-type

    Comment le serveur a classé la réponse juste avant de la retourner à l’utilisateur. Voir aussi le champ x-edge-result-type. Les valeurs possibles incluent :

    • Hit – Le serveur a servi l’objet à l’utilisateur depuis le cache.

    • RefreshHit – Le serveur a trouvé l’objet dans le cache, mais l’objet avait expiré. Le serveur a donc contacté l’origine pour vérifier que le cache possédait la dernière version de l’objet.

    • Miss – La demande n’a pas pu être satisfaite par un objet du cache, c’est pourquoi le serveur a transmis la demande au serveur d’origine et a renvoyé le résultat à l’utilisateur.

    • LimitExceeded— La demande a été refusée car un CloudFront quota (anciennement appelé limite) a été dépassé.

    • CapacityExceeded : le serveur a renvoyé une erreur 503 car il n’avait pas suffisamment de capacité au moment de la demande pour servir l’objet.

    • Error – Généralement, cela signifie que la demande a entraîné une erreur client (la valeur du champ sc-status est dans la plage 4xx) ou une erreur serveur (la valeur du champ sc-status est dans la plage 5xx).

      Si la valeur du champ x-edge-result-type est Error et que la valeur de ce champ n’est pas Error, le client s’est déconnecté avant d’avoir fini le téléchargement.

    • Redirect— Le serveur a redirigé le lecteur de HTTP vers HTTPS en fonction des paramètres de distribution.

  23. x-forwarded-for

    Si l'utilisateur a utilisé un HTTP proxy ou un équilibreur de charge pour envoyer la demande, la valeur du c-ip champ est l'adresse IP du proxy ou de l'équilibreur de charge. Dans ce cas, ce champ est l’adresse IP de l’utilisateur à l’origine de la demande. Ce champ peut contenir plusieurs adresses IP séparées par des virgules. Chaque adresse IP peut être une IPv4 adresse (par exemple192.0.2.183) ou une IPv6 adresse (par exemple,2001:0db8:85a3::8a2e:0370:7334).

  24. ssl-protocol

    Lorsque la demande est utiliséeHTTPS, ce champ contient les 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 protocoles dansProtocoles et chiffrements pris en charge entre les utilisateurs et CloudFront.

  25. ssl-cipher

    Lorsque la demande est utiliséeHTTPS, ce champ contient les 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 chiffrements. Protocoles et chiffrements pris en charge entre les utilisateurs et CloudFront

  26. x-edge-result-type

    Comment le serveur a classé la réponse après que le dernier octet a quitté le serveur. Dans certains cas, le type de résultat peut changer entre le moment où le serveur est prêt à envoyer la réponse et celui où il a fini d’envoyer celle-ci. Voir aussi le champ x-edge-response-result-type.

    Par exemple, en HTTP streaming, supposons que le serveur trouve un segment du flux dans le cache. Dans ce scénario, la valeur de ce champ est normalement Hit. Cependant, si l’utilisateur ferme la connexion avant que le serveur ait livré la totalité du segment, le type de résultat final (et donc la valeur de ce champ) est Error.

    WebSocket les connexions auront une valeur égale à Miss pour ce champ car le contenu ne peut pas être mis en cache et est directement transmis par proxy à l'origine.

    Les valeurs possibles incluent :

    • Hit – Le serveur a servi l’objet à l’utilisateur depuis le cache.

    • RefreshHit – Le serveur a trouvé l’objet dans le cache, mais l’objet avait expiré. Le serveur a donc contacté l’origine pour vérifier que le cache possédait la dernière version de l’objet.

    • Miss – La demande n’ayant pas pu être satisfaite par un objet du cache, le serveur a transmis la demande à l’origine et retourné le résultat à l’utilisateur.

    • LimitExceeded— La demande a été refusée car un CloudFront quota (anciennement appelé limite) a été dépassé.

    • CapacityExceeded— Le serveur a renvoyé un code d'état HTTP 503 car il ne disposait pas d'une capacité suffisante au moment de la demande pour servir l'objet.

    • Error – Généralement, cela signifie que la demande a entraîné une erreur client (la valeur du champ sc-status est dans la plage 4xx) ou une erreur serveur (la valeur du champ sc-status est dans la plage 5xx). Si la valeur du sc-status champ est200, ou si la valeur de ce champ est Error et que la valeur du champ ne l'x-edge-response-result-typeest pasError, cela signifie que la HTTP demande a été acceptée mais que le client s'est déconnecté avant de recevoir tous les octets.

    • Redirect— Le serveur a redirigé le lecteur de HTTP vers HTTPS en fonction des paramètres de distribution.

  27. fle-encrypted-fields

    Le nombre de champs de chiffrement au niveau des champs que le serveur a chiffrés et transmis à l'origine. CloudFront les serveurs transmettent la demande traitée à l'origine au fur et à mesure qu'ils chiffrent les données. Ce champ peut donc avoir une valeur même si la valeur de fle-status est une erreur.

  28. fle-status

    Lorsque le chiffrement au niveau du champ est configuré pour une distribution, ce champ contient un code indiquant si le corps de la demande a bien été traité. Quand le serveur traite le corps de la demande, chiffre les valeurs dans les champs spécifiés et transfère la demande à l’origine correctement, la valeur de ce champ est Processed. La valeur x-edge-result-type peut toujours indiquer une erreur côté client ou côté serveur dans ce cas.

    Les valeurs possibles pour ce champ sont les suivantes :

    • ForwardedByContentType – Le serveur a réacheminé la demande vers l’origine sans analyse ou chiffrement, car aucun type de contenu n’était configuré.

    • ForwardedByQueryArgs : le serveur a réacheminé la demande vers l’origine sans analyse ou chiffrement, car la demande contient un argument de requête qui n’était pas dans la configuration du chiffrement au niveau du champ.

    • ForwardedDueToNoProfile – Le serveur a réacheminé la demande vers l’origine sans analyse ou chiffrement, car aucun profil n’était spécifié dans la configuration du chiffrement au niveau du champ.

    • MalformedContentTypeClientError— Le serveur a rejeté la demande et a renvoyé un code d'état HTTP 400 au visualiseur car le format de la valeur de l'Content-Typeen-tête n'était pas valide.

    • MalformedInputClientError— Le serveur a rejeté la demande et a renvoyé un code d'état HTTP 400 au visualiseur car le format du corps de la demande n'était pas valide.

    • MalformedQueryArgsClientError— Le serveur a rejeté la demande et renvoyé un code d'état HTTP 400 au visualiseur car un argument de requête était vide ou dans un format non valide.

    • RejectedByContentType— Le serveur a rejeté la demande et renvoyé un code d'état HTTP 400 au lecteur car aucun type de contenu n'était spécifié dans la configuration pour le chiffrement au niveau des champs.

    • RejectedByQueryArgs— Le serveur a rejeté la demande et renvoyé un code d'état HTTP 400 au visualiseur car aucun argument de requête n'était spécifié dans la configuration pour le chiffrement au niveau des champs.

    • ServerError – Le serveur d’origine a renvoyé une erreur.

    Si la demande dépasse un quota de chiffrement au niveau du champ (anciennement appelé limite), ce champ contient l'un des codes d'erreur suivants, et le serveur renvoie le code d'HTTPétat 400 au lecteur. Pour obtenir une liste des quotas actuels de chiffrement au niveau du champ, consultez Quotas sur le chiffrement au niveau du champ.

    • FieldLengthLimitClientError – Un champ configuré pour être chiffré a dépassé la longueur maximale autorisée.

    • FieldNumberLimitClientError – Une demande de configuration de la distribution pour le chiffrement contient un nombre de champs supérieur à celui autorisé.

    • RequestLengthLimitClientError – La longueur du corps de la demande dépasse la longueur maximale autorisée lorsque le chiffrement au niveau du champ est configuré.

  29. sc-content-type

    La valeur de l'HTTPContent-Typeen-tête de la réponse.

  30. sc-content-len

    La valeur de l'HTTPContent-Lengthen-tête de la réponse.

  31. sc-range-start

    Lorsque la réponse contient l'HTTPContent-Rangeen-tête, ce champ contient la valeur de début de la plage.

  32. sc-range-end

    Lorsque la réponse contient l'HTTPContent-Rangeen-tête, ce champ contient la valeur finale de la plage.

  33. c-port

    Numéro de port de la demande depuis l’utilisateur.

  34. x-edge-detailed-result-type

    Ce champ contient la même valeur que le champ x-edge-result-type, sauf dans les cas suivants :

    • Lorsque l’objet a été servi à l’utilisateur à partir de la couche Origin Shield, ce champ contient OriginShieldHit.

    • Lorsque l'objet n'était pas dans le CloudFront cache et que la réponse a été générée par une fonction Lambda @Edge de demande d'origine, ce champ contient. MissGeneratedResponse

    • Lorsque la valeur du champ x-edge-result-type est Error, ce champ contient l'une des valeurs suivantes et présente des informations supplémentaires sur l'erreur :

      • AbortedOrigin – Le serveur a rencontré un problème avec l’origine.

      • ClientCommError – La réponse à l’utilisateur a été interrompue en raison d’un problème de communication entre le serveur et l’utilisateur.

      • ClientGeoBlocked : la distribution est configurée de manière à refuser les demandes en provenance de l’emplacement géographique de l’utilisateur.

      • ClientHungUpRequest – La visionneuse s’est arrêtée prématurément lors de l’envoi de la demande.

      • Error : une erreur s’est produite pour laquelle le type d’erreur ne correspond à aucune des autres catégories. Ce type d’erreur peut se produire lorsque le serveur sert une réponse d’erreur à partir du cache.

      • InvalidRequest – Le serveur a reçu une demande non valide de la part de l’utilisateur.

      • InvalidRequestBlocked – L’accès à la ressource demandée est bloqué.

      • InvalidRequestCertificate— La distribution ne correspond pas au TLS certificatSSL/pour lequel la HTTPS connexion a été établie.

      • InvalidRequestHeader – La demande contenait un en-tête non valide.

      • InvalidRequestMethod— La distribution n'est pas configurée pour gérer la méthode de HTTP demande utilisée. Cela peut se produire lorsque la distribution prend en charge uniquement les demandes pouvant être mises en cache.

      • OriginCommError – La demande a expiré lors de la connexion à l'origine ou lors de la lecture de données à partir de l'origine.

      • OriginConnectError : le serveur n’a pas pu se connecter à l’origine.

      • OriginContentRangeLengthError : l’en-tête Content-Length de la réponse de l’origine ne correspond pas à la longueur de l’en-tête Content-Range.

      • OriginDnsError : le serveur n’a pas pu résoudre le nom de domaine de l’origine.

      • OriginError — L’origine a renvoyé une réponse incorrecte.

      • OriginHeaderTooBigError – Un en-tête renvoyé par l’origine est trop volumineux pour être traité.

      • OriginInvalidResponseError — L’origine a renvoyé une réponse non valide.

      • OriginReadError : le serveur n’a pas pu lire à partir de l’origine.

      • OriginWriteError : le serveur n’a pas pu écrire à l’origine.

      • OriginZeroSizeObjectError — Un objet de taille zéro envoyé depuis l’origine a provoqué une erreur.

      • SlowReaderOriginError — La visionneuse a été lente à lire le message qui a provoqué l’erreur d’origine.

  35. c-country

    Code de pays qui représente l'emplacement géographique de l'utilisateur, déterminé par l'adresse IP de l'utilisateur. Pour une liste des codes de pays, voir ISO3166-1 alpha-2.

  36. cs-accept-encoding

    Valeur de l’en-tête Accept-Encoding dans la demande de l’utilisateur.

  37. cs-accept

    Valeur de l’en-tête Accept dans la demande de l’utilisateur.

  38. cache-behavior-path-pattern

    Modèle de chemin qui identifie le comportement du cache correspondant à la demande de l'utilisateur.

  39. cs-headers

    Les HTTP en-têtes (noms et valeurs) de la demande du visualiseur.

    Note

    Ce champ est tronqué à 800 octets.

  40. cs-header-names

    Les noms des HTTP en-têtes (et non des valeurs) de la demande du visualiseur.

    Note

    Ce champ est tronqué à 800 octets.

  41. cs-headers-count

    Le nombre d'HTTPen-têtes contenus dans la demande du visualiseur.

  42. origin-fbl

    Le nombre de secondes de latence du premier octet entre CloudFront et votre origine.

  43. origin-lbl

    Le nombre de secondes de latence du dernier octet entre CloudFront et votre origine.

  44. asn

    Numéro de système autonome (ASN) du visualiseur.

  45. primary-distribution-id

    Lorsque le déploiement continu est activé, cet ID identifie la distribution principale de la distribution actuelle.

  46. primary-distribution-dns-name

    Lorsque le déploiement continu est activé, cette valeur indique le nom de domaine principal associé à la CloudFront distribution actuelle (par exemple, d111111abcdef8.cloudfront.net).

    CMCDchamps dans les journaux en temps réel

    Pour plus d'informations sur ces champs, consultez le document CTASpecification Web Application Video Ecosystem - Common Media Client Data CTA -5004.

  47. cmcd-encoded-bitrate

    Débit codé de l'objet audio ou vidéo demandé.

  48. cmcd-buffer-length

    La longueur de la mémoire tampon de l'objet multimédia demandé.

  49. cmcd-buffer-starvation

    Si la mémoire tampon a été épuisée à un moment donné entre la demande précédente et la demande d'objet. Cela peut entraîner une mise en mémoire tampon du lecteur, ce qui peut bloquer la lecture vidéo ou audio.

  50. cmcd-content-id

    Chaîne unique qui identifie le contenu actuel.

  51. cmcd-object-duration

    Durée de lecture de l'objet demandé (en millisecondes).

  52. cmcd-deadline

    Date limite à compter de la date de demande pendant laquelle le premier échantillon de cet objet doit être disponible, afin d'éviter un état de sous-utilisation de la mémoire tampon ou d'autres problèmes de lecture.

  53. cmcd-measured-throughput

    Le débit entre le client et le serveur, tel que mesuré par le client.

  54. cmcd-next-object-request

    Le chemin relatif du prochain objet demandé.

  55. cmcd-next-range-request

    Si la demande suivante est une demande d'objet partielle, cette chaîne indique la plage d'octets à demander.

  56. cmcd-object-type

    Type de média de l'objet actuellement demandé.

  57. cmcd-playback-rate

    1 si vous jouez en temps réel, 2 si vous êtes à double vitesse, 0 si vous ne jouez pas.

  58. cmcd-requested-maximum-throughput

    Le débit maximal demandé que le client considère comme suffisant pour la livraison des actifs.

  59. cmcd-streaming-format

    Le format de streaming qui définit la demande en cours.

  60. cmcd-session-id

    A GUID identifiant la session de lecture en cours.

  61. cmcd-stream-type

    Jeton identifiant la disponibilité du segment. v= tous les segments sont disponibles. l= les segments deviennent disponibles au fil du temps.

  62. cmcd-startup

    La clé est incluse sans valeur si l'objet est requis de toute urgence lors du démarrage, de la recherche ou de la restauration après un événement de vide dans la mémoire tampon.

  63. cmcd-top-bitrate

    Le rendu le plus haut débit que le client peut lire.

  64. cmcd-version

    Version de cette spécification utilisée pour interpréter les noms de clés et les valeurs définis. Si cette clé est omise, le client et le serveur doivent interpréter les valeurs telles qu'elles sont définies par la version 1.

Point de terminaison (Kinesis Data Streams)

Le point de terminaison contient des informations sur les Kinesis Data Streams auxquels vous souhaitez envoyer des journaux en temps réel. Vous fournissez le nom de ressource Amazon (ARN) du flux de données.

Pour plus d'informations sur la création d'un Kinesis Data Streams, consultez les rubriques suivantes du manuel Amazon Kinesis Data Streams Developer Guide.

Lorsque vous créez un flux de données, vous devez spécifier le nombre de partitions. Utilisez les informations suivantes pour vous aider à estimer le nombre de partitions dont vous avez besoin.

Pour estimer le nombre de partitions pour votre flux de données Kinesis

  1. Calculez (ou estimez) le nombre de demandes par seconde reçues par votre CloudFront distribution.

    Vous pouvez utiliser les rapports CloudFront d'utilisation (dans la CloudFront console) et les CloudFront métriques (dans les CloudWatch consoles CloudFront et Amazon) pour vous aider à calculer le nombre de demandes par seconde.

  2. Déterminez la taille type d'un seul enregistrement en temps réel.

    En général, un seul enregistrement de journal est d'environ 500 octets. Un enregistrement volumineux qui contient tous les champs disponibles est généralement d'environ 1 Ko.

    Si vous ne connaissez pas la taille de vos enregistrements, vous pouvez activer les journaux en temps réel avec un faible taux d’échantillonnage (par exemple, 1 %), puis calculer la taille moyenne des enregistrements en utilisant les données de surveillance dans Kinesis Data Streams (nombre total d’octets entrants divisé par le nombre total d’enregistrements).

  3. Sur la page de tarification d'Amazon Kinesis Data Streams, AWS Pricing Calculator sous, choisissez Create your custom estimate now.

    • Dans le calculateur, entrez le nombre de demandes (enregistrements) par seconde.

    • Entrez la taille moyenne d'un enregistrement de journal unique.

    • Choisissez Afficher les calculs.

    Le calculateur de prix vous indique le nombre de partitions dont vous avez besoin et le coût estimé.

IAMrôle

Le rôle AWS Identity and Access Management (IAM) qui CloudFront autorise la transmission de journaux en temps réel à votre flux de données Kinesis.

Lorsque vous créez une configuration de journal en temps réel avec la CloudFront console, vous pouvez choisir Créer un nouveau rôle de service pour laisser la console créer le IAM rôle pour vous.

Lorsque vous créez une configuration de journal en temps réel avec AWS CloudFormation AWS CLI ou le CloudFront API (ouSDK), vous devez créer le IAM rôle vous-même et fournir le rôleARN. Pour créer le IAM rôle vous-même, appliquez les règles suivantes.

Stratégie d'approbation de rôle IAM

Pour utiliser la politique de confiance des IAM rôles suivante, remplacez 111122223333 avec ton Compte AWS numéro. L'Conditionélément de cette politique permet d'éviter le problème de confusion des adjoints, car ils ne CloudFront peuvent assumer ce rôle qu'au nom d'une distribution de votre entreprise Compte AWS.

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

IAMpolitique d'autorisations de rôle pour un flux de données non chiffré

Pour appliquer la politique suivante, remplacez arn:aws:kinesis:us-east-2:123456789012:stream/StreamName avec le flux ARN de données de votre Kinesis.

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

IAMpolitique d'autorisations de rôle pour un flux de données chiffré

Pour appliquer la politique suivante, remplacez arn:aws:kinesis:us-east-2:123456789012:stream/StreamName avec le flux ARN de données de votre Kinesis et arn:aws:kms:us-east-2:123456789012:key/e58a3d0b-fe4f-4047-a495-ae03cc73d486 avec le ARN de vos 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"
            ]
        }
    ]
}

Créez un client Kinesis Data Streams

Pour lire et analyser vos journaux en temps réel, vous créez ou utilisez un consommateur Kinesis Data Streams. Lorsque vous créez un consommateur pour les journaux CloudFront en temps réel, il est important de savoir que les champs de chaque enregistrement de journal en temps réel sont toujours livrés dans le même ordre, comme indiqué dans la Champs section. Assurez-vous que vous créez votre consommateur en fonction de cet ordre fixe.

Prenons l'exemple d'une configuration de journal en temps réel qui inclut uniquement les trois champs suivants : time-to-first-byte, sc-status et c-country. Dans ce scénario, le dernier champ, c-country, est toujours le champ numéro 3 dans chaque enregistrement de journal. Toutefois, si vous ajoutez ultérieurement des champs à la configuration du journal en temps réel, le placement de chaque champ dans un enregistrement peut changer.

Par exemple, si vous ajoutez les champs sc-bytes et time-taken à la configuration du journal en temps réel, ces champs sont insérés dans chaque enregistrement de journal selon l'ordre indiqué à la section Champs. L'ordre final des cinq champs est time-to-first-byte, sc-status, sc-bytes, time-taken et c-country. Le champ c-country était à l'origine le champ numéro 3, mais il est maintenant le champ numéro 5. Assurez-vous que votre application grand public peut gérer les champs qui changent de position dans un enregistrement de journal, au cas où vous ajouteriez des champs à votre configuration de journal en temps réel.

Résolution des problèmes liés aux journaux en temps réel

Une fois que vous avez créé une configuration de journal en temps réel, vous pouvez constater qu'aucun enregistrement (ou seulement certains d'entre eux) n'est remis à Kinesis Data Streams. Dans ce cas, vous devez d'abord vérifier que votre CloudFront distribution reçoit les demandes des spectateurs. Le cas échéant, vous pouvez vérifier le paramètre suivant pour poursuivre le dépannage.

IAMautorisations de rôle

Pour fournir des enregistrements de journal en temps réel à votre flux de données Kinesis, utilisez le CloudFront IAM rôle dans la configuration des journaux en temps réel. Assurez-vous que la stratégie d'approbation de rôle et la stratégie d'autorisations de rôle correspondent aux stratégies indiquées dans IAMrôle.

Limitation des Kinesis Data Streams

Si vous CloudFront enregistrez des enregistrements de journal en temps réel dans votre flux de données Kinesis plus rapidement que ce dernier ne peut le gérer, Kinesis Data Streams peut limiter le nombre de demandes provenant de. CloudFront Dans ce cas, vous pouvez augmenter le nombre de partitions dans votre flux de données Kinesis. Chaque partition peut prendre en charge des écritures jusqu’à 1 000 enregistrements par seconde, jusqu’à un maximum d’écritures de données de 1 Mo par seconde.