Server Load Balancer:journal d'accès

Présentation

Prérequis

• Vous avez créé une instance CLB.

• Vous avez créé un groupe vServer, ajouté des serveurs backend au groupe vServer et déployé des applications sur les serveurs backend.

• Vous avez configuré un écouteur HTTP ou un écouteur HTTPS pour l'instance CLB.

• Vous avez activé Simple Log Service.

Configurer les journaux d'accès

1. Connectez-vous à la console CLB.

2. Dans le volet de navigation de gauche, choisissez Logs > Access Log.

3. Dans la barre de navigation supérieure, sélectionnez la région où l'instance CLB est déployée.

4. Si vous utilisez cette fonctionnalité pour la première fois, cliquez sur Authorize. Sur la page Authorize Access to Cloud Resources, cliquez sur Confirm.

   Remarque

   Cette autorisation n'est nécessaire qu'une seule fois.

   Si vous êtes un utilisateur RAM, le compte Alibaba Cloud principal doit d'abord vous accorder les autorisations requises. Pour plus d'informations, consultez Autoriser un utilisateur RAM à utiliser la fonctionnalité de journal d'accès de CLB.

5. Sur la page Access Log (Layer 7), recherchez l'instance CLB cible et cliquez sur Configure dans la colonne Actions.

6. Dans le panneau Log Settings, définissez le Project et le Logstore, puis cliquez sur OK.

   • Project : Un Project est une unité de gestion des ressources dans SLS utilisée pour l'isolation et le contrôle des ressources. Nous recommandons d'utiliser différents Projects pour différentes applications.

   • Logstore : Un Logstore est l'unité de collecte, de stockage et d'interrogation des données de journal dans SLS. Nous recommandons de créer des Logstores distincts pour différents types de journaux au sein de la même application.

     • Select Logstore : Cette option active par défaut un tableau de bord d'analyse prédéfini pour le Logstore sélectionné. Si un index est déjà configuré pour le Logstore, la configuration d'index existante est écrasée.

   Remarque

   • Assurez-vous que le Project se trouve dans la même région que l'instance CLB et que son nom est globalement unique.

   • Après la configuration, le Project SLS et le Logstore peuvent mettre quelques minutes à apparaître dans la console SLS. Les données de journal ne sont pas perdues pendant cette période. S'ils ne sont pas encore visibles, actualisez la page ultérieurement.

   Une fois la journalisation d'accès configurée pour l'équilibreur de charge, vous pouvez interroger et récupérer les informations de journal en utilisant les champs suivants dans SLS.

   Paramètre	Description
   body_bytes_sent	Taille du corps HTTP envoyé au client, en octets.
   client_ip	Adresse IP du client.
   client_port	Port du client qui a envoyé la requête.
   host	L'hôte est récupéré à partir de la première source disponible dans l'ordre suivant : paramètres de la requête, en-tête Host et adresse IP du serveur backend qui traite la requête.
   http_host	Contenu de l'en-tête Host dans la requête.
   http_referer	En-tête Referer de la requête HTTP.
   http_user_agent	En-tête User-Agent de la requête HTTP.
   http_x_forwarded_for	En-tête X-Forwarded-For de la requête HTTP.
   http_x_real_ip	En-tête X-Real-IP de la requête HTTP.
   read_request_time	Temps que l'équilibreur de charge prend pour lire la requête. Unité : millisecondes.
   request_length	Longueur de la requête, y compris la ligne de départ, l'en-tête HTTP et le corps HTTP.
   request_method	Méthode de la requête.
   request_time	Temps écoulé entre la réception du premier octet d'une requête par l'équilibreur de charge et l'envoi du dernier octet de la réponse. Unité : secondes.
   request_uri	URI de la requête reçue par l'équilibreur de charge.
   scheme	Schéma de la requête. Valeurs valides : http et https.
   server_protocol	Version HTTP de la requête reçue par l'équilibreur de charge, telle que HTTP/1,0 ou HTTP/1,1.
   slb_vport	Port de l'écouteur de l'équilibreur de charge.
   slbid	ID de l'instance de l'équilibreur de charge.
   ssl_cipher	Suite de chiffrement utilisée pour établir la connexion SSL, telle que ECDHE-RSA-AES128-GCM-SHA256.
   ssl_protocol	Protocole utilisé pour établir la connexion SSL, tel que TLSv1.2.
   status	Code d'état dans la réponse de l'équilibreur de charge.
   tcpinfo_rtt	Temps aller-retour (RTT) de la connexion TCP du client. Unité : microsecondes.
   time	Heure à laquelle l'entrée de journal a été enregistrée.
   upstream_addr	Adresse IP et port du serveur backend.
   upstream_response_time	Temps écoulé entre l'établissement d'une connexion à un serveur backend et la fermeture de la connexion après réception d'une réponse. Unité : secondes.
   upstream_status	Code d'état de la réponse que l'équilibreur de charge reçoit du serveur backend.
   vip_addr	Adresse IP virtuelle (VIP).
   write_response_time	Temps que l'équilibreur de charge prend pour écrire une réponse. Unité : millisecondes.

Notes d'utilisation

client_ip et http_x_forwarded_for

Lorsque vous analysez les sources de requêtes dans les journaux d'accès SLS, ces deux champs ont des significations différentes :

• client_ip : L'adresse IP source qui a établi la connexion avec CLB, telle qu'observée par CLB au niveau réseau. S'il n'y a pas de proxy devant le client, il s'agit de la véritable adresse IP du client. Si le client se trouve derrière un proxy, il s'agit de l'adresse IP de sortie du proxy le plus proche.

• http_x_forwarded_for : La valeur d'origine de l'en-tête X-Forwarded-For dans la requête entrante reçue par CLB. Elle est écrite par le client ou un proxy amont, peut être falsifiée et est fournie à titre indicatif uniquement.

Pour analyser les sources de requêtes dans les journaux d'accès, utilisez client_ip.

Identifier quelle règle de transfert a traité une requête

Les journaux d'accès n'enregistrent pas les ID de groupe de serveurs ni les noms des règles de transfert de trafic. Pour déterminer quelle règle de transfert a traité une requête spécifique, corrèle les valeurs request_uri et http_host dans le journal avec les règles de transfert configurées dans la console CLB. Sur cette base, vous pouvez vérifier davantage qu'une règle de transfert fonctionne comme prévu :

• Identifier les règles de transfert inactives : Interrogez le nombre de fois qu'une règle de transfert a été mise en correspondance dans une plage de temps spécifique en combinant slbid, request_uri et une plage de temps. Si le résultat est 0, la règle n'a correspondu à aucune requête pendant cette période. Évaluez s'il convient de la nettoyer en fonction de vos besoins commerciaux.

  slbid: <instance-ID> and request_uri: <forwarding-rule-path> | select count(*) as hit_count

• Vérifier que le transfert correspond aux attentes : Comparez la valeur upstream_addr (l'adresse IP et le port du serveur backend vers lequel la requête a été réellement transférée) dans le journal avec les membres du groupe de serveurs de l'écouteur correspondant dans la console CLB, pour confirmer que les requêtes sont transférées vers les serveurs backend prévus.

Interception de la politique TLS

Les connexions bloquées par une politique de sécurité TLS ne terminent pas la négociation TLS et ne génèrent donc pas d'entrées de journal d'accès. Les journaux d'accès n'enregistrent que les requêtes qui établissent avec succès une connexion avec CLB.

Interroger les journaux d'accès

Une fois la fonctionnalité de journal d'accès configurée, vous pouvez interroger les journaux dans la console SLS.

1. Connectez-vous à la console CLB.

2. Dans le volet de navigation de gauche, choisissez Logs > Access Log.

3. Dans la barre de navigation supérieure, sélectionnez la région où l'instance CLB est déployée.

4. Sur la page Access Log (Layer 7), recherchez l'instance cible et cliquez sur View Logs dans la colonne Actions. Vous êtes redirigé vers la console SLS.

5. Une fois SLS configuré, vous pouvez afficher les entrées de journal pour tout client ayant accédé à l'instance CLB.

6. Saisissez une instruction SQL pour interroger des journaux d'accès spécifiques.

   Par exemple, exécutez l'instruction SQL suivante pour trouver les 20 principaux clients. Les résultats peuvent vous aider à analyser les sources de trafic et à éclairer les décisions commerciales.

   * | select http_user_agent, count(*) as pv group by http_user_agent order by pv desc limit 20

   Par exemple, exécutez l'instruction SQL suivante pour interroger les requêtes d'accès provenant d'une plage d'adresses IP spécifique en filtrant les journaux par adresse IP source et code d'état de réponse.

   * | select * where client_ip like '172.17.%' and status=200

   Filtrage des journaux lorsque plusieurs instances CLB partagent un Logstore

   Si plusieurs instances CLB partagent le même Logstore SLS, les requêtes qui filtrent uniquement par domaine ou par port peuvent renvoyer des résultats incomplets ou trompeurs. Pour restreindre les journaux à une instance CLB et un écouteur spécifiques, combinez les champs slbid (ID d'instance) et slb_vport (port de l'écouteur) dans votre requête.

   Par exemple, pour interroger les erreurs 5xx pour une instance et un port d'écouteur spécifiques, exécutez l'instruction SQL suivante :

   slbid: <instance-ID> and slb_vport: <port> and status: 5*

   Si votre requête ne renvoie aucun résultat, vérifiez les points suivants :

   • La valeur slbid doit correspondre exactement à l'ID d'instance affiché dans la console CLB (pas le nom de l'instance).

   • La valeur slb_vport doit correspondre au numéro de port de l'écouteur (par exemple, 80 ou 443).

   • Élargissez la plage de temps de la requête, car les entrées de journal peuvent être écrites avec un court délai.

   Remarque

   Notez les éléments suivants concernant le comportement d'actualisation des journaux et les entrées avec le même horodatage :

   • Comportement d'actualisation des journaux : Les statistiques d'index de champ dans SLS sont mises à jour en temps réel à mesure que les entrées de journal sont écrites. Il n'y a pas d'intervalle d'actualisation fixe. Si vous modifiez la plage de temps de la requête dans la console, cliquez sur le bouton de requête pour recharger les résultats.

   • Plusieurs entrées avec le même horodatage : Si vous voyez plusieurs entrées de journal partageant la même valeur time, il s'agit d'un comportement attendu indiquant que le client a envoyé plusieurs requêtes dans la même seconde. Il s'agit d'un modèle normal pour les clients à haute fréquence et n'indique pas une erreur système. Si vous déterminez que les requêtes répétées sont anormales, configurez une politique de contrôle d'accès pour restreindre l'adresse IP source.

Analyser les journaux d'accès

Vous pouvez utiliser des tableaux de bord dans SLS pour analyser les journaux d'accès. Les tableaux de bord fournissent des visualisations de données riches et des informations pertinentes.

1. Sur la page SLS, cliquez sur l'icône dans le volet de navigation de gauche, puis cliquez sur Dashboard.

2. Cliquez sur le nom du tableau de bord correspondant aux journaux d'accès de votre instance CLB, tel que slb_layer7_access_center_en, pour afficher le rapport d'analyse.

slbid: <instance-ID> and slb_vport: <port> | select count(*) as total_requests

* | select http_host, sum(request_length) as total_bytes, round(sum(request_length) * 100.0 / sum(sum(request_length)) over(), 2) as traffic_pct group by http_host order by total_bytes desc

* | select upstream_addr, count(*) as request_count, sum(request_length) as total_bytes group by upstream_addr order by request_count desc limit 20

Identifier les requêtes anormales

Les journaux d'accès CLB enregistrent toutes les requêtes externes qui transitent par l'instance de l'équilibreur de charge. Si vous trouvez des requêtes provenant de sources inconnues dans les journaux, vous pouvez utiliser les champs clés suivants pour déterminer s'il s'agit de requêtes externes anormales et prendre les mesures de protection appropriées.

* | select client_ip, request_method, request_uri, count(*) as cnt group by client_ip, request_method, request_uri order by cnt desc limit 50

Désactiver les journaux d'accès

Vous pouvez désactiver la fonctionnalité de journal d'accès pour arrêter la collecte des journaux d'accès CLB.

1. Connectez-vous à la console CLB.

2. Dans le volet de navigation de gauche, choisissez Logs > Access Log.

3. Dans la barre de navigation supérieure, sélectionnez la région où l'instance CLB est déployée.

4. Sur la page Access Log (Layer 7), recherchez l'instance cible, puis cliquez sur Disable Logging dans la colonne Actions.

5. Dans la boîte de dialogue qui s'affiche, cliquez sur OK pour désactiver la journalisation d'accès pour l'instance.

Documents connexes

• Pour en savoir plus sur Simple Log Service, consultez Qu'est-ce que Simple Log Service ?.

• Si vous soupçonnez qu'un serveur backend est défaillant lors de l'utilisation de l'équilibrage de charge de couche 7, consultez Utiliser les journaux d'accès CLB pour localiser rapidement un serveur backend défaillant.

FAQ