Ce document explique comment créer un test de disponibilité public. Un test de disponibilité public peut envoyer des requêtes depuis plusieurs emplacements dans le monde entier vers des URL ou des ressources Google Cloud accessibles au public pour voir si la ressource répond. Pour savoir comment créer des tests de disponibilité pour des réseaux privés, consultez la section Créer des tests de disponibilité privés.
Les tests de disponibilité publics peuvent déterminer la disponibilité des ressources suivantes:- URL du test de disponibilité
- Instance de VM
- Application App Engine
- Service Kubernetes
- Instance Amazon Elastic Compute Cloud (EC2)
- Équilibreur de charge Amazon ELB
- Révision dans Cloud Run
Pour obtenir des liens vers des informations sur la gestion et la surveillance de vos tests de disponibilité, consultez la section Étape suivante de ce document.
À propos des tests de disponibilité
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 n'ont pas de contenus obligatoires, ou les contenus obligatoires sont présents.
Les tests de disponibilité ne chargent pas les éléments de page et n'exécutent pas JavaScript. La configuration par défaut d'un test de disponibilité n'inclut pas l'authentification.
Avant de commencer
-
Pour obtenir les autorisations nécessaires pour créer des vérifications de l'état de disponibilité, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet:
-
Éditeur Monitoring (
roles/monitoring.editor
) : utilisateurs de la console Google Cloud -
Éditeur de configuration des tests de disponibilité Monitoring (
roles/monitoring.uptimeCheckConfigEditor
) – Utilisateurs de l'API -
Éditeur de règles d'alerte Monitoring (
roles/monitoring.alertPolicyEditor
) : utilisateurs de l'API -
Éditeur Monitoring NotificationChannel (
roles/monitoring.notificationChannelEditor
) : utilisateurs de l'API
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.
-
Éditeur Monitoring (
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 la section Créer des tests de disponibilité privés.
Lorsque votre ressource se trouve derrière un pare-feu, configurez-le pour autoriser le trafic entrant à partir des adresses IP des serveurs de test de disponibilité. Pour en savoir plus, consultez la section Lister les adresses IP des serveurs de vérification de l'état.
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 la page Créer et gérer des canaux de notification.
Identifiez au moins trois vérificateurs pour votre test de disponibilité. La région
USA
du test de disponibilité inclut les régionsUSA_OREGON
,USA_IOWA
etUSA_VIRGINIA
. Chacune des régionsUSA_*
dispose d'un vérificateur, etUSA
les inclut toutes les trois. Les autres régions de test de disponibilité,EUROPE
,SOUTH_AMERICA
etASIA_PACIFIC
, possèdent chacune un vérificateur.Si vous sélectionnez Global lors de l'utilisation de Google Cloud Console ou
REGION_UNSPECIFIED
lors de l'utilisation de l'API, les tests de disponibilité sont émis à partir de toutes les régions.
Créer un test de disponibilité
Cette section explique comment créer et configurer des tests de disponibilité.
Pour créer une vérification de l'état de disponibilité d'un équilibreur de charge externe qui comporte au moins un port TCP ou HTTP/S configuré, vous pouvez suivre ces instructions. Vous pouvez également accéder à la page Informations sur le service du 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.
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.
Cliquez sur Create Uptime Check (Créer un test de disponibilité).
Spécifiez la cible du test de disponibilité :
Sélectionnez le protocole. Vous pouvez sélectionner HTTP, HTTPS ou TCP.
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.
- Instance : instances Compute Engine ou AWS EC2.
- App Engine : applications App Engine (modules).
- Elastic Load Balancer : équilibreur de charge AWS.
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 votre 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 surexample.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 d'accès vide. Pour émettre le test de disponibilité au gestionnaire/hello
, définissez la valeur du champ Path (Chemin d'accès) sur/hello
.
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
.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 un test de disponibilité à une seule instance ou à un seul équilibreur de charge, sélectionnez Simple, puis utilisez le menu pour sélectionner l'instance ou l'équilibreur de charge spécifique.
- Pour émettre un test de disponibilité dans un groupe Monitoring, sélectionnez Groupe, puis utilisez le menu pour sélectionner le nom du groupe.
Facultatif: Pour définir la fréquence d'exécution du test de disponibilité, utilisez le champ Check frequency (Fréquence de vérification).
Facultatif: Pour sélectionner des régions de vérification ou des certificats SSL, l'authentification, les en-têtes et les ports pour les vérifications HTTP et HTTPS, cliquez sur Autres 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 comporte trois vérificateurs. Le paramètre par défaut, Global, inclut toutes les régions.
- Pings ICMP: configurez le test de disponibilité pour envoyer jusqu'à trois pings. Pour en savoir plus, consultez Utiliser des pings ICMP.
- Méthode de requête: pour les vérifications HTTP, sélectionnez la méthode de requête.
- Body (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: renseignez ce champ pour tester des 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 sous la forme d'un en-tête d'autorisation. Ce champ n'est pas disponible pour les tests TCP.
parmi les options suivantes :
- Authentification de base: indiquez un seul nom d'utilisateur et un seul 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 tests 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 valide le certificat SSL. Les tests de disponibilité échouent si une URL comporte un certificat non valide. Un certificat peut ne pas être valide pour diverses raisons:
- Un certificat expiré
- Un certificat autosigné
- Certificat avec erreur de correspondance du nom de domaine
- Certificat qui utilise l'extension AIA (Authority Information Access).
Pour forcer un test de disponibilité HTTPS à 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é.Cochez la case Valider les certificats SSL.
Cliquez sur Continuer, puis configurez les exigences concernant les réponses. 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 si aucune réponse n'est reçue de plusieurs emplacements dans ce délai.
Pour configurer le test de disponibilité pour effectuer une correspondance de contenu, assurez-vous que le libellé d'activation est La correspondance de contenu est activée:
- Sélectionnez le type de correspondance du contenu de la réponse dans le menu des 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 de contenu soit Contient. Le test de disponibilité n'aboutit que lorsque les données de réponse contiennentabcd
. 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 1 024 octets maximum. Dans l'API, ce champ est l'objet
ContentMatcher
.
- Sélectionnez le type de correspondance du contenu de la réponse dans le menu des 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
Pour empêcher la création d'entrées de journal en raison de tests de disponibilité, effacez Échecs de vérification du journal.
Pour les vérifications de disponibilité HTTP, configurez les codes de réponse acceptés. Par défaut, les tests de disponibilité HTTP marquent toute réponse
2xx
comme une réponse réussie.
Cliquez sur Continuer, puis configurez les notifications.
Pour être averti 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:
- Facultatif: modifiez le nom de la règle d'alerte.
- Facultatif: Dans le champ Durée, sélectionnez la durée pendant laquelle les vérifications de disponibilité doivent échouer avant l'envoi de notifications. Par défaut, des notifications sont envoyées lorsqu'au moins deux régions signalent des échecs de test de disponibilité pendant au moins une minute.
Dans la zone Canaux de notification, cliquez sur arrow_drop_down 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 d'activation est Ne pas créer d'alerte.
Cliquez sur Continuer et effectuez votre test de disponibilité:
Saisissez un titre descriptif pour le test de disponibilité.
Facultatif: Pour ajouter des libellés définis par l'utilisateur à votre test de disponibilité, procédez comme suit:
- Cliquez sur expand_more Afficher les étiquettes utilisateur.
- Dans le champ Clé, saisissez un nom pour le libellé.
Les noms de libellé 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
. - Dans le champ Valeur, saisissez une valeur pour votre libellé. Les valeurs de libellé peuvent contenir des lettres minuscules, des chiffres, des traits de soulignement et des tirets. Par exemple, saisissez
critical
. - Pour chaque libellé supplémentaire, cliquez sur Ajouter un libellé utilisateur, puis saisissez la clé et la valeur du libellé.
Pour vérifier la configuration du test disponibilité, cliquez sur Test (Tester). Si le résultat ne correspond pas à vos attentes, consultez la section Échec du test, corrigez votre configuration, puis effectuez à nouveau l'étape de vérification.
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.
Pour créer le test de disponibilité, exécutez la commande gcloud monitoring uptime create
:
gcloud monitoring uptime create DISPLAY_NAME REQUIRED_FLAGS OPTIONAL_FLAGS
Avant d'exécuter la commande précédente, procédez comme suit:
Remplacez DISPLAY_NAME par le nom de votre vérification de l'état de disponibilité.
Configurez REQUIRED_FLAGS pour spécifier la ressource explorée par le test de disponibilité. Par exemple, la commande suivante crée une vérification de l'état de disponibilité qui teste l'URL EXAMPLE.com pour un projet particulier:
gcloud monitoring uptime create
DISPLAY_NAME \ --resource-labels=host=EXAMPLE.com ,project_id=PROJECT_ID \ --resource-type=uptime-urlLa commande précédente spécifie les valeurs pour chaque libellé requis par le type de ressource
uptime-url
.Configurez les indicateurs OPTIONAL_FLAGS pour remplacer les valeurs par défaut. Par exemple, vous devez définir l'indicateur
--protocol
lorsque le protocole n'est pashttp
.
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. Il doit s'agir du nom du projet dans lequel créer le test de disponibilité. Remplacez
PROJECT_ID
par l'ID de votre projet Google Cloud. Il 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 quelques champs. Pour obtenir une documentation complète sur cet objet et ses champs, consultez la pageUptimeCheckConfig
: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'objetUptimeCheckConfig
. Dans cet objet, définissez le champrequestMethod
surGET
ouPOST
. Si ce champ est omis ou défini surMETHOD_UNSPECIFIED
, une requêteGET
est émise.Si vous configurez une requête
POST
, renseignez les champscontentType
,customContentType
facultatif etbody
.
La méthode create
renvoie l'objet UptimeCheckConfig
pour la nouvelle configuration.
Si la configuration du test de disponibilité créé ne fonctionne pas comme prévu, consultez la section Échec du test de cette page.
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.
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.
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.
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.
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.
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.
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.
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 test de disponibilité et une règle d'alerte pour le surveiller, procédez comme suit:
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" }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é.
Pour créer un canal de notification, procédez comme suit:
-
Dans la console Google Cloud, accédez à la page notificationsAlertes :
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.
- Sélectionnez Gérer les canaux de notification.
- Accédez au type de canal que vous souhaitez ajouter, cliquez sur Ajouter, puis remplissez la boîte de dialogue.
-
Pour créer une règle d'alerte, 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.
- Recherchez votre test de disponibilité, sélectionnez more_vert Plus, puis Ajouter une règle d'alerte.
- Dans la boîte de dialogue, accédez à la section Notifications et nom, développez Canaux de notification, puis effectuez vos sélections.
- Attribuez un nom à 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.
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 des pings ICMP
Pour vous aider à résoudre les problèmes de test de disponibilité public 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 avant expiration dans votre application.
Par défaut, les tests de disponibilité n'envoient pas de pings. Chaque ping ajoute une 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
: temps aller-retour pour chaque requête ping non réussie.unreachable_count
: nombre de requêtes ping ayant renvoyé le code d'étatICMP_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 de l'état de disponibilité 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 avec chaque vérification, jusqu'à trois. Par défaut, aucun ping n'est envoyé.
Pour configurer des pings, procédez comme suit:
Lorsque vous utilisez la console Google Cloud, développez Autres options de cible et saisissez une valeur dans le champ Pings ICMP.
Lorsque vous utilisez l'API Cloud Monitoring, utilisez l'objet
PingConfig
, qui a la structure suivante:{ "pingsCount": integer }
Pour en savoir plus sur l'utilisation de l'API Monitoring pour les configurations de vérification de l'état de fonctionnement, consultez Créer une vérification de l'état de fonctionnement: API ou Modifier une vérification de l'état de fonctionnement: 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 d'enregistrer.
Vérifications réussies
Pour qu'un test de disponibilité réussisse, les conditions suivantes doivent être remplies:
- L'état HTTP correspond aux critères que vous avez sélectionnés.
- La réponse n'a pas de contenus obligatoires, ou la recherche des contenus obligatoires dans la réponse a abouti.
Tests ayant échoué
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.
- 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 tests de disponibilité. Consultez la section Répertorier 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'expiration de la requête peut se produire en raison de la congestion du réseau. Par exemple, en raison d'une congestion temporaire du réseau, vous pouvez constater qu'un vérificateur échoue, mais que tous les autres réussissent. L'échec d'un seul vérificateur ne déclenche 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é échoués sont écrits dans Cloud Logging. Pour en savoir plus, consultez la section Utiliser des pings ICMP.
Étape suivante
- Gérer les tests de disponibilité
- Créer des règles d'alerte pour les tests de disponibilité
- Répertorier les adresses IP des serveurs de test de disponibilité
- Créer un graphique des métriques de test de disponibilité