Ce document décrit la compatibilité de Cloud Monitoring avec 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 surveillances synthétiques envoient régulièrement des requêtes simulées, puis enregistrent si ces requêtes ont abouti. Elles enregistrent également des données supplémentaires les concernant, 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 vos applications, vous pouvez adopter l'une des approches suivantes:
Les tests de disponibilité permettent à Google Cloud d'interroger régulièrement une application qui répond à des 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 surveillances synthétiques personnalisées et basées 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 surveillances synthétiques, vous devez commencer avec un framework fourni par Cloud Monitoring (personnalisé ou Mocha), puis écrire 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 non fonctionnels permettent à Google Cloud de tester régulièrement un URI et de tester un nombre configurable de liens détectés au niveau de cet URI.
Le tableau suivant répertorie les outils que vous pouvez utiliser pour créer des tests de disponibilité et des surveillances 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 | |
| Vérificateurs de 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 provenant de plusieurs emplacements à travers le monde à des URL accessibles au public ou à des ressources 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 via un réseau privé vers des ressources telles qu'une machine virtuelle (VM) ou un équilibreur de charge interne L4 (ILB).
Les requêtes effectuées pour le compte de tests de disponibilité proviennent de vérificateurs résidant 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 de 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.
Collecter et stocker les résultats dans des métriques de tests de disponibilité
Pour en savoir plus sur ces métriques, consultez les entrées
uptime_checkdu tableau des métriquesmonitoring.Écrire des entrées de journal en cas d'échec
Si vous créez un test de disponibilité à l'aide de la console Google Cloud, vous pouvez le configurer de sorte qu'il écrive également une entrée de journal en cas d'échec du test. 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 la section Utiliser des pings ICMP.
À propos des vérificateurs de liens interrompus et des autres surveillances synthétiques
Les surveillances 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 envoie à des services tiers.
Lorsque vous créez une surveillance synthétique, vous déployez une fonction Cloud de 2e génération basée sur Cloud Run. Votre fonction doit être écrite en Node.js et s'appuyer sur le framework de SDK synthétique Open Source. Cloud Monitoring distribue et gère ce framework.
Cloud Monitoring est compatible avec les types de surveillance synthétique suivants:
Les surveillance synthétiques personnalisées ou basées sur Mocha vous permettent de déployer une fonction Cloud à usage unique entièrement configurable.
Les vérificateurs de liens rompus vous permettent de spécifier des options, telles que l'URI d'origine, le nombre de liens testés et le nombre de tentatives, avant de déployer une fonction Cloud préconfigurée.
Le système d'exécution de requêtes pour les surveillances synthétiques, fourni par Google Cloud, gère les éléments suivants:
- Exécution périodique de votre fonction Cloud
Collecter et stocker les résultats de chaque exécution:
- Informations de réussite et d'é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 en savoir plus sur l'affichage des 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 surveillances synthétiques et tests de disponibilité dans la console Google Cloud:
- Pour les surveillances synthétiques, accédez à la page Surveillances 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'un test de disponibilité, créez une règle d'alerte à l'aide de la console Google Cloud ou de Google Cloud CLI.
Régionalité des données
N'utilisez pas de surveillances synthétiques ni de tests de disponibilité lorsque vous avez configuré Assured Workloads, car vous avez des exigences concernant la résidence des données ou le niveau d'impact 4 (IL4).
Cloud Monitoring ne garantit pas que les données de la requête de test de disponibilité seront conservées dans un emplacement géographique spécifique.
Pour les surveillances synthétiques qui dépendent d'une fonction Cloud, vous pouvez spécifier la région dans laquelle votre fonction Cloud est déployée. Cependant, votre fonction peut être appelée à partir de n'importe quelle région compatible avec les serveurs de tests de disponibilité. Ce comportement n'est pas configurable.
Tarification
En général, les métriques système de Cloud Monitoring sont gratuites, contrairement aux métriques 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 les tarifs de Cloud Monitoring, consultez les documents suivants:
Limites
Les limites suivantes s'appliquent à votre utilisation des surveillances 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† |
†Pour savoir comment augmenter cette limite, consultez Gérer votre quota à l'aide de la console Google Cloud.
Étapes suivantes
Pour en savoir plus sur les tests de disponibilité, consultez les documents suivants:
Pour en savoir plus sur les surveillances synthétiques, consultez les documents suivants: