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.
# CloudFront et journalisation des fonctions Edge
Amazon CloudFront propose différents types de journalisation. Vous pouvez enregistrer les demandes des utilisateurs qui arrivent à vos CloudFront distributions, ou vous pouvez enregistrer l'activité du CloudFront service (activité de l'API) dans votre AWS compte. Vous pouvez également obtenir des journaux à partir de vos CloudFront fonctions Functions et Lambda @Edge.
## Demandes d'enregistrement
CloudFront fournit les méthodes suivantes pour enregistrer les demandes envoyées à vos distributions.
**Journaux d'accès (journaux standard)**
CloudFrontles journaux d'accès fournissent des informations détaillées sur chaque demande adressée à une distribution. Vous pouvez utiliser les journaux pour des scénarios, tels que des audits de sécurité et d’accès.
CloudFrontles journaux d'accès sont envoyés à la destination de livraison que vous spécifiez.
Utilisez les journaux d'accès lorsque vous avez besoin de :
+ Analyse historique et rapports
+ Audits de sécurité et exigences de conformité
+ Conservation rentable des journaux à long terme
Pour de plus amples informations, veuillez consulter [Journaux d'accès (journaux standard)](AccessLogs.md).
**Journaux d’accès en temps réel**
CloudFrontles journaux d'accès en temps réel sont fournis quelques secondes après réception des demandes et fournissent des informations sur les demandes adressées à une distribution en temps réel. Vous pouvez choisir le *taux d'échantillonnage* pour vos journaux d'accès 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. Vous pouvez également choisir les champs que vous souhaitez recevoir dans les enregistrements de journaux. Les journaux d'accès en temps réel sont idéaux pour surveiller en direct les performances de diffusion de contenu.
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. 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.
Utilisez des journaux d'accès en temps réel lorsque vous avez besoin de :
+ Surveillance et alertes en temps réel
+ Tableaux de bord en direct et informations opérationnelles
Pour de plus amples informations, veuillez consulter [Utiliser des journaux d'accès en temps réel](real-time-logs.md).
**Journaux de connexion.**
Les journaux de connexion fournissent des informations détaillées sur la connexion entre le serveur et le client pour les distributions compatibles mTLS. Les journaux de connexion fournissent une visibilité sur les informations relatives aux certificats clients, les raisons des échecs d'authentification MTL et indiquent si une connexion a été autorisée ou refusée.
Tout comme les journaux d'accès (journaux standard), les journaux de connexion sont envoyés à la destination de livraison que vous spécifiez.
Pour activer les journaux de connexion, vous devez d'abord [activer les MTL](mtls-authentication.md) pour votre distribution.
Utilisez les journaux de connexion lorsque vous avez besoin de :
+ Raisons de la réussite ou de l'échec des connexions lors de la prise de contact TLS
+ Visibilité des informations relatives aux certificats clients
Pour de plus amples informations, veuillez consulter [Observabilité à l'aide des journaux de connexion](connection-logs.md).
## Journalisation des fonctions de périphérie
Vous pouvez utiliser Amazon CloudWatch Logs pour obtenir les journaux de vos fonctions périphériques, à la fois Lambda @Edge et CloudFront Functions. Vous pouvez accéder aux journaux à l'aide de la CloudWatch console ou de l'API CloudWatch Logs. Pour de plus amples informations, veuillez consulter [Journaux des fonctions de périphérie](edge-functions-logs.md).
## Activité de service de journalisation
Vous pouvez l'utiliser AWS CloudTrail pour enregistrer l'activité du CloudFront service (activité de l'API) dans votre AWS compte. CloudTrail fournit un enregistrement des actions d'API effectuées par un utilisateur, un rôle ou un AWS service dans CloudFront. À l'aide des informations collectées par CloudTrail, vous pouvez déterminer la demande d'API qui a été faite CloudFront, l'adresse IP à partir de laquelle la demande a été faite, qui a fait la demande, quand elle a été faite et des détails supplémentaires.
Pour de plus amples informations, veuillez consulter [Journalisation des appels CloudFront d'API Amazon à l'aide AWS CloudTrail](logging_using_cloudtrail.md).
Pour plus d’informations sur la journalisation, consultez les rubriques suivantes :
**Topics**
+ [Demandes d'enregistrement](#logging-requests)
+ [Journalisation des fonctions de périphérie](#logging-edge-functions)
+ [Activité de service de journalisation](#logging-service-activity)
+ [Journaux d'accès (journaux standard)](AccessLogs.md)
+ [Utiliser des journaux d'accès en temps réel](real-time-logs.md)
+ [Journaux des fonctions de périphérie](edge-functions-logs.md)
+ [Journalisation des appels CloudFront d'API Amazon à l'aide AWS CloudTrail](logging_using_cloudtrail.md)
# Journaux d'accès (journaux standard)
Vous pouvez configurer CloudFront pour créer des fichiers journaux contenant des informations détaillées sur chaque demande d'utilisateur (spectateur) CloudFront reçue. Ils sont appelés *journaux d'accès*, également appelés *journaux standard*.
Chaque journal contient des informations comme l’heure à laquelle la demande a été reçue, l’heure du traitement, les chemins de demande et les réponses du serveur. Vous pouvez utiliser ces journaux d’accès pour analyser les modèles de trafic et résoudre des problèmes.
Le schéma suivant montre comment CloudFront enregistre les informations relatives aux demandes relatives à vos objets. Dans cet exemple, les distributions sont configurées pour envoyer les journaux d’accès vers un compartiment Amazon S3.
![\[Flux de base pour les journaux d’accès\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/images/Logging.png)
1. Dans cet exemple, vous avez deux sites Web, A et B, et deux CloudFront distributions correspondantes. Les utilisateurs demandent vos objets en utilisant URLs ceux qui sont associés à vos distributions.
1. CloudFront achemine chaque demande vers l'emplacement périphérique approprié.
1. CloudFront écrit les données relatives à chaque demande dans un fichier journal spécifique à cette distribution. Dans cet exemple, les informations sur les demandes associées à Distribution A vont dans un fichier journal réservé à Distribution A et celles sur les demandes associées à Distribution B dans un fichier journal réservé à Distribution B.
1. CloudFront enregistre régulièrement le fichier journal d'une distribution dans le compartiment Amazon S3 que vous avez spécifié lorsque vous avez activé la journalisation. CloudFront commence ensuite à enregistrer les informations relatives aux demandes suivantes dans un nouveau fichier journal pour la distribution.
Si aucun utilisateur n’accède à votre contenu pendant une heure donnée, vous ne recevez aucun fichier journal pour cette heure.
**Note**
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 dans la mesure du possible. 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. Quand une entrée du journal est omise des journaux d'accès, le nombre d'entrées des journaux d'accès ne correspond pas à l'utilisation qui apparaît dans les rapports d'utilisation et de facturation AWS .
CloudFront prend en charge deux versions de journalisation standard. La journalisation standard (héritée) prend *uniquement* en charge l’envoi des journaux d’accès vers Amazon S3. La journalisation standard (v2) prend en charge des destinations de livraison supplémentaires. Vous pouvez configurer les deux options de journalisation, ou seulement l’une d’entre elles, pour votre distribution. Pour plus d’informations, consultez les rubriques suivantes :
**Topics**
+ [Configuration de la journalisation standard (v2)](standard-logging.md)
+ [Configurer la journalisation standard (héritée)](standard-logging-legacy-s3.md)
+ [Référence de la journalisation standard](standard-logs-reference.md)
**Astuce**
CloudFront propose également des journaux d'accès en temps réel, qui vous fournissent 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. Pour de plus amples informations, veuillez consulter [Utiliser des journaux d'accès en temps réel](real-time-logs.md).
# Configuration de la journalisation standard (v2)
Vous pouvez activer les journaux d'accès (journaux standard) lorsque vous créez ou mettez à jour une distribution. La journalisation standard (v2) comprend les fonctionnalités suivantes :
+ Envoyez les journaux d'accès à Amazon CloudWatch Logs, Amazon Data Firehose et Amazon Simple Storage Service (Amazon S3).
+ La sélection des champs de journal souhaités. Vous pouvez également sélectionner un [sous-ensemble de champs du journal d'accès en temps réel](#standard-logging-real-time-log-selection).
+ La sélection d’autres formats de [fichiers journaux de sortie](#supported-log-file-format).
Si vous utilisez Amazon S3, vous disposez des fonctionnalités optionnelles suivantes :
+ Envoyez des journaux pour vous inscrire. Régions AWS
+ Organisation des journaux à l’aide du partitionnement.
+ Activation des noms de fichiers compatibles avec Hive.
Pour plus d’informations, consultez [Envoi de journaux vers Amazon S3](#send-logs-s3).
Pour commencer avec la journalisation standard, procédez comme suit :
1. Configurez les autorisations requises pour la personne spécifiée Service AWS qui recevra vos journaux.
1. Configurez la journalisation standard depuis la CloudFront console ou l' CloudWatch API.
1. Affichez vos journaux d’accès.
**Note**
L’activation de la journalisation standard (v2) n’a aucun impact sur la journalisation standard (héritée). Vous pouvez continuer à utiliser la journalisation standard (héritée) pour votre distribution, en plus de la journalisation standard (v2). Pour plus d’informations, consultez [Configurer la journalisation standard (héritée)](standard-logging-legacy-s3.md).
Si vous utilisez déjà la journalisation standard (héritée) et que vous souhaitez activer la journalisation standard (v2) sur Amazon S3, nous vous conseillons d’indiquer un compartiment Amazon S3 *différent* ou d’utiliser un *chemin distinct* dans le même compartiment (par exemple, un préfixe de journal ou un partitionnement). Vous pouvez ainsi facilement identifier les fichiers journaux associés à chaque distribution, tout en évitant qu’ils ne se remplacent mutuellement.
## Permissions
CloudFront utilise des CloudWatch journaux vendus pour fournir des journaux d'accès. Pour ce faire, vous devez disposer des autorisations relatives à ce qui Service AWS est spécifié afin de pouvoir activer la livraison des journaux.
Pour connaître les autorisations requises pour chaque destination de journalisation, choisissez l'une des rubriques suivantes dans le *guide de l'utilisateur Amazon CloudWatch Logs*.
+ [CloudWatch Journaux](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-CloudWatchLogs)
+ [Firehose](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-Firehose)
+ [Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-S3)
Une fois les autorisations configurées pour votre destination de journalisation, vous pouvez activer la journalisation standard sur votre distribution.
**Note**
CloudFront prend en charge l'envoi de journaux d'accès à différents Comptes AWS (comptes croisés). Pour activer la livraison entre comptes, les deux comptes (le vôtre et celui du destinataire) doivent disposer des autorisations requises. Pour plus d'informations, consultez la [Activation de la journalisation standard pour la livraison entre comptes](#enable-standard-logging-cross-accounts) section ou l'[exemple de livraison entre comptes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#vended-logs-crossaccount-example) dans le *guide de l'utilisateur Amazon CloudWatch Logs*.
## Activation de la journalisation standard
Pour activer la journalisation standard, vous pouvez utiliser la CloudFront console ou l' CloudWatch API.
**Contents**
+ [Activer la journalisation standard (CloudFront console)](#access-logging-console)
+ [Activer la journalisation standard (CloudWatch API)](#enable-access-logging-api)
### Activer la journalisation standard (CloudFront console)
**Pour activer la journalisation standard pour une CloudFront distribution (console)**
1. Utilisez la CloudFront console pour mettre [à jour une distribution existante](HowToUpdateDistribution.md#HowToUpdateDistributionProcedure).
1. Sélectionnez l'onglet **Logging** (Journalisation).
1. Choisissez **Ajouter**, puis sélectionnez le service qui recevra vos journaux :
+ CloudWatch Journaux
+ Firehose
+ Amazon S3
1. Pour la **Destination**, sélectionnez la ressource correspondant à votre service. Si vous n’avez pas encore créé votre ressource, vous pouvez sélectionner **Créer** ou consulter la documentation ci-dessous.
+ Pour CloudWatch Logs, entrez le **[nom du groupe de logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html)**.
+ Pour Firehose, saisissez le **[Flux de diffusion Firehose](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html)**.
+ Pour Amazon S3, saisissez le **[Nom du compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)**.
**Astuce**
Pour ajouter un préfixe, saisissez-le après le nom du compartiment, par exemple `amzn-s3-demo-bucket.s3.amazonaws.com/MyLogPrefix`. Si vous ne spécifiez pas de préfixe, il en CloudFront ajoutera automatiquement un pour vous. Pour de plus amples informations, veuillez consulter [Envoi de journaux vers Amazon S3](#send-logs-s3).
1. Pour **Paramètres supplémentaires – *facultatif***, vous pouvez définir les options suivantes :
1. Pour la **Sélection des champs**, sélectionnez les noms de champs de journaux que vous souhaitez envoyer vers votre destination. Vous pouvez sélectionner les [champs du journal d'accès](standard-logs-reference.md#BasicDistributionFileFormat) et un sous-ensemble de [champs du journal d'accès en temps réel](#standard-logging-real-time-log-selection).
1. (Amazon S3 uniquement) Pour le **Partitionnement**, indiquez le chemin permettant de partitionner les données de votre fichier journal.
1. (Amazon S3 uniquement) Pour le **Format de nom de fichier compatible avec hive**, vous pouvez cocher la case afin d’utiliser des chemins S3 compatibles avec Hive. Vous pourrez ainsi charger plus facilement de nouvelles données dans vos outils compatibles avec Hive.
1. Pour **Format de sortie**, indiquez le format que vous souhaitez utiliser.
**Note**
Si vous choisissez **Parquet**, cette option entraîne des CloudWatch frais pour la conversion de vos journaux d'accès vers Apache Parquet. Pour plus d'informations, consultez la [section Vended Logs pour CloudWatch connaître les tarifs](https://aws.amazon.com/cloudwatch/pricing/).
1. Pour **Délimiteur de champ**, indiquez comment séparer les champs du journal.
1. Terminez les étapes pour mettre à jour ou créer votre distribution.
1. Pour ajouter une autre destination, répétez les étapes 3 à 6.
1. Sur la page **Journaux**, vérifiez que l’état des journaux standard est défini sur **Activé** à côté de la distribution.
1. (Facultatif) Pour activer l’enregistrement des cookies, choisissez **Gérer**, **Paramètres** et activez **Journalisation des cookies**, puis sélectionnez **Enregistrer les modifications**.
**Astuce**
La journalisation des cookies est un paramètre global qui s’applique à *l’ensemble* de la journalisation standard de votre distribution. Vous ne pouvez pas remplacer ce paramètre pour des destinations de livraison distinctes.
Pour plus d’informations sur la livraison de la journalisation standard et les champs de journal, consultez la [Référence de la journalisation standard](standard-logs-reference.md).
### Activer la journalisation standard (CloudWatch API)
Vous pouvez également utiliser l' CloudWatch API pour activer la journalisation standard pour vos distributions.
**Remarques**
Lorsque vous appelez l' CloudWatch API pour activer la journalisation standard, vous devez spécifier la région des États-Unis Est (Virginie du Nord`us-east-1`) (), même si vous souhaitez activer la livraison entre régions vers une autre destination. Par exemple, si vous souhaitez envoyer vos journaux d'accès à un compartiment S3 dans la région Europe (Irlande) `eu-west-1` (), utilisez CloudWatch l'API de `us-east-1` la région.
Une option supplémentaire permet d’inclure les cookies dans la journalisation standard. Dans l' CloudFront API, il s'agit du `IncludeCookies` paramètre. Si vous configurez la journalisation des accès à l'aide de l' CloudWatch API et que vous spécifiez que vous souhaitez inclure des cookies, vous devez utiliser la CloudFront console ou l' CloudFront API pour mettre à jour votre distribution afin d'inclure les cookies. Dans le cas contraire, CloudFront vous ne pourrez pas envoyer de cookies à la destination de votre journal. Pour de plus amples informations, veuillez consulter [Journalisation des cookies](DownloadDistValuesGeneral.md#DownloadDistValuesCookieLogging).
**Pour activer la journalisation standard pour une distribution (CloudWatch API)**
1. Après avoir créé une distribution, récupérez l’Amazon Resource Name (ARN).
Vous pouvez trouver l'ARN sur la page de **distribution** de la CloudFront console ou vous pouvez utiliser l'opération [GetDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_GetDistribution.html)API. L’ARN d’une distribution suit le format suivant : `arn:aws:cloudfront::123456789012:distribution/d111111abcdef8`
1. Utilisez ensuite l'opération CloudWatch [PutDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html)API pour créer une source de diffusion pour la distribution.
1. Entrez un nom pour la source de livraison.
1. Indiquez le `resourceArn` de la distribution.
1. Pour `logType`, indiquez `ACCESS_LOGS` comme type de journaux à collecter.
1.
**Example Exemple de AWS CLI put-delivery-source commande**
Voici un exemple de configuration d’une source de livraison pour une distribution.
```
aws logs put-delivery-source --name S3-delivery --resource-arn arn:aws:cloudfront::123456789012:distribution/d111111abcdef8 --log-type ACCESS_LOGS
```
**Sortie**
```
{
"deliverySource": {
"name": "S3-delivery",
"arn": "arn:aws:logs:us-east-1:123456789012:delivery-source:S3-delivery",
"resourceArns": [
"arn:aws:cloudfront::123456789012:distribution/d111111abcdef8"
],
"service": "cloudfront",
"logType": "ACCESS_LOGS"
}
}
```
1. Utilisez l'opération [PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html)API pour configurer l'emplacement de stockage de vos journaux.
1. Renseignez l’ARN de la destination dans le paramètre `destinationResourceArn`. Il peut s'agir d'un groupe de CloudWatch journaux, d'un flux de diffusion Firehose ou d'un compartiment Amazon S3.
1. Indiquez le format de sortie de vos journaux dans le paramètre `outputFormat`.
1.
**Example Exemple de AWS CLI put-delivery-destination commande**
Voici un exemple de configuration d’une destination de livraison vers un compartiment Amazon S3.
```
aws logs put-delivery-destination --name S3-destination --delivery-destination-configuration destinationResourceArn=arn:aws:s3:::amzn-s3-demo-bucket
```
**Sortie**
```
{
"name": "S3-destination",
"arn": "arn:aws:logs:us-east-1:123456789012:delivery-destination:S3-destination",
"deliveryDestinationType": "S3",
"deliveryDestinationConfiguration": {
"destinationResourceArn": "arn:aws:s3:::amzn-s3-demo-bucket"
}
}
```
**Note**
Si vous distribuez des journaux entre comptes, vous devez utiliser l'opération [PutDeliveryDestinationPolicy](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestinationPolicy.html)API pour attribuer une politique Gestion des identités et des accès AWS (IAM) au compte de destination. La politique IAM autorise la livraison d’un compte à un autre.
1. Utilisez l'opération [CreateDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html)API pour lier la source de livraison à la destination que vous avez créée lors des étapes précédentes. Cette opération d’API associe la source de livraison à la destination finale.
1. Indiquez le nom de la source dans le paramètre `deliverySourceName`.
1. Indiquez l’ARN correspondant à la destination de livraison dans le paramètre `deliveryDestinationArn`.
1. Indiquez la chaîne qui séparera les champs du journal dans le paramètre `fieldDelimiter`.
1. Indiquez les champs de journal souhaités dans le paramètre `recordFields`.
1. Si vous utilisez S3, indiquez s’il faut activer `enableHiveCompatiblePath` et `suffixPath`.
**Example Exemple de commande de AWS CLI création et de livraison**
Voici un exemple de création d’une livraison.
```
aws logs create-delivery --delivery-source-name cf-delivery --delivery-destination-arn arn:aws:logs:us-east-1:123456789012:delivery-destination:S3-destination
```
**Sortie**
```
{
"id": "abcNegnBoTR123",
"arn": "arn:aws:logs:us-east-1:123456789012:delivery:abcNegnBoTR123",
"deliverySourceName": "cf-delivery",
"deliveryDestinationArn": "arn:aws:logs:us-east-1:123456789012:delivery-destination:S3-destination",
"deliveryDestinationType": "S3",
"recordFields": [
"date",
"time",
"x-edge-location",
"sc-bytes",
"c-ip",
"cs-method",
"cs(Host)",
"cs-uri-stem",
"sc-status",
"cs(Referer)",
"cs(User-Agent)",
"cs-uri-query",
"cs(Cookie)",
"x-edge-result-type",
"x-edge-request-id",
"x-host-header",
"cs-protocol",
"cs-bytes",
"time-taken",
"x-forwarded-for",
"ssl-protocol",
"ssl-cipher",
"x-edge-response-result-type",
"cs-protocol-version",
"fle-status",
"fle-encrypted-fields",
"c-port",
"time-to-first-byte",
"x-edge-detailed-result-type",
"sc-content-type",
"sc-content-len",
"sc-range-start",
"sc-range-end",
"c-country",
"cache-behavior-path-pattern"
],
"fieldDelimiter": ""
}
```
1. Depuis la CloudFront console, sur la page **Logs**, vérifiez que le statut standard des logs est **Activé** à côté de la distribution.
Pour plus d’informations sur la livraison de la journalisation standard et les champs de journal, consultez la [Référence de la journalisation standard](standard-logs-reference.md).
**Note**
Pour activer la journalisation standard (v2) pour CloudFront en utilisant AWS CloudFormation, vous pouvez utiliser les propriétés de CloudWatch journalisation suivantes :
[Delivery](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-delivery.html)
[DeliveryDestination](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverydestination.html)
[DeliverySource](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverysource.html)
`ResourceArn`Il s'agit de la CloudFront distribution et `LogType` doit correspondre `ACCESS_LOGS` au type de journal pris en charge.
## Activation de la journalisation standard pour la livraison entre comptes
Si vous activez la journalisation standard pour votre compte Compte AWS et que vous souhaitez transmettre vos journaux d'accès à un autre compte, assurez-vous de configurer correctement le compte source et le compte de destination. Le *compte source* associé à la CloudFront distribution envoie ses journaux d'accès au *compte de destination*.
Dans cet exemple de procédure, le *111111111111* (compte source) envoie ses journaux d'accès à un compartiment Amazon S3 du compte de destination (*222222222222*). Pour envoyer les journaux d’accès vers un compartiment Amazon S3 dans le compte de destination, utilisez l’ AWS CLI.
### Configuration du compte de destination
Exécutez la procédure ci-dessous pour le compte de destination.
**Pour configurer le compte de destination**
1. Pour créer la destination de livraison des journaux, vous pouvez saisir la commande de l’ AWS CLI suivante. Cet exemple utilise la chaîne `MyLogPrefix` pour créer un préfixe pour vos journaux d’accès.
```
aws logs put-delivery-destination --name cloudfront-delivery-destination --delivery-destination-configuration "destinationResourceArn=arn:aws:s3:::amzn-s3-demo-bucket-cloudfront-logs/MyLogPrefix"
```
**Sortie**
```
{
"deliveryDestination": {
"name": "cloudfront-delivery-destination",
"arn": "arn:aws:logs:us-east-1:222222222222:delivery-destination:cloudfront-delivery-destination",
"deliveryDestinationType": "S3",
"deliveryDestinationConfiguration": {"destinationResourceArn": "arn:aws:s3:::amzn-s3-demo-bucket-cloudfront-logs/MyLogPrefix"}
}
}
```
**Note**
Si vous spécifiez un compartiment S3 *sans* préfixe, il CloudFront sera automatiquement ajouté en `AWSLogs//CloudFront` tant que préfixe qui apparaît dans la destination `suffixPath` de livraison S3. Pour plus d'informations, consultez [S3 DeliveryConfiguration](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_S3DeliveryConfiguration.html).
1. Ajoutez la politique de ressource pour la destination de livraison des journaux afin d’autoriser le compte source à créer une livraison de journaux.
Dans la politique suivante, remplacez-le *111111111111* par l'ID du compte source et spécifiez l'ARN de destination de livraison à partir de la sortie de l'étape 1.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCreateDelivery",
"Effect": "Allow",
"Principal": {"AWS": "111111111111"},
"Action": ["logs:CreateDelivery"],
"Resource": "arn:aws:logs:us-east-1:222222222222:delivery-destination:cloudfront-delivery-destination"
}
]
}
```
------
1. Enregistrez le fichier, par exemple sous le nom `deliverypolicy.json`.
1. Pour associer la politique précédente à la destination de livraison, entrez la AWS CLI commande suivante.
```
aws logs put-delivery-destination-policy --delivery-destination-name cloudfront-delivery-destination --delivery-destination-policy file://deliverypolicy.json
```
1. Ajoutez l’instruction ci-dessous à la stratégie de compartiment Amazon S3 de destination, en remplaçant l’ARN de la ressource et l’ID du compte source. Cette stratégie autorise le principal de service `delivery.logs.amazonaws.com` à effectuer l’action `s3:PutObject`.
```
{
"Sid": "AWSLogsDeliveryWrite",
"Effect": "Allow",
"Principal": {"Service": "delivery.logs.amazonaws.com"},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-cloudfront-logs/*",
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceAccount": "111111111111"
},
"ArnLike": {"aws:SourceArn": "arn:aws:logs:us-east-1:111111111111:delivery-source:*"}
}
}
```
1. Si vous l'utilisez AWS KMS pour votre compartiment, ajoutez la déclaration suivante à la politique des clés KMS pour accorder des autorisations au principal du `delivery.logs.amazonaws.com` service.
```
{
"Sid": "Allow Logs Delivery to use the key",
"Effect": "Allow",
"Principal": {"Service": "delivery.logs.amazonaws.com"},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {"aws:SourceAccount": "111111111111"},
"ArnLike": {"aws:SourceArn": "arn:aws:logs:us-east-1:111111111111:delivery-source:*"}
}
}
```
### Configuration du compte source
Une fois le compte de destination configuré, suivez cette procédure pour créer la source de livraison et activer la journalisation pour la distribution dans le compte source.
**Pour configurer le compte source**
1. Créez une source de diffusion pour la journalisation CloudFront standard afin de pouvoir envoyer des fichiers CloudWatch journaux à Logs.
Vous pouvez entrer la AWS CLI commande suivante en remplaçant le nom et l'ARN de votre distribution.
```
aws logs put-delivery-source --name s3-cf-delivery --resource-arn arn:aws:cloudfront::111111111111:distribution/E1TR1RHV123ABC --log-type ACCESS_LOGS
```
**Sortie**
```
{
"deliverySource": {
"name": "s3-cf-delivery",
"arn": "arn:aws:logs:us-east-1:111111111111:delivery-source:s3-cf-delivery",
"resourceArns": ["arn:aws:cloudfront::111111111111:distribution/E1TR1RHV123ABC"],
"service": "cloudfront",
"logType": "ACCESS_LOGS"
}
}
```
1. Créez une livraison pour associer la source de livraison des journaux du compte source à la destination de livraison des journaux du compte de destination.
Dans la AWS CLI commande suivante, spécifiez l'ARN de destination de livraison à partir de la sortie de l'[étape 1 : Configurer le compte de destination](#steps-destination-account).
```
aws logs create-delivery --delivery-source-name s3-cf-delivery --delivery-destination-arn arn:aws:logs:us-east-1:222222222222:delivery-destination:cloudfront-delivery-destination
```
**Sortie**
```
{
"delivery": {
"id": "OPmOpLahVzhx1234",
"arn": "arn:aws:logs:us-east-1:111111111111:delivery:OPmOpLahVzhx1234",
"deliverySourceName": "s3-cf-delivery",
"deliveryDestinationArn": "arn:aws:logs:us-east-1:222222222222:delivery-destination:cloudfront-delivery-destination",
"deliveryDestinationType": "S3",
"recordFields": [
"date",
"time",
"x-edge-location",
"sc-bytes",
"c-ip",
"cs-method",
"cs(Host)",
"cs-uri-stem",
"sc-status",
"cs(Referer)",
"cs(User-Agent)",
"cs-uri-query",
"cs(Cookie)",
"x-edge-result-type",
"x-edge-request-id",
"x-host-header",
"cs-protocol",
"cs-bytes",
"time-taken",
"x-forwarded-for",
"ssl-protocol",
"ssl-cipher",
"x-edge-response-result-type",
"cs-protocol-version",
"fle-status",
"fle-encrypted-fields",
"c-port",
"time-to-first-byte",
"x-edge-detailed-result-type",
"sc-content-type",
"sc-content-len",
"sc-range-start",
"sc-range-end",
"c-country",
"cache-behavior-path-pattern"
],
"fieldDelimiter": "\t"
}
}
```
1. Vérifiez que votre livraison entre comptes s’est déroulée correctement.
1. Depuis le *source* compte, connectez-vous à la CloudFront console et choisissez votre distribution. Dans l’onglet **Journalisation**, la section **Type** affichera une entrée créée pour la livraison de journaux S3 entre comptes.
1. Depuis le *destination* compte, connectez-vous à la console Amazon S3 et choisissez votre compartiment Amazon S3. Le préfixe `MyLogPrefix` apparaîtra dans le nom du compartiment et dans chaque journal d’accès livré dans ce dossier.
## Format du fichier de sortie
En fonction de la destination de livraison que vous choisissez, vous pouvez spécifier l’un des formats suivants pour les fichiers journaux :
+ JSON
+ Plain
+ w3c
+ Raw
+ Parquet (Amazon S3 uniquement)
**Note**
Vous ne pouvez définir le format de sortie que lorsque vous créez la destination de livraison pour la première fois. Cet élément ne peut pas être mis à jour ultérieurement. Pour modifier le format de sortie, supprimez la livraison et créez-en une autre.
Pour plus d'informations, consultez [PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html)le manuel *Amazon CloudWatch Logs API Reference*.
## Modification des paramètres de journalisation standard
Vous pouvez activer ou désactiver la journalisation et mettre à jour les autres paramètres de journalisation à l'aide de la [CloudFront console](https://console.aws.amazon.com/cloudfront/v4/home) ou de l' CloudWatch API. Les modifications apportées aux paramètres de journalisation prennent effet dans les 12 heures.
Pour plus d’informations, consultez les rubriques suivantes :
+ Pour mettre à jour une distribution à l'aide de la CloudFront console, consultez[Mettre à jour une distribution](HowToUpdateDistribution.md).
+ Pour mettre à jour une distribution à l'aide de l' CloudFront API, consultez [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)le *Amazon CloudFront API Reference*.
+ Pour plus d'informations sur CloudWatch les opérations de l'API Logs, consultez le manuel [Amazon CloudWatch Logs API Reference](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/Welcome.html).
## Accès aux champs de journal
Vous pouvez sélectionner les mêmes champs de journal que ceux pris en charge par la journalisation standard (héritée). Pour plus d’informations, consultez [Champs d’un fichier journal](standard-logs-reference.md#BasicDistributionFileFormat).
En outre, vous pouvez sélectionner les [champs du journal d'accès en temps réel](real-time-logs.md#understand-real-time-log-config) suivants.
1. `timestamp(ms)` : horodatage en millisecondes.
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` : le numéro de système autonome (ASN) de l’utilisateur.
1. `c-country` : un 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. `cache-behavior-path-pattern` : le modèle de chemin qui identifie le comportement du cache correspondant à la demande de l’utilisateur.
## Envoyer des journaux à CloudWatch Logs
Pour envoyer des CloudWatch journaux à Logs, créez ou utilisez un groupe de CloudWatch journaux Logs existant. Pour plus d'informations sur la configuration d'un groupe de CloudWatch journaux, consultez la section [Utilisation des groupes de journaux et des flux de journaux](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html).
Après avoir créé votre groupe de journaux, vous devez disposer des autorisations nécessaires pour activer la journalisation standard. Pour plus d'informations sur les autorisations requises, consultez la section [Logs envoyés à CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-CloudWatchLogs) dans le *guide de l'utilisateur Amazon CloudWatch Logs*.
**Remarques**
Lorsque vous spécifiez le nom du groupe de CloudWatch journaux Logs, utilisez uniquement le modèle `[\w-]` regex. Pour plus d'informations, consultez le fonctionnement de l'[PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html#API_PutDeliveryDestination_RequestSyntax)API dans le manuel *Amazon CloudWatch Logs API Reference*.
Vérifiez que la politique de ressources de votre groupe de journaux ne dépasse pas la limite de taille autorisée. Consultez la section [Considérations relatives à la limite de taille des ressources liées à la politique des groupes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-CloudWatchLogs) de CloudWatch journaux dans la rubrique Journaux.
### Exemple de journal d'accès envoyé à CloudWatch Logs
```
{
"date": "2024-11-14",
"time": "21:34:06",
"x-edge-location": "SOF50-P2",
"asn": "16509",
"timestamp(ms)": "1731620046814",
"origin-fbl": "0.251",
"origin-lbl": "0.251",
"x-host-header": "d111111abcdef8.cloudfront.net",
"cs(Cookie)": "examplecookie=value"
}
```
## Envoi des journaux à Firehose
Pour envoyer des journaux à Firehose, créez ou utilisez un flux de diffusion Firehose existant. Indiquez ensuite le flux de diffusion Firehose comme destination de livraison des journaux. Vous devez indiquer un flux de diffusion Firehose situé dans la région USA Est (Virginie du Nord).
Pour en savoir plus sur la création des flux de diffusion, consultez [Création d’un flux de diffusion Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html).
Après avoir créé votre flux de diffusion, vous devez disposer des autorisations nécessaires pour activer la journalisation standard. Pour plus d'informations, consultez la section [Logs envoyés à Firehose](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-Firehose) dans le guide de *l'utilisateur Amazon CloudWatch Logs*.
**Note**
Lorsque vous indiquez le nom du flux Firehose, utilisez uniquement le modèle regex `[\w-]`. Pour plus d'informations, consultez le fonctionnement de l'[PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html#API_PutDeliveryDestination_RequestSyntax)API dans le manuel *Amazon CloudWatch Logs API Reference*.
### Exemple de journal d’accès envoyé à Firehose
```
{"date":"2024-11-15","time":"19:45:51","x-edge-location":"SOF50-P2","asn":"16509","timestamp(ms)":"1731699951183","origin-fbl":"0.254","origin-lbl":"0.254","x-host-header":"d111111abcdef8.cloudfront.net","cs(Cookie)":"examplecookie=value"}
{"date":"2024-11-15","time":"19:45:52","x-edge-location":"SOF50-P2","asn":"16509","timestamp(ms)":"1731699952950","origin-fbl":"0.125","origin-lbl":"0.125","x-host-header":"d111111abcdef8.cloudfront.net","cs(Cookie)":"examplecookie=value"}
```
## Envoi de journaux vers Amazon S3
Pour envoyer vos journaux d’accès à Amazon S3, créez ou utilisez un compartiment S3 existant. Lorsque vous activez la connexion CloudFront, spécifiez le nom du compartiment. Pour en savoir plus sur la création des compartiments, consultez [Création d’un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) dans le *Guide de l’utilisateur Amazon Simple Storage Service*.
Une fois votre compartiment créé, vous devez disposer des autorisations nécessaires pour activer la journalisation standard. Pour plus d'informations, consultez la section [Logs envoyés à Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-S3) dans le *guide de l'utilisateur Amazon CloudWatch Logs*.
+ Une fois que vous avez activé la journalisation, il ajoute AWS automatiquement les politiques de compartiment requises pour vous.
+ Vous pouvez également utiliser des compartiments S3 dans les [Régions AWS soumises à adhésion](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html).
**Note**
Si vous utilisez déjà la journalisation standard (héritée) et que vous souhaitez activer la journalisation standard (v2) sur Amazon S3, nous vous conseillons d’indiquer un compartiment Amazon S3 *différent* ou d’utiliser un *chemin distinct* dans le même compartiment (par exemple, un préfixe de journal ou un partitionnement). Vous pouvez ainsi facilement identifier les fichiers journaux associés à chaque distribution, tout en évitant qu’ils ne se remplacent mutuellement.
**Topics**
+ [Spécification d’un compartiment S3](#prefix-s3-buckets)
+ [Partitioning](#partitioning)
+ [Format de nom de fichier compatible avec Hive](#hive-compatible-file-name-format)
+ [Exemple de chemins d’accès aux journaux](#bucket-path-examples)
+ [Exemple de journal d’accès envoyé à Amazon S3](#example-access-logs-s3)
### Spécification d’un compartiment S3
Lorsque vous spécifiez un compartiment S3 comme destination de livraison, tenez compte des points suivants.
Le nom du compartiment S3 ne peut utiliser que le modèle regex `[\w-]`. Pour plus d'informations, consultez le fonctionnement de l'[PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html#API_PutDeliveryDestination_RequestSyntax)API dans le manuel *Amazon CloudWatch Logs API Reference*.
Si vous avez spécifié un préfixe pour votre compartiment S3, vos journaux seront visibles sous ce chemin. Si vous ne spécifiez aucun préfixe, CloudFront il sera automatiquement ajouté pour `AWSLogs/{account-id}/CloudFront` vous.
Pour de plus amples informations, veuillez consulter [Exemple de chemins d’accès aux journaux](#bucket-path-examples).
### Partitioning
Vous pouvez utiliser le partitionnement pour organiser vos journaux d'accès lorsque vous CloudFront les envoyez à votre compartiment S3. Cela vous permet d’organiser et de localiser vos journaux d’accès en fonction du chemin souhaité.
Vous pouvez utiliser les variables suivantes pour créer un chemin de dossier.
+ `{DistributionId}` ou `{distributionid}`
+ `{yyyy}`
+ `{MM}`
+ `{dd}`
+ `{HH}`
+ `{accountid}`
Vous pouvez utiliser autant de variables que vous le souhaitez et spécifier des noms de dossiers dans votre chemin. CloudFrontutilise ensuite ce chemin pour créer une structure de dossiers pour vous dans le compartiment S3.
**Exemples**
+ `my_distribution_log_data/{DistributionId}/logs`
+ `/cloudfront/{DistributionId}/my_distribution_log_data/{yyyy}/{MM}/{dd}/{HH}/logs `
**Note**
Vous pouvez utiliser l’une ou l’autre variable pour l’ID de distribution dans le chemin de suffixe. Toutefois, si vous envoyez des journaux d'accès à AWS Glue, vous devez utiliser la `{distributionid}` variable car AWS Glue les noms de partition doivent être en minuscules. Mettez à jour votre configuration de journal existante CloudFront pour la `{DistributionId}` remplacer par`{distributionid}`.
### Format de nom de fichier compatible avec Hive
Cette option peut être utilisée afin que les objets S3 contenant les journaux d’accès livrés utilisent une structure de préfixe permettant l’intégration avec Apache Hive. Pour plus d'informations, consultez l'opération API [CreateDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html).
**Example Exemple**
```
/cloudfront/DistributionId={DistributionId}/my_distribution_log_data/year={yyyy}/month={MM}/day={dd}/hour={HH}/logs
```
Pour plus d'informations sur le partitionnement et les options compatibles avec Hive, consultez l'DeliveryConfigurationélément [S3 dans le manuel](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_S3DeliveryConfiguration.html) *Amazon CloudWatch Logs* API Reference.
### Exemple de chemins d’accès aux journaux
Lorsque vous spécifiez un compartiment S3 comme destination, vous pouvez utiliser les options suivantes pour créer le chemin d’accès à vos journaux d’accès :
+ Un compartiment Amazon S3, avec ou sans préfixe
+ Partitionnement, en utilisant une variable CloudFront fournie ou en saisissant la vôtre
+ L’activation de l’option compatible avec Hive
Les tableaux suivants montrent comment vos journaux d’accès apparaissent dans votre compartiment, en fonction des options que vous avez choisies.
#### Compartiment Amazon S3 avec un préfixe
| Nom du compartiment Amazon S3 | Partition que vous spécifiez dans le chemin du suffixe | Chemin de suffixe mis à jour | Option compatible Hive activée ? | Les journaux d’accès sont envoyés à |
| --- | --- | --- | --- | --- |
| amzn-s3-demo-bucket/MyLogPrefix | Aucune | Aucune | Non | amzn-s3-demo-bucket/MyLogPrefix/ |
| amzn-s3-demo-bucket/MyLogPrefix | myFolderA/ | myFolderA/ | Non | amzn-s3-demo-bucket/MyLogPrefix/myFolderA/ |
| amzn-s3-demo-bucket/MyLogPrefix | myFolderA/\$1yyyy\$1 | myFolderA/\$1yyyy\$1 | Oui | amzn-s3-demo-bucket/MyLogPrefix/myFolderA/year=2025 |
#### Compartiment Amazon S3 sans préfixe
| Nom du compartiment Amazon S3 | Partition que vous spécifiez dans le chemin du suffixe | Chemin de suffixe mis à jour | Option compatible Hive activée ? | Les journaux d’accès sont envoyés à |
| --- | --- | --- | --- | --- |
| amzn-s3-demo-bucket | Aucune | AWSLogs/\$1account-id\$1/CloudFront/ | Non | amzn-s3-demo-bucket/AWSLogs//CloudFront/ |
| amzn-s3-demo-bucket | myFolderA/ | AWSLogs/\$1account-id\$1/CloudFront/myFolderA/ | Non | amzn-s3-demo-bucket/AWSLogs//CloudFront/myFolderA/ |
| amzn-s3-demo-bucket | myFolderA/ | AWSLogs/\$1account-id\$1/CloudFront/myFolderA/ | Oui | amzn-s3-demo-bucket/AWSLogs/aws-account-id=/CloudFront/myFolderA/ |
| amzn-s3-demo-bucket | myFolderA/\$1yyyy\$1 | AWSLogs/\$1account-id\$1/CloudFront/myFolderA/\$1yyyy\$1 | Oui | amzn-s3-demo-bucket/AWSLogs/aws-account-id=/CloudFront/myFolderA/year=2025 |
#### Compte AWS ID en tant que partition
| Nom du compartiment Amazon S3 | Partition que vous spécifiez dans le chemin du suffixe | Chemin de suffixe mis à jour | Option compatible Hive activée ? | Les journaux d’accès sont envoyés à |
| --- | --- | --- | --- | --- |
| amzn-s3-demo-bucket | Aucune | AWSLogs/\$1account-id\$1/CloudFront/ | Oui | amzn-s3-demo-bucket/AWSLogs/aws-account-id=/CloudFront/ |
| amzn-s3-demo-bucket | myFolderA/\$1accountid\$1 | AWSLogs/\$1account-id\$1/CloudFront/myFolderA/\$1accountid\$1 | Oui | amzn-s3-demo-bucket/AWSLogs/aws-account-id=/CloudFront/myFolderA/accountid= |
**Remarques**
La `{account-id}` variable est réservée à CloudFront. CloudFrontajoute automatiquement cette variable au chemin de votre suffixe si vous spécifiez un compartiment Amazon S3 *sans* préfixe. Si vos journaux sont compatibles avec Hive, cette variable apparaît sous la forme `aws-account-id`.
Vous pouvez utiliser la `{accountid}` variable pour CloudFront ajouter votre identifiant de compte au chemin du suffixe. Si vos journaux sont compatibles avec Hive, cette variable apparaît sous la forme `accountid`.
Pour plus d'informations sur le chemin du suffixe, consultez [S3 DeliveryConfiguration](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_S3DeliveryConfiguration.html).
### Exemple de journal d’accès envoyé à Amazon S3
```
#Fields: date time x-edge-location asn timestamp(ms) x-host-header cs(Cookie)
2024-11-14 22:30:25 SOF50-P2 16509 1731623425421
d111111abcdef8.cloudfront.net examplecookie=value2
```
## Désactivation de la journalisation standard
Si vous n’avez plus besoin de la journalisation standard, vous pouvez la désactiver sur votre distribution.
**Pour désactiver la journalisation standard**
1. Connectez-vous à la CloudFront console.
1. Sélectionnez **Distribution**, puis choisissez votre ID de distribution.
1. Choisissez **Logging**, puis sous **Destinations du journal d'accès**, sélectionnez la destination.
1. Sélectionnez **Gérer**, puis choisissez **Supprimer**.
1. Répétez l’étape précédente si vous avez plus d’une journalisation standard.
**Note**
Lorsque vous supprimez la journalisation standard de la CloudFront console, cette action supprime uniquement la livraison et la destination de livraison. Cela ne supprime pas la source de diffusion de votre Compte AWS. Pour supprimer une source de livraison, spécifiez le nom de la source de livraison dans la commande `aws logs delete-delivery-source --name DeliverySourceName`. Pour plus d'informations, consultez [DeleteDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteDeliverySource.html)le manuel *Amazon CloudWatch Logs API Reference*.
## Dépannage
Utilisez les informations suivantes pour résoudre les problèmes courants liés à l'utilisation de la journalisation CloudFront standard (v2).
### La source de livraison existe déjà
Lorsque vous activez la journalisation standard pour une distribution, vous créez une source de livraison. Vous utilisez ensuite cette source de livraison pour créer des livraisons vers le type de destination que vous souhaitez : CloudWatch Logs, Firehose, Amazon S3. À l’heure actuelle, une distribution ne peut disposer que d’une seule source de livraison. Si vous essayez de créer une autre source de livraison pour la même distribution, le message d’erreur suivant s’affiche.
```
This ResourceId has already been used in another Delivery Source in this account
```
Pour créer une autre source de livraison, supprimez d’abord la source existante. Pour plus d'informations, consultez [DeleteDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteDeliverySource.html)le manuel *Amazon CloudWatch Logs API Reference*.
### J’ai modifié le chemin du suffixe et le compartiment Amazon S3 ne parvient plus à recevoir mes journaux
Si vous avez activé la journalisation standard (v2) et que vous spécifiez un ARN de compartiment sans préfixe, CloudFront vous ajouterez la valeur par défaut suivante au chemin du suffixe :. `AWSLogs/{account-id}/CloudFront` Si vous utilisez la CloudFront console ou l'opération [UpdateDeliveryConfiguration](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_UpdateDeliveryConfiguration.html)API pour spécifier un chemin de suffixe différent, vous devez mettre à jour la politique du compartiment Amazon S3 pour utiliser le même chemin.
**Example Exemple : mise à jour du chemin de suffixe**
1. Votre chemin de suffixe par défaut est `AWSLogs/{account-id}/CloudFront` et vous le remplacez par `myFolderA`.
1. Étant donné que votre nouveau chemin de suffixe diffère de celui indiqué dans la stratégie de compartiment Amazon S3, vos journaux d’accès ne seront pas livrés.
1. Vous pouvez effectuer l’une des actions suivantes :
+ Mettre à jour l’autorisation du compartiment Amazon S3 en remplaçant `amzn-s3-demo-bucket/AWSLogs//CloudFront/*` par `amzn-s3-demo-bucket/myFolderA/*`.
+ Mettre à jour votre configuration de journalisation pour réutiliser le chemin de suffixe par défaut : `AWSLogs/{account-id}/CloudFront`
Pour plus d’informations, consultez [Permissions](#permissions-standard-logging).
## Suppression des fichiers journaux
CloudFront ne supprime pas automatiquement les fichiers journaux de votre destination. Pour en savoir plus sur la suppression des fichiers journaux, consultez les rubriques suivantes :
**Amazon S3**
+ [Suppression des objets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeletingObjects.html) dans le *Guide de l’utilisateur de la console Amazon Simple Storage Service*
**CloudWatch Journaux**
+ [Utilisation des groupes de journaux et des flux de journaux](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html) dans le *guide de l'utilisateur Amazon CloudWatch Logs*
+ [DeleteLogGroup](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteLogGroup.html)dans le manuel de *référence de l'API Amazon CloudWatch Logs*
**Firehose**
+ [DeleteDeliveryStream](https://docs.aws.amazon.com/firehose/latest/APIReference/API_DeleteDeliveryStream.html)dans le manuel de *référence de l'API Amazon Data Firehose*
## Tarification
CloudFront l'activation des journaux standard est gratuite. Cependant, vous pouvez être facturé pour la livraison, l’ingestion, le stockage ou l’accès, selon la destination de livraison des journaux que vous avez choisie. Pour plus d'informations, consultez la section [Tarification d'Amazon CloudWatch Logs](https://aws.amazon.com/cloudwatch/pricing/). Dans **Niveau payant**, sélectionnez l’onglet **Journaux**, puis, dans **Journaux payants**, consultez les informations pour chaque destination de livraison.
Pour plus d'informations sur la tarification de chacun d'entre eux Service AWS, consultez les rubriques suivantes :
+ [Tarification d'Amazon CloudWatch Logs](https://aws.amazon.com/cloudwatch/pricing/)
+ [Tarification Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/pricing/)
+ [Tarification Amazon S3](https://aws.amazon.com/s3/pricing/)
**Note**
La livraison des journaux vers Amazon S3 n’entraîne aucun coût supplémentaire, toutefois vous serez facturé par Amazon S3 pour le stockage et l’accès aux fichiers journaux. Si vous activez l'option **Parquet** pour convertir vos journaux d'accès en Apache Parquet, cette option entraîne des CloudWatch frais. Pour plus d'informations, consultez la [section Vended Logs pour CloudWatch connaître les tarifs](https://aws.amazon.com/cloudwatch/pricing/).
# Configurer la journalisation standard (héritée)
**Remarques**
Cette rubrique concerne la version précédente de la journalisation standard. Pour obtenir la dernière version, consultez [Configuration de la journalisation standard (v2)](standard-logging.md).
Si vous utilisez déjà la journalisation standard (héritée) et que vous souhaitez activer la journalisation standard (v2) sur Amazon S3, nous vous conseillons d’indiquer un compartiment Amazon S3 *différent* ou d’utiliser un *chemin distinct* dans le même compartiment (par exemple, un préfixe de journal ou un partitionnement). Vous pouvez ainsi facilement identifier les fichiers journaux associés à chaque distribution, tout en évitant qu’ils ne se remplacent mutuellement.
Pour commencer avec la journalisation standard (héritée), procédez comme suit :
1. Choisissez un compartiment Amazon S3 qui recevra vos journaux, puis ajoutez les autorisations requises.
1. Configurez la journalisation standard (ancienne) depuis la CloudFront console ou l' CloudFront API. Vous ne pouvez choisir qu’un compartiment Amazon S3 pour recevoir vos journaux.
1. Affichez vos journaux d’accès.
## Choix d’un compartiment Amazon S3 pour les journaux standard
Lorsque vous activez la journalisation pour une distribution, vous spécifiez le compartiment Amazon S3 dans lequel vous CloudFront souhaitez stocker les fichiers journaux. Si vous utilisez Amazon S3 comme origine, nous vous recommandons d’utiliser un compartiment *distinct* pour vos fichiers journaux.
Spécifiez le compartiment Amazon S3 dans lequel vous CloudFront souhaitez stocker les connexions d'accès, par exemple`amzn-s3-demo-bucket.s3.amazonaws.com`.
Vous pouvez stocker les fichiers journaux de plusieurs distributions dans le même compartiment. Lorsque vous activez la journalisation, vous pouvez spécifier un préfixe facultatif pour les noms de fichier et vous pouvez ainsi savoir quels fichiers journaux sont associés à quelles distributions.
**À propos du choix d’un compartiment S3**
La liste de contrôle d’accès (ACL) doit être activée sur votre compartiment. Si vous choisissez un bucket sans ACL activé depuis la CloudFront console, un message d'erreur s'affiche. Consultez [Permissions](#AccessLogsBucketAndFileOwnership).
Ne choisissez pas un compartiment Amazon S3 avec l’option [S3 Object Ownership (Propriété de l’objet S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) définie sur **bucket owner enforced (appliqué par le propriétaire du compartiment)**. Ce paramètre désactive ACLs le compartiment et les objets qu'il contient, ce qui CloudFront empêche de fournir des fichiers journaux au compartiment.
La journalisation traditionnelle ne prend pas en charge les compartiments Amazon S3 dans les régions optionnelles. Choisissez une région activée par défaut ou utilisez [Standard Logging V2](standard-logging.md), qui prend en charge les régions optionnelles et propose des fonctionnalités supplémentaires. Pour obtenir la liste des régions par défaut et facultatives, consultez [Régions AWS](https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions.html).
## Permissions
**Important**
À compter d'avril 2023, vous devez activer S3 ACLs pour les nouveaux compartiments S3 utilisés pour les journaux CloudFront standard. Vous pouvez l'activer ACLs lorsque vous [créez un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-ownership-new-bucket.html) ou l'activer ACLs pour un [bucket existant](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-ownership-existing-bucket.html).
Pour plus d'informations sur ces modifications, consultez [Paramètres par défaut pour les nouveaux compartiments S3 FAQ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-faq.html) dans le *Guide de l'utilisateur d'Amazon Simple Storage Service* et [Attention : des modifications de sécurité seront apportées à Amazon S3 en avril 2023](https://aws.amazon.com/blogs/aws/heads-up-amazon-s3-security-changes-are-coming-in-april-of-2023/) dans le *Blog d'actualités AWS *.
Vous Compte AWS devez disposer des autorisations suivantes pour le compartiment que vous spécifiez pour les fichiers journaux :
+ L’ACL définie pour le compartiment doit vous accorder l’autorisation `FULL_CONTROL`. Si vous êtes le propriétaire du compartiment, votre compte dispose de cette autorisation par défaut. Si vous ne l’êtes pas, le propriétaire du compartiment doit mettre à jour l’ACL de ce compartiment.
+ `s3:GetBucketAcl`
+ `s3:PutBucketAcl`
**Liste ACL pour le compartiment**
Lorsque vous créez ou mettez à jour une distribution et que vous activez la CloudFront journalisation, utilisez ces autorisations pour mettre à jour l'ACL du bucket afin d'`FULL_CONTROL`autoriser le `awslogsdelivery` compte. Le compte `awslogsdelivery` écrit les fichiers journaux dans le compartiment. Si votre compte ne dispose pas des autorisations requises pour mettre à jour la liste ACL, la création ou la mise à jour de la distribution échouera.
Dans certaines circonstances, si vous envoyez par programmation une demande pour créer un compartiment, mais qu’un compartiment avec le nom spécifié existe déjà, S3 réinitialise les autorisations sur le compartiment à la valeur par défaut. Si vous avez configuré CloudFront pour enregistrer les journaux d'accès dans un compartiment S3 et que vous ne recevez plus de journaux dans ce compartiment, vérifiez les autorisations sur le compartiment pour vous assurer qu'il CloudFront dispose des autorisations nécessaires.
**Restauration de la liste ACL pour le compartiment**
Si vous supprimez des autorisations pour le compte `awslogsdelivery`, CloudFront ne peut plus enregistrer des journaux dans le compartiment S3. Pour permettre CloudFront de recommencer à enregistrer les journaux pour votre distribution, restaurez l'autorisation ACL en effectuant l'une des opérations suivantes :
+ Désactivez la journalisation de votre distribution CloudFront, puis réactivez-la. Pour de plus amples informations, veuillez consulter [Journalisation standard](DownloadDistValuesGeneral.md#DownloadDistValuesLoggingOnOff).
+ Ajoutez manuellement l’autorisation de la liste ACL pour le compte `awslogsdelivery` en accédant au compartiment S3 dans la console Amazon S3 et en ajoutant l’autorisation. Afin d’ajouter la liste ACL pour le compte `awslogsdelivery`, vous devez fournir l’ID canonique suivant pour le compte :
`c4c1ede66af53448b93c283ce9448c4ba468c9432aa01d700d3878632f77d2d0`
Pour plus d'informations sur l'ajout ACLs aux compartiments S3, consultez la [section Configuration ACLs](https://docs.aws.amazon.com/AmazonS3/latest/userguide/managing-acls.html) dans le *guide de l'utilisateur d'Amazon Simple Storage Service*.
**Liste ACL pour chaque fichier journal**
En plus de la liste ACL sur le compartiment, il existe une ACL sur chaque fichier journal. Le propriétaire du compartiment dispose de l’autorisation `FULL_CONTROL` sur chaque fichier journal, le propriétaire de la distribution (s’il est différent du propriétaire du compartiment) n’a aucune autorisation et le compte `awslogsdelivery` a les autorisations en lecture et écriture.
**Désactivation de la journalisation**
Si vous désactivez la ACLs journalisation, CloudFront cela ne supprime ni le bucket ni les fichiers journaux. Vous pouvez les supprimer ACLs si nécessaire.
### Politique de clé requise pour les compartiments SSE-KMS
Si le compartiment S3 de vos journaux standard utilise le chiffrement côté serveur avec les AWS KMS keys (SSE-KMS) utilisant une clé gérée par le client, vous devez ajouter l’instruction suivante à la stratégie de clé pour la clé gérée par votre client. Cela permet CloudFront d'écrire des fichiers journaux dans le compartiment. Vous ne pouvez pas utiliser SSE-KMS avec le Clé gérée par AWS car vous CloudFront ne pourrez pas écrire de fichiers journaux dans le compartiment.
```
{
"Sid": "Allow CloudFront to use the key to deliver logs",
"Effect": "Allow",
"Principal": {
"Service": "delivery.logs.amazonaws.com"
},
"Action": "kms:GenerateDataKey*",
"Resource": "*"
}
```
Si le compartiment S3 de vos journaux standard utilise SSE-KMS avec une [clé de compartiment S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-key.html), vous devez également ajouter l’autorisation `kms:Decrypt` à l’instruction de stratégie. Dans ce cas, l’énoncé de stratégie complet ressemble à ce qui suit.
```
{
"Sid": "Allow CloudFront to use the key to deliver logs",
"Effect": "Allow",
"Principal": {
"Service": "delivery.logs.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey*",
"kms:Decrypt"
],
"Resource": "*"
}
```
**Note**
Lorsque vous activez SSE-KMS pour votre compartiment S3, spécifiez l’ARN complet de la clé gérée par le client. Pour plus d'informations, consultez [Spécifier le chiffrement côté serveur avec AWS KMS keys (SSE-KMS) dans le guide de l'utilisateur](https://docs.aws.amazon.com/AmazonS3/latest/userguide/specifying-kms-encryption.html) d'*Amazon Simple Storage Service*.
## Activation de la journalisation standard (héritée)
Pour activer les journaux standard, utilisez la CloudFront console ou l' CloudFront API.
**Contents**
+ [Activer la journalisation standard (ancienne) (CloudFront console)](#standard-logs-legacy-enable-console)
+ [Activer la journalisation standard (ancienne) (CloudFront API)](#standard-logs-legacy-enable-api)
### Activer la journalisation standard (ancienne) (CloudFront console)
**Pour activer les journaux standard pour une CloudFront distribution (console)**
1. Utilisez la CloudFront console pour créer une [nouvelle distribution](distribution-web-creating-console.md) ou [mettre à jour une distribution existante](HowToUpdateDistribution.md#HowToUpdateDistributionProcedure).
1. Dans la section **Journalisation standard**, sélectionnez **Activé** pour la **Livraison des journaux**.
1. (Facultatif) Pour la **journalisation des cookies**, choisissez **Activé** si vous souhaitez inclure les cookies dans vos journaux. Pour plus d’informations, consultez [Journalisation des cookies](DownloadDistValuesGeneral.md#DownloadDistValuesCookieLogging).
**Astuce**
La journalisation des cookies est un paramètre global qui s’applique à *l’ensemble* des journaux standard de votre distribution. Vous ne pouvez pas remplacer ce paramètre pour des destinations de livraison distinctes.
1. Dans la section **Livrer à**, indiquez **Amazon S3 (hérité)**.
1. Indiquez votre compartiment Amazon S3. Si vous n’en avez pas encore, vous pouvez choisir **Créer** ou consulter la documentation pour [créer un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html).
1. (Facultatif) Pour le **préfixe du journal**, spécifiez la chaîne, le cas échéant, que vous CloudFront souhaitez préfixer aux noms des fichiers journaux d'accès pour cette distribution, par exemple,. `exampleprefix/` La barre oblique de fin (/) est facultative, mais recommandée pour simplifier la navigation dans vos fichiers-journaux. Pour plus d’informations, consultez [Préfixe de journal](DownloadDistValuesGeneral.md#DownloadDistValuesLogPrefix).
1. Terminez les étapes pour mettre à jour ou créer votre distribution.
1. Sur la page **Journaux**, vérifiez que l’état des journaux standard est défini sur **Activé** à côté de la distribution.
Pour plus d’informations sur la livraison de la journalisation standard et les champs de journal, consultez la [Référence de la journalisation standard](standard-logs-reference.md).
### Activer la journalisation standard (ancienne) (CloudFront API)
Vous pouvez également utiliser l' CloudFront API pour activer les journaux standard pour vos distributions.
**Pour activer les journaux standard pour une distribution (CloudFront API)**
+ Utilisez l'opération [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)ou [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)API et configurez l'[LoggingConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_LoggingConfig.html)objet.
## Modification des paramètres de journalisation standard
Vous pouvez activer ou désactiver la journalisation, modifier le compartiment Amazon S3 dans lequel vos journaux sont stockés et modifier le préfixe des fichiers journaux à l'aide de la [CloudFront console](https://console.aws.amazon.com/cloudfront/v4/home) ou de l' CloudFront API. Les modifications apportées aux paramètres de journalisation prennent effet dans les 12 heures.
Pour plus d’informations, consultez les rubriques suivantes :
+ Pour mettre à jour une distribution à l'aide de la CloudFront console, consultez[Mettre à jour une distribution](HowToUpdateDistribution.md).
+ Pour mettre à jour une distribution à l'aide de l' CloudFront API, consultez [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)le *Amazon CloudFront API Reference*.
## Envoi de journaux vers Amazon S3
Lorsque vos journaux sont envoyés à Amazon S3, ils se présentent sous le format suivant.
### Format de nom de fichier
Le nom de chaque fichier journal enregistré CloudFront dans votre compartiment Amazon S3 utilise le format de nom de fichier suivant :
`/.YYYY-MM-DD-HH.unique-ID.gz`
Les dates et heures sont exprimées en heure UTC (temps universel coordonné).
Par exemple, si vous utilisez `example-prefix` comme préfixe et que votre ID de distribution est `EMLARXS9EXAMPLE`, les noms de fichiers ressemblent à ceci :
`example-prefix/EMLARXS9EXAMPLE.2019-11-14-20.RT4KCN4SGK9.gz`
Lorsque vous activez la journalisation pour une distribution, vous pouvez spécifier un préfixe facultatif pour les noms de fichier et vous pouvez ainsi savoir quels fichiers journaux sont associés à quelles distributions. Si vous incluez une valeur pour le préfixe du fichier journal et que celui-ci ne se termine pas par une barre oblique (`/`), il en CloudFront ajoute une automatiquement. Si votre préfixe se termine par une barre oblique, CloudFront il n'en ajoute pas un autre.
Le nom `.gz` à la fin du fichier indique que le fichier journal CloudFront a été compressé à l'aide de gzip.
## Format de fichier journal standard
Chaque entrée d’un fichier journal fournit des informations détaillées sur une seule demande utilisateur. Les fichiers journaux présentent les caractéristiques suivantes :
+ Utilisez le [format de fichier journal étendu W3C](https://www.w3.org/TR/WD-logfile.html).
+ Contiennent des valeurs séparées par des virgules.
+ Contiennent des enregistrements qui ne sont pas nécessairement dans l’ordre chronologique.
+ Contiennent deux lignes d’en-tête : l’une avec la version fichier-format et l’autre qui répertorie les champs W3C inclus dans chaque enregistrement.
+ Contiennent des équivalents encodés en URL pour des espaces et certains autres caractères dans les valeurs de champ.
Les équivalents encodés en URL sont utilisés pour les caractères suivants :
+ Codes de caractères ASCII 0 à 32 inclus
+ Codes de caractères ASCII 127 et suivants
+ Tous les caractères du tableau suivant
La norme d’encodage d’URL est définie dans la norme [RFC 1738](https://tools.ietf.org/html/rfc1738.html).
| Valeur codée par URL | Caractère |
| --- | --- |
| %3C | < |
| %3E | > |
| %22 | " |
| %23 | \$1 |
| %25 | % |
| %7B | \$1 |
| %7D | \$1 |
| %7C | \$1 |
| %5C | \$1 |
| %5E | ^ |
| %7E | \$1 |
| %5B | [ |
| %5D | ] |
| %60 | ` |
| %27 | ' |
| %20 | espace |
## Suppression des fichiers journaux
CloudFront ne supprime pas automatiquement les fichiers journaux de votre compartiment Amazon S3. Pour en savoir plus sur la suppression de fichiers journaux dans un compartiment Amazon S3, consultez [Suppression des objets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeletingObjects.html) dans le *Guide de l’utilisateur de la console Amazon Simple Storage Service*.
## Tarification
La journalisation standard est une fonctionnalité facultative de CloudFront. CloudFront l'activation des journaux standard est gratuite. Cependant, les frais Amazon S3 usuels sont facturés pour stocker les fichiers et y accéder sur Amazon S3. Vous pouvez les supprimer à tout moment.
Pour plus d’informations sur la tarification Amazon S3, consultez [Tarification Amazon S3](https://aws.amazon.com/s3/pricing/).
Pour plus d'informations sur la CloudFront tarification, consultez la section [CloudFront Tarification](https://aws.amazon.com/cloudfront/pricing/).
# Référence de la journalisation standard
Les sections suivantes s’appliquent à la fois à la journalisation standard (v2) et à la journalisation standard (héritée).
**Topics**
+ [Chronologie de la livraison des fichiers journaux](#access-logs-timing)
+ [Comment les demandes sont consignées lorsque l’URL de la demande ou les en-têtes dépassent la taille maximale](#access-logs-request-URL-size)
+ [Champs du fichier journal](#BasicDistributionFileFormat)
+ [Analyse des journaux](#access-logs-analyzing)
## Chronologie de la livraison des fichiers journaux
CloudFront fournit des journaux pour une distribution jusqu'à plusieurs fois par heure. En général, un fichier journal contient des informations sur les demandes CloudFront reçues au cours d'une période donnée. CloudFront fournit généralement le fichier journal pour cette période à votre destination dans l'heure qui suit l'apparition des événements dans le journal. Notez, cependant, que tout ou partie des entrées d’un fichier journal d’une période peut parfois être retardé de 24 heures au plus. Lorsque les entrées du journal sont retardées, les CloudFront enregistre dans un fichier journal dont le nom inclut la date et l'heure de la période au cours de laquelle les demandes *ont* été effectuées, et non la date et l'heure de livraison du fichier.
Lorsque vous créez un fichier journal, CloudFront consolide les informations relatives à votre distribution provenant de tous les emplacements périphériques ayant reçu des demandes pour vos objets pendant la période couverte par le fichier journal.
CloudFront peut enregistrer plusieurs fichiers pendant une période en fonction du nombre de demandes CloudFront reçues pour les objets associés à une distribution.
CloudFront commence à fournir des journaux d'accès de manière fiable environ quatre heures après l'activation de la journalisation. Vous pourriez obtenir quelques journaux d’accès avant ce moment-là.
**Note**
Si aucun utilisateur ne demande vos objets pendant la période, vous ne recevez aucun fichier journal pour cette dernière.
## Comment les demandes sont consignées lorsque l’URL de la demande ou les en-têtes dépassent la taille maximale
Si la taille totale de tous les en-têtes de demande, y compris les cookies, dépasse 20 Ko ou si l'URL de demande dépasse les 8 192 octets pour l’URL, CloudFront ne peut pas analyser complètement la demande et ne peut pas la consigner. Étant donné que la demande n’est pas consignée, vous ne verrez pas dans les fichiers journaux le code de statut d’erreur HTTP renvoyé.
Si le corps de la demande dépasse la taille maximale, la demande est consignée, y compris le code de statut d’erreur HTTP.
## Champs du fichier journal
Le fichier journal d’une distribution contient 33 champs. La liste suivante contient chaque nom de champ, dans l’ordre, ainsi qu’une description des informations contenues dans ce champ.
1. **`date`**
Date à laquelle l’événement s’est produit au format `YYYY-MM-DD`. Par exemple, `2019-06-30`. Les dates et heures sont exprimées en heure UTC (temps universel coordonné). Pour WebSocket les connexions, il s'agit de la date de fermeture de la connexion.
1. **`time`**
Heure à laquelle le CloudFront serveur a fini de répondre à la demande (en UTC), par exemple,`01:42:39`. Pour WebSocket les connexions, il s'agit de l'heure à laquelle la connexion est fermée.
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. **`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. **`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. **`cs-method`**
Méthode de demande HTTP reçue de l’utilisateur.
1. **`cs(Host)`**
Le nom de domaine de la CloudFront distribution (par exemple, d111111abcdef8.cloudfront.net).
1. **`cs-uri-stem`**
Partie de l’URL de la requête qui identifie le chemin d’accès et l’objet (par exemple, `/images/cat.jpg`). Points d'interrogation (?) les chaînes URLs de saisie et de requête ne sont pas incluses dans le journal.
1. **`sc-status`**
Contient une des valeurs suivantes :
+ Code de statut HTTP de la réponse du serveur (par exemple, `200`).
+ `000`, ce qui indique que l’utilisateur a fermé la connexion avant que le serveur puisse répondre à la demande. Si l’utilisateur ferme la connexion après que le serveur a commencé à envoyer la réponse, ce champ contient le code de statut HTTP de la réponse que le serveur a commencé à envoyer.
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(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-uri-query`**
Partie de la chaîne de requête de l’URL de la demande, le cas échéant.
Quand un URL ne contient pas de chaîne de requête, la valeur de ce champ est un trait d’union (-). Pour plus d’informations, consultez [Mise en cache de contenu basée sur les paramètres de chaîne de requête](QueryStringParameters.md).
1. **`cs(Cookie)`**
En-tête `Cookie` de la demande, y compris les paires nom-valeur et les attributs associés.
Si vous activez l'enregistrement des cookies, les CloudFront enregistre dans toutes les demandes, quels que soient les cookies que vous choisissez de transférer à l'origine. Quand une demande n'inclut pas un en-tête de cookie, la valeur de ce champ est un trait d'union (-). Pour plus d’informations sur les cookies, consultez [Mise en cache de contenu basée sur des cookies](Cookies.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. **`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`**
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.
Si vous utilisez des noms de domaine alternatifs, consultez `cs(Host)` dans le champ 7 pour connaître le nom de domaine associé à votre distribution.
1. **`cs-protocol`**
Protocole de la demande de l’utilisateur (`http`, `https`, `grpcs`, `ws` ou `wss`).
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. **`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. **`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`).
Si l’utilisateur n’a pas utilisé de proxy HTTP ou d’équilibreur de charge, la valeur de ce champ est un trait d’union (-).
1. **`ssl-protocol`**
Lorsque la demande a utilisé le protocole HTTPS, ce champ contient le SSL/TLS protocole négocié par le spectateur 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).
Quand `cs-protocol` dans le champ 17 est `http`, la valeur de ce champ est un trait d’union (-).
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)
Quand `cs-protocol` dans le champ 17 est `http`, la valeur de ce champ est un trait d’union (-).
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. **`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. **`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é.
Si le chiffrement au niveau du champ n’est pas configuré pour la distribution, la valeur de ce champ est un trait d’union (-).
1. **`fle-encrypted-fields`**
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.
Si le chiffrement au niveau du champ n’est pas configuré pour la distribution, la valeur de ce champ est un trait d’union (-).
1. **`c-port`**
Numéro de port de la demande depuis l’utilisateur.
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. **`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. **`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. **`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).
L’exemple suivant est celui d’un fichier journal pour une distribution.
```
#Version: 1.0
#Fields: date time x-edge-location sc-bytes c-ip cs-method cs(Host) cs-uri-stem sc-status cs(Referer) cs(User-Agent) cs-uri-query cs(Cookie) x-edge-result-type x-edge-request-id x-host-header cs-protocol cs-bytes time-taken x-forwarded-for ssl-protocol ssl-cipher x-edge-response-result-type cs-protocol-version fle-status fle-encrypted-fields c-port time-to-first-byte x-edge-detailed-result-type sc-content-type sc-content-len sc-range-start sc-range-end
2019-12-04 21:02:31 LAX1 392 192.0.2.100 GET d111111abcdef8.cloudfront.net /index.html 200 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Hit SOX4xwn4XV6Q4rgb7XiVGOHms_BGlTAC4KyHmureZmBNrjGdRLiNIQ== d111111abcdef8.cloudfront.net https 23 0.001 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Hit HTTP/2.0 - - 11040 0.001 Hit text/html 78 - -
2019-12-04 21:02:31 LAX1 392 192.0.2.100 GET d111111abcdef8.cloudfront.net /index.html 200 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Hit k6WGMNkEzR5BEM_SaF47gjtX9zBDO2m349OY2an0QPEaUum1ZOLrow== d111111abcdef8.cloudfront.net https 23 0.000 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Hit HTTP/2.0 - - 11040 0.000 Hit text/html 78 - -
2019-12-04 21:02:31 LAX1 392 192.0.2.100 GET d111111abcdef8.cloudfront.net /index.html 200 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Hit f37nTMVvnKvV2ZSvEsivup_c2kZ7VXzYdjC-GUQZ5qNs-89BlWazbw== d111111abcdef8.cloudfront.net https 23 0.001 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Hit HTTP/2.0 - - 11040 0.001 Hit text/html 78 - -
2019-12-13 22:36:27 SEA19-C1 900 192.0.2.200 GET d111111abcdef8.cloudfront.net /favicon.ico 502 http://www.example.com/ Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Error 1pkpNfBQ39sYMnjjUQjmH2w1wdJnbHYTbag21o_3OfcQgPzdL2RSSQ== www.example.com http 675 0.102 - - - Error HTTP/1.1 - - 25260 0.102 OriginDnsError text/html 507 - -
2019-12-13 22:36:26 SEA19-C1 900 192.0.2.200 GET d111111abcdef8.cloudfront.net / 502 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Error 3AqrZGCnF_g0-5KOvfA7c9XLcf4YGvMFSeFdIetR1N_2y8jSis8Zxg== www.example.com http 735 0.107 - - - Error HTTP/1.1 - - 3802 0.107 OriginDnsError text/html 507 - -
2019-12-13 22:37:02 SEA19-C2 900 192.0.2.200 GET d111111abcdef8.cloudfront.net / 502 - curl/7.55.1 - - Error kBkDzGnceVtWHqSCqBUqtA_cEs2T3tFUBbnBNkB9El_uVRhHgcZfcw== www.example.com http 387 0.103 - - - Error HTTP/1.1 - - 12644 0.103 OriginDnsError text/html 507 - -
```
## Analyse des journaux
Comme vous pouvez recevoir plusieurs journaux d’accès par heure, nous vous recommandons de combiner tous les fichiers journaux que vous avez reçus pour une période donnée en un seul fichier. Vous pouvez alors analyser les données de cette période plus précisément et plus complètement.
Pour analyser vos journaux d’accès, une solution possible consiste à utiliser [Amazon Athena](https://aws.amazon.com/athena/). Athena est un service de requêtes interactif qui peut vous aider à analyser les données pour les AWS services, notamment. CloudFront Pour en savoir plus, consultez la section [Interrogation d'Amazon CloudFront Logs](https://docs.aws.amazon.com/athena/latest/ug/cloudfront-logs.html) dans le guide de l'*utilisateur d'Amazon Athena*.
En outre, les articles de AWS blog suivants décrivent certaines méthodes d'analyse des journaux d'accès.
+ [Amazon CloudFront Request Logging](https://aws.amazon.com/blogs/aws/amazon-cloudfront-request-logging/) (pour le contenu diffusé via HTTP)
+ [ CloudFront Journaux améliorés, désormais dotés de chaînes de requête](https://aws.amazon.com/blogs/aws/enhanced-cloudfront-logs-now-with-query-strings/)
# 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.
# Journaux des fonctions de périphérie
[Vous pouvez utiliser Amazon CloudWatch Logs pour obtenir les journaux de vos fonctions périphériques, à la fois [Lambda @Edge](lambda-at-the-edge.md) et CloudFront Functions.](cloudfront-functions.md) Vous pouvez accéder aux journaux à l'aide de la CloudWatch console ou de l'API CloudWatch Logs.
**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 des fonctions de pointe 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. Quand une entrée de journal est omise des journaux de fonctions de périphérie, le nombre d'entrées des journaux de fonctions de périphérie ne correspond pas à l'utilisation qui apparaît dans les rapports d'utilisation et de facturation AWS .
**Topics**
+ [Journaux Lambda@Edge](#lambda-at-edge-logs)
+ [CloudFront Journaux de fonctions](#cloudfront-function-logs)
## Journaux Lambda@Edge
Lambda @Edge envoie automatiquement des journaux de fonctions à Logs, créant ainsi des flux de CloudWatch journaux dans l' Régions AWS endroit où les fonctions sont invoquées. Lorsque vous créez ou modifiez une fonction dans AWS Lambda, vous pouvez soit utiliser le nom du groupe de CloudWatch journaux par défaut, soit le personnaliser.
+ Le nom du groupe de journaux par défaut est `/aws/lambda/`, où `` est le nom que vous avez indiqué lors de la création de la fonction. Lors de l'envoi de journaux à CloudWatch, Lambda @Edge ajoute automatiquement le `us-east-1` préfixe au nom de la fonction, de sorte que le nom du groupe de journaux soit. `/aws/lambda/us-east-1.` Ce préfixe correspond à l' Région AWS endroit où la fonction a été créée. Ce préfixe fait toujours partie du nom du groupe de journaux, même dans les autres Régions où la fonction est invoquée.
+ Si vous spécifiez un nom de groupe de journaux personnalisé, tel que `/MyLogGroup`, Lambda@Edge n’ajoutera pas le préfixe de Région. Le nom du groupe de journaux reste le même dans toutes les autres Régions où la fonction est invoquée.
**Note**
Si vous créez un groupe de journaux personnalisé et spécifiez le même nom que le nom par défaut `/aws/lambda/`, Lambda@Edge ajoute le préfixe `us-east-1` au nom de la fonction.
Outre la personnalisation du nom du groupe de journaux, les fonctions Lambda@Edge prennent en charge les formats de journal JSON et en texte brut, ainsi que le filtrage au niveau du journal. Pour plus d’informations, consultez [Configuration de commandes de journalisation avancées pour la fonction Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs-advanced.html) dans le *Guide du développeur AWS Lambda *.
**Note**
Lambda@Edge limite les journaux en fonction du volume de la demande et de la taille des journaux.
Vous devez consulter les fichiers CloudWatch journaux dans la région appropriée pour voir les fichiers journaux de vos fonctions Lambda @Edge. Pour voir les régions dans lesquelles votre fonction Lambda @Edge est exécutée, consultez les graphiques des métriques de la fonction dans la CloudFront console. Les métriques sont affichées pour chaque région . Sur la même page, vous pouvez choisir une région et afficher les fichiers journaux pour cette région afin de pouvoir rechercher des problèmes.
Pour en savoir plus sur l'utilisation des CloudWatch journaux avec les fonctions Lambda @Edge, consultez les rubriques suivantes :
+ Pour plus d'informations sur l'affichage des graphiques dans la section **Surveillance** de la CloudFront console, consultez[Surveillez CloudFront les métriques avec Amazon CloudWatch](monitoring-using-cloudwatch.md).
+ Pour plus d'informations sur les autorisations requises pour envoyer des données à CloudWatch Logs, consultez[Définition des autorisations et rôles IAM pour Lambda@Edge](lambda-edge-permissions.md).
+ Pour plus d'informations sur l'ajout de la journalisation à une fonction Lambda, consultez [Journalisation des fonctions AWS Lambda dans Node.js](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-logging.html) ou [Journalisation des fonctions AWS Lambda dans Python](https://docs.aws.amazon.com/lambda/latest/dg/python-logging.html) dans le *Guide du développeur AWS Lambda *.
+ Pour plus d'informations sur CloudWatch les quotas de journaux (anciennement appelés limites), consultez la section [Quotas de CloudWatch journaux](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html) dans le *guide de l'utilisateur Amazon CloudWatch Logs*.
## CloudFront Journaux de fonctions
Si le code d'une CloudFront fonction contient des `console.log()` instructions, CloudFront Functions envoie automatiquement ces lignes de journal à CloudWatch Logs. S'il n'y a aucune `console.log()` déclaration, rien n'est envoyé à CloudWatch Logs.
CloudFront Functions crée toujours des flux de journaux dans la région de l'est des États-Unis (Virginie du Nord) (`us-east-1`), quel que soit l'emplacement périphérique sur lequel la fonction a été exécutée. Le nom du flux de journal est au format `YYYY/M/D/UUID`.
Le nom du groupe de journaux utilise le format suivant :
+ Pour CloudFront les fonctions au niveau du comportement du cache, le format est `/aws/cloudfront/function/`
+ Pour les CloudFront fonctions au niveau de la distribution (fonctions de connexion), le format est `/aws/cloudfront/connection-function/`
``Il s'agit du nom que vous avez donné à la fonction lorsque vous l'avez créée.
**Example Demandes des spectateurs**
Voici un exemple de message de journal envoyé à CloudWatch Logs. Chaque ligne commence par un identifiant qui identifie de manière unique une CloudFront demande. Le message commence par une `START` ligne qui inclut l'ID CloudFront de distribution et se termine par une `END` ligne. Entre les lignes `START` et `END` se trouvent les lignes de journal générées par les instructions `console.log()` de la fonction.
```
U7b4hR_RaxMADupvKAvr8_m9gsGXvioUggLV5Oyq-vmAtH8HADpjhw== START DistributionID: E3E5D42GADAXZZ
U7b4hR_RaxMADupvKAvr8_m9gsGXvioUggLV5Oyq-vmAtH8HADpjhw== Example function log output
U7b4hR_RaxMADupvKAvr8_m9gsGXvioUggLV5Oyq-vmAtH8HADpjhw== END
```
**Example Demandes de connexion**
Voici un exemple de message de journal envoyé à CloudWatch Logs. Chaque ligne commence par un identifiant qui identifie de manière unique une CloudFront demande. Le message commence par une `START` ligne qui inclut l'ID CloudFront de distribution et se termine par une `END` ligne. Entre les lignes `START` et `END` se trouvent les lignes de journal générées par les instructions `console.log()` de la fonction.
```
U7b4hR_RaxMADupvKAvr8_m9gsGXvioUggLV5Oyq-vmAtH8HADpjhw== START DistributionID: E3E5D42GADA123
U7b4hR_RaxMADupvKAvr8_m9gsGXvioUggLV5Oyq-vmAtH8HADpjhw== 1.2.3.4
U7b4hR_RaxMADupvKAvr8_m9gsGXvioUggLV5Oyq-vmAtH8HADpjhw== END
```
**Note**
CloudFront Functions envoie des journaux CloudWatch uniquement pour les fonctions de la `LIVE` phase qui s'exécutent en réponse aux demandes et réponses de production. Lorsque vous [testez une fonction](test-function.md), CloudFront elle n'envoie aucun journal à CloudWatch. Le résultat du test contient des informations sur les erreurs, l'utilisation du calcul et les journaux de fonctionnement (`console.log()`instructions), mais ces informations ne sont pas envoyées à CloudWatch.
CloudFront Functions utilise un [rôle lié à un service Gestion des identités et des accès AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM) pour envoyer les journaux aux CloudWatch journaux de votre compte. Un rôle lié à un service est un rôle IAM directement associé à un Service AWS. Les rôles liés au service sont prédéfinis par le service et incluent toutes les autorisations dont le service a besoin Services AWS pour appeler d'autres personnes à votre place. CloudFront Functions utilise le rôle **AWSServiceRoleForCloudFrontLogger**lié au service. Pour plus d'informations sur ce rôle, consultez [Rôles liés à un service pour Lambda@Edge](lambda-edge-permissions.md#using-service-linked-roles-lambda-edge) (Lambda@Edge utilise le même rôle lié au service).
Lorsqu'une fonction échoue en raison d'une erreur de validation ou d'exécution, les informations sont enregistrées dans des [journaux standard et des journaux](AccessLogs.md) [d'accès en temps réel](real-time-logs.md). Pour obtenir des informations précises sur l’erreur, consultez les champs `x-edge-result-type`, `x-edge-response-result-type` et `x-edge-detailed-result-type`.
# Journalisation des appels CloudFront d'API Amazon à l'aide AWS CloudTrail
CloudFront est intégré à [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)un service qui fournit un enregistrement des actions entreprises par un utilisateur, un rôle ou un Service AWS. CloudTrail capture tous les appels d'API CloudFront sous forme d'événements. Les appels capturés incluent des appels provenant de la CloudFront console et des appels de code vers les opérations de l' CloudFront API. À l'aide des informations collectées par CloudTrail, vous pouvez déterminer la demande qui a été faite CloudFront, l'adresse IP à partir de laquelle la demande a été faite, la date à laquelle elle a été faite et des informations supplémentaires.
Chaque événement ou entrée de journal contient des informations sur la personne ayant initié la demande. Les informations relatives à l’identité permettent de déterminer :
+ Si la demande a été effectuée avec des informations d’identification d’utilisateur root ou d’utilisateur root.
+ Si la demande a été faite au nom d'un utilisateur du centre d'identité IAM.
+ Si la demande a été effectuée avec les informations d’identification de sécurité temporaires d’un rôle ou d’un utilisateur fédéré.
+ Si la requête a été effectuée par un autre Service AWS.
CloudTrail est actif dans votre compte Compte AWS lorsque vous créez le compte et vous avez automatiquement accès à l'**historique des CloudTrail événements**. L'**historique des CloudTrail événements** fournit un enregistrement consultable, consultable, téléchargeable et immuable des 90 derniers jours des événements de gestion enregistrés dans un. Région AWS Pour plus d'informations, consultez la section [Utilisation de l'historique des CloudTrail événements](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) dans le *guide de AWS CloudTrail l'utilisateur*. La consultation de CloudTrail l'**historique des événements est gratuite**.
Pour un enregistrement continu des événements de vos 90 Compte AWS derniers jours, créez un magasin de données sur les événements de Trail ou [CloudTrailLake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html).
**CloudTrail sentiers**
Un *suivi* permet CloudTrail de fournir des fichiers journaux à un compartiment Amazon S3. Tous les sentiers créés à l'aide du AWS Management Console sont multirégionaux. Vous ne pouvez créer un journal de suivi en une ou plusieurs régions à l'aide de l' AWS CLI. Il est recommandé de créer un parcours multirégional, car vous capturez l'activité dans l'ensemble Régions AWS de votre compte. Si vous créez un journal de suivi pour une seule région, il convient de n'afficher que les événements enregistrés dans le journal de suivi pour une seule région Région AWS. Pour plus d'informations sur les journaux de suivi, consultez [Créez un journal de suivi dans vos Compte AWS](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) et [Création d'un journal de suivi pour une organisation](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/creating-trail-organization.html) dans le *AWS CloudTrail Guide de l'utilisateur*.
Vous pouvez envoyer une copie de vos événements de gestion en cours dans votre compartiment Amazon S3 gratuitement CloudTrail en créant un journal. Toutefois, des frais de stockage Amazon S3 sont facturés. Pour plus d'informations sur la CloudTrail tarification, consultez la section [AWS CloudTrail Tarification](https://aws.amazon.com/cloudtrail/pricing/). Pour obtenir des informations sur la tarification Amazon S3, consultez [Tarification Amazon S3](https://aws.amazon.com/s3/pricing/).
**CloudTrail Stockages de données sur les événements du lac**
*CloudTrail Lake* vous permet d'exécuter des requêtes SQL sur vos événements. CloudTrail Lake convertit les événements existants au format JSON basé sur les lignes au format [Apache ORC](https://orc.apache.org/). ORC est un format de stockage en colonnes qui est optimisé pour une récupération rapide des données. Les événements sont agrégés dans des *magasins de données d’événement*. Ceux-ci constituent des collections immuables d’événements basées sur des critères que vous sélectionnez en appliquant des [sélecteurs d’événements avancés](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-concepts.html#adv-event-selectors). Les sélecteurs que vous appliquez à un magasin de données d’événement contrôlent les événements qui persistent et que vous pouvez interroger. Pour plus d'informations sur CloudTrail Lake, consultez la section [Travailler avec AWS CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html) dans le *guide de AWS CloudTrail l'utilisateur*.
CloudTrail Les stockages et requêtes de données sur les événements de Lake entraînent des coûts. Lorsque vous créez un magasin de données d’événement, vous choisissez l’[option de tarification](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-manage-costs.html#cloudtrail-lake-manage-costs-pricing-option) que vous voulez utiliser pour le magasin de données d’événement. L’option de tarification détermine le coût d’ingestion et de stockage des événements, ainsi que les périodes de conservation par défaut et maximale pour le magasin de données d’événement. Pour plus d'informations sur la CloudTrail tarification, consultez la section [AWS CloudTrail Tarification](https://aws.amazon.com/cloudtrail/pricing/).
**Note**
CloudFront est un service mondial. CloudTrail enregistre des événements CloudFront dans la région de l'est des États-Unis (Virginie du Nord). Pour plus d’informations, consultez [Événements de services mondiaux](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-concepts.html#cloudtrail-concepts-global-service-events) dans le *Guide de l’utilisateur AWS CloudTrail *.
Si vous utilisez des informations d'identification de sécurité temporaires en utilisant AWS Security Token Service, les appels vers les points de terminaison régionaux`us-west-2`, tels que, sont connectés CloudTrail à la région appropriée.
Pour plus d'informations sur les CloudFront points de terminaison, consultez la section [CloudFront Points de terminaison et quotas](https://docs.aws.amazon.com/general/latest/gr/cf_region.html) dans le. *Références générales AWS*
## CloudFront événements de données dans CloudTrail
[Les événements de données](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events) fournissent des informations sur les opérations de ressources effectuées sur ou dans une ressource (par exemple, lecture ou écriture dans une CloudFront distribution). Ils sont également connus sous le nom opérations de plans de données. Les événements de données sont souvent des activités à fort volume. Par défaut, CloudTrail n'enregistre pas les événements liés aux données. L'**historique des CloudTrail événements** n'enregistre pas les événements liés aux données.
Des frais supplémentaires s’appliquent pour les événements de données. Pour plus d'informations sur la CloudTrail tarification, consultez la section [AWS CloudTrail Tarification](https://aws.amazon.com/cloudtrail/pricing/).
Vous pouvez enregistrer les événements de données pour les types de CloudFront ressources à l'aide de la CloudTrail console ou AWS CLI des opérations de CloudTrail l'API. Pour plus d’informations sur la façon de journaliser les événements de données, consultez [Journalisation des événements de données avec la AWS Management Console](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events-console) et [Journalisation des événements de données avec l’ AWS Command Line Interface](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#creating-data-event-selectors-with-the-AWS-CLI) dans le *Guide de l’utilisateur AWS CloudTrail *.
Le tableau suivant répertorie les types de CloudFront ressources pour lesquels vous pouvez enregistrer des événements de données. La colonne **Type d'événement de données (console)** indique la valeur à choisir dans la liste des **types d'événements de données** de la CloudTrail console. La colonne de valeur **resources.type indique la `resources.type` valeur** que vous devez spécifier lors de la configuration de sélecteurs d'événements avancés à l'aide du ou. AWS CLI CloudTrail APIs La CloudTrail colonne **Données APIs enregistrées** indique les appels d'API enregistrés CloudTrail pour le type de ressource.
| Type d’événement de données (console) | valeur resources.type | Données APIs enregistrées sur CloudTrail |
| --- | --- | --- |
| CloudFront KeyValueStore | AWS::CloudFront::KeyValueStore | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/logging_using_cloudtrail.html) |
Vous pouvez configurer des sélecteurs d’événements avancés pour filtrer les champs `eventName`, `readOnly` et `resources.ARN` afin de ne journaliser que les événements importants pour vous. Pour plus d’informations sur ces champs, consultez [https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html](https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html) dans la *Référence des API AWS CloudTrail *.
## CloudFront événements de gestion dans CloudTrail
[Les événements de gestion](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-management-events-with-cloudtrail.html#logging-management-events) fournissent des informations sur les opérations de gestion effectuées sur les ressources de votre Compte AWS. Ils sont également connus sous le nom opérations de plan de contrôle. Par défaut, CloudTrail enregistre les événements de gestion.
Amazon CloudFront enregistre toutes les opérations CloudFront du plan de contrôle en tant qu'événements de gestion. Pour obtenir la liste des opérations du plan de CloudFront contrôle Amazon auxquelles CloudFront se connecte CloudTrail, consultez le [Amazon CloudFront API Reference](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_Operations_Amazon_CloudFront.html).
## CloudFront exemples d'événements
Un événement représente une demande unique provenant de n'importe quelle source et inclut des informations sur l'opération d'API demandée, la date et l'heure de l'opération, les paramètres de la demande, etc. CloudTrail les fichiers journaux ne constituent pas une trace ordonnée des appels d'API publics. Les événements n'apparaissent donc pas dans un ordre spécifique.
**Contents**
+ [Exemple : UpdateDistribution](#example-cloudfront-service-cloudtrail-log)
+ [Exemple : UpdateKeys](#example-cloudfront-kvs-cloudtrail-log)
### Exemple : UpdateDistribution
L'exemple suivant montre un CloudTrail événement illustrant l'[UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)opération.
Pour les appels à l' CloudFront API, `eventSource` c'est`cloudfront.amazonaws.com`.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AIDACKCEVSQ6C2EXAMPLE:role-session-name",
"arn": "arn:aws:sts::111122223333:assumed-role/Admin/role-session-name",
"accountId": "111122223333",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AIDACKCEVSQ6C2EXAMPLE",
"arn": "arn:aws:iam::111122223333:role/Admin",
"accountId": "111122223333",
"userName": "Admin"
},
"webIdFederationData": {},
"attributes": {
"creationDate": "2024-02-02T19:23:50Z",
"mfaAuthenticated": "false"
}
}
},
"eventTime": "2024-02-02T19:26:01Z",
"eventSource": "cloudfront.amazonaws.com",
"eventName": "UpdateDistribution",
"awsRegion": "us-east-1",
"sourceIPAddress": "52.94.133.137",
"userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36",
"requestParameters": {
"distributionConfig": {
"defaultRootObject": "",
"aliases": {
"quantity": 3,
"items": [
"alejandro_rosalez.awsps.myinstance.com",
"cross-testing.alejandro_rosalez.awsps.myinstance.com",
"*.alejandro_rosalez.awsps.myinstance.com"
]
},
"cacheBehaviors": {
"quantity": 0,
"items": []
},
"httpVersion": "http2and3",
"originGroups": {
"quantity": 0,
"items": []
},
"viewerCertificate": {
"minimumProtocolVersion": "TLSv1.2_2021",
"cloudFrontDefaultCertificate": false,
"aCMCertificateArn": "arn:aws:acm:us-east-1:111122223333:certificate/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"sSLSupportMethod": "sni-only"
},
"webACLId": "arn:aws:wafv2:us-east-1:111122223333:global/webacl/testing-acl/a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"customErrorResponses": {
"quantity": 0,
"items": []
},
"logging": {
"includeCookies": false,
"prefix": "",
"enabled": false,
"bucket": ""
},
"priceClass": "PriceClass_All",
"restrictions": {
"geoRestriction": {
"restrictionType": "none",
"quantity": 0,
"items": []
}
},
"isIPV6Enabled": true,
"callerReference": "1578329170895",
"continuousDeploymentPolicyId": "",
"enabled": true,
"defaultCacheBehavior": {
"targetOriginId": "d111111abcdef8",
"minTTL": 0,
"compress": false,
"maxTTL": 31536000,
"functionAssociations": {
"quantity": 0,
"items": []
},
"trustedKeyGroups": {
"quantity": 0,
"items": [],
"enabled": false
},
"smoothStreaming": false,
"fieldLevelEncryptionId": "",
"defaultTTL": 86400,
"lambdaFunctionAssociations": {
"quantity": 0,
"items": []
},
"viewerProtocolPolicy": "redirect-to-https",
"forwardedValues": {
"cookies": {"forward": "none"},
"queryStringCacheKeys": {
"quantity": 0,
"items": []
},
"queryString": false,
"headers": {
"quantity": 1,
"items": ["*"]
}
},
"trustedSigners": {
"items": [],
"enabled": false,
"quantity": 0
},
"allowedMethods": {
"quantity": 2,
"items": [
"HEAD",
"GET"
],
"cachedMethods": {
"quantity": 2,
"items": [
"HEAD",
"GET"
]
}
}
},
"staging": false,
"origins": {
"quantity": 1,
"items": [
{
"originPath": "",
"connectionTimeout": 10,
"customOriginConfig": {
"originReadTimeout": 30,
"hTTPSPort": 443,
"originProtocolPolicy": "https-only",
"originKeepaliveTimeout": 5,
"hTTPPort": 80,
"originSslProtocols": {
"quantity": 3,
"items": [
"TLSv1",
"TLSv1.1",
"TLSv1.2"
]
}
},
"id": "d111111abcdef8",
"domainName": "d111111abcdef8.cloudfront.net",
"connectionAttempts": 3,
"customHeaders": {
"quantity": 0,
"items": []
},
"originShield": {"enabled": false},
"originAccessControlId": ""
}
]
},
"comment": "HIDDEN_DUE_TO_SECURITY_REASONS"
},
"id": "EDFDVBD6EXAMPLE",
"ifMatch": "E1RTLUR9YES76O"
},
"responseElements": {
"distribution": {
"activeTrustedSigners": {
"quantity": 0,
"enabled": false
},
"id": "EDFDVBD6EXAMPLE",
"domainName": "d111111abcdef8.cloudfront.net",
"distributionConfig": {
"defaultRootObject": "",
"aliases": {
"quantity": 3,
"items": [
"alejandro_rosalez.awsps.myinstance.com",
"cross-testing.alejandro_rosalez.awsps.myinstance.com",
"*.alejandro_rosalez.awsps.myinstance.com"
]
},
"cacheBehaviors": {"quantity": 0},
"httpVersion": "http2and3",
"originGroups": {"quantity": 0},
"viewerCertificate": {
"minimumProtocolVersion": "TLSv1.2_2021",
"cloudFrontDefaultCertificate": false,
"aCMCertificateArn": "arn:aws:acm:us-east-1:111122223333:certificate/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"sSLSupportMethod": "sni-only",
"certificateSource": "acm",
"certificate": "arn:aws:acm:us-east-1:111122223333:certificate/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"webACLId": "arn:aws:wafv2:us-east-1:111122223333:global/webacl/testing-acl/a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"customErrorResponses": {"quantity": 0},
"logging": {
"includeCookies": false,
"prefix": "",
"enabled": false,
"bucket": ""
},
"priceClass": "PriceClass_All",
"restrictions": {
"geoRestriction": {
"restrictionType": "none",
"quantity": 0
}
},
"isIPV6Enabled": true,
"callerReference": "1578329170895",
"continuousDeploymentPolicyId": "",
"enabled": true,
"defaultCacheBehavior": {
"targetOriginId": "d111111abcdef8",
"minTTL": 0,
"compress": false,
"maxTTL": 31536000,
"functionAssociations": {"quantity": 0},
"trustedKeyGroups": {
"quantity": 0,
"enabled": false
},
"smoothStreaming": false,
"fieldLevelEncryptionId": "",
"defaultTTL": 86400,
"lambdaFunctionAssociations": {"quantity": 0},
"viewerProtocolPolicy": "redirect-to-https",
"forwardedValues": {
"cookies": {"forward": "none"},
"queryStringCacheKeys": {"quantity": 0},
"queryString": false,
"headers": {
"quantity": 1,
"items": ["*"]
}
},
"trustedSigners": {
"enabled": false,
"quantity": 0
},
"allowedMethods": {
"quantity": 2,
"items": [
"HEAD",
"GET"
],
"cachedMethods": {
"quantity": 2,
"items": [
"HEAD",
"GET"
]
}
}
},
"staging": false,
"origins": {
"quantity": 1,
"items": [
{
"originPath": "",
"connectionTimeout": 10,
"customOriginConfig": {
"originReadTimeout": 30,
"hTTPSPort": 443,
"originProtocolPolicy": "https-only",
"originKeepaliveTimeout": 5,
"hTTPPort": 80,
"originSslProtocols": {
"quantity": 3,
"items": [
"TLSv1",
"TLSv1.1",
"TLSv1.2"
]
}
},
"id": "d111111abcdef8",
"domainName": "d111111abcdef8.cloudfront.net",
"connectionAttempts": 3,
"customHeaders": {"quantity": 0},
"originShield": {"enabled": false},
"originAccessControlId": ""
}
]
},
"comment": "HIDDEN_DUE_TO_SECURITY_REASONS"
},
"aliasICPRecordals": [
{
"cNAME": "alejandro_rosalez.awsps.myinstance.com",
"iCPRecordalStatus": "APPROVED"
},
{
"cNAME": "cross-testing.alejandro_rosalez.awsps.myinstance.com",
"iCPRecordalStatus": "APPROVED"
},
{
"cNAME": "*.alejandro_rosalez.awsps.myinstance.com",
"iCPRecordalStatus": "APPROVED"
}
],
"aRN": "arn:aws:cloudfront::111122223333:distribution/EDFDVBD6EXAMPLE",
"status": "InProgress",
"lastModifiedTime": "Feb 2, 2024 7:26:01 PM",
"activeTrustedKeyGroups": {
"enabled": false,
"quantity": 0
},
"inProgressInvalidationBatches": 0
},
"eTag": "E1YHBLAB2BJY1G"
},
"requestID": "4e6b66f9-d548-11e3-a8a9-73e33example",
"eventID": "5ab02562-0fc5-43d0-b7b6-90293example",
"readOnly": false,
"eventType": "AwsApiCall",
"apiVersion": "2020_05_31",
"managementEvent": true,
"recipientAccountId": "111122223333",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_128_GCM_SHA256",
"clientProvidedHostHeader": "cloudfront.amazonaws.com"
},
"sessionCredentialFromConsole": "true"
}
```
### Exemple : UpdateKeys
L'exemple suivant montre un CloudTrail événement illustrant l'[UpdateKeys](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_kvs_UpdateKeys.html)opération.
Pour les appels à l' CloudFront KeyValueStore API, le `eventSource` est `edgekeyvaluestore.amazonaws.com` au lieu de`cloudfront.amazonaws.com`.
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AIDACKCEVSQ6C2EXAMPLE:role-session-name",
"arn": "arn:aws:sts::111122223333:assumed-role/Admin/role-session-name",
"accountId": "111122223333",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AIDACKCEVSQ6C2EXAMPLE",
"arn": "arn:aws:iam::111122223333:role/Admin",
"accountId": "111122223333",
"userName": "Admin"
},
"attributes": {
"creationDate": "2023-11-01T23:41:14Z",
"mfaAuthenticated": "false"
}
}
},
"eventTime": "2023-11-01T23:41:28Z",
"eventSource": "edgekeyvaluestore.amazonaws.com",
"eventName": "UpdateKeys",
"awsRegion": "us-east-1",
"sourceIPAddress": "3.235.183.252",
"userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36,
"requestParameters": {
"kvsARN": "arn:aws:cloudfront::111122223333:key-value-store/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"ifMatch": "KV3O6B1CX531EBP",
"deletes": [
{"key": "key1"}
]
},
"responseElements": {
"itemCount": 0,
"totalSizeInBytes": 0,
"eTag": "KVDC9VEVZ71ZGO"
},
"requestID": "5ccf104c-acce-4ea1-b7fc-73e33example",
"eventID": "a0b1b5c7-906c-439d-9925-90293example",
"readOnly": false,
"resources": [
{
"accountId": "111122223333",
"type": "AWS::CloudFront::KeyValueStore",
"ARN": "arn:aws:cloudfront::111122223333:key-value-store/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": false,
"recipientAccountId": "111122223333",
"eventCategory": "Data",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_128_GCM_SHA256",
"clientProvidedHostHeader": "111122223333.cloudfront-kvs.global.api.aws"
}
}
```
Pour plus d'informations sur le contenu des CloudTrail enregistrements, voir [le contenu des CloudTrail enregistrements](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html) dans le *Guide de AWS CloudTrail l'utilisateur*.