Ce document décrit la compatibilité de Cloud Monitoring avec la surveillance synthétique, qui vous permet de tester la disponibilité, la cohérence 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 si ces demandes ont abouti, et elles enregistrent des données supplémentaires comme la latence. Vous pouvez recevoir une notification lorsqu'un test échoue. Pour ce faire, créez une règle d'alerte afin de surveiller les résultats des tests.
Pour tester vos services et applications, vous pouvez utiliser n'importe quelle 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. Tests de disponibilité peuvent tester les points de terminaison publics ou privés, et valider la réponse données.
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 ces fonctionnalités de surveillance synthétique, vous devez commencer par utiliser un framework 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 URI, puis testez un nombre configurable de liens trouvés à cet URI.
Le tableau suivant répertorie les outils que vous pouvez utiliser pour créer tests de disponibilité et surveillance synthétique:
| console Google Cloud | API Cloud Monitoring | Terraform | Bibliothèques clientes | |
|---|---|---|---|---|
| Tests de disponibilité | O | O | O | O |
| Surveillance synthétique | O | O | O | |
| Vérifications 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 depuis plusieurs zones géographiques dans le monde entier vers des URL ou des ressources Google Cloud accessibles au public.
- Les tests de disponibilité privés envoient des requêtes à des adresses IP internes. des adresses IP 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 pour le compte des tests de disponibilité proviennent de vérificateurs qui résident dans plusieurs régions Google Cloud. Lorsque vous créez un dans le 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 de la configuration des tests de disponibilité sont satisfaites. Dans le cas contraire, la requête échoue. Les requêtes des vérificateurs individuels sont sans état : c'est-à-dire chaque requête est une action indépendante.
Collecter et stocker les résultats pour les métriques de tests de disponibilité
Pour en savoir plus sur ces métriques, consultez les entrées
uptime_checkdans le 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 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 lorsque le ping est défaillant. Pour en savoir plus, consultez Utilisez des pings ICMP.
À propos des vérificateurs de liens non fonctionnels et des autres outils de surveillance synthétique
Les surveillances synthétiques vous permettent de définir ce que vous êtes 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 de l'application à des services tiers.
Lorsque vous créez une surveillance synthétique, vous déployez Fonction Cloud de 2e génération basé sur Cloud Run. Votre fonction doit être écrite en Node.js et s'appuyer sur le code Open Source Framework du SDK Synthetics : Cloud Monitoring distribue et gère ce framework.
Cloud Monitoring est compatible avec les types de surveillance synthétique suivants:
La surveillance synthétique personnalisée ou basée sur Mocha vous permet de déployer un fonction Cloud entièrement configurable.
Les vérificateurs de liens non fonctionnels vous permettent de spécifier des options, comme 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 la surveillance synthétique, 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:
- Les informations sur la réussite et l'échec, telles que le message d'erreur, le type d'erreur et une ligne de code.
- Durée d'exécution
- Journaux
- Métriques
Pour savoir comment afficher les résultats de l'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 la surveillance synthétique et des tests de disponibilité dans la console Google Cloud:
- Pour la surveillance synthétique, accédez à la page Surveillance synthétique.
- Pour les tests de disponibilité, accédez à la page Tests de disponibilité.
Pour recevoir une notification en cas d'échec de la surveillance synthétique ou d'un test de disponibilité, créez une règle d'alerte à l'aide de la la console Google Cloud ou 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 variables incluent l'ID de la surveillance synthétique ou du test de disponibilité associés. Pour plus d'informations, consultez 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 data-residency ou niveau d'impact 4 (IL4) exigences.
Cloud Monitoring ne garantit pas que les données contenues dans la requête est conservé dans un emplacement géographique spécifique.
Pour la surveillance synthétique qui dépend 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 depuis n'importe quelle région compatible par les serveurs de tests de disponibilité. Ce comportement n'est pas configurable.
Tarifs
En général, les métriques système de Cloud Monitoring sont gratuites, et les métriques des systèmes, agents ou applications externes. Les métriques facturables sont facturés en fonction du nombre d'octets ou 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 à l'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† |
†Pour savoir comment augmenter cette limite, consultez Gérez votre quota à l'aide de la console Google Cloud.
Étape suivante
Pour en savoir plus sur les tests de disponibilité, consultez les documents suivants:
Pour en savoir plus sur la surveillance synthétique, consultez les documents suivants: