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 sur laquelle vous pouvez surveiller, dépanner et améliorer les performances des applications dans votre environnement Google Cloud. Cloud Monitoring, Cloud Logging et Cloud Tracing sont les principaux piliers de la suite Cloud Operations.
Regardez cette vidéo pour avoir une vue d'ensemble de la suite Google Cloud Operations.
Objectifs de l'atelier
Dans cet atelier de programmation, vous allez déployer un exemple d'API sur Google Cloud. Ensuite, vous explorerez et configurerez plusieurs fonctionnalités de Cloud Monitoring par rapport à l'API.
Points abordés
- Utiliser Cloud Shell de Google Cloud pour déployer un exemple d'application sur Cloud Run
- Utilisation des fonctionnalités de Google Cloud Monitoring telles que les tableaux de bord, les alertes, les tests de disponibilité, la surveillance SLI/SLO et bien plus encore.
Prérequis
- Utiliser une version récente de Chrome (version 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 le nom à afficher pour 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 parmi tous les projets Google Cloud et est immuable (ne peut pas être modifié après avoir été défini). La console Cloud génère automatiquement une chaîne unique. généralement, vous ne vous souciez pas de ce que c’est. Dans la plupart des ateliers de programmation, vous devrez référencer l'ID du projet (il est généralement identifié comme PROJECT_ID). Si l'ID généré ne vous convient pas, vous pouvez en générer un autre au hasard. Vous pouvez également essayer la vôtre pour voir si elle est disponible. Il ne peut pas être modifié après cette étape et restera actif pendant toute la durée du projet.
- Pour votre information, il existe une troisième valeur, un numéro de projet, utilisée par certaines API. Pour en savoir plus sur ces trois valeurs, consultez la documentation.
Attention: Un ID de projet doit être unique et ne peut être utilisé par personne d'autre une fois que vous l'avez sélectionné. Vous en êtes le seul utilisateur. Même si un projet est supprimé, l'ID ne peut plus jamais être 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 arrêter les ressources afin d'éviter que des frais ne vous soient facturés au-delà de ce tutoriel, vous pouvez supprimer les ressources que vous avez créées ou l'ensemble du projet. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai gratuit pour bénéficier d'un crédit de 300 $.
Configuration de Google Cloud Shell
Bien que vous puissiez utiliser Google Cloud et Google Cloud Trace à distance depuis votre ordinateur portable, dans cet atelier de programmation, nous allons utiliser Google Cloud Shell, un environnement de ligne de commande exécuté dans le cloud.
Pour activer Cloud Shell depuis la console Cloud, il vous suffit de cliquer sur "Activer Cloud Shell". Le provisionnement et la connexion à l'environnement ne devraient pas prendre plus de quelques minutes.
Si vous n'avez jamais démarré Cloud Shell auparavant, un écran intermédiaire (en dessous de la ligne de flottaison) vous explique de quoi il s'agit. Dans ce cas, cliquez sur "Continuer". Cette option ne s'affiche plus jamais. 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 que vous pouvez choisir d'utiliser pour cet exercice.
Lien du dépôt Git: https://github.com/rominirani/cloud-code-sample-repository
3. Déployer l'application API
En quoi consiste l'exemple d'application ou d'API ?
Notre application est une application d'API Inventory simple qui expose un point de terminaison d'API REST en quelques opérations pour répertorier les articles en stock et obtenir un nombre spécifique d'articles.
Une fois l'API déployée et en supposant qu'elle est hébergée sur https://<somehost>, nous pouvons accéder aux points de terminaison de l'API comme suit:
- https://<somehost>/inventory
Tous les articles ainsi que les niveaux de stock disponibles s'affichent.
- https://<somehost>/inventory/{productid}
Vous obtiendrez ainsi un enregistrement unique avec l'ID du produit et le niveau d'inventaire disponible pour ce produit.
Les données de réponse renvoyées sont au format JSON.
Échantillon de données et requête/réponse API
Pour simplifier les choses, l'application n'est pas alimentée par une base de données au niveau du backend. Il contient trois exemples d'ID produit et leurs niveaux d'inventaire disponibles.
ID produit | Disponibilité de l'inventaire |
I-1 | 10 |
I-2 | 20 |
I-3 | 30 |
Des exemples de requête et de réponse API sont présentés ci-dessous:
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 nommé cloud-code-sample-repository est 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 via 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 de ce document, Python 3.9.x est installé dans Cloud Shell. Nous utiliserons la version par défaut. Si vous prévoyez de l'exécuter localement sur votre ordinateur portable, vous pouvez opter pour Python 3.8 ou version ultérieure) :
$ python app.py
- Vous pouvez exécuter la commande suivante pour démarrer le serveur Python localement.
- Un serveur est alors démarré sur le port 8080. Vous pouvez le tester en local via la fonctionnalité Aperçu sur le Web de Cloud Shell. Cliquez sur le bouton Aperçu sur le Web comme illustré ci-dessous:
Cliquez sur "Prévisualiser" sur le port 8080.
- Une fenêtre de navigateur s'ouvre. Une erreur 404 s'affiche. Ce n'est pas un problème. Modifiez l'URL et remplacez-la par /inventory après le nom d'hôte.
Par exemple, sur ma machine, 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 API dans Cloud Run. Processus impliquant l'utilisation du client de ligne de commande gcloud pour exécuter la commande permettant de déployer le code sur Cloud Run.
Depuis le terminal, exécutez la commande gcloud suivante:
$ gcloud run deploy --source .
Vous serez invité à répondre à plusieurs questions (si vous êtes invité à donner votre autorisation, veuillez continuer). Certains des points sont mentionnés ci-dessous. Vous recevrez peut-être toutes les questions en fonction de la configuration et selon que vous avez déjà activé des API spécifiques dans votre projet Google Cloud.
- Nom du service (python-flask-api): utilisez cette valeur par défaut ou choisissez un nom du type my-inventory-api.
- API [run.googleapis.com] non activée sur le projet [project-number]. Voulez-vous l'activer et réessayer (cela prendra quelques minutes) ? (y/N)? O
- Veuillez spécifier une région: choisissez la région de votre choix en indiquant un nombre.
- API [artifactregistry.googleapis.com] non activée sur le projet [project-number]. Voulez-vous l'activer et réessayer (cela prendra quelques minutes) ? (y/N)? O
- Le déploiement depuis 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 à [my-inventory-api] (y/N) ? O
À terme, cela lancera le processus consistant à récupérer votre code source, à le conteneuriser, à le transférer vers Artifact Registry, puis à déployer le service et la révision Cloud Run. Soyez patient tout au long de ce processus (cela peut prendre trois à quatre minutes). Le processus devrait se terminer avec l'URL du service qui vous est présentée.
Un exemple d'exécution est présenté ci-dessous:
Tester l'application
Maintenant que nous avons déployé l'application sur Cloud Run, vous pouvez accéder à l'application API comme suit:
- Notez l'URL de service obtenue à l'étape précédente. Par exemple, dans ma configuration, il s'affiche sous la forme
https://my-inventory-api-bt2r5243dq-uw.a.run.app. Appelons-la <SERVICE_URL>. - Ouvrez un navigateur et accédez aux trois URL suivantes pour les points de terminaison de l'API:
- <SERVICE_URL>/inventory
- <URL_SERVICE>/inventory/I-1
- <URL_SERVICE>/inventory/I-100
Elle doit être conforme aux spécifications que nous avions fournies dans une section précédente, avec des exemples de requêtes et de réponses 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 en cours d'exécution dans Cloud Run s'affiche. Le service que vous venez de déployer doit s'afficher. En fonction du nom que vous avez sélectionné, un message semblable au suivant doit s'afficher:
Cliquez sur le nom du service pour afficher les détails. Des exemples de détails sont présentés ci-dessous:
Notez l'URL, qui n'est rien d'autre que l'URL du service que vous pouvez insérer dans le navigateur et accéder à l'API Inventory que nous venons de déployer. N'hésitez pas à consulter les métriques et d'autres détails.
Nous allons commencer à utiliser la suite Google Cloud Operations.
4. Configurer un tableau de bord
L'une des fonctionnalités pratiques proposées par Cloud Monitoring concerne les tableaux de bord prêts à l'emploi pour plusieurs ressources Google Cloud. Cela rend la configuration initiale de tableaux de bord avec des métriques standard, un processus 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
Maintenant que nous avons déployé notre service d'API dans Cloud Run, voyons comment configurer des tableaux de bord permettant de visualiser diverses métriques, dont certaines incluent la latence du service.
Tout d'abord, depuis la console, accédez à Monitoring → Overview (Surveillance → Présentation), comme indiqué ci-dessous:
La vue d'ensemble présente plusieurs éléments que vous auriez 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 latéral. L'écran suivant s'affiche:
Cliquez sur EXEMPLE DE BIBLIOTHÈQUE . La liste des tableaux de bord prêts à l'emploi disponibles dans Google Cloud pour plusieurs ressources s'affiche. Plus précisément, faites défiler la liste vers le bas et sélectionnez Google Cloud Run, comme indiqué ci-dessous.
La 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.
Vous ne verrez qu'un seul tableau de bord pour la surveillance Cloud Run. Cliquez sur le lien APERÇU pour afficher la liste des graphiques (métriques) standards disponibles pour la surveillance Cloud Run. Il suffit de cliquer sur IMPORTER UN EXEMPLE DE TABLEAU DE BORD pour importer tous ces graphiques dans un tableau de bord personnalisé. Un écran "Tableau de bord" s'affiche. Il a un nom prérempli, comme illustré ci-dessous:
Vous pouvez revenir en arrière en cliquant sur la flèche vers la gauche , située à gauche du nom du tableau de bord, à droite en haut à gauche. Vous accédez ainsi à la liste des tableaux de bord, à partir de laquelle vous devriez être en mesure de voir le nouveau tableau de bord que vous venez de créer.
Cliquez sur le lien "Tableau de bord" pour surveiller plusieurs métriques prêtes à l'emploi. Ces métriques incluent la latence, le nombre de requêtes, les métriques du conteneur, etc.
Vous pouvez également choisir un tableau de bord comme favori, en sélectionnant simplement l'icône en forme d'étoile, comme illustré ci-dessous:
Le tableau de bord sera ajouté à l'écran "Overview" (Aperçu) de Monitoring et vous permettra d'accéder facilement aux tableaux de bord fréquemment utilisés.
Fantastique ! Vous venez d'ajouter un tableau de bord personnalisé pour surveiller vos services Cloud Run. Bien joué !
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 à travers le monde vers des URL publiques ou des ressources Google Cloud pour voir si la ressource répond.
Dans ce cas, la ressource est le service d'API que nous avons déployé dans 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 de service de l'API, nous avons exposé un point de terminaison /healthy qui renvoie la valeur de chaîne "All Izz Well". Il nous suffit donc de définir un test de disponibilité qui appelle https://<SERVICE_URL>/healthy et qui vérifie si la chaîne https://<SERVICE_URL>/healthy est renvoyée ou non.
Créer un canal de notification
Avant de créer le test de disponibilité, il est important de configurer les canaux de notification. Un canal de notification est un support par lequel vous serez averti en cas d'incident ou de problème avec l'une de nos ressources surveillées. Par exemple, l'e-mail est un canal de notification qui vous permet de recevoir des e-mails en cas d'alerte, etc.
Pour le moment, nous allons configurer un canal de notification par e-mail et le configurer avec notre adresse e-mail, afin d'être averti de toute alerte générée par notre système et que nous allons configurer.
Pour créer un canal de notification, procédez comme suit:
Accédez à Monitoring → Alertes depuis 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 le moment, un lien intitulé MODIFIER LES CHAÎNES DE NOTIFICATION s'affiche en haut de l'écran. Cliquez dessus.
La liste des différents canaux de notification s'affiche, comme illustré ci-dessous:
Recherchez la section Adresse e-mail et cliquez sur le bouton AJOUTER associé à cette ligne. Les détails de la configuration de messagerie s'affichent, comme illustré ci-dessous:
Saisissez votre adresse e-mail et un nom à afficher comme indiqué ci-dessous. Cliquez sur ENREGISTRER.
Le canal de notification par e-mail est désormais créé. Configurons maintenant le test de disponibilité.
Créer un test de disponibilité
Accédez à Monitoring → Tests de disponibilité dans le menu principal de la console Google Cloud. Le lien CRÉER UN TEST DE DISPONIBILITÉ apparaît en haut de l'écran. Cliquez dessus.
Une série d'étapes s'affiche pour vous permettre de 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 nous avons déployé. Voici un formulaire rempli:
Vous pouvez sélectionner les différentes valeurs comme suit:
- Protocole : HTTPS
- Resource Type (Type de ressource) : sélectionnez le service Cloud Run. Notez les autres ressources compatibles et que vous pouvez également définir des tests de disponibilité sur celles-ci.
- Service Cloud Run : sélectionnez my-inventory-api ou le nom spécifique du service Cloud Run.
- Le chemin d'accès est /healthy, car nous renvoyons une chaîne "All Izz Well" et nous voulons vérifier cela.
Cliquez sur CONTINUER pour passer à l'étape suivante. L'étape suivante est l'étape de validation de la réponse, comme indiqué ci-dessous:
Comme vous pouvez le voir, nous activons la vérification de "Correspondance de contenu" et en configurant que la réponse renvoyée par le point de terminaison /healthy sera "All Izz Well". Cliquez sur CONTINUER pour passer à l'étape suivante, où nous allons configurer l'alerte et choisir le canal de notification sur lequel nous devons être avertis en cas d'échec du test de disponibilité.
Au cours de cette étape, attribuez un nom à l'alerte. Je l'ai choisi en tant qu'échec du test de disponibilité de l'API Inventory, mais vous pouvez choisir votre nom. L'important ici est de sélectionner le canal de notification approprié dans la liste que vous avez configurée précédemment.
Enfin, cliquez sur EXAMINER pour examiner le test de disponibilité que nous avons configuré.
Au cours de cette dernière étape, attribuez un nom au test de disponibilité (par exemple, Inventory API Uptime Check). Vous pourrez ensuite vérifier qu'il est correctement configuré. Pour cela, cliquez sur le bouton TEST.
Terminez le processus (cliquez sur le bouton CRÉER à gauche). Google Cloud demandera aux vérifications de tests de disponibilité configurées dans différentes régions de pinguer l'URL. Ces réponses seront collectées. Après quelques minutes, accédez à la section Surveillance → Tests de disponibilité. Dans l'idéal, tous les signaux verts indiquant que l'URL est accessible depuis les différentes vérifications doivent apparaître.
Si l'une des vérifications échoue pendant un certain temps (configurable), vous recevrez une notification d'alerte sur le canal de messagerie que nous avons configuré.
Nous arrivons à la fin de notre section sur la configuration d'un test de disponibilité. Bien joué !
6. Explorateur de métriques
Cloud Monitoring expose des milliers de métriques standards issues de plusieurs produits Google Cloud. Vous pouvez examiner ces métriques, les interroger, les convertir en graphiques, les ajouter aux tableaux de bord, générer des alertes et plus encore.
Notre objectif dans cette section est le suivant:
- Découvrez comment analyser différentes métriques, puis nous étudierons une métrique spécifique (latence) pour notre service d'API.
- Convertissez cette métrique en un graphique et en un tableau de bord personnalisé que nous pouvons ensuite utiliser pour visualiser la métrique à tout moment.
Explorer les métriques de latence du service de l'API Inventory
Accédez à Monitoring → Explorateur de métriques depuis le menu principal de la console Google Cloud. L'écran de l'Explorateur de métriques s'affiche. Cliquez sur SÉLECTIONNER UNE MÉTRIQUE. Vous pouvez désormais parcourir plusieurs ressources actives ayant des métriques générées.
Puisque nous traitons les 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 dans un graphique. Vous pouvez remplacer le type de widget par un graphique en courbes dans les paramètres d'affichage à droite, comme illustré ci-dessous:
Le graphique de latence s'affiche comme suit:
Créer un graphique et un tableau de bord personnalisé
Enregistrons ce graphique. Cliquez sur Save Chart (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 nouvellement créé sera ajouté à notre liste de tableaux de bord, comme indiqué ci-dessous:
Cliquez sur le tableau de bord que nous avons créé pour afficher les détails.
Ainsi s'achève la section sur l'analyse de différentes métriques via l'Explorateur de métriques et sur la création de tableaux de bord personnalisés.
7. Cloud Logging
Dans cette section, nous allons explorer Cloud Logging. Cloud Logging est doté d'une interface Explorateur de journaux qui vous permet de parcourir et d'explorer les journaux générés par divers services Google et vos propres applications.
Dans cette section, nous allons découvrir l'explorateur de journaux et simuler quelques messages de journal que nous pourrons ensuite rechercher et convertir en métriques, grâce à une fonctionnalité appelée métriques basées sur les journaux.
Explorateur de journaux
Vous pouvez accéder à l'explorateur de journaux via Logging → Explorateur de journaux à partir de la console Google Cloud principale, comme indiqué ci-dessous:
Une interface de journal s'affiche, dans laquelle vous pouvez sélectionner/désélectionner différentes ressources (projet, ressource Google Cloud, noms de service, etc.) ainsi que des niveaux de journalisation pour filtrer les messages de journal selon vos besoins.
Vous trouverez ci-dessus la liste des journaux de la révision Cloud Run, c'est-à-dire des services Cloud Run que nous avons déployés. Vous verrez plusieurs requêtes qui sont des tests de disponibilité atteignant le point de terminaison /healthy que nous avons configuré.
Rechercher des avertissements
Simulez quelques requêtes non valides envoyées au service Inventory en fournissant des ID produit autres que I-1, I-2 ou I-3. Par exemple, une requête incorrecte est:
https://<SERVICE_URL>/inventory/I-999
Nous allons maintenant rechercher tous les avertissements générés par notre API, lorsqu'un identifiant 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 =~ "Demande d'inventaire reçue pour un ID de produit incorrect"
Voici un exemple :
Cliquez sur "Exécuter la requête". Toutes les requêtes qui sont arrivées et qui présentent ce problème s'affichent alors.
Métriques basées sur les journaux
Nous allons maintenant créer une métrique de journal personnalisée pour suivre ces erreurs. Nous aimerions savoir si un grand nombre d'appels sont passés avec des ID produit incorrects.
Pour convertir la métrique ci-dessus en métrique d'erreur, cliquez sur le bouton Create Metric (Créer une métrique) qui apparaît dans l'explorateur de journaux.
Le formulaire permettant de créer la définition de la métrique s'affiche. Choisissez une métrique de compteur, puis saisissez les détails relatifs au nom de la métrique (inventory_lookup_errors) et à la description (comme indiqué ci-dessous), puis cliquez sur Create Metric (Créer une métrique).
La métrique de compteur est alors créée. Le message ci-dessous doit s'afficher:
Accédez à Logging → Métriques basées sur les journaux dans le menu principal. Vous devriez voir la métrique personnalisée que nous avons définie 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 devrait être semblable à celle que vous voyez 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 vu dans la section précédente, mais il est désormais prérempli.
Cliquez sur Enregistrer le graphique. Utilisez les valeurs suivantes pour les options "Enregistrer le graphique" :
Cette opération va créer un tableau de bord dans lequel vous pouvez voir les erreurs de recherche d'inventaire. Ce tableau de bord sera disponible dans la liste des tableaux de bord.
Parfait ! Vous venez de créer une métrique personnalisée à partir de vos journaux et de la convertir en graphique qui se trouve dans un tableau de bord personnalisé. Cela nous permettra de 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 en fonction d'un seuil. Par exemple, si le nombre d'erreurs dépasse un certain seuil, nous déclencherons une alerte. En d'autres termes, nous allons créer une règle d'alerte.
Créer une règle d'alerte
Accédons au tableau de bord de recherche d'inventaire. Le graphique que nous avons créé pour noter les erreurs de recherche d'inventaire s'affiche, comme illustré 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 nous indique le taux d'erreurs en une somme, c'est-à-dire le nombre d'erreurs. Le champ à modifier est illustré ci-dessous:
Cliquez sur APPLIQUER en haut à droite pour revenir à l'écran "Métriques", mais cette fois, nous pouvons voir le nombre total d'erreurs pendant la période d'alignement par rapport au taux d'erreurs.
Nous allons créer une règle d'alerte qui pourra nous avertir si le nombre d'erreurs dépasse un certain seuil. Cliquez sur les trois points en haut à droite du graphique. Dans la liste des options, comme indiqué ci-dessus, cliquez sur Convert to alert chart (Convertir en graphique d'alerte).
L'écran ci-dessous doit s'afficher:
Cliquez sur Next (Suivant). Vous pouvez alors définir une valeur de seuil. L'échantillon de seuils que nous avons pris ici est de 5 , mais vous pouvez choisir celui que vous préférez.
Cliquez sur SUIVANT pour afficher le formulaire de notification.
Nous avons sélectionné le canal de notification comme canal de messagerie que nous avons créé précédemment. Vous pouvez remplir d'autres détails comme la documentation (qui sera fournie dans le cadre de l'alerte générée). Cliquez sur SUIVANT pour afficher le récapitulatif et terminer le processus.
Une fois que vous aurez créé cette règle d'alerte, elle sera visible dans la liste des règles d'alerte, comme indiqué ci-dessous. Pour accéder à la liste des règles d'alerte, sélectionnez Monitoring → Alertes. Recherchez la section Policies (Règles) de la page pour voir la liste des règles que nous avons configurées jusqu'à présent.
Parfait ! Vous avez désormais configuré une règle d'alerte personnalisée qui vous informera en cas d'augmentation du taux d'erreurs lors de la recherche de l'API Inventory.
9. Service Monitoring (facultatif)
Dans cette section, nous allons configurer des SLI/SLO pour nos services, conformément aux principes d'ingénierie de la fiabilité des sites (SRE). Vous remarquerez que Cloud Monitoring vous facilite la tâche en identifiant automatiquement les services que vous avez déployés dans Cloud Run et qu'il peut calculer automatiquement pour vous des SLI clés tels que la disponibilité et la latence, ainsi que des calculs de marge d'erreur.
Configurons le SLO de latence pour notre service d'API.
Configurer un SLO de latence pour le service d'inventaire
Cliquez sur Monitoring → Services dans le menu principal de Cloud Console. La liste des services configurés pour Service Monitoring s'affiche.
Aucun service n'a été configuré pour la surveillance des SLI/SLO à l'heure actuelle. La liste est donc vide. Cliquez sur le lien DÉFINIR LE SERVICE en haut de la page pour définir / identifier un service.
Cette opération va détecter automatiquement les services pouvant bénéficier de la surveillance des SLO. Il est capable de découvrir les services Cloud Run. Par conséquent, le 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 pouvez maintenant sélectionner les SLI qui sont calculés automatiquement pour vous.
Pour commencer, nous choisissons le SLI de latence. Cliquez sur CONTINUER. Un écran vous indique les performances actuelles de ce service et la latence habituelle.
Nous avons saisi une valeur pour le seuil, c'est-à-dire 300 ms , ce que nous souhaitons atteindre. Si vous le souhaitez, vous pouvez choisir une autre valeur, mais gardez à l'esprit que cela aura une incidence sur la marge d'erreur que vous définissez en conséquence. Cliquez sur CONTINUER.
Nous définissons maintenant le SLO (période cible et de mesure) comme indiqué ci-dessous:
Cela signifie que nous sélectionnons la période de mesure glissante et que nous la mesurons sur sept jours. De même, pour la cible, nous avons choisi un objectif de 90%. Ce que nous essayons de dire ici, c'est que 90% des requêtes adressées au service d'API doivent être effectuées en 300 ms, ce qui doit être mesuré sur sept jours.
Cliquez sur Continuer. Un écran récapitulatif s'affiche. Vous pouvez le vérifier en cliquant sur le bouton METTRE À JOUR LE SLO.
La définition de votre SLO est alors enregistrée, et la marge d'erreur est calculée automatiquement.
Voici ce que vous pouvez faire:
- Testez l'API via plusieurs appels, et observez les performances du service et son impact sur la marge d'erreur restante.
- Modifier le code source pour introduire un délai supplémentaire (veille) de manière aléatoire dans certains appels Cela augmentera la latence pour un certain nombre d'appels et devrait avoir une incidence négative sur la marge d'erreur.
10. Félicitations
Félicitations ! Vous avez déployé un exemple d'application dans Google Cloud et appris à surveiller l'état de l'application à l'aide de la suite Google Cloud Operations.
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 ces métriques
- Explorer l'explorateur de métriques et configurer un tableau de bord/graphique
- Configurer des règles d'alerte.
- Configurer un SLI/SLO pour la surveillance des services dans Google Cloud
Remarque:Si vous avez exécuté l'atelier de programmation en utilisant votre propre compte et votre projet Google Cloud, les ressources allouées peuvent continuer à être facturées. Supprimez donc le projet et les ressources une fois l'atelier terminé.
Et ensuite ?
Découvrez cette quête Cloud Skills Boost pour en savoir plus sur la suite Google Cloud Operations.