Alibaba Cloud Service Mesh:ASM observability settings

Sortie des journaux d'accès

1. Dans la section Log Settings, activez ou désactivez l'option Enable Log Output selon vos besoins.

   • Si vous activez cette option, les sidecars ou les passerelles du plan de données envoient les journaux d'accès vers la sortie standard (stdout) du conteneur.

   • Si vous désactivez cette option, les sidecars ou les passerelles du plan de données cessent d'envoyer les journaux vers la sortie standard du conteneur.

2. 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.

   1. 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"
      }

   2. Exécutez la commande suivante pour afficher les journaux de la passerelle ingress :

      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"
      }

3. (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 sur l'onglet Logs en bas de la page pour afficher les journaux d'accès.

Format de sortie des journaux

Dans la section Log Settings, définissez le Log Output Format sur JSON ou TEXT selon vos besoins.

• Si vous sélectionnez JSON, les journaux d'accès sont envoyés vers la sortie standard du conteneur sous forme de chaînes JSON.

• Si vous sélectionnez TEXT, les journaux d'accès sont envoyés vers la sortie standard du conteneur sous forme de texte brut.

Format de journal personnalisé

1. Dans la section Log Settings, sélectionnez des champs, modifiez les informations des champs personnalisés ou cliquez sur l'icône en bas de la liste des champs de journal pour ajouter un nouveau champ.

   Vous ne pouvez personnaliser le format des journaux que si l'option Enable Log Output est activée. Dans la section Log Format, les champs de journal sélectionnés par défaut sont obligatoires et ne peuvent pas être désélectionnés. Les valeurs des champs de journal peuvent être extraites des en-têtes de requête, des en-têtes de réponse ou des valeurs intégrées d'Envoy.

   Par exemple, pour enregistrer l'en-tête de requête accept-encoding, définissez la accessLogFormat key sur accept-encoding, le Type sur Request Properties et la accessLogFormat value sur Accept-Encoding. Le modèle de format pour un en-tête de requête est %REQ(HEADER_NAME)% (par exemple, %REQ(:AUTHORITY)%), pour un en-tête de réponse, il est %RESP(HEADER_NAME)% (par exemple, %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%) et pour un attribut Envoy intégré, il est %ATTRIBUTE_NAME% (par exemple, %REQUEST_DURATION%).

2. Exécutez la commande suivante pour afficher les journaux des composants du plan de données dans le service mesh.

   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"
   }

   Le journal d'accès affiche désormais la valeur de l'en-tête Accept-Encoding que vous avez ajoutée à l'étape 1.

Filtrage des journaux

Sous la section Log Settings, sélectionnez l'option Enable Log Filter pour activer le filtrage des journaux, puis saisissez une expression de filtrage dans la zone de texte. Les journaux d'accès sont générés uniquement pour les requêtes qui correspondent à l'expression.

Par exemple, pour enregistrer uniquement les requêtes qui répondent à la condition Response Http Status >= 400, utilisez l'expression response.code >= 400. Pour plus d'informations, consultez les Expressions CEL et champs courants.

Génération de métriques

Les métriques sont classées en métriques côté client et en métriques côté serveur.

• Métriques côté client : Métriques générées lorsqu'un sidecar agit en tant que client pour initier des requêtes. Les métriques de passerelle sont également classées comme métriques côté client.

• Métriques côté serveur : Métriques générées lorsqu'un sidecar agit en tant que serveur pour recevoir des requêtes.

1. Dans la section Metric Settings, dans la colonne Client-Side Metrics ou Server-Side Metrics, cochez ou décochez la case Enabled d'une métrique selon vos besoins.

   • Si une métrique est activée, le sidecar ou la passerelle du plan de données expose cette métrique via le chemin /stats/prometheus sur le port 15020.

   • Si une métrique est désactivée, elle n'est pas exposée sur le port et le chemin spécifiés.

2. Exécutez la commande suivante pour afficher les métriques exposées par un sidecar ou une passerelle.

   Vous pouvez utiliser kubectl pour exécuter une commande curl à l'intérieur du conteneur sidecar ou de la passerelle afin d'accéder au chemin /stats/prometheus sur le port local 15020 et afficher les métriques exportées.

   kubectl exec httpbin-5c5944c58c-w**** -c istio-proxy -- curl 127.0.0.1:15020/stats/prometheus|head -n 10

   Exemple de sortie :

   # TYPE istio_agent_cert_expiry_seconds gauge
   istio_agent_cert_expiry_seconds{resource_name="default"} 46725.287654548
   # HELP istio_agent_endpoint_no_pod Endpoints without an associated pod.
   # TYPE istio_agent_endpoint_no_pod gauge
   istio_agent_endpoint_no_pod 0
   # HELP istio_agent_go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
   # TYPE istio_agent_go_gc_duration_seconds summary
   istio_agent_go_gc_duration_seconds{quantile="0"} 5.0149e-05
   istio_agent_go_gc_duration_seconds{quantile="0.25"} 9.8807e-05
   ......

Dimensions des métriques

Les dimensions des métriques fournissent des informations contextuelles riches. Vous pouvez utiliser ces dimensions pour filtrer les métriques cibles dans Prometheus. Par exemple, vous pouvez utiliser la dimension source_app pour filtrer les métriques des requêtes provenant d'une application cliente spécifique.

kubectl exec httpbin-5c5944c58c-w**** -c istio-proxy -- curl 127.0.0.1:15020/stats/prometheus

istio_request_bytes_sum{reporter="destination",source_workload="istio-ingressgateway",source_canonical_service="unknown",source_canonical_revision="latest",source_workload_namespace="istio-system",source_principal="spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway",source_app="istio-ingressgateway",source_version="unknown",source_cluster="c479fc4abd2734bfaaa54e9e36fb26c01",destination_workload="httpbin",destination_workload_namespace="default",destination_principal="spiffe://cluster.local/ns/default/sa/httpbin",destination_app="httpbin",destination_version="v1",destination_service="httpbin.default.svc.cluster.local",destination_canonical_service="httpbin",destination_canonical_revision="v1",destination_service_name="httpbin",destination_service_namespace="default",destination_cluster="c479fc4abd2734bfaaa54e9e36fb26c01",request_protocol="http",response_code="200",grpc_response_status="",response_flags="-",connection_security_policy="mutual_tls"} 18000

istio_request_bytes_sum{response_code="200"} 16550

istio_request_bytes_sum{response_code="200",request_path="/spec.json"} 5800

Pourcentage d'échantillonnage

Vous pouvez personnaliser le pourcentage d'échantillonnage pour le tracing, qui détermine le pourcentage de requêtes pour lesquelles des traces sont générées. Une valeur de 0 désactive le tracing.

Balises personnalisées

Vous pouvez personnaliser les balises jointes aux spans de tracing signalées. Dans la section Tracing Analysis Settings, cliquez sur Add Custom Tags, puis configurez le Name, le Type et la Value.

Les types valides incluent Fixed Value, Request Header et Environment Variable. Le tableau suivant décrit chaque type et fournit des exemples.