Présentation de la surveillance synthétique

Ce document décrit l'assistance fournie par Cloud Monitoring pour les moniteurs synthétiques, qui vous permettent de tester la disponibilité, la cohérence et les performances de vos services, applications, pages Web et API. Les moniteurs synthétiques envoient 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 périodiquement une application qui répond aux requêtes HTTP, HTTPS ou TCP. Les vérifications de disponibilité peuvent tester des points de terminaison publics ou privés, et elles peuvent valider les données de réponse.

  • Les moniteurs 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 outils de vérification des liens brisés permettent à Google Cloud de tester périodiquement 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 moniteurs synthétiques:

Console Google 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 de l'état de fonctionnement:

  • Les tests de disponibilité publics envoient des requêtes depuis plusieurs emplacements dans le monde entier vers des URL ou des ressources Google Cloud publiquement disponibles.
  • Les vérifications de disponibilité privées envoient des requêtes aux adresses IP internes des ressources Google Cloud. Les vérifications de disponibilité privées peuvent envoyer des requêtes via un réseau privé à des ressources telles qu'une machine virtuelle (VM) ou un équilibreur de charge interne (ILB) de niveau L4.

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 pour les vérificateurs.

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

  • Exécution des outils de vérification configurés.

  • Validation des résultats.

    La requête émise par un vérificateur aboutit si la ressource répond et que toutes les exigences de la configuration du test de disponibilité sont remplies. 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.

  • Écriture d'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 lorsque le ping échoue. Pour en savoir plus, consultez la section Utiliser des pings ICMP.

À propos des outils de vérification des liens brisés et d'autres outils de surveillance synthétique

Les moniteurs 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 d'e-commerce ou les appels d'API que votre application effectue vers des services tiers.

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

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

Le système d'exécution des requêtes pour les moniteurs synthétiques, fourni par Google 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 la section Explorer les résultats de la surveillance synthétique.

Surveiller et afficher les résultats

Vous pouvez observer les résultats de vos moniteurs synthétiques et de vos tests de disponibilité 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'une surveillance synthétique ou d'une vérification de l'état de fonctionnement, créez une règle d'alerte à l'aide de la console Google 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 journalisées incluent l'ID du moniteur synthétique ou de la vérification de l'état de fonctionnement associés. Pour en savoir plus, consultez la section 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 vérification de la 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 requête de vérification de l'état de fonctionnement 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 l'état de disponibilité. Ce comportement n'est pas configurable.

Tarifs

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

Pour en savoir plus sur la tarification de Cloud Monitoring, consultez les documents suivants:

Limites

Les limites suivantes s'appliquent à votre utilisation des moniteurs 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 du statut de la ressource spécifiée.
†Pour savoir comment augmenter cette limite, consultez la section Gérer votre quota avec la console Google Cloud.

Étape suivante