GSP484

Présentation

Quand on assure la gestion d'un système de production qui traite des requêtes HTTP ou fournit une API, il est important de mesurer le temps de latence des points de terminaison. En effet, cela permet de détecter les cas où les performances d'un système ne sont pas conformes aux spécifications. Dans les systèmes monolithiques, cette mesure de la latence peut servir à détecter et à diagnostiquer une dégradation du comportement. Toutefois, cette opération s'avère beaucoup plus difficile pour les architectures de microservices modernes, car une même requête peut impliquer l'envoi de requêtes supplémentaires à de nombreux autres systèmes avant qu'elle puisse être entièrement traitée.

La dégradation des performances d'un système sous-jacent peut avoir une incidence sur tous les autres systèmes qui en dépendent. Bien que la latence puisse être mesurée au niveau de chaque point de terminaison de service, il peut être difficile d'établir un lien entre la lenteur d'un point de terminaison public et un sous-service particulier qui a des problèmes.

C'est ici que le traçage distribué entre en jeu. Il utilise les métadonnées transmises avec les requêtes pour établir des liens entre ces requêtes sur différents niveaux de service. En collectant les données de télémétrie de tous les services dans une architecture de microservices et en propageant un ID de trace depuis une requête initiale vers toutes les requêtes subsidiaires, les développeurs peuvent identifier beaucoup plus facilement le service à l'origine des ralentissements affectant le reste du système.

La suite de produits Operations de Google Cloud permet de gérer la journalisation, la surveillance et le traçage distribué. Cet atelier sera déployé sur Kubernetes Engine et présentera une architecture à plusieurs niveaux sur laquelle le traçage distribué sera implémenté. Il s'appuiera également sur Terraform pour la mise en place de l'infrastructure nécessaire.

Cet atelier a été conçu par les ingénieurs de GKE Helmsman pour vous aider à mieux comprendre le fonctionnement de l'autorisation binaire dans GKE. Pour regarder cette démonstration, exécutez les commandes gsutil cp -r gs://spls/gke-binary-auth/* . et cd gke-binary-auth-demo dans Cloud Shell. Nous invitons chacun d'entre vous à enrichir nos ressources !

Préparation

Avant de cliquer sur le bouton "Démarrer l'atelier"

Lisez ces instructions. Les ateliers sont minutés, et vous ne pouvez pas les mettre en pause. Le minuteur, qui démarre lorsque vous cliquez sur Démarrer l'atelier, indique combien de temps les ressources Google Cloud resteront accessibles.

Cet atelier pratique vous permet de suivre vous-même les activités dans un véritable environnement cloud, et non dans un environnement de simulation ou de démonstration. Nous vous fournissons des identifiants temporaires pour vous connecter à Google Cloud le temps de l'atelier.

Pour réaliser cet atelier :

• vous devez avoir accès à un navigateur Internet standard (nous vous recommandons d'utiliser Chrome) ;

Remarque : Ouvrez une fenêtre de navigateur en mode incognito/navigation privée pour effectuer cet atelier. Vous éviterez ainsi les conflits entre votre compte personnel et le temporaire étudiant, qui pourraient entraîner des frais supplémentaires facturés sur votre compte personnel.

• vous disposez d'un temps limité ; une fois l'atelier commencé, vous ne pouvez pas le mettre en pause.

Remarque : Si vous possédez déjà votre propre compte ou projet Google Cloud, veillez à ne pas l'utiliser pour réaliser cet atelier afin d'éviter que des frais supplémentaires ne vous soient facturés.

Démarrer l'atelier et se connecter à la console Google Cloud

1. Cliquez sur le bouton Démarrer l'atelier. Si l'atelier est payant, un pop-up s'affiche pour vous permettre de sélectionner un mode de paiement. Sur la gauche, vous trouverez le panneau Détails concernant l'atelier, qui contient les éléments suivants :

   • Le bouton Ouvrir la console Google
   • Le temps restant
   • Les identifiants temporaires que vous devez utiliser pour cet atelier
   • Des informations complémentaires vous permettant d'effectuer l'atelier

2. Cliquez sur Ouvrir la console Google. L'atelier lance les ressources, puis ouvre la page Se connecter dans un nouvel onglet.

   Conseil : Réorganisez les onglets dans des fenêtres distinctes, placées côte à côte.

   Remarque : Si la boîte de dialogue Sélectionner un compte s'affiche, cliquez sur Utiliser un autre compte.

3. Si nécessaire, copiez le nom d'utilisateur inclus dans le panneau Détails concernant l'atelier et collez-le dans la boîte de dialogue Se connecter. Cliquez sur Suivant.

4. Copiez le mot de passe inclus dans le panneau Détails concernant l'atelier et collez-le dans la boîte de dialogue de bienvenue. Cliquez sur Suivant.

   Important : Vous devez utiliser les identifiants fournis dans le panneau de gauche. Ne saisissez pas vos identifiants Google Cloud Skills Boost. Remarque : Si vous utilisez votre propre compte Google Cloud pour cet atelier, des frais supplémentaires peuvent vous être facturés.

5. Accédez aux pages suivantes :

   • Acceptez les conditions d'utilisation.
   • N'ajoutez pas d'options de récupération ni d'authentification à deux facteurs (ce compte est temporaire).
   • Ne vous inscrivez pas aux essais offerts.

Après quelques instants, la console Cloud s'ouvre dans cet onglet.

Remarque : Vous pouvez afficher le menu qui contient la liste des produits et services Google Cloud en cliquant sur le menu de navigation en haut à gauche.

Activer Cloud Shell

Cloud Shell est une machine virtuelle qui contient de nombreux outils pour les développeurs. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud. Cloud Shell vous permet d'accéder via une ligne de commande à vos ressources Google Cloud.

1. Cliquez sur Activer Cloud Shell  en haut de la console Google Cloud.

Une fois connecté, vous êtes en principe authentifié et le projet est défini sur votre ID_PROJET. Le résultat contient une ligne qui déclare YOUR_PROJECT_ID (VOTRE_ID_PROJET) pour cette session :

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud est l'outil de ligne de commande pour Google Cloud. Il est préinstallé sur Cloud Shell et permet la complétion par tabulation.

2. (Facultatif) Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :

gcloud auth list

3. Cliquez sur Autoriser.

4. Vous devez à présent obtenir le résultat suivant :

Résultat :

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (Facultatif) Vous pouvez lister les ID de projet à l'aide de cette commande :

gcloud config list project

Résultat :

[core] project = <ID_Projet>

Exemple de résultat :

[core] project = qwiklabs-gcp-44776a13dea667a6 Remarque : Pour consulter la documentation complète sur gcloud, dans Google Cloud, accédez au guide de présentation de la gcloud CLI.

Cloner la démonstration

1. Clonez les ressources nécessaires pour la réalisation de cet atelier en exécutant la commande suivante :

git clone https://github.com/GoogleCloudPlatform/gke-tracing-demo

2. Accédez au répertoire de la démonstration :

cd gke-tracing-demo

Définir votre région et votre zone

Certaines ressources Compute Engine sont hébergées dans des régions et des zones. Une région est un emplacement géographique spécifique où vous pouvez exécuter vos ressources. Chaque région se compose d'une ou plusieurs zones.

Pour en savoir plus et accéder à une liste complète des régions et zones disponibles, accédez à l'article Régions et zones.

Exécutez la commande suivante pour définir la région et la zone associées à votre atelier (vous pouvez utiliser la région/zone qui vous convient le mieux) :

gcloud config set compute/region {{{ project_0.default_region | REGION }}} gcloud config set compute/zone {{{ project_0.default_zone | ZONE }}}

Architecture

Cet atelier commence par le déploiement d'un cluster Kubernetes Engine. Une application Web simple placée derrière un équilibreur de charge sera déployée sur ce cluster. Elle publiera les messages fournis par l'utilisateur dans un sujet Cloud Pub/Sub. L'instrumentation de l'application fait que les requêtes HTTP qui lui sont adressées entraînent la création d'une trace dont le contexte sera propagé à la requête API de publication Cloud Pub/Sub. Les données de télémétrie corrélées issues de ces requêtes seront disponibles dans la console Cloud Trace.

Introduction à Terraform

Comme Terraform applique les principes de l'Infrastructure as Code et de l'infrastructure immuable, il permet d'écrire des descriptions déclaratives de l'état souhaité de l'infrastructure. Lorsque le descripteur est appliqué, Terraform utilise les API Google Cloud pour provisionner et mettre à jour les ressources à mettre en correspondance. Il compare l'état souhaité à l'état actuel, ce qui permet d'apporter des modifications incrémentielles sans avoir besoin de tout effacer et recommencer à zéro. Par exemple, Terraform est capable de créer des projets Google Cloud, des instances de calcul, etc., et même de configurer un cluster Kubernetes Engine pour y déployer des applications. Lorsque les exigences changent, le descripteur peut être mis à jour. Terraform ajuste alors l'infrastructure cloud en conséquence.

Dans cet exemple, nous allons commencer par créer un cluster Kubernetes Engine à l'aide de Terraform. Vous utiliserez ensuite les commandes Kubernetes pour déployer une application de démonstration sur le cluster. Par défaut, les clusters Kubernetes Engine de Google Cloud sont lancés avec un collecteur préconfiguré basé sur Fluentd qui transfère les événements de journalisation du cluster à Cloud Monitoring. Vos interactions avec l'application de démonstration engendreront des événements de trace visibles dans l'UI de Cloud Trace.

Exécuter Terraform

Dans le cadre de cette démonstration, trois fichiers Terraform vous sont fournis. Ils se situent dans le sous-répertoire /terraform du projet. Le premier, main.tf, est le point de départ de Terraform. Il décrit les fonctionnalités qui seront utilisées, les ressources qui seront manipulées et les résultats qui en découleront. Le deuxième fichier, provider.tf, spécifie le fournisseur de services cloud et la version de cloud qui seront la cible des commandes Terraform (dans le cas présent, Google Cloud). Le dernier fichier, variables.tf, contient une liste de variables qui seront utilisées comme entrées dans Terraform. Pour toutes les variables référencées dans le fichier main.tf dont les valeurs par défaut ne sont pas configurées dans variables.tf, l'utilisateur verra s'afficher des invites au moment de l'exécution.

Tâche 1 : Initialisation

L'authentification ayant été configurée précédemment, vous voici prêt à déployer l'infrastructure.

• Exécutez la commande suivante à partir du répertoire racine du projet :

cd terraform

Mettre à jour le fichier provider.tf

Supprimez la version de fournisseur Terraform du fichier de script provider.tf.

1. Modifiez le fichier de script provider.tf :

nano provider.tf

2. Si le fichier contient une chaîne de version statique pour le fournisseur google comme dans l'exemple ci-dessous, supprimez-la :

.... provider "google" { project = var.project version = "~> 2.10.0" }

3. Enregistrez ensuite le fichier : Ctrl+X > Y > Entrée.

Après modification, votre fichier de script provider.tf doit se présenter comme suit :

... provider "google" { project = var.project }

Vous pouvez alors initialiser Terraform :

4. Saisissez cette commande :

terraform init

Cette commande permet de télécharger les dépendances dont Terraform a besoin : le projet et la zone Google Cloud dans lesquels l'application de démonstration doit être déployée. Terraform demandera ces valeurs par le biais d'une requête s'il ne les connaît pas déjà. Par défaut, il recherchera dans le répertoire actuel un fichier appelé terraform.tfvars ou des fichiers avec le suffixe .auto.tfvars afin d'obtenir ces valeurs.

Par souci de commodité, cette démonstration fournit un script qui invite à indiquer le projet et la zone, et les conserve dans un fichier terraform.tfvars.

5. Exécutez la commande suivante :

../scripts/generate-tfvars.sh Remarque : Si le fichier existe déjà, un message d'erreur vous est renvoyé.

Le script utilise les valeurs configurées précédemment à partir de la commande gcloud. Si elles n'ont pas été configurées, le message d'erreur vous indiquera de quelle manière procéder. Les valeurs existantes peuvent être visualisées à l'aide de la commande suivante :

gcloud config list

6. Si les valeurs affichées ne correspondent pas à l'emplacement où vous souhaitez exécuter l'application de démonstration, remplacez les valeurs dans terraform.tfvars par celles de votre choix.

Tâche 2 : Déploiement

1. Une fois Terraform initialisé, vous pouvez voir les tâches qu'il réalisera grâce à la commande suivante :

terraform plan

Cette commande peut être utilisée pour vérifier visuellement que les paramètres sont corrects. Si Terraform détecte des erreurs, il vous en informe. Bien que cela ne soit pas obligatoire, il peut être utile de l'exécuter avant d'apporter une quelconque modification à l'infrastructure à l'aide de Terraform.

2. Après la vérification, demandez à Terraform de configurer l'infrastructure nécessaire à l'aide de la commande suivante :

terraform apply

Les modifications à apporter sont alors affichées et il vous est demandé de les confirmer avec yes (oui).

Remarque : Si vous voyez s'afficher des avertissements indiquant un abandon pour la variable "zone", veuillez les ignorer et poursuivre l'atelier.

En attendant que la compilation se termine, configurez un espace de travail Cloud Monitoring que vous utiliserez plus tard dans l'atelier.

Tester la tâche terminée

Cliquez sur Vérifier ma progression pour valider la tâche exécutée. Si vous avez réussi à déployer l'infrastructure nécessaire avec Terraform, vous recevez une note d'évaluation.

Configurer l'infrastructure nécessaire à l'aide de Terraform

Créer un champ d'application des métriques Monitoring

Définissez un champ d'application des métriques Monitoring associé à votre projet Google Cloud. Suivez les étapes ci-dessous pour créer un compte incluant un essai gratuit de Monitoring.

• Dans la console Cloud, cliquez sur le Menu de navigation () > Monitoring.

Lorsque la page Aperçu de Monitoring s'affiche, votre projet de champ d'application des métriques est prêt.

Tâche 3 : Déployer l'application de démonstration

1. Retournez dans Cloud Shell. Lorsque le message Apply complete! s'affiche, revenez à la console.

2. Dans le menu de navigation, accédez à Kubernetes Engine > Clusters pour visualiser votre cluster.

3. Cliquez sur le menu de navigation, puis faites-le défiler jusqu'à la section "Analyse". Cliquez sur Pub/Sub pour afficher le Sujet et l'Abonnement.

4. Maintenant, déployez l'application de démonstration à l'aide de la commande kubectl de Kubernetes :

kubectl apply -f tracing-demo-deployment.yaml

Une fois l'application déployée, vous pouvez la visualiser dans Kubernetes Engine > Charges de travail. Vous pouvez également voir l'équilibreur de charge créé pour l'application dans la section Services et entrées de la console.

Le déploiement de l'application peut prendre quelques minutes. Si vos charges de travail se présentent de la façon suivante dans la console, avec pour état "Does not have minimum availability" (Disponibilité minimale non présente) :

5. Actualisez la page jusqu'à ce que "OK" s'affiche dans la barre d'état :

À titre d'information, le point de terminaison peut être acquis de manière automatisée à l'aide de la commande suivante :

echo http://$(kubectl get svc tracing-demo -n default -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

Tester la tâche terminée

Cliquez sur Vérifier ma progression pour valider la tâche exécutée. Si l'application de démonstration a bien été déployée, vous recevrez une note d'évaluation.

Déployer l'application de démonstration

Tâche 4 : Validation

Générer des données de télémétrie

Une fois l'application de démonstration déployée, une liste de vos services exposés doit s'afficher.

1. Dans la fenêtre Kubernetes, cliquez sur Services et entrées pour afficher les services exposés.

2. Cliquez sur le point de terminaison figurant à côté de l'équilibreur de charge tracing-demo pour ouvrir la page Web de l'application de démonstration dans un nouvel onglet du navigateur.

Notez que votre adresse IP sera probablement différente de celle présente dans l'exemple ci-dessus. La page affichée est très simple :

3. Ajoutez la chaîne ?string=CustomMessage à l'URL. Vous pouvez constater que le message suivant s'affiche désormais :

Comme vous pouvez vous en apercevoir, si aucun paramètre string n'est fourni, la valeur utilisée par défaut est Hello World. L'application est utilisée pour générer des données de télémétrie de trace.

4. Remplacez "CustomMessage" par vos propres messages afin de générer des données à consulter.

Tester la tâche terminée

Cliquez sur Vérifier ma progression pour valider la tâche exécutée. Si vous avez correctement généré des données de télémétrie, vous recevez une note d'évaluation.

Générer des données de télémétrie

Examiner les traces

1. Dans la console, accédez au menu de navigation > Trace > Explorateur Trace. Un graphique représentant les événements de trace sur une chronologie devrait s'afficher. L'axe vertical correspond aux métriques de latence.

2. Cliquez sur le bouton d'activation Actualisation automatique pour afficher les données les plus récentes.

Remarque : Passez le pointeur sur les points pour développer la vue.

3. Cliquez sur l'un des points du graphique. Vous verrez s'afficher un graphique comportant deux barres, celle du haut étant plus longue que celle du bas.

La barre supérieure est appelée root span (délai racine). Elle représente la durée de la requête HTTP, de l'arrivée du premier octet jusqu'au moment où le dernier octet de la réponse est renvoyé. La barre du bas représente la durée de la requête réalisée lors de l'envoi du message au sujet Pub/Sub.

Le traitement de la requête HTTP étant bloqué par l'appel de l'API Pub/Sub, il devient évident que la grande majorité du temps passé à réaliser la requête HTTP est occupée par l'interaction Pub/Sub. Cela démontre qu'en instrumentant chaque niveau de votre application, vous pouvez facilement repérer où se trouvent les goulots d'étranglement.

Récupérer les messages Pub/Sub

Comme nous l'avons vu dans la section Architecture de ce document, les messages de l'application de démonstration sont publiés dans un sujet Pub/Sub.

Ces messages peuvent être consommés à partir du sujet à l'aide de la gcloud CLI :

gcloud pubsub subscriptions pull --auto-ack --limit 10 tracing-demo-cli

Résultat :

DATA: Hello World MESSAGE_ID: 4117341758575424 ORDERING_KEY: ATTRIBUTES: DELIVERY_ATTEMPT: DATA: CustomMessage MESSAGE_ID: 4117243358956897 ORDERING_KEY: ATTRIBUTES: DELIVERY_ATTEMPT:

L'extraction des messages du sujet n'a aucun impact sur le traçage. Cette section a simplement pour but de fournir un consommateur de messages utilisable à des fins de vérification.

Surveillance et journalisation

Bien que Cloud Monitoring et Logging ne soient pas le sujet de cette démonstration, il est intéressant de noter que l'application que vous avez déployée va publier des journaux dans Cloud Logging et des métriques dans Cloud Monitoring.

1. Dans la console, accédez au menu de navigation > Surveillance > Explorateur de métriques.

2. Dans le champ "Sélectionner une métrique", sélectionnez Instance de VM > Instance > Usage du processeur, puis cliquez sur Appliquer.

Un graphique correspondant à cette métrique, représentant différents pods s'exécutant dans le cluster, devrait s'afficher.

3. Pour afficher les journaux, accédez au menu de navigation > Journalisation.

4. Dans la section Champs de journal, définissez les paramètres suivants :

• TYPE DE RESSOURCE : Conteneur Kubernetes
• NOM DU CLUSTER : tracing-demo-space
• NOM DE L'ESPACE DE NOMS : default

Tâche 5 : Dépannage dans votre environnement

Vous pouvez diagnostiquer un certain nombre d'erreurs possibles à l'aide de la commande kubectl. Par exemple, vous pouvez demander l'affichage d'un déploiement :

kubectl get deployment tracing-demo

Résultat :

NAME READY UP-TO-DATE AVAILABLE AGE tracing-demo 1/1 1 1 21m

Plus de détails peuvent être affichés à l'aide de la commande describe :

kubectl describe deployment tracing-demo

La commande suivante permet d'afficher une liste des pods déployés :

kubectl get pod

Résultat :

NAME READY STATUS RESTARTS AGE tracing-demo-59cc7988fc-h5w27 1/1 Running 0 23m

Les détails concernant le pod peuvent également être consultés à l'aide de la commande describe :

kubectl describe pod tracing-demo

1. Notez le nom du pod. Vous l'utiliserez à l'étape suivante.

2. Une fois que vous connaissez le nom du pod, vous pouvez l'utiliser pour afficher les journaux en local :

kubectl logs <LOG_NAME>

Résultat :

10.60.0.1 - - [22/Jun/2018:19:42:23 +0000] "HEAD / HTTP/1.0" 200 - "-" "-" Publishing string: Hello World 10.60.0.1 - - [22/Jun/2018:19:42:23 +0000] "GET / HTTP/1.1" 200 669 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36"

Le script d'installation échoue en affichant le message Permission denied (Autorisation refusée) lors de l'exécution de Terraform. Cela signifie que les identifiants utilisés par Terraform ne fournissent pas les autorisations nécessaires à la création de ressources dans les projets sélectionnés. Assurez-vous que le compte répertorié dans gcloud config list dispose des autorisations nécessaires pour créer des ressources. Si c'est le cas, générez à nouveau les identifiants par défaut de l'application à l'aide de la commande gcloud auth application-default login.

Tâche 6 : Suppression

• Qwiklabs supprimera toutes les ressources utilisées dans le cadre de cet atelier. Notez toutefois qu'en conditions réelles, afin de nettoyer votre environnement pour limiter vos dépenses et utiliser le cloud de manière raisonnée, vous devrez saisir la commande suivante :

terraform destroy

Comme pour la commande apply, Terraform vous invitera à confirmer par yes (oui).

Comme Terraform effectue le suivi de toutes les ressources qu'il crée, il est en mesure de supprimer le cluster, ainsi que le sujet et l'abonnement Pub/Sub.

Remarque : Si vous voyez s'afficher des avertissements indiquant un abandon pour la variable "zone", ignorez-les.

Félicitations !

Étapes suivantes et informations supplémentaires

Voici quelques références intéressantes si vous souhaitez en savoir plus :

Kubernetes

Kubernetes est une plate-forme d'orchestration de conteneurs couramment employée dans les architectures de microservices. Google Cloud propose une version gérée de Kubernetes appelée Kubernetes Engine.

OpenCensus

OpenCensus fournit des bibliothèques standardisées à des fins de capture et de publication des données de télémétrie liées au traçage. Les bibliothèques sont proposées dans plusieurs langages courants et sont compatibles avec de nombreuses plates-formes de traçage, parmi lesquelles Cloud Monitoring et Zipkin. La démonstration présentée dans ce document utilise OpenCensus pour la publication des données de télémétrie sur Cloud Monitoring.

Spring Sleuth

Spring Sleuth permet l'instrumentation des applications Java qui utilisent Spring, un framework couramment employé. Spring Sleuth permet une abstraction sur les collecteurs de télémétrie dédiés au traçage distribué, afin que les développeurs puissent basculer facilement entre Zipkin, Cloud Monitoring et d'autres moteurs de traçage.

Cloud Monitoring

Operations est une suite d'outils Google Cloud proposant des fonctionnalités de journalisation, de surveillance et de traçage, ainsi que d'autres fonctionnalités associées. Ce document et cette démonstration se concentrent particulièrement sur l'utilisation de la fonctionnalité Cloud Trace de cette suite.

Terraform

Terraform est un outil Infrastructure as Code déclaratif, qui permet d'utiliser des fichiers de configuration pour automatiser le déploiement et l'évolution des infrastructures dans le cloud.

Zipkin

Zipkin est un outil de traçage distribué qui a contribué à démocratiser cette pratique.

Il est possible d'adapter les données de télémétrie Zipkin des applications déjà instrumentées pour cet outil aux événements Cloud Monitoring à l'aide d'un collecteur Zipkin. Vous pouvez en déployer un sur Kubernetes Engine à l'aide de cette commande :

kubectl run stackdriver-zipkin --image=gcr.io/stackdriver-trace-docker/zipkin-collector --expose --port=9411

Cette commande déploie le collecteur sur le port Zipkin habituel, 9411. Les applications qui le recherchent sur leur port local ne pourront pas le distinguer d'un serveur Zipkin, mais les données de télémétrie apparaîtront dans Cloud Trace.

Terminer l'atelier

Une fois l'atelier terminé, cliquez sur Terminer l'atelier. Votre compte et les ressources utilisées sont alors supprimés de la plate-forme d'atelier.

Si vous le souhaitez, vous pouvez noter l'atelier. Sélectionnez un nombre d'étoiles, saisissez un commentaire, puis cliquez sur Envoyer.

Voici à quoi correspond le nombre d'étoiles que vous pouvez attribuer à un atelier :

• 1 étoile = très insatisfait(e)
• 2 étoiles = insatisfait(e)
• 3 étoiles = ni insatisfait(e), ni satisfait(e)
• 4 étoiles = satisfait(e)
• 5 étoiles = très satisfait(e)

Si vous ne souhaitez pas donner votre avis, vous pouvez fermer la boîte de dialogue.

Pour soumettre des commentaires, suggestions ou corrections, veuillez accéder à l'onglet Assistance.

Dernière mise à jour du manuel : 28 septembre 2023

Dernier test de l'atelier : 28 septembre 2023

Copyright 2024 Google LLC. Ce logiciel est distribué tel quel, sans garantie ni représentation pour quelque utilisation ou fin que ce soit. Votre utilisation de ce logiciel est sujette à l'accord conclu avec Google.