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

Ce document explique comment rechercher les données des journaux et comment résoudre les échecs de la surveillance synthétique et des tests de disponibilité:

Rechercher des journaux

Cette section explique comment rechercher les journaux des moniteurs synthétiques et des tests de disponibilité:

  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 (Journalisation).

  2. Effectuez l'une des actions suivantes :

    • Pour rechercher tous les journaux associés à vos surveillances synthétiques ou tests de disponibilité, interrogez 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 surveillances 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 rechercher les journaux contenant des informations sur la réponse reçue lors d'une surveillance synthétique ou de l'exécution d'un test de disponibilité, effectuez l'une des opérations suivantes:

      • Pour effectuer une requête à l'aide de l'ID de la surveillance synthétique ou du test de disponibilité, 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 les données de réponse des requêtes émises par des surveillances synthétiques et des tests de disponibilité, 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 surveillances synthétiques, il s'agit du nom de la fonction Cloud, qui est stocké dans le champ resource.labels.service_name.

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

    • Pour vérifier que votre service a reçu des requêtes provenant 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 répertorier toutes les adresses IP, consultez la section Répertorier 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.

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

  1. Pour déterminer quand l'échec a commencé, effectuez l'une des opérations suivantes:

    • Pour les tests de disponibilité, pour déterminer à quel moment l'échec s'est produit, consultez la page Détails de disponibilité:

      1. Dans la console Google Cloud, accédez à la page Tests de disponibilité :

        Accéder aux tests de disponibilité

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

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

        Le graphique Vérifications réussies affiche l'historique des contrôles. Pour déterminer le moment où le test de disponibilité a échoué, vous devrez peut-être modifier la période du graphique. Le sélecteur de période se trouve dans la barre d'outils de la page Détails du temps d'activité.

    • Pour les surveillances synthétiques, pour déterminer à quel moment l'échec s'est produit, consultez la page Détails du temps d'activité:

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

        Accéder à la page Surveillance synthétique

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

      2. Recherchez et sélectionnez la surveillance synthétique.

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

Vous n'êtes pas averti qu'un test de disponibilité a échoué

Vous avez configuré un test de disponibilité et vous consultez la page Détails de disponibilité de ce test. Vous remarquez que le graphique Réussites des vérifications indique qu'au moins un vérificateur a échoué. Cependant, 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 échecs 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 pouvez recevoir en cas 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  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 Surveillance.

  2. Cliquez sur Afficher toutes les règles dans le volet Règles.

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

    Vous pouvez afficher et modifier la règle sur la page Détails des règles.

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

Cette section décrit certaines erreurs que vous pouvez rencontrer lors de l'utilisation de tests de disponibilité publics et fournit des informations pour les résoudre.

Échec de vos tests de disponibilité publics

Vous configurez un test de disponibilité public, mais vous recevez un message d'erreur lorsque vous effectuez l'étape de vérification.

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 section 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 Répertorier les adresses IP des serveurs de tests 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 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 échecs des tests de disponibilité publics, vous pouvez les configurer de sorte qu'ils envoient jusqu'à trois pings ICMP au cours du test. Les pings peuvent vous aider à distinguer les défaillances dues, par exemple, à des problèmes de connectivité réseau et à des délais d'inactivité de votre application. Pour en savoir plus, consultez la section Utiliser des 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 lors de l'utilisation de tests de disponibilité privés 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 que les tests de disponibilité utilisent pour gérer les interactions avec le service de l'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:

Console Google Cloud

Lorsque vous utilisez la console Google Cloud pour créer le test de disponibilité privé, elle exécute les commandes permettant d'attribuer les rôles de l'Annuaire des services au compte de service.

Pour en savoir plus sur l'attribution de rôles à un compte de service, consultez la section Autoriser le compte de service.

API: projet de surveillance

La première fois que vous créez un test de disponibilité privé pour un service d'Annuaire des services et des ressources privées dans un même projet Google Cloud, la requête peut réussir ou échouer. Le résultat varie selon que vous avez ou non désactivé les attributions automatiques de rôles pour les comptes de service dans votre projet:

  • La première création d'un test de disponibilité réussit si votre projet autorise l'attribution automatique de rôles pour les comptes de service. Un compte de service est créé automatiquement et dispose des rôles nécessaires.

  • La création du premier test de disponibilité échoue si votre projet n'autorise pas l'attribution automatique de rôles pour les comptes de service. Un compte de service est créé, mais aucun rôle n'est attribué.

Si la création du test de disponibilité échoue, procédez comme suit:

  1. Autorisez le compte de service.
  2. Attendez quelques minutes que les autorisations se propagent.
  3. Réessayez de créer le test de disponibilité privé.

API: projet surveillé

La première fois que vous créez un test de disponibilité privé qui cible un service de l'Annuaire des services dans un projet surveillé ou des ressources privées dans un autre projet Google Cloud, la requête échoue et entraîne la création d'un compte de service Monitoring.

La manière dont vous autorisez le compte de service dépend du nombre de projets Google Cloud que vous utilisez et de leurs relations. Jusqu'à quatre projets peuvent être impliqués:

  • Projet dans lequel vous avez défini le test de disponibilité privé.
  • Projet surveillé dans lequel vous avez configuré le service de l'Annuaire des services.
  • Projet dans lequel vous avez configuré le réseau VPC.
  • Projet dans lequel les ressources réseau telles que les VM ou les équilibreurs de charge sont configurées. Ce projet ne dispose d'aucun rôle dans l'autorisation du compte de service décrite ici.

Lorsque la création du premier test de disponibilité échoue, procédez comme suit:

  1. Autorisez le compte de service.
  2. Attendez quelques minutes que les autorisations se propagent.
  3. Réessayez de créer le test de disponibilité privé.

Accès refusé

Échec de vos tests de disponibilité avec des résultats VPC_ACCESS_DENIED. Ce résultat signifie qu'un aspect de votre configuration réseau ou de votre autorisation de compte de service n'est pas correct.

Vérifiez l'autorisation de votre compte de service pour l'utilisation d'un projet effectuant une surveillance ou d'un projet surveillé, comme décrit dans la section Échec de la création du test de disponibilité.

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

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

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

Lorsque votre configuration de 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 arrêtée.

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 à un point de terminaison cible pour un test de disponibilité privé, elle inclut les en-têtes et les valeurs suivants:

En-tête Valeur
HTTP_USER_AGENT GoogleStackdriverMonitoring-UptimeChecks(https://cloud.google.com/monitoring)
HTTP_CONNECTION keep-alive
HTTP_HOST Adresse IP du point de terminaison de l'Annuaire des services
HTTP_ACCEPT_ENCODING gzip, deflate et br
CONTENT_LENGTH Calculé à partir des données post-temps d'activité

Si vous tentez de remplacer ces valeurs, voici ce qui peut 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

Aucune donnée ne s'affiche dans le tableau de bord des tests de disponibilité lorsque votre test de disponibilité se trouve dans un projet Google Cloud différent de celui du service de l'Annuaire des services.

Assurez-vous que le projet Google Cloud contenant le test de disponibilité surveille le projet Google Cloud qui contient le service de l'Annuaire des services.

Pour savoir comment répertorier les projets surveillés et ajouter des projets, consultez la section Configurer un champ d'application des métriques pour plusieurs projets.

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

Cette section fournit des informations qui vous aideront à résoudre les problèmes liés à vos surveillances synthétiques.

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

Vous ouvrez le flux de création pour une surveillance synthétique et vous êtes invité à activer au moins une API. Une fois les API activées, un message semblable au suivant s'affiche:

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

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

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

Accéder aux API et services

Après avoir vérifié que l'API est activée, vous pouvez poursuivre le processus de création. La condition se résout automatiquement une fois que l'activation de l'API se propagera dans le backend.

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

Vous configurez votre surveillance synthétique pour collecter des données de trace pour les requêtes HTTP de sortie. Les données de trace n'affichent qu'un seul segment, comme dans la capture d'écran suivante:

Cloud Trace n'affichant qu'une seule trace.

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

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

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

    Accéder à IAM

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

  2. Sélectionnez Inclure les attributions de rôles fournies par Google.

  3. Si le compte de service utilisé par votre surveillance synthétique n'est pas répertorié ou s'il ne dispose pas d'un rôle incluant les autorisations associées au rôle Agent Cloud Trace (roles/cloudtrace.agent), accordez 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 Surveillances synthétiques répertorie une surveillance synthétique avec l'état In progress. L'état In progress signifie que la surveillance synthétique a été créée 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 ne contient pas de trait de soulignement. Si un trait de soulignement est présent, supprimez-le et redéployez la fonction Cloud.

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

    Si le message suivant s'affiche, supprimez la surveillance 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 la surveillance synthétique n'est donc pas en mesure d'exécuter la fonction.

  • Ouvrez la page Cloud Functions de la fonction. Pour ouvrir cette page à partir de la page Informations sur la surveillance synthétique, cliquez sur Code, puis sur le nom de la fonction.

    Si un message semblable au suivant 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 création ou le déploiement de la fonction.

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

État de l'avertissement

La page Surveillances synthétiques répertorie une surveillance synthétique avec l'état Warning. L'état Warning signifie que les résultats de l'exécution ne sont pas cohérents. Cela peut indiquer un problème de conception avec votre test ou indiquer que l'élément testé présente un comportement incohérent.

État "Échec"

La page Surveillances synthétiques répertorie une surveillance synthétique avec l'état Failing. Pour en savoir plus sur le motif de l'échec, consultez l'historique d'exécution le plus récent.

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

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

  • Si l'échec renvoie une heure d'exécution de 0ms, il se peut que la fonction Cloud soit à court de mémoire. Pour résoudre cet échec, modifiez la fonction Cloud, puis augmentez la mémoire à au moins 2 Gio et définissez le champ "CPU" sur 1.

Échec de la suppression pour une surveillance synthétique

Vous utilisez l'API Cloud Monitoring pour supprimer une surveillance 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 de la surveillance synthétique, puis supprimez la surveillance synthétique.

Impossible de modifier la configuration d'un vérificateur de liens non fonctionnels

Vous avez créé un vérificateur de liens non fonctionnels à l'aide de la console Google Cloud et vous souhaitez modifier les éléments HTML testés, ou modifier le délai avant expiration de l'URI, les nouvelles tentatives, l'attente du sélecteur et les options par lien. Toutefois, lorsque vous modifiez l'outil de vérification des liens non fonctionnels, 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 à la page Surveillance synthétique

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

  2. Recherchez la surveillance synthétique que vous souhaitez modifier, cliquez sur Plus d'options, puis sélectionnez Modifier.
  3. Cliquez sur Modifier la fonction.

  4. Modifiez l'objet options dans le fichier index.js, puis cliquez sur Apply function (Appliquer la fonction).

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

  5. Cliquez sur Enregistrer.

Affichage de la console Google Cloud avec un échec d'enregistrement des captures d'écran

Vous avez créé un vérificateur de liens non fonctionnels et l'avez configuré pour enregistrer des captures d'écran. Cependant, 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 ce qui suit:

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

  • Affichez les journaux associés à votre fonction Cloud. Pour en savoir plus, consultez la section Rechercher des journaux.

  • Vérifiez que le compte de service utilisé dans la fonction Cloud 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.