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. Cloud Monitoring, Cloud Logging et Cloud Tracing sont les principaux piliers de la suite Cloud Operations.
Regardez cette vidéo pour obtenir une présentation générale 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 allez ensuite explorer et configurer 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 vérifications 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 de 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 (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 gratuit 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 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 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'affiche 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 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 de l'API
De quoi s'agit-il dans l'exemple d'application ou d'API ?
Notre application est une application API d'inventaire simple 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 de l'inventaire.
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 de votre inventaire seront listés, avec les niveaux d'inventaire disponibles.
- 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.
Exemples de données et de requêtes/réponses d'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 produit et leurs niveaux d'inventaire en stock.
ID produit | Niveau de l'inventaire en stock |
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 votre ID de 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 dans Cloud Shell
Pour exécuter l'application en local, procédez comme suit:
- Dans 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, exécutez la commande suivante (au moment de la rédaction, Cloud Shell est fourni avec Python 3.9.x installé et 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 en local.
- 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 "Preview on port 8080" (Aperçu sur le port 8080).
- Une fenêtre de navigateur s'ouvre. Une erreur 404 s'affiche, ce qui est normal. Modifiez l'URL en remplaçant /inventory par /inventory après le nom d'hôte.
Par exemple, sur mon ordinateur, cela se présente comme suit:
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 dans Cloud Run. Le processus a consisté à utiliser le client de ligne de commande gcloud pour exécuter la commande permettant de déployer le code dans Cloud Run.
Depuis le terminal, exécutez la commande gcloud suivante:
$ gcloud run deploy --source .
Vous serez alors invité à répondre à plusieurs questions (si vous êtes invité à autoriser l'accès, veuillez le faire). Certains points sont mentionnés ci-dessous. Vous pouvez ne pas recevoir 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): utilisez cette valeur par défaut ou choisissez un nom du type my-inventory-api.
- API [run.googleapis.com] not enabled on project [project-number]. Would you like to enable and retry (this will take a few 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]. Would you like to enable and retry (this will take a few 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 à [my-inventory-api] (O/N) ? O
Le processus démarrera alors pour récupérer votre code source, le conteneuriser, le transférer vers Artifact Registry, puis déployer le service Cloud Run et la révision. Soyez patient pendant ce processus (il peut prendre trois à quatre minutes). Vous devriez voir le processus se terminer et l'URL du service s'afficher.
Un exemple d'exécution est présenté ci-dessous:
Tester l'application
Maintenant que nous avons déployé l'application dans Cloud Run, vous pouvez y accéder comme suit:
- Notez l'URL du service de 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-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 respecter les 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. 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. Les détails de l'exemple 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 informations.
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 sur 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
Comme nous avons déployé notre service d'API sur Cloud Run, voyons comment configurer des tableaux de bord qui peuvent aider à visualiser diverses métriques, dont certaines incluent la latence du service.
Dans la console, accédez à Monitoring → Overview (Surveillance → Aperçu), 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, cliquez sur Tableaux de bord dans le menu principal latéral. L'écran suivant s'affiche:
Cliquez sur SAMPLE LIBRARY (BIBLIOTHÈQUE D'EXEMPLES). 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 alors. Cela nous intéresse, car nous avons déployé notre service sur Cloud Run.
Un tableau de bord s'affiche pour la surveillance de Cloud Run. Cliquez sur le lien APERÇU pour afficher la liste des graphiques (métriques) standards 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é. Un écran de tableau de bord s'affiche, avec un nom prérempli, comme illustré ci-dessous:
Pour revenir en arrière , cliquez sur la flèche vers la gauche située à gauche du nom du tableau de bord, en haut à gauche. Vous accéderez alors à la liste des tableaux de bord, parmi lesquels vous devriez voir le nouveau tableau de bord que vous venez de créer.
Cliquez sur ce lien pour accéder au tableau de bord et surveiller plusieurs métriques disponibles par défaut. Ces métriques incluent la latence, le nombre de requêtes, les métriques du conteneur, etc.
Vous pouvez également ajouter un tableau de bord à vos favoris en sélectionnant simplement l'icône en forme d'étoile, comme illustré ci-dessous:
Le tableau de bord est alors ajouté à l'écran "Vue d'ensemble" de la surveillance. Vous pouvez ainsi accéder facilement aux tableaux de bord fréquemment utilisés.
Parfait ! 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 entier vers des URL ou des ressources Google Cloud accessibles au public 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 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 une vérification de l'état qui accède à une URL telle que 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 êtes 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 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'alertes émises 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 CANAUX DE NOTIFI cations s'affiche en haut de la page. Cliquez dessus.
La liste des différents canaux de notification s'affiche, comme illustré ci-dessous:
Recherchez la section Adresse e-mail, puis cliquez sur AJOUTER sur 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.
La création du canal de notification par e-mail est terminée. Voyons maintenant comment configurer le test de disponibilité.
Créer un test de disponibilité
Accédez à Monitoring → Vérifications de l'état de disponibilité dans le menu principal de la console Google Cloud. En haut de la page, vous trouverez le lien CRÉER UN TEST DE DISPONIBILITÉ. Cliquez dessus.
Une série d'étapes s'affiche, que vous devrez 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 nous avons déployé. Un formulaire rempli est présenté ci-dessous:
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 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 vérifier cela.
Cliquez sur CONTINUER pour passer à l'étape suivante. L'étape suivante est la validation de la réponse, comme illustré ci-dessous:
Vous pouvez constater que nous activons la vérification de la "correspondance de contenu" et que nous configurons ensuite que la réponse renvoyée par le point de terminaison /healthy sera "All Izz Well" ( puits de connexion). Cliquez sur CONTINUER pour passer à l'étape suivante, où nous allons configurer l'alerte et le canal de notification sur lequel nous devons être alertés en cas d'échec du test de disponibilité.
À cette étape, attribuez un nom à l'alerte. J'ai choisi Échec de la vérification de la disponibilité de l'API Inventory, mais vous pouvez choisir votre propre nom. L'essentiel est de sélectionner le bon canal de notification dans la liste que vous avez configurée précédemment.
Pour terminer, cliquez sur EXAMINER afin de 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). Vous pouvez ensuite vérifier si le test est correctement configuré. Pour ce faire, cliquez sur le bouton TEST.
Poursuivez la procédure (cliquez sur le bouton CREATE (CRÉER) à gauche). Google Cloud demandera aux sondes de vérification de l'état de fonctionnement configurées dans différentes régions d'envoyer un ping à l'URL. Les réponses seront collectées. Accédez à la section Surveillance → Vérifications de la disponibilité après quelques minutes. Vous devriez idéalement voir tous les signaux verts indiquant que l'URL était accessible depuis les différentes sondes.
Si l'une des sondes échoue pendant une période donnée (configurable), vous recevrez une notification d'alerte sur le canal d'e-mail que nous avons configuré.
Vous avez terminé cette section sur la configuration d'un test de disponibilité. Bravo !
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 examiner différentes métriques, puis nous allons examiner 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 utiliser pour la visualiser à tout moment.
Explorer la métrique de latence pour le service de l'API Inventory
Accédez à Monitoring → Explorateur de métriques dans le menu principal de la console Google Cloud. Vous êtes alors redirigé vers l'écran "Explorateur de métriques". Cliquez sur SÉLECTIONNER UNE MÉTRIQUE. Vous pouvez désormais parcourir plusieurs ressources actives ayant des métriques générées.
Comme nous traitons de services Cloud Run, cliquez sur "Révision dans Cloud Run", puis sur la catégorie et la métrique spécifique intitulée Latence de la requête, comme indiqué ci-dessous:
Cliquez sur Apply (Appliquer). La latence des requêtes s'affiche alors 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 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 nouveau tableau de bord , et non que nous l'enregistrons dans un tableau de bord existant. Cliquez sur le bouton ENREGISTRER. Le nouveau tableau de bord est alors ajouté à la liste, comme illustré ci-dessous:
Cliquez sur le tableau de bord spécifique que nous avons créé pour afficher les détails.
Nous terminons ainsi la section sur l'exploration de diverses 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 découvrir Cloud Logging. Cloud Logging est fourni avec une interface d'explorateur de journaux qui vous aide à parcourir et à examiner les journaux générés par divers services Google et vos propres applications.
Dans cette section, vous allez découvrir l'explorateur de journaux et simuler quelques messages de journal que vous pourrez 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 via Journalisation → Explorateur de journaux dans la console Google Cloud principale, comme illustré ci-dessous:
Une interface de journal s'affiche, dans laquelle vous pouvez sélectionner/désélectionner spécifiquement différentes ressources (projet, ressource Google Cloud, noms de services, etc.) ainsi que des niveaux de journalisation pour filtrer les messages de journal selon vos besoins.
La liste des journaux de la révision Cloud Run (services Cloud Run que nous avons déployés) est affichée ci-dessus. Vous verrez plusieurs requêtes de vérification de l'état de fonctionnement qui accèdent au 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 produit qui ne correspondent pas à I-1, I-2 et I-3. Par exemple, une requête incorrecte est la suivante:
https://<SERVICE_URL>/inventory/I-999
Nous rechercherons désormais 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". 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
Créons 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 Créer une métrique 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 le nom de la métrique (inventory_lookup_errors) et la description, comme indiqué ci-dessous. Cliquez ensuite sur Créer une métrique.
La métrique de compteur est alors créée. Le message ci-dessous doit s'afficher:
Accédez à Logging → Logs-based Metrics (Journalisation → 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 d'enregistrement du graphique:
Un nouveau tableau de bord s'affichera, dans lequel vous pourrez voir les erreurs de recherche d'inventaire. Il sera disponible dans la liste des tableaux de bord.
Parfait ! Vous avez maintenant créé une métrique personnalisée à partir de vos journaux, puis converti cette métrique en graphique dans un tableau de bord personnalisé. Cela nous aidera à suivre le nombre d'appels utilisant des identifiants 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 déclencherons 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 de 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 le taux d'erreurs au lieu de la 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 peut nous avertir si le nombre d'erreurs dépasse un seuil. Cliquez sur les trois points en haut à droite du graphique, puis dans la liste des options, comme indiqué ci-dessus, cliquez sur 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. Nous avons choisi un seuil d'5 pour cet exemple , mais vous pouvez choisir celui qui vous convient le mieux.
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 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 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, accédez à Surveillance → 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 maintenant configuré une règle d'alerte personnalisée qui vous avertira en cas d'augmentation du taux d'erreurs lors de la recherche dans l'API Inventory.
9. Surveillance des services (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 détectant automatiquement les services que vous avez déployés dans Cloud Run. Il peut également calculer automatiquement les SLI clés, comme la disponibilité et la latence, ainsi que les calculs du budget d'erreur.
Passons à la configuration du SLO de latence pour notre service d'API.
Configurer un SLO de latence pour le service d'inventaire
Dans le menu principal de Cloud Console, cliquez sur Surveillance → Services. La liste des services configurés pour la surveillance des services s'affiche.
Actuellement, aucun service n'a été 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 / identifier un service.
Les services candidats à la surveillance des SLO sont alors détectés automatiquement. 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 peut être différent et dépend de ce que vous avez choisi au moment 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.
Nous commençons par choisir SLI de latence. Cliquez sur CONTINUER. Un écran s'affiche ensuite, qui présente les performances actuelles de ce service et la latence typique.
Nous avons saisi une valeur pour le seuil, c'est-à-dire 300 ms , ce que nous souhaitons atteindre. Vous pouvez choisir une autre valeur si vous le souhaitez, mais gardez à l'esprit qu'elle aura un impact sur la marge d'erreur que vous définirez en conséquence. Cliquez sur CONTINUER.
Nous définissons maintenant l'objectif de niveau de service (cible et période d'évaluation) 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, nous avons choisi un objectif de 90 % pour la cible. Ce que nous essayons de dire ici, c'est que 90% des requêtes adressées au service d'API doivent être traitées sous 300 ms, et ce sur une période de sept jours.
Cliquez sur Continuer. L'écran récapitulatif s'affiche. Vous pouvez le confirmer en cliquant sur le bouton METTRE À JOUR LE SLO.
Vous pouvez ainsi enregistrer la définition de votre SLO, et la marge d'erreur est calculée automatiquement.
Voici quelques suggestions:
- Exécutez l'API via plusieurs appels et examinez les performances du service et son impact sur le budget d'erreur restant.
- Modifiez le code source pour ajouter un délai supplémentaire (en veille) 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 le budget d'erreurs.
10. Félicitations
Félicitations, vous avez réussi à déployer un exemple d'application sur Google Cloud et vous avez 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 ces métriques
- Explorer l'explorateur de métriques et configurer un tableau de bord/un graphique
- Configurer des règles d'alerte
- Configurer des SLI/SLO pour la surveillance des services dans Google Cloud
Remarque:Si vous avez exécuté l'atelier de programmation à l'aide de votre propre compte et de votre propre projet Google Cloud, des frais de facturation peuvent toujours être facturés pour les ressources alloué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.