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.
# Utiliser des journaux d'accès en temps réel
Grâce aux journaux d'accès 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 les journaux d'accès en temps réel pour surveiller, analyser et prendre des mesures en fonction des performances de diffusion du contenu.
CloudFront les journaux d'accès en temps réel sont configurables. Vous pouvez choisir :
+ Le *taux d'échantillonnage de* vos journaux en temps réel, c'est-à-dire le pourcentage de demandes pour lesquelles vous souhaitez recevoir des enregistrements de journaux d'accès 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 d'accès 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](https://docs.aws.amazon.com/streams/latest/dev/amazon-kinesis-consumers.html) 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 d'accès 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](https://aws.amazon.com/cloudfront/pricing/) et [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/pricing/).
**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 d'accès 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 d'accès en temps réel, le nombre d'entrées dans les journaux d'accès en temps réel ne correspond pas à l'utilisation indiquée dans les rapports AWS de facturation et d'utilisation.
**Topics**
+ [Création et utilisation de configurations de journaux d'accès en temps réel](#create-real-time-log-config)
+ [Comprendre les configurations des journaux d'accès en temps réel](#understand-real-time-log-config)
+ [Création d’un consommateur Kinesis Data Streams](#real-time-log-consumer-guidance)
+ [Résolution des problèmes liés aux journaux d'accès en temps réel](#real-time-log-troubleshooting)
## Création et utilisation de configurations de journaux d'accès en temps réel
Pour obtenir des informations sur les demandes adressées à une distribution en temps réel, vous pouvez utiliser les configurations d'un journal d'accès 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 d'accès 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 d'accès 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 d'accès en temps réel**
1. Connectez-vous à la page **Logs AWS Management Console et ouvrez-la** dans la CloudFront console à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home?#/logs](https://console.aws.amazon.com/cloudfront/v4/home?#/logs).
1. Choisissez l’onglet **Configurations en temps réel**.
1. Choisissez **Créer une configuration**.
1. Pour **Nom**, entrez un nom pour la configuration.
1. Pour **Taux d’échantillonnage**, entrez le pourcentage de demandes pour lesquelles vous souhaitez recevoir des journaux.
1. Pour **les champs**, choisissez les champs à recevoir dans les journaux d'accès en temps réel.
+ Pour inclure tous les [champs CMCD](#CMCD-real-time-logging-fields) dans vos journaux, choisissez **CMCD all keys**.
1. Pour **Endpoint**, choisissez un ou plusieurs flux de données Kinesis pour recevoir des journaux d'accès en temps réel.
**Note**
CloudFront les journaux d'accès 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 d'accès 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
1. Dans le champ **Rôle IAM**, sélectionnez **Créer un nouveau rôle de service** ou choisissez un rôle existant. Vous devez être autorisé à créer des rôles IAM.
1. (Facultatif) Pour **Distribution**, choisissez un comportement de CloudFront distribution et de cache à associer à la configuration du journal d'accès en temps réel.
1. Choisissez **Créer une configuration**.
En cas de succès, la console affiche les détails de la configuration du journal d'accès en temps réel que vous venez de créer.
Pour de plus amples informations, veuillez consulter [Comprendre les configurations des journaux d'accès en temps réel](#understand-real-time-log-config).
------
#### [ AWS CLI ]
Pour créer une configuration de journal d'accès 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 d'accès en temps réel (CLI avec 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
```
1. 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 d'accès en temps réel que vous souhaitez, puis enregistrez le fichier. Notez ce qui suit :
+ Pour `StreamType`, la seule valeur valide est `Kinesis`.
Pour plus d’informations sur les paramètres de configuration longue durée en temps réel, consultez [Comprendre les configurations des journaux d'accès en temps réel](#understand-real-time-log-config).
1. Utilisez la commande suivante pour créer la configuration du journal d'accès en temps réel à l'aide des paramètres d'entrée du `rtl-config.yaml` fichier.
```
aws cloudfront create-realtime-log-config --cli-input-yaml file://rtl-config.yaml
```
En cas de succès, le résultat de la commande affiche les détails de la configuration du journal d'accès en temps réel que vous venez de créer.
**Pour associer une configuration de journal d'accès en temps réel à une distribution existante (CLI avec 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\$1ID* par l'ID de la distribution.
```
aws cloudfront get-distribution-config --id distribution_ID --output yaml > dist-config.yaml
```
1. 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 afin d'utiliser une configuration de journal d'accès 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 d'accès 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é.
1. Utilisez la commande suivante pour mettre à jour la distribution afin d'utiliser la configuration du journal d'accès en temps réel. Remplacez *distribution\$1ID* 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 d'accès en temps réel avec l' CloudFront API, utilisez l'opération [CreateRealtimeLogConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateRealtimeLogConfig.html)API. Pour plus d'informations sur les paramètres que vous spécifiez dans cet appel d'API, consultez [Comprendre les configurations des journaux d'accès en temps réel](#understand-real-time-log-config) 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 d'accès 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](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
+ Pour l'associer à un comportement de cache dans une nouvelle distribution, utilisez [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).
Pour ces deux opérations d'API, fournissez l'ARN de la configuration du journal d'accès 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 de tous les paramètres de distribution](distribution-web-values-specify.md) la documentation de référence de l'API pour votre AWS SDK ou autre client d'API.
------
## Comprendre les configurations des journaux d'accès en temps réel
Pour utiliser les journaux d'accès CloudFront en temps réel, vous devez commencer par créer une configuration de journal d'accès en temps réel. La configuration du journal d'accès en temps réel contient des informations sur les champs de journal que vous souhaitez recevoir, le *taux d'échantillonnage* des enregistrements de journal et le flux de données Kinesis dans lequel vous souhaitez transmettre les journaux.
Plus précisément, une configuration de journal d'accès en temps réel contient les paramètres suivants :
**Contents**
+ [Nom](#real-time-logs-name)
+ [Taux d'échantillonnage](#real-time-logs-sampling-rate)
+ [Champs](#real-time-logs-fields)
+ [Point de terminaison (Kinesis Data Streams)](#real-time-logs-endpoint)
+ [Rôle IAM](#real-time-logs-IAM)
### Nom
Nom permettant d'identifier la configuration du journal d'accès 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 utilisateur envoyées à Kinesis Data Streams sous forme d’enregistrements de journal d’accès en temps réel. Pour inclure chaque demande utilisateur dans vos journaux d’accès en temps réel, spécifiez 100 pour le taux 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 d’accès en temps réel.
### Champs
Liste des champs inclus dans chaque enregistrement du journal d'accès 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](#CMCD-real-time-logging-fields) 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 d'accès 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.
1. **`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`.
1. **`s-ip`**
L'adresse IP du CloudFront serveur qui a répondu à la demande, par exemple, `192.0.2.183` ou`2001:0db8:85a3::8a2e:0370:7334`.
1. **`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.
1. **`sc-status`**
Code de statut HTTP de la réponse du serveur (par exemple, `200`).
1. **`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.
1. **`cs-method`**
Méthode de demande HTTP reçue de l’utilisateur.
1. **`cs-protocol`**
Protocole de la demande de l’utilisateur (`http`, `https`, `grpcs`, `ws` ou `wss`).
1. **`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.
1. **`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](AccessLogs.md), la valeur `cs-uri-stem` n'inclut pas la chaîne de requête.
1. **`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.
1. **`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.)
1. **`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.
1. **`x-host-header`**
Le nom de domaine de la CloudFront distribution (par exemple, d111111abcdef8.cloudfront.net).
1. **`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.
1. **`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`.
1. **`c-ip-version`**
Version IP de la demande (IPv4 ou IPv6).
1. **`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é.
1. **`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.
1. **`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.
1. **`cs-uri-query`**
Partie de la chaîne de requête de l'URL de la demande, le cas échéant.
1. **`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.
+ `LambdaExecutionError`— La fonction Lambda @Edge associée à la distribution ne s'est pas terminée en raison d'une association mal formée, d'un délai d'expiration de la fonction, d'un problème de AWS dépendance ou d'un autre problème de disponibilité générale.
1. **`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 exemple`192.0.2.183`) ou une IPv6 adresse (par exemple,`2001:0db8:85a3::8a2e:0370:7334`).
1. **`ssl-protocol`**
Lorsque la demande a utilisé le protocole HTTPS, ce champ contient le SSL/TLS protocole négocié par le lecteur et le serveur pour transmettre la demande et la réponse. Pour obtenir la liste des valeurs possibles, consultez les SSL/TLS protocoles pris en charge dans[Protocoles et chiffrements pris en charge entre les utilisateurs et CloudFront](secure-connections-supported-viewer-protocols-ciphers.md).
1. **`ssl-cipher`**
Lorsque la demande a utilisé le protocole HTTPS, ce champ contient le SSL/TLS code que le lecteur et le serveur ont négocié pour chiffrer la demande et la réponse. Pour une liste des valeurs possibles, consultez les chiffrements pris en charge dans SSL/TLS . [Protocoles et chiffrements pris en charge entre les utilisateurs et CloudFront](secure-connections-supported-viewer-protocols-ciphers.md)
1. **`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.
+ `LambdaExecutionError`— La fonction Lambda @Edge associée à la distribution ne s'est pas terminée en raison d'une association mal formée, d'un délai d'expiration de la fonction, d'un problème de AWS dépendance ou d'un autre problème de disponibilité générale.
1. **`fle-encrypted-fields`**
Le nombre de [champs de chiffrement au niveau](field-level-encryption.md) 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.
1. **`fle-status`**
Lorsque le [chiffrement au niveau du champ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/field-level-encryption.html) 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 à 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 à 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](cloudfront-limits.md#limits-field-level-encryption).
+ `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é.
1. **`sc-content-type`**
Valeur de l'en-tête `Content-Type` HTTP de la réponse.
1. **`sc-content-len`**
Valeur de l’en-tête `Content-Length` HTTP de la réponse.
1. **`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.
1. **`sc-range-end`**
Lorsque la réponse contient l'en-tête `Content-Range` HTTP, ce champ contient la valeur de fin de plage.
1. **`c-port`**
Numéro de port de la demande depuis l’utilisateur.
1. **`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](origin-shield.md), 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](lambda-at-the-edge.md), 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 SSL/TLS certificat 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.
1. **`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](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2).
1. **`cs-accept-encoding`**
Valeur de l’en-tête `Accept-Encoding` dans la demande de l’utilisateur.
1. **`cs-accept`**
Valeur de l’en-tête `Accept` dans la demande de l’utilisateur.
1. **`cache-behavior-path-pattern`**
Modèle de chemin qui identifie le comportement du cache correspondant à la demande de l'utilisateur.
1. **`cs-headers`**
En-têtes HTTP (noms et valeurs) dans la demande de l'utilisateur.
**Note**
Ce champ est tronqué à 800 octets.
1. **`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.
1. **`cs-headers-count`**
Nombre d'en-têtes HTTP dans la demande de l'utilisateur.
1. **`primary-distribution-id`**
Lorsque le déploiement continu est activé, cet ID identifie la distribution principale dans la distribution actuelle.
1. **`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).
1. **`origin-fbl`**
Le nombre de secondes de latence du premier octet entre CloudFront et votre origine.
1. **`origin-lbl`**
Le nombre de secondes de latence du dernier octet entre CloudFront et votre origine.
1. **`asn`**
Numéro de système autonome (ASN) de l'utilisateur.
1.
**Champs CMCD dans les journaux d'accès 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](https://cdn.cta.tech/cta/media/media/resources/standards/pdfs/cta-5004-final.pdf).
1. **`cmcd-encoded-bitrate`**
Le débit binaire encodé de l’objet audio ou vidéo demandé.
1. **`cmcd-buffer-length`**
La longueur du tampon de l’objet média demandé.
1. **`cmcd-buffer-starvation`**
Indique si le tampon s’est retrouvé à court de données entre la demande précédente et la demande de l’objet. Cela peut entraîner le lecteur dans un état de rebuffering, ce qui peut bloquer la lecture vidéo ou audio.
1. **`cmcd-content-id`**
Une chaîne unique qui identifie le contenu actuel.
1. **`cmcd-object-duration`**
La durée de lecture de l’objet demandé (en millisecondes).
1. **`cmcd-deadline`**
Le délai à compter de la demande dans lequel le premier échantillon de cet objet doit être disponible, afin d’éviter tout état de sous-alimentation du tampon ou tout autre problème de lecture.
1. **`cmcd-measured-throughput`**
Le débit entre le client et le serveur, tel que mesuré par le client.
1. **`cmcd-next-object-request`**
Le chemin d’accès relatif du prochain objet demandé.
1. **`cmcd-next-range-request`**
Si la demande suivante est une demande d’objet partielle, cette chaîne indique la plage d’octets à demander.
1. **`cmcd-object-type`**
Le type de média de l’objet actuellement demandé.
1. **`cmcd-playback-rate`**
1 pour une lecture en temps réel, 2 pour une lecture à double vitesse, 0 lorsque la lecture est arrêtée.
1. **`cmcd-requested-maximum-throughput`**
Le débit maximal demandé que le client considère comme suffisant pour la livraison des ressources.
1. **`cmcd-streaming-format`**
Le format de streaming qui définit la demande en cours.
1. **`cmcd-session-id`**
Un GUID identifiant la session de lecture en cours.
1. **`cmcd-stream-type`**
Jeton identifiant la disponibilité du segment. `v` = tous les segments sont disponibles. `l` = les segments deviennent disponibles au fil du temps.
1. **`cmcd-startup`**
La clé est incluse sans valeur si l’objet est requis de toute urgence lors du démarrage, d’une opération de recherche, ou lors de la récupération après un événement de tampon vide.
1. **`cmcd-top-bitrate`**
La version au débit binaire le plus élevé que le client peut lire.
1. **`cmcd-version`**
La 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.
1. **`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`.
1. **`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.
Si un basculement d’origine se produit, le champ contiendra le code d’erreur HTTP ayant provoqué le basculement, comme `Failover:403` ou `Failover:502`. En cas de basculement d’origine, si la demande réessayée échoue également et que vous n’avez pas configuré de pages d’erreur personnalisées, alors `r-status` indique la réponse de la deuxième origine. Toutefois, si vous avez configuré des pages d’erreur personnalisées en plus du basculement d’origine, ce champ contiendra la réponse de la seconde origine si la demande a échoué et qu’une page d’erreur personnalisée a été renvoyée à la place.
S’il n’y a pas de basculement, mais qu’une sélection d’origine MQAR (résilience tenant compte de la qualité média) est effectuée, l’entrée sera enregistrée sous `MediaQuality`. Pour de plus amples informations, veuillez consulter [Résilience tenant compte de la qualité média](media-quality-score.md).
1. **`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 tenant compte de la qualité média](media-quality-score.md).
1. **`distribution-tenant-id`**
L’ID du locataire de distribution.
1. **`connection-id`**
Identifiant unique pour la connexion TLS.
Vous devez activer les MTLs pour vos distributions avant de pouvoir obtenir des informations pour ce champ. Pour de plus amples informations, veuillez consulter [Authentification TLS mutuelle avec CloudFront (Viewer MTLS)Origin Mutual TLS avec CloudFront](mtls-authentication.md).
### Point de terminaison (Kinesis Data Streams)
Le point de terminaison contient des informations sur le Kinesis Data Streams dans lequel 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 *Guide de l’utilisateur Amazon Kinesis Data Streams*.
+ [Création et gestion de flux](https://docs.aws.amazon.com/streams/latest/dev/working-with-streams.html)
+ [Effectuez des opérations de base sur Kinesis Data Streams à l'aide du AWS CLI](https://docs.aws.amazon.com/streams/latest/dev/fundamental-stream.html)
+ [Création d'un flux](https://docs.aws.amazon.com/streams/latest/dev/kinesis-using-sdk-java-create-stream.html) (utilise le AWS SDK pour 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**
1. Calculez (ou estimez) le nombre de demandes par seconde que votre distribution CloudFront reçoit.
Vous pouvez utiliser les [rapports CloudFront d'utilisation](https://console.aws.amazon.com/cloudfront/v4/home#/usage) (dans la CloudFront console) et les [CloudFront métriques](viewing-cloudfront-metrics.md#monitoring-console.distributions) (dans les CloudWatch consoles CloudFront et Amazon) pour vous aider à calculer le nombre de demandes par seconde.
1. Déterminez la taille typique d'un seul enregistrement de journal d'accès 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).
1. Sur la page de [tarification d'Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/pricing/), 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 moyenne d’un enregistrement de journal individuel.
+ Sélectionnez **Afficher les calculs**.
Le calculateur de tarification vous indique le nombre de partitions nécessaire et le coût estimé.
### Rôle IAM
Rôle Gestion des identités et des accès AWS (IAM) qui donne l' CloudFront autorisation de fournir des journaux d'accès en temps réel à votre flux de données Kinesis.
Lorsque vous créez une configuration de journal d'accès 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 d'accès 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html), car ils ne CloudFront peuvent assumer ce rôle qu'au nom d'une distribution de votre entreprise Compte AWS.
------
#### [ JSON ]
****
```
{
"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.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kinesis:DescribeStreamSummary",
"kinesis:DescribeStream",
"kinesis:PutRecord",
"kinesis:PutRecords"
],
"Resource": [
"arn:aws:kinesis:us-east-2:123456789012:stream/StreamName"
]
}
]
}
```
------
**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
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kinesis:DescribeStreamSummary",
"kinesis:DescribeStream",
"kinesis:PutRecord",
"kinesis:PutRecords"
],
"Resource": [
"arn:aws:kinesis:us-east-2:123456789012:stream/StreamName"
]
},
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": [
"arn:aws:kms:us-east-2:123456789012:key/e58a3d0b-fe4f-4047-a495-ae03cc73d486"
]
}
]
}
```
------
****
## Création d’un consommateur Kinesis Data Streams
Pour lire et analyser vos journaux d'accès en temps réel, vous créez ou utilisez un client 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 d'accès en temps réel sont toujours livrés dans le même ordre, comme indiqué dans la [Champs](#real-time-logs-fields) section. Assurez-vous que vous créez votre consommateur en fonction de cet ordre fixe.
Par exemple, considérez une configuration de journal d'accès 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 d'accès 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 d'accès en temps réel, ces champs sont insérés dans chaque enregistrement du journal conformément à l'ordre indiqué dans la [Champs](#real-time-logs-fields) section. 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 à la configuration de votre journal d'accès en temps réel.
## Résolution des problèmes liés aux journaux d'accès en temps réel
Après avoir créé une configuration de journal d'accès en temps réel, vous constaterez peut-être qu'aucun enregistrement (ou pas tous les enregistrements) n'est transmis à 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 journaux d'accès en temps réel à votre flux de données Kinesis, CloudFront utilisez le rôle IAM dans la configuration du journal d'accès 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](#real-time-logs-IAM).
**Limitation des Kinesis Data Streams**
Si CloudFront les enregistrements du journal d'accès en temps réel sont écrits 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.