Un test de disponibilité est une requête envoyée à une ressource pour voir si elle répond. Vous pouvez utiliser des tests de disponibilité pour déterminer la disponibilité d'une instance de VM, d'un service App Engine, d'une URL ou d'un équilibreur de charge AWS.
Vous pouvez surveiller la disponibilité d'une ressource en créant une règle d'alerte qui crée un incident en cas d'échec du test de disponibilité. Vous pouvez configurer la règle d'alerte pour vous avertir par e-mail ou via un autre canal. Cette notification peut inclure des détails sur la ressource qui n'a pas pu répondre. Vous avez également la possibilité d'observer les résultats des tests de disponibilité dans les tableaux de bord des tests de disponibilité Monitoring.
Cette page vous explique comment :
- créer un test de disponibilité ;
- afficher le tableau de bord d'un test de disponibilité ;
- modifier un test de disponibilité ;
- supprimer un test de disponibilité.
Consultez la section Étape suivante pour obtenir des liens vers des pages de tarification et des pages décrivant la surveillance de vos tests de disponibilité.
Avant de commencer
Les pare-feu qui protègent votre service ont une incidence sur votre utilisation des tests de disponibilité.
- Si la ressource que vous testez n'est pas accessible en mode public, vous devez configurer son pare-feu de façon à autoriser le trafic entrant à partir des serveurs de tests de disponibilité. Pour télécharger la liste des adresses IP, consultez la section Obtenir des adresses IP.
- Si la ressource que vous testez n'a pas d'adresse IP externe, les tests de disponibilité ne peuvent pas l'atteindre.
Le test de disponibilité ne charge pas les éléments de page et n'exécute pas JavaScript. La configuration par défaut d'un test de disponibilité n'inclut pas l'authentification.
Pour HTTP et HTTPS, si la réponse est une redirection vers une autre URL, la vérification récupère les données de cette URL. Enfin, le test de disponibilité évalue les données pour déterminer s'il a réussi ou échoué.
Pour réussir, les conditions suivantes doivent être remplies :
- L'état HTTP est
Success
. - Les données n'ont pas de contenus obligatoires, ou les contenus obligatoires sont présents.
- L'état HTTP est
Créer un test de disponibilité
Cette section explique comment créer et configurer des tests de disponibilité.
Console
Pour créer un test de disponibilité à l'aide de Google Cloud Console, procédez comme suit :
Dans Cloud Console, sélectionnez Surveillance :
Cliquez sur Tests de disponibilité.
Cliquez sur Create Uptime Check (Créer un test de disponibilité).
Saisissez un titre descriptif pour le test de disponibilité, puis cliquez sur Suivant.
Spécifiez la cible du test de disponibilité :
Sélectionnez le protocole. Vous disposez des options HTTP, HTTPS et 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.
- App Engine : applications App Engine (modules).
- Instance : instances Compute Engine ou AWS EC2.
- 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 avez la possibilité de 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/
.Pour émettre un test de disponibilité sur la ressource d'URL
example.com/tester
, définissez le champ de nom d'hôte surexample.com
et le champ du chemin d'accès sur/tester
.Supposons que vous ayez déployé un serveur sur App Engine avec un coordinateur compatible avec
/
et/hello
. Si vous laissez le champ de chemin vide, le test de disponibilité est envoyé au gestionnaire/
. Pour émettre le test de disponibilité au gestionnaire/hello
, définissez la valeur du champ de chemin 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 les champs suivants :
- Pour émettre un test de disponibilité à une seule instance ou à un seul équilibreur de charge, dans le champ S'applique à, 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, dans le champ Applicable à, sélectionnez Groupe, puis utilisez le menu pour sélectionner le nom du groupe.
Le champ Fréquence de consultation contrôle la fréquence d'exécution du test de disponibilité. Vous pouvez conserver la valeur par défaut ou sélectionner une valeur dans le menu des options.
Pour configurer 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.
- Général : 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 des en-têtes 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 : indiquez un seul nom d'utilisateur et un mot de passe. Ces valeurs sont envoyées sous la forme d'un en-tête d'autorisation. Si vous définissez des valeurs dans ce champ, ne définissez pas un en-tête d'autorisation distinct. Inversement, si vous définissez un en-tête d'autorisation, ne définissez aucune valeur dans ce champ. Les mots de passe sont toujours masqués dans le formulaire. Ce champ n'est pas disponible pour les tests TCP.
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. Le test de disponibilité échoue si une URL comporte un certificat non valide. Les raisons d'un certificat non valide incluent un certificat arrivé à expiration, un certificat autosigné, un certificat avec une erreur de nom de domaine et un certificat utilisant l'extension AIA.
Pour forcer un test de disponibilité HTTPS à valider le certificat SSL, assurez-vous que l'option Valider les certificats SSL est sélectionnée.
Pour désactiver la validation des certificats SSL, assurez-vous que l'option Valider les certificats SSL n'est pas sélectionnée.
Si vous disposez de certificats SSL avec des extensions d'autorisation d'accès aux informations (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 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 Suivant.
Configurez les exigences portant sur les réponses comme suit :
Sélectionnez le délai avant expiration de la réponse dans le menu des options. Vous pouvez choisir une valeur comprise entre
1
et60
secondes. Un test de disponibilité échoue si aucune réponse n'est reçue de plusieurs emplacements dans ce délai.Pour la 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, si le contenu de la réponse est
abcd
et que le type de correspondance du contenu est Contient, le test de disponibilité réussit si les données de réponse contiennentabcd
. Le test de disponibilité échoue si la réponse ne contient pasabcd
. - Saisissez le contenu de la réponse. Il doit s'agir d'une chaîne qui ne dépasse pas 1 024 octets. Dans l'API, il s'agit de 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, si le contenu de la réponse est
Si vous ne souhaitez pas que les tests de disponibilité soient envoyés à Cloud Logging, décochez la case Consigner les échecs de vérification.
Cliquez sur Suivant.
Créer une règle d'alerte Lorsqu'un test de disponibilité surveillé par une règle d'alerte échoue, un incident est créé et une notification envoyée à tous les canaux de notification associés à la règle. Par exemple, si vous ajoutez une adresse e-mail à la règle, un e-mail est envoyé à cette adresse. Vous pouvez créer la règle d'alerte à cette étape ou après la création du test de disponibilité.
Si vous ne souhaitez pas créer de règle d'alerte dans le cadre de ce flux, assurez-vous que le texte du bouton d'activation est Ne pas créer d'alerte. Cliquez sur le bouton pour le faire changer d'état.
Pour créer une règle d'alerte dans le cadre de ce flux, procédez comme suit :
Assurez-vous que le texte du bouton d'activation indique Créer une alerte. Si nécessaire, cliquez sur le bouton.
Dans le champ du nom, saisissez un nom pour la règle d'alerte ou utilisez le nom par défaut.
Pour ajouter un ou plusieurs canaux de notification à la règle d'alerte, dans la zone de texte intitulée Canaux de notification, cliquez sur Menu arrow_drop_down. Sélectionnez les canaux à ajouter, puis cliquez sur OK. Les canaux de notification sont classés par ordre alphabétique pour chaque type de canal.
Si un canal de notification que vous souhaitez ajouter à la règle d'alerte n'est pas répertorié, cliquez sur Gérer les canaux de notification.
La fenêtre Canaux de notification s'affiche dans un nouvel onglet du navigateur. Ajoutez les canaux de notification, puis revenez à cet onglet, cliquez sur Actualiser refresh, puis sélectionnez les canaux de notification à ajouter à la règle d'alerte.
Dans le champ de durée, sélectionnez la durée pendant laquelle les tests de disponibilité doivent échouer avant la création d'un incident. Par défaut, la règle d'alerte est configurée pour créer un incident si au moins deux régions signalent des échecs de test pendant une minute.
Consultez la section Gérer les règles pour en savoir plus sur la désactivation, la modification et la suppression des règles d'alerte.
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 ci-dessous, corrigez votre configuration et effectuez à nouveau l'étape de vérification.
Cliquez sur Créer. Si les données requises sont manquantes, l'opération d'enregistrement échoue et la liste des champs nécessitant des données s'affiche à côté des boutons de la boîte de dialogue. Une fois les modifications enregistrées, la boîte de dialogue Uptime check created (Test de disponibilité créé) apparaît.
API
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 ne contient que 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'object 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
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.
C#
Java
Go
Node.js
PHP
Python
Ruby
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".
Identifiants pour les tests de disponibilité
Lorsque votre test de disponibilité est créé, Monitoring lui attribue un identifiant appelé ID de test de disponibilité. Cet identifiant est intégré au nom de la ressource pour le nouveau test de disponibilité :
projects/PROJECT_ID/uptimeCheckConfigs/UPTIME_CHECK_ID
Vous pouvez obtenir l'ID de test de disponibilité dans la réponse d'un appel de méthode pour créer ou répertorier les tests de disponibilité. Vous pouvez également trouver l'ID de test de disponibilité dans la fenêtre Détails du test, en dessous de la section Configuration.
Vérifier le test de disponibilité
Lorsque vous créez un test de disponibilité dans Cloud Console, vous pouvez tester la configuration avant d'enregistrer.
Succès du test
Pour qu'un test de disponibilité réussisse, deux conditions doivent être remplies :
- L'état HTTP est
Success
. - La réponse n'a pas de contenus obligatoires, ou la recherche des contenus obligatoires dans la réponse a abouti.
Échec du test
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. Cette erreur peut se produire sur une nouvelle instance si vous n'avez pas installé de serveur Web. Consultez la page 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 Obtenir des adresses IP.
- 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 de serveurs de tests de disponibilité. Consultez la section Obtenir des adresses IP. Le délai avant expiration est spécifié dans la partie Vérification de l'état des options avancées.
Afficher un test de disponibilité
Pour afficher un test de disponibilité, procédez comme suit :
Console
Pour afficher l'état détaillé d'un test de disponibilité, procédez comme suit :
Dans Cloud Console, sélectionnez Surveillance :
Cliquez sur Tests de disponibilité.
Pour afficher la fenêtre Uptime details (Détails du test), localisez le test de disponibilité que vous souhaitez afficher, puis cliquez sur son nom.
La capture d'écran ci-dessous montre les détails du test de disponibilité "My Uptime Check" :
La fenêtre Uptime details (Détails du test) contient les informations suivantes :
- Intervalle de temps sélectionné. Par défaut, l'intervalle est défini sur 1 hour (1 heure).
- Nom du test de disponibilité. Dans cet exemple, le nom est My Uptime Check.
Pourcentage de disponibilité et latence moyenne. La valeur Percent uptime (Pourcentage de disponibilité) est un pourcentage calculé comme suit :
(S/T)*100
, oùS
représente le nombre de réponses de test ayant abouti etT
le nombre total de réponses de test, pour tous les emplacements. Pour les tests de groupe, les valeurs deS
etT
sont additionnées pour tous les membres actuels du groupe.Par exemple, sur une période de 25 minutes, un test de disponibilité d'une période d'une minute dans toutes les régions reçoit 25 requêtes de chacune des six zones, pour un total de 150 requêtes. Si le tableau de bord indique une disponibilité de 83,3 %, cela signifie que 125 requêtes sur 150 ont abouti.
Les volets Passed checks (Tests réussis) et Uptime check latency (Latence du test de disponibilité) fournissent une représentation graphique du nombre de tests réussis et de la latence de chaque test en fonction du temps.
Le volet Current Status (État actuel) affiche l'état des tests les plus récents. Un cercle vert avec une coche à côté d'une région indique que la dernière exécution du test a réussi dans cette région. En revanche, un cercle rouge avec un "X" signifie qu'elle a échoué.
Le volet Configuration affiche la configuration du test de disponibilité. Ces données sont attribuées lors de la création du test de disponibilité. La valeur Check ID (ID du test de disponibilité) correspond à la valeur
UPTIME_CHECK_ID
dans les appels d'API.Le volet Alert Policies (Règles d'alerte) fournit des informations sur les règles d'alerte associées. Dans l'exemple de tableau de bord, une règle d'alerte est configurée.
C#
Java
Go
Node.js
PHP
Python
Ruby
Modifier un test de disponibilité
Le protocole de test de disponibilité, le type de ressource et la ressource surveillée ne peuvent pas être modifiés. Si vous souhaitez modifier ces champs, vous devez créer un test de disponibilité avec la configuration appropriée. Cependant, tous les autres champs d'un test de disponibilité peuvent être modifiés après la création du test.
Pour modifier une règle d'alerte associée à un test de disponibilité, dans le volet de navigation Monitoring, cliquez sur notifications Alertes, sélectionnez la règle à modifier, puis cliquez sur Modifier.
Pour modifier un test de disponibilité, procédez comme suit :
Console
Dans Cloud Console, sélectionnez Surveillance :
Cliquez sur Tests de disponibilité.
Localisez le test de disponibilité que vous souhaitez modifier, puis effectuez l'une des opérations suivantes :
- Cliquez sur Plus more_vert et sélectionnez Modifier.
- Affichez les détails du test de disponibilité, puis cliquez sur Modifier.
Modifiez les valeurs des champs selon vos besoins. Vous ne pouvez pas modifier tous les champs. Si les valeurs d'en-têtes personnalisés d'un test sont masquées, vous ne pouvez pas les rendre visibles.
Pour vérifier si le test fonctionne, cliquez sur Tester. Si le test échoue, consultez la section Échec du test pour identifier les causes possibles.
Cliquez sur Save.
API
Appelez la méthode projects.uptimeCheckConfigs.patch
. Définissez les paramètres associés à la méthode comme suit :
uptimeCheckConfig.name : obligatoire. Ce paramètre fait partie de l'URL REST. Il s'agit du nom de ressource du test de disponibilité à modifier :
projects/PROJECT_ID/uptimeCheckConfigs/UPTIME_CHECK_ID
Vous pouvez obtenir la valeur de UPTIME_CHECK_ID à partir des réponses des méthodes
create
oulist
. L'ID ne s'affiche pas dans Cloud Console.updateMask : facultatif. Il s'agit d'un paramètre de requête :
?updateMask=[FIELD_LIST]
.[FIELD_LIST]
est une liste de champs séparés par une virgule dans l'objetUptimeCheckConfig
à modifier. Exemple :"resource.type,httpCheck.path"
Le corps de la requête doit contenir un objet
UptimeCheckConfig
avec les nouvelles valeurs de champ.
Si updateMask
est défini, seuls les champs répertoriés dans updateMask
remplacent les champs correspondants dans la configuration existante. Si un champ comporte des sous-champs et qu'il est répertorié dans le masque de champ, mais qu'aucun de ses sous-champs ne l'est, tous les sous-champs remplacent les champs correspondants.
Si updateMask
n'est pas défini, la configuration figurant dans le corps de la requête remplace l'ensemble de la configuration existante.
La méthode patch
renvoie l'objet UptimeCheckConfig
pour la configuration modifiée.
C#
Java
Go
Node.js
PHP
Python
Ruby
Il peut s'écouler jusqu'à 5 minutes avant que vous ne voyiez les résultats du nouveau test de disponibilité. Pendant ce temps, les résultats de l'ancien test de disponibilité sont affichés dans les tableaux de bord et utilisés dans les règles d'alerte.
Supprimer un test de disponibilité
Si vous essayez de supprimer un test de disponibilité à l'aide de Cloud Console et qu'une règle d'alerte dépend de ce test, l'opération de suppression échoue. Réessayez la suppression après avoir supprimé le test de disponibilité de toutes les règles d'alerte qui l'utilisent.
Si vous tentez de supprimer un test de disponibilité à l'aide de l'API Cloud Monitoring, le test de disponibilité est supprimé même si des règles d'alerte dépendent de la vérification. Aucune erreur n'est générée. Aucun incident n'est créé pour la vérification manquante. Avant de supprimer un test de disponibilité, assurez-vous qu'aucune règle d'alerte ne dépend de ce test.
Pour supprimer un test de disponibilité, procédez comme suit :
Console
Dans Cloud Console, sélectionnez Surveillance :
Cliquez sur Tests de disponibilité.
Localisez le test de disponibilité que vous souhaitez modifier, puis effectuez l'une des opérations suivantes :
- Cliquez sur Plus more_vert et sélectionnez Supprimer.
- Affichez les détails du test de disponibilité, puis cliquez sur Supprimerdelete.
API
Appelez la méthode projects.uptimeCheckConfigs.delete
. Spécifiez le paramètre comme suit :
name : obligatoire. Il s'agit du nom de ressource de la configuration de test de disponibilité à supprimer :
projects/PROJECT_ID/uptimeCheckConfigs/UPTIME_CHECK_ID
Vous pouvez obtenir la valeur de UPTIME_CHECK_ID à partir des réponses des méthodes
create
oulist
. L'ID ne s'affiche pas dans Cloud Console.
C#
Java
Go
Node.js
PHP
Python
Ruby
Étape suivante
- Pour connaître les tarifs et les limites applicables aux tests de disponibilité, consultez la section Tarifs et limites.
- Pour afficher la liste de tous les tests de disponibilité, consultez la page Examiner les tests de disponibilité.
- Pour obtenir la liste des adresses IP pouvant être employées pour effectuer des tests de disponibilité, consultez la section Obtenir des adresses IP.
- Pour déterminer l'état de vos tests de disponibilité à l'aide de l'API, surveillez la métrique
monitoring.googleapis.com/uptime_check/check_passed
. Pour en savoir plus, consultez la liste des métriques Google Cloud.