Utilisez des journaux en temps réel - Amazon CloudFront
Création et utilisation de configurations de journaux en temps réelComprenez 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 l' 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'adressehttp://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 champs CMCD pour vos journaux, choisissez CMCD all keys.

  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 le rôle IAM, choisissez Créer un nouveau rôle de service ou choisissez un rôle existant. Vous devez être autorisé à créer des rôles IAM.

  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 Comprenez 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 (CLI avec un 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 Comprenez 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 attacher une configuration de journal en temps réel à une distribution existante (CLI avec un 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 par l'ID 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 l'ARN de la configuration du journal en temps réel que vous souhaitez attacher à 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 par l'ID 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 l' CloudFront API, utilisez l'opération CreateRealtimeLogConfigAPI. Pour plus d'informations sur les paramètres que vous spécifiez dans cet appel d'API, consultez Comprenez les configurations des journaux en temps réel la documentation de référence de l'API pour votre AWS SDK ou autre client d'API.

Après avoir créé une configuration de journal en temps réel, vous pouvez l'associer à un comportement de cache en utilisant l'une des opérations d'API 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 opérations d'API, fournissez l'ARN de la configuration du journal en temps réel RealtimeLogConfigArn sur le terrain, dans un comportement de cache. Pour plus d'informations sur les autres champs que vous spécifiez dans ces appels d'API, consultez Référence des paramètres de distribution la documentation de référence de l'API pour votre AWS SDK ou autre client d'API.

Comprenez 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 communes sur les clients multimédia (CMCD) auxquelles les clients des lecteurs multimédia peuvent envoyer des données CDNs à 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 proxy HTTP 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

    Code de statut HTTP 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 les connexions gRPC WebSocket et gRPC, il s'agit du nombre total d'octets envoyés par le serveur au client via la connexion.

  7. cs-method

    Méthode de demande HTTP reçue de l’utilisateur.

  8. cs-protocol

    Protocole de la demande de l’utilisateur (http, http, grpcs, 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

    L'URL entière de la demande, y compris la chaîne de requête (le cas échéant), 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 les connexions gRPC WebSocket et gRPC, 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 IATA (International Air Transport Association) d’un aéroport proche de l’emplacement périphérique. (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 de l'utilisateur, le temps total pour obtenir la réponse complète sera plus long que cette valeur en raison de la latence réseau et de la mise en tampon TCP.

  16. cs-protocol-version

    Version de HTTP que l'utilisateur a spécifiée dans la requête. 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 (IPv4 ou IPv6).

  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

    Partie de la chaîne de requête de l'URL de la demande, 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é l'utilisateur depuis HTTP vers HTTPS en fonction des paramètres de distribution.

  23. x-forwarded-for

    Si l'utilisateur a utilisé un proxy HTTP ou un équilibreur de charge pour envoyer la demande, la valeur du champ c-ip 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 a utilisé le protocole HTTPS, 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 a utilisé le protocole HTTPS, 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, dans le streaming HTTP, 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 et les connexions gRPC auront une valeur égale à Miss pour ce champ car le contenu ne peut pas être mis en cache et est transmis directement à l'origine par proxy.

    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’erreur HTTP 503, car la capacité était insuffisante pour servir l’objet au moment de la demande.

    • 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 sc-status est 200, ou si la valeur de ce champ est Error et que la valeur du champ x-edge-response-result-type est différente de Error, cela signifie que la demande HTTP a réussi mais que le client a été déconnecté avant de recevoir tous les octets.

    • Redirect – Le serveur a redirigé l’utilisateur depuis 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é le code de statut HTTP 400 à l’utilisateur, car le format de la valeur de l’en-tête Content-Type n’était pas valide.

    • MalformedInputClientError – Le serveur a rejeté la demande et a renvoyé le code de statut HTTP 400 à l’utilisateur, car le format du corps de la requête n’était pas valide.

    • MalformedQueryArgsClientError – Le serveur a rejeté la demande et a renvoyé le code de statut HTTP 400 à l’utilisateur, car un argument de requête était vide ou son format n’était pas valide.

    • RejectedByContentType – Le serveur a rejeté la demande et a renvoyé le code de statut HTTP 400 à l’utilisateur, car aucun type de contenu n’était spécifié dans la configuration du chiffrement au niveau du champ.

    • RejectedByQueryArgs – Le serveur a rejeté la demande et a renvoyé le code de statut HTTP 400 à l’utilisateur, car aucun argument de requête n’était spécifié dans la configuration du chiffrement au niveau du champ.

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

    Si la demande dépasse un quota de chiffrement au niveau du champ (précédemment appelé limite), ce champ contient l’un des codes d’erreur suivants, et le serveur renvoie le code d’état HTTP 400 à l’utilisateur. 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

    Valeur de l'en-tête Content-Type HTTP de la réponse.

  30. sc-content-len

    Valeur de l’en-tête Content-Length HTTP de la réponse.

  31. sc-range-start

    Lorsque la réponse contient l’en-tête Content-Range HTTP, ce champ contient la valeur de début de plage.

  32. sc-range-end

    Lorsque la réponse contient l'en-tête Content-Range HTTP, ce champ contient la valeur de fin de 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 certificat SSL/TLS pour lequel la connexion HTTPS 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 demande HTTP 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 obtenir une liste des codes de pays, consultez ISO 3166-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

    En-têtes HTTP (noms et valeurs) dans la demande de l'utilisateur.

    Note

    Ce champ est tronqué à 800 octets.

  40. cs-header-names

    Noms des en-têtes HTTP (et non des valeurs) dans la demande de l'utilisateur.

    Note

    Ce champ est tronqué à 800 octets.

  41. cs-headers-count

    Nombre d'en-têtes HTTP dans la demande de l'utilisateur.

  42. primary-distribution-id

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

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

  44. origin-fbl

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

  45. origin-lbl

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

  46. asn

    Numéro de système autonome (ASN) de l'utilisateur.

    Champs CMCD dans les journaux en temps réel

    Pour plus d'informations sur ces champs, consultez le document CTA Specification 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

    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.

  65. r-host

    Ce champ est envoyé pour les demandes d'origine et indique le domaine du serveur d'origine utilisé pour servir l'objet. En cas d'erreur, vous pouvez utiliser ce champ pour trouver la dernière origine tentée, par exemple :cd8jhdejh6a.mediapackagev2.us-east-1.amazonaws.com.

  66. sr-reason

    Ce champ indique la raison pour laquelle l'origine a été sélectionnée. Il est vide lorsqu'une demande adressée à l'origine principale aboutit.

    En cas de basculement d'origine, le champ contiendra le code d'erreur HTTP à l'origine du basculement, tel que Failover:403 ou. Failover:502 En cas de basculement d'origine, si la nouvelle demande échoue également et que vous n'avez pas configuré de pages d'erreur personnalisées, r-status indique la réponse de la deuxième origine. Toutefois, si vous avez configuré des pages d'erreur personnalisées ainsi que le basculement d'origine, celles-ci contiendront la réponse de la deuxième origine si la demande a échoué et qu'une page d'erreur personnalisée a été renvoyée à la place.

    Si aucun basculement d'origine ne se produit mais que la sélection de l'origine par résilience consciente de la qualité des médias (MQAR) a lieu, cela sera enregistré comme tel. MediaQuality Pour de plus amples informations, veuillez consulter Résilience axée sur la qualité des médias.

  67. x-edge-mqcs

    Ce champ indique le Media Quality Confidence Score (MQCS) (plage : 0 à 100) pour les segments multimédias CloudFront extraits dans les en-têtes de réponse CMSD de la version v2. MediaPackage Ce champ est disponible pour les demandes correspondant à un comportement de cache dont le groupe d'origine est compatible MQAR. CloudFront enregistre ce champ pour les segments multimédias qui sont également diffusés à partir de son cache en plus des demandes d'origine. Pour de plus amples informations, veuillez consulter Résilience axée sur la qualité des médias.

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 Amazon Resource Name (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 que votre distribution CloudFront reçoit.

    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, Calculateur de tarification AWS sous, choisissez Create your custom estimate now.

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

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

    • Choisissez Afficher les calculs.

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

Rôle IAM

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 permettre à la console de créer le rôle IAM pour vous.

Lorsque vous créez une configuration de journal en temps réel avec AWS CloudFormation l' CloudFront API (AWS CLI ou le SDK), vous devez créer vous-même le rôle IAM et fournir l'ARN du rôle. Pour créer le rôle IAM vous-même, utilisez les politiques suivantes.

Stratégie d’approbation de rôle IAM

Pour utiliser la politique de confiance des rôles IAM suivante, remplacez-la 111122223333 par votre 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"
                }
            }
        }
    ]
}

Stratégie d’autorisations de rôle IAM pour un flux de données non chiffré

Pour appliquer la politique suivante, remplacez-la arn:aws:kinesis:us-east-2:123456789012:stream/StreamName par l'ARN de votre flux de données 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"
            ]
        }
    ]
}

Stratégie d’autorisations de rôle IAM pour un flux de données chiffré

Pour appliquer la politique suivante, remplacez-le arn:aws:kinesis:us-east-2:123456789012:stream/StreamName par l'ARN de votre flux de données Kinesis et arn:aws:kms:us-east-2:123456789012:key/e58a3d0b-fe4f-4047-a495-ae03cc73d486 par l'ARN de votre. 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 distribution CloudFront reçoit des demandes de l'utilisateur. Le cas échéant, vous pouvez vérifier le paramètre suivant pour poursuivre le dépannage.

Autorisations de rôle IAM

Pour fournir des enregistrements de journal en temps réel à votre flux de données Kinesis, CloudFront utilisez le rôle IAM 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 Rôle IAM.

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.