Cloud Trace et Cloud Service Mesh

Cloud Trace est un système de traçage distribué qui recueille les données de latence des applications et les affiche en quasi-temps réel. Il vous permet de suivre un échantillon de requêtes à travers votre système distribué, d'observer les appels réseau et de profiler votre système de bout en bout.

Cloud Trace est disponible avec les installations Cloud Service Mesh sur les plates-formes suivantes :

• GKE sur Google Cloud
• Clusters GKE Enterprise sur site si vous avez installé Autorité de certification Cloud Service Mesh

Notez que Cloud Trace est désactivé par défaut. Une fois activé, Cloud Service Mesh de la console Google Cloud fournissent un lien vers les traces dans le Cloud Trace . Pour en savoir plus sur la tarification, consultez la page des tarifs de Cloud Trace.

Activer Cloud Trace

Cette section explique comment activer Cloud Trace.

Géré

Cette section explique comment activer Cloud Trace sur Cloud Service Mesh géré.

Avertissement : Vous pouvez écraser vos propres modifications. Si vous disposez déjà d'un mappage de configuration, vous devez inclure tous les paramètres de personnalisation précédents dans la section mesh: pour conserver vos modifications.

1. Exécutez la commande suivante :

   cat <<EOF | kubectl apply -f -
   apiVersion: v1
   data:
      mesh: |-
         defaultConfig:
           tracing:
             stackdriver: {}
   kind: ConfigMap
   metadata:
      name: istio-release-channel
      namespace: istio-system
   EOF
   

   où release-channel est votre version disponible (asm-managed, asm-managed-stable ou asm-managed-rapid).

2. Exécutez la commande suivante pour afficher le ConfigMap :

   kubectl get configmap istio-release-channel -n istio-system -o yaml
   

3. Pour vérifier que Cloud Trace est bien activé, assurez-vous que les lignes suivantes apparaissent dans la section mesh:.

   ...
   apiVersion: v1
   data:
      mesh: |
      ....
      defaultConfig:
         tracing:
            stackdriver:{}
   ...
   

4. Redémarrez les proxys.

   Notez qu'à l'heure actuelle, la configuration du traceur fait partie de la configuration d'amorçage du proxy. Par conséquent, chaque pod doit redémarrer et être réinjecté pour récupérer la mise à jour du traceur. Par exemple, vous pouvez utiliser la commande suivante pour redémarrer les pods appartenant à un déploiement :

   kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Dans le cluster

Cette section explique comment activer Cloud Trace sur Cloud Service Mesh dans le cluster.

Pour activer Cloud Trace, redéployez le plan de contrôle géré par le client à l'aide de le fichier de superposition suivant. Pour plus d'informations sur les fichiers de superposition, consultez À propos des fichiers de superposition

Attention : L'utilisation de asmcli install écrase la configuration existante du plan de contrôle. Lorsque vous activez les fonctionnalités facultatives pour une installation existante, veillez à spécifier tous les fichiers que vous souhaitez conserver dans la configuration d'origine, ainsi que les fichiers de superposition pour les fonctionnalités que vous souhaitez activer. Nous vous recommandons de stocker les fichiers de superposition que vous utilisez pour l'installation dans le dépôt source afin de pouvoir appliquer les mêmes configurations à votre plan de contrôle avec des mises à niveau ou lors de l'activation de fonctionnalités facultatives supplémentaires.

Par défaut

Exécutez la commande suivante pour activer Cloud Trace :

 ./asmcli install \
    OTHER_FLAGS \
    --option cloud-trace

Cette commande applique le fichier de superposition suivant pour activer le traçage avec les options par défaut. Notez que le taux d'échantillonnage par défaut est de 1 %. Si vous souhaitez remplacer la valeur par défaut, vous devez utiliser --custom-overlay.

 apiVersion: install.istio.io/v1alpha1
 kind: IstioOperator
 spec:
 meshConfig:
    enableTracing: true
 values:
    global:
       proxy:
         tracer: stackdriver

Pour obtenir la liste des options, consultez le package anthos-service-mesh.

Personnalisé

Vous pouvez remplacer la valeur par défaut en spécifiant une valeur tracing.sampling. La doit être comprise entre 0,0 et 100,0 avec une précision de 0,01. Par exemple, pour tracer cinq requêtes sur 10 000, spécifiez 0,05.

L'exemple suivant montre un taux d'échantillonnage de 100 % (ce qui n'est destiné qu'à des fins de démonstration ou de dépannage).

 apiVersion: install.istio.io/v1alpha1
 kind: IstioOperator
 spec:
 meshConfig:
    enableTracing: true
    defaultConfig:
       tracing:
       sampling: 100
 values:
    global:
       proxy:
         tracer: stackdriver

Exécutez la commande suivante pour activer Cloud Trace :

 ./asmcli install \
    OTHER_FLAGS \
    --custom_overlay PATH_TO_FILE

Notez que la configuration du traceur fait partie de la configuration d'amorçage du proxy, Les pods doivent donc redémarrer et être réinjectés pour récupérer la mise à jour du traceur. Utilisez la commande suivante pour redémarrer les pods appartenant à un déploiement :

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Propagation du contexte de trace

Même si les proxys side-car peuvent envoyer automatiquement des délais de trace, ils ont besoin d'indications pour relier l'intégralité de la trace. Les applications doivent propager les en-têtes HTTP appropriés de sorte que, lorsque les proxys envoient des informations de délais, ceux-ci soient correctement corrélés en une seule trace.

Pour ce faire, une application doit collecter et propager les en-têtes appropriés de la requête entrante vers les requêtes sortantes : La configuration de traçage Stackdriver de Cloud Service Mesh accepte l'un des formats d'en-tête suivants et propage tous les formats suivants :

• B3 (x-b3-traceid, x-b3-spanid, x-b3parentspanid, x-b3-sampled, x-b3-flags)
• W3C TraceContext (traceparent)
• Google Cloud Trace (x-cloud-trace-context)
• gRPC TraceBin (grpc-trace-bin)

Cela signifie que vos applications peuvent utiliser n'importe lequel de ces formats pour propager le contexte de traçage, et les traces sont générées et définies de manière appropriée sur Stackdriver.

Exemple

Voici un exemple de requête HTTP-Get avec un en-tête traceparent dans la requête d'origine. Notez les en-têtes de contexte de trace supplémentaires ajoutés par le proxy.

$ kubectl exec -it sleep-557747455f-n6flv -- curl "httpbin:8000/anything?freeform=" -H "accept: application/json" -H "Traceparent: 00-7543d15e09e5d61801d4f74cde1269b8-604ef051d35c5b3f-01" -vv
*   Trying 10.12.3.52:8000...
* Connected to httpbin (10.12.3.52) port 8000 (#0)
> GET /anything?freeform= HTTP/1.1
> Host: httpbin:8000
> User-Agent: curl/7.80.0-DEV
> accept: application/json
> Traceparent: 00-7543d15e09e5d61801d4f74cde1269b8-604ef051d35c5b3f-01
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< server: envoy
< date: Wed, 10 Nov 2021 20:36:04 GMT
< content-type: application/json
< content-length: 1032
< access-control-allow-origin: *
< access-control-allow-credentials: true
< x-envoy-upstream-service-time: 5
<
{
  "args": {
    "freeform": ""
  },
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Accept": "application/json",
    "Grpc-Trace-Bin": "AAB1Q9FeCeXWGAHU90zeEmm4AaDHmGRtdM7wAgE",
    "Host": "httpbin:8000",
    "Traceparent": "00-7543d15e09e5d61801d4f74cde1269b8-a0c798646d74cef0-01",
    "User-Agent": "curl/7.80.0-DEV",
    "X-B3-Sampled": "1",
    "X-B3-Spanid": "a0c798646d74cef0",
    "X-B3-Traceid": "7543d15e09e5d61801d4f74cde1269b8",
    "X-Cloud-Trace-Context": "7543d15e09e5d61801d4f74cde1269b8/11585396123534413552;o=1",
    "X-Envoy-Attempt-Count": "1",
    "X-Forwarded-Client-Cert": "<REDACTED>"
  },
  "json": null,
  "method": "GET",
  "origin": "127.0.0.6",
  "url": "http://httpbin:8000/anything?freeform="
}

Notez que dans l'ensemble d'en-têtes de requête renvoyé, l'ensemble complet des données en-têtes de contexte sont présents.

Pour obtenir davantage d'exemples de propagation des en-têtes, consultez la page Propagation du contexte de trace.

Créer une trace à partir d'un client avec un ID personnalisé

Pour créer une trace à partir d'un client avec un ID personnalisé, utilisez la commande curl pour créer une requête avec un client externe et l'obliger à afficher une trace. Exemple :

curl $URL --header "x-client-trace-id: 105445aa7843bc8bf206b12000100000"

Pour plus d'informations sur x-client-trace-id, reportez-vous à la documentation d'Envoy.

Remarque : Si vous testez les conteneurs side-car de Cloud Service Mesh qui envoient des données Cloud Trace à l'aide de la démonstration microservices-demo de Google, veillez à désactiver la fonctionnalité intégrée Cloud Trace. La démonstration microservices-demo est capable d'envoyer des données Cloud Trace sans Istio. Si vous ne désactivez pas cette fonctionnalité, des traces en double sont créées, car le conteneur d'application et le conteneur side-car envoient tous deux des traces. Vous devez configurer plusieurs variables DISABLE_TRACING dans le fichier de release microservices-demo.

Accéder aux traces

Afficher des exemples de traces pour un service

Pour afficher un échantillon de traces d'un service dans votre application, procédez comme suit :

1. Accédez à la page Cloud Service Mesh dans la console Google Cloud.

   Accéder à la page "Cloud Service Mesh"

2. Sous Services, sélectionnez le nom du service que vous souhaitez inspecter.

   La capture d'écran suivante montre un exemple de service frontend.

   

3. Sous Demander des traces, cliquez sur une trace pour afficher plus d'informations.

   La capture d'écran suivante montre un exemple du sous-panneau de la requête de suivi.

   

Afficher toutes les traces

Pour afficher toutes les traces d'un service, procédez comme suit :

1. Accédez à la page Cloud Service Mesh dans la console Google Cloud.

   Accéder à la page Cloud Service Mesh

2. Sous Services, sélectionnez le nom du service que vous souhaitez inspecter.

3. Accédez à la page Métriques.

4. Spécifiez une période dans le menu déroulant Période ou définissez une période personnalisée avec la chronologie.

5. Cliquez sur Afficher les traces.

Les traces d'un service dans Cloud Service Mesh contiennent les informations suivantes :

• Latences des requêtes dans différents services du maillage.
• Propriétés des requêtes HTTP, y compris l'ID, l'URL, la taille, la latence et le protocole.
• Nom du service, espace de noms et ID de maillage associés aux libellés istio.canonical_service, istio.namespace et istio.mesh_id, respectivement.

Étape suivante

• Afficher les traces dans la console Google Cloud