Personnaliser les journaux d'accès du plan de données - Alibaba Cloud Service Mesh

Prérequis

Étape 1 : Activer la journalisation des accès

Pour les instances ASM antérieures à la version 1.17.2.35

Connectez-vous à la console ASM. Dans le volet de navigation de gauche, choisissez Service Mesh > Mesh Management.
Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, choisissez Instance Information > Base Information.
Dans le coin supérieur droit de la page Basic Information, cliquez sur Settings.

Dans le panneau Settings Update, sélectionnez Enable access logging and print it to container stdout et cliquez sur OK.

Par défaut, le conteneur istio-proxy génère des journaux contenant les champs suivants. Si vous désactivez la journalisation des accès, le conteneur istio-proxy ne génère pas de journaux d'accès au format JSON.

Champs de journal par défaut


    "authority_for":"%REQ(:AUTHORITY)%",
    "bytes_received":"%BYTES_RECEIVED%",
    "bytes_sent":"%BYTES_SENT%",
    "downstream_local_address":"%DOWNSTREAM_LOCAL_ADDRESS%",
    "downstream_remote_address":"%DOWNSTREAM_REMOTE_ADDRESS%",
    "duration":"%DURATION%",
    "istio_policy_status":"%DYNAMIC_METADATA(istio.mixer:status)%",
    "method":"%REQ(:METHOD)%",
    "path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
    "protocol":"%PROTOCOL%",
    "request_id":"%REQ(X-REQUEST-ID)%",
    "requested_server_name":"%REQUESTED_SERVER_NAME%",
    "response_code":"%RESPONSE_CODE%",
    "response_flags":"%RESPONSE_FLAGS%",
    "route_name":"%ROUTE_NAME%",
    "start_time":"%START_TIME%",
    "trace_id":"%REQ(X-B3-TRACEID)%",
    "upstream_cluster":"%UPSTREAM_CLUSTER%",
    "upstream_host":"%UPSTREAM_HOST%",
    "upstream_local_address":"%UPSTREAM_LOCAL_ADDRESS%",
    "upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
    "upstream_transport_failure_reason":"%UPSTREAM_TRANSPORT_FAILURE_REASON%",
    "user_agent":"%REQ(USER-AGENT)%",
    "x_forwarded_for":"%REQ(X-FORWARDED-FOR)%"

Pour les instances ASM 1.17.2.35 et versions ultérieures

Connectez-vous à la console ASM. Dans le volet de navigation de gauche, choisissez Service Mesh > Mesh Management.
Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, choisissez Observability Management Center > Observability Settings.
Sur la page Observability Settings, cliquez sur l'onglet Global, Namespace ou Custom selon vos besoins.
- Si vous cliquez sur l'onglet Namespace, cliquez sur Create et sélectionnez un Namespace si nécessaire.
- Si vous cliquez sur l'onglet Custom, cliquez sur Create, sélectionnez un Namespace et saisissez un Name et une Match Label si nécessaire.
Dans la section Log Settings, activez l'interrupteur Enable Log Output et cliquez sur Submit.

Une fois l'interrupteur activé, les sidecars ou les passerelles du plan de données du maillage de services envoient les journaux d'accès vers la sortie standard. ASM prend également en charge le filtrage des journaux. Pour plus d'informations, consultez la rubrique Filter logs.

Consultez les journaux dans la sortie standard du conteneur sidecar du plan de données.

Les exemples suivants montrent comment afficher les journaux d'accès à l'aide de kubectl.

Exécutez la commande suivante pour afficher les journaux du sidecar :

kubectl logs httpbin-5c5944c58c-w**** -c istio-proxy --tail 1

Exemple de sortie

{
    "authority_for":"47.110.XX.XXX",
    "bytes_received":"0",
    "bytes_sent":"22382",
    "downstream_local_address":"192.168.0.29:80",
    "downstream_remote_address":"221.220.XXX.XXX:0",
    "duration":"80",
    "istio_policy_status":"-",
    "method":"GET",
    "path":"/static/favicon.ico",
    "protocol":"HTTP/1.1",
    "request_id":"0f2cf829-3da5-4810-a618-08d9745d****",
    "requested_server_name":"outbound_.8000_._.httpbin.default.svc.cluster.local",
    "response_code":"200",
    "response_flags":"-",
    "route_name":"default",
    "start_time":"2023-06-30T04:00:36.841Z",
    "trace_id":"-",
    "upstream_cluster":"inbound|80||",
    "upstream_host":"192.168.0.29:80",
    "upstream_local_address":"127.0.X.X:55879",
    "upstream_response_time":"79",
    "upstream_service_time":"79",
    "upstream_transport_failure_reason":"-",
    "user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.X.X Safari/537.36",
    "x_forwarded_for":"221.220.XXX.XXX"
}

Exécutez la commande suivante pour afficher les journaux de la passerelle d'entrée :

kubectl -n istio-system logs istio-ingressgateway-6cff9b6b58-r**** --tail 1

Exemple de sortie

{
    "authority_for":"47.110.XX.XXX",
    "bytes_received":"0",
    "bytes_sent":"22382",
    "downstream_local_address":"192.168.0.63:80",
    "downstream_remote_address":"221.220.XXX.XXX:64284",
    "duration":"81",
    "istio_policy_status":"-",
    "method":"GET",
    "path":"/static/favicon.ico",
    "protocol":"HTTP/1.1",
    "request_id":"0f2cf829-3da5-4810-a618-08d9745d****",
    "requested_server_name":"-",
    "response_code":"200",
    "response_flags":"-",
    "route_name":"httpbin",
    "start_time":"2023-06-30T04:00:36.841Z",
    "trace_id":"-",
    "upstream_cluster":"outbound|8000||httpbin.default.svc.cluster.local",
    "upstream_host":"192.168.0.29:80",
    "upstream_local_address":"192.168.0.63:36140",
    "upstream_response_time":"81",
    "upstream_service_time":"81",
    "upstream_transport_failure_reason":"-",
    "user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.X.X Safari/537.36",
    "x_forwarded_for":"221.220.XXX.XXX"
}

(Facultatif) Consultez les journaux d'accès dans la console Container Service for Kubernetes.

Si vous utilisez un cluster Alibaba Cloud Container Service for Kubernetes (ACK), vous pouvez également consulter les journaux d'accès dans la console ACK.
1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Workloads > Pods.
3. Sur la page Pods, cliquez sur le nom du pod cible, puis cliquez sur l'onglet Logs en bas de la page pour afficher les journaux d'accès.

Pour plus d'informations sur les journaux, consultez les rubriques Observability Settings et Enable control plane log collection and log-based alerting (New).

Étape 2 : Personnaliser le contenu des journaux d'accès

Pour les instances ASM antérieures à la version 1.17.2.35

Connectez-vous à la console ASM. Dans le volet de navigation de gauche, choisissez Service Mesh > Mesh Management.
Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, choisissez Instance Information > Base Information.
Dans la section Basic Information de la page Config Info, cliquez sur Enable access logging and print it to container stdout à côté de Update Access Log Format.
Dans la boîte de dialogue Update Access Log Format, ajoutez un format de journal d'accès personnalisé. Définissez la accessLogFormat key sur my_custom_key et la accessLogFormat value sur %REQ(end-user)%, puis cliquez sur Submit.

Cet exemple montre comment obtenir le champ d'en-tête end-user d'une requête HTTP dans l'exemple d'application Bookinfo. Lorsque vous personnalisez le format des journaux d'accès, vous pouvez sélectionner des champs facultatifs fournis par ASM ou ajouter des champs personnalisés. Une fois les champs sélectionnés, les journaux d'accès sont générés dans le format personnalisé. Il n'est pas nécessaire de sélectionner les quatre champs suivants : request_duration (%REQUEST_DURATION%), request_tx_duration (%REQUEST_TX_DURATION%), response_duration (%RESPONSE_DURATION%) et response_tx_duration (%RESPONSE_TX_DURATION%).

Pour les instances ASM 1.17.2.35 et versions ultérieures

Connectez-vous à la console ASM. Dans le volet de navigation de gauche, choisissez Service Mesh > Mesh Management.
Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, choisissez Observability Management Center > Observability Settings.
Sur la page Observability Settings, cliquez sur l'onglet Global, Namespace ou Custom selon vos besoins.
- Si vous cliquez sur l'onglet Namespace, cliquez sur Create et sélectionnez un Namespace si nécessaire.
- Si vous cliquez sur l'onglet Custom, cliquez sur Create, sélectionnez un Namespace et saisissez un Name et une Match Label si nécessaire.
Dans la section Log Settings, sélectionnez des champs, modifiez les informations relatives aux champs cibles ou cliquez sur l'icône située à côté des métriques de journal en bas de la page pour ajouter un champ de journal si nécessaire. Cliquez ensuite sur Submit.

Vous ne pouvez personnaliser le format des journaux qu'après avoir activé l'interrupteur Enable Log Output. Dans la section Log Format, les champs de journal sélectionnés par défaut sont obligatoires et ne peuvent pas être modifiés. Les champs de journal peuvent récupérer des valeurs à partir des en-têtes de requête, des en-têtes de réponse et des valeurs intégrées d'Envoy.

L'exemple suivant montre comment imprimer l'en-tête accept-encoding d'une requête. Définissez la accessLogFormat key sur accept-encoding, le Type sur Request Properties et la accessLogFormat value sur Accept-Encoding. Par exemple, l'expression de format pour le champ d'attribut de requête authority_for est %REQ(:AUTHORITY)%, l'expression de format pour le champ d'attribut de réponse upstream_response_time est %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% et les propriétés intégrées d'Envoy incluent des champs tels que request_duration et response_duration.

Exécutez la commande suivante pour afficher les journaux d'un composant du plan de données du maillage de services :

kubectl logs httpbin-5c5944c58c-w**** -c istio-proxy --tail 1|grep accept-encoding --color=auto

Exemple de sortie

{
    "bytes_received":"0",
    "bytes_sent":"9593",
    "downstream_local_address":"192.168.0.29:80",
    "downstream_remote_address":"69.164.XXX.XX:0",
    "duration":"2",
    "istio_policy_status":"-",
    "method":"GET",
    "path":"/",
    "protocol":"HTTP/1.1",
    "request_id":"29939dc9-62be-4ddf-acf6-32cb098d****",
    "requested_server_name":"outbound_.8000_._.httpbin.default.svc.cluster.local",
    "response_code":"200",
    "response_flags":"-",
    "route_name":"default",
    "start_time":"2023-06-30T04:18:19.734Z",
    "trace_id":"-",
    "upstream_cluster":"inbound|80||",
    "upstream_host":"192.168.0.29:80",
    "upstream_local_address":"127.0.X.X:34723",
    "upstream_service_time":"2",
    "upstream_transport_failure_reason":"-",
    "user_agent":"Mozilla/5.0 zgrab/0.x",
    "x_forwarded_for":"69.164.XXX.XX",
    "authority_for":"47.110.XX.XXX",
    "upstream_response_time":"2",
    "accept-encoding":"gzip"
}

La sortie indique que la valeur de l'en-tête Accept-Encoding ajoutée à l'étape Étape 2 est incluse dans le journal d'accès. Pour plus d'informations sur les journaux, consultez les rubriques Observability Settings et Enable control plane log collection and log-based alerting (New).

Étape 3 : Afficher les journaux d'accès

Après avoir activé la journalisation des accès, le conteneur sidecar émetteur génère des journaux d'accès au format personnalisé spécifié.

Dans la barre d'adresse de votre navigateur, saisissez <Adresse de la passerelle d'entrée>/productpage pour accéder à l'application productpage.
Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Workloads > Deployments.
En haut de la page Deployments, définissez le Namespace sur default. Recherchez ensuite l'application productpage-v1 et cliquez sur Details dans la colonne Actions.

Sur la page des détails de l'application, cliquez sur l'onglet Logs et définissez Container sur istio-proxy.

Le volet de sortie des journaux affiche l'entrée suivante. La présence du champ my_custom_key avec la valeur jason indique que vous avez correctement configuré le contenu personnalisé du journal.

{"method":"GET","x_forwarded_for":null,"upstream_host":"172.19.16.90:9080","protocol":"HTTP/1.1","my_custom_key":"jason","authority_for":"addedvalues:9080","response_code":200,"start_time":"2021-10-21T11:40:12.0552","request_id":"5222b7fb-05a6-4fae-8e13-xxx","bytes_sent":883,"downstream_remote_address":"172.19.16.11:33752","upstream_transport_failure_reason":null,"downstream_local_address":"192.168.237.140:9080","requested_server_name":null,"response_flags":"-","duration":4,"user_agent":"python-requests/2.18.4","route_name":"default","trace_id":null,"istio_policy_status":null,"path":"/addedvalues/0","upstream_cluster":"outbound|9080||addedvalues.default.svc.cluster.local","bytes_received":0,"upstream_service_time":"3","authority":"addedvalues:9080","upstream_local_address":"172.19.16.11:52430"}

Champs des journaux d'accès

Dans Service Mesh ASM, « upstream » (amont) désigne le destinataire d'une requête dans une chaîne d'appels, tandis que « downstream » (aval) désigne l'initiateur de la requête. Par exemple, lorsque le service A envoie une requête au service B, le service A est le « downstream » et le service B est l'« upstream ».

Paramètre	Valeur	Description
authority_for	%REQ(:AUTHORITY)%	Le nom d'hôte de destination dans la requête. Pour une requête HTTP/1,1, cela correspond à la valeur de l'en-tête de requête `Host`. Pour une requête HTTP/2, cela correspond à la valeur de l'en-tête de requête `:authority`.
bytes_received	%BYTES_RECEIVED%	HTTP : Nombre d'octets dans le corps de la requête. TCP : Nombre d'octets reçus depuis la connexion aval.
bytes_sent	%BYTES_SENT%	HTTP : Nombre d'octets envoyés dans le corps de la requête. Pour une connexion WebSocket, cette valeur inclut la longueur de l'en-tête de réponse. TCP : Nombre d'octets envoyés vers la connexion aval.
downstream_local_address	%DOWNSTREAM_LOCAL_ADDRESS%	L'adresse et le port de destination de la connexion aval. Cela peut être considéré comme l'adresse de destination d'origine de la connexion aval.
downstream_remote_address	%DOWNSTREAM_REMOTE_ADDRESS%	L'adresse et le port du client de la connexion aval.
method	%REQ(:METHOD)%	La méthode de requête. Ce champ n'est valide que pour les requêtes HTTP.
path	%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%	Le chemin de la requête.
protocol	%PROTOCOL%	Le protocole de la requête.
request_id	%REQ(X-REQUEST-ID)%	L'identifiant unique de la requête.
requested_server_name	%REQUESTED_SERVER_NAME%	Le nom du serveur spécifié dans la connexion SSL (Server Name Indication).
response_code	%RESPONSE_CODE%	Le code d'état de la réponse HTTP.
response_flags	%RESPONSE_FLAGS%	Informations supplémentaires sur la réponse ou la connexion. Pour plus d'informations sur les valeurs et leur signification, consultez la référence response_flag.
route_name	%ROUTE_NAME%	Le nom de la route correspondante. Ceci est cohérent avec le nom de route défini dans le service virtuel. Une valeur vide (-) indique qu'aucune route n'a été trouvée.
start_time	%START_TIME%	L'heure à laquelle le traitement de la requête a commencé, avec une précision à la milliseconde.
trace_id	%TRACE_ID%	L'identifiant de trace pour le traçage.
upstream_cluster	%UPSTREAM_CLUSTER%	Le service de destination amont et le sous-ensemble.
upstream_host	%UPSTREAM_HOST%	L'hôte de destination amont, généralement l'adresse IP et le port du Pod.
upstream_local_address	%UPSTREAM_LOCAL_ADDRESS%	L'adresse locale utilisée pour établir une connexion avec le service amont.
duration	%DURATION%	Pour une requête HTTP, ce champ indique le temps total écoulé entre le début de la lecture de la requête et l'envoi du dernier octet de la réponse au service aval. Il s'agit du temps total nécessaire à un sidecar ou à une passerelle pour traiter une requête. Pour une requête TCP, ce champ indique la durée totale de la connexion aval.
request_duration	%REQUEST_DURATION%	Pour une requête HTTP, ce champ indique le temps nécessaire pour lire l'intégralité de la requête (en-têtes et corps) depuis le service aval. Si cette durée est longue, vérifiez les points suivants : La qualité du réseau et la bande passante disponible sont-elles suffisantes ? L'application amont ou aval présente-t-elle un goulot d'étranglement sous une charge d'E/S similaire ? Pour une requête TCP, ce champ n'est pas implémenté et s'affiche sous la forme - dans le journal.
request_tx_duration	%REQUEST_TX_DURATION%	Pour une requête HTTP, ce champ indique le temps écoulé entre le début de la requête et l'envoi de son dernier octet au service amont. Si cette durée est longue, vérifiez les points suivants : La qualité du réseau et la bande passante disponible sont-elles suffisantes ? L'application amont ou aval présente-t-elle un goulot d'étranglement sous une charge d'E/S similaire ? Pour une requête TCP, ce champ n'est pas implémenté et s'affiche sous la forme - dans le journal.
response_duration	%RESPONSE_DURATION%	Pour une requête HTTP, ce champ indique le temps écoulé entre le début de la requête et la lecture du premier octet de la réponse depuis le service amont. Si cette durée est longue et que request_tx_duration est courte, vérifiez si l'application amont présente un goulot d'étranglement au niveau des performances. Pour une requête TCP, ce champ n'est pas implémenté et s'affiche sous la forme - dans le journal.
response_tx_duration	%RESPONSE_TX_DURATION%	Pour une requête HTTP, ce champ indique le temps écoulé entre la lecture du premier octet de la réponse du service amont et l'envoi du dernier octet au service aval. Si cette durée est longue, vérifiez les points suivants : La qualité du réseau et la bande passante disponible sont-elles suffisantes ? L'application amont ou aval présente-t-elle un goulot d'étranglement sous une charge d'E/S similaire ? Pour une requête TCP, ce champ n'est pas implémenté et s'affiche sous la forme - dans le journal.
upstream_service_time (sidecar)	%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%	Dans les journaux d'accès d'un sidecar ou d'une passerelle, ce champ indique le temps de traitement du service amont et le temps nécessaire à la communication réseau avec le service amont. Si cette durée est longue, vérifiez si : Les performances de traitement de l'application amont répondent aux attentes. La latence réseau et la bande passante pour la communication avec le service amont répondent aux attentes.
upstream_response_time (passerelle)	%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%

Remarque

Pour les requêtes HTTP avec un corps (Content-Length > 0), Envoy transmet la requête au service amont au fur et à mesure de sa réception, plutôt que d'attendre l'arrivée de l'intégralité de la requête avant de la transférer. Par conséquent, un client aval lent peut augmenter le temps total de requête pour tous les services de la chaîne d'appels amont.

Valeurs des indicateurs de réponse

Le champ response_flag du journal d'accès fournit des informations supplémentaires sur la requête ou la connexion. Le tableau suivant décrit les différentes valeurs de response_flag.

Valeur

Description

UH

Envoy n'a pas pu trouver d'hôte amont sain. Cela est généralement dû à l'absence de point de terminaison disponible pour le service de destination.

UF

Échec de la connexion à l'hôte amont. Cela est généralement dû au fait que l'application amont n'est pas à l'écoute ou que le port est mal configuré.

UO

Débordement amont (disjoncteur).

NR

Envoy n'a pas trouvé de route pour la requête.

NC

Envoy n'a pas pu trouver le service de destination. Cela signifie généralement que le nom d'hôte ou le nom de sous-ensemble dans la règle de routage configurée est incorrect.

URX

La requête a été limitée en débit.

DC

Le client aval s'est déconnecté.

UR

Le service amont a réinitialisé la connexion.

UAEX

Un service d'autorisation externe a rejeté la requête. Cela signifie que le proxy ASM a rejeté la requête sur la base de la réponse du service d'autorisation externe.

DPE

Erreur de protocole aval. Cela indique que la requête envoyée par l'application aval utilise un protocole inattendu. Vérifiez si les noms de port des services de votre cluster sont préfixés par le protocole correct, tel que http-80, http ou grpc.

UPE

Erreur de protocole amont. Cela indique que le proxy ASM a tenté de transférer une requête au service amont en utilisant un protocole inattendu. Vérifiez si les noms de port des services de votre cluster sont préfixés par le protocole correct, tel que http-80, http ou grpc.

Opérations connexes

Vous pouvez également utiliser Log Service (SLS) pour collecter les journaux d'accès du plan de données. Pour plus d'informations, consultez la rubrique Generate and collect ASM gateway access logs.