Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Créer des tests de disponibilité publics

Les tests de disponibilité publics vous permettent de vérifier la disponibilité des URL et des ressources accessibles publiquement Google Cloud en envoyant des requêtes HTTP, HTTPS ou TCP périodiques depuis plusieurs emplacements dans le monde. Lorsque vous créez un test de disponibilité, vous pouvez également configurer une règle d'alerte pour être averti si la cible ne répond pas. Pour tester des ressources sur un réseau privé, consultez Créer des tests de disponibilité privés.

À propos des tests de disponibilité

Les tests de disponibilité publics peuvent déterminer l'état des ressources surveillées suivantes :

Pour HTTP et HTTPS, toutes les redirections d'URL sont suivies, et la réponse finale reçue par le test de disponibilité est utilisée pour évaluer les critères de réussite. Pour les tests HTTPS, le délai d'expiration du certificat SSL est calculé en fonction du certificat de serveur reçu dans la réponse finale.

Pour qu'un test de disponibilité réussisse, les conditions suivantes doivent être remplies :

L'état HTTP doit correspondre aux critères que vous spécifiez.
Les données de réponse ne contiennent aucun contenu requis ou le contenu requis est présent.

Les tests de disponibilité ne chargent pas les composants de la page ni n'exécutent de code JavaScript. De plus, la configuration par défaut d'un test de disponibilité n'inclut pas d'authentification.

Avant de commencer

Effectuez les étapes suivantes dans le projet Google Cloud qui stockera le contrôle du temps d'activité. Pour les configurations App Hub, sélectionnez le projet hôte App Hub ou le projet de gestion.

Pour obtenir les autorisations nécessaires pour créer des tests de disponibilité, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet :
- Utilisateurs de la console Google Cloud : Éditeur Monitoring (roles/monitoring.editor)
- Utilisateurs de l'API :
  - Éditeur de configuration des tests de disponibilité Monitoring (roles/monitoring.uptimeCheckConfigEditor)
  - Éditeur de règles d'alerte Monitoring (roles/monitoring.alertPolicyEditor)
  - Éditeur Monitoring NotificationChannel (roles/monitoring.notificationChannelEditor)
Remarque : Si vous prévoyez de créer un contrôle du temps d'activité sur un service Cloud Run, vous devez également disposer de l'autorisation run.routes.invoke sur ce service.
Vérifiez que la ressource que vous souhaitez vérifier dispose d'un point de terminaison public ou se trouve derrière un pare-feu configurable.

Pour toutes les autres configurations, vous devez créer un test de disponibilité privé. Pour en savoir plus, consultez Créer des tests de disponibilité privés.
Lorsque votre ressource se trouve derrière un pare-feu, configurez ce pare-feu pour autoriser le trafic entrant provenant des adresses IP des serveurs de test de disponibilité. Pour en savoir plus, consultez Lister les adresses IP des serveurs de vérification du temps d'activité.
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.
Identifiez au moins trois vérificateurs pour votre test de disponibilité. La région de vérification du temps d'activité USA inclut les régions USA_OREGON, USA_IOWA et USA_VIRGINIA. Chacune des régions USA_* dispose d'un vérificateur, et USA inclut les trois. Les autres régions de vérification du temps d'activité, EUROPE, SOUTH_AMERICA et ASIA_PACIFIC, disposent chacune d'un vérificateur.

Si vous sélectionnez Global lorsque vous utilisez la console Google Cloud , ou REGION_UNSPECIFIED lorsque vous utilisez l'API, les tests de disponibilité sont émis depuis toutes les régions de test de disponibilité.
Sélectionnez l'onglet correspondant à la façon dont vous prévoyez d'utiliser les exemples de cette page :
Console

Lorsque vous utilisez la console Google Cloud pour accéder aux services et aux API Google Cloud , vous n'avez pas besoin de configurer l'authentification.

gcloud

Dans la console Google Cloud , activez Cloud Shell.

Activer Cloud Shell

En bas de la console Google Cloud , une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.
Terraform

Pour utiliser les exemples Terraform de cette page dans un environnement de développement local, installez et initialisez la gcloud CLI, puis configurez les Identifiants par défaut de l'application avec vos identifiants utilisateur.
1. Installez la Google Cloud CLI.
2. Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.
3. Si vous utilisez un shell local, créez des identifiants d'authentification locaux pour votre compte utilisateur :
  gcloud auth application-default login
  Vous n'avez pas besoin de le faire si vous utilisez Cloud Shell.
  
  Si une erreur d'authentification est renvoyée et que vous utilisez un fournisseur d'identité (IdP) externe, vérifiez que vous vous êtes connecté à la gcloud CLI avec votre identité fédérée.
Pour en savoir plus, consultez Configurer les ADC pour un environnement de développement local dans la documentation sur l'authentification Google Cloud .
C#

Pour utiliser les exemples .NET de cette page dans un environnement de développement local, installez et initialisez la gcloud CLI, puis configurez les Identifiants par défaut de l'application avec vos identifiants utilisateur.
1. Installez la Google Cloud CLI.
2. Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.
3. Si vous utilisez un shell local, créez des identifiants d'authentification locaux pour votre compte utilisateur :
  gcloud auth application-default login
  Vous n'avez pas besoin de le faire si vous utilisez Cloud Shell.
  
  Si une erreur d'authentification est renvoyée et que vous utilisez un fournisseur d'identité (IdP) externe, vérifiez que vous vous êtes connecté à la gcloud CLI avec votre identité fédérée.
Pour en savoir plus, consultez Configurer les ADC pour un environnement de développement local dans la documentation sur l'authentification Google Cloud .
Go

Pour utiliser les exemples Go de cette page dans un environnement de développement local, installez et initialisez la gcloud CLI, puis configurez les Identifiants par défaut de l'application avec vos identifiants utilisateur.
1. Installez la Google Cloud CLI.
2. Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.
3. Si vous utilisez un shell local, créez des identifiants d'authentification locaux pour votre compte utilisateur :
  gcloud auth application-default login
  Vous n'avez pas besoin de le faire si vous utilisez Cloud Shell.
  
  Si une erreur d'authentification est renvoyée et que vous utilisez un fournisseur d'identité (IdP) externe, vérifiez que vous vous êtes connecté à la gcloud CLI avec votre identité fédérée.
Pour en savoir plus, consultez Configurer les ADC pour un environnement de développement local dans la documentation sur l'authentification Google Cloud .
Java

Pour utiliser les exemples Java de cette page dans un environnement de développement local, installez et initialisez la gcloud CLI, puis configurez les Identifiants par défaut de l'application avec vos identifiants utilisateur.
1. Installez la Google Cloud CLI.
2. Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.
3. Si vous utilisez un shell local, créez des identifiants d'authentification locaux pour votre compte utilisateur :
  gcloud auth application-default login
  Vous n'avez pas besoin de le faire si vous utilisez Cloud Shell.
  
  Si une erreur d'authentification est renvoyée et que vous utilisez un fournisseur d'identité (IdP) externe, vérifiez que vous vous êtes connecté à la gcloud CLI avec votre identité fédérée.
Pour en savoir plus, consultez Configurer les ADC pour un environnement de développement local dans la documentation sur l'authentification Google Cloud .
Node.js

Pour utiliser les exemples Node.js de cette page dans un environnement de développement local, installez et initialisez la gcloud CLI, puis configurez les Identifiants par défaut de l'application avec vos identifiants utilisateur.
1. Installez la Google Cloud CLI.
2. Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.
3. Si vous utilisez un shell local, créez des identifiants d'authentification locaux pour votre compte utilisateur :
  gcloud auth application-default login
  Vous n'avez pas besoin de le faire si vous utilisez Cloud Shell.
  
  Si une erreur d'authentification est renvoyée et que vous utilisez un fournisseur d'identité (IdP) externe, vérifiez que vous vous êtes connecté à la gcloud CLI avec votre identité fédérée.
Pour en savoir plus, consultez Configurer les ADC pour un environnement de développement local dans la documentation sur l'authentification Google Cloud .
PHP

Pour utiliser les exemples PHP de cette page dans un environnement de développement local, installez et initialisez la gcloud CLI, puis configurez les Identifiants par défaut de l'application avec vos identifiants utilisateur.
1. Installez la Google Cloud CLI.
2. Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.
3. Si vous utilisez un shell local, créez des identifiants d'authentification locaux pour votre compte utilisateur :
  gcloud auth application-default login
  Vous n'avez pas besoin de le faire si vous utilisez Cloud Shell.
  
  Si une erreur d'authentification est renvoyée et que vous utilisez un fournisseur d'identité (IdP) externe, vérifiez que vous vous êtes connecté à la gcloud CLI avec votre identité fédérée.
Pour en savoir plus, consultez Configurer les ADC pour un environnement de développement local dans la documentation sur l'authentification Google Cloud .
Python

Pour utiliser les exemples Python de cette page dans un environnement de développement local, installez et initialisez la gcloud CLI, puis configurez les Identifiants par défaut de l'application avec vos identifiants utilisateur.
1. Installez la Google Cloud CLI.
2. Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.
3. Si vous utilisez un shell local, créez des identifiants d'authentification locaux pour votre compte utilisateur :
  gcloud auth application-default login
  Vous n'avez pas besoin de le faire si vous utilisez Cloud Shell.
  
  Si une erreur d'authentification est renvoyée et que vous utilisez un fournisseur d'identité (IdP) externe, vérifiez que vous vous êtes connecté à la gcloud CLI avec votre identité fédérée.
Pour en savoir plus, consultez Configurer les ADC pour un environnement de développement local dans la documentation sur l'authentification Google Cloud .
Ruby

Pour utiliser les exemples Ruby de cette page dans un environnement de développement local, installez et initialisez la gcloud CLI, puis configurez les Identifiants par défaut de l'application avec vos identifiants utilisateur.
1. Installez la Google Cloud CLI.
2. Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.
3. Si vous utilisez un shell local, créez des identifiants d'authentification locaux pour votre compte utilisateur :
  gcloud auth application-default login
  Vous n'avez pas besoin de le faire si vous utilisez Cloud Shell.
  
  Si une erreur d'authentification est renvoyée et que vous utilisez un fournisseur d'identité (IdP) externe, vérifiez que vous vous êtes connecté à la gcloud CLI avec votre identité fédérée.
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 API REST de cette page dans un environnement de développement local, vous devez utiliser les identifiants que vous fournissez à la gcloud CLI.
Pour en savoir plus, consultez la section S'authentifier pour utiliser REST dans la documentation sur l'authentification Google Cloud .

Créer un test de disponibilité

Cette section explique comment créer et configurer des tests de disponibilité.

Pour créer un test de disponibilité pour un équilibreur de charge externe qui comporte au moins un port TCP, HTTP ou HTTPS configuré, vous pouvez suivre ces instructions. Vous pouvez également accéder à la page Informations sur le service, puis cliquer sur Créer un test de disponibilité. Lorsque vous commencez à partir de la page Informations sur le service, les champs spécifiques au service sont préremplis.

Console

Pour créer un test de disponibilité à l'aide de la console Google Cloud , procédez comme suit :

Dans la console Google Cloud , accédez à la page Tests de disponibilité :
Accéder à la page Tests de disponibilité

Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.
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.
Cliquez sur Create Uptime Check (Créer un test de disponibilité).
Spécifiez la cible du test de disponibilité :
1. Sélectionnez le protocole. Vous pouvez sélectionner HTTP, HTTPS ou TCP.
2. Choisissez l'un des types de ressources suivants :
  - URL : tout nom d'hôte ou toute adresse IPv4. Le chemin d'accès et le port sont saisis séparément.
  - Service Kubernetes LoadBalancer : service Kubernetes de type LoadBalancer.
  - Service Cloud Run : si vous sélectionnez un service Cloud Run comme cible d'un contrôle du temps d'activité, assurez-vous de disposer de l'autorisation run.routes.invoke sur ce service.
  - App Engine : applications App Engine (modules).
  - Instance : instances Compute Engine ou AWS EC2.
  - Elastic Load Balancer : équilibreur de charge AWS.
  Remarque : Ne sélectionnez pas Adresse IP interne, car ce type de ressource ne peut pas être la cible d'un test de disponibilité public.
3. Renseignez les champs spécifiques au protocole :
  - Pour les vérifications TCP, saisissez le port.
  - Pour les vérifications HTTP et HTTPS, vous pouvez saisir un chemin d'accès dans votre hôte ou ressource. Tous les tests de disponibilité qui utilisent ces protocoles envoient une requête à http://target/path. Dans cette expression, target est une nom d'hôte ou une adresse IP pour une ressource d'URL. Pour une ressource App Engine, target est un nom d'hôte dérivé du nom du service. Pour les ressources d'instance et d'équilibreur de charge, target est une adresse IP dérivée du nom que vous avez fourni pour la ressource ou le groupe de ressources.
    
    Si vous laissez le champ path vide ou si vous définissez la valeur sur /, la requête est envoyée à http://target/.
    
    Par exemple, pour émettre un test de disponibilité sur la ressource d'URL example.com/tester, définissez le champ Nom d'hôte sur example.com et le champ Chemin d'accès sur /tester.
    
    Supposons que vous ayez déployé un serveur sur App Engine avec un coordinateur compatible avec / et /hello. Pour émettre le test de disponibilité au gestionnaire /, laissez le champ Chemin vide. Pour émettre le contrôle du temps d'activité au gestionnaire /hello, définissez la valeur du champ Chemin d'accès sur /hello.
4. Renseignez les champs spécifiques à la ressource :
  - Pour les ressources URL, saisissez le nom d'hôte dans le champ Nom d'hôte. Par exemple, saisissez example.com.
    
    Remarque : Créez des vérifications par rapport aux URL directes lorsque cela est possible.
  - Pour les ressources App Engine, saisissez le nom du service dans le champ Service.
  - Pour les ressources Elastic Load Balancer et Instance, renseignez le champ S'applique à comme suit :
    - Pour émettre une vérification du temps d'activité vers une seule instance ou un seul équilibreur de charge, sélectionnez Unique, puis utilisez le menu pour sélectionner l'instance ou l'équilibreur de charge spécifique.
    - Pour émettre un test de disponibilité vers un groupe Monitoring, sélectionnez Groupe, puis utilisez le menu pour sélectionner le nom du groupe.
5. Facultatif : Pour définir la fréquence d'exécution de la vérification du temps d'activité, utilisez le champ Fréquence de vérification.
6. Facultatif : Pour sélectionner des régions de vérification ou configurer des certificats SSL, l'authentification, les en-têtes et les ports pour les vérifications HTTP et HTTPS, cliquez sur Plus d'options de cible :
  - Régions : sélectionnez les régions dans lesquelles les tests de disponibilité doivent recevoir des requêtes. Un test de disponibilité doit comporter au moins trois vérificateurs. Il existe un vérificateur dans toutes les régions, à l'exception des États-Unis, qui en comptent trois. Le paramètre par défaut, Monde, inclut toutes les régions.
  - Pings ICMP : configurez le test de disponibilité pour qu'il envoie jusqu'à trois pings. Pour en savoir plus, consultez Utiliser les pings ICMP.
  - Méthode de requête : pour les vérifications HTTP, sélectionnez la méthode de requête.
  - Corps : pour les vérifications HTTP POST, saisissez le corps encodé en URL. Vous devez effectuer l'encodage vous-même. Pour toutes les autres vérifications, laissez ce champ vide.
  - En-tête de l'hôte : remplissez ce champ pour vérifier les hôtes virtuels. Ce champ n'est pas disponible pour les tests TCP.
  - Port : spécifiez un numéro de port.
  - En-têtes personnalisés : spécifiez des en-têtes personnalisés, puis chiffrez-les si souhaité. Le chiffrement masque les valeurs de l'en-tête dans le formulaire. Utilisez le chiffrement pour les en-têtes liés à l'authentification que vous ne souhaitez pas voir visibles par les autres.
  - Authentification : ces valeurs sont envoyées en tant qu'en-tête d'autorisation. Ce champ n'est pas disponible pour les tests TCP.
    
    Remarque : Ne définissez pas les champs Authentification lorsque vous envoyez un en-tête d'autorisation. Si vous définissez les champs Authentication et envoyez un en-tête d'autorisation, une erreur Invalid Argument se produit.
    
    parmi les options suivantes :
    - Authentification de base : indiquez un seul nom d'utilisateur et un mot de passe. Les mots de passe sont toujours masqués dans le formulaire.
    - Authentification de l'agent de service : lorsqu'elle est activée, un jeton d'identité est généré pour l'agent de service de surveillance. Cette option n'est disponible que pour les vérifications HTTPS.
  - Validation du certificat SSL : si vous avez sélectionné HTTPS pour une ressource d'URL, le service tente par défaut de se connecter via HTTPS et de valider le certificat SSL. Les tests de disponibilité échouent lorsqu'une URL possède un certificat non valide. Voici quelques raisons pour lesquelles un certificat peut être non valide :
    - Un certificat expiré
    - Certificat autosigné
    - Un certificat dont le nom de domaine ne correspond pas
    - Certificat qui utilise l'extension AIA (Authority Information Access).
    Remarque : Un certificat SSL révoqué n'est pas considéré comme non valide.
    
    Pour forcer une vérification du temps d'activité HTTPS afin de valider le certificat SSL, sélectionnez Valider les certificats SSL.
    
    Pour désactiver la validation des certificats SSL, décochez Valider les certificats SSL.
    
    Si vous disposez de certificats SSL avec des extensions AIA, vous devez désactiver la validation des certificats SSL. Ces types de certificats ne sont pas compatibles et échouent à la séquence de validation. Généralement, le message d'erreur est "Réponse avec erreur handshake SSL en 10 000 ms".
    
    Vous pouvez utiliser la métrique monitoring.googleapis.com/uptime_check/time_until_ssl_cert_expires pour créer une règle d'alerte qui vous avertit avant l'expiration de votre certificat. Pour en savoir plus, consultez la section Exemples de règles : stratégie de test de disponibilité.
Cliquez sur Continuer et configurez les exigences de réponse. Tous les paramètres de cette section ont des valeurs par défaut :
- Pour modifier le délai avant expiration du test de disponibilité, utilisez le champ Délai avant expiration de la réponse. Un test de disponibilité échoue lorsqu'aucune réponse n'est reçue de plusieurs emplacements au cours de cette période.
  
  Remarque : Si vous créez des vérifications pour les URL de redirection, augmentez le délai d'expiration de la réponse à 30 secondes ou plus.
- Pour configurer le test de disponibilité afin qu'il effectue une correspondance de contenu, assurez-vous que le libellé du bouton bascule est La correspondance de contenu est activée :
  - Sélectionnez le type de correspondance du contenu de la réponse dans le menu d'options. Ce champ détermine comment le contenu de la réponse est comparé aux données renvoyées. Par exemple, supposons que le contenu de la réponse soit abcd et que le type de correspondance du contenu soit Contient. Le test de disponibilité n'est réussi que lorsque les données de réponse contiennent abcd. Pour en savoir plus, consultez Valider les données de réponse.
  - Saisissez le contenu de la réponse. Le contenu de la réponse doit être une chaîne de caractères ne dépassant pas 1 024 octets. Dans l'API, ce champ correspond à l'objet ContentMatcher.
  Remarque : Activez la correspondance du contenu de la réponse lorsque vous sélectionnez le protocole TCP.
- Pour éviter la création d'entrées de journal en raison des tests de disponibilité, décochez Journaliser les échecs de tests.
- Pour les tests de disponibilité HTTP, configurez les codes de réponse acceptables. Par défaut, les tests de disponibilité HTTP marquent toute réponse 2xx comme une réponse réussie.
Cliquez sur Continuer et configurez les notifications.

Pour recevoir une notification en cas d'échec d'un test de disponibilité, créez une règle d'alerte et configurez des canaux de notification pour cette règle :
1. Facultatif : Modifiez le nom de la règle d'alerte.
2. Facultatif : Dans le champ Durée, sélectionnez la durée pendant laquelle les tests de disponibilité doivent échouer avant l'envoi de notifications. Par défaut, les notifications sont envoyées lorsqu'au moins deux régions signalent des échecs de test de disponibilité pendant au moins une minute.
3. Dans la zone Canaux de notification, cliquez sur le menu, sélectionnez les canaux à ajouter, puis cliquez sur OK.
  
  Dans le menu, les canaux de notification sont regroupés par ordre alphabétique pour chaque type de canal.
Si vous ne souhaitez pas créer de règle d'alerte, assurez-vous que le texte du bouton bascule est Ne pas créer d'alerte.
Cliquez sur Continuer et effectuez votre test de disponibilité :
1. Saisissez un titre descriptif pour le test de disponibilité.
2. Facultatif : Pour ajouter des libellés définis par l'utilisateur à votre vérification du temps d'activité, procédez comme suit :
  1. Cliquez sur Afficher les étiquettes utilisateur.
  2. Dans le champ Clé, saisissez un nom pour le libellé. Les noms de libellés doivent commencer par une lettre minuscule et peuvent contenir des lettres minuscules, des chiffres, des traits de soulignement et des tirets. Par exemple, saisissez severity.
  3. Dans le champ Valeur, saisissez une valeur pour votre libellé. Les valeurs d'étiquette peuvent contenir des lettres minuscules, des chiffres, des traits de soulignement et des tirets. Par exemple, saisissez critical.
  4. Pour chaque étiquette supplémentaire, cliquez sur Ajouter une étiquette utilisateur, puis saisissez la clé et la valeur de l'étiquette.
3. Pour vérifier la configuration du test disponibilité, cliquez sur Test (Tester). Si le résultat ne correspond pas à vos attentes, consultez Échecs de vérification, corrigez votre configuration, puis répétez l'étape de vérification.
4. Cliquez sur Créer. Si vous sélectionnez Créer et qu'un champ obligatoire n'est pas renseigné, un message d'erreur s'affiche.

gcloud

Pour créer le contrôle du temps d'activité, exécutez la commande gcloud monitoring uptime create :

gcloud monitoring uptime create DISPLAY_NAME REQUIRED_FLAGS OPTIONAL_FLAGS --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.
DISPLAY_NAME : nom de votre vérification du temps d'activité.
REQUIRED_FLAGS : configurez cette option pour spécifier la ressource examinée par le contrôle du temps d'activité. Par exemple, la commande suivante crée un contrôle du temps d'activité qui teste l'URL EXAMPLE.com pour un projet spécifique :
```
gcloud monitoring uptime create DISPLAY_NAME \
--resource-labels=host=EXAMPLE.com,project_id=PROJECT_ID \
--resource-type=uptime-url
```
La commande précédente spécifie des valeurs pour chaque libellé requis par le type de ressource uptime-url.

Remarque : Dans la commande précédente, définissez le champ resource-type sur uptime-url. N'utilisez pas uptime_url. Les commandes Google Cloud CLI ne suivent pas les mêmes conventions de dénomination que Cloud Monitoring. Pour obtenir la liste des valeurs valides pour le champ resource-type, consultez la documentation gcloud monitoring uptime create.
OPTIONAL_FLAGS : configurez ces indicateurs pour remplacer les valeurs par défaut. Par exemple, vous devez définir l'option --protocol lorsque le protocole n'est pas http.

Terraform

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

Pour créer un test de disponibilité et une règle d'alerte pour le surveiller :

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.

Modifiez votre fichier de configuration Terraform et ajoutez une ressource google_monitoring_uptime_check_config, puis appliquez le fichier de configuration.

L'exemple suivant illustre une configuration qui vérifie une URL publique :

resource "google_monitoring_uptime_check_config" "example" {
    display_name = "example"
    timeout      = "60s"

    http_check {
        port = "80"
        request_method = "GET"
    }

    monitored_resource {
        type = "uptime_url"
        labels = {
            project_id = "PROJECT_ID"
            host="EXAMPLE.com"
        }
    }

    checker_type = "STATIC_IP_CHECKERS"
}

Dans l'expression précédente :

PROJECT_ID est l'ID de votre projet. Pour les configurations App Hub, sélectionnez le projet hôte App Hub ou le projet de gestion.
EXAMPLE.com correspond à l'URL de l'hôte.

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 test de disponibilité.
1. Pour créer un canal de notification :
  1. Dans la console Google Cloud , accédez à la page Alertes :
    Accéder à la page Alertes
    
    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.
  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.
  3. Sélectionnez Gérer les canaux de notification.
  4. 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 Tests de disponibilité :
    Accéder à la page Tests de disponibilité
    
    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.
  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.
  3. Localisez votre test de disponibilité, sélectionnez Plus, puis Ajouter une règle d'alerte.
  4. Dans la boîte de dialogue, accédez à la section Notifications et nom, développez Canaux de notification, puis effectuez vos sélections.
  5. Nommez la règle d'alerte, puis cliquez sur Créer une règle.
Vous pouvez créer une règle d'alerte en ajoutant une ressource google_monitoring_alert_policy à votre fichier de configuration et en appliquant la nouvelle configuration.

C#

Pour vous authentifier auprès de Monitoring, configurez les identifiants par défaut de l'application. Pour en savoir plus, consultez Configurer l'authentification pour un environnement de développement local.

public static object CreateUptimeCheck(string projectId, string hostName,
    string displayName)
{
    // Define a new config.
    var config = new UptimeCheckConfig()
    {
        DisplayName = displayName,
        MonitoredResource = new MonitoredResource()
        {
            Type = "uptime_url",
            Labels = { { "host", hostName } }
        },
        HttpCheck = new UptimeCheckConfig.Types.HttpCheck()
        {
            Path = "/",
            Port = 80,
        },
        Timeout = TimeSpan.FromSeconds(10).ToDuration(),
        Period = TimeSpan.FromMinutes(5).ToDuration()
    };
    // Create a client.
    var client = UptimeCheckServiceClient.Create();
    ProjectName projectName = new ProjectName(projectId);
    // Create the config.
    var newConfig = client.CreateUptimeCheckConfig(
        projectName,
        config,
        CallSettings.FromExpiration(
            Expiration.FromTimeout(
                TimeSpan.FromMinutes(2))));
    Console.WriteLine(newConfig.Name);
    return 0;
}

Java

private static void createUptimeCheck(
    String projectId, String displayName, String hostName, String pathName) throws IOException {
  CreateUptimeCheckConfigRequest request =
      CreateUptimeCheckConfigRequest.newBuilder()
          .setParent(ProjectName.format(projectId))
          .setUptimeCheckConfig(
              UptimeCheckConfig.newBuilder()
                  .setDisplayName(displayName)
                  .setMonitoredResource(
                      MonitoredResource.newBuilder()
                          .setType("uptime_url")
                          .putLabels("host", hostName))
                  .setHttpCheck(HttpCheck.newBuilder().setPath(pathName).setPort(80))
                  .setTimeout(Duration.newBuilder().setSeconds(10))
                  .setPeriod(Duration.newBuilder().setSeconds(300)))
          .build();
  try (UptimeCheckServiceClient client = UptimeCheckServiceClient.create()) {
    UptimeCheckConfig config = client.createUptimeCheckConfig(request);
    System.out.println("Uptime check created: " + config.getName());
  } catch (Exception e) {
    usage("Exception creating uptime check: " + e.toString());
    throw e;
  }
}

Go


// createGet creates an example uptime check on a GET request.
func createGet(w io.Writer, projectID string) (*monitoringpb.UptimeCheckConfig, error) {
	ctx := context.Background()
	client, err := monitoring.NewUptimeCheckClient(ctx)
	if err != nil {
		return nil, fmt.Errorf("NewUptimeCheckClient: %w", err)
	}
	defer client.Close()
	req := &monitoringpb.CreateUptimeCheckConfigRequest{
		Parent: "projects/" + projectID,
		UptimeCheckConfig: &monitoringpb.UptimeCheckConfig{
			DisplayName: "new GET uptime check",
			Resource: &monitoringpb.UptimeCheckConfig_MonitoredResource{
				MonitoredResource: &monitoredres.MonitoredResource{
					Type: "uptime_url",
					Labels: map[string]string{
						"host": "example.com",
					},
				},
			},
			CheckRequestType: &monitoringpb.UptimeCheckConfig_HttpCheck_{
				HttpCheck: &monitoringpb.UptimeCheckConfig_HttpCheck{
					RequestMethod: monitoringpb.UptimeCheckConfig_HttpCheck_GET,
					Path:          "/",
					Port:          80,
				},
			},
			Timeout: &duration.Duration{Seconds: 10},
			Period:  &duration.Duration{Seconds: 300},
		},
	}
	config, err := client.CreateUptimeCheckConfig(ctx, req)
	if err != nil {
		return nil, fmt.Errorf("CreateUptimeCheckConfig GET: %w", err)
	}
	fmt.Fprintf(w, "Successfully created GET uptime check %q\n", config.GetDisplayName())
	return config, nil
}

// createPost creates an example uptime check on a POST request.
func createPost(w io.Writer, projectID string) (*monitoringpb.UptimeCheckConfig, error) {
	ctx := context.Background()
	client, err := monitoring.NewUptimeCheckClient(ctx)
	if err != nil {
		return nil, fmt.Errorf("NewUptimeCheckClient: %w", err)
	}
	defer client.Close()
	req := &monitoringpb.CreateUptimeCheckConfigRequest{
		Parent: "projects/" + projectID,
		UptimeCheckConfig: &monitoringpb.UptimeCheckConfig{
			DisplayName: "new POST uptime check",
			Resource: &monitoringpb.UptimeCheckConfig_MonitoredResource{
				MonitoredResource: &monitoredres.MonitoredResource{
					Type: "uptime_url",
					Labels: map[string]string{
						"host": "example.com",
					},
				},
			},
			CheckRequestType: &monitoringpb.UptimeCheckConfig_HttpCheck_{
				HttpCheck: &monitoringpb.UptimeCheckConfig_HttpCheck{
					RequestMethod: monitoringpb.UptimeCheckConfig_HttpCheck_POST,
					ContentType:   monitoringpb.UptimeCheckConfig_HttpCheck_URL_ENCODED,
					Path:          "/",
					Port:          80,
					Body:          []byte(base64.URLEncoding.EncodeToString([]byte("key: value"))),
				},
			},
			Timeout: &duration.Duration{Seconds: 10},
			Period:  &duration.Duration{Seconds: 300},
		},
	}
	config, err := client.CreateUptimeCheckConfig(ctx, req)
	if err != nil {
		return nil, fmt.Errorf("CreateUptimeCheckConfig POST: %w", err)
	}
	fmt.Fprintf(w, "Successfully created POST uptime check %q\n", config.GetDisplayName())
	return config, nil
}

Node.js

// Imports the Google Cloud client library
const monitoring = require('@google-cloud/monitoring');

// Creates a client
const client = new monitoring.UptimeCheckServiceClient();

/**
 * TODO(developer): Uncomment and edit the following lines of code.
 */
// const projectId = 'YOUR_PROJECT_ID';
// const hostname = 'mydomain.com';

const request = {
  // i.e. parent: 'projects/my-project-id'
  parent: client.projectPath(projectId),
  uptimeCheckConfig: {
    displayName: 'My Uptime Check',
    monitoredResource: {
      // See the Uptime Check docs for supported MonitoredResource types
      type: 'uptime_url',
      labels: {
        host: hostname,
      },
    },
    httpCheck: {
      path: '/',
      port: 80,
    },
    timeout: {
      seconds: 10,
    },
    period: {
      seconds: 300,
    },
  },
};

// Creates an uptime check config for a GCE instance
const [uptimeCheckConfig] = await client.createUptimeCheckConfig(request);
console.log('Uptime check created:');
console.log(`ID: ${uptimeCheckConfig.name}`);
console.log(`Display Name: ${uptimeCheckConfig.displayName}`);
console.log('Resource: %j', uptimeCheckConfig.monitoredResource);
console.log('Period: %j', uptimeCheckConfig.period);
console.log('Timeout: %j', uptimeCheckConfig.timeout);
console.log(`Check type: ${uptimeCheckConfig.check_request_type}`);
console.log(
  'Check: %j',
  uptimeCheckConfig.httpCheck || uptimeCheckConfig.tcpCheck
);
console.log(
  `Content matchers: ${uptimeCheckConfig.contentMatchers
    .map(matcher => matcher.content)
    .join(', ')}`
);
console.log(`Regions: ${uptimeCheckConfig.selectedRegions.join(', ')}`);

PHP

use Google\Api\MonitoredResource;
use Google\Cloud\Monitoring\V3\Client\UptimeCheckServiceClient;
use Google\Cloud\Monitoring\V3\CreateUptimeCheckConfigRequest;
use Google\Cloud\Monitoring\V3\UptimeCheckConfig;

/**
 * Example:
 * ```
 * create_uptime_check($projectId, 'myproject.appspot.com', 'Test Uptime Check!');
 * ```
 *
 * @param string $projectId Your project ID
 * @param string $hostName
 * @param string $displayName
 */
function create_uptime_check($projectId, $hostName = 'example.com', $displayName = 'New uptime check')
{
    $projectName = 'projects/' . $projectId;
    $uptimeCheckClient = new UptimeCheckServiceClient([
        'projectId' => $projectId,
    ]);

    $monitoredResource = new MonitoredResource();
    $monitoredResource->setType('uptime_url');
    $monitoredResource->setLabels(['host' => $hostName]);

    $uptimeCheckConfig = new UptimeCheckConfig();
    $uptimeCheckConfig->setDisplayName($displayName);
    $uptimeCheckConfig->setMonitoredResource($monitoredResource);
    $createUptimeCheckConfigRequest = (new CreateUptimeCheckConfigRequest())
        ->setParent($projectName)
        ->setUptimeCheckConfig($uptimeCheckConfig);

    $uptimeCheckConfig = $uptimeCheckClient->createUptimeCheckConfig($createUptimeCheckConfigRequest);

    printf('Created an uptime check: %s' . PHP_EOL, $uptimeCheckConfig->getName());
}

Python

def create_uptime_check_config_get(
    project_id: str, host_name: str = None, display_name: str = None
) -> uptime.UptimeCheckConfig:
    """Creates a new uptime check configuration

    Args:
        project_id: Google Cloud project id where the uptime check is created
        host_name: An example label's value for the "host" label
        display_name: A human friendly name of the configuration

    Returns:
        A structure that describes a new created uptime check
    """
    config = monitoring_v3.UptimeCheckConfig()
    config.display_name = display_name or "New GET uptime check"
    config.monitored_resource = {
        "type": "uptime_url",
        "labels": {"host": host_name or "example.com"},
    }
    config.http_check = {
        "request_method": monitoring_v3.UptimeCheckConfig.HttpCheck.RequestMethod.GET,
        "path": "/",
        "port": 80,
    }
    config.timeout = {"seconds": 10}
    config.period = {"seconds": 300}

    client = monitoring_v3.UptimeCheckServiceClient()
    new_config = client.create_uptime_check_config(
        request={"parent": project_id, "uptime_check_config": config}
    )
    pprint.pprint(new_config)
    return new_config


def create_uptime_check_config_post(
    project_id: str, host_name: str = None, display_name: str = None
) -> uptime.UptimeCheckConfig:
    """Creates a new uptime check configuration

    Args:
        project_id: Google Cloud project id where the uptime check is created
        host_name: An example label's value for the "host" label
        display_name: A human friendly name of the configuration

    Returns:
        A structure that describes a new created uptime check
    """
    config = monitoring_v3.UptimeCheckConfig()
    config.display_name = display_name or "New POST uptime check"
    config.monitored_resource = {
        "type": "uptime_url",
        "labels": {"host": host_name or "example.com"},
    }
    config.http_check = {
        "request_method": monitoring_v3.UptimeCheckConfig.HttpCheck.RequestMethod.POST,
        "content_type": monitoring_v3.UptimeCheckConfig.HttpCheck.ContentType.URL_ENCODED,
        "body": "foo=bar".encode("utf-8"),
        "path": "/",
        "port": 80,
    }
    config.timeout = {"seconds": 10}
    config.period = {"seconds": 300}

    client = monitoring_v3.UptimeCheckServiceClient()
    new_config = client.create_uptime_check_config(
        request={"parent": project_id, "uptime_check_config": config}
    )
    pprint.pprint(new_config)
    return new_config

Ruby

gem "google-cloud-monitoring"
require "google/cloud/monitoring"

def create_uptime_check_config project_id: nil, host_name: nil, display_name: nil
  client = Google::Cloud::Monitoring.uptime_check_service
  project_name = client.project_path project: project_id
  config = {
    display_name:       display_name.nil? ? "New uptime check" : display_name,
    monitored_resource: {
      type:   "uptime_url",
      labels: { "host" => host_name.nil? ? "example.com" : host_name }
    },
    http_check:         { path: "/", port: 80 },
    timeout:            { seconds: 10 },
    period:             { seconds: 300 }
  }
  new_config = client.create_uptime_check_config \
    parent:              project_name,
    uptime_check_config: config
  puts new_config.name
  new_config
end

REST

Pour créer un test de disponibilité, appelez la méthode projects.uptimeCheckConfigs.create. Définissez les paramètres de la méthode comme suit :

parent : obligatoire. Projet dans lequel créer le test de disponibilité. Pour les configurations App Hub, sélectionnez le projet hôte App Hub ou le projet de gestion. Ce champ a le format suivant :
```
projects/PROJECT_ID
```
Le corps de la requête doit contenir un objet UptimeCheckConfig pour le nouveau test de disponibilité. Cette page fournit des informations sur certains champs. Pour obtenir une documentation complète sur cet objet et ses champs, consultez la page UptimeCheckConfig :
- Laissez le champ name de l'objet de configuration vide. Le système définit ce champ lors de la construction de l'objet de configuration de la réponse.
- Si vous configurez une vérification HTTP ou HTTPS, vous devez renseigner le champ HttpCheck de l'objet UptimeCheckConfig. Dans cet objet, définissez le champ requestMethod sur GET ou POST. Si ce champ est omis ou défini sur METHOD_UNSPECIFIED, une requête GET est émise.
  
  Si vous configurez une requête POST, renseignez les champs contentType, customContentType (facultatif) et body.

La méthode create renvoie l'objet UptimeCheckConfig pour la nouvelle configuration.

Si la configuration de disponibilité créée ne fonctionne pas comme prévu, consultez la section Échecs de vérification sur cette page.

Il peut s'écouler jusqu'à 5 minutes avant que les résultats du test de disponibilité ne commencent à parvenir à Monitoring. Pendant ce temps, le tableau de bord du test de disponibilité indique l'état "aucune donnée disponible".

Utiliser les pings ICMP

Pour vous aider à résoudre les problèmes liés aux tests de disponibilité publics ayant échoué, vous pouvez configurer vos tests de disponibilité pour qu'ils envoient jusqu'à trois pings ICMP pendant le test. Les pings peuvent vous aider à faire la distinction entre les échecs causés, par exemple, par des problèmes de connectivité réseau et par des délais d'attente dans votre application.

Par défaut, les tests de disponibilité n'envoient pas de pings. Chaque ping ajoute une certaine latence au test de disponibilité. Les tests de disponibilité privés ne peuvent pas envoyer de pings.

Lorsqu'un test de disponibilité public échoue, les résultats des pings sont écrits dans les journaux Cloud Logging. Si le ping échoue, les champs suivants sont ajoutés au champ httpRequest dans l'entrée de journal :

rtt_usec : délai aller-retour pour chaque requête ping infructueuse.
unreachable_count : nombre de requêtes ping ayant renvoyé le code d'état ICMP_DEST_UNREACH.
no_answer_count : nombre de requêtes ping ayant expiré et n'ayant renvoyé aucune réponse.

Les résultats des pings pour les tests de disponibilité réussis ne sont pas consignés.

Configurer les pings

Chaque configuration de vérification du temps d'activité inclut un objet HttpCheck ou un objet TcpCheck. Ces deux objets incluent un champ pingConfig. Utilisez ce champ pour spécifier le nombre de pings ICMP à inclure dans chaque vérification (jusqu'à trois). Par défaut, aucun ping n'est envoyé.

Pour configurer les pings, procédez comme suit :

Lorsque vous utilisez la console Google Cloud , développez Plus d'options de ciblage et saisissez une valeur dans le champ Pings ICMP.
Lorsque vous utilisez l'API Cloud Monitoring, utilisez l'objet PingConfig, qui présente la structure suivante :
```
{
  "pingsCount": integer
}
```
Pour en savoir plus sur l'utilisation de l'API Monitoring pour les configurations de vérification du temps d'activité, consultez Créer une vérification du temps d'activité : API ou Modifier une vérification du temps d'activité : API.

Vérifier le test de disponibilité

Lorsque vous créez un test de disponibilité dans la console Google Cloud , vous pouvez tester la configuration avant de l'enregistrer.

Vérifications réussies

Un test de disponibilité est réussi lorsque les conditions suivantes sont remplies :

L'état HTTP correspond aux critères que vous avez sélectionnés.
La réponse ne contient aucun contenu obligatoire ou une recherche du contenu obligatoire dans la réponse est fructueuse.

Échec des vérifications

Voici des causes possibles de l'échec d'un test de disponibilité :

Erreur de connexion - Refusée : si vous utilisez le type de connexion HTTP par défaut, vérifiez qu'un serveur Web est installé et qu'il répond aux requêtes HTTP. Une erreur de connexion peut se produire sur une nouvelle instance si vous n'avez pas installé de serveur Web. Consultez le démarrage rapide pour Compute Engine. Si vous utilisez le type de connexion HTTPS, vous devrez peut-être effectuer des étapes de configuration supplémentaires. Pour les problèmes de pare-feu, consultez la section Lister les adresses IP des serveurs de test de disponibilité.
Nom ou service introuvable : le nom d'hôte est peut-être incorrect.
403 (interdit) : le service renvoie un code d'erreur au vérificateur de tests de disponibilité. Par exemple, la configuration par défaut du serveur Web Apache renvoie ce code sous Amazon Linux, mais elle renvoie le code 200 (succès) sous d'autres versions de Linux. Consultez le tutoriel LAMP pour Amazon Linux ou la documentation de votre serveur Web.

Si ce message d'erreur s'affiche et que la cible de votre vérification du temps d'activité est un service Cloud Run, assurez-vous de disposer de l'autorisation run.routes.invoke sur ce service.
404 (introuvable) : le chemin d'accès est peut-être incorrect.
408 (Délai avant expiration de la requête) ou absence de réponse : le numéro de port est peut-être incorrect, le service ne fonctionne peut-être pas ou est peut-être inaccessible, ou le délai avant expiration est peut-être trop court. Vérifiez que votre pare-feu autorise le trafic provenant des serveurs de test de disponibilité. Pour en savoir plus, consultez Lister les adresses IP des serveurs de test de disponibilité. Le délai avant expiration est spécifié dans les options de validation de réponse.

Un délai d'inactivité de la requête peut se produire en raison de l'encombrement du réseau. Par exemple, en raison d'une congestion temporaire du réseau, vous remarquerez peut-être qu'un vérificateur échoue, mais que tous les autres réussissent. L'échec d'un seul vérificateur n'entraîne pas de notification lorsque votre règle d'alerte utilise la configuration par défaut.

Si votre test de disponibilité est configuré pour envoyer des pings, les résultats des pings pour les tests de disponibilité ayant échoué sont écrits dans Cloud Logging. Pour en savoir plus, consultez Utiliser les pings ICMP.

Limites

Les vérifications du temps d'activité publiques ne sont pas compatibles avec les périmètres VPC Service Controls. Les tests de disponibilité privés peuvent se trouver dans un périmètre VPC Service Controls. Pour en savoir plus, consultez Créer des tests de disponibilité privés.

Créer des tests de disponibilité publics Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

À propos des tests de disponibilité

Avant de commencer

Console

gcloud

Terraform

C#

Go

Java

Node.js

PHP

Python

Ruby

REST

Créer un test de disponibilité

Console

gcloud

Terraform

C#

Java

Go

Node.js

PHP

Python

Ruby

REST

Utiliser les pings ICMP

Configurer les pings

Vérifier le test de disponibilité

Vérifications réussies

Échec des vérifications

Limites

Étapes suivantes

Créer des tests de disponibilité publics