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.
# 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/)