L'exportation des journaux intègre les passerelles cloud-native MSE au service Simple Log Service (SLS) d'Alibaba Cloud. Cette fonctionnalité vous permet d'analyser les journaux d'accès de la passerelle afin de comprendre le comportement des clients, de cartographier la répartition géographique des utilisateurs et de résoudre les problèmes. Cette rubrique explique comment activer l'exportation des journaux pour une passerelle cloud-native MSE.
Prérequis
Vous avez créé une instance de passerelle cloud-native MSE. Pour plus d'informations, consultez la rubrique Créer une passerelle cloud-native.
Le service Simple Log Service doit être activé. Si ce n'est pas le cas, connectez-vous à la console Simple Log Service avec votre compte Alibaba Cloud pour l'activer. Pour en savoir plus, consultez la rubrique Présentation de Simple Log Service.
La fonctionnalité d'exportation des journaux est gratuite, mais les frais standard du service Simple Log Service (SLS) s'appliquent en fonction de l'utilisation. Pour plus d'informations sur la facturation de SLS, consultez la rubrique paiement à l'utilisation.
Activer l'exportation des journaux
Connectez-vous à la console MSE. Dans la barre de navigation supérieure, sélectionnez une région.
Dans le volet de navigation de gauche, choisissez Cloud-native Gateway > Gateways. Sur la page Gateways, cliquez sur l'ID de la passerelle.
-
Dans le volet de navigation de gauche, cliquez sur Parameter Settings. Dans la section Observability Parameters, cliquez sur l'icône de modification
située à côté de Log Shipping. Dans la boîte de dialogue Log Shipping Settings, activez l'option Enable Log Shipping (Ship Gateway Access Logs to Log Service).RemarqueAprès activation de l'exportation des journaux, Simple Log Service crée un projet SLS par défaut. Vous pouvez également sélectionner un projet SLS existant.
Une fois Tracing Analysis activé, vous pouvez consulter les données de surveillance de la passerelle sur la console Tracing Analysis. Pour plus d'informations, consultez la rubrique Activer Tracing Analysis pour une passerelle.
Une fois l'exportation des journaux activée, cliquez sur le lien situé à côté de Project dans la section Observability Parameters. Cette action vous redirige vers le Logstore de la passerelle. Pour plus d'informations, consultez la rubrique Démarrage rapide pour la requête et l'analyse des journaux.
Dépannage : absence de contenu dans les journaux des plug-ins
Si l'exportation des journaux est activée mais qu'aucun contenu n'apparaît lors de la consultation des journaux des plug-ins, procédez au dépannage dans l'ordre suivant :
Élargissez la plage de temps de la requête : assurez-vous que la fenêtre de temps de la requête couvre la période durant laquelle les requêtes ont eu lieu. L'exportation des journaux vers Simple Log Service (SLS) présente une latence de quelques secondes à quelques minutes ; élargissez donc la fenêtre de temps si nécessaire.
Vérifiez que les requêtes invoquent le plug-in : recherchez les enregistrements de requêtes correspondants dans les journaux d'accès de la passerelle. Si aucun enregistrement de ce type n'existe, les requêtes n'ont jamais atteint le plug-in. Vérifiez la configuration des routes.
Examinez la logique de génération des journaux dans le code du plug-in : vérifiez que les requêtes métier atteignent effectivement les instructions de journalisation. Même lorsque l'exportation des journaux fonctionne correctement, si des branches conditionnelles dans le code du plug-in empêchent les requêtes d'atteindre les instructions de journalisation, les journaux du plug-in restent vides.
Champs d'exportation des journaux
|
Nom du champ |
Type |
Description |
|
__time__ |
long |
L'heure de génération de l'entrée de journal. |
|
cluster_id |
string |
L'ID de l'instance de passerelle. |
|
consumer |
string |
Le consommateur de la requête. Ce champ n'est renseigné que lorsque l'authentification du consommateur est activée. |
|
custom_log |
json |
Stocke les champs de journal définis par l'utilisateur. Cette fonction peut être utilisée avec des plug-ins personnalisés. |
|
authority |
string |
La valeur de l'en-tête Host dans la requête. |
|
bytes_received |
long |
La taille du corps de la requête en octets, hors en-têtes. |
|
bytes_sent |
long |
La taille du corps de la réponse en octets, hors en-têtes. |
|
downstream_local_address |
string |
L'adresse du pod de la passerelle. |
|
downstream_remote_address |
string |
L'adresse du client connecté à la passerelle. |
|
downstream_transport_failure_reason |
string |
La raison de l'échec du transport en aval (downstream). |
|
duration |
long |
Le temps total de traitement de la requête en millisecondes, mesuré depuis le premier octet reçu du client jusqu'au dernier octet envoyé dans la réponse. |
|
method |
string |
La méthode HTTP. |
|
path |
string |
Le chemin d'accès dans la requête HTTP. |
|
protocol |
string |
La version du protocole HTTP. |
|
request_id |
string |
La passerelle génère un ID pour chaque requête et l'inclut dans l'en-tête |
|
requested_server_name |
string |
Le nom du serveur utilisé pour la connexion SSL. |
|
request_duration |
long |
Le temps en millisecondes écoulé entre la réception du premier octet et du dernier octet de la requête en aval (downstream) par la passerelle. |
|
response_code |
long |
Le code d'état de la réponse HTTP. |
|
response_code_details |
string |
Des détails supplémentaires sur le code de réponse. Par exemple, |
|
response_flags |
string |
La raison de l'échec de la réponse. |
|
response_tx_duration |
long |
Le temps en millisecondes écoulé entre la réception du premier octet provenant du service amont (upstream) et l'envoi du dernier octet au client aval (downstream). |
|
route_name |
string |
Le nom de la route. |
|
start_time |
string |
L'heure de début de la requête au format UTC. |
|
trace_id |
string |
L'ID de trace. |
|
upstream_cluster |
string |
Le cluster amont (upstream). |
|
upstream_host |
string |
L'adresse IP du service amont (upstream). |
|
upstream_local_address |
string |
L'adresse locale utilisée pour se connecter au service amont (upstream). |
|
upstream_protocol |
string |
Le protocole utilisé pour interroger le service backend. |
|
upstream_service_time |
long |
Le temps en millisecondes nécessaire au service amont (upstream) pour traiter la requête. Cette durée inclut la latence réseau et le temps de traitement propre au service. |
|
upstream_transport_failure_reason |
string |
La raison de l'échec de la connexion amont (upstream). |
|
user_agent |
string |
L'en-tête User-Agent dans la requête HTTP. |
|
x_forwarded_for |
string |
La valeur de l'en-tête HTTP |
|
ext_authz_status_code |
long |
Le code de réponse du service d'autorisation personnalisé. |
|
ext_authz_duration |
long |
Le temps de réponse du service d'autorisation personnalisé. |
Ajouter des champs personnalisés aux journaux d'accès
Pour enregistrer un champ personnalisé, tel que Referer, dans les journaux d'accès, utilisez la fonctionnalité d'ajustement du format des journaux afin de configurer un format de journal personnalisé.
Sur la page des détails de la passerelle, cliquez sur Parameter Settings dans le volet de navigation de gauche.
Dans la section Observability Parameters, repérez Log Format Adjustment sous Log Shipping.
Cliquez sur Default Format (Click to Customize). Dans la boîte de dialogue qui s'affiche, cliquez sur Add.
Définissez Field Type sur Request Header et saisissez la valeur du champ, par exemple
Referer.Cliquez sur OK pour enregistrer la configuration. Le statut passe à Custom Format (Click to Edit).
Une fois la configuration appliquée, les requêtes incluant l'en-tête de requête Referer sont enregistrées, et le champ request_headers du journal d'accès contient la valeur Referer.
L'ajustement du format des journaux prend en charge les types de champs suivants : en-tête de requête, en-tête de réponse, métadonnées dynamiques de requête et métadonnées dynamiques de réponse.
Response flags
La raison de l'échec d'une requête est principalement déterminée par la valeur de Response_Flag dans les journaux. Les différentes valeurs de Response_Flag sont décrites ci-dessous.
Dans ce contexte, « downstream » (aval) fait référence au client, et « upstream » (amont) au service backend.
UH : Aucun hôte amont (upstream) sain n'est disponible dans le cluster.
UF : Échec de la connexion amont (upstream).
NR : Aucune route configurée ne correspond à la requête. Lorsqu'une requête ne correspond à aucune route (
response_flags=NRetresponse_code_details=route_not_found), leresponse_codeest404, et les champsroute_nameetupstream_clusters'affichent tous deux comme-. La requête est rejetée au niveau de la passerelle et n'atteint jamais le service backend. Par conséquent, l'absence de valeur pourupstream_clusteret pour tous les champsupstream_*est un comportement attendu et n'indique pas un problème de configuration du cluster amont. Pour résoudre ce problème, vérifiez si une route a été configurée pour le chemin de la requête.URX : La requête a été rejetée car la limite de nouvelles tentatives amont (HTTP) ou le nombre maximal de tentatives de connexion (TCP) a été atteint.
NC : Le cluster amont (upstream) est introuvable.
DT : La requête ou la connexion a dépassé
max_connection_durationoumax_downstream_connection_duration.DC : La connexion aval (downstream) a été interrompue.
LH : Le service local a échoué à une requête de contrôle d'intégrité (health check).
UT : Délai d'attente de la requête amont (upstream) dépassé.
LR : La connexion a été réinitialisée localement.
UR : La connexion amont (upstream) a été réinitialisée à distance.
UC : La connexion amont (upstream) a été interrompue.
DI : Le traitement de la requête a été retardé pendant une période spécifiée par l'injection de pannes.
FI : La requête a été abandonnée avec un code de réponse spécifié par l'injection de pannes.
RL : La requête a été limitée localement par le filtre de limitation de débit HTTP, à l'exclusion des réponses 429.
UAEX : La requête a été rejetée par un service d'autorisation externe.
RLSE : La requête a été rejetée en raison d'une erreur dans le service de limitation de débit.
IH : La requête a été rejetée car un en-tête soumis à une vérification stricte contenait une valeur non valide.
SI : Le délai d'inactivité du flux a été atteint.
DPE : Une erreur de protocole HTTP s'est produite dans la requête aval (downstream).
UPE : Une erreur de protocole HTTP s'est produite dans la réponse amont (upstream).
UMSDR : La requête amont (upstream) a atteint sa durée maximale.
OM : Le gestionnaire de surcharge a terminé la requête.
DF : La requête a été interrompue en raison d'un échec de résolution DNS.