Activer et gérer les journaux d'accès ALB | Application Load Balancer - Server Load Balancer

Pour analyser le comportement des utilisateurs, comprendre la répartition géographique de votre audience et résoudre les problèmes à partir des journaux d'accès, utilisez la fonctionnalité de journalisation fournie par ALB conjointement avec Simple Log Service (SLS).

Les journaux d'accès ALB conviennent aux scénarios d'audit des requêtes, de diagnostic des pannes et d'analyse des performances. Ils offrent des capacités de journalisation similaires à celles des passerelles web traditionnelles telles que Nginx. Exploitez ces journaux pour interroger des informations comme les en-têtes de requête HTTP, les codes d'état et la distribution de la latence, afin de diagnostiquer des problèmes tels que les URL erronées dans les requêtes, une latence API élevée ou des écarts entre les données de surveillance et le volume de trafic réel. Les journaux d'accès n'enregistrent que les requêtes HTTP/HTTPS établies avec succès ; ils ne consignent pas les événements tels que les échecs de connexion TCP, les balayages de ports ou les échecs de handshake TLS.

Facturation

Une fois les journaux d'accès ALB acheminés vers Simple Log Service, vous êtes facturé pour le stockage, le trafic en lecture, les requêtes, la transformation des données et l'expédition. Pour plus d'informations, consultez la rubrique Facturation de Simple Log Service.

Prérequis

Simple Log Service est activé. Activer Simple Log Service.

Créer un journal d'accès

Connectez-vous à la console ALB.
Dans la barre de navigation supérieure, sélectionnez la région où est déployée l'instance ALB.
Sur la page Instances, cliquez sur l'ID de l'instance à gérer.
Sur la page des détails de l'instance, cliquez sur l'onglet Access Logs puis sur Create Access Log.

Dans la boîte de dialogue Create Access Log , configurez les paramètres Project et Logstore , puis cliquez sur OK.

Paramètre	Description
Project	Sélectionnez un projet Simple Log Service pour gérer les ressources. Options : Select Project : sélectionnez un projet existant dans la liste déroulante. Create Project : saisissez un nom de projet dans le champ.
Logstore	Sélectionnez un Logstore pour collecter, stocker et interroger les données de journal. Options : Select Logstore : sélectionnez un Logstore existant dans la liste déroulante. Create Logstore : saisissez un nom de Logstore dans le champ. Si vous sélectionnez Create Project, vous devez également sélectionner Create Logstore.
Notes on Creating Service-linked Role	Un rôle lié au service est créé automatiquement.

Dans le message qui s'affiche, lisez les informations et cliquez sur OK.
- Si vous créez un Logstore, les index et les tableaux de bord sont activés par défaut.
- Si vous sélectionnez un Logstore existant, les tableaux de bord sont activés automatiquement. Les index existants ne sont pas écrasés. Créez les index dans la console Simple Log Service.

Consulter un journal d'accès

Sur l'onglet Access Logs , cliquez sur le lien situé à droite de Simple Log Service pour accéder à la console Simple Log Service et consulter les données de journal.

Sur l'onglet Access Logs , cliquez sur l'onglet Monitoring Center , Access Center ou Fine-grained Monitoring et spécifiez des conditions de filtre pour interroger les métriques.

Module

Description

Monitoring Center

Affiche les données de surveillance en temps réel : PV, taux de réussite des requêtes, latence moyenne, requêtes 4xx, distribution des statuts, trafic, latence P50/P90/P99/P9999, ainsi que les hôtes/URL/backends les plus sollicités en termes de requêtes, de latence et de taux d'échec.

Access center

Affiche les statistiques d'accès : comparaisons jour par jour et semaine par semaine des PV/UV, distribution des PV/UV, PV du jour, PV sur 7 jours, top 10 des États avec le plus de requêtes, pourcentage d'utilisateurs mobiles, top 10 des hôtes, top 10 des user agents et adresses IP générant le plus de requêtes.

Fine-grained Monitoring

Affiche les métriques agrégées à des intervalles d'une seconde pour identifier les fluctuations transitoires : QPS, latence d'accès, latence amont, taux de réussite, trafic des requêtes, trafic du corps de réponse, code d'état 2xx, code d'état 3xx, codes d'erreur, code d'état amont 2xx, code d'état amont 3xx et codes d'erreur amont.

Dans le coin supérieur droit de l'onglet Monitoring Center , Access Center ou Fine-grained Monitoring , cliquez sur More Charts pour accéder à la page CloudLens for ALB et consulter davantage de rapports ALB . Pour plus d'informations, reportez-vous à la rubrique Rapports de données.
Dans le coin supérieur droit de l'onglet Monitoring Center , Access Center ou Fine-grained Monitoring , cliquez sur Configure Alert Rules pour accéder à la page CloudLens for ALB et consulter les incidents d'alerte ALB .
Vous pouvez également utiliser les fonctionnalités suivantes dans le coin supérieur droit de l'onglet Monitoring Center , Access Center ou Fine-grained Monitoring :
- : active Dedicated SQL. Activer Dedicated SQL.
- Après l'acheminement vers Simple Log Service, vous pouvez interroger, analyser, télécharger, expédier et traiter les journaux d'accès, ainsi que créer des règles d'alerte. Pour plus d'informations, reportez-vous à la rubrique Opérations courantes pour les journaux de service.

Enregistrer des en-têtes personnalisés

Le champ slb_headers enregistre les noms et les valeurs des en-têtes de requête personnalisés à des fins d'analyse des requêtes.

La taille maximale des en-têtes personnalisés par journal d'accès est de 1 Ko (extensible à 4 Ko). Pour demander une augmentation, contactez votre gestionnaire de compte. Pour plus d'informations, reportez-vous à la rubrique Limites de longueur des requêtes

Si la longueur totale des en-têtes personnalisés dans une seule entrée de journal dépasse la limite précédente, le champ slb_headers n'enregistre que les en-têtes tenant dans la limite et ajoute Discarded:TooManyCustomizedHeaders à la fin de la valeur du champ.

L'édition Extensible ne prend pas en charge l'enregistrement des en-têtes personnalisés.

Sur l'onglet Access Logs , cliquez sur Record Custom Headers dans la section Basic Information .
Dans la boîte de dialogue Record Custom HTTP Headers in Logs , sélectionnez l'écouteur ajouté à l'instance ALB dans la liste déroulante.

Pour créer un écouteur, cliquez sur Create Listener dans la liste déroulante. Pour plus d'informations, reportez-vous aux rubriques Ajouter un écouteur HTTP , Ajouter un écouteur HTTPS et Ajouter un écouteur QUIC .

Dans le message qui s'affiche, lisez les informations et cliquez sur OK.

Après configuration, le champ slb_headers enregistre tous les en-têtes de requête, à l'exception de :

# The slb_headers field does not record information about the following headers:
host
referer
user-agent
x-forwarded-for
x-readtime
x-real-ip
uber-trace-id
X-B3-TraceId
X-B3-SpanId
X-B3-ParentSpanId
X-B3-Sampled

Supprimer un journal d'accès

Sur l'onglet Access Logs , cliquez sur Disable Logging dans la section Basic Information .
Dans le message qui s'affiche, lisez les informations et cliquez sur OK.

Champs de journal

Standard Edition

Champ

Description

app_lb_id

ID de l'instance ALB.

__topic__

Sujet du journal. Par défaut : alb_layer7_access_log.

body_bytes_sent

Taille du corps de la réponse HTTP. Unité : octets.

client_ip

Adresse IP du client si l'option Retrieve Client IP est activée ; sinon, adresse IP du saut précédent.

host

Nom de domaine ou adresse IP. Ordre de résolution : paramètres de requête → en-tête host → IP du serveur backend.

http_host

En-tête Host d'une requête HTTP.

http_referer

En-tête Referer d'une requête HTTP.

http_user_agent

En-tête User-Agent d'une requête HTTP.

http_x_forwarded_for

En-tête X-Forwarded-For d'une requête HTTP.

http_x_real_ip

En-tête X-Real-IP d'une requête HTTP.

read_request_time

Durée nécessaire à ALB pour lire la requête. Unité : millisecondes.

request_length

Taille combinée de la ligne de début de requête, des en-têtes et du corps. Unité : octets.

request_method

Méthode de requête.

request_time

Délai entre la réception de la requête et le retour de la réponse. Unité : secondes.

request_uri

URI d'une requête.

scheme

Schéma de requête : HTTP ou HTTPS.

server_protocol

Version du protocole HTTP. Exemples : HTTP/1,0, HTTP/1,1.

slb_vport

Port de l'écouteur de l'instance ALB.

slb_xtrace

ID de trace de l'instance ALB pour l'analyse de traçage.

xtrace_type

Type de données utilisé par Xtrace pour l'analyse de traçage de l'instance ALB. Seul Zipkin est pris en charge.

ssl_cipher

Suite de chiffrement utilisée pour la connexion SSL. Exemple : ECDHE-RSA-AES128-GCM-SHA256.

ssl_protocol

Protocole de connexion SSL. Exemple : TLS 1.2.

status

Code d'état HTTP renvoyé par l'instance ALB.

tcpinfo_rtt

Durée d'établissement de la connexion TCP. Unité : millisecondes.

time

Heure de génération du journal au format ISO 8601 : YYYY-MM-DDThh:mm:ssZ .

upstream_addr

Adresse IP et port du serveur backend.

upstream_response_time

Délai entre l'établissement et la fermeture de la connexion backend. Unité : secondes.

upstream_status

Code d'état HTTP provenant du serveur backend.

vip_addr

Adresse IP virtuelle.

write_response_time

Durée d'écriture de la réponse. Unité : millisecondes.

client_port

Numéro de port du client.

slb_headers

En-têtes personnalisés. Disponible uniquement après activation de l'enregistrement des en-têtes personnalisés.

Extensible Edition

Champ	Description
app_lb_id	ID de l'instance ALB.
__topic__	Sujet du journal. Par défaut : alb_layer7_access_log.
body_bytes_sent	Taille du corps de la réponse HTTP. Unité : octets.
client_ip	Adresse IP du client si l'option Retrieve Client IP est activée ; sinon, adresse IP du saut précédent.
host	Nom de domaine ou adresse IP. Ordre de résolution : paramètres de requête → en-tête host → IP du serveur backend.
http_referer	En-tête Referer d'une requête HTTP.
http_user_agent	En-tête User-Agent d'une requête HTTP.
http_x_forwarded_for	En-tête X-Forwarded-For d'une requête HTTP. Enregistre la valeur X-Forwarded-For après réécriture par ALB.
http_x_real_ip	En-tête X-Real-IP d'une requête HTTP.
read_request_time	Durée nécessaire à ALB pour lire la requête. Unité : millisecondes.
request_length	Taille combinée de la ligne de début de requête, des en-têtes et du corps. Unité : octets.
request_method	Méthode de requête.
request_time	Délai entre la réception de la requête et le retour de la réponse. Unité : secondes.
request_uri	URI d'une requête.
scheme	Schéma de requête : HTTP ou HTTPS.
server_protocol	Version du protocole HTTP. Exemples : HTTP/1,0, HTTP/1,1.
slb_vport	Port de l'écouteur de l'instance ALB.
ssl_cipher	Suite de chiffrement utilisée pour la connexion SSL. Exemple : ECDHE-RSA-AES128-GCM-SHA256.
ssl_protocol	Protocole de connexion SSL. Exemple : TLS 1.2.
status	Code d'état HTTP renvoyé par l'instance ALB.
time	Heure de génération du journal au format ISO 8601 : `YYYY-MM-DDThh:mm:ssZ`.
upstream_addr	Adresse IP et port du serveur backend.
upstream_response_time	Délai entre l'établissement et la fermeture de la connexion backend. Unité : secondes.
vip_addr	Adresse IP virtuelle.
write_response_time	Durée d'écriture de la réponse. Unité : millisecondes.
client_port	Numéro de port du client.
upstream_protocol	Version du protocole HTTP utilisée pour la communication entre ALB et le serveur backend.
upstream_hostname	Nom de domaine DNS du serveur backend. Si aucun nom de domaine DNS n'est disponible, l'adresse IP et le port du serveur backend sont utilisés.
response_flags	Détails supplémentaires concernant la réponse ou la connexion.
status_details	Informations détaillées sur le code d'état de la réponse, telles que via_upstream, direct_response et route_not_found.
llm_log	Données de requête IA, encodées au format JSON. Elles contiennent les sous-champs suivants : chat_id : ID de la conversation LLM. chat_round : Tour de conversation actuel. first_token_duration : Latence entre l'envoi de la requête en flux et la réception de la première réponse de jeton, en millisecondes. input_token : Nombre de jetons dans la requête. output_token : Nombre de jetons dans la réponse. total_token : Nombre total de jetons. model : Modèle effectivement appelé pour cette requête. response_type : Type de réponse (flux ou non-flux).

Exemples de requêtes

Sur la page d'interrogation des journaux de la console Simple Log Service , vous pouvez filtrer les journaux d'accès ALB de plusieurs manières :

Filtrer par heure : utilisez le sélecteur de temps en haut de la page pour choisir une plage horaire, par exemple les 15 dernières minutes, la dernière heure, aujourd'hui ou une plage personnalisée.
Filtrer par URL : saisissez request_uri:/api/xxx dans la zone de saisie de la requête pour afficher uniquement les entrées de journal dont l'URI de requête contient /api/xxx .
Filtrer par code d'état : saisissez status:200 ou status:5* pour interroger les requêtes ayant un code d'état spécifique.
Filtrer par méthode de requête : saisissez request_method:Get* pour filtrer les requêtes GET.
Requête multi-critères : saisissez request_uri:/api/xxx and status:200 pour filtrer les requêtes correspondant à un modèle d'URI spécifique et renvoyant un code d'état 200.

Important

Avant d'utiliser la syntaxe field:value pour des requêtes spécifiques aux champs, configurez les index au niveau des champs pour les champs de journal correspondants dans la console Simple Log Service. Les index en texte intégral ne prennent pas en charge les requêtes au niveau des champs. Si les index au niveau des champs ne sont pas configurés, la requête renvoie une erreur. Pour la liste des champs disponibles pour l'indexation, consultez le tableau Champs de journal ci-dessus.

FAQ

Puis-je consulter les données relatives aux requêtes adressées à mon instance ALB avant la création d'un journal d'accès ?

Non, ce n'est pas possible.

Les journaux d'accès ne capturent les données qu'à partir du moment où vous les activez. Avant la création d'un journal d'accès, Simple Log Service ne collecte aucune donnée d'accès provenant d'ALB.

Pourquoi la surveillance ALB affiche-t-elle des anomalies (telles que des erreurs 4XX ou des volumes de trafic élevés) ou une activité de balayage, alors qu'aucun enregistrement n'apparaît dans les journaux d'accès ?

Les causes possibles sont les suivantes :

1. Les journaux d'accès ne sont pas activés

Vous devez activer la fonctionnalité de journal d'accès ALB pour interroger les informations détaillées sur les erreurs, les URL des requêtes et vérifier l'exactitude des données. Sans activation des journaux d'accès, il est difficile de résoudre les problèmes en se basant uniquement sur les données de surveillance.

2. Échecs de connexion TCP ou balayage de ports

ALB est un équilibreur de charge de couche 7. Les journaux d'accès n'enregistrent que les requêtes HTTP/HTTPS et ne consignent pas les échecs de connexion TCP. Pour identifier et bloquer les adresses IP anormales, activez Cloud Firewall afin de consulter les enregistrements des connexions TCP ayant échoué vers l'adresse IP publique d'ALB.

3. Délai d'expiration de l'écouteur de couche 4

Les délais d'expiration des écouteurs TCP de couche 4 ne sont généralement pas enregistrés dans les journaux Ingress ou les journaux d'accès. Une entrée avec un code d'état 499 ou 504 peut être générée uniquement lorsqu'une connexion est établie avec succès mais que la réponse expire.

4. Échec du handshake TLS

Les échecs de handshake TLS (tels qu'une inadéquation de certificat ou une incompatibilité de version de protocole) ne peuvent généralement pas être reflétés directement dans les journaux d'accès, car la requête HTTP n'a pas été établie lorsque le handshake échoue. Ces problèmes nécessitent une analyse utilisant les journaux du serveur backend et la capture de paquets côté client.

Comment utiliser les journaux d'accès ALB pour résoudre les problèmes d'URL erronées, de latence élevée ou pour retrouver des enregistrements de requêtes spécifiques ?

Connectez-vous à la console Simple Log Service , accédez au Logstore ALB correspondant et effectuez des requêtes selon les scénarios suivants :

1. Interroger les URL renvoyant des codes d'état spécifiques (tels que 400 ou 4XX)

Dans la zone de saisie de la requête, entrez status:400 (ou un autre code d'état, tel que status:5* ). Vérifiez le champ request_uri dans les résultats pour identifier les chemins d'URL spécifiques ayant renvoyé l'erreur.

2. Résoudre les problèmes de latence élevée des interfaces

Appliquez un filtre sur le champ upstream_response_time , qui enregistre le temps écoulé entre l'établissement de la connexion par ALB au serveur backend et la fin de la réception des données (unité : secondes). Une valeur élevée indique que la latence est causée par le traitement backend plutôt que par le transfert ALB. Comparez cette valeur avec le champ request_time pour confirmer le temps total écoulé (intervalle entre la réception de la requête client et le retour de la réponse, unité : secondes).

3. Vérifier les enregistrements de requêtes pour des chemins ou des IP sources spécifiques

Des champs tels que request_uri ne sont pas indexés par défaut dans le Logstore SLS, vous ne pouvez donc pas effectuer de recherche directe par mot-clé de chemin. Utilisez des champs indexés tels que client_ip (IP client) ou http_host (Host de la requête) dans des requêtes combinées pour confirmer si ALB a reçu des requêtes provenant de la source spécifiée. Pour rechercher directement request_uri , créez d'abord un index pour ce champ dans la console SLS.

4. Vérifier l'exactitude des données de journal

Les journaux d'accès ALB enregistrent tout le trafic de requêtes HTTP/HTTPS des clients accédant aux services backend via ALB. Reportez-vous à la section Champs de journal de ce document pour vérifier les définitions des données et confirmer si le contenu du journal correspond au trafic métier attendu.