Présentation de la surveillance synthétique

Les vérifications de disponibilité et la surveillance synthétique dans Cloud Monitoring vous permettent de tester la disponibilité, la cohérence et les performances de vos services, applications, pages Web et API. Ils envoient régulièrement des requêtes simulées ou exécutent des tests scriptés, et enregistrent le résultat et la latence de chaque exécution. Vous pouvez ensuite créer une règle d'alerte pour être averti en cas d'échec d'un test.

Options de surveillance synthétique

Pour tester vos services et applications, vous pouvez choisir l'une des approches suivantes :

  • Les tests de disponibilité vous permettent d'interroger régulièrement des points de terminaison publics ou privés qui répondent aux requêtes HTTP, HTTPS ou TCP, et de valider les données de réponse.

  • Les tests synthétiques personnalisés et basés sur Mocha vous permettent de déployer une suite de tests pour les applications qui répondent aux requêtes HTTP ou HTTPS. Vous commencez par un framework personnalisé ou Mocha fourni par Cloud Monitoring, puis vous écrivez vos tests ou demandez à Gemini Code Assist de générer le code de test si vous y avez accès dans votre projet.

  • Les vérificateurs de liens brisés vous permettent de tester périodiquement un URI et un nombre configurable de liens trouvés à cet URI.

Le tableau suivant liste les outils que vous pouvez utiliser pour créer des tests de disponibilité et des moniteurs synthétiques :

ConsoleGoogle Cloud API Cloud Monitoring Terraform Bibliothèques clientes
Tests de disponibilité O O O O
Surveillance synthétique O O O
Outils de vérification des liens non fonctionnels O O O

À propos des tests de disponibilité

Il existe deux types de tests de disponibilité :

  • Les tests de disponibilité publics envoient des requêtes depuis plusieurs emplacements à travers le monde vers des URL ou des ressources publiquement disponibles Google Cloud .
  • Les tests de disponibilité privés envoient des requêtes aux adresses IP internes des ressources Google Cloud . Les tests de disponibilité privés peuvent envoyer des requêtes sur un réseau privé à des ressources telles qu'une machine virtuelle (VM) ou un équilibreur de charge interne (ILB) de couche 4.

Les requêtes effectuées au nom des tests de disponibilité proviennent de vérificateurs situés dans plusieurs régions Google Cloud . Lorsque vous créez une vérification du temps d'activité, vous spécifiez les régions des vérificateurs.

Le système d'exécution des requêtes pour les tests de disponibilité, fourni parGoogle Cloud, gère les éléments suivants :

  • Exécution des vérificateurs configurés.

  • Validez les résultats.

    La requête émise par un vérificateur aboutit si la ressource répond et si toutes les exigences de la configuration du test de disponibilité sont respectées. Sinon, la requête échoue. Les requêtes des vérificateurs individuels sont sans état, c'est-à-dire que chaque requête est une action indépendante.

  • Collecter et stocker les résultats dans les métriques de test de disponibilité.

    Pour en savoir plus sur ces métriques, consultez les entrées uptime_check dans le tableau des métriques monitoring.

  • Écrire des entrées de journal en cas d'échec.

    Si vous créez votre test de disponibilité à l'aide de la console Google Cloud , vous pouvez configurer le test de disponibilité pour qu'il écrive également une entrée de journal en cas d'échec. Si vous avez configuré un test de disponibilité public pour envoyer des pings ICMP, les résultats de ces pings sont écrits dans les journaux Cloud Logging en cas d'échec du ping. Pour en savoir plus, consultez Utiliser les pings ICMP.

À propos des vérificateurs de liens brisés et des autres moniteurs synthétiques

Les vérifications synthétiques vous permettent de définir ce que vous allez tester et une séquence de tests. Par exemple, vous pouvez tester la page de connexion de votre application, le processus de paiement de votre boutique en ligne ou les appels d'API que votre application effectue vers des services tiers.

Lorsque vous créez un monitor synthétique, vous déployez une fonction Cloud Run de 2e génération, qui est basée sur Cloud Run. Votre fonction doit être écrite en Node.js et s'appuyer sur le framework SDK Synthetics Open Source. Cloud Monitoring distribue et gère ce framework.

Cloud Monitoring est compatible avec les types de contrôles synthétiques suivants :

Le système d'exécution des requêtes pour la surveillance synthétique, fourni parGoogle Cloud, gère les éléments suivants :

  • Exécution périodique de votre fonction Cloud Run.

  • Collecter et stocker les résultats de chaque exécution :

    • Informations sur la réussite ou l'échec, comme le message d'erreur, le type d'erreur et la ligne de code
    • Durée d'exécution
    • Journaux
    • Métriques

    Pour savoir comment afficher les résultats d'exécution, consultez Explorer les résultats de la surveillance synthétique.

Surveiller et afficher les résultats

Vous pouvez observer les résultats de vos tests de disponibilité et de votre surveillance synthétique dans la console Google Cloud  :

  • Pour les moniteurs synthétiques, accédez à la page Moniteurs synthétiques.
  • Pour les tests de disponibilité, accédez à la page Tests de disponibilité.

Pour être averti en cas d'échec d'un test de disponibilité ou d'un monitor synthétique, créez une règle d'alerte à l'aide de la consoleGoogle Cloud ou de Google Cloud CLI.

Résoudre les échecs

Pour vous aider à résoudre les problèmes, les en-têtes de requête et les données enregistrées incluent l'ID du test de disponibilité ou du monitor synthétique associé. Pour en savoir plus, consultez Résoudre les problèmes liés aux tests synthétiques ou aux tests de disponibilité.

Régionalité des données

N'utilisez pas de vérifications synthétiques ni de tests de disponibilité lorsque vous avez configuré Assured Workloads, car vous avez des exigences de résidence des données ou de niveau d'impact 4 (IL4).

Cloud Monitoring ne garantit pas que les données de la demande de vérification du temps d'activité sont conservées dans un emplacement géographique spécifique.

Pour les moniteurs synthétiques qui dépendent d'une fonction Cloud Run, vous pouvez spécifier la région dans laquelle votre fonction Cloud Run est déployée. Toutefois, votre fonction peut être appelée depuis n'importe quelle région compatible avec les serveurs de vérification du temps d'activité. Ce comportement n'est pas configurable.

Périmètres VPC Service Controls

Lorsqu'un projet Google Cloud se trouve dans un périmètre VPC Service Controls activé, le comportement suivant s'applique :

  • Tests de disponibilité privés : vous pouvez créer, modifier, afficher et supprimer des tests de disponibilité privés.

  • Tests de disponibilité et surveillance synthétique publics : vous ne pouvez pas créer ni modifier de tests de disponibilité ou de surveillance synthétique publics. Toutefois, les vérifications ou les moniteurs synthétiques qui existaient avant l'ajout du projet Google Cloud au périmètre continuent de fonctionner. Vous pouvez toujours les afficher et les supprimer.

Tarifs

Pour en savoir plus sur les tarifs de Cloud Monitoring, consultez la page Tarifs de Google Cloud Observability.

Limites

Les limites suivantes s'appliquent à votre utilisation des vérifications synthétiques :

Catégorie Valeur
Tests de disponibilité par champ d'application des métriques * 100
Nombre maximal de pings ICMP par test de disponibilité public 3
Surveillance synthétique par champ d'application des métriques 100†
*Cette limite s'applique au nombre de configurations de tests de disponibilité. Chaque configuration de test de disponibilité inclut l'intervalle de temps entre les tests de l'état de la ressource spécifiée.
†Pour savoir comment augmenter cette limite, consultez Demander un ajustement de quota.

Étapes suivantes