Création et utilisation de configurations de journaux en temps réel Comprendre les configurations des journaux en temps réel Créez un client Kinesis Data Streams Résolution des problèmes liés aux journaux en temps réel

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.

Rubriques

Création et utilisation de configurations de journaux en temps réel
Comprendre les configurations des journaux en temps réel
Créez un client Kinesis Data Streams
Résolution des problèmes liés aux journaux en temps réel

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

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.
Choisissez l'onglet Configurations en temps réel.
Choisissez Create configuration (Créer une configuration).
Dans Nom, entrez le nom de la configuration.
Pour Taux d'échantillonnage, entrez le pourcentage de demandes pour lesquelles vous souhaitez recevoir des enregistrements de journal.
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.
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
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.
(Facultatif) Pour Distribution, choisissez un comportement CloudFront de distribution et de cache à associer à la configuration du journal en temps réel.
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 plus d’informations, consultez 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 (CLI avec un fichier d'entrée)

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

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
```
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é.
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 Comprendre 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.

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 :

Table des matières

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) que les clients des lecteurs multimédias peuvent envoyer aux CDN à 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.

timestamp

Date et heure auxquelles le serveur Edge a fini de répondre à la demande.
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.
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.
sc-status

Code de statut HTTP de la réponse du serveur (par exemple, 200).
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.
cs-method

Méthode de demande HTTP reçue de l'utilisateur.
cs-protocol

Protocole de la demande de l'utilisateur (http, https, ws ou wss).
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 les URL de vos objets (par exemple d111111abcdef8.cloudfront.net), ce champ contient ce nom de domaine. Si vous utilisez des noms de domaine alternatifs (CNAMES) dans vos URL d’objet (tels que www.example.com), ce champ contient l’autre nom de domaine.
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.
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.
x-edge-location

Emplacement périphérique ayant servi la demande. Chaque emplacement périphérique est identifié 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.)
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.
x-host-header

Le nom de domaine de la CloudFront distribution (par exemple, d111111abcdef8.cloudfront.net).
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.
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.
c-ip-version

Version IP de la demande (IPv4 ou IPv6).
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é.
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.
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.
cs-uri-query

Partie de la chaîne de requête de l'URL de la demande, le cas échéant.
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.
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 adresse IPv4 (par exemple192.0.2.183) ou une adresse IPv6 (par exemple,2001:0db8:85a3::8a2e:0370:7334).
ssl-protocol

Lorsque la demande a utilisé HTTPS, ce champ contient le protocole SSL/TLS que l’utilisateur et le serveur ont négocié pour transmettre la demande et la réponse. Pour obtenir la liste des valeurs possibles, consultez les chiffrements SSL/TLS pris en charge dans Protocoles et chiffrements pris en charge entre les utilisateurs et CloudFront.
ssl-cipher

Lorsque la demande utilise HTTPS, ce champ contient le chiffrement SSL/TLS que l'utilisateur et le serveur ont négocié pour chiffrer la demande et la réponse. Pour obtenir la liste des valeurs possibles, consultez les chiffrements SSL/TLS pris en charge dans Protocoles et chiffrements pris en charge entre les utilisateurs et CloudFront.
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 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’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.
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.
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é.
sc-content-type

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

Valeur de l’en-tête Content-Length HTTP de la réponse.
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.
sc-range-end

Lorsque la réponse contient l'en-tête Content-Range HTTP, ce champ contient la valeur de fin de plage.
c-port

Numéro de port de la demande depuis l’utilisateur.
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.
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.
cs-accept-encoding

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

Valeur de l’en-tête Accept dans la demande de l’utilisateur.
cache-behavior-path-pattern

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

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

Note
Ce champ est tronqué à 800 octets.
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.
cs-headers-count

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

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

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

Numéro de système autonome (ASN) de l'utilisateur.
primary-distribution-id

Lorsque le déploiement continu est activé, cet ID identifie la distribution principale de la distribution actuelle.
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).

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.
cmcd-encoded-bitrate

Débit codé de l'objet audio ou vidéo demandé.
cmcd-buffer-length

La longueur de la mémoire tampon de l'objet multimédia demandé.
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.
cmcd-content-id

Chaîne unique qui identifie le contenu actuel.
cmcd-object-duration

Durée de lecture de l'objet demandé (en millisecondes).
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.
cmcd-measured-throughput

Le débit entre le client et le serveur, tel que mesuré par le client.
cmcd-next-object-request

Le chemin relatif du prochain objet demandé.
cmcd-next-range-request

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

Type de média de l'objet actuellement demandé.
cmcd-playback-rate

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

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

Le format de streaming qui définit la demande en cours.
cmcd-session-id

GUID identifiant la session de lecture en cours.
cmcd-stream-type

Jeton identifiant la disponibilité du segment. v= tous les segments sont disponibles. l= les segments deviennent disponibles au fil du temps.
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.
cmcd-top-bitrate

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

Version de cette spécification utilisée pour interpréter les noms et valeurs de clé 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 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.

Gestion de flux à l’aide de la console
Effectuez des opérations de base sur le flux de données Kinesis à l'aide du AWS CLI
Création d'un flux (utilise le AWS SDK for Java)

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

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.
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).
Dans le Calculateur de tarification de la page de tarification d’Amazon Kinesis Data Streams, entrez le nombre de demandes (enregistrements) par seconde et la taille moyenne de l’enregistrement d'un unique enregistrement de journal. Sélectionnez ensuite Show calculations (Afficher les calculs).

Le calculateur de tarification vous indique le nombre de partitions nécessaire. (Il affiche également le coût estimé.)

L'exemple suivant montre que pour une taille moyenne d'enregistrement de 0,5 Ko et 50 000 demandes par seconde, vous avez besoin de 50 partitions.

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 stratégie d'approbation de rôle IAM suivante, remplacez 111122223333par votre numéro de Compte AWS . 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 arn:aws:kinesis:us-east- 2:123456789012:stream/ par l'ARN de votre flux de données Kinesis. StreamName


{
    "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 arn:aws:kinesis:us-east- 2:123456789012:stream/ 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'StreamNameARN 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 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.

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.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Utiliser des journaux standard (journaux d'accès)

Journaux des fonctions Edge

Utilisez des journaux en temps réel

Important

Rubriques

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

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

Note

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

Pour attacher une configuration de journal en temps réel à une distribution existante (CLI avec un fichier d'entrée)

Comprendre les configurations des journaux en temps réel

Table des matières

Nom

Taux d'échantillonnage

Champs

Note

Note

Note

Note

Champs CMCD dans les journaux en temps réel

Point de terminaison (Kinesis Data Streams)

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

Rôle IAM

Créez un client Kinesis Data Streams

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