1. Introduction
Dernière mise à jour : 28/07/2023
Qu'est-ce que la suite Google Cloud Operations ?
La suite Google Cloud Operations est une plate-forme qui vous permet de surveiller, de dépanner et d'améliorer les performances des applications dans votre environnement Google Cloud. Les principaux piliers de la suite Cloud Operations incluent Cloud Monitoring, Cloud Logging et Cloud Trace.
Regardez cette vidéo pour obtenir un aperçu général de Google Cloud Operations.
Objectifs de l'atelier
Dans cet atelier de programmation, vous allez déployer un exemple d'API sur Google Cloud. Vous explorerez et configurerez ensuite plusieurs fonctionnalités de Cloud Monitoring par rapport à l'API.
Points abordés
- Utilisation de Cloud Shell de Google Cloud pour déployer un exemple d'application sur Cloud Run.
- Utilisation des fonctionnalités de Google Cloud Monitoring, comme les tableaux de bord, les alertes, les tests de disponibilité, la surveillance des SLI/SLO, etc.
Prérequis
- Une version récente de Chrome (74 ou ultérieure)
- Un compte Google Cloud et un projet Google Cloud
2. Préparation
Configuration de l'environnement au rythme de chacun
Si vous ne possédez pas encore de compte Google (Gmail ou Google Apps), vous devez en créer un. Connectez-vous à la console Google Cloud Platform (console.cloud.google.com) et créez un projet.
- Le nom du projet est celui que verront les participants au projet. Il s'agit d'une chaîne de caractères non utilisée par les API Google. Vous pouvez le modifier à tout moment.
- L'ID du projet doit être unique sur l'ensemble des projets Google Cloud et doit être immuable (vous ne pouvez pas le modifier une fois que vous l'avez défini). La console Cloud génère automatiquement une chaîne unique (en général, vous n'y accordez d'importance particulière). Dans la plupart des ateliers de programmation, vous devrez indiquer l'ID de votre projet (généralement identifié par PROJECT_ID). Si l'ID généré ne vous convient pas, vous pouvez en générer un autre de manière aléatoire. Vous pouvez également en spécifier un et voir s'il est disponible. Après cette étape, l'ID n'est plus modifiable et restera donc le même pour toute la durée du projet.
- Pour information, il existe une troisième valeur (le numéro de projet) que certaines API utilisent. Pour en savoir plus sur ces trois valeurs, consultez la documentation.
Attention : Un ID de projet doit être unique au niveau mondial. Personne d'autre ne peut l'employer une fois que vous l'avez sélectionné. Vous en êtes le seul utilisateur. Même si un projet est supprimé, son ID ne peut pas être réutilisé.
- Vous devez ensuite activer la facturation dans la console Cloud pour utiliser les ressources/API Cloud. L'exécution de cet atelier de programmation est très peu coûteuse, voire sans frais. Pour désactiver les ressources et éviter ainsi que des frais ne vous soient facturés après ce tutoriel, vous pouvez supprimer le projet ou les ressources que vous avez créées. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai sans frais pour bénéficier d'un crédit de 300$.
Configuration de Google Cloud Shell
Bien que Google Cloud et Google Cloud Trace puissent être utilisés à distance depuis votre ordinateur portable, nous allons utiliser Google Cloud Shell pour cet atelier de programmation, un environnement de ligne de commande exécuté dans le cloud.
Pour activer Cloud Shell à partir de la console Cloud, cliquez simplement sur Activer Cloud Shell (l'opération de provisionnement et la connexion à l'environnement ne devraient prendre que quelques minutes).
Si vous n'avez jamais démarré Cloud Shell auparavant, un écran intermédiaire s'affiche en dessous de la ligne de flottaison, décrivant de quoi il s'agit. Si tel est le cas, cliquez sur "Continuer" (cet écran ne s'affichera qu'une seule fois). Voici à quoi il ressemble :
Le provisionnement et la connexion à Cloud Shell ne devraient pas prendre plus de quelques minutes.
Cette machine virtuelle contient tous les outils de développement dont vous avez besoin. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud, ce qui améliore nettement les performances du réseau et l'authentification. Vous pouvez réaliser une grande partie, voire la totalité, des activités de cet atelier dans un simple navigateur ou sur votre Chromebook.
Une fois connecté à Cloud Shell, vous êtes en principe authentifié et le projet est défini avec votre ID de projet.
Exécutez la commande suivante dans Cloud Shell pour vérifier que vous êtes authentifié :
Une fois connecté à Cloud Shell, vous êtes normalement déjà authentifié et le projet PROJECT_ID est sélectionné :
gcloud auth list
Résultat de la commande
Credentialed accounts: - <myaccount>@<mydomain>.com (active)
gcloud config list project
Résultat de la commande
[core] project = <PROJECT_ID>
Si, pour une raison quelconque, le projet n'est pas défini, exécutez simplement la commande suivante :
gcloud config set project <PROJECT_ID>
Par défaut, Cloud Shell définit certaines variables d'environnement qui pourront s'avérer utiles pour exécuter certaines commandes dans le futur.
echo $GOOGLE_CLOUD_PROJECT
Résultat de la commande
<PROJECT_ID>
Exemples d'application
Pour ce projet, nous avons regroupé tout ce dont vous avez besoin dans un dépôt Git. Le dépôt contient quelques exemples d'applications. Vous pouvez choisir d'en utiliser l'une d'elles pour cet exercice.
Lien du dépôt Git : https://github.com/rominirani/cloud-code-sample-repository
3. Déployer l'application d'API
Quel est l'objet de l'application ou de l'API exemple ?
Notre application est une application simple de l'API Inventory qui expose un point de terminaison d'API REST avec quelques opérations permettant de lister les articles de l'inventaire et d'obtenir le nombre d'articles spécifiques en stock.
Une fois l'API déployée et en supposant qu'elle soit hébergée sur https://<somehost>, nous pouvons accéder aux points de terminaison de l'API comme suit :
- https://<somehost>/inventory
Tous les produits et leurs niveaux de stock disponibles seront listés.
- https://<somehost>/inventory/{productid}
Vous obtiendrez ainsi un seul enregistrement avec l'ID du produit et le niveau de stock disponible pour ce produit.
Les données de réponse renvoyées sont au format JSON.
Exemple de données et de requête/réponse API
Pour plus de simplicité, l'application n'est pas alimentée par une base de données au niveau du backend. Il contient trois exemples d'ID de produits et leurs niveaux de stock disponibles.
Identifiant produit | Niveau de stock disponible |
I-1 | 10 |
I-2 | 20 |
I-3 | 30 |
Vous trouverez ci-dessous un exemple de requête et de réponse de l'API :
Requête API | Réponse de l'API |
https://<somehost>/inventory | [ { "I-1": 10, "I-2": 20, "I-3": 30 }] |
https://<somehost>/inventory/I-1 | { "productid": "I-1", "qty": 10} |
https://<somehost>/inventory/I-2 | { "productid": "I-2", "qty": 20} |
https://<somehost>/inventory/I-200 | { "productid": I-200, "qty": -1} |
Cloner le dépôt
Bien que Google Cloud puisse être utilisé à distance depuis votre ordinateur portable, nous allons nous servir de Google Cloud Shell pour cet atelier de programmation, un environnement de ligne de commande exécuté dans le cloud.
Depuis la console GCP, cliquez sur l'icône Cloud Shell de la barre d'outils située dans l'angle supérieur droit :
Le provisionnement et la connexion à l'environnement prennent quelques instants seulement. Une fois l'opération terminée, le résultat devrait ressembler à ceci :
Cette machine virtuelle contient tous les outils de développement nécessaires. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud, ce qui améliore nettement les performances du réseau et l'authentification. Vous pouvez réaliser toutes les activités de cet atelier dans un simple navigateur.
Configurer gcloud
Dans Cloud Shell, définissez l'ID de votre projet et enregistrez-le en tant que variable PROJECT_ID.
PROJECT_ID=[YOUR-PROJECT-ID]
gcloud config set project $PROJECT_ID
Exécutez maintenant la commande suivante :
$ git clone https://github.com/rominirani/cloud-code-sample-repository.git
Un dossier intitulé cloud-code-sample-repository sera alors créé dans ce dossier.
(Facultatif) Exécuter l'application sur Cloud Shell
Pour exécuter l'application en local, procédez comme suit :
- Depuis le terminal, accédez à la version Python de l'API à l'aide de la commande suivante :
$ cd cloud-code-sample-repository
$ cd python-flask-api
- Dans le terminal, saisissez la commande suivante (au moment de la rédaction, Cloud Shell est fourni avec Python 3.9.x installé. Nous utiliserons la version par défaut. Si vous prévoyez de l'exécuter localement sur votre ordinateur portable, vous pouvez utiliser Python 3.8 ou une version ultérieure :
$ python app.py
- Vous pouvez exécuter la commande suivante pour démarrer le serveur Python en local.
- Un serveur sera alors lancé sur le port 8080. Vous pourrez le tester localement à l'aide de la fonctionnalité d'aperçu sur le Web de Cloud Shell. Cliquez sur le bouton Aperçu sur le Web, comme indiqué ci-dessous :
Cliquez sur "Prévisualiser sur le port 8080".
- Une fenêtre de navigateur s'ouvre. Une erreur 404 s'affiche, mais ce n'est pas grave. Modifiez l'URL pour qu'elle ne contienne que /inventory après le nom d'hôte.
Par exemple, sur mon ordinateur, cela ressemble à ceci :
https://8080-cs-557561579860-default.cs-asia-southeast1-yelo.cloudshell.dev/inventory
La liste des articles d'inventaire s'affiche, comme expliqué précédemment :
- Vous pouvez arrêter le serveur maintenant en accédant au terminal et en appuyant sur Ctrl+C.
Déployer l'application
Nous allons maintenant déployer cette application d'API sur Cloud Run. Le processus impliquait l'utilisation du client de ligne de commande gcloud pour exécuter la commande permettant de déployer le code sur Cloud Run.
Dans le terminal, exécutez la commande gcloud suivante :
$ gcloud run deploy --source .
Plusieurs questions vous seront posées (si vous êtes invité à autoriser, veuillez le faire). Voici quelques points à prendre en compte : Vous pouvez ou non obtenir toutes les questions, en fonction de la configuration et si vous avez déjà activé des API spécifiques dans votre projet Google Cloud.
- Nom du service (python-flask-api) : conservez le nom par défaut ou choisissez-en un autre, par exemple my-inventory-api.
- L'API [run.googleapis.com] n'est pas activée pour le projet [project-number]. Voulez-vous activer et réessayer (cela prendra quelques minutes) ? (y/N)? O
- Veuillez spécifier une région : choisissez une région de votre choix en indiquant un numéro.
- API [artifactregistry.googleapis.com] not enabled on project [project-number]. Voulez-vous activer et réessayer (cela prendra quelques minutes) ? (y/N)? O
- Le déploiement à partir de la source nécessite un dépôt Docker Artifact Registry pour stocker les conteneurs créés. Un dépôt nommé [cloud-run-source-deploy] sera créé dans la région [us-west1].
Do you want to continue (Y/n)? O
- Autoriser les appels non authentifiés vers [my-inventory-api] (y/N) ? O
Cela lancera le processus de conteneurisation de votre code source, de transfert vers Artifact Registry, puis de déploiement du service et de la révision Cloud Run. Soyez patient pendant ce processus (qui peut prendre trois à quatre minutes). Une fois terminé, l'URL du service s'affiche.
Voici un exemple d'exécution :
Tester l'application
Maintenant que nous avons déployé l'application sur Cloud Run, vous pouvez accéder à l'application d'API comme suit :
- Notez l'URL du service de l'étape précédente. Par exemple, sur ma configuration, il s'affiche sous la forme
https://my-inventory-api-bt2r5243dq-uw.a.run.app. Appelons-le <SERVICE_URL>. - Ouvrez un navigateur et accédez aux trois URL suivantes pour les points de terminaison de l'API :
- <SERVICE_URL>/inventory
- <SERVICE_URL>/inventory/I-1
- <SERVICE_URL>/inventory/I-100
Il doit correspondre aux spécifications que nous avons fournies dans une section précédente avec un exemple de requête et de réponse d'API.
Obtenir les détails du service à partir de Cloud Run
Nous avons déployé notre service d'API sur Cloud Run, un environnement de calcul sans serveur. Nous pouvons accéder au service Cloud Run via la console Google Cloud à tout moment.
Dans le menu principal, accédez à Cloud Run. La liste des services que vous exécutez dans Cloud Run s'affiche. Vous devriez voir le service que vous venez de déployer. Selon le nom que vous avez sélectionné, l'écran qui s'affiche devrait ressembler à ce qui suit :
Cliquez sur le nom du service pour afficher les détails. Vous trouverez ci-dessous les détails de l'échantillon :
Notez l'URL, qui n'est autre que l'URL du service que vous pouvez saisir dans le navigateur pour accéder à l'API Inventory que nous venons de déployer. N'hésitez pas à consulter les métriques et d'autres détails.
Commençons tout de suite par la suite Google Cloud Operations.
4. Configurer un tableau de bord
Cloud Monitoring propose des tableaux de bord prêts à l'emploi pour plusieurs ressources dans Google Cloud. La configuration initiale des tableaux de bord avec des métriques standards est ainsi rapide et pratique.
Voyons comment procéder pour le service d'API que nous venons de déployer sur Cloud Run.
Tableau de bord personnalisé pour notre Service
Comme nous avons déployé notre service d'API sur Cloud Run, voyons comment configurer des tableaux de bord qui peuvent aider à visualiser différentes métriques, dont la latence du service.
Tout d'abord, dans la console, accédez à Monitoring → Aperçu, comme indiqué ci-dessous :
La vue d'ensemble affiche plusieurs éléments que vous avez configurés dans Monitoring, comme les tableaux de bord, les alertes, les tests de disponibilité, etc.
Pour l'instant, cliquons sur Tableaux de bord dans le menu principal sur le côté. Vous accéderez à l'écran suivant :
Cliquez sur SAMPLE LIBRARY (Bibliothèque d'échantillons). La liste des tableaux de bord prêts à l'emploi disponibles dans Google Cloud s'affiche pour plusieurs ressources. Plus précisément, faites défiler la liste vers le bas et sélectionnez Google Cloud Run, comme illustré ci-dessous.
Une liste des tableaux de bord standards disponibles pour Google Cloud Run s'affiche. Cela nous intéresse, car nous avons déployé notre service sur Cloud Run.
Un tableau de bord Cloud Run Monitoring s'affiche. Cliquez sur le lien APERÇU pour afficher la liste des graphiques standards (métriques) disponibles pour la surveillance Cloud Run. Il vous suffit de cliquer sur IMPORTER UN EXEMPLE DE TABLEAU DE BORD pour importer tous ces graphiques dans un tableau de bord personnalisé. L'écran "Tableau de bord" s'affiche avec un nom prérempli, comme indiqué ci-dessous :
Pour revenir en arrière, cliquez sur la flèche vers la gauche, qui se trouve à gauche du nom du tableau de bord, en haut à gauche. Vous serez redirigé vers la liste des tableaux de bord, dans laquelle vous devriez voir le nouveau tableau de bord que vous venez de créer.
Cliquez sur le lien du tableau de bord pour surveiller plusieurs métriques disponibles prêtes à l'emploi. Ces métriques incluent la latence, le nombre de requêtes, les métriques de conteneur et plus encore.
Vous pouvez également marquer n'importe quel tableau de bord comme favori en sélectionnant l'icône en forme d'étoile, comme indiqué ci-dessous :
Le tableau de bord est alors ajouté à l'écran "Vue d'ensemble" de Monitoring, ce qui facilite l'accès aux tableaux de bord fréquemment utilisés.
Fantastique ! Vous venez d'ajouter un tableau de bord personnalisé pour surveiller vos services Cloud Run. Bravo !
5. Tests de disponibilité
Dans cette section, nous allons configurer un test de disponibilité pour le service d'API que nous avons déployé. Un test de disponibilité public peut envoyer des requêtes depuis plusieurs emplacements dans le monde vers des URL accessibles au public ou des ressources Google Cloud pour vérifier si la ressource répond.
Dans ce cas, la ressource sera le service d'API que nous avons déployé sur Cloud Run. L'URL sera un point de terminaison spécifique que le service d'API expose pour indiquer l'état du service.
Dans l'exemple de code du service d'API, nous avons exposé un point de terminaison /healthy qui renvoie une valeur de chaîne "All Izz Well". Il nous suffit donc de définir un test de disponibilité qui accède à une URL de type https://<SERVICE_URL>/healthy et vérifie si la chaîne "All Izz Well" est renvoyée ou non.
Créer un canal de notification
Avant de créer le test de disponibilité, il est important de configurer d'abord les canaux de notification. Un canal de notification est un moyen par lequel vous serez averti en cas d'incident ou de problème avec l'une de nos ressources surveillées. Un canal de notification peut être un e-mail. Vous recevrez alors des e-mails en cas d'alerte, etc.
Pour l'instant, nous allons configurer un canal de notification par e-mail avec notre adresse e-mail afin de recevoir des notifications en cas d'alerte émise par notre système et que nous allons configurer.
Pour créer un canal de notification, procédez comme suit :
Accédez à Monitoring → Alertes dans le menu principal de la console Google Cloud, comme indiqué ci-dessous :
Une page contenant des alertes, des règles et plus encore s'affiche. Pour l'instant, un lien intitulé MODIFIER LES CANAUX DE NOTIFICATION s'affiche en haut de la page. Cliquez dessus.
Une liste de différents canaux de notification s'affiche, comme indiqué ci-dessous :
Recherchez la section Adresse e-mail, puis cliquez sur AJOUTER sur la ligne correspondante. Les détails de la configuration de l'e-mail s'affichent, comme illustré ci-dessous :
Saisissez votre adresse e-mail et un nom à afficher, comme indiqué ci-dessous. Cliquez sur ENREGISTRER.
La création du canal de notification par e-mail est terminée. Configurons maintenant le test de disponibilité.
Créer un test de disponibilité
Accédez à Monitoring → Vérifications du temps d'activité dans le menu principal de la console Google Cloud. En haut de la page, vous verrez le lien CRÉER UN TEST DE DISPONIBILITÉ. Cliquez dessus.
Une série d'étapes s'affiche. Vous devrez les suivre pour configurer le test de disponibilité.
La première étape consiste à configurer les détails de la cible, c'est-à-dire les informations sur le service Cloud Run que vous avez déployé. Voici un exemple de formulaire rempli :
Vous pouvez sélectionner les différentes valeurs comme suit :
- Protocole : HTTPS
- Type de ressource : sélectionnez "Service Cloud Run". Notez les autres ressources qu'il prend en charge et sur lesquelles vous pouvez également définir des vérifications du temps d'activité.
- Service Cloud Run : sélectionnez my-inventory-api ou le nom spécifique que vous avez attribué au service Cloud Run.
- Le chemin d'accès est /healthy, car nous renvoyons une chaîne All Izz Well et nous voulons la vérifier.
Cliquez sur CONTINUER pour passer à l'étape suivante. L'étape suivante est la validation de la réponse, comme indiqué ci-dessous :
Vous pouvez voir que nous activons la vérification de la "correspondance du contenu", puis que nous configurons la réponse renvoyée par le point de terminaison /healthy sur "All Izz Well". Cliquez sur CONTINUER pour passer à l'étape suivante, où nous allons configurer l'alerte et le canal de notification à utiliser en cas d'échec du test de disponibilité.
Dans cette étape, attribuez un nom à l'alerte. Je l'ai nommé Échec du test de disponibilité de l'API Inventory, mais vous pouvez choisir le nom de votre choix. L'important ici est de sélectionner le bon canal de notification dans la liste que vous avez configurée précédemment.
Cliquez sur VÉRIFIER pour passer à la dernière étape et vérifier le test de disponibilité que nous avons configuré.
Dans cette dernière étape, donnez un nom au test de disponibilité (par exemple, Test de disponibilité de l'API Inventory), puis vérifiez que le test est correctement configuré. Pour cela, cliquez sur le bouton TESTER.
Poursuivez le processus (cliquez sur le bouton CRÉER à gauche). Google Cloud demandera aux vérifications de disponibilité configurées dans différentes régions d'envoyer un ping à l'URL, et ces réponses seront collectées. Accédez à la section Surveillance → Tests de disponibilité au bout de quelques minutes. Idéalement, vous devriez voir tous les signaux verts indiquant que l'URL était accessible depuis les différentes vérifications.
Si l'une des vérifications échoue pendant une période donnée (qui est configurable), vous recevrez une notification d'alerte sur le canal de messagerie que nous avons configuré.
Ainsi s'achève notre section sur la configuration d'un test de disponibilité. Bravo !
6. Explorateur de métriques
Cloud Monitoring expose des milliers de métriques standards provenant de plusieurs produits Google Cloud. Vous pouvez examiner ces métriques, les interroger, les convertir en graphiques, les ajouter à des tableaux de bord, configurer des alertes, etc.
Dans cette section, nous allons :
- Découvrez comment examiner différentes métriques, puis nous étudierons une métrique spécifique (latence) pour notre service d'API.
- Convertissez cette métrique en graphique et en tableau de bord personnalisé que vous pourrez ensuite utiliser pour la visualiser à tout moment.
Explorer la métrique de latence pour le service de l'API Inventory
Dans le menu principal de la console Google Cloud, accédez à Monitoring → Explorateur de métriques. Vous serez redirigé vers l'écran de l'explorateur de métriques. Cliquez sur SÉLECTIONNER UNE MÉTRIQUE. Vous pouvez désormais parcourir plusieurs ressources actives pour lesquelles des métriques ont été générées.
Comme nous traitons des services Cloud Run, cliquez sur "Révision dans Cloud Run", puis sur la catégorie et la métrique spécifique intitulée Latence des requêtes, comme indiqué ci-dessous :
Cliquez sur Apply (Appliquer). La latence des requêtes s'affiche alors dans un graphique. Vous pouvez modifier le type de widget en graphique en courbes dans les paramètres d'affichage à droite, comme indiqué ci-dessous :
Le graphique de latence s'affiche comme ci-dessous :
Créer un graphique et un tableau de bord personnalisé
Enregistrons ce graphique. Cliquez sur Enregistrer le graphique et utilisez les informations ci-dessous :
N'oubliez pas que nous créons un tableau de bord au lieu de l'enregistrer dans un tableau de bord existant. Cliquez sur le bouton ENREGISTRER. Le tableau de bord que vous venez de créer est ajouté à la liste des tableaux de bord, comme indiqué ci-dessous :
Cliquez sur le tableau de bord que vous avez créé pour afficher les détails.
Cette section sur l'étude de différentes métriques à l'aide de l'explorateur de métriques et sur la création de tableaux de bord personnalisés est maintenant terminée.
7. Cloud Logging
Dans cette section, nous allons explorer Cloud Logging. Cloud Logging est fourni avec une interface Explorateur de journaux qui vous aide à parcourir et à examiner en détail les journaux générés par différents services Google et vos propres applications.
Dans cette section, nous allons découvrir l'explorateur de journaux et simuler quelques messages de journaux que nous pourrons ensuite rechercher et convertir en métriques à l'aide d'une fonctionnalité appelée Métriques basées sur les journaux.
Explorateur de journaux
Vous pouvez accéder à l'explorateur de journaux en cliquant sur Logging → Explorateur de journaux dans la console Google Cloud principale, comme indiqué ci-dessous :
Une interface de journal s'affiche. Elle vous permet de sélectionner/désélectionner spécifiquement différentes ressources (projet, ressource Google Cloud, noms de services, etc.), ainsi que des niveaux de journaux pour filtrer les messages de journaux selon vos besoins.
La liste des journaux de la révision Cloud Run, c'est-à-dire des services Cloud Run que nous avons déployés, est affichée ci-dessus. Vous verrez plusieurs requêtes de vérification du temps d'activité atteindre le point de terminaison /healthy que nous avons configuré.
Rechercher des avertissements
Simulez quelques requêtes non valides au service Inventory en fournissant des ID de produits qui ne sont pas I-1, I-2 et I-3. Par exemple, une requête incorrecte :
https://<SERVICE_URL>/inventory/I-999
Nous allons maintenant rechercher tous les AVERTISSEMENTS générés par notre API lorsqu'un ID de produit incorrect est fourni dans la requête.
Dans la zone de requête, insérez les paramètres de requête suivants :
resource.type="cloud_run_revision"
textPayload =~ "Received inventory request for incorrect productid"
Voici un exemple :
Cliquez sur "Exécuter la requête". Vous verrez alors toutes les demandes reçues qui présentent ce problème.
Métriques basées sur les journaux
Créons une métrique de journal personnalisée pour suivre ces erreurs. Nous aimerions savoir si un nombre important d'appels sont effectués avec des ID de produit incorrects.
Pour convertir la métrique ci-dessus en métrique d'erreur, cliquez sur le bouton Créer une métrique qui s'affiche dans l'explorateur de journaux.
Le formulaire de création de la définition de métrique s'affiche. Choisissez une métrique de type "Compteur", puis saisissez les détails du nom de la métrique (inventory_lookup_errors) et de la description, comme indiqué ci-dessous, puis cliquez sur Créer une métrique.
La métrique de compteur est alors créée. Un message semblable à celui ci-dessous devrait s'afficher :
Accédez à Journalisation → Métriques basées sur les journaux dans le menu principal. La métrique personnalisée que nous avons définie devrait s'afficher dans la liste des métriques définies par l'utilisateur, comme indiqué ci-dessous :
À la fin de cette entrée, vous trouverez trois points verticaux. Cliquez dessus pour afficher les opérations que vous pouvez effectuer sur cette métrique personnalisée. La liste doit être semblable à celle ci-dessous. Cliquez sur l'option Afficher dans l'explorateur de métriques.
Vous devriez être redirigé vers l'explorateur de métriques que nous avons découvert dans la section précédente, sauf qu'il est désormais prérempli.
Cliquez sur Enregistrer le graphique. Utilisez les valeurs suivantes pour les options "Enregistrer le graphique" :
Un tableau de bord est alors créé. Vous pouvez y consulter les erreurs de recherche d'inventaire. Il est disponible dans la liste des tableaux de bord.
Parfait ! Vous avez maintenant créé une métrique personnalisée à partir de vos journaux, que vous avez convertie en graphique dans un tableau de bord personnalisé. Cela nous aidera à suivre le nombre d'appels utilisant des ID de produit incorrects.
8. Règles d'alerte
Dans cette section, nous allons utiliser la métrique personnalisée que nous avons créée et surveiller ses données pour un seuil. Autrement dit, si le nombre d'erreurs dépasse un certain seuil, nous allons générer une alerte. En d'autres termes, nous allons configurer une règle d'alerte.
Créer une règle d'alerte
Accédons au tableau de bord "Recherche dans l'inventaire". Le graphique que nous avons créé pour noter les erreurs de recherche d'inventaire s'affiche, comme indiqué ci-dessous :
Les données de métriques actuelles s'affichent. Commençons par modifier la métrique comme indiqué ci-dessous (cliquez sur le bouton "Modifier") :
Les détails de la métrique s'affichent. Nous allons convertir le graphique pour qu'il affiche la somme (c'est-à-dire le nombre) des erreurs au lieu de leur taux. Le champ à modifier est indiqué ci-dessous :
Cliquez sur APPLIQUER en haut à droite. Vous serez redirigé vers l'écran "Métriques", mais cette fois, vous pourrez voir le nombre total d'erreurs au cours de la période d'alignement par rapport au taux d'erreurs.
Nous allons créer une règle d'alerte qui nous avertira si le nombre d'erreurs dépasse un seuil. Cliquez sur les trois points en haut à droite du graphique, puis sur Convertir en graphique d'alerte dans la liste des options, comme indiqué ci-dessus.
Un écran semblable à celui-ci devrait s'afficher :
Cliquez sur Suivant pour afficher la valeur du seuil que nous pouvons définir. Le seuil d'échantillon que nous avons choisi ici est 5 , mais vous pouvez le modifier selon vos préférences.
Cliquez sur SUIVANT pour afficher le formulaire de notifications.
Nous avons sélectionné le canal de notification comme canal de messagerie que nous avons créé précédemment. Vous pouvez renseigner les autres informations, comme la documentation (qui sera fournie dans l'alerte déclenchée). Cliquez sur SUIVANT pour afficher le récapitulatif et terminer le processus.
Une fois cette règle d'alerte créée, elle s'affiche dans la liste des règles d'alerte, comme indiqué ci-dessous. Pour accéder à la liste des règles d'alerte, accédez à Monitoring → Alertes. Recherchez la section Règles sur la page pour afficher la liste des règles que nous avons configurées jusqu'à présent.
Parfait ! Vous avez configuré une règle d'alerte personnalisée qui vous avertit en cas d'augmentation du taux d'erreurs lors de la recherche dans l'API Inventory.
9. Service Monitoring (facultatif)
Dans cette section, nous allons configurer des SLI/SLO pour nos services conformément aux principes de l'ingénierie de la fiabilité des sites (SRE). Vous remarquerez que Cloud Monitoring vous facilite la tâche en détectant automatiquement les services que vous avez déployés dans Cloud Run. Il peut également calculer automatiquement les principaux SLI (comme la disponibilité et la latence) ainsi que le budget d'erreur.
Nous allons configurer le SLO de latence pour notre service d'API.
Configurer un SLO de latence pour le service d'inventaire
Dans le menu principal de la console Cloud, cliquez sur Monitoring → Services. La liste des services configurés pour le service de surveillance s'affiche.
Actuellement, aucun service n'est configuré pour la surveillance des SLI/SLO. La liste est donc vide. Cliquez sur le lien DÉFINIR LE SERVICE en haut de la page pour définir ou identifier un service.
Les services candidats à la surveillance des SLO seront détectés automatiquement. Il est capable de détecter les services Cloud Run. Par conséquent, notre service d'API Inventory déployé sur Cloud Run sera visible dans la liste.
Le nom à afficher que vous voyez peut être différent et dépend de ce que vous avez choisi lors du déploiement du service sur Cloud Run. Cliquez sur le bouton ENVOYER. L'écran ci-dessous s'affiche :
Vous pouvez cliquer sur CRÉER UN SLO. Vous pourrez alors choisir parmi les indicateurs de niveau de service calculés automatiquement pour vous.
Nous allons commencer par choisir Latence SLI. Cliquez sur CONTINUER. L'écran suivant affiche les performances actuelles de ce service et la latence habituelle.
Nous saisissons une valeur pour le seuil, c'est-à-dire 300 ms, qui correspond à ce que nous voulons atteindre. Vous pouvez choisir une autre valeur si vous le souhaitez, mais n'oubliez pas que cela affectera la marge d'erreur que vous définissez en conséquence. Cliquez sur CONTINUER.
Nous définissons maintenant le SLO (cible et période de mesure) comme indiqué ci-dessous :
Cela signifie que nous sélectionnons la fenêtre de mesure comme fenêtre de type "glissante" et que nous la mesurons sur sept jours. De même, nous avons choisi un objectif de 90 % pour la cible. En d'autres termes, 90 % des requêtes adressées au service d'API doivent être traitées en 300 ms maximum, et ce, sur une période de sept jours.
Cliquez sur Continuer. L'écran récapitulatif s'affiche. Vous pouvez confirmer en cliquant sur le bouton MODIFIER LE SLO.
Votre définition de SLO est enregistrée et la marge d'erreur est calculée automatiquement.
Voici quelques actions possibles à effectuer :
- Exercez l'API via plusieurs appels et observez les performances du service et leur impact sur la marge d'erreur restante.
- Modifiez le code source pour introduire un délai (veille) supplémentaire de manière aléatoire dans certains appels. Cela augmentera la latence pour un certain nombre d'appels et devrait avoir un impact négatif sur la marge d'erreur.
10. Félicitations
Félicitations ! Vous avez déployé un exemple d'application sur Google Cloud et appris à utiliser la suite Google Cloud Operations pour surveiller l'état de l'application.
Points abordés
- Déployer un service sur Google Cloud Run
- Configurer un tableau de bord pour le service Google Cloud Run
- Tests de disponibilité
- Configurer des métriques de journaux personnalisées et un tableau de bord/graphique basé sur celles-ci.
- Explorer l'explorateur de métriques et configurer un tableau de bord/graphique
- Configurer des règles d'alerte
- Configurer les SLI/SLO pour la surveillance des services dans Google Cloud.
Remarque : Si vous avez exécuté l'atelier de programmation avec votre propre compte et projet Google Cloud, les ressources allouées peuvent continuer à générer des frais. Supprimez donc le projet et les ressources une fois l'atelier terminé.
Et ensuite ?
Consultez cette quête Cloud Skills Boost pour en savoir plus sur la suite Google Cloud Operations.