Cette page a été traduite par l'API Cloud Translation.

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. Le moniteur synthétique exécute ce script et enregistre les résultats des tests et d'autres données telles que la latence. Pour être averti lorsqu'un test échoue, vous pouvez configurer une règle d'alerte pour surveiller les résultats du test.

À propos des surveillances synthétiques

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 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 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. Bien que vous spécifiiez la région dans laquelle se trouve votre fonction Cloud Run, les commandes qui déclenchent l'exécution peuvent provenir de n'importe quelle région prise en charge par les serveurs de vérification de l'état de fonctionnement. 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 pour être averti en cas d'échec de test:

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 pour vous avertir en cas d'échec de deux tests consécutifs ou plus.
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 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 éventuelles violations 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 tenir compte de la façon dont le taux d'exécution se traduit en charge sur votre service et sur vos coûts. Chaque exécution génère une charge sur votre service. Par conséquent, plus vous exécutez votre fonction Cloud Run fréquemment, plus vous lui imposez de charge. 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 10 minutes avant que deux tests échouent. 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 pour les 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. L'utilisation de Gemini pour générer du code est disponible 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 envers les produits Open Source, vous devez vous attendre à des modifications de 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 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. 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 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 votre 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 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 journalisation 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 la fonction Cloud Run est de deuxième génération. Si vous utilisez la console Google Cloud, le déploiement est géré automatiquement. 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 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 votre moniteur synthétique. Pour savoir comment afficher les résultats d'exécution, consultez la section Explorer les résultats de la surveillance synthétique.

Historique des exécutions

Pour chaque moniteur synthétique, un historique des résultats d'exécution est collecté. 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. Le temps d'exécution de la fonction n'est pas enregistré. 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 fourni 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 indiquent si le test a réussi ou échoué, ainsi que sa durée. 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 des fonctions 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 des données de trace, de journalisation et de latence pour les requêtes HTTP sortantes effectuées par votre moniteur synthétique, vous devez utiliser le modèle générique. Pour en savoir plus, consultez Échantillons pour les moniteurs synthétiques.

Avant de commencer

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.
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
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 et porte un nom 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.
Assurez-vous que le compte de service Compute Engine par défaut ou le compte de service que vous avez créé a reçu le 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 moniteur 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.
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 les pages Créer et gérer des canaux de notification et Créer et gérer des canaux de notification à l'aide d'API.

Créer une surveillance synthétique

Console

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

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.
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.
Sélectionnez Créer une surveillance synthétique.
Sélectionnez le modèle de votre fonction Cloud Run:
- Surveillance synthétique personnalisée: utilisez ce modèle lorsque vous souhaitez collecter 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 vérificateur de liens brisés.
Attribuez un nom au moniteur.
Facultatif: Mettez à jour le Délai avant expiration de la réponse, la Fréquence de vérification et ajoutez des libellés définis par l'utilisateur.
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.
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.
  
  Remarque:N'incluez pas de 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 de la mémoire allouée, du processeur et de la sécurité peuvent ne pas être suffisants. Nous vous recommandons de définir la mémoire sur au moins 2 Go.
  - 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 à partir de votre système local, sélectionnez Importation 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 disposez pas d'un bucket Cloud Storage approprié, créez-en un.
    
    Remarque :Lorsque vous créez un bucket de stockage, il s'ouvre immédiatement, le message No objects found s'affiche et les options sont "Sélectionner" ou "Annuler". Cliquez sur Annuler pour revenir à la boîte de dialogue Créer une fonction. Ensuite, pour le bucket de destination, sélectionnez Parcourir, puis 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 des pages "Fonctions Cloud Run" de 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.
Configurez la règle d'alerte:
1. Facultatif: Modifiez 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.
Cliquez sur Créer.

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

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'un moniteur synthétique qui surveille une fonction Cloud Run existante.

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.
Écrivez et déployez 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 la région de déploiement.
    
    Remarque:N'incluez pas de trait de soulignement dans le nom de votre fonction Cloud Run.
  - Spécifiez 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.
  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 la section Déployer une fonction Cloud Run.
Pour répertorier les fonctions Cloud Run de votre projet Google Cloud, exécutez la 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.
Pour créer le moniteur 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, procédez comme suit:
- Remplacez DISPLAY_NAME par le nom de votre moniteur synthétique.
- Remplacez TARGET par le nom complet de votre fonction Cloud Run.
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 l'identifiant du moniteur 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 la section Créer des règles d'alerte à l'aide de l'API.

API

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.
Écrivez et déployez 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 la région de déploiement.
    
    Remarque:N'incluez pas de trait de soulignement dans le nom de votre fonction Cloud Run.
  - Spécifiez 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.
  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 la section Déployer une fonction Cloud Run.
Pour répertorier les fonctions Cloud Run de votre projet Google Cloud, exécutez la 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.
Pour créer un moniteur 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.
  Si l'opération réussit, 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"
    }
    }
 }
}
}
```
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 l'identifiant du moniteur 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 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 ce test, procédez comme suit:

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.
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
}
```
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"
}
```

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

Pour créer un moniteur 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
      }
   }
}

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 moniteur 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 à 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. 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 Cloud Monitoring sont gratuites, contrairement aux métriques provenant de systèmes, d'agents ou d'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 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 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 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 l'activation de l'API propagée dans le backend.

Les requêtes HTTP sortantes ne sont pas suivies

Vous configurez votre moniteur synthétique pour collecter des données de trace pour les requêtes HTTP de sortie. Vos données de trace n'affichent qu'une seule période, comme illustré 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:

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.
Sélectionnez Inclure les attributions de rôles fournies par Google.
Si le compte de service utilisé par votre moniteur synthétique n'est pas listé ou s'il ne s'est pas vu attribuer un rôle qui inclut 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 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é, 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 de la surveillance synthétique.

Si le message suivant s'affiche, supprimez le moniteur 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 au suivant s'affiche, 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 ce problème, examinez le code de la fonction et corrigez les erreurs qui empêchent la compilation ou le déploiement de la fonction.

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

É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 avec votre test ou que ce qui est testé présente un comportement incohérent.

État d'échec

La section Surveillance synthétique liste un moniteur 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, 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 les moniteurs synthétiques.
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 mémoire à au moins 2 Go 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.

Créer une surveillance synthétique

À propos des surveillances synthétiques

Considérations concernant la fréquence d'exécution

Exemple de code de fonction Cloud Run

Configuration des fonctions Cloud Run

Restrictions concernant les fonctions Cloud Run

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

Historique des exécutions

Métriques et journaux des fonctions Cloud Run

Latence de la requête

Avant de commencer

Créer une surveillance synthétique

Console

gcloud

API

Terraform

Tarifs

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

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

Les requêtes HTTP sortantes ne sont pas suivies

État "En cours"

État d'avertissement

État d'échec

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

Étape suivante