Résoudre les problèmes liés aux surveillances synthétiques et aux tests de disponibilité

Ce document explique comment trouver les données de journaux et résoudre les problèmes liés aux échecs des tests de disponibilité et des moniteurs synthétiques :

• Rechercher des journaux
• Résoudre les problèmes liés aux notifications
• Résoudre les problèmes liés aux tests de disponibilité publics
• Résoudre les problèmes liés aux tests de disponibilité privés
• Résoudre les problèmes liés à la surveillance synthétique

Rechercher des journaux

Cette section explique comment trouver les journaux de vos tests de disponibilité et de vos synthétiques :

1. Dans la console Google Cloud , accédez à la page Explorateur de journaux.

   Accéder à l'explorateur de journaux

   Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Logging.

2. Dans la barre d'outils de la console Google Cloud , sélectionnez votre projet Google Cloud . Pour les configurations App Hub, sélectionnez le projet hôte App Hub ou le projet de gestion du dossier compatible avec les applications.

3. Effectuez l'une des actions suivantes :

   • Pour trouver tous les journaux associés à vos tests de disponibilité ou à vos synthétiques, interrogez-les par type de ressource. Vous pouvez utiliser le menu Ressource ou saisir une requête.

     Pour les tests de disponibilité, dans le menu Ressource, sélectionnez URL du test de disponibilité, ou saisissez la requête suivante dans l'éditeur de requête, puis cliquez sur Exécuter la requête :

     resource.type="uptime_url"
     

     Pour les vérifications synthétiques, dans le menu Ressource, sélectionnez Révision dans Cloud Run, ou saisissez la requête suivante dans l'éditeur de requête, puis cliquez sur Exécuter la requête :

     resource.type="cloud_run_revision"
     

   • Pour trouver les journaux contenant des informations sur la réponse reçue lors de l'exécution d'un test de disponibilité ou d'un monitor synthétique, procédez comme suit :

     • Pour interroger les données à l'aide de l'ID du test de disponibilité ou du moniteur synthétique, utilisez le format suivant lorsque vous saisissez l'ID dans l'éditeur de requête, puis cliquez sur Exécuter la requête.

       labels.check_id="my-check-id"
       

     • Pour interroger les journaux contenant des données de réponse pour les requêtes émises par les vérifications de disponibilité et les moniteurs synthétiques, saisissez la requête suivante dans l'éditeur de requête, puis cliquez sur Exécuter la requête.

       "UptimeCheckResult"
       

       La requête précédente correspond à toutes les entrées de journal qui incluent la chaîne "UptimeCheckResult".

     Ces journaux incluent les éléments suivants :

     • ID de la surveillance synthétique ou du test de disponibilité, stocké dans le champ labels.check_id.

     • Pour les monitors synthétiques, le nom de votre fonction Cloud Run, stocké dans le champ resource.labels.service_name.

     • Lorsque des données de trace sont collectées, l'ID d'une trace associée est stocké dans le champ trace.

   • Pour vérifier que votre service a reçu des requêtes de serveurs Google Cloud , copiez la requête suivante dans l'éditeur de requête, puis cliquez sur Exécuter la requête :

     "GoogleStackdriverMonitoring-UptimeChecks"
     

     Le champ protoPayload.ip contient l'une des adresses utilisées par les serveurs de tests de disponibilité. Pour savoir comment lister toutes les adresses IP, consultez Lister les adresses IP.

Résoudre les problèmes liés aux notifications

Cette section décrit certaines erreurs que vous pouvez rencontrer lors de la configuration des règles d'alerte et fournit des informations pour les résoudre.

Un vérificateur a échoué, mais pas les autres

Vous examinez vos métriques de test de disponibilité et remarquez qu'un vérificateur a signalé un échec alors que tous les autres ont signalé une réussite.

Aucune action n'est requise de votre part pour résoudre ce problème.

Lorsqu'un seul vérificateur signale un échec, cela peut être dû à un délai d'expiration de la commande du vérificateur en raison d'un problème de réseau. Autrement dit, au lieu d'échouer, la commande ne se termine pas dans le délai spécifié.

Les règles d'alerte qui utilisent la configuration par défaut nécessitent des échecs d'au moins deux vérificateurs avant de créer un incident et d'envoyer une notification. Une défaillance signalée par un seul vérificateur n'entraîne pas l'envoi d'une notification.

Vous avez reçu une notification et vous souhaitez déboguer l'échec

1. Pour identifier le moment où l'échec a commencé, effectuez l'une des opérations suivantes :

   • Pour les tests de disponibilité, afin de déterminer quand l'échec s'est produit, consultez la page Détails sur la disponibilité :

     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 du dossier compatible avec les applications.

     3. Recherchez et sélectionnez le test de disponibilité.

        Le graphique Tests réussis affiche l'historique des vérifications. Pour identifier la date du premier échec du test de disponibilité, vous devrez peut-être modifier la plage de dates du graphique. Le sélecteur de période se trouve dans la barre d'outils de la page Détails de la disponibilité.

   • Pour les surveillances synthétiques, afin de déterminer quand l'échec s'est produit, consultez la page Détails sur la disponibilité :

     1. Dans la console Google Cloud , accédez à la page  Surveillance synthétique :

        Accéder à Surveillance synthétique

        Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.

     2. Dans la barre d'outils de la console Google Cloud , sélectionnez votre projet Google Cloud . Pour les configurations App Hub, sélectionnez le projet hôte App Hub ou le projet de gestion du dossier compatible avec les applications.
     3. Recherchez et sélectionnez le moniteur synthétique.

2. Pour savoir comment trouver les données de journaux associées, consultez la section Rechercher des journaux sur cette page.

Vous ne recevez pas de notification en cas d'échec d'un test de disponibilité

Vous avez configuré un test de disponibilité et vous consultez la page Détails du temps d'activité pour ce test. Vous remarquez que le graphique Vérifications réussies indique qu'au moins un vérificateur a échoué. Toutefois, vous n'avez pas reçu de notification.

Par défaut, la règle d'alerte est configurée pour créer un incident et envoyer une notification lorsque les vérificateurs d'au moins deux régions ne reçoivent pas de réponse à un test de disponibilité. Ces défaillances doivent se produire simultanément.

Vous pouvez modifier la condition de la règle d'alerte afin d'être averti lorsqu'une seule région ne reçoit pas de réponse. Toutefois, nous vous encourageons à utiliser la configuration par défaut, qui réduit le nombre de notifications que vous pourriez recevoir en raison d'échecs temporaires.

Pour afficher ou modifier une règle d'alerte, procédez comme suit :

1. Dans la console Google Cloud , accédez à la page notifications Alertes :

   Accéder à l'interface des alertes

   Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.

2. Dans la barre d'outils de la console Google Cloud , sélectionnez votre projet Google Cloud . Pour les configurations App Hub, sélectionnez le projet hôte App Hub ou le projet de gestion du dossier compatible avec les applications.
3. Cliquez sur Afficher toutes les règles dans le volet Règles.

4. Recherchez la règle que vous souhaitez afficher ou modifier, puis cliquez sur son nom.

   Vous pouvez consulter et modifier la règle sur la page Détails de la règle.

Résoudre les problèmes liés aux tests de disponibilité publics

Cette section décrit certaines erreurs que vous pouvez rencontrer lorsque vous utilisez des vérifications publiques du temps d'activité et fournit des informations pour les résoudre.

Vos tests de disponibilité publics échouent

Vous configurez un test de disponibilité public, mais vous recevez une erreur lorsque vous effectuez l'étape de validation.

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 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 Lister les adresses IP des serveurs de vérification de la 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 de serveurs de tests de disponibilité. Consultez la section Répertorier les adresses IP des serveurs de tests de disponibilité. Le délai avant expiration est spécifié dans les options de validation de réponse.

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. Pour en savoir plus, consultez Utiliser les pings ICMP.

Résoudre les problèmes liés aux tests de disponibilité privés

Cette section décrit certaines erreurs que vous pouvez rencontrer lorsque vous utilisez des vérifications privées du temps d'activité et fournit des informations pour les résoudre.

Échec de la création du test de disponibilité

Les paramètres de votre projet Google Cloud peuvent empêcher la modification des rôles attribués au compte de service utilisé par les vérifications du temps d'activité pour gérer les interactions avec le service Annuaire des services. Dans ce cas, la création du test de disponibilité échoue.

Cette section explique comment attribuer les rôles requis par le compte de service :

Accès refusé

Vos tests de disponibilité échouent et renvoient des résultats VPC_ACCESS_DENIED. Ce résultat signifie qu'un aspect de la configuration de votre réseau ou de l'autorisation du compte de service n'est pas correct.

Vérifiez l'autorisation de votre compte de service pour utiliser un projet de définition du champ d'application ou un projet surveillé, comme décrit dans Échec de la création du test de disponibilité.

Pour en savoir plus sur l'accès aux réseaux privés, consultez Configurer le projet de réseau.

Résultats anormaux des tests de disponibilité privés

Vous disposez d'un service Annuaire des services avec plusieurs VM, et votre configuration de service contient plusieurs points de terminaison. Lorsque vous arrêtez l'une des VM, votre test de disponibilité indique toujours que l'opération a réussi.

Lorsque la configuration de votre service contient plusieurs points de terminaison, l'un d'eux est choisi au hasard. Si la VM associée au point de terminaison choisi est en cours d'exécution, le test de disponibilité réussit même si l'une des VM est hors service.

En-têtes par défaut

Vos tests de disponibilité renvoient des erreurs ou des résultats inattendus. Cela peut se produire si vous avez remplacé les valeurs d'en-tête par défaut.

Lorsqu'une requête est envoyée pour un contrôle de disponibilité privé à un point de terminaison cible, elle inclut les en-têtes et valeurs suivants :

Si vous essayez de remplacer ces valeurs, les conséquences suivantes peuvent se produire :

• Le test de disponibilité signale des erreurs
• Les valeurs de remplacement sont supprimées et remplacées par les valeurs du tableau.

Aucune donnée visible

Vous ne voyez aucune donnée dans le tableau de bord des vérifications de disponibilité lorsque votre vérification de disponibilité se trouve dans un projet Google Cloud différent de celui du service Annuaire des services.

Assurez-vous que le projet Google Cloud qui contient la vérification du temps d'activité surveille le projet Google Cloud qui contient le service Annuaire des services.

Pour savoir comment lister les projets surveillés et en ajouter d'autres, consultez Configurer un champ d'application des métriques pour plusieurs projets.

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

Cette section fournit des informations qui peuvent vous aider à résoudre les problèmes liés à vos vérifications synthétiques.

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

Vous ouvrez le flux de création d'un moniteur synthétique et êtes invité à activer au moins une API. Une fois les API activées, un message semblable à celui-ci s'affiche :

An error occurred during fetching available regions: Cloud Functions API has
not been used in project PROJECT_ID before or it is disabled.

Le message d'erreur vous recommande de vérifier que l'API est activée, puis vous conseille d'attendre et de réessayer.

Pour vérifier que l'API est activée, accédez à la page API et services de votre projet :

Accéder aux API et services

Une fois que vous avez vérifié que l'API est activée, vous pouvez poursuivre le flux de création. La condition se résout automatiquement une fois que l'activation de l'API s'est propagée dans le backend.

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

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

Pour résoudre ce problème, assurez-vous que le rôle Agent Cloud Trace (roles/cloudtrace.agent) a été attribué à votre compte de service. Le rôle Éditeur (roles/editor) est également suffisant.

Pour afficher les rôles attribués à votre compte de service, procédez comme suit :

1. Dans la console Google Cloud , accédez à la page IAM :

   Accéder à IAM

   Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est IAM et administration.

2. Dans la barre d'outils de la console Google Cloud , sélectionnez votre projet Google Cloud . Pour les configurations App Hub, sélectionnez le projet hôte App Hub ou le projet de gestion du dossier compatible avec les applications.
3. Sélectionnez Inclure les attributions de rôles fournies par Google.

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

   Si vous ne connaissez pas le nom de votre compte de service, sélectionnez Comptes de service dans le menu de navigation.

État "En cours"

La page Surveillance synthétique liste une surveillance synthétique dont l'état est In progress. Un état In progress signifie que le monitor synthétique a été créé récemment et qu'il n'y a aucune donnée à afficher, ou que le déploiement de la fonction a échoué.

Pour déterminer si le déploiement de la fonction a échoué, procédez comme suit :

• Assurez-vous que le nom de votre fonction Cloud Run ne contient pas de trait de soulignement. Si un trait de soulignement est présent, supprimez-le et redéployez la fonction Cloud Run.

• Ouvrez la page Détails de la surveillance synthétique pour le moniteur synthétique.

  Si le message suivant s'affiche, supprimez le contrôleur synthétique.

  Cloud Function not found for this Synthetic monitor. Please confirm it exists or delete this monitor.
  

  Le message d'erreur indique que la fonction a été supprimée et que, par conséquent, la surveillance synthétique ne peut pas l'exécuter.

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

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

  This function has failed to deploy and will not work correctly. Please edit and redeploy
  

  Pour résoudre cet échec, examinez le code de la fonction et corrigez les erreurs qui empêchent la fonction d'être créée ou déployée.

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

État d'avertissement

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

État "Échec"

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

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

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

• Si l'échec renvoie une durée d'exécution de 0ms, il est possible que la fonction Cloud Run manque de mémoire. Pour résoudre ce problème, modifiez votre fonction Cloud Run, puis augmentez la mémoire à au moins 2 Gio et définissez le champ "CPU" sur 1.

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

Vous utilisez l'API Cloud Monitoring pour supprimer un test synthétique, mais l'appel d'API échoue et renvoie une réponse semblable à la suivante :

{
  "error": {
    "code": 400,
    "message": "Request contains an invalid argument.",
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.DebugInfo",
        "detail": "[ORIGINAL ERROR] generic::invalid_argument: Cannot delete check 1228258045726183344. One or more alerting policies is using it.Delete the alerting policy with id projects/myproject/alertPolicies/16594654141392976482 and any other policies using this uptime check and try again."
      }
    ]
  }
}

Pour résoudre l'échec, supprimez les règles d'alerte qui surveillent les résultats du moniteur synthétique, puis supprimez le moniteur synthétique.

Impossible de modifier la configuration d'un vérificateur de liens brisés

Vous avez créé un vérificateur de liens brisés à l'aide de la console Google Cloud et vous souhaitez modifier les éléments HTML testés, ou vous voulez modifier le délai d'expiration de l'URI, les tentatives, l'attente du sélecteur et les options par lien. Toutefois, lorsque vous modifiez le vérificateur de liens brisés, la console Google Cloud n'affiche pas les champs de configuration.

Pour résoudre ce problème, procédez comme suit :

1. Dans la console Google Cloud , accédez à la page  Surveillance synthétique :

   Accéder à Surveillance synthétique

   Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.

2. Dans la barre d'outils de la console Google Cloud , sélectionnez votre projet Google Cloud . Pour les configurations App Hub, sélectionnez le projet hôte App Hub ou le projet de gestion du dossier compatible avec les applications.
3. Localisez le monitor synthétique que vous souhaitez modifier, cliquez sur more_vert Plus d'options, puis sélectionnez Modifier.
4. Cliquez sur Modifier la fonction.

5. Modifiez l'objet options dans le fichier index.js, puis cliquez sur Appliquer la fonction.

   Pour en savoir plus sur les champs et la syntaxe de cet objet, consultez broken-links-ok/index.js.

6. Cliquez sur Enregistrer.

La consoleGoogle Cloud indique que l'enregistrement des captures d'écran a échoué.

Vous avez créé un vérificateur de liens non fonctionnels et l'avez configuré pour enregistrer des captures d'écran. Toutefois, la console Google Cloud affiche l'un des messages d'avertissement suivants, ainsi que des informations plus détaillées :

• InvalidStorageLocation
• StorageValidationError
• BucketCreationError
• ScreenshotFileUploadError

Pour résoudre ces échecs, essayez les solutions suivantes :

• Si le message InvalidStorageLocation s'affiche, vérifiez l'existence du bucket Cloud Storage spécifié dans le champ options.screenshot_options.storage_location.

• Affichez les journaux liés à votre fonction Cloud Run. Pour en savoir plus, consultez Rechercher des journaux.

• Vérifiez que le compte de service utilisé dans la fonction Cloud Run correspondante dispose d'un rôle Identity and Access Management qui lui permet de créer des buckets Cloud Storage, d'y accéder et d'y écrire.