Elastic Load Balancing
Classic Load Balancers

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.

La journalisation des accès est une fonction facultative d'Elastic Load Balancing qui est désactivée par défaut. Une fois que vous avez activé la journalisation des 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.

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.

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

Préfixe (hiérarchie logique) dans le compartiment. Si vous ne spécifiez pas de préfixe, les journaux sont placés à la racine du compartiment.

aws-account-id

ID de compte AWS du propriétaire.

région

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

aaaa/mm/jj

Date à laquelle le journal a été fourni.

load-balancer-name

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 :

s3://my-loadbalancer-logs/my-app/AWSLogs/123456789012/elasticloadbalancing/us-west-2/2014/02/15/123456789012_elasticloadbalancing_us-west-2_my-loadbalancer_20140215T2340Z_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 de plus amples informations, veuillez consulter la rubrique Gestion du cycle de vie des objets dans le manuel Amazon Simple Storage Service Manuel du développeur.

Entrées de journal 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

timestamp

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

[Ecouteur 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.

[Ecouteur 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

[Ecouteur 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.

[Ecouteur 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

[Ecouteur 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.

[Ecouteur 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

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

backend_status_code

[Ecouteur 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).

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

[Ecouteur 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).

[Ecouteur 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.

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

user_agent

[Ecouteur 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

[Ecouteur 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

[Ecouteur 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. Vous pouvez ne pas être en mesure de traiter une telle quantité de données à l'aide d'un traitement ligne par ligne. 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 :