Superviser la disponibilité avec des tests Ping d’URL

Le nom test ping d’URL prête un peu à confusion. Ces tests n’utilisent pas le protocole ICMP (Internet Control Message Protocol) pour vérifier la disponibilité de votre site. Au lieu cela, ils se servent de fonctionnalités de requête HTTP plus avancées pour s’assurer qu’un point de terminaison répond bien. Ils mesurent les performances associées à cette réponse. Ils permettent aussi de définir des critères de réussite personnalisés à l’aide de fonctionnalités plus avancées, comme analyser des requêtes dépendantes et autoriser de nouvelles tentatives.

Pour créer un test de disponibilité, vous devez utiliser une ressource Application Insights existante ou créer une ressource Application Insights.

Créer un test

Pour créer votre première demande de disponibilité :

1. Dans votre ressource Application Insights, ouvrez le volet Disponibilité et sélectionnez Ajouter un test classique.

   

2. Donnez un nom à votre test et sélectionnez Ping URL pour SKU.

3. Entrez l’URL que vous voulez tester.

4. Ajustez les paramètres à vos besoins à l’aide du tableau suivant. Sélectionnez Create (Créer).

   Paramètre	Description
   URL	L’URL peut être n’importe quelle page web que vous souhaitez tester, mais elle doit être visible à partir de l’Internet public. L’URL peut contenir une chaîne de requête. Vous pouvez donc par exemple tester un peu votre base de données. Si l’URL correspond à une redirection, vous pouvez suivre jusqu’à 10 redirections.
   Analyser les demandes dépendantes	Le test demande des images, des scripts, des fichiers de style et d’autres fichiers qui font partie de la page web de test. Le temps de réponse enregistré inclut le temps qui a été nécessaire pour obtenir ces fichiers. Le test échoue si l’une de ces ressources ne peut pas être téléchargée dans le délai imparti pour l’ensemble du test. Si l’option n’est pas cochée, le test ne demande que le fichier à l’URL spécifiée. L’activation de cette option donne lieu à une vérification plus stricte. Le test peut échouer pour les cas qui ne sont pas perceptibles lors de la navigation manuellement sur le site.
   Autoriser les nouvelles tentatives	Lorsque le test échoue, une nouvelle tentative est effectuée peu après. L’échec est signalé uniquement après trois tentatives infructueuses. Les tests suivants sont ensuite effectués selon la fréquence de test habituelle. La nouvelle tentative est temporairement suspendue jusqu’à la réussite de la tentative suivante. Cette règle est appliquée indépendamment à chaque emplacement de test. Nous recommandons cette option. En moyenne, environ 80 % des échecs disparaissent lors de la nouvelle tentative.
   Fréquence de test	Ce paramètre définit la fréquence selon laquelle le test est exécuté à partir de chaque emplacement de test. Avec, par défaut, une fréquence de cinq minutes et cinq emplacements de test, votre site sera testé en moyenne une fois par minute.
   Emplacements du test	Les valeurs de ce paramètre sont les emplacements à partir desquels les serveurs envoient des requêtes web à votre URL. Nous recommandons au moins cinq emplacements de test pour pouvoir faire la distinction entre les problèmes propres à votre site web et les problèmes de réseau. Vous pouvez sélectionner jusqu’à 16 emplacements.

Si votre URL n’est pas visible à partir de l’Internet public, vous pouvez choisir une ouverture sélective de votre pare-feu pour autoriser uniquement les transactions entrantes à des fins de test. Pour en savoir plus sur les exceptions de pare-feu applicables aux agents de test de disponibilité, consultez le guide des adresses IP.

Critères de réussite

Alertes

Étiquettes de remplissage d’emplacement

Vous pouvez utiliser les étiquettes de remplissage suivantes pour l’attribut de géolocalisation lorsque vous déployez un test Ping d’URL de disponibilité à l’aide d’Azure Resource Manager.

Azure Government

Azure Chine

Azure

Consulter les résultats des tests de disponibilité

Vous pouvez visualiser les résultats des tests de disponibilité à l’aide des vues ligne et nuage de points.

Au bout de quelques minutes, sélectionnez Actualiser pour voir les résultats de vos tests.

La vue en nuage de points montre des exemples de résultats de test contenant des détails de l’étape de test de diagnostic. Le moteur de test stocke les détails de diagnostic pour les tests qui présentent des erreurs. Pour les tests réussis, les détails de diagnostic sont stockés pour un sous-ensemble des exécutions. Pointez sur les points verts ou rouges pour voir le nom du test et son emplacement.

Sélectionnez un test ou emplacement ou réduisez la période pour voir plus de résultats autour de la période d’intérêt. Utilisez l’Explorateur de recherche pour voir les résultats de toutes les exécutions, ou utilisez les requêtes Analytics pour exécuter des rapports personnalisés sur ces données.

Examiner et modifier des tests

Pour modifier, désactiver temporairement ou supprimer un test, sélectionnez les points de suspension ( ... ) en regard du nom du test. Les modifications de la configuration peuvent prendre jusqu’à 20 minutes pour se propager dans tous les agents de test une fois la modification effectuée.

Vous souhaiterez peut-être désactiver les tests de disponibilité ou les règles d’alerte associées lorsque vous effectuez la maintenance de votre service.

Actions en cas d’erreurs

Sélectionnez un point rouge.

À partir d’un résultat de test de disponibilité, vous pouvez voir les détails de la transaction pour tous les composants. Vous pouvez ensuite :

• Examiner le rapport de résolution des problèmes pour déterminer ce qui a pu provoquer l’échec de votre test tant que votre application est toujours disponible.
• Vérifier la réponse reçue à partir de votre serveur.
• Diagnostiquer une défaillance à l’aide des données de télémétrie côté serveur corrélées qui ont été collectées pendant le traitement du test de disponibilité en échec.
• Enregistrer un problème ou un élément de travail dans Git ou Azure Boards pour suivre le problème. Le bogue contient un lien vers cet événement.
• Ouvrir le résultat du test web dans Visual Studio.

Pour en savoir plus sur les diagnostics des transactions de bout en bout, consultez la documentation relative aux diagnostics des transactions.

Sélectionnez la ligne d’une exception pour afficher les détails de l’exception côté serveur qui a provoqué l’échec du test de disponibilité synthétique. Vous pouvez également obtenir la capture instantanée de débogage pour des diagnostics de niveau code plus riches.

Outre les résultats bruts, vous pouvez examiner deux mesures essentielles de la disponibilité dans Metrics Explorer :

• Disponibilité : pourcentage des tests qui ont réussi, sur toutes les exécutions de test.
• Durée du test : durée moyenne du test sur toutes les exécutions de test.

Automatisation

• Utilisez des scripts PowerShell pour configurer un test de disponibilité automatiquement.
• Configurez un webhook qui est appelé lorsqu’une alerte est déclenchée.

Étapes suivantes

• Alertes de disponibilité
• Tests web à plusieurs étapes
• Dépannage
• Modèle Azure Resource Manager pour les tests web