GSP736

Présentation

Cloud Logging et l'outil associé, Cloud Monitoring, sont des produits complets qui sont tous deux profondément intégrés à Google Kubernetes Engine. Cet atelier vous apprend le fonctionnement de Cloud Logging avec les clusters GKE et les applications ainsi que quelques bonnes pratiques de collecte des journaux à travers plusieurs cas courants d'utilisation de la journalisation.

Objectifs

Dans cet atelier, vous allez apprendre à effectuer les tâches suivantes :

• Utiliser Cloud Monitoring pour détecter les problèmes
• Utiliser Cloud Logging pour dépanner une application qui s'exécute sur GKE

L'application de démonstration utilisée lors de l'atelier

Afin d'utiliser un exemple concret, vous allez dépanner une application de démonstration reposant sur des microservices déployée sur un cluster GKE. Cette application de démonstration comprend de nombreux microservices associés à des dépendances. Vous générerez du trafic à l'aide d'un générateur de charge puis utiliserez Logging, Monitoring et GKE afin de relever l'erreur (alerte/métriques). Vous identifierez ensuite une cause première à l'aide de Logging. Enfin, vous corrigerez le problème et confirmerez que le problème a été corrigé à l'aide de Logging et de Monitoring.

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 les activités dans un véritable environnement cloud, et non dans un environnement de simulation ou de démonstration. Des identifiants temporaires vous sont fournis pour vous permettre de 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 (recommandé) ou de navigation privée pour effectuer cet atelier. Vous éviterez ainsi les conflits entre votre compte personnel et le compte temporaire de participant, qui pourraient entraîner des frais supplémentaires facturés sur votre compte personnel.

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

Remarque : Utilisez uniquement le compte de participant pour cet atelier. Si vous utilisez un autre compte Google Cloud, des frais peuvent être facturés à ce compte.

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, une boîte de dialogue 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 Cloud"
   • 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 Cloud (ou effectuez un clic droit et sélectionnez Ouvrir le lien dans la fenêtre de navigation privée si vous utilisez le navigateur Chrome).

   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 ci-dessous et collez-le dans la boîte de dialogue Se connecter.

   {{{user_0.username | "Username"}}}

   Vous trouverez également le nom d'utilisateur dans le panneau "Détails concernant l'atelier".

4. Cliquez sur Suivant.

5. Copiez le mot de passe ci-dessous et collez-le dans la boîte de dialogue Bienvenue.

   {{{user_0.password | "Password"}}}

   Vous trouverez également le mot de passe dans le panneau "Détails concernant l'atelier".

6. Cliquez sur Suivant.

   Important : Vous devez utiliser les identifiants fournis pour l'atelier. Ne saisissez pas ceux de votre compte Google Cloud. Remarque : Si vous utilisez votre propre compte Google Cloud pour cet atelier, des frais supplémentaires peuvent vous être facturés.

7. 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 à des essais sans frais.

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

Remarque : Pour accéder aux produits et services Google Cloud, cliquez sur le menu de navigation ou saisissez le nom du service ou du produit dans le champ Recherche.

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.

2. Passez les fenêtres suivantes :

   • Accédez à la fenêtre d'informations de Cloud Shell.
   • Autorisez Cloud Shell à utiliser vos identifiants pour effectuer des appels d'API 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 l'ID_PROJET pour cette session :

Your Cloud Platform project in this session is set to {{{project_0.project_id | "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.

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

gcloud auth list

4. Cliquez sur Autoriser.

Résultat :

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} 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 = {{{project_0.project_id | "PROJECT_ID"}}} Remarque : Pour consulter la documentation complète sur gcloud, dans Google Cloud, accédez au guide de présentation de la gcloud CLI.

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.

Exécutez les commandes gcloud suivantes dans la console Cloud pour définir la région et la zone par défaut de votre atelier :

gcloud config set compute/zone "{{{project_0.default_zone|ZONE}}}" export ZONE=$(gcloud config get compute/zone) gcloud config set compute/region "{{{project_0.default_region|REGION}}}" export REGION=$(gcloud config get compute/region)

Tâche 1 : Configurer l'infrastructure

Connectez-vous à un cluster Google Kubernetes Engine et confirmez qu'il a été créé correctement.

1. Définissez la variable d'ID du projet :

export PROJECT_ID={{{project_0.startup_script.project | Project ID}}}

2. Utilisez la commande suivante pour afficher l'état du cluster :

gcloud container clusters list

L'état indiqué pour le cluster est "PROVISIONING" (En cours de provisionnement).

3. Patientez un moment, puis exécutez à nouveau la commande ci-dessus jusqu'à ce que l'état passe à "RUNNING" (En cours d'exécution). Cette opération peut prendre quelques minutes.

4. Vérifiez que le cluster appelé central a bien été créé.

Vous pouvez aussi surveiller la progression de l'opération dans la console Cloud en suivant ce chemin : menu de navigation > Kubernetes Engine > Clusters.

5. Une fois que votre cluster est à l'état "RUNNING" (En cours d'exécution), récupérez ses identifiants :

gcloud container clusters get-credentials central --zone $ZONE

Résultat :

Fetching cluster endpoint and auth data. kubeconfig entry generated for central.

6. Vérifiez que les nœuds ont été créés :

kubectl get nodes

Vous devez normalement obtenir le résultat suivant :

NAME STATUS ROLES AGE VERSION gke-central-default-pool-5ff4130f-qz8v Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-ssd2 Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-tz63 Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-zfmn Ready 24d v1.27.2-gke.1200

Tâche 2 : Déployer l'application

Maintenant, déployez l'application de microservices appelée Hipster Shop sur votre cluster, afin de créer une charge de travail que vous pourrez surveiller.

1. Exécutez la commande suivante pour cloner le dépôt :

git clone https://github.com/xiangshen-dk/microservices-demo.git

2. Accédez au répertoire microservices-demo :

cd microservices-demo

3. Installez l'application à l'aide de la commande kubectl :

kubectl apply -f release/kubernetes-manifests.yaml

4. Vérifiez que tout fonctionne correctement :

kubectl get pods

Le résultat doit ressembler à l'exemple ci-dessous :

NAME READY STATUS RESTARTS AGE adservice-55f94cfd9c-4lvml 1/1 Running 0 20m cartservice-6f4946f9b8-6wtff 1/1 Running 2 20m checkoutservice-5688779d8c-l6crl 1/1 Running 0 20m currencyservice-665d6f4569-b4sbm 1/1 Running 0 20m emailservice-684c89bcb8-h48sq 1/1 Running 0 20m frontend-67c8475b7d-vktsn 1/1 Running 0 20m loadgenerator-6d646566db-p422w 1/1 Running 0 20m paymentservice-858d89d64c-hmpkg 1/1 Running 0 20m productcatalogservice-bcd85cb5-d6xp4 1/1 Running 0 20m recommendationservice-685d7d6cd9-pxd9g 1/1 Running 0 20m redis-cart-9b864d47f-c9xc6 1/1 Running 0 20m shippingservice-5948f9fb5c-vndcp 1/1 Running 0 20m

5. Avant de passer à l'étape suivante, réexécutez la commande jusqu'à ce que tous les pods soient à l'état Running (En cours d'exécution).

Cliquez sur Vérifier ma progression pour valider l'objectif. Déployer l'application

6. Exécutez la commande suivante pour obtenir l'adresse IP externe de l'application. Cette commande ne renverra une adresse IP qu'une fois le service déployé. Vous devrez donc peut-être la répéter plusieurs fois jusqu'à ce qu'une adresse IP externe soit attribuée au service :

export EXTERNAL_IP=$(kubectl get service frontend-external | awk 'BEGIN { cnt=0; } { cnt+=1; if (cnt > 1) print $4; }')

7. Enfin, vérifiez que l'application est opérationnelle :

curl -o /dev/null -s -w "%{http_code}\n" http://$EXTERNAL_IP

La confirmation se présentera comme suit :

200

Une fois l'application déployée, vous pouvez aussi accéder à la console Cloud et consulter son état.

Sur la page Kubernetes Engine > Charges de travail, vous constaterez que tous les pods fonctionnent.

8. Sélectionnez Passerelles, services et entrées, puis cliquez sur l'onglet Services et vérifiez que tous les services sont en ordre. Restez sur cet écran afin de configurer la surveillance pour l'application.

Tâche 3 : Ouvrir l'application

1. Faites défiler la page vers le bas jusqu'à frontend-external, puis cliquez sur l'adresse IP des points de terminaison du service.

L'application doit s'ouvrir sur une page ressemblant à ceci :

Tâche 4 : Créer une métrique basée sur les journaux

Maintenant, vous allez configurer Cloud Logging pour créer une métrique basée sur les journaux, autrement dit une métrique personnalisée constituée d'entrées de journal, exploitable dans Cloud Monitoring. Les métriques basées sur les journaux sont pratiques pour compter le nombre d'entrées de journal et pour suivre la distribution d'une valeur dans les journaux. Dans ce cas de figure, vous allez utiliser la métrique basée sur les journaux pour compter le nombre d'erreurs dans votre service de frontend. Vous pourrez ensuite utiliser cette métrique dans les tableaux de bord et les alertes.

1. Revenez dans la console Cloud. Dans le menu de navigation, ouvrez Logging, puis cliquez sur Explorateur de journaux.

2. Activez l'option Afficher la requête. Ensuite, dans la zone de texte Générateur de requêtes, ajoutez la requête suivante :

resource.type="k8s_container" severity=ERROR labels."k8s-pod/app": "recommendationservice"

3. Cliquez sur Exécuter la requête.

La requête que vous exécutez vous permet de rechercher toutes les erreurs renvoyées par le pod de frontend. Toutefois, vous ne devriez obtenir aucun résultat à ce stade, car aucune erreur ne s'est encore produite.

4. Pour créer la métrique basée sur les journaux, cliquez sur la liste déroulante Actions, puis sélectionnez Créer une métrique.

5. Nommez la métrique Error_Rate_SLI (SLI_taux_erreur) et cliquez sur Créer la métrique pour enregistrer la métrique basée sur les journaux :

La métrique est maintenant répertoriée sous "Métriques définies par l'utilisateur" sur la page des métriques basées sur les journaux.

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer une métrique basée sur les journaux

Tâche 5 : Créer une règle d'alerte

Les alertes permettent de détecter et de résoudre rapidement les problèmes qui surviennent dans les applications cloud. Vous allez maintenant utiliser Cloud Monitoring afin de surveiller la disponibilité de votre service de frontend en créant une règle d'alerte à partir de la métrique basée sur les journaux des erreurs de frontend que vous avez créée précédemment. Lorsque la condition de la règle d'alerte est remplie, Cloud Monitoring crée et affiche un incident dans la console Cloud.

1. Dans le menu de navigation, ouvrez Monitoring, puis cliquez sur Alertes.

2. Une fois l'espace de travail créé, cliquez sur Créer une règle en haut de la page.

Remarque : Si besoin, cliquez sur Essayer pour utiliser le processus de création d'alertes mis à jour.

3. Cliquez sur le menu déroulant Sélectionner une métrique. Décochez Active.

4. Dans le champ Filtrer par nom de ressource ou de métrique, saisissez Error_Rate.

5. Cliquez sur Conteneur Kubernetes > Métrique basée sur les journaux. Sélectionnez logging/user/Error_Rate_SLI, puis cliquez sur Appliquer.

Votre écran doit désormais ressembler à ce qui suit :

6. Définissez la fonction de fenêtre glissante sur Taux.

7. Cliquez sur Suivant.

8. Indiquez 0,5 comme valeur de seuil.

Comme prévu, il n'y a aucune défaillance et votre application respecte l'objectif de niveau de service (SLO) de disponibilité.

9. Cliquez à nouveau sur Suivant.

10. Désactivez l'option Utiliser le canal de notification.

11. Indiquez un nom d'alerte, par exemple SLI de taux d'erreur, puis cliquez sur Suivant.

12. Examinez l'alerte et cliquez sur Créer une règle.

Remarque : Vous ne créerez pas de canal de notification lors de cet atelier, mais vous devriez le faire pour vos applications exécutées en production, afin de pouvoir envoyer des notifications par e-mail, SMS, Pub/Sub ou encore via une application mobile ou des webhooks.

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer une règle d'alerte

Déclencher une erreur d'application

Vous allez maintenant utiliser un générateur de charge afin de générer du trafic pour votre application Web. Étant donné qu'un bug a été introduit volontairement dans cette version de l'application, un certain volume de trafic déclenchera des erreurs. Vous allez suivre les étapes indiquées pour identifier le bug et le corriger.

1. Dans le menu de navigation, sélectionnez Kubernetes Engine, puis Passerelles, services et entrées et cliquez sur l'onglet Services.

2. Recherchez le service loadgenerator-external, puis cliquez sur le lien Points de terminaison.

Vous pouvez également ouvrir un nouvel onglet ou une nouvelle fenêtre de navigateur et copier puis coller l'adresse IP dans le champ d'URL, par exemple : http://\[loadgenerator-external-ip\]

La page du générateur de charge Locust s'affiche :

Locust est un générateur de charge Open Source qui permet d'effectuer un test de charge sur une application Web. Il peut simuler l'accès simultané aux points de terminaison de votre application par un certain nombre d'utilisateurs à un taux d'apparition donné.

1. Simulez l'accès à l'application par 300 utilisateurs avec un taux d'apparition de 30. Locust ajoutera 30 utilisateurs par seconde jusqu'à atteindre 300 utilisateurs.

2. Pour le champ d'hôte, vous utiliserez frontend-external. Copiez l'URL de la page "Passerelles, services et entrée", en veillant à exclure le port. Exemple :

3. Cliquez sur le bouton Start swarming (Démarrer le travail en essaim). Vous devriez avoir environ 300 utilisateurs sur les URL prédéfinies en quelques secondes.

4. Cliquez sur l'onglet Failures (Échecs) pour vérifier que des erreurs commencent à se produire. Vous constatez un grand nombre d'erreurs 500.

Par ailleurs, si vous cliquez sur un produit sur la page d'accueil, vous constatez des ralentissements importants ou vous recevez des messages d'erreur semblables à celui-ci :

Confirmer l'alerte et les erreurs d'application

1. Dans le menu de navigation de la console, cliquez sur Monitoring, puis sur Alertes. Un message d'incident concernant logging/user/Error_Rate_SLI doit s'afficher rapidement. Si vous ne voyez pas d'incident tout de suite, patientez une à deux minutes, puis actualisez l'affichage. Le déclenchement de l'alerte peut prendre jusqu'à cinq minutes.

2. Cliquez sur le lien de l'incident :

La page "Informations" s'affiche.

3. Dans la section "Journaux", cliquez sur Afficher dans l'explorateur de journaux, puis sélectionnez l'ID du projet dans le menu déroulant pour afficher les journaux du pod.

4. Vous pouvez également cliquer sur l'étiquette Erreur dans le panneau "Explorateur" du champ "Journaux" pour n'interroger que les erreurs.

Vous pouvez également cliquer sur le champ "Aperçu de la requête" pour afficher le générateur de requêtes, puis cliquer sur le menu déroulant Gravité et ajouter le niveau Erreur à la requête. Cliquez sur le bouton Ajouter, puis sur Exécuter la requête. Le menu déroulant permet d'ajouter plusieurs valeurs de gravité.

Dans tous les cas, le résultat ajoute severity=ERROR à votre requête. Vous devriez maintenant recevoir tous les messages d'erreur pour le pod RecommendationService.

5. Consultez les informations concernant une erreur en développant l'événement associé. Exemple :

6. Développez le champ textPayload.

7. Cliquez sur le message d'erreur et sélectionnez Ajouter un champ à la ligne de résumé pour que les messages d'erreur s'affichent en tant que champ de résumé :

Ici, vous pouvez constater que les erreurs sont en effet nombreuses pour le service RecommendationService. Les messages d'erreur indiquent que le service RecommendationService n'a pas pu se connecter à certains services en aval afin de récupérer des produits ou des recommandations. Toutefois, la cause première des erreurs n'est toujours pas claire.

Si vous réexaminez le schéma de l'architecture, vous constaterez que le service RecommendationService fournit une liste de recommandations au service Frontend. Toutefois, le service Frontend et le service RecommendationService appellent tous deux ProductCatalogService afin d'obtenir une liste de produits.

Lors de la prochaine étape, vous allez examiner les métriques du suspect principal, ProductCatalogService, et rechercher d'éventuelles anomalies. Dans tous les cas, vous pourrez examiner les journaux en détail pour obtenir des insights.

Dépannage à l'aide du tableau de bord et des journaux Kubernetes

1. Pour consulter les métriques, pensez en premier lieu à la section Kubernetes Engine de la console Monitoring (menu de navigation > Monitoring > Tableaux de bord > GKE).

2. Consultez la section Charges de travail.

3. Accédez à Kubernetes Engine > Charges de travail > productcatalogservice. Vous pouvez voir que le pod du service plante et redémarre en permanence.

Voyez maintenant si les journaux contiennent des informations intéressantes.

Vous pouvez accéder facilement à vos journaux de conteneur de deux manières :

1. Cliquez sur l'onglet Journaux pour afficher un aperçu des journaux les plus récents. Ensuite, cliquez sur le bouton de lien externe en haut à droite du panneau des journaux pour revenir dans l'explorateur de journaux.

2. Sur la page de l'aperçu, cliquez sur le lien Journaux de conteneur de la page des détails du déploiement.

Vous vous trouvez de nouveau sur la page de l'explorateur de journaux, cette fois avec une requête prédéfinie, filtrée spécialement pour les journaux du conteneur que vous examiniez dans GKE.

Dans la visionneuse de journaux, les messages des journaux et l'histogramme indiquent tous les deux que le conteneur analyse de façon répétée les catalogues de produits sur une courte durée. Cela semble très inefficace.

En bas des résultats de la requête, vous pouvez également trouver une erreur d'exécution comme celle-ci :

panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation

Elle pourrait être à l'origine du plantage du pod.

Pour mieux en comprendre la cause, recherchez le message du journal dans le code.

1. Dans Cloud Shell, exécutez la commande suivante :

grep -nri 'successfully parsed product catalog json' src

Le résultat doit se présenter sous la forme suivante, avec le nom du fichier source accompagné d'un numéro de ligne :

src/productcatalogservice/server.go:237: log.Info("successfully parsed product catalog json")

2. Pour voir le fichier source, cliquez sur le bouton Ouvrir l'éditeur dans le menu Cloud Shell, puis sur Ouvrir dans une nouvelle fenêtre. Si l'erreur "Impossible de charger l'éditeur de code, car les cookies tiers sont désactivés" s'affiche, cliquez sur l'œil en haut de la page du navigateur Chrome.

3. Cliquez sur le fichier microservices-demo/src/productcatalogservice/server.go, faites défiler vers le bas jusqu'à la ligne 237, et vous constaterez que la méthode readCatalogFile renvoie ce message :

En regardant de plus près, vous constaterez que si la variable booléenne reloadCatalog a la valeur "true", le service s'actualise et analyse le catalogue de produits à chaque fois qu'il est appelé, ce qui semble inutile.

Si vous recherchez la variable reloadCatalog dans le code, vous verrez qu'elle est contrôlée par la variable d'environnement ENABLE_RELOAD et qu'elle crée un message de journal sur son état.

Vérifiez à nouveau les journaux en ajoutant ce message à votre requête, puis recherchez les éventuelles entrées correspondantes.

1. Revenez dans l'onglet où l'explorateur de journaux est ouvert et ajoutez la ligne suivante à la requête :

jsonPayload.message:"catalog reloading"

Dans le générateur de requêtes, la requête complète se présente comme suit :

resource.type="k8s_container" resource.labels.location="{{{project_0.startup_script.zone | ZONE}}}" resource.labels.cluster_name="central" resource.labels.namespace_name="default" labels.k8s-pod/app="productcatalogservice" jsonPayload.message:"catalog reloading"

2. Cliquez à nouveau sur Exécuter la requête et recherchez le message "Enable catalog reloading" dans le journal du conteneur. Ce message confirme que la fonction d'actualisation du catalogue est activée.

À ce stade, vous pouvez avoir la certitude que l'erreur de l'interface (frontend) est causée par une contrainte trop importante liée au chargement du catalogue pour chaque requête. Lorsque vous avez augmenté la charge, cette contrainte supplémentaire a causé l'échec du service et généré l'erreur.

Tâche 6 : Corriger le problème et vérifier le résultat

En vous appuyant sur le code et le contenu des journaux, essayez de corriger le problème en désactivant l'actualisation du catalogue. Maintenant, supprimez la variable d'environnement ENABLE_RELOAD correspondant au service du catalogue de produits. Une fois les modifications de variable effectuées, vous pouvez redéployer l'application et vérifier que les modifications ont permis de résoudre le problème observé précédemment.

1. Cliquez sur le bouton Ouvrir le terminal pour revenir dans le terminal Cloud Shell s'il s'est fermé.

2. Exécutez la commande ci-dessous.

grep -A1 -ni ENABLE_RELOAD release/kubernetes-manifests.yaml

Le résultat indique le numéro de ligne de la variable d'environnement dans le fichier manifeste :

373: - name: ENABLE_RELOAD 374- value: "1"

3. Vous devez supprimer ces deux lignes pour désactiver l'actualisation en exécutant la commande suivante :

sed -i -e '373,374d' release/kubernetes-manifests.yaml

4. Ensuite, appliquez à nouveau le fichier manifeste :

kubectl apply -f release/kubernetes-manifests.yaml

Vous pouvez remarquer que seul le service productcatalogservice est configuré. Les autres services n'ont pas été modifiés.

5. Revenez sur la page des détails du déploiement (menu de navigation > Kubernetes Engine > Charges de travail > productcatalogservice) et patientez jusqu'à la fin de l'exécution du pod. Patientez deux à trois minutes, ou jusqu'à ce que vous puissiez confirmer la fin du plantage.

6. Si vous cliquez à nouveau sur le lien Journaux des conteneurs, vous pouvez voir que les messages indiquant que l'analyse du catalogue au format JSON a réussi qui s'affichaient plusieurs fois ont disparu :

7. Si vous revenez à l'URL de l'application Web et cliquez sur les produits présentés sur la page d'accueil, vous constatez également qu'elle est beaucoup plus réactive et qu'aucune erreur HTTP n'est renvoyée.

8. Revenez dans le générateur de charge et cliquez sur le bouton Reset Stats (Réinitialiser les statistiques) en haut à droite. Le pourcentage d'échec est réinitialisé. Il ne devrait plus augmenter.

Toutes les coches ci-dessus indiquent que le problème a été corrigé. Si l'erreur 500 s'affiche toujours, patientez encore quelques minutes, puis réessayez de cliquer sur un produit.

Félicitations !

Vous avez utilisé Cloud Logging et Cloud Monitoring pour trouver une erreur dans une version volontairement mal configurée de l'application de démonstration de microservices. Il s'agit d'un processus de dépannage semblable à celui que vous utiliseriez afin de filtrer les problèmes concernant vos applications GKE dans un environnement de production.

Vous avez commencé par déployer l'application sur GKE, puis vous avez configuré une métrique et une alerte pour les erreurs de frontend. Ensuite, vous avez généré une charge et remarqué que l'alerte se déclenchait. En vous appuyant sur l'alerte, vous avez pu circonscrire le problème à certains services utilisant Cloud Logging. Ensuite, vous avez utilisé Cloud Monitoring et l'UI GKE pour examiner les métriques des services GKE. Enfin, pour corriger le problème, vous avez déployé une configuration mise à jour sur GKE. Vous avez pu ensuite confirmer que le correctif avait permis de résoudre les erreurs des journaux.

Étapes suivantes et informations supplémentaires

• Cet atelier s'inspire de cet article de blog concernant l'utilisation de Logging pour vos applications exécutées sur GKE.
• L'article de suivi sur la manière dont les équipes DevOps peuvent utiliser Cloud Monitoring et Logging pour identifier rapidement les problèmes est également susceptible de vous intéresser.

Formations et certifications Google Cloud

Les formations et certifications Google Cloud vous aident à tirer pleinement parti des technologies Google Cloud. Nos cours portent sur les compétences techniques et les bonnes pratiques à suivre pour être rapidement opérationnel et poursuivre votre apprentissage. Nous proposons des formations pour tous les niveaux, à la demande, en salle et à distance, pour nous adapter aux emplois du temps de chacun. Les certifications vous permettent de valider et de démontrer vos compétences et votre expérience en matière de technologies Google Cloud.

Dernière mise à jour du manuel : 21 février 2025

Dernier test de l'atelier : 21 février 2025

Copyright 2025 Google LLC. Tous droits réservés. Google et le logo Google sont des marques de Google LLC. Tous les autres noms d'entreprises et de produits peuvent être des marques des entreprises auxquelles ils sont associés.