Diagnostiquer les échecs de test de disponibilité dans Application Insights
Cet article explique comment accéder au rapport de résolution des problèmes d’Application Insights. Ce rapport vous permet de diagnostiquer facilement les problèmes courants qui entraînent l’échec de vos tests de disponibilité.
Note
De nombreux problèmes liés au test web sont causés par des enregistrements DNS obsolètes ou obsolètes. Pour commencer, nous vous recommandons de vider le cache DNS sur votre ordinateur local.
Dans Windows, exécutez la commande ipconfig /flushdns . Pour d’autres systèmes d’exploitation, la commande équivalente est différente.
Afficher le rapport de résolution des problèmes d’Application Insights
Pour afficher le rapport de résolution des problèmes d’Application Insights, procédez comme suit :
Dans la page Disponibilité de votre ressource Application Insights, recherchez le titre Sélectionner un test de disponibilité. Sous ce titre, sélectionnez le nom d’un test de disponibilité individuel ou sélectionnez Global pour afficher les résultats combinés de tous les noms de test.
Effectuez l'une des opérations suivantes :
Dans le volet Résultats de la disponibilité pour le nom de test, recherchez l’en-tête d’extraction , puis sélectionnez le bouton Échec . Ensuite, dans le volet Cliquer sur un exemple de volet de test de disponibilité, sélectionnez une exécution de test (qui représente une région et une heure particulières) pour le nom du test.
Dans le graphique disponibilité , sélectionnez l’affichage Nuage de points , puis sélectionnez l’un des points du graphique de nuages de points.
Dans la page détails de la transaction de bout en bout, sélectionnez un événement, puis sélectionnez n’importe où dans la table Propriétés de disponibilité pour ouvrir la section Résumé du rapport de résolution des problèmes.
Dans la section Résumé du rapport de résolution des problèmes, recherchez le nom d’erreur approprié, puis sélectionnez le lien Accéder à l’étape de cet élément pour afficher les détails du rapport de résolution des problèmes.
Utiliser le rapport de résolution des problèmes pour déterminer les causes possibles d’échec
Le tableau suivant répertorie les étapes, les messages d’erreur et les causes possibles que vous pouvez trouver dans le rapport.
| Étape | Message d’erreur | Cause possible |
|---|---|---|
| Réutilisation de la connexion | Aucun message d’erreur spécifique n’est retourné pour ce problème. | L’étape de test web dépend d’une connexion établie précédemment. Par conséquent, aucune étape DNS, connexion ou SSL n’est requise. |
| Résolution DNS | Impossible de résoudre le nom distant : «< votre URL> » | Le processus de résolution DNS échoue. Cela s’est probablement produit en raison d’enregistrements DNS mal configurés ou d’échecs temporaires du serveur DNS. |
| Établissement de la connexion | Une tentative de connexion a échoué, car la partie connectée n’a pas répondu convenablement après une certaine durée. | Votre serveur ne répond pas à la requête HTTP. Une cause courante est qu’un pare-feu sur votre serveur bloque nos agents de test. Pour tester dans un Réseau virtuel Azure, ajoutez la balise de service de disponibilité à votre environnement. |
| Transport TLS | Le client et le serveur ne peuvent pas communiquer, car ils ne possèdent pas d’algorithme commun. | Seules les versions TLS 1.0, 1.1 et 1.2 sont prises en charge. SSL n’est pas pris en charge. Cette étape ne valide pas les certificats SSL, elle établit uniquement une connexion sécurisée. Cette étape s’affiche uniquement si une erreur se produit. |
| En-tête de réception de réponse | Impossible de lire les données de la connexion de transport. La connexion a été fermée. | Votre serveur valide une erreur de protocole dans l’en-tête de réponse. Par exemple, votre serveur ferme la connexion si la réponse n’est pas entièrement lue. |
| Corps de réception de réponse | Impossible de lire les données de la connexion de transport : la connexion a été fermée. | Votre serveur valide une erreur de protocole dans le corps de la réponse. Par exemple, votre serveur ferme la connexion si la réponse n’est pas entièrement lue ou si la taille de segment est incorrecte dans le corps de la réponse segmentée. |
| Validation de la limite de redirection | Cette page web comporte trop de redirections. Cette boucle se terminera ici car la requête dépassait la limite des redirections automatiques. | Les redirections sont limitées à 10 par test. |
| Validation du code d’état | 200 - OK ne correspond pas à l’état attendu 400 - BadRequest. |
Le code d’état retourné est compté comme un succès. Le code « 200 » indique qu’une page web normale a été retournée. |
| Validation du contenu | Le texte obligatoire «< attendu-response-text> » n’apparaît pas dans la réponse. | La chaîne n’est pas une correspondance exacte sensible à la casse dans la réponse. Par exemple, la chaîne « Welcome ! » doit être une chaîne simple, sans caractères génériques (par exemple, un astérisque). Si le contenu de votre page change, vous devrez peut-être mettre à jour la chaîne. La correspondance de contenu prend en charge uniquement des caractères anglais. La correspondance de contenu échoue également si le corps de la réponse est de plus de 1 000 000 octets de long. Une fois que le client a lu ce nombre d’octets, il arrête de lire le corps de la réponse et supprime la connexion. En raison de ce comportement, le serveur rencontre une |
| Résultats de test manquants dans Portail Azure | Aucun message d’erreur spécifique n’est retourné pour ce problème. Les résultats des tests sont manquants dans la Portail Azure lors de l’affichage des détails de la transaction de bout en bout d’un test de disponibilité. | Les caractères non UTF8 ne sont pas pris en charge pour l’affichage des résultats des tests web. Vérifiez qu’il n’y a pas de caractères non UTF8 dans la réponse du point de terminaison appelé à l’aide du test de disponibilité. |
| URL non prise en charge | Cette URL n’est pas prise en charge | Les tests de disponibilité autorisent uniquement la communication sur les adresses IP et les noms d’hôte disponibles publiquement. Cette erreur peut se produire lorsque vous essayez de communiquer avec une adresse IP interne qui n’est pas routable via l’Internet public. Pour résoudre cette erreur, vérifiez que seules les adresses IP publiques sont définies dans votre test web et que toutes les recherches DNS de votre test web dépendent du retour uniquement des adresses IP routables publiquement valides. |
Note
Si l’étape de réutilisation de la connexion est présente, les étapes suivantes ne sont pas présentes :
- Résolution DNS
- Établissement de la connexion
- Transport TLS
Prochaines étapes
Utilisez TrackAvailability pour envoyer des tests de disponibilité personnalisés.
Découvrez les tests ping d’URL.
Contactez-nous pour obtenir de l’aide
Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.