Problème
Le moniteur Synthétique Simple, Scripted ou Scripted API (non-ping) de New Relic a signalé une erreur, mais l'application semble s'être chargée correctement. Pour les erreurs de ping et de moniteur simples, voir les erreurs de moniteur non scriptées.
Solutions
Vous trouverez ci-dessous quelques-uns des messages d'erreur de moniteur non ping les plus courants.
Erreurs de navigateur simples ou scriptées
Problème
Le script Synthétique tente de .click() un élément (Élément A) au point (X,Y), mais un autre élément (Élément B) masque l'élément cible.
Solution
Définissez un temps d’attente personnalisé, laissant le temps nécessaire pour qu’une condition spécifique soit remplie. Dans ce cas, jusqu'à ce que l'animation de chargement ne soit plus visible :
.then(function () { return $browser.wait( $driver.until.elementIsNotVisible($browser.findElement($driver.By.id("LOADING"))), 10000 );});Vous pouvez également définir un délai de veille personnalisé à l'aide de $browser.sleep(sleeptime_ms), bloquant ainsi l'exécution du script pendant une durée spécifiée. Comme il s'agit d'un temps d'attente fixe, qui ne tient pas compte de l'augmentation de la latence du réseau ou de la dégradation des performances du site, nous vous recommandons d'utiliser plutôt la fonction .wait() .
Conseil
Cela ne corrigera pas les problèmes .click() causés par les en-têtes ou pieds de page collants. Dans ces cas, vous devrez peut-être faire défiler manuellement pour afficher la cible.
Cause
Cela se produit si l'élément cible, au moment de la fonction .click() , est masqué par :
- Une superposition de chargement, une fenêtre modale ou une fenêtre contextuelle
- Une animation qui révèle l'élément cible
- Un en-tête ou un pied de page collant
Problème
L'élément cible n'est pas visible par le sélénium Webdriver.
Solution
Vérifiez que l'élément cible n'a pas les propriétés CSS de display: none ou visibility: hidden appliquées.
Cause
Tout élément ayant une propriété CSS de display: none ou visibility: hidden ne sera pas trouvé par le Webdriver sélénium, car le script ne recherchera que les éléments réellement visibles par un utilisateur.
Problème
Le Webdriver sélénium n'a pas pu trouver cet élément dans le DOM visible.
Solution
Pour résoudre ce problème :
Confirmez que le localisateur d’élément utilisé pour l’élément cible est précis. Évitez d'utiliser
By.XPathdans la mesure du possible, car il est étroitement lié à la structure DOM de la page et peut facilement devenir obsolète lorsque des mises à jour sont effectuées sur la page.Si l'élément est dans un iframe, utilisez
$browser.switchTo().frame(<index or element reference>.Conseil
Consultez la documentation de sélénium pour plus d'informations sur les fonctions
switchTo()etTargetLocator().Cause
Les raisons courantes de cette erreur incluent :
L'élément cible ne peut pas être localisé par des fonctions telles que :
$browser.findElement(locator: $driver.Locator)ou$browser.waitForAndFindElement(locator: $driver.Locator [, timeout: number]
Cela peut être dû à un problème de timing. Par exemple, le Webdriver tente de localiser l'élément avant que la page ne soit chargée.
L'élément se trouve dans un iframe, qui est un contexte de document distinct.
Problème
L'exécution du moniteur scripté a atteint le seuil de délai d'expiration non configurable de 180 secondes et l'exécution a été interrompue.
Solution
S’il s’agit d’une erreur fréquente, envisagez de diviser les tâches scriptées en un moniteur scripté distinct.
S'il semble qu'une tâche spécifique entraîne une attente inacceptable du travail, envisagez de modifier la méthode par laquelle vous accomplissez cette tâche. Par exemple, changer $browser.findElement(locator: $driver.Locator) en $browser.waitForAndFindElement(locator: $driver.Locator [, timeout: number) attribuerait à la tâche son propre délai d'expiration configurable.
Si vous avez plusieurs étapes où la fonction $browser.waitForAndFindElement(locator, timeout) est appelée, assurez-vous que la somme des délais d'attente fournis pour ces étapes ne dépasse pas 180 secondes. Si vous trouvez difficile d'accomplir cela, c'est un signe que le moniteur doit probablement être divisé en un script de moniteur distinct.
Cause
Tous les moniteurs scriptés Synthétique ont un délai d'expiration global maximal non configurable de 180 s pour l'exécution d'un script.
Si un script n'est pas terminé après 180 secondes, le travail est terminé. Si cela se produit systématiquement, cela peut être le signe d'un script qui prend trop de temps à se terminer ou que le travail attend une période prolongée lors de la tentative d'exécution d'une tâche scriptée.
Problème
Le test API ou le moniteur de navigateur scripté semble être en cours d'exécution mais renvoie cette erreur.
Solution
Assurez-vous que $http.get() ou $browser.get() sont appelés correctement et génèrent du trafic.
Pour le moniteur d'API scripté, si vous utilisez une option de demande pour lancer un agent HTTP non instrumenté en arrière-plan, spécifiez l'un de nos agents HTTP instrumentés à l'aide de l'une des options de demande d'agent ci-dessous :
$globalAgents.http$globalAgents.httpsExemple:
var options = {uri: "https://www.newrelic.com",agent: $globalAgents.https,agentOptions: {rejectUnauthorized: false,},strictSSL: false,};function callback(err, res, body) {//...}$http.get(options, callback);Cause
Cela se produit dans les exécutions du moniteur scripté lorsque le client HTTP ($http dans le moniteur d'API scripté) ou le navigateur Chrome ($browser dans le moniteur de navigateur scripté) n'est pas utilisé pour générer du trafic HTTP.
Dans certains cas, certaines options de requête dans API Monitorer peuvent forcer un nouvel agent HTTP, qui n'est pas instrumenté par Synthétique monitoring, à être utilisé pour collecter le trafic HTTP.
Problème
L'objet $network utilisé pour définir les proxys du moniteur n'est pas disponible pour l'exécution de ce moniteur.
Solution
Si votre moniteur a été créé avant la sortie du runtime 0.4.0, créez un nouveau moniteur pour profiter du dernier runtime. La version d'exécution actuelle de votre moniteur est affichée en haut des paramètres du moniteur.
Pour plus d'informations, consultez Environnements d'exécution de la version du moniteur scripté.
Cause
Cette erreur se produit lorsque vous tentez d'utiliser $network sur un moniteur avec un runtime égal ou inférieur à 0.2.2. Le trafic proxy du moniteur a été introduit dans la version d'exécution du moniteur 0.4.0, provoquant l'évaluation de cette méthode comme non définie lors des exécutions de monitoring précédentes.
Problème
Cette erreur indique que le travail a atteint le seuil d’expiration du conteneur Docker et que le script a été arrêté.
Solution
S’il s’agit d’une erreur fréquente, envisagez de diviser les tâches scriptées en un moniteur scripté distinct.
S'il semble qu'une tâche spécifique entraîne une attente inacceptable du travail, envisagez de modifier la méthode par laquelle vous accomplissez cette tâche. Par exemple, si vous remplacez $browser.findElement(locator: $driver.Locator) par $browser.waitForAndFindElement(locator: $driver.Locator [, timeout: number) la tâche se verra attribuer son propre délai d'expiration configurable.
Si vous avez plusieurs étapes où la fonction $browser.waitForAndFindElement(locator, timeout) est appelée, assurez-vous que la somme des délais d'attente fournis pour ces étapes ne dépasse pas 180 secondes. Si vous trouvez difficile d'accomplir cela, c'est un signe que le moniteur doit probablement être divisé en un script de moniteur distinct.
Cause
Tous les moniteurs scriptés Synthétique ont un délai d'expiration global maximal non configurable de 180 s pour l'exécution d'un script.
Si un script n'est pas terminé après 180 secondes, le travail est terminé. Si cela se produit systématiquement, cela peut être le signe d'un script qui prend trop de temps à se terminer ou que le travail attend une période prolongée lors de la tentative d'exécution d'une tâche scriptée.
Problème
La page cible a été chargée, mais une modification a été apportée à un élément entre l'exécution d'un localisateur d'élément et une action en cours d'exécution sur l'élément.
Solution
Configurez votre navigateur scripté pour attendre que la page soit configurée avant d'effectuer une action findElement() . Cela peut être accompli en définissant un temps d'attente personnalisé, en utilisant la fonction $browser.wait(fn, timeout) avant l'appel findElement, pour attendre une condition indiquant un état de page défini. Cela réduira le risque que la manipulation du DOM entraîne l'obsolescence d'une référence.
Vous pouvez également définir un délai de veille personnalisé à l'aide de $browser.sleep(sleeptime_ms), bloquant ainsi l'exécution du script pendant une durée spécifiée. Comme il s'agit d'un temps d'attente fixe, qui ne tient pas compte de l'augmentation de la latence du réseau ou de la dégradation des performances du site, nous vous recommandons d'utiliser plutôt la fonction .wait() .
Cause
Cette erreur se produit généralement lorsque le script tente de .click() un élément après avoir utilisé la fonction findElement() ou waitForAndFindElement() .
Si le DOM a changé entre le moment où le localisateur d'élément a été généré et le moment où l'action a été exécutée sur l'élément, cette erreur se produira car l'élément réel a changé.
Par exemple : la fonction findElement() est utilisée pour générer une référence d'élément pendant que le script de la page manipule activement le DOM. Le DOM est ensuite modifié, ce qui rend obsolète la référence précédemment générée. La référence désormais obsolète est utilisée pour tenter d'effectuer une action .click() , ce qui entraîne l'échec de ce moniteur.
Conseil
Pour plus d'informations, consultez la documentation Sélénium sur les exceptions de référence d'éléments obsolètes.
Problème
La fonction waitForAndFindElement(<locator>, <timeout>) n'a pas réussi à localiser un élément dans le délai imparti.
Solution
Confirmez que le localisateur d’élément utilisé pour l’élément cible est précis. Évitez d'utiliser By.XPath() dans la mesure du possible, car il est étroitement lié à la structure DOM de la page et peut facilement devenir obsolète lorsque des mises à jour sont effectuées sur la page.
Cause
L'élément cible n'existait pas sur la page lorsque la fonction waitForAndFindElement(<locator>, <timeout>) a été appelée. Cela peut être dû au fait que la page cible n’est pas dans l’état attendu.
Les raisons courantes de cette erreur incluent :
- Il y a un problème légitime avec le site cible.
- Le localisateur d'élément utilisé est incorrect.
- Le site cible a changé, nécessitant la révision du script Synthetics.
- L'action précédente dans le script n'a pas été exécutée avec succès, ce qui a entraîné un état inattendu de la page lorsque l'appel waitForAndFindElement() suivant a été lancé.
Problème
La page cible a été chargée avec succès, mais a renvoyé l'erreur :
TimeoutError : le chargement de la page a expiré (impossible de terminer toutes requests réseau à temps)
Solution
Si les échecs ont commencé soudainement, examinez toutes les requests qui pourraient bloquer ou retarder l'événement de chargement de la page. Si vous n'êtes pas sûr de la requête à l'origine de l'erreur, utilisez la vue chronologique pour identifier requests HTTP de longue durée.
Si la page ne parvient souvent pas à se charger complètement dans le délai d'expiration actuel, définissez un délai d'expiration de chargement de page personnalisé à l'aide de la fonction $browser.manage().timeouts().pageLoadTimeout(ms: number) .
Cause
La page cible a été chargée avec succès, mais l'événement de chargement de la page n'a pas été déclenché dans le délai de chargement de la page défini dans la fonction .pageLoadTimeout() .
Il existe un certain nombre de raisons pour lesquelles vous pourriez voir ce message d'erreur, notamment :
- Une demande de ressource bloquée sur la page a retardé le chargement de la page.
- Une demande de ressource a été traitée plus lentement que la normale en raison d'un problème réseau sous-jacent.
- Une ressource dépendante sur la page a bloqué l'événement de chargement de l'iframe.
Problème
La fonction isElementPresent(), utilisée par le monitorer Synthétique avec un runtime >= 0.5.0, est obsolète dans sélénium 3.
Solution
Pour continuer à utiliser cette fonction après l'amortissement, vous devrez créer une version personnalisée de cette fonction, telle que :
return $browser.findElements(ele).then(function (found) { return found.length > 0;});Exemple d'utilisation, qui renverrait vrai :
$browser .get("https://www.newrelic.com") .then(function () { return isElementPresent($driver.By.id("nav_signup")); }) .then(function (found) { return console.log(found); });Cause
Cela peut se produire lorsque vous essayez d'utiliser un script moniteur de navigateur scripté provenant d'un ancien moniteur (runtime <= 0.4.1) avec un moniteur plus récent (>= 0.5.0) Durée d'exécution.
Erreurs du moniteur d'API scriptées
Problème
Le test API ou le moniteur de navigateur scripté semble être en cours d'exécution mais renvoie cette erreur.
Solution
Assurez-vous que $http.get() ou $browser.get() sont appelés correctement et génèrent du trafic.
Pour le moniteur d'API scripté, si vous utilisez une option de demande pour lancer un agent HTTP non instrumenté en arrière-plan, spécifiez l'un de nos agents HTTP instrumentés à l'aide de l'une des options de demande d'agent ci-dessous :
$globalAgents.http$globalAgents.httpsExemple:
var options = {uri: "https://www.newrelic.com",agent: $globalAgents.https,agentOptions: {rejectUnauthorized: false,},strictSSL: false,};function callback(err, res, body) {// ...}$http.get(options, callback);Cause
Cela se produit dans les exécutions du moniteur scripté lorsque le client HTTP ($http dans le moniteur d'API scripté) ou le navigateur Chrome ($browser dans le moniteur de navigateur scripté) n'est pas utilisé pour générer du trafic HTTP.
Dans certains cas, certaines options de requête dans API Monitorer peuvent forcer un nouvel agent HTTP, qui n'est pas instrumenté par Synthétique monitoring, à être utilisé pour collecter le trafic HTTP.
Problème
L'objet $network utilisé pour définir les proxys du moniteur n'est pas disponible pour l'exécution de ce moniteur.
Solution
Si votre moniteur a été créé avant la sortie du runtime 0.4.0, créez un nouveau moniteur pour profiter du dernier runtime. La version d'exécution actuelle de votre moniteur est affichée en haut de la page Paramètres du moniteur.
Pour plus d'informations, consultez Environnements d'exécution de la version du moniteur scripté.
Cause
Cette erreur se produit lorsque vous tentez d'utiliser $network sur un moniteur avec un runtime égal ou inférieur à 0.2.2. Le trafic proxy du moniteur a été introduit dans la version d'exécution du moniteur 0.4.0, provoquant l'évaluation de cette méthode comme non définie lors des exécutions de monitoring précédentes.
Problème
JSON.parse() une chaîne qui commence par le caractère < et qui est probablement du HTML, au lieu de JSON, lui a été transmise.
Solution
Assurez-vous que le point de terminaison cible renvoie le corps de réponse attendu. Vous pouvez le faire en enregistrant le corps de la réponse dans le rappel, avant de tenter l'analyse.
Exemple:
$http.get("http://www.newrelic.com", function (error, response, body) { if (error) { throw new Error(error); }
console.log(body); // Log HTML response body, don't parse as JSON});Selon les points de terminaison cibles de l'API, vous devrez peut-être inclure des en-têtes de requête spécifiques pour garantir que JSON est renvoyé.
Cause
Le script tente d'utiliser JSON.parse() sur un corps de réponse après qu'une demande a été effectuée et s'attend à ce que le point de terminaison renvoie JSON, mais HTML a été renvoyé à la place.
Problème
JSON.parse() un paramètre indéfini a été passé, mais on attendait une chaîne JSON.
Solution
Résolvez la cause de l’erreur de demande. Les détails sur les causes des erreurs de demande peuvent être trouvés dans l'objet d'erreur transmis à la fonction de rappel de demande.
Exemple:
$http.get("http://www.newrelic.com", function (error, response, body) { if (error) { throw new Error(error); }
var bodyJson = JSON.parse(body); console.log(bodyJson); // Log response body});Cause
Cela peut se produire dans le moniteur d'API scripté lors de l'exécution d'une requête API, puis de la tentative d'analyse de la réponse à la requête dans la fonction rappel. Le corps de la réponse est transmis à JSON.parse() sans vérifier au préalable si le corps de la réponse n'est pas défini.
Un corps de réponse indéfini est souvent causé par une erreur de demande. S'il n'existe aucune gestion des erreurs pour empêcher le code d'analyser le corps de la réponse, cette défaillance du moniteur se produira.
Problème
L'objet de réponse (et donc response.statusCode) dans un rappel de demande d'API n'est pas défini.
Solution
Résolvez la cause de l’erreur de demande. Les détails sur les causes des erreurs de demande peuvent être trouvés dans l'objet d'erreur transmis à la fonction de rappel de demande.
Exemple:
$http.get("http://www.newrelic.com", function (error, response, body) { if (error) { throw new Error(error); } console.log(response.statusCode);});Cause
Cette erreur se produit lorsqu'une erreur s'est produite lors de la finalisation de la demande d'API (par exemple, impossible d'atteindre le serveur, impossible de résoudre le DNS). Dans ces cas, la demande n'a pas été complétée, donc l'objet de réponse dans les arguments de la fonction rappel n'est pas défini.
S'il n'existe aucune gestion des erreurs pour empêcher le code de vérifier le code d'état de réponse, cette défaillance du moniteur se produira.