Créer une surveillance synthétique

Ce document explique comment créer des surveillances 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. Le contrôleur synthétique exécute ce script et enregistre les résultats des tests ainsi que des données supplémentaires telles que la latence. Pour être averti lorsqu'un test échoue, vous pouvez configurer une règle d'alerte afin de surveiller les résultats du test.

Cette fonctionnalité n'est disponible que pour les projets Google Cloud . Pour les configurations App Hub, sélectionnez le projet hôte App Hub ou le projet de gestion du dossier compatible avec les applications.

À propos de la surveillance synthétique

Un contrôleur synthétique exécute périodiquement une fonction Cloud Run de deuxième génération à usage unique déployée sur Cloud Run. Lorsque vous créez le monitor 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 interagisse avec 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 qui se trouvent dans 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 par un squelette fourni. Une fois que vous avez créé un monitor synthétique, Cloud Monitoring utilise un système de planification qui planifie l'exécution périodique de votre fonction Cloud Run. Bien que vous spécifiiez la région dans laquelle votre fonction Cloud Run existe, les commandes qui déclenchent l'exécution peuvent provenir de n'importe quelle région acceptée par les serveurs de vérification du temps d'activité. Pour en savoir plus, consultez Lister les adresses IP des serveurs de vérification de la disponibilité.

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

  • Lorsque vous créez un contrôleur 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 pour vous avertir en cas d'échec de deux tests consécutifs ou plus.

  • Lorsque vous créez un test 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.

Remarques concernant la fréquence d'exécution

Vous configurez la fréquence d'exécution de votre fonction Cloud Run. Pour déterminer la fréquence des exécutions, tenez compte de l'objectif de niveau de service (SLO) de votre service. Pour détecter les éventuels non-respects des SLO, vous devez exécuter les tests fréquemment. Toutefois, le SLO de votre service n'est pas le seul élément à prendre en compte. Vous devez également réfléchir à la façon dont le taux d'exécution se traduit en charge sur votre service et en coûts. Chaque exécution exerce une charge sur votre service. Par conséquent, plus vous exécutez fréquemment votre fonction Cloud Run, plus la charge appliquée à votre service est importante. Pour information, 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 rapidité avec laquelle vous pouvez être averti en cas d'échec de votre test. Monitoring ouvre un incident et envoie une notification après le deuxième échec consécutif d'un test. Par exemple, si votre fréquence d'exécution est de cinq minutes, il peut s'écouler dix minutes avant que deux tests aient échoué. Vous recevez une notification après le deuxième échec du test.

Exemple de code de fonction Cloud Run

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

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

Vous pouvez implémenter votre propre approche pour collecter les données de trace et de journalisation des 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 les paramètres d'exécution, de compilation, de connexion et 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. Nous vous recommandons de définir ce champ sur au moins 2 Gio.

  • La valeur par défaut des paramètres de transfert de données entrants de votre fonction Cloud Run est d'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 Cloud Run Functions, qui se déroule au niveau du réseau, est toujours réussie. 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 votre fonction Cloud Run. Pour savoir comment afficher ou modifier les paramètres de transfert de données entrantes, consultez Paramètres d'entrée.

Restrictions concernant les 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 consoleGoogle Cloud pour créer votre monitor synthétique, une fonction par défaut qui interroge une URL vous est fournie. 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 Écrire des fonctions HTTP.

  • Si vous utilisez l'API, la commande de déploiement doit spécifier que la fonction Cloud Run est de deuxième génération. Si vous utilisez la consoleGoogle Cloud , le déploiement est géré pour vous. Pour en savoir plus, consultez Déployer une fonction Cloud Run.

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

Données collectées par les contrôles synthétiques

Cette section décrit les données collectées pour votre analyseur synthétique. Pour savoir comment afficher les résultats d'exécution, consultez Explorer les résultats de la surveillance synthétique.

Historique des exécutions

Un historique des résultats d'exécution est collecté pour chaque surveillance synthétique. Ces données incluent les éléments suivants :

  • 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 durée d'exécution de la fonction n'est pas enregistrée. Les données de latence sont écrites sous forme de 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 du test synthétique.

  • Journaux contenant des informations sur les exécutions de contrôles synthétiques, comme des informations sur le test et les détails des échecs. Les journaux disponibles dépendent de votre fonction Cloud Run. Par exemple, si vous utilisez le modèle Mocha, les journaux incluent des informations indiquant si le test a réussi ou échoué, ainsi que sa durée. Lorsqu'elle est incluse, la trace de pile liste la ligne de code qui a échoué, les types d'erreur et les messages d'erreur.

  • Éventuellement, les traces et les journaux des requêtes HTTP sortantes. Pour savoir comment collecter ces données, consultez Latence des requêtes.

Métriques et journaux des fonctions Cloud Run

Métriques et journaux pour 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 pour la requête HTTP effectuée par le contrôleur synthétique sont automatiquement collectées et stockées par Cloud Trace.

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

Avant de commencer

Effectuez les étapes suivantes dans le projet Google Cloud qui stockera le contrôleur synthétique :

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

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

    Vous pouvez également obtenir les autorisations requises avec 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érifiez que votre projet Google Cloud contient le compte de service Compute Engine par défaut. Ce compte de service est créé lorsque vous activez l'API Compute Engine. Son nom est semblable à 12345-compute@developer.gserviceaccount.com.

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

    Accéder à 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 Créer un compte de service, puis renseignez la boîte de dialogue.

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

    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 contrôleur synthétique n'est pas listé ou s'il ne s'est pas vu attribuer un rôle incluant les autorisations du rôle Agent Cloud Trace (roles/cloudtrace.agent), attribuez ce rôle à votre compte de service.
  5. Configurez les canaux de notification que vous souhaitez utiliser pour recevoir les 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 et Créer et gérer des canaux de notification à l'aide d'API.

  6. Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

      In the Google Cloud console, activate Cloud Shell.

      Activate Cloud Shell

      At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

      Terraform

      Pour utiliser les exemples Terraform de cette page dans un environnement de développement local, installez et initialisez gcloud CLI, puis configurez le service Identifiants par défaut de l'application à l'aide de vos identifiants utilisateur.

      1. Install the Google Cloud CLI.

      2. If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

      3. To initialize the gcloud CLI, run the following command: 

        gcloud init

      4. If you're using a local shell, then create local authentication credentials for your user account: 

        gcloud auth application-default login

        You don't need to do this if you're using Cloud Shell.

        If an authentication error is returned, and you are using an external identity provider (IdP), confirm that you have signed in to the gcloud CLI with your federated identity.

      Pour en savoir plus, consultez Configurer les ADC pour un environnement de développement local dans la documentation sur l'authentification Google Cloud .

      REST

      Pour utiliser les exemples d'API REST de cette page dans un environnement de développement local, vous devez utiliser les identifiants que vous fournissez à gcloud CLI.

        After installing the Google Cloud CLI, initialize it by running the following command: 

        gcloud init

        If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

      Pour en savoir plus, consultez la section S'authentifier pour utiliser REST dans la documentation sur l'authentification Google Cloud .

      Créer une surveillance synthétique

      Console

      Lorsque vous créez un monitor synthétique à l'aide de la console Google Cloud , une fonction Cloud Run (2e génération) est déployée et le monitor correspondant est créé. Vous ne pouvez pas créer de monitor 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 dispose du rôle Éditeur (roles/editor). Pour en savoir plus, consultez 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. Dans la barre d'outils de la console Google Cloud , sélectionnez votre projet Google Cloud . Pour les configurations App Hub, sélectionnez le projet hôte App Hub ou le projet de gestion du dossier compatible avec les applications.
      4. Sélectionnez Créer une surveillance synthétique.

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

        • Moniteur synthétique personnalisé : utilisez ce modèle lorsque vous souhaitez collecter des données de journaux ou de trace pour les requêtes HTTP sortantes.

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

        • Vérificateur de 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 ce vérificateur, consultez Créer un vérificateur de liens brisés.

      6. Attribuez un nom au moniteur.

      7. Facultatif : Mettez à jour le délai d'expiration de la réponse et la fréquence de vérification, et ajoutez des libellés définis par l'utilisateur.

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

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

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

        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.

          • 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 le code de votre fonction Cloud Run :

          • Pour modifier le code généré, saisir votre propre code ou charger la fonction exemple par défaut, sélectionnez Éditeur intégré. La fonction exemple, 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 Importer un fichier ZIP.

            Si vous importez un fichier ZIP depuis votre système local, vous devez également spécifier un bucket Cloud Storage pour ce fichier. Si vous ne disposez pas d'un bucket Cloud Storage approprié, créez-en un.

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

            Vous pouvez également créer une fonction Cloud Run à l'aide des pages Cloud Run Functions de la console Google Cloud . Pour créer un monitor 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.

      10. 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.

      11. Cliquez sur Créer.

        La fonction Cloud Run que vous avez définie est créée et déployée en tant que fonction de 2e génération, et le monitoring synthétique est créé.

      gcloud

      Lorsque vous créez un test 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 un monitor synthétique que pour 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 dispose du rôle Éditeur (roles/editor). Pour en savoir plus, consultez Avant de commencer.
      2. Configurez Google Cloud CLI pour définir un projet par défaut à l'aide de la commande gcloud config set :

        gcloud config set project PROJECT_ID

        Avant d'exécuter la commande précédente, remplacez les éléments suivants :

        • PROJECT_ID : identifiant du projet. Pour les configurations App Hub, sélectionnez le projet hôte App Hub ou le projet de gestion du dossier compatible avec les applications.
      3. Rédiger et déployer votre fonction Cloud Run de 2e génération

        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 sa région de déploiement.

          • Ajoutez l'option --gen2 et définissez la région de déploiement.

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

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

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

          • Spécifiez 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.

          Cloud Run Functions compile, puis déploie 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 lister les fonctions Cloud Run dans votre projet Google Cloud , utilisez la commande gcloud functions list :

        gcloud functions list

        La réponse à 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.

      4. Pour créer le monitor synthétique, exécutez la commande gcloud monitoring uptime create :

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

        Avant d'exécuter la commande précédente, remplacez les éléments suivants :

        • DISPLAY_NAME : nom de votre monitor synthétique.
        • TARGET : nom complet de votre fonction Cloud Run.

      5. 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 Moniteurs synthétiques de 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 consoleGoogle Cloud , cliquez sur Créer une règle sur la page Moniteurs synthétiques.

        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 surveillance synthétique. Veillez à remplacer CHECK_ID par l'identifiant du contrôleur synthétique, qui est inclus dans les données de réponse d'une commande de création.

        Pour savoir comment créer une règle d'alerte, consultez 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 un monitor synthétique et une règle d'alerte pour surveiller ce test, procédez comme suit :

      1. Installez et configurez Terraform pour votre projet. Pour les configurations App Hub, sélectionnez le projet hôte App Hub ou le projet de gestion du dossier compatible avec les applications.

      2. 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 dispose du rôle Éditeur (roles/editor). Pour en savoir plus, consultez Avant de commencer.

      3. Modifiez votre fichier de configuration Terraform et ajoutez une ressource google_storage_bucket, puis appliquez 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
}

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

        La ressource 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 nommé 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"
}

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

        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 les synthétiques. Par exemple, lorsque vous appliquez le code suivant, une fonction portant le nom sm-central1 est déployée :

        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
   }
}

      6. Pour créer un monitor synthétique, modifiez votre fichier de configuration Terraform et ajoutez une ressource google_monitoring_uptime_check_config, 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
      }
   }
}

      7. 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 :

          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 à 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.

          2. Localisez votre monitor 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 faites votre sélection.
          4. Nommez la règle d'alerte, puis cliquez sur Créer une règle.

      REST

      Lorsque vous créez un test 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 un monitor synthétique que pour 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 dispose du rôle Éditeur (roles/editor). Pour en savoir plus, consultez Avant de commencer.
      2. Configurez Google Cloud CLI pour définir un projet par défaut à l'aide de la commande gcloud config set :

        gcloud config set project PROJECT_ID

        Avant d'exécuter la commande précédente, remplacez les éléments suivants :

        • PROJECT_ID : identifiant du projet. Pour les configurations App Hub, sélectionnez le projet hôte App Hub ou le projet de gestion du dossier compatible avec les applications.
      3. Rédiger et déployer votre fonction Cloud Run de 2e génération

        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 sa région de déploiement.

          • Ajoutez l'option --gen2 et définissez la région de déploiement.

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

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

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

          • Spécifiez 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.

          Cloud Run Functions compile, puis déploie 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 lister les fonctions Cloud Run dans votre projet Google Cloud , utilisez la commande gcloud functions list :

        gcloud functions list

        La réponse à 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.

      4. Pour créer un monitor synthétique :

        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" : projet dans lequel créer le test synthétique. Pour les configurations App Hub, sélectionnez le projet hôte App Hub ou le projet de gestion du dossier compatible avec les applications. Ce champ est au format suivant :

            projects/PROJECT_ID

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

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

          En cas de réussite, la réponse de l'appel d'API ressemble à ce qui suit :

          {
"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"
    }
    }
 }
}
}

      5. 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 Moniteurs synthétiques de 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 consoleGoogle Cloud , cliquez sur Créer une règle sur la page Moniteurs synthétiques.

        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 surveillance synthétique. Veillez à remplacer CHECK_ID par l'identifiant du contrôleur synthétique, qui est inclus dans les données de réponse d'une commande de création.

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

      Tarifs

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

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

      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 vérifications synthétiques.

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

      Vous ouvrez le flux de création d'un moniteur synthétique et êtes invité à activer au moins une API. Une fois les API activées, un message semblable à celui-ci 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.

      Pour vérifier que l'API est activée, accédez à la page API et 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 flux de création. La condition se résout automatiquement une fois que l'activation de l'API s'est propagée dans le backend.

      Les requêtes HTTP sortantes ne sont pas tracées

      Vous configurez votre contrôleur synthétique pour collecter les données de trace des requêtes HTTP de sortie. Vos données de trace n'affichent qu'une seule étendue, comme dans la capture d'écran suivante :

      Cloud Trace n'affiche qu'une seule trace.

      Pour résoudre ce problème, assurez-vous que le rôle Agent Cloud Trace (roles/cloudtrace.agent) a été attribué à votre compte de service. 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. Dans la barre d'outils de la console Google Cloud , sélectionnez votre projet Google Cloud . Pour les configurations App Hub, sélectionnez le projet hôte App Hub ou le projet de gestion du dossier compatible avec les applications.
      3. Sélectionnez Inclure les attributions de rôles fournies par Google.

      4. Si le compte de service utilisé par votre analyseur synthétique n'est pas listé ou s'il ne s'est pas vu attribuer un rôle incluant les autorisations du rôle Agent Cloud Trace (roles/cloudtrace.agent), attribuez ce rôle à votre compte de service.

        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 une surveillance synthétique dont l'état est In progress. Un état In progress signifie que le monitor synthétique a été créé récemment et qu'il n'y a aucune donnée à afficher, ou que le déploiement de la fonction a échoué.

      Pour déterminer si le déploiement de la fonction a échoué, procédez comme 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 pour le moniteur synthétique.

        Si le message suivant s'affiche, supprimez le contrôleur 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, par conséquent, la surveillance synthétique ne peut pas l'exécuter.

      • Ouvrez la page Cloud Run Functions pour la fonction. Pour ouvrir cette page à partir de la page Détails du contrôleur synthétique, cliquez sur Code, puis sur le nom de la fonction.

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

        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 qui empêchent la fonction d'être créée ou déployée.

      Lorsque vous créez un monitor synthétique, le déploiement et l'exécution de la fonction peuvent prendre plusieurs minutes.

      État d'avertissement

      La page Surveillance synthétique liste une surveillance synthétique dont l'état est Warning. L'état Warning signifie que les résultats de l'exécution sont incohérents. Cela peut indiquer un problème de conception de votre test ou un comportement incohérent de l'élément testé.

      État "Échec"

      La page Surveillance synthétique liste une surveillance synthétique avec l'état Failing. Pour en savoir plus sur la raison de l'échec, consultez l'historique d'exécution le plus récent.

      • Si le message d'erreur Request failed with status code 429 s'affiche, cela signifie que la cible de la requête HTTP a refusé la commande. Pour résoudre cet échec, vous devez modifier la cible de votre surveillance synthétique.

        Le point de terminaison https://www.google.com rejette les requêtes envoyées par les moniteurs synthétiques.

      • Si l'échec renvoie une durée d'exécution de 0ms, il est possible que la fonction Cloud Run manque de mémoire. Pour résoudre ce problème, modifiez votre fonction Cloud Run, puis augmentez la mémoire à 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 test synthétique, mais l'appel d'API échoue et renvoie 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.

      Étapes suivantes