Problème
Votre ping synthétique ou votre simple moniteur a signalé l'une de ces erreurs. Pour les erreurs du monitoring scriptées, voir les erreurs non liées au ping.
Solutions
Voici quelques-uns des messages d'erreur du monitoring non scriptés les plus courants.
Problème
Votre ping a expiré après 65 secondes, la limite de durée de vérification non configurable.
Solution
La limite de temps de 65 secondes n'est pas configurable. Les pings dépassant 65 secondes peuvent être le résultat d'une latence du serveur cible. Recherchez les problèmes potentiels le long du chemin réseau entre nos serveurs et les vôtres, car cela peut indiquer un problème rencontré par un véritable utilisateur de votre application.
Cause
Le moniteur Ping exécutera d’abord une requête HEAD . Si cette requête échoue pour une raison quelconque ou atteint le délai d'expiration de connexion HTTP de 30 secondes pour le moniteur de ping, une requête GET ultérieure est exécutée. Cette erreur se produit lorsque les requêtes HEAD et GET dépassent 30 secondes, généralement en raison de la latence du serveur.
Problème
requests HTTP lors de la vérification ont dépassé la limite de délai d'expiration de connexion TCP non configurable de 30 secondes.
Solution
La limite de temps de 30 secondes n'est pas configurable. Recherchez les problèmes potentiels le long du chemin réseau entre nos serveurs et les vôtres, car cela peut indiquer un problème rencontré par un véritable utilisateur de votre application.
Cause
Cet échec indique un problème lors de l'accès à votre site à partir de l'emplacement où le contrôle du Synthétique a été effectué.
Problème
Le serveur cible a refusé la connexion du client HTTP du moniteur de ping Synthétique.
Solution
Ajoutez nos adresses IP monitoring Synthétique à votre liste de domaines autorisés, pour vous assurer que le trafic de notre moniteur Synthétique peut atteindre le serveur cible.
Cause
Le serveur cible bloque probablement ou limite le trafic de Synthétique.
Problème
Le moniteur Synthétique a rencontré un code d'état d'échec, généralement un code de réponse qui n'est pas dans la plage 2XX/3XX.
Solution
Vérifiez le logging côté serveur pour déterminer pourquoi le code de réponse a été envoyé. Pour vous aider à identifier le trafic de Synthétique sur votre serveur, tout le trafic monitoring Synthétique inclut un en-tête de requête HTTPX-Abuse-Info et nous fournissons une liste d'adresses IP d'origine pour tout le trafic monitoring Synthétique.
Cause
La cause dépend du code de réponse envoyé.
Problème
Votre moniteur renvoie une SSLVerificationError.
Solution
Allez dans one.newrelic.com > Synthetic monitoring > (sélectionnez un moniteur) > General > Advanced options, puis désactivez le Verify SSL check.
Cause
Les échecs SSLVerificationError sont le résultat de l’échec de l’option Verify SSL check sur l’hôte cible.
SSL verification failed during execution for domain <TARGET_URL> les échecs indiquent que l'URL fournie n'est pas HTTPS ou ne redirige pas vers un point de terminaison HTTPS.
SSLVerificationError: (<ERROR CODE>) <ERROR> les erreurs sont récupérées directement à partir de la commande openssl et indiquent souvent un problème de configuration SSL légitime sur le site cible.
Problème
La valeur de chaîne incluse dans le champ facultatif Response Validation du moniteur Synthétique n'a pas été trouvée dans la réponse du serveur cible.
Solution
Pour résoudre le problème :
Vérifiez la chronologie des résultats ayant échoué pour vous assurer que le point de terminaison où le texte de validation de la réponse est attendu est le dernier point de terminaison demandé.
Tentez une requête curl sur le point de terminaison cible pour voir si le corps de réponse attendu est renvoyé.
Assurez-vous que votre point de terminaison ne dispose pas de politiques qui renverront un contenu différent en fonction du contenu de l'en-tête ou de l'activité de la demande. Si tel est le cas, utilisez un navigateur scripté pour usurper une chaîne d’en-tête spécifique.
Si vous utilisez un navigateur simple pour monitorer une page dont le contenu est chargé via JavaScript après le déclenchement de l'événement de chargement de la page, envisagez plutôt d'utiliser un moniteur de navigateur scripté. Vous pouvez programmer des navigateurs scriptés pour attendre que des éléments spécifiques apparaissent sur une page avant d'interagir avec eux.
Cause
La cause dépend du type de moniteur :
Moniteur de ping : la valeur de la chaîne doit être présente dans les 1 Mo (10^6 octets) du premier corps de la réponse.
Navigateurs simples : la chaîne doit être visible sur la page lorsque l'événement de chargement de la page est déclenché.
Problème
Le client du moniteur a pu établir une connexion HTTP avec le site cible, mais a ensuite dépassé le délai de lecture de 30 secondes en attendant une réponse.
Solution
Pour résoudre le problème :
Enquêtez sur les performances du serveur cible pendant la période où le problème a été observé.
Recherchez les problèmes potentiels le long du chemin réseau entre nos serveurs et les vôtres, car cela peut indiquer un problème rencontré par un véritable utilisateur de votre application.
Cause
Cela indique un problème avec le serveur cible répondant au client HTTP du moniteur Synthétique, ou une latence réseau entre votre serveur et le nôtre.
Problème
Le client HTTP du moniteur Synthétique a pu établir une connexion avec le serveur cible. Le serveur cible a ensuite fermé la connexion sans réponse.
Solution
Ajoutez nos adresses IP monitoring Synthétique à votre liste de domaines autorisés, pour vous assurer que le trafic de notre moniteur Synthétique peut atteindre le serveur cible.
Cause
L'infrastructure Edge implémente parfois des mesures telles que celle-ci pour un point de terminaison d'application afin de gérer le trafic qui enfreint les politiques de comportement telles que la limitation de débit.
Problème
Le client monitoring Synthétique a pu résoudre l'adresse IP de l'hôte cible, mais il n'a pas pu trouver de route vers l'hôte cible pour établir une connexion.
Solution
Si la panne se produit sur un emplacement de monitoring Synthétique public, assurez-vous que les enregistrements DNS de cet hôte se résolvent en une adresse IP accessible.
Si la panne se produit sur un site privé de Synthétique monitoring, assurez-vous que la configuration réseau du minion privé est correctement configurée et que la cible nom d'hôte est résoluble et accessible via l'interface virtuelle de ligne de commande minion privé.
Cause
Cela se produit lorsque le nom d'hôte cible se résout en une adresse IP non routable selon la RFC 1918.
Problème
Le client du moniteur Synthétique a été redirigé (observant des codes de réponse 301 ou 302) 20 fois lors de l'exécution d'une requête vers le point de terminaison cible.
Solution
Assurez-vous que le point de terminaison cible redirige requests des clients moins de 20 fois. Si cela se produit uniquement dans New Relic, recréez le problème en dehors de New Relic pour résoudre la cause première. Utilisez un client similaire pour effectuer requests sur le point de terminaison cible :
Ping monitorer : client HTTP similaire à curl.
Navigateur simple et moniteur de navigateur scripté : Chrome 60 instance dans une VM Ubuntu 14.04.5.
Moniteur d'API scripté : utilisez le client HTTP de requête pour Node.js
Cause
Cela se produit lorsque le point de terminaison du moniteur sert effectivement une boucle de redirection au moniteur Synthétique : la réponse initiale redirige vers une autre URL qui redirige vers une autre URL, etc.
Problème
Le nom d'hôte cible n'a pas pu être résolu par le client HTTP du moniteur Synthétique.
Solution
Private synthetic monitoring's locations: Vérifiez que la configuration réseau du minion est correcte. Si le nom d'hôte cible est interne, assurez-vous que le minion utilise le service DNS interne de votre réseau capable de résoudre l'hôte. Le minion privé conteneurisé (CPM) et le conteneur runner qu'il génère sur l'hôte (pour exécuter des vérifications non ping) doivent hériter de configuration DNS de l'hôte /etc/resolv.conf.
Docker: Les arguments réseau tels que –dns ou -network utilisés dans la commande d'exécution Docker sur le minion privé conteneurisé (CPM) ne seront utilisés que par le conteneur subordonné mais pas par le conteneur runner. Si le DNS pointe vers l'interface de bouclage telle que 127.0.0.1, définissez une configuration DNS au niveau du daemon Docker ou utilisez un outil comme dnsmasq pour vous assurer que le runner transmettra requests DNS sur l'interface du pont Docker .
Public synthetic monitoring locations: Assurez-vous que l'enregistrement DNS du site cible peut être recherché par des services DNS publics tels que le DNS public de Google et le DNS fourni par Amazon.
Cause
Nos emplacements monitoring Synthétique publics utilisent le DNS public de Google et le DNS fourni par Amazon. Si la résolution DNS de l'hôte cible échoue sur nos emplacements monitoring Synthétique publics, il s'agit probablement d'un problème auquel d'autres utilisateurs sont confrontés.
Si vous constatez des échecs de monitoring liés à la résolution DNS sur un site monitoring privé Synthétique, cela est souvent dû au fait que le minion privé de cet emplacement a une configuration réseau non valide.
Problème
Le domaine cible est bloqué par monitoring Synthétique.
Solution
Pour débloquer le domaine, vous devez utiliser un moniteur de navigateur scripté et effectuer manuellement des appels dans votre script.
Cause
monitoring synthétique exclut spécifiquement les scripts pour les services d'analyse populaires tels que Google Analytics. Cela garantit que vos outils d'analyse continuent de recevoir des données précises, même avec des milliers de moniteurs vérifiant votre site Web chaque mois.