Résoudre les problèmes liés à la surveillance synthétique et aux tests de disponibilité

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

• 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

Remarque :Les en-têtes de requête HTTP(S) incluent un champ intitulé Check-Id, qui stocke l'identifiant de la surveillance synthétique ou du test de disponibilité associé avec la requête.

Rechercher des journaux

Cette section explique comment trouver les journaux de votre compte la surveillance synthétique et les 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.

2. Effectuez l'une des actions suivantes :

   • Pour rechercher tous les journaux associés à vos surveillances synthétiques ou à vos tests de disponibilité, procédez comme suit : par type de ressource. Vous pouvez utiliser le menu Ressource ou saisissez 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 la requête puis cliquez sur Run query (Exécuter la requête) :

     resource.type="uptime_url"
     

     Pour la surveillance synthétique, dans le menu Ressource, sélectionnez Révision dans Cloud Run, ou saisissez la requête suivante dans la requête puis cliquez sur Run query (Exécuter la requête) :

     resource.type="cloud_run_revision"
     

   • Journaux de recherche contenant des informations sur la réponse reçue lors de l'exécution d'une surveillance synthétique ou d'un test de disponibilité, suivantes:

     • Pour effectuer une requête en utilisant 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"
       

     • À interroger les journaux contenant des données de réponse aux requêtes générés par la surveillance synthétique et les tests de disponibilité, saisissez 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 la surveillance synthétique, le nom de votre fonction Cloud stocké dans le champ resource.labels.service_name.

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

   • Pour vérifier que votre service a reçu des requêtes des serveurs Google Cloud, copiez la requête suivante dans le 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 le 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 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 s'est produit, effectuez l'une des opérations suivantes:

   • Pour les tests de disponibilité, pour déterminer quand l'échec s'est produit, Accédez à la page Informations sur le temps d'activité:

     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. Recherchez et sélectionnez le test de disponibilité.

        Le graphique Vérifications réussies affiche l'historique des vérifications. Pour déterminer quand le test de disponibilité a échoué pour la première fois, vous devrez peut-être modifier la période du graphique. Le sélecteur de période est située dans la barre d'outils de la page Uptime details (Détails du test).

   • Pour la surveillance synthétique, vous pouvez déterminer quand l'échec s'est produit Accédez à la page Informations sur le temps d'activité:

     1. Dans la console Google Cloud, accédez à 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. 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 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 cette vérification. Vous remarquez que le graphique Vérifications réussies indique qu'au moins un échec du vérificateur. 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 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 parvient pas à recevoir de réponse. Toutefois, nous vous conseillons d'utiliser la configuration par défaut, ce qui réduit le nombre de notifications que vous pourriez recevoir en raison de défaillances 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 Monitoring.

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

3. Recherchez la stratégie que vous souhaitez afficher ou modifier, puis cliquez sur l'icône nom de la stratégie.

   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 des 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 une erreur lorsque vous effectuer 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 les 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 Répertoriez 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 des serveurs de temps d'activité ; voir Répertoriez 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 échecs des tests de disponibilité publics, vous pouvez configurer vos tests de disponibilité pour envoyer Pings ICMP pendant la vérification. Les pings peuvent vous aider à distinguer des défaillances causées, par exemple, par des problèmes de connectivité réseau et par des délais avant expiration dans votre application. Pour en savoir plus, consultez Utilisez 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 des 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 utilisé par les tests de disponibilité 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 attribués au compte de service requiert:

console Google Cloud

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

Pour savoir comment attribuer des 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 Service de l'Annuaire des services et 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 Vous avez désactivé l'attribution automatique de rôles pour les comptes de service dans votre projet:

• Le premier test de disponibilité est créé avec succès si votre projet le permet l'attribution automatique de rôles pour les comptes de service. Un compte de service créé pour vous et obtient les 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 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 service de l'Annuaire des services dans un projet surveillé des ressources privées dans différents projets Google Cloud, la requête échoue et entraîne la création Compte de service Monitoring.

La méthode d'autorisation du compte de service dépend du nombre Les projets Google Cloud que vous utilisez et leurs relations. Vous pouvez avoir jusqu'à quatre projets impliqués:

• Projet dans lequel vous avez défini le test de disponibilité privé.
• Le projet surveillé dans lequel vous avez configuré 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é. Ce projet ne dispose d'aucun rôle dans l'autorisation du compte de service abordées 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é

Vos tests de disponibilité échouent avec VPC_ACCESS_DENIED résultats. Ce résultat qu'un aspect de votre configuration réseau ou de votre compte de service l'autorisation n'est pas correcte.

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

Pour plus d'informations sur l'accès aux réseaux privés, consultez Configurez le projet réseau.

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

Vous disposez d'un service de l'Annuaire des services plusieurs VM et que 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 la configuration de votre service contient plusieurs points de terminaison, l'un 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 pourrait se produire si vous avez remplacé les valeurs d'en-tête par défaut.

Lorsqu'une requête est envoyée pour un test de disponibilité privé à un point de terminaison cible, la requête inclut les en-têtes et 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, br
CONTENT_LENGTH	Calculé à partir des données sur le temps d'activité après

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 de la table

Aucune donnée visible

Le tableau de bord du test de disponibilité ne contient aucune donnée le test de disponibilité se trouve dans un projet Google Cloud différent de Service de l'Annuaire des services.

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

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

Résoudre les problèmes liés à la surveillance synthétique

Cette section fournit des informations qui vous aideront à résoudre les problèmes. la surveillance synthétique.

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

Vous ouvrez le flux de création pour la surveillance 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, puis de relancer l'action.

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

Accéder aux API et services

Après avoir vérifié que l'API est activée, vous pouvez passer à la créer un flux. La condition est résolue automatiquement une fois que l'API l'activation se propage dans le backend.

Les requêtes HTTP sortantes ne sont pas suivies.

Vous configurez la surveillance synthétique afin de collecter des données de trace pour la sortie. Requêtes HTTP. Vos données de trace n'affichent qu'un seul segment, semblable à celui-ci : capture d'écran:

Pour résoudre ce problème, assurez-vous que votre compte de service a reçu le rôle Agent Cloud Trace (roles/cloudtrace.agent). 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 s'est pas vu attribuer un rôle incluant les autorisations associées au rôle Agent Cloud Trace (roles/cloudtrace.agent), puis attribuez ce rôle à votre de service géré.

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

État "En cours"

La page Surveillance synthétique indique une surveillance synthétique dont l'état est 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é, essayez ce qui suit:

• Assurez-vous que le nom de votre fonction Cloud contiennent un trait de soulignement. Si un trait de soulignement est présent, supprimez-le et redéployer la fonction Cloud.

• Ouvrez la page Détails de la surveillance synthétique correspondant à 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, par conséquent, la surveillance synthétique ne peut pas exécuter la fonction.

• Ouvrez la page Cloud Functions pour la fonction. Ouvrir cette page sur la page Détails de la surveillance synthétique, cliquez sur Code, puis sur cliquez sur le nom de la fonction.

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

  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. empêchant la création ou le déploiement de la fonction.

Lorsque vous créez une surveillance synthétique, la à déployer et à exécuter la fonction.

État de l'avertissement

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

État "Échec"

La page Surveillance synthétique indique une surveillance synthétique dont l'état est Failing Pour en savoir plus sur le motif de l'échec, afficher l'historique des exécutions le plus récent.

• Si le message d'erreur Request failed with status code 429 s'affiche, alors la cible de la requête HTTP a rejeté la commande. Pour résoudre ce problème, 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 la surveillance synthétique.

• Si l'échec renvoie une durée d'exécution de 0ms, alors La fonction Cloud est peut-être à court de mémoire. Pour résoudre ce problème, modifiez votre fonction Cloud et augmentez la quantité de mémoire sur 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'API échoue avec un résultat semblable à celui-ci:

{
  "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 le problème, supprimez les règles d'alerte surveiller les résultats de la surveillance synthétique, puis la supprimer.

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 pour modifier les éléments HTML testés ou si vous souhaitez 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 le vérificateur de liens non fonctionnels, la console Google Cloud n'effectue pas pour afficher les champs de configuration.

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

1. Dans la console Google Cloud, accédez à 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. Recherchez la surveillance synthétique que vous souhaitez modifier, cliquez sur Autres options, puis sélectionnez Modifier.
3. Cliquez sur Modifier la fonction.

4. 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.

5. Cliquez sur Enregistrer.

Écran de la console Google Cloud indiquant l'échec de l'enregistrement des captures d'écran

Remarque :Une surveillance synthétique qui ne peut pas enregistrer de captures d'écran continue de tester les liens contenus dans un URI.

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

• InvalidStorageLocation
• StorageValidationError
• BucketCreationError
• ScreenshotFileUploadError

Pour résoudre ces problèmes, procédez comme suit:

• Si le message InvalidStorageLocation s'affiche, vérifiez l'existence de cette option. du bucket Cloud Storage spécifié dans le champ 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 Cloud Functions dispose d'un rôle Identity and Access Management qui lui permet de créer, y accéder et écrire dans des buckets Cloud Storage.