Le monitoring synthétique exécute des vérifications automatisées et planifiées sur vos applications et points de terminaison à partir des emplacements que vous choisissez — des emplacements publics que New Relic exploite dans le monde entier, ou des sites privés au sein de votre propre réseau. Chaque moniteur effectue une requête réelle ou un parcours utilisateur à un intervalle fixe, et signale le résultat, afin que vous puissiez détecter les défaillances, les ralentissements, et les flux interrompus le plus tôt possible.
Parce que ces vérifications s’exécutent en permanence, elles fournissent une disponibilité, une fonctionnalité, et une base de référence de performances pour vos applications (à la fois les points de terminaison d’API et les parcours dans le navigateur). L’APM et le monitoring de navigateurs vous indiquent comment le trafic réel s’est comporté, tandis que les outils pour monitorer en Synthétique vous indiquent si votre fonctionnalité critique fonctionne comme prévu à tout moment, y compris dans les régions avec peu de trafic ou avant qu’une sortie n’atteigne les utilisateurs.
Exemples de cas d’utilisation
Le monitoring synthétique de New Relic couvre un spectre allant des pings légers de temps de disponibilité qui couvrent largement la disponibilité, jusqu’aux parcours d’API et de navigateur entièrement scriptés qui testent vos flux les plus complexes. Sur les monitorers scriptés s’exécutant depuis des sites privés, vous pouvez aller encore plus loin, en étendant l’exécution avec vos propres modules npm pour vérifier presque tout ce qui est accessible depuis votre réseau.
Ping
La vérification la plus économique que vous puissiez exécuter est une requête HTTP planifiée confirmant qu’un point de terminaison est en ligne et suffisamment rapide. Suffisamment économique pour s’exécuter fréquemment sur des centaines de points de terminaison, ce qui en fait votre fondation pour une large disponibilité et des rapports sur le temps de disponibilité. Elle détecte les pannes, et non les fonctionnalités défectueuses ; traitez-la donc comme votre premier signal plutôt que comme la preuve que l’application fonctionne.
Pour commencer, consultez Ajouter et modifier des éléments à monitorer pour en créer un, et Afficher les résultats du ping à monitorer pour lire ce qu’il signale.
API scriptée
Utilise Node.js avec l’API $http pour chaîner les requests, transmettre l’authentification et l’état à travers les étapes, et utiliser un assertion sur le statut, la charge, et le délai d’exécution. Utilisez-le pour encoder une véritable transaction métier au niveau de la couche de service, ou pour surveiller une dépendance tierce sur laquelle vous comptez, mais que vous ne contrôlez pas. Sur des sites privés, utilisez require() pour vos propres modules afin d’atteindre des protocoles non HTTP, ou d’appeler des API de modèle, de stockage vectoriel, et de cloud avec vos SDK existants.
Pour commencer, consultez Écrire des tests d’API Synthétique pour créer votre premier script, et Importer des modules Node.js pour l’étendre avec des bibliothèques.
Navigateur simple
Charge votre page dans une instance Chrome ou Firefox réelle, afin que la vérification exécute votre JavaScript, vos ressources, votre CDN, et votre cache, plutôt que seulement le code d’état. Détecte les erreurs de script bloquant le rendu, les bundles manquants, et les tags tiers échouant silencieusement qu’un ping ne voit jamais. Aucun code n’est requis, c’est donc le moyen le plus rapide d’obtenir une couverture de rendu réel sur de nombreuses pages.
Pour commencer, consultez Ajouter et éditer des monitorers pour en créer un, et Émulation d’appareil pour tester les fenêtres d’affichage sur mobile et tablette.
Navigateur scripté
Pilote un vrai navigateur avec l’API $browser (sélénium Webdriver) à travers des parcours en plusieurs étapes, conditionnels, et authentifiés. Une vérification valide l’ensemble du chemin, du navigateur à la couche de données, comme la connexion, la recherche, le paiement, ou un flux interne critique. C’est le monitoring le plus lent et le plus gourmand en ressources, réservez-le donc pour les parcours qui génèrent des revenus et de la confiance.
Pour commencer, consultez l’ Introduction aux moniteurs de navigateur scriptés pour les bases, et la référence du navigateur scripté pour l’API $browser complète.
Les monitorers d’API scriptés et les moniteurs de navigateur scriptés exécutent votre JavaScript, vous pouvez donc utiliser require() sur vos propres modules npm. Vous alimentez le protocole, le cloud-SDK, et les vérifications de documents ci-dessus de la même manière. Sur les sites privés, ces modules s’installent à partir de votre propre registre et s’exécutent au sein de votre réseau. Stockez toutes les clés ou tous les jetons en tant qu’ identifiants sécurisés.
Code personnalisé et extensibilité
Les scripts pour monitorer de New Relic ne sont pas des vérificateurs à fonction fixe : ce sont des programmes. Si vous pouvez l’exprimer en code, vous pouvez le monitorer. Cela signifie que vous pouvez créer une chaîne de logique personnalisée, exécuter une requête sur vos propres données New Relic, et étendre les éléments à monitorer avec votre propre code et vos propres modules.
Apporter votre propre code
Les monitorer scriptés vous permettent d’utiliser require() sur vos propres modules. Sur les sites privés, vous montez un répertoire contenant une package.json, et le gestionnaire de tâches exécute npm install au démarrage ; ainsi, tout package npm ou bibliothèque interne fait partie de votre monitorer, suffisamment pour parler des protocoles non-HTTP (TCP, WebSocket, MQTT, LDAP, SFTP, SMTP), appeler des SDK de fournisseurs cloud, ou décoder des formats propriétaires. La portée de vos monitorer est l’écosystème entier de packages plus votre propre code, et non une liste de fonctionnalités fixe : un nouveau besoin signifie donc ajouter une dépendance, et non déposer une demande de fonctionnalité.
Exécutez-le en privé, dans votre réseau
Étant donné que les scripts pour monitorer s’exécutent sur le gestionnaire de tâches Synthetics, vous pouvez les exécuter depuis des sites privés au sein de votre propre réseau. Cela signifie tester les systèmes internes avec vos propres modules, installés à partir de votre propre registre, sans rien exposer à l’Internet public.
Soyez alerté sur les anomalies de télémétrie
Un monitorer d’API scripté peut effectuer une requête sur vos propres données New Relic et déclencher une alerte sur le résultat en fonction de la logique que vous définissez dans les scripts personnalisés, offrant une couverture pour les scénarios qui ne correspondent pas aux conditions d’alerte, comme effectuer une requête sur des données sur une période plus longue, ou comparer des résultats avec une période précédente :
- Requête sur vos données : appelez l’API NerdGraph avec
$http, en utilisant une clé API stockée en tant qu’ information d’identification sécurisée, pour exécuter une requête NRQL. - Alerte sur les déviations : utilisez une
assertionou une logique similaire pour faire échouer la vérification lorsque le résultat franchit un seuil ou dévie d’une période précédente.