Présentation de la surveillance synthétique

Ce document décrit la compatibilité de Cloud Monitoring avec la surveillance synthétique, qui vous permet de tester la disponibilité, la cohérence et les performances de vos services, applications, pages Web et API. Les moniteurs synthétiques émettent périodiquement des requêtes simulées, puis enregistrent si ces requêtes ont abouti. Ils enregistrent également des données supplémentaires sur la requête, telles que la latence. Vous pouvez être averti lorsqu'un test échoue en créant une règle d'alerte pour surveiller les résultats.

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

  • Les tests de disponibilité permettent à Google Cloud d'interroger régulièrement une application qui répond aux requêtes HTTP, HTTPS ou TCP. Les tests de disponibilité peuvent tester des points de terminaison publics ou privés, et valider les données de réponse.

  • Les synthétiques personnalisés et basés sur Mocha vous permettent de déployer une suite de tests que vous pouvez utiliser pour tester une application qui répond aux requêtes HTTP ou HTTPS. Pour créer ces moniteurs synthétiques, vous commencez par un framework fourni par Cloud Monitoring (personnalisé ou Mocha), puis vous écrivez vos tests. Si vous avez accès à Gemini Code Assist dans ce projet, vous pouvez fournir une invite pour générer votre code de test.

  • Les vérificateurs de liens brisés permettent à Google Cloud de tester régulièrement un URI et un nombre configurable de liens trouvés à cet URI.

Le tableau suivant répertorie les outils que vous pouvez utiliser pour créer des vérifications de disponibilité et des 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 vérifications du temps d'activité :

  • Les tests de disponibilité publics envoient des requêtes depuis plusieurs emplacements dans 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 vérifications de disponibilité proviennent de vérificateurs situés dans plusieurs régions Google Cloud . Lorsque vous créez un test de disponibilité, 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.

  • Validation des 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. À défaut, 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 du 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 le configurer 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 monitors 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 deuxième génération, qui est basée sur Cloud Run. Votre fonction doit être écrite en Node.js et s'appuyer sur le framework Synthetics SDK Open Source. Cloud Monitoring distribue et gère ce framework.

Cloud Monitoring accepte les types de contrôles synthétiques suivants :

Le système d'exécution des requêtes pour les moniteurs synthétiques, 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 et l'échec, telles que 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 la 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 moniteurs synthétiques ou aux tests de disponibilité.

Régionalité des données

N'utilisez pas de surveillance synthétique 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 de la disponibilité. Ce comportement n'est pas configurable.

Tarifs

En général, les métriques système Cloud Monitoring sont gratuites, contrairement à celles provenant de systèmes, d'agents ou d'applications externes. Les métriques facturables sont facturées en fonction du nombre d'octets ou d'échantillons ingérés.

Pour en savoir plus, consultez les sections Cloud Monitoring de 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 tests de disponibilité inclut l'intervalle de temps entre les tests du statut de la ressource spécifiée.
†Pour savoir comment augmenter cette limite, consultez Demander un ajustement de quota.

Étapes suivantes