Présentation de la surveillance synthétique

Ce document décrit la prise en charge de Cloud Monitoring pour 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. La surveillance synthétique envoie périodiquement des requêtes simulées, puis enregistre si ces requêtes ont abouti et des données supplémentaires sur la requête, telles que la latence. Vous pouvez être averti en cas d'échec d'un test en créant une règle d'alerte pour surveiller les résultats du test.

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

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

  • La surveillance synthétique personnalisée et basée sur Mocha vous permet 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 cette surveillance synthétique, 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 rompus vous permettent de tester périodiquement un URI et un nombre configurable de liens trouvés à cet URI. Google Cloud

Le tableau suivant répertorie les outils que vous pouvez utiliser pour créer des tests de disponibilité et une surveillance synthétique :

Google Cloud Console API Cloud Monitoring Terraform Bibliothèques clientes
Tests de disponibilité Y O O Y
Surveillance synthétique Y O Y
Vérificateurs de liens rompus Y O Y

À 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 dans le monde vers des URL ou des Google Cloud ressources publiquement disponibles.
  • 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) L4.

Les requêtes effectuées au nom des tests de disponibilité proviennent de vérificateurs qui résident dans plusieurs Google Cloud régions. 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 par Google 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 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.

  • Collecte et stockage des résultats dans les métriques des tests de disponibilité.

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

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

    Si vous créez votre test de disponibilité à l'aide de la Google Cloud console, 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. Pour en savoir plus, consultez la section Utiliser des pings ICMP.

À propos des vérificateurs de liens rompus et des autres types de surveillance synthétique

La surveillance synthétique vous permet 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 de commerce électronique ou les appels d'API que votre application effectue vers des services tiers.

Lorsque vous créez une surveillance synthétique, vous déployez une fonction Cloud Run de 2e génération 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 accepte les types de surveillance synthétique suivants :

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

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

  • Collecte et stockage des résultats de chaque exécution :

    • Informations sur les réussites et les échecs, 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 votre surveillance synthétique et de vos tests de disponibilité dans la Google Cloud console :

  • Pour la surveillance synthétique, accédez à la page Synthetic monitors (Surveillance synthétique).
  • Pour les tests de disponibilité, accédez à la page Uptime checks (Tests de disponibilité).

Pour être averti en cas d'échec d'une surveillance synthétique ou d'un test de disponibilité, créez une règle d'alerte à l'aide de la Google Cloud console 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 de la surveillance synthétique ou du test de disponibilité associé. Pour en savoir plus, consultez la section Résoudre les problèmes liés à la surveillance synthétique ou aux tests de disponibilité.

Régionalité des données

N'utilisez pas la surveillance synthétique ni les 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 requête de test de disponibilité sont conservées dans un emplacement géographique spécifique.

Pour la surveillance synthétique qui dépend 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 test de disponibilité. Ce comportement n'est pas configurable.

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 de la surveillance synthétique :

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.

Étape suivante