Créer une surveillance synthétique

Ce document explique comment créer des moniteurs synthétiques pour tester la disponibilité, la cohérence et les performances de vos services, applications, pages Web et API. Vous fournissez des tests pour votre application. La surveillance synthétique exécute ce script et enregistre les résultats des tests. des données supplémentaires telles que la latence. Pour recevoir une notification lorsque un test échoue, vous pouvez configurer une règle d'alerte pour surveiller les résultats du test.

À propos de la surveillance synthétique

Un moniteur synthétique exécute régulièrement une fonction Cloud Run de 2e génération à usage unique déployée sur Cloud Run. Lorsque vous créez le moniteur synthétique, vous définissez la fonction Cloud Run, qui doit être écrite en Node.js, et la fréquence d'exécution. Par exemple, vous pouvez configurer votre fonction Cloud Run pour qu'elle interagit associée à une page Web à l'aide de Puppeteer. Vous pouvez également configurer votre fonction Cloud Run pour qu'elle interagisse avec une API à l'aide du module Axios. Vous pouvez également tester les ressources d'un réseau VPC.

Pour créer votre fonction Cloud Run, vous pouvez utiliser un éditeur intégré ou importer un fichier ZIP. Si vous choisissez d'utiliser l'éditeur intégré, vous pouvez commencer avec un squelette fourni. Une fois que vous avez créé un moniteur synthétique, Cloud Monitoring utilise un système de planification qui planifie l'exécution périodique de votre fonction Cloud Run. Pendant que vous spécifier la région dans laquelle votre fonction Cloud Run existe, les commandes que l'exécution peut provenir de n'importe quelle région prise en charge par le de tests de disponibilité. Pour en savoir plus, consultez la section Lister les adresses IP des serveurs de vérification de la disponibilité.

Vous pouvez créer une règle d'alerte afin d'être averti en cas de échecs des tests:

• Lorsque vous créez un moniteur synthétique à l'aide de la console Google Cloud, le comportement par défaut consiste à créer une règle d'alerte. Vous fournissez les canaux de notification. La règle d'alerte par défaut est configurée vous avertir lorsque deux échecs de test consécutifs ou plus se produisent.

• Lorsque vous créez un moniteur synthétique à l'aide de l'API Cloud Monitoring, vous devez créer la règle d'alerte pour surveiller le type de métrique uptime_check/check_passed pour la ressource Cloud Run sur laquelle la fonction Cloud Run s'exécute.

Considérations relatives à la fréquence d'exécution

Vous configurez la fréquence d'exécution de votre fonction Cloud Run. À la fréquence des exécutions, objectif de niveau de service (SLO) de votre service. Pour détecter les éventuelles violations des SLO, vous devez exécuter les tests fréquemment. Cependant, le SLO de votre service n'est pas le seul élément à prendre en compte. Vous devez également tenir compte de la manière dont le taux d'exécutions se traduit en charge sur à votre service et à vos coûts. Chaque exécution apporte une charge au service, Ainsi, plus votre fonction Cloud Run est exécutée fréquemment, plus la charge appliquée à votre service est importante. À titre indicatif, l'intervalle d'exécution par défaut des tests de disponibilité est d'une minute.

La fréquence d'exécution détermine également la vitesse à laquelle vous pouvez être averti votre test échoue. Monitoring ouvre un incident et envoie une notification après le deuxième échec consécutif d'un test. Par exemple : si la fréquence d'exécution est de 5 minutes, deux tests ont échoué. Vous recevrez une notification après l'échec du deuxième test.

Exemple de code de la fonction Cloud Run

Pour obtenir des modèles et des exemples, consultez Exemples pour la surveillance synthétique. Vous pouvez utiliser ces exemples comme point de départ pour votre fonction Cloud Run. Si vous êtes un développeur expérimenté, envisagez Utiliser Gemini pour générer du code pour la surveillance synthétique et ainsi réduire le temps de développement. L'utilisation de Gemini pour générer du code est en version Preview publique.

Le modèle générique, que vous pouvez sélectionner lorsque vous créez un moniteur synthétique à l'aide de la console Google Cloud, est configuré pour collecter des données de trace et de journalisation pour les requêtes HTTP sortantes. La solution s'appuie sur le module auto-instrumentation-node d'OpenTelemetry et le journal Winston. En raison de la dépendance aux produits Open Source, vous devez vous attendre à des changements la structure des données de trace et de journal. Par conséquent, les données de trace et les données des journaux ne doivent être utilisées qu'à des fins de débogage.

Vous pouvez implémenter votre propre approche pour collecter des données de trace et de journalisation pour les requêtes HTTP sortantes. Pour obtenir un exemple d'approche personnalisée, consultez la classe SyntheticAutoInstrumentation.

Configuration des fonctions Cloud Run

Lorsque vous configurez votre fonction Cloud Run, vous devez spécifier l'environnement d'exécution, la compilation, les connexions et les paramètres de sécurité, ou accepter les paramètres par défaut :

• La valeur par défaut de la mémoire allouée peut ne pas être suffisante. Mer nous vous recommandons de définir ce champ sur une valeur d'au moins 2 Gio.

• La valeur par défaut des paramètres de transfert de données entrantes de votre la fonction Cloud Run consiste à autoriser tout le trafic. Vous pouvez utiliser ce paramètre ou un paramètre plus restrictif.

  Lorsque vous autorisez tout le trafic, la première phase de validation effectuée par les fonctions Cloud Run, qui se fait au niveau du réseau, passe toujours. La deuxième phase de validation détermine si l'appelant a été autorisé à exécuter la fonction Cloud Run. L'autorisation dépend du rôle IAM (Identity and Access Management) de l'appelant. Par défaut, Cloud Monitoring est autorisé à exécuter vos fonction Cloud Run. Pour savoir comment afficher ou modifier les paramètres de transfert de données entrants, consultez la section Paramètres d'entrée.

Restrictions des fonctions Cloud Run

• Le nom de votre fonction Cloud Run ne doit pas contenir de trait de soulignement.

• Vous ne pouvez collecter des données de trace et de journal pour les requêtes HTTP sortantes que lorsque vous utilisez le modèle générique.

• Seules les fonctions HTTP sont acceptées. Si vous utilisez la console Google Cloud pour créer votre moniteur synthétique, vous disposez d'une fonction par défaut qui interroge une URL. La source de la fonction par défaut, qui peut être modifiée, est disponible dans le dépôt Git generic-synthetic-nodejs.

  Pour en savoir plus sur les fonctions HTTP, consultez la section Écrire des fonctions HTTP.

• Si vous utilisez l'API, la commande de déploiement doit spécifier que le La fonction Cloud Run correspond à la deuxième génération. Si vous utilisez les console Google Cloud, le déploiement est géré pour vous. Pour plus d'informations, consultez la section Déployer une fonction Cloud Run.

• L'environnement d'exécution est limité à Node.js. Pour en savoir plus, consultez la section Nœud. Les versions de Node.js suivantes sont compatibles : 12, 14, 16, 18 et 20.

Données collectées par les moniteurs synthétiques

Cette section décrit les données collectées pour la surveillance synthétique. Pour en savoir plus sur l'affichage des résultats d'exécution, consultez Explorer les résultats de la surveillance synthétique

Historique des exécutions

Pour chaque surveillance synthétique, un historique des résultats d'exécution est collecté. Ces données incluent les suivantes :

• Série temporelle qui enregistre la réussite ou l'échec des exécutions au fil du temps.

• Série temporelle qui enregistre la durée d'exécution du code. La la durée d'exécution de la fonction n'est pas enregistrée. Les données de latence sont écrites en tant que série temporelle uptime_check/request_latency pour la ressource Cloud Run sur laquelle la fonction Cloud Run s'exécute. Un graphique de ces données est disponible sur la Page Détails de la surveillance synthétique.

• Journaux contenant des informations sur les exécutions de surveillance synthétique, telles que des informations sur le test et les détails de l'échec. Les journaux disponibles dépendent de votre fonction Cloud Run. Par exemple, si vous utilisez le modèle Mocha, les journaux contiennent des informations indiquant si le test a réussi ou échoué, et les de la vidéo. La trace de la pile, lorsqu'elle est incluse, liste la ligne de code qui a échoué, les types d'erreur et les messages d'erreur.

• (facultatif) traces et journaux pour les requêtes HTTP sortantes Pour savoir comment collecter ces données, consultez la section Latence des requêtes.

Métriques et journaux de la fonction Cloud Run

Métriques et journaux de votre fonction Cloud Run. Ces données, collectées par les fonctions Cloud Run, incluent des informations sur le nombre d'exécutions par seconde, le temps d'exécution et l'utilisation de la mémoire de votre fonction.

Latence de la requête

Les données de latence de la requête HTTP effectuée par le moniteur synthétique sont automatiquement collectées et stockées par Cloud Trace.

Pour collecter les données de trace, de journal et de latence des requêtes HTTP sortantes effectuées par la surveillance synthétique, vous devez utiliser modèle générique. Pour en savoir plus, consultez la section Exemples pour la surveillance synthétique.

Avant de commencer

1. Pour obtenir les autorisations nécessaires pour afficher et modifier les moniteurs synthétiques à l'aide de la console Google Cloud, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet :

   • Éditeur Monitoring (roles/monitoring.editor)
   • Développeur Cloud Functions (roles/cloudfunctions.developer)

   Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

   Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.

2. Enable the Cloud Monitoring API, Artifact Registry API, Cloud Build API, Cloud Functions API, Cloud Logging API, Pub/Sub API, and Cloud Run Admin API APIs.

   Enable the APIs

3. Vérifier que votre projet Google Cloud contient l'instance Compute Engine par défaut de service géré. Ce compte de service est créé lorsque vous activez l'API Compute Engine et porte un nom semblable à [e-mail].

   Dans la console Google Cloud, accédez à la page Comptes de service:

   Accédez à Comptes de service.

   Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est IAM et administration.

   Si le compte de service Compute Engine par défaut n'existe pas, cliquez sur Create service account (Créer un compte de service), puis renseignez les champs de la boîte de dialogue.

4. Assurez-vous que le compte de service Compute Engine par défaut, ou le que vous avez créé, a été Le rôle Éditeur (roles/editor) a été attribué.

   Pour afficher les rôles attribués à votre compte de service, procédez comme suit:

   1. Dans la console Google Cloud, accédez à la page IAM :

      Accéder à IAM

      Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est IAM et administration.

   2. Sélectionnez Inclure les attributions de rôles fournies par Google.
   3. Si le compte de service utilisé par votre surveillance synthétique n'est pas répertorié, ou si il ne s'est pas vu attribuer un rôle incluant les autorisations du rôle de l'agent Cloud Trace (roles/cloudtrace.agent), puis attribuez ce rôle votre compte de service.
5. Configurez les canaux de notification que vous souhaitez utiliser pour recevoir des notifications. Nous vous recommandons de créer plusieurs types de canaux de notification. Pour en savoir plus, consultez Créer et gérer des canaux de notification Créer et gérer des canaux de notification par API

Créer une surveillance synthétique

Avertissement :Ne configurez pas de surveillance synthétique pour tester https://www.google.com. Si vous utilisez l'exemple de code, assurez-vous de modifier le champ url avant de déployer l'exemple de code.

Console

Lorsque vous créez une surveillance synthétique à l'aide de la console Google Cloud, une nouvelle Fonction Cloud Run (2e génération) est déployé et que la surveillance de cette fonction Cloud Run est créée. Vous ne pouvez pas créer une surveillance synthétique qui surveille fonction Cloud Run existante.

1. Assurez-vous d'avoir activé la et les API requises, que votre projet contient un compte de service Compute Engine par défaut, et que ce compte dispose Le rôle Éditeur (roles/editor) a été attribué. Pour plus d'informations, consultez la section Avant de commencer.

2. Dans la console Google Cloud, accédez à la page  Surveillance synthétique :

   Accéder à Surveillance synthétique

   Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.

3. Sélectionnez Créer une surveillance synthétique.

4. Sélectionnez le modèle pour votre fonction Cloud Run:

   • Surveillance synthétique personnalisée: utilisez ce modèle pour collecter des données des données de journal ou de trace pour les requêtes HTTP sortantes.

   • Surveillance synthétique Mocha : utilisez ce modèle lorsque vous écrivez des suites de tests Mocha.

   • Outil de vérification des liens brisés : utilisez ce modèle pour tester un URI et un nombre configurable de liens trouvés à cet URI. Pour en savoir plus sur les champs de cet outil, consultez la section Créer un outil de vérification des liens brisés.

5. Attribuez un nom à la surveillance.

6. Facultatif: mettez à jour les paramètres Response Timeout (Délai avant expiration de la réponse), Check Frequency (Fréquence de vérification) et ajouter des étiquettes définies par l'utilisateur.

7. Effectuez l'une des opérations suivantes :

   • Si vous avez accès à Gemini Code Assist dans ce projet et que vous souhaitez obtenir de l'aide pour écrire votre code, cliquez sur M'aider à coder. Cette fonctionnalité est en version Preview publique. Pour obtenir des conseils sur les requêtes, consultez la section En savoir plus sur l'écriture de requêtes pour les moniteurs synthétiques.

     Une fois que vous êtes satisfait du code, cliquez sur Insérer dans la fonction Cloud

   • Cliquez sur Créer une fonction.

8. Dans la boîte de dialogue de la fonction Cloud Run, procédez comme suit:

   1. Saisissez un nom à afficher, puis sélectionnez une région. Les noms doivent être uniques dans une région.

      Remarque : inclure un trait de soulignement dans le nom de votre fonction Cloud Run.

   2. Dans la section Paramètres d'exécution, de compilation, de connexion et de sécurité, procédez comme suit :

      • Examinez les paramètres par défaut et mettez-les à jour si nécessaire.

        Remarque :Les paramètres par défaut pour la mémoire, le processeur et le la sécurité peut ne pas être suffisante. Nous vous recommandons de définir mémoire à au moins 2 Gio.

      • Dans le champ Compte de service d'exécution, sélectionnez un compte de service.

   3. Modifiez le code généré, ou écrivez ou importez du code pour votre fonction Cloud Run :

      • Pour modifier le code généré, saisir votre propre code ou charger l'exemple de fonction par défaut, sélectionnez Éditeur intégré. L'exemple de fonction, qui dépend du modèle que vous avez sélectionné précédemment, envoie une requête à une URL spécifique. Vous pouvez modifier la fonction par défaut.

      • Pour charger un fichier ZIP depuis votre système local, sélectionnez Fichier ZIP.

        Si vous importez un fichier ZIP à partir de votre système local, vous devez également spécifier un bucket Cloud Storage pour le fichier ZIP. Si vous ne possédez pas de bucket Cloud Storage approprié, puis créez-en un.

        Remarque :Lorsque vous créez un bucket de stockage, celui-ci est immédiatement ouvert, le message No objects found s'affiche, et les options sont de sélection ou d'annulation. Cliquez sur Annuler pour revenir à la boîte de dialogue Créer une fonction. Ensuite, pour le bucket de destination, cliquez sur Parcourir, puis sélectionnez votre bucket Cloud Storage.

      • Pour charger un fichier ZIP à partir de votre Cloud Storage, sélectionnez ZIP depuis Cloud Storage, sélectionnez le bucket de stockage, puis le fichier ZIP à charger.

        Vous pouvez également créer une fonction Cloud Run à l'aide de la commande Pages des fonctions Cloud Run dans la console Google Cloud Pour créer un moniteur synthétique qui surveille une copie de cette fonction Cloud Run, accédez à l'onglet Source, puis cliquez sur Télécharger le fichier ZIP. Vous pouvez ensuite importer le fichier ZIP.

   4. Cliquez sur Appliquer la fonction.

9. Configurez la règle d'alerte :

   1. Facultatif: Mettez à jour le nom de la règle d'alerte et la durée de l'échec avant l'envoi des notifications.

   2. Ajoutez les canaux de notification.

10. Cliquez sur Créer.

    La fonction Cloud Run que vous avez définie est créée et déployée ainsi que la surveillance synthétique.

gcloud

Lorsque vous créez un moniteur synthétique à l'aide de Google Cloud CLI ou de l'API Cloud Monitoring, vous transmettez le nom de la fonction à l'appel d'API. Par conséquent, vous ne pouvez créer qu'une surveillance synthétique qui surveille une fonction Cloud Run existante.

1. Assurez-vous d'avoir activé les API requises, que votre projet contient un compte de service Compute Engine par défaut et que ce compte a reçu le rôle Éditeur (roles/editor). Pour en savoir plus, consultez la section Avant de commencer.
2. Écrivez et déployez votre fonction Cloud Run de 2e génération.

   Par exemple, pour déployer l'exemple synthetics-sdk-nodejs dans dépôt Google Cloud/synthetics-sdk-nodejs, effectuer les opérations suivantes:

   1. Clonez le dépôt et accédez à l'emplacement du code source:

      git clone https://github.com/GoogleCloudPlatform/synthetics-sdk-nodejs.git
      cd synthetics-sdk-nodejs/samples/generic-synthetic-nodejs
      

   2. Déployez la fonction Cloud Run à l'aide de la commande Commande gcloud functions deploy:

      gcloud functions deploy FUNCTION_NAME \
      --gen2 --region="us-west2" --source="." \
      --entry-point=SyntheticFunction --trigger-http --runtime=nodejs18
      

      Dans la commande gcloud functions deploy, procédez comme suit:

      • Assurez-vous que la valeur du champ FUNCTION_NAME est unique dans la région de déploiement.

        Remarque : N'incluez pas de trait de soulignement dans le nom de votre fonction Cloud Run.

      • Incluez l'option --gen2 et définissez la région du déploiement.

      • Définissez le champ --entry-point comme suit:

        • Mocha : SyntheticMochaSuite
        • Pas de café : SyntheticFunction.

      • Définissez le champ --runtime sur nodejs18.

      • Incluez l'option --trigger-http.

      • Définissez le champ --ingress-settings lorsque vous ne souhaitez pas utiliser le paramètre par défaut, qui autorise tout le trafic.

      Les fonctions Cloud Run compilent et déploient votre fonction Cloud Run. Les résultats de la commande Google Cloud CLI incluent des informations sur la fonction, y compris son nom complet :

      name: projects/PROJECT_ID/locations/REGION/functions/FUNCTION_NAME
      

      Pour en savoir plus sur le déploiement d'une fonction, consultez Déployer une fonction Cloud Run.

   Pour répertorier les fonctions Cloud Run dans votre projet Google Cloud, utilisez la classe Commande gcloud functions list:

   gcloud functions list
   

   La réponse de cet appel est une liste d'entrées, chacune listant une fonction Cloud Run :

   NAME: function-1
   STATE: ACTIVE
   TRIGGER: HTTP Trigger
   REGION: us-west2
   ENVIRONMENT: 2nd gen
   

   Pour trouver le nom complet d'une fonction Cloud Run spécifique, exécutez la commande gcloud monitoring uptime describe.

3. Pour créer la surveillance synthétique, exécutez la commande Commande gcloud monitoring uptime create:

   gcloud monitoring uptime create DISPLAY_NAME --synthetic-target=TARGET
   

   Avant d'exécuter la commande précédente, procédez comme suit :

   • Remplacez DISPLAY_NAME par le nom de votre surveillance synthétique.
   • Remplacez TARGET par le nom complet de votre fonction Cloud Run.

4. Créez une règle d'alerte.

   En raison de la complexité de la règle d'alerte nous vous recommandons d'accéder à la section Moniteurs synthétiques de la console Google Cloud, puis utilisez les options pour créer règle d'alerte. Avec cette approche, la plupart des champs des règles d'alerte renseigné pour vous. Pour créer la règle d'alerte à l'aide de la méthode Dans la console Google Cloud, cliquez sur Créer une règle Page Moniteurs synthétiques.

   Si vous prévoyez d'utiliser la Google Cloud CLI ou l'API Cloud Monitoring, configurez le filtre de la condition comme suit:

   "filter": "resource.type = \"cloud_run_revision\" AND
               metric.type = \"monitoring.googleapis.com/uptime_check/check_passed\" AND
               metric.labels.check_id = \"CHECK_ID\"",
   

   La condition surveille les séries temporelles uptime_check/check_passed écrites par votre moniteur synthétique. Veillez à remplacer CHECK_ID par le l'identifiant de la surveillance synthétique, qui est inclus dans les données de réponse d'une create.

   Pour savoir comment créer une règle d'alerte, consultez la section Créer des règles d'alerte à l'aide de l'API.

API

Lorsque vous créez un moniteur synthétique à l'aide de Google Cloud CLI ou de l'API Cloud Monitoring, vous transmettez le nom de la fonction à l'appel d'API. Par conséquent, vous ne pouvez créer qu'un moniteur synthétique qui surveille une fonction Cloud Run existante.

1. Assurez-vous d'avoir activé les API requises, que votre projet contient un compte de service Compute Engine par défaut et que ce compte a reçu le rôle Éditeur (roles/editor). Pour en savoir plus, consultez la section Avant de commencer.
2. Écrire et déployer votre instance fonction Cloud Run.

   Par exemple, pour déployer l'exemple synthetics-sdk-nodejs dans le dépôt Google Cloud/synthetics-sdk-nodejs, procédez comme suit :

   1. Clonez le dépôt et accédez à l'emplacement du code source :

      git clone https://github.com/GoogleCloudPlatform/synthetics-sdk-nodejs.git
      cd synthetics-sdk-nodejs/samples/generic-synthetic-nodejs
      

   2. Déployez la fonction Cloud Run à l'aide de la commande gcloud functions deploy :

      gcloud functions deploy FUNCTION_NAME \
      --gen2 --region="us-west2" --source="." \
      --entry-point=SyntheticFunction --trigger-http --runtime=nodejs18
      

      Dans la commande gcloud functions deploy, procédez comme suit :

      • Assurez-vous que la valeur du champ FUNCTION_NAME est unique dans la région de déploiement.

        Remarque : N'incluez pas de trait de soulignement dans le nom de votre fonction Cloud Run.

      • Incluez l'option --gen2 et définissez la région du déploiement.

      • Définissez le champ --entry-point comme suit:

        • Mocha : SyntheticMochaSuite
        • Pas de café : SyntheticFunction.

      • Définissez le champ --runtime sur nodejs18.

      • Incluez l'option --trigger-http.

      • Définissez le champ --ingress-settings lorsque vous ne souhaitez pas utiliser le paramètre par défaut, qui autorise tout le trafic.

      Les fonctions Cloud Run compilent et déploient votre fonction Cloud Run. Les résultats de la commande Google Cloud CLI incluent des informations sur la fonction, y compris son nom complet :

      name: projects/PROJECT_ID/locations/REGION/functions/FUNCTION_NAME
      

      Pour en savoir plus sur le déploiement d'une fonction, consultez Déployez une fonction Cloud Run.

   Pour répertorier les fonctions Cloud Run dans votre projet Google Cloud, utilisez la classe Commande gcloud functions list:

   gcloud functions list
   

   La réponse à cet appel est une entrée de liste, chaque entrée répertorie une Fonction Cloud Run:

   NAME: function-1
   STATE: ACTIVE
   TRIGGER: HTTP Trigger
   REGION: us-west2
   ENVIRONMENT: 2nd gen
   

   Pour trouver le nom complet d'une fonction Cloud Run spécifique, exécutez la commande gcloud monitoring uptime describe.

3. Pour créer une surveillance synthétique, procédez comme suit:

   1. Cliquez sur projects.uptimeCheckConfigs.create pour ouvrir la page de référence de l'API pour la méthode.
   2. Cliquez sur Essayer pour ouvrir APIs Explorer.

   3. Définissez les champs suivants, puis exécutez la commande.

      • Champ parent: projects/PROJECT_ID.

      • Dans le corps de la requête, spécifiez les éléments suivants :

        • displayName : définissez cette valeur sur le nom à afficher de votre moniteur synthétique.
        • syntheticMonitor : défini sur le nom complet de votre fonction Cloud Run.

      En cas de réussite, la réponse à l'appel d'API est semblable à celle-ci:

      {
      "name": "projects/myproject/uptimeCheckConfigs/17272586127463315332",
      "displayName": "MyMonitor",
      ...
      "syntheticMonitor": {
       "cloudFunctionV2": {
          "name": "projects/myproject/locations/us-west2/functions/function-1",
          "cloudRunRevision": {
          "type": "cloud_run_revision",
          "labels": {
             "project_id": "myproject",
             "configuration_name": "",
             "location": "us-west2",
             "revision_name": "",
             "service_name": "function-1"
          }
          }
       }
      }
      }
      

4. Créez une règle d'alerte.

   En raison de la complexité de la configuration des règles d'alerte, nous vous recommandons d'accéder à la page Surveillance synthétique dans la console Google Cloud et d'utiliser les options pour créer une règle d'alerte. De cette manière, la plupart des champs de la règle d'alerte sont déjà renseignés. Pour créer la règle d'alerte à l'aide de la console Google Cloud, cliquez sur Créer une règle sur la page Surveillance synthétique.

   Si vous prévoyez d'utiliser Google Cloud CLI ou l'API Cloud Monitoring, configurez le filtre de la condition comme suit :

   "filter": "resource.type = \"cloud_run_revision\" AND
               metric.type = \"monitoring.googleapis.com/uptime_check/check_passed\" AND
               metric.labels.check_id = \"CHECK_ID\"",
   

   La condition surveille les séries temporelles uptime_check/check_passed écrites par votre moniteur synthétique. Veillez à remplacer CHECK_ID par le l'identifiant de la surveillance synthétique, qui est inclus dans les données de réponse d'une create.

   Pour savoir comment créer une règle d'alerte, consultez la section Créer des règles d'alerte à l'aide de l'API.

Terraform

Pour savoir comment appliquer ou supprimer une configuration Terraform, consultez la page Commandes Terraform de base. Pour en savoir plus, consultez la documentation de référence du fournisseur Terraform.

Pour créer une surveillance synthétique et une règle d'alerte pour surveiller cette vérification, effectuer les opérations suivantes:

1. Assurez-vous d'avoir activé les API requises, que votre projet contient un compte de service Compute Engine par défaut et que ce compte a reçu le rôle Éditeur (roles/editor). Pour en savoir plus, consultez la section Avant de commencer.

2. Modifiez votre fichier de configuration Terraform et ajoutez un Ressource google_storage_bucket, puis appliquer vos modifications.

   Le code suivant définit un bucket Cloud Storage à l'emplacement US:

   resource "google_storage_bucket" "gcf_source" {
      name = "gcf-v2-source-9948673986912-us"
      location = "US"
      uniform_bucket_level_access = true
   }
   

3. Modifiez votre fichier de configuration Terraform et ajoutez une ressource google_storage_bucket_object, puis appliquez vos modifications.

   "resource" spécifie le nom de l'objet dans votre bucket, et l'emplacement du fichier zip sur votre système local. Par exemple, lorsque vous appliquez le code suivant, un fichier portant le nom example-function.zip est ajouté à votre bucket de stockage:

   resource "google_storage_bucket_object" "object" {
      name = "example-function.zip"
      bucket = google_storage_bucket.gcf_source.name
      source = "generic-synthetic-node.js.zip"
   }
   

4. Modifiez votre fichier de configuration Terraform et ajoutez un google_cloudfunctions2_function ressource, puis appliquez vos modifications.

   Remarque : inclure un trait de soulignement dans le nom de votre fonction Cloud Run.

   Assurez-vous que votre ressource google_cloudfunctions2_function spécifie un environnement d'exécution Node.js et le point d'entrée utilisé par la surveillance synthétique. Par exemple, lorsque vous appliquez le code suivant, une fonction dont le nom sm-central1 est déployé:

   resource "google_cloudfunctions2_function" "central1" {
      name = "sm-central1"
      location = "us-central1"
   
      build_config {
         runtime = "nodejs20"
         entry_point = "SyntheticFunction"
         source {
               storage_source {
                  bucket = google_storage_bucket.gcf_source.name
                  object = google_storage_bucket_object.object.name
               }
         }
      }
   
      service_config {
         max_instance_count = 1
         available_memory = "256Mi"
         timeout_seconds  = 60
      }
   }
   

5. Pour créer une surveillance synthétique, modifiez votre fichier de configuration Terraform et ajoutez un élément google_monitoring_uptime_check_config ressource, puis appliquez vos modifications.

   Pour cette ressource, spécifiez le bloc synthetic_monitor:

   resource "google_monitoring_uptime_check_config" "synthetic" {
      display_name = "sm-central1"
      timeout = "30s"
   
      synthetic_monitor {
         cloud_function_v2 {
               name = google_cloudfunctions2_function.central1.id
         }
      }
   }
   

6. Facultatif: Créez un canal de notification et une règle d'alerte.

   Les étapes suivantes utilisent la console Google Cloud pour créer le canal de notification et la règle d'alerte. Cette approche garantit que la règle d'alerte ne surveille que les données générées par votre surveillance synthétique.

   1. Pour créer un canal de notification, procédez comme suit:

      1. Dans la console Google Cloud, accédez à la page Alertes :

         Accéder à l'interface des alertes

         Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.

      2. Sélectionnez Gérer les canaux de notification.
      3. Accédez au type de canal que vous souhaitez ajouter, cliquez sur Ajouter, puis remplissez la boîte de dialogue.

   2. Pour créer une règle d'alerte, procédez comme suit :

      1. Dans la console Google Cloud, accédez à Page Surveillance synthétique:

         Accéder à Surveillance synthétique

         Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.

      2. Recherchez votre moniteur synthétique, sélectionnez  Plus, puis Ajouter une règle d'alerte.
      3. Dans la boîte de dialogue, accédez à la section Notifications et nom, développez Canaux de notification, puis effectuez vos sélections.
      4. Attribuez un nom à la règle d'alerte, puis cliquez sur Créer une règle.

Tarifs

En général, les métriques système de Cloud Monitoring sont gratuites, et les métriques des systèmes, agents ou applications externes. Les métriques facturables sont facturées en fonction du nombre d'octets ou du nombre d'échantillons ingérés.

Pour en savoir plus sur les tarifs de Cloud Monitoring, consultez les documents suivants:

• Récapitulatif des tarifs de Cloud Monitoring
• Tarifs de Cloud Monitoring

Résoudre les problèmes liés aux moniteurs synthétiques

Cette section fournit des informations qui peuvent vous aider à résoudre les problèmes liés à vos moniteurs synthétiques.

Message d'erreur après l'activation des API

Vous ouvrez le flux de création d'un moniteur synthétique et vous êtes invité à activer au moins une API. Une fois les API activées, un message semblable au suivant s'affiche :

An error occurred during fetching available regions: Cloud Functions API has
not been used in project PROJECT_ID before or it is disabled.

Le message d'erreur vous recommande de vérifier que l'API est activée, puis vous conseille d'attendre et de réessayer l'action.

Pour vérifier que l'API est activée, accédez à la page API et la page "Services" de votre projet:

Accéder aux API et services

Une fois que vous avez vérifié que l'API est activée, vous pouvez poursuivre le processus de création. La condition est résolue automatiquement une fois que l'API l'activation se propage dans le backend.

Les requêtes HTTP sortantes ne sont pas suivies.

Vous configurez la surveillance synthétique afin de collecter des données de trace pour la sortie. Requêtes HTTP. Vos données de trace n'affichent qu'une seule période, comme illustré dans la capture d'écran suivante :

Pour résoudre ce problème, assurez-vous que votre compte de service a reçu le rôle Agent Cloud Trace (roles/cloudtrace.agent). Le rôle Éditeur (roles/editor) est également suffisant.

Pour afficher les rôles attribués à votre compte de service, procédez comme suit :

1. Dans la console Google Cloud, accédez à la page IAM :

   Accéder à IAM

   Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est IAM et administration.

2. Sélectionnez Inclure les attributions de rôles fournies par Google.

3. Si le compte de service utilisé par votre surveillance synthétique n'est pas répertorié, ou s'il ne s'est pas vu attribuer un rôle incluant les autorisations associées au rôle Agent Cloud Trace (roles/cloudtrace.agent), puis attribuez ce rôle à votre de service géré.

   Si vous ne connaissez pas le nom de votre compte de service, sélectionnez Comptes de service dans le menu de navigation.

État "En cours"

La page Surveillance synthétique liste un moniteur synthétique avec un état In progress. Un état In progress signifie que le moniteur synthétique a été créé récemment et qu'aucune donnée n'est à afficher, ou que le déploiement de la fonction a échoué.

Pour déterminer si le déploiement de la fonction a échoué, essayez ce qui suit:

• Assurez-vous que le nom de votre fonction Cloud Run ne contient pas de trait de soulignement. Si un trait de soulignement est présent, supprimez-le et redéployez la fonction Cloud Run.

• Ouvrez la page Détails de la surveillance synthétique correspondant à la surveillance synthétique.

  Si le message suivant s'affiche, supprimez la surveillance synthétique.

  Cloud Function not found for this Synthetic monitor. Please confirm it exists or delete this monitor.
  

  Le message d'erreur indique que la fonction a été supprimée et que le moniteur synthétique ne peut donc pas l'exécuter.

• Ouvrez la page des fonctions Cloud Run pour la fonction. Pour ouvrir cette page depuis la page Détails du moniteur synthétique, cliquez sur Code, puis sur le nom de la fonction.

  Si un message semblable à celui-ci s'affiche, cela signifie que la fonction a échoué. à déployer.

  This function has failed to deploy and will not work correctly. Please edit and redeploy
  

  Pour résoudre cet échec, examinez le code de la fonction et corrigez les erreurs. empêchant la création ou le déploiement de la fonction.

Lorsque vous créez une surveillance synthétique, la à déployer et à exécuter la fonction.

État d'avertissement

La section Surveillance synthétique liste un moniteur synthétique avec l'état Warning. Un état Warning signifie que les résultats d'exécution sont incohérents. Cela peut indiquer un problème de conception test, ou cela peut indiquer que ce qui est testé a un comportement incohérent.

État "Échec"

La section Surveillance synthétique liste un moniteur synthétique avec l'état Failing. Pour en savoir plus sur le motif de l'échec, afficher l'historique des exécutions le plus récent.

• Si le message d'erreur Request failed with status code 429 s'affiche, alors la cible de la requête HTTP a rejeté la commande. Pour résoudre ce problème, vous devez modifier la cible de votre moniteur synthétique.

  Le point de terminaison https://www.google.com rejette les requêtes effectuées par la surveillance synthétique.

• Si l'échec renvoie un temps d'exécution de 0ms, la fonction Cloud Run risque de manquer de mémoire. Pour résoudre ce problème, modifiez votre fonction Cloud Run, puis augmentez la quantité de mémoire sur au moins 2 Gio et définissez le champ "CPU" sur 1.

Échec de la suppression d'une surveillance synthétique

Vous utilisez l'API Cloud Monitoring pour supprimer un moniteur synthétique, mais l'appel d'API échoue avec une réponse semblable à la suivante :

{
  "error": {
    "code": 400,
    "message": "Request contains an invalid argument.",
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.DebugInfo",
        "detail": "[ORIGINAL ERROR] generic::invalid_argument: Cannot delete check 1228258045726183344. One or more alerting policies is using it.Delete the alerting policy with id projects/myproject/alertPolicies/16594654141392976482 and any other policies using this uptime check and try again."
      }
    ]
  }
}

Pour résoudre l'échec, supprimez les règles d'alerte qui surveillent les résultats du moniteur synthétique, puis supprimez le moniteur synthétique.

Étape suivante

• Exemples pour les moniteurs synthétiques
• Gérer les moniteurs synthétiques
• Explorer les résultats de la surveillance synthétique