À propos des access logs

Les access logs fournissent des informations détaillées sur les requêtes envoyées à vos load balancers.

Par défaut, les access logs sont désactivés. Vous pouvez les activer ou désactiver à tout moment. Pour en savoir plus, voir Activer ou désactiver les access logs pour vos load balancers.

Informations générales

Les access logs sont publiés dans des fichiers logs dans un bucket OUTSCALE Object Storage (OOS). Pour activer les access logs, vous devez spécifier le nom du bucket OOS dans lequel le load balancer peut les publier. Pour en savoir plus, voir À propos d’OOS, Activer les access logs et Modifier les attributs d’un load balancer.

Le load balancer et le bucket OOS doivent être situés dans la même Région, mais peuvent appartenir à des comptes différents. Dans ce cas, vous devez accorder au load balancer les droits d’accès au bucket OOS. Pour en savoir plus, voir Configurer l’ACL d’un bucket.

Après la désactivation des access logs, les fichiers logs existants restent dans le bucket OOS jusqu’à ce que vous les supprimiez. Pour en savoir plus, voir Supprimer les objets d’un bucket.

Fichiers logs

Le load balancer publie un fichier log dans le bucket OOS toutes les 5 ou 60 minutes (par défaut, 60 minutes). Vous pouvez modifier cet intervalle à tout moment. Pour en savoir plus, voir Activer ou désactiver les access logs pour vos load balancers.

Les fichiers logs sont automatiquement nommés selon le format suivant :

bucket[/prefix]/OWSLogs/account-id/lbu/region/yyyy/mm/dd/account-id_lbu_region_load-balancer-name_end-time_ip-address_random-string.log

Ce format se compose des éléments suivants :

  • bucket : Le nom du bucket OOS dans lequel les access logs sont publiés.

  • prefix : Le chemin d’accès du répertoire dans le bucket OOS pour les access logs. Si aucun chemin d’accès n’est spécifié, ils sont publiés au niveau root du bucket.

  • account-id : L’ID du compte du propriétaire du load balancer.

  • region : La Région dans laquelle le load balancer et le bucket OOS sont situés.

  • yyyy/mm/dd : La date de publication du fichier log.

  • load-balancer-name : Le nom du load balancer qui a publié le fichier log.

  • end-time : La date et l’heure de fin de l’intervalle de publication. Par exemple, un fichier log daté 20170210T1940Z contient les access logs entre 19:35 et 19:40 si l’intervalle est de 5 minutes.

  • ip-address : L’IP du load balancer qui a traité la requête. Pour un load balancer interne, son IP privée.

  • random-string : Une chaîne de caractères aléatoire générée par le système.

Entrées logs

Dans un fichier log, chaque entrée log correspond à une seule requête envoyée au load balancer. Ceci inclut également les requêtes qui n’ont jamais atteint de machine virtuelle (VM) backend, telles que les requêtes mal formées ou les requêtes auxquelles aucune VM saine ne peut répondre.

Les entrées logs utilisent le format suivant :

  • Pour les protocoles HTTP et HTTPS

    timelog lbu user:port backend:port total_time/request_time/wait_time/connection_time/server_response_time lbu_state_code request_size response_size "request" "user_agent" ssl_cipher ssl_protocol

  • Pour les protocoles TCP et SSL

    timelog lbu user:port backend:port total_time/wait_time/connection_time lbu_state_code request_size response_size "request" "user_agent" ssl_cipher ssl_protocol

Les champs des entrées logs dépendent du protocole de routage du listener (HTTP, HTTPS, TCP, SSL). Ils sont séparés par un espace, excepté les champs de durée qui sont séparés par une barre oblique. Pour en savoir plus, voir À propos des load balancers.

Les champs suivants sont disponibles :

timelog

La date et l’heure à laquelle le load balancer a reçu la requête de l’utilisateur (par exemple 20170210T1940Z).

lbu

Le nom du load balancer qui a reçu la requête de l’utilisateur.

user:port

L’IP et le port utilisés par l’utilisateur pour se connecter au load balancer.

`backend:port `

L’IP et le port de la VM backend qui a traité la requête.

Cette valeur peut être :

  • “–” si l’utilisateur a envoyé une requête incomplète, que le load balancer ne peut donc distribuer à aucune VM backend.

  • “-1” si la VM backend ne répond pas avant le délai d’expiration.

total_time

La durée totale de traitement de la requête par le load balancer.

Cette durée correspond au temps écoulé entre :

  • Le moment où l’utilisateur envoie la requête au load balancer

  • Le moment où le load balancer renvoie la réponse à l’utilisateur.

request_time

(Listeners HTTP uniquement) La durée totale de réception de la requête de l’utilisateur par le load balancer.

Cette durée correspond au temps écoulé entre :

  • Le moment où le load balancer accepte la connexion de l’utilisateur

  • Le moment où le load balancer reçoit la dernière en-tête HTTP de réponse.

La valeur “-1” signifie que le load balancer n’a jamais reçu la ligne vide indiquant la fin des en-têtes, par exemple lorsque l’utilisateur est déconnecté prématurément.

wait_time

La durée totale d’attribution d’un créneau de connexion à la requête.

Cette durée inclut l’attente au serveur et à la VM backend. Elle dépend de la taille de la file d’attente, et du temps nécessaire aux serveur pour traiter les requêtes précédentes.

La valeur “-1” signifie que la requête a été annulée avant d’atteindre la file d’attente, par exemple lorsqu’elle est invalide ou refusée.

connection_time

La durée totale d’établissement de la connexion TCP à la VM backend par le load balancer.

Cette durée correspond au temps écoulé entre :

  • Le moment où le load balancer envoie la requête de connexion, ou le paquet TCP SYN

  • Le moment où la VM backend accepte la requête de connexion, ou renvoie le paquet SYN/ACK.

La valeur “-1” signifie que la connexion n’a jamais été établie.

server_response_time

(Listeners HTTP uniquement) La durée totale de réponse par la VM backend.

Cette durée correspond au temps écoulé entre :

  • Le moment où le load balancer établit une connexion TCP avec la VM backend

  • Le moment où la VM backend renvoie ses en-têtes de réponse complètes.

La valeur “-1” signifie que le load balancer n’a jamais reçu la ligne vide indiquant la fin des en-têtes, par exemple lorsque la VM backend est déconnectée avant la fin du traitement de la requête.

lbu_state_code

(Listeners HTTP uniquement) Le code HTTP de la réponse du load balancer.

request_size

La taille de la requête reçue de l’utilisateur, en octets.

Cette valeur inclut :

  • (Listeners HTTP/HTTPS) Le corps de la requête sans les en-têtes.

  • (Listeners TCP/SSL) Le corps de la requête avec les en-têtes.

response_size

La taille de la réponse renvoyée à l’utilisateur, en octets.

Cette valeur inclut :

  • (Listeners HTTP/HTTPS) Le corps de la requête sans les en-têtes.

  • (Listeners TCP/SSL) Le corps de la requête avec les en-têtes.

request

La requête de l’utilisateur, entre guillemets et au format suivant :

Méthode HTTP + Protocole://Host en-tête:port + chemin d'accès + version HTTP

(Listeners TCP) L’URL est remplacée par trois tirets séparés par un espace, et suivis d’un espace (- - - ).

user_agent

(Listeners HTTP/HTTPS uniquement) Une chaîne de caractères qui identifie l’utilisateur, entre guillemets.

Cette chaîne contient un ou plusieurs identifiants produit, au format suivant : produit[/version].

Au-delà de 8 Kio, la chaîne est tronquée.

ssl_cipher

(Listeners HTTPS/SSL uniquement) Le chiffrement SSL.

Ce champ apparaît uniquement si la connexion SSL/TLS entrante a été établie après une negotiation réussie. Sinon, sa valeur est “-”.

ssl_protocol

(Listeners HTTPS/SSL uniquement) Le protocole SSL.

Ce champ apparaît uniquement si la connexion SSL/TLS entrante a été établie après une negotiation réussie. Sinon, sa valeur est “-”.

Pages connexes

Exporter en PDF