Points de contrôle
Deploy Application
/ 30
Create a logs-based metric
/ 30
Create an alerting policy
/ 40
Déboguer des applications sur Google Kubernetes Engine
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 de l'atelier
-
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 microservices de démonstration déployée sur un cluster GKE. Cette application de démonstration comporte 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), identifierez une cause première à l'aide de Logging, puis corrigerez le problème/confirmerez que le problème a été corrigé à l'aide de Logging et de Monitoring.
Prérequis
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) ;
- vous disposez d'un temps limité ; une fois l'atelier commencé, vous ne pouvez pas le mettre en pause.
Démarrer l'atelier et se connecter à la console Google Cloud
-
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
-
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. -
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.
-
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. -
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.
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.
- 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 :
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.
- (Facultatif) Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :
-
Cliquez sur Autoriser.
-
Vous devez à présent obtenir le résultat suivant :
Résultat :
- (Facultatif) Vous pouvez lister les ID de projet à l'aide de cette commande :
Résultat :
Exemple de résultat :
gcloud, dans Google Cloud, accédez au guide de présentation de la gcloud CLI.
Configurer l'infrastructure
Connectez-vous à un cluster Google Kubernetes Engine et confirmez qu'il a été créé correctement.
Dans Cloud Shell, définissez votre zone dans gcloud :
Définissez la variable d'ID du projet :
Utilisez la commande suivante pour afficher l'état du cluster :
L'état indiqué pour le cluster est "Provisionning" (En cours de provisionnement). 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. Vérifiez que le cluster appelé central a bien été créé.
Vous pouvez aussi surveiller la progression de l'opération dans Cloud Console en suivant ce chemin : menu de navigation > Kubernetes Engine > Clusters.
Une fois que votre cluster indique "Running" (En cours d'exécution), récupérez ses identifiants :
(Résultat)
Vérifiez que les nœuds ont été créés :
Vous devez normalement obtenir le résultat suivant :
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.
Exécutez la commande suivante pour cloner le dépôt :
Accédez au répertoire microservices-demo :
Installez l'application à l'aide de la commande kubectl :
Vérifiez que tout fonctionne correctement :
Le résultat doit ressembler à l'exemple ci-dessous. Avant de passer à l'étape suivante, réexécutez la commande jusqu'à ce que tous les pods indiquent "Running" (En cours d'exécution).
Cliquez sur Vérifier ma progression pour valider l'objectif.
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 lui soit attribuée :
Enfin, vérifiez que l'application est opérationnelle :
La confirmation se présentera comme suit :
Une fois l'application déployée, vous pouvez aussi accéder à Cloud Console et consulter son état.
Sur la page Kubernetes Engine > Charges de travail, vous constaterez que tous les pods sont corrects.
Cliquez maintenant sur Services et entrée et vérifiez que tous les services sont en ordre. Restez sur cet écran afin de configurer la surveillance pour l'application.
Ouvrir l'application
Faites défiler vers le bas jusqu'à frontend-external, puis cliquez sur l'IP des points de terminaison du service.
L'application doit s'ouvrir sur une page ressemblant à ceci :
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, c'est-à-dire une métrique personnalisée dans Cloud Monitoring et constituée d'entrées de journal. 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.
Revenez dans Cloud Console, et dans le menu de navigation, ouvrez Logging, puis cliquez sur Explorateur de journaux.
Dans la zone de texte Générateur de requêtes, ajoutez la requête suivante :
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.
Pour créer la métrique basée sur les journaux, cliquez sur Créer une métrique.
Nommez la métrique Error_Rate_SLI (SLI_taux_erreur) et cliquez sur Créer une 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 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 Cloud Console.
Dans le menu de navigation, ouvrez Monitoring, puis cliquez sur Alertes.
Une fois l'espace de travail créé, cliquez sur Créer une règle en haut de la page.
Cliquez sur le menu déroulant Sélectionner une métrique. Désactivez l'option Afficher uniquement les ressources et les métriques actives.
Dans le champ Filtrer par nom de ressource ou de métrique, saisissez Error_Rate.
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 :
Définissez la fonction de fenêtre dynamique sur Taux.
Cliquez sur Suivant.
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é.
Cliquez à nouveau sur Suivant.
Désactivez l'option Utiliser un canal de notification. Indiquez un nom d'alerte, comme SLI de taux d'erreur, puis cliquez sur Suivant.
Examinez l'alerte et cliquez sur Créer une règle.
Cliquez sur Vérifier ma progression pour valider l'objectif.
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.
Dans le menu de navigation, sélectionnez Moteur Kubernetes, puis Services et entrée.
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é.
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.
Pour le champ d'hôte, vous utiliserez frontend-external. Copiez l'URL de la page "Services et entrée", en veillant à exclure le port. Exemple :
Cliquez sur le bouton Démarrer le travail en essaim. Vous devriez avoir environ 300 utilisateurs sur les URL prédéfinies en quelques secondes.
Cliquez sur l'onglet É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, elle est soit extrêmement lente, soit vous recevez des erreurs semblables à celle-ci :
Confirmer l'alerte et les erreurs d'application
Dans le menu de navigation de Cloud Console, cliquez sur Monitoring, puis sur Alertes. Un 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.
Cliquez sur le lien de l'incident :
La page Informations s'affiche. Cliquez sur le lien AFFICHER LES JOURNAUX pour voir les journaux associés au pod.
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 d'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 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. Ensuite, vous devriez recevoir tous les messages d'erreur pour le pod RecommendationService.
Consultez les informations concernant une erreur en développant l'événement associé. Exemple :
Développez le champ textPayload. 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 aux services Frontend. Toutefois, le service Frontend et le service RecommendationService appellent tous les 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
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).
Consultez la section Charges de travail.
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 :
- 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.
- 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, il peut également y avoir une erreur d'exécution comme celle-ci :
Elle pourrait être à l'origine du plantage du pod.
Pour mieux en comprendre la cause, recherchez le message du journal dans le code.
Dans Cloud Shell, exécutez la commande suivante :
Le résultat doit se présenter sous la forme suivante, avec le nom du fichier source accompagné d'un numéro de ligne :
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.
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'elle est appelée, 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.
Revenez dans l'onglet où l'explorateur de journaux est ouvert et ajoutez la ligne suivante à la requête :
La requête complète dans le générateur de requêtes se présente comme suit :
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 frontend a été causée par une contrainte trop importante liée au chargement du catalogue pour chaque requête. Lorsque vous avez augmenté la charge, le dépassement a causé l'échec du service et généré l'erreur.
Corrigez le problème et vérifiez 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.
Cliquez sur le bouton Ouvrir le terminal pour revenir dans le terminal Cloud Shell s'il s'est fermé.
Exécutez la commande suivante :
Le résultat indique le numéro de ligne de la variable d'environnement dans le fichier manifeste :
Supprimez ces deux lignes pour désactiver l'actualisation en exécutant la commande suivante :
Ensuite, appliquez à nouveau le fichier manifeste :
Vous remarquerez que seul le service productcatalogservice est configuré. Les autres services n'ont pas été modifiés.
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.
Si vous cliquez à nouveau sur le lien Journaux de conteneur, vous verrez que les messages indiquant que l'analyse du catalogue au format JSON a réussi qui s'affichaient plusieurs fois ont disparu :
Si vous revenez dans l'URL de l'application Web et cliquez sur les produits sur la page d'accueil, vous constaterez aussi qu'elle est beaucoup plus réactive, et vous ne devriez plus rencontrer aucune erreur HTTP.
Revenez dans le générateur de charge et cliquez sur le bouton Réinitialiser les statistiques en haut à droite de l'écran. 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 du 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 réduire 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 et confirmé que le correctif avait permis de résoudre les erreurs des journaux.
Terminer votre quête
Cet atelier d'auto-formation fait partie de la quête Qwiklabs Google Cloud's Operations Suite on GKE. Une quête est une série d'ateliers associés qui constituent une formation. Si vous terminez cette quête, vous obtiendrez le badge ci-dessus attestant de votre réussite. Vous pouvez rendre publics les badges que vous recevez et ajouter leur lien dans votre CV en ligne ou sur vos comptes de réseaux sociaux. Inscrivez-vous à cette quête pour obtenir immédiatement les crédits associés à cet atelier si vous l'avez suivi. Découvrez les autres quêtes Qwiklabs disponibles.
Atelier suivant
Continuez sur votre lancée en suivant l'atelier Cloud Logging sur Kubernetes Engine ou consultez ces suggestions :
É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 Cloud 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 : 14 avril 2022
Dernier test de l'atelier : 14 avril 2022
Copyright 2024 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.