Journaux d'accès pour votre Classic Load Balancer - Elastic Load Balancing
Fichiers journaux d'accèsEntrées des journaux d'accèsTraitement des journaux d'accès

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 pour votre Classic Load Balancer

Elastic Load Balancing fournit des journaux d'accès qui capturent des informations détaillées sur les demandes envoyées à votre équilibreur de charge. Chaque journal contient des informations comme l'heure à laquelle la demande a été reçue, l'adresse IP du client, les latences, 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.

Les journaux d'accès sont une fonctionnalité facultative d'Elastic Load Balancing qui est désactivée par défaut. Une fois que vous avez activé les journaux d'accès pour votre équilibreur de charge, Elastic Load Balancing capture les journaux et les stocke dans le compartiment Amazon S3 que vous spécifiez. Vous pouvez désactiver la journalisation des accès à tout moment.

Tous les fichiers journaux des accès sont automatiquement chiffrés avec SSE-S3 avant d'être stockés dans votre compartiment S3, puis déchiffrés lorsque vous y accédez. Vous n'avez pas besoin d'intervenir ; le chiffrement et le déchiffrement sont effectués de manière transparente. Chaque fichier journal est chiffré à l'aide d'une clé unique qui est elle-même chiffrée à l'aide d'une clé principale faisant l'objet d'une rotation régulière. Pour plus d'informations, consultez la section Protection des données à l'aide du chiffrement côté serveur avec les clés de chiffrement gérés par Amazon S3 (SSE-S3) dans le Guide de l'utilisateur Amazon Simple Storage Service.

L'utilisation des journaux d'accès n'implique aucun coût supplémentaire. Les coûts de stockage pour Amazon S3 vous seront facturés, mais pas la bande passante utilisée par Elastic Load Balancing pour envoyer les fichiers journaux à Amazon S3. Pour plus d'informations sur les coûts de stockage, consultez Tarification Amazon S3.

Table des matières

Fichiers journaux d'accès

Elastic Load Balancing publie un fichier journal pour chaque nœud d'équilibreur de charge à l'intervalle que vous spécifiez. Vous pouvez spécifier un intervalle de publication de 5 minutes ou de 60 minutes lorsque vous activez le journal d'accès pour votre équilibreur de charge. Par défaut, Elastic Load Balancing publie les journaux à un intervalle de 60 minutes. Si l'intervalle est défini sur 5 minutes, les journaux sont publiés à 1 h 05, 1 h 10, 1 h 15, et ainsi de suite. Le démarrage de la livraison des journaux est différé de jusqu'à 5 minutes si l'intervalle est défini sur 5 minutes et jusqu'à 15 minutes si l'intervalle est défini sur 60 minutes. Vous pouvez modifier l'intervalle de publication à tout moment.

L'équilibreur de charge peut fournir plusieurs journaux pour la même période. Cela se produit généralement si le site connaît un trafic dense, dispose de plusieurs nœuds d'équilibreur de charge et a un intervalle court pour la publication des journaux.

Les noms de fichiers des journaux d'accès respectent le format suivant :

bucket[/prefix]/AWSLogs/aws-account-id/elasticloadbalancing/region/yyyy/mm/dd/aws-account-id_elasticloadbalancing_region_load-balancer-name_end-time_ip-address_random-string.log
bucket

Nom du compartiment S3.

prefix

(Facultatif) Préfixe (hiérarchie logique) pour le compartiment. Le préfixe que vous spécifiez ne doit pas inclure la chaîne AWSLogs. Pour plus d'informations, consultez Organisation des objets à l'aide de préfixes.

AWSLogs

Nous ajoutons la partie du nom de fichier commençant par AWSLogs après le nom du compartiment et le préfixe facultatif que vous avez spécifié.

aws-account-id

ID de compte AWS du propriétaire.

region

Région pour votre équilibreur de charge et le compartiment S3.

aaaa/mm/jj

Date à laquelle le journal a été fourni.

load-balancer-name

Le nom de l'équilibreur de charge.

end-time

Date et heure auxquelles l'intervalle de journalisation a pris fin. Par exemple, une heure de fin de 20140215T2340Z contient des entrées pour les demandes effectuées entre 23 h 35 et 23 h 40, si l'intervalle de publication est de 5 minutes.

ip-address

Adresse IP du nœud d'équilibreur de charge qui a traité la demande. Pour un équilibreur de charge, il s'agit d'une adresse IP privée.

random-string

Chaîne aléatoire générée par le système.

Voici un exemple de nom de fichier journal avec un préfixe « my-app » :

s3://my-loadbalancer-logs/my-app/AWSLogs/123456789012/elasticloadbalancing/us-west-2/2018/02/15/123456789012_elasticloadbalancing_us-west-2_my-loadbalancer_20180215T2340Z_172.160.001.192_20sg8hgm.log

Voici un exemple de nom de fichier journal sans préfixe :

s3://my-loadbalancer-logs/AWSLogs/123456789012/elasticloadbalancing/us-west-2/2018/02/15/123456789012_elasticloadbalancing_us-west-2_my-loadbalancer_20180215T2340Z_172.160.001.192_20sg8hgm.log

Vous pouvez stocker vos fichiers journaux dans votre compartiment aussi longtemps que vous le souhaitez, mais vous pouvez également définir des règles de cycle de vie Amazon S3 pour archiver ou supprimer automatiquement les fichiers journaux. Pour plus d'informations, consultez la section Gestion du cycle de vie des objets dans le Guide de l'utilisateur Amazon Simple Storage Service.

Entrées des journaux d'accès

Elastic Load Balancing consigne toutes les demandes envoyées à l'équilibreur de charge, y compris celles qui ne sont jamais parvenues aux instances principales. Par exemple, si un client envoie une demande incorrecte ou qu'il n'existe aucune instance saine pour répondre, les demandes sont quand-même consignées.

Important

Elastic Load Balancing consigne les demandes dans la mesure du possible. Il est recommandé d'utiliser les journaux d'accès pour comprendre la nature des demandes, et non comme comptabilisation complète de toutes les demandes.

Syntaxe

Chaque entrée contient les détails d'une seule demande adressée à l'équilibreur de charge. Tous les champs de l'entrée de journal sont séparés par des espaces. Chaque entrée du fichier journal a le format suivant :

timestamp elb client:port backend:port request_processing_time backend_processing_time response_processing_time elb_status_code backend_status_code received_bytes sent_bytes "request" "user_agent" ssl_cipher ssl_protocol

Le tableau suivant décrit les champs d'une entrée de journal d'accès.

Champ Description

time

Date et heure auxquelles l'équilibreur de charge a reçu les demandes, au format ISO 8601.

elb

Nom de l'équilibreur de charge

client:port

Adresse IP et port du client demandeur.

backend:port

Adresse IP et port de l'instance enregistrée qui a traité cette demande.

Si l'équilibreur de charge ne peut pas envoyer la demande à une instance enregistrée, ou si l'instance ferme la connexion avant qu'une réponse puisse être envoyée, cette valeur est définie sur -.

Cette valeur peut également être définie sur - si l'instance enregistrée ne répond pas avant le délai d'inactivité.

request_processing_time

[Écouteur HTTP] Durée totale écoulée, en secondes, du moment où l'équilibreur de charge a reçu la demande au moment où il l'a envoyée à une instance enregistrée.

[Écouteur TCP] Durée totale écoulée, en secondes, du moment où l'équilibreur de charge a accepté une connexion TCP/SSL à partir d'un client au moment où il envoie le premier octet de données à une instance enregistrée.

Cette valeur est définie sur -1 si l'équilibreur de charge ne peut pas envoyer la demande à une instance enregistrée. Cela peut se produire si l'instance enregistrée ferme la connexion avant la fin du délai d'inactivité ou si le client envoie une demande incorrecte. En outre, pour les auditeurs TCP, cela peut se produire si le client établit une connexion avec l'équilibreur de charge, mais n'envoie pas de données.

Cette valeur peut également être définie sur -1 si l'instance enregistrée ne répond pas avant le délai d'inactivité.

backend_processing_time

[Écouteur HTTP] Durée totale écoulée, en secondes, du moment où l'équilibreur de charge a envoyé la demande à une instance enregistrée au moment où l'instance a commencé à envoyer les en-têtes de réponse.

[Écouteur TCP] Délai total, en secondes, avant que l'équilibreur de charge parvienne à établir une connexion à une instance enregistrée.

Cette valeur est définie sur -1 si l'équilibreur de charge ne peut pas envoyer la demande à une instance enregistrée. Cela peut se produire si l'instance enregistrée ferme la connexion avant la fin du délai d'inactivité ou si le client envoie une demande incorrecte.

Cette valeur peut également être définie sur -1 si l'instance enregistrée ne répond pas avant le délai d'inactivité.

response_processing_time

[Écouteur HTTP] Durée totale écoulée (en secondes) du moment où l'équilibreur de charge a reçu l'en-tête de réponse de l'instance enregistrée au moment où il a commencé à envoyer la réponse au client. Cette durée inclut le temps en file d'attente sur l'équilibreur de charge et le temps d'acquisition de la connexion entre l'équilibreur de charge et le client.

[Écouteur TCP] Durée totale écoulée (en secondes) du moment où l'équilibreur de charge a reçu le premier octet de l'instance enregistrée au moment où il a commencé à envoyer la réponse au client.

Cette valeur est définie sur -1 si l'équilibreur de charge ne peut pas envoyer la demande à une instance enregistrée. Cela peut se produire si l'instance enregistrée ferme la connexion avant la fin du délai d'inactivité ou si le client envoie une demande incorrecte.

Cette valeur peut également être définie sur -1 si l'instance enregistrée ne répond pas avant le délai d'inactivité.

elb_status_code

[Écouteur HTTP] Code d'état de la réponse de l'équilibreur de charge.

backend_status_code

[Écouteur HTTP] Code d'état de la réponse de l'instance enregistrée.

received_bytes

Taille de la demande, en octets, reçue du client (demandeur).

[Écouteur HTTP] La valeur inclut le corps de la demande, mais pas les en-têtes.

[Écouteur TCP] La valeur inclut le corps de la demande et les en-têtes.

sent_bytes

Taille de la réponse, en octets, envoyée au client (demandeur).

[Écouteur HTTP] La valeur inclut le corps de la réponse, mais pas les en-têtes.

[Ecouteur TCP] La valeur inclut le corps de la demande et les en-têtes.

de la demande

Ligne de demande du client placée entre guillemets et consignée au format suivant : Méthode HTTP + Protocole://en-tête hôte:port + Chemin + Version HTTP. L'équilibreur de charge conserve en l'état l'URL envoyée par le client lors de l'enregistrement de l'URI de la demande. Il ne définit pas le type de contenu pour le fichier journal d'accès. Lorsque vous traitez ce champ, tenez compte de la façon dont le client a envoyé l'URL.

[Écouteur TCP] L'URL est constituée de trois tirets, séparés par un espace, et se termine par un espace (« --- »).

user_agent

[Écouteur HTTP/HTTPS] Chaîne Agent utilisateur qui identifie le client qui a envoyé la demande. La chaîne se compose d'un ou plusieurs identificateurs, et du produit/[version]. Si la chaîne dépasse 8 Ko, elle est tronquée.

ssl_cipher

[Écouteur HTTPS/SSL] Chiffrement SSL. Cette valeur est enregistrée uniquement si la connexion SSL/TLS entrante a été établie après une négociation réussie. Sinon, la valeur est définie sur -.

ssl_protocol

[Écouteur HTTPS/SSL] Protocole SSL. Cette valeur est enregistrée uniquement si la connexion SSL/TLS entrante a été établie après une négociation réussie. Sinon, la valeur est définie sur -.

Exemples

Exemple d'entrée HTTP

Voici un exemple d'entrée de journal pour un écouteur HTTP (port 80 vers port 80) :

2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.000073 0.001048 0.000057 200 200 0 29 "GET http://www.example.com:80/ HTTP/1.1" "curl/7.38.0" - -
Exemple d'entrée HTTPS

Voici un exemple d'entrée de journal pour un écouteur HTTPS (port 443 vers port 80) :

2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.000086 0.001048 0.001337 200 200 0 57 "GET https://www.example.com:443/ HTTP/1.1" "curl/7.38.0" DHE-RSA-AES128-SHA TLSv1.2
Exemple d'entrée TCP

Voici un exemple d'entrée de journal pour un écouteur TCP (port 8080 vers port 80) :

2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.001069 0.000028 0.000041 - - 82 305 "- - - " "-" - -
Exemple d'entrée SSL

Voici un exemple d'entrée de journal pour un écouteur SSL (port 8443 vers port 80) :

2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.001065 0.000015 0.000023 - - 57 502 "- - - " "-" ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2

Traitement des journaux d'accès

Si la demande est importante sur votre site web, votre équilibreur de charge peut générer des fichiers journaux avec des gigaoctets de données. Il se peut que vous ne puissiez pas traiter une telle quantité de données à l'aide du line-by-line traitement. Vous devrez donc peut-être utiliser des outils d'analyse qui proposent des solutions de traitement en parallèle. Par exemple, vous pouvez utiliser les outils d'analyse suivants pour analyser et traiter des journaux d'accès :