Partager via

Tests de disponibilité d’Application Insights

  • Article

Après avoir déployé votre application web ou votre site web, vous pouvez configurer des tests périodiques pour surveiller la disponibilité et la réactivité. Application Insights envoie des requêtes web à votre application à intervalles réguliers à partir de différents points du monde, Il peut vous alerter si votre application ne répond pas ou si elle répond trop lentement.

Vous pouvez configurer des tests de disponibilité pour n’importe quel point de terminaison HTTP ou HTTPS accessible à partir du réseau Internet public. Vous n’avez pas besoin d’apporter de modifications au site web que vous testez. En fait, vous n’êtes même pas tenu d’en être le propriétaire. Vous pouvez tester la disponibilité d’une API REST dont dépend votre service.

Types de tests

Important

Il existe deux mises hors service de tests de disponibilité à venir. Le 31 août 2024, les tests web multi-étapes dans Application Insights seront mis hors service. Nous conseillons aux utilisateurs de ces tests de passer à d’autres tests de disponibilité avant la date de mise hors service. Après cette date, nous retirerons l’infrastructure sous-jacente, ce qui arrêtera les tests multi-étapes restants. Le 30 septembre 2026, les tests ping d’URL dans Application Insights seront mis hors service. Les tests ping d’URL existants seront supprimés de vos ressources. Passez en revue la tarification pour les tests standard et la transition pour les utiliser avant le 30 septembre 2026 pour vous assurer que vous pouvez continuer à exécuter des tests de disponibilité en une seule étape dans vos ressources Application Insights.

Il existe deux types de tests de disponibilité :

  • Test standard : ce test de requête unique est semblable au test ping d’URL. Il comprend la validité des certificats TLS/SSL, la vérification de la durée de vie proactive, le verbe de requête HTTP (par exemple GET, HEAD ou POST), les en-têtes personnalisés et les données personnalisées associées à votre requête HTTP.
  • Test personnalisé de suivi de la disponibilité : si vous décidez de créer une application personnalisée pour exécuter des tests de disponibilité, vous pouvez utiliser la méthode TrackAvailability()pour envoyer les résultats à Application Insights.
  • Tests classiques (versions antérieures des tests de disponibilité)
    • Test ping d’URL (déconseillé) : vous pouvez créer ce test via le Portail Azure pour vérifier si un point de terminaison répond et mesurer le niveau de performance associé à cette réponse. Vous pouvez également 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.
    • Test Web à plusieurs étapes (déconseillé) : vous pouvez relire cet enregistrement d’une séquence de requêtes Web pour tester des scénarios plus complexes. Les tests Web à plusieurs étapes sont créés dans Visual Studio Enterprise et chargés sur le portail pour y être exécutés.

Important

Les tests classiques antérieurs, test ping d’URL et test Web à plusieurs étapes, s’appuient sur l’infrastructure DNS de l’Internet public pour résoudre les noms de domaine des points de terminaison testés. Si vous utilisez un DNS privé, vous devez vous assurer que les serveurs de noms de domaine publics peuvent résoudre chaque nom de domaine de votre test. Lorsque cela n’est pas possible, vous pouvez utiliser les tests personnalisés de suivi de la disponibilité à la place.

Vous pouvez créer jusqu’à 100 tests de disponibilité par ressource Application Insights.

Notes

Les tests de disponibilité sont stockés sous forme chiffrée, conformément aux stratégies de chiffrement des données Azure au repos.

Prise en charge de TLS

Pour fournir un chiffrement de classe optimale, tous les tests de disponibilité utilisent TLS (Transport Layer Security) 1.2, ou une version ultérieure, comme mécanisme de chiffrement privilégié.

Avertissement

Le 31 octobre 2024, conformément à la dépréciation du TLS hérité à l’échelle d’Azure, les versions du protocole TLS 1.0/1.1 et les suites de chiffrement et les courbes elliptiques TLS 1.2/1.3 héritées seront supprimées pour les tests de disponibilité Application Insights.

Configurations TLS prises en charge

Les versions 1.2 et 1.3 du protocole TLS sont des mécanismes de chiffrement pris en charge pour les tests de disponibilité. En outre, les suites de chiffrement et les courbes elliptiques suivantes sont également prises en charge dans chaque version.

Remarque

TLS 1.3 n’est actuellement disponible que dans ces régions de test de disponibilité : NorthCentralUS, CentralUS, EastUS, SouthCentralUS, WestUS

TLS 1.2

Suites de chiffrement

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Courbes elliptiques

  • NistP384
  • NistP256

TLS 1.3

Suites de chiffrement

  • TLS_AES_256_GCM_SHA384
  • TLS_AES_128_GCM_SHA256

Courbes elliptiques :

  • NistP384
  • NistP256

Dépréciation de configuration TLS

Avertissement

Après le 31 octobre 2024, seules les suites de chiffrement et les courbes elliptiques listées dans les sections TLS 1.2 et TLS 1.3 ci-dessous vont être supprimées. TLS 1.2/1.3 et les suites de chiffrement et courbes elliptiques mentionnées précédemment, sous la section « Configurations TLS prises en charge », sont toujours pris en charge.

TLS 1.0 et TLS 1.1

Les versions du protocole ne sont plus prises en charge

TLS 1.2

Suites de chiffrement

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA

Courbes elliptiques :

  • curve25519

TLS 1.3

Courbes elliptiques

  • curve25519

Forum aux questions

Cette section fournit des réponses aux questions fréquentes.

Général

Puis-je exécuter des tests de disponibilité sur un serveur intranet ?

Nos tests web s’exécutent sur des points de présence qui sont répartis dans le monde entier. Il existe deux solutions :

  • Porte pare-feu : Autorisez les requêtes envoyées à votre serveur à partir de la longue liste modifiable d’agents de test web.
  • Code personnalisé : Écrivez votre propre code pour envoyer des requêtes régulières à votre serveur depuis votre intranet. Vous pouvez exécuter des tests web Visual Studio à cet effet. Le testeur peut envoyer les résultats à Application Insights à l’aide de l’API TrackAvailability().

Quelle est la chaîne de l’agent utilisateur pour les tests de disponibilité ?

La chaîne de l’agent utilisateur est Mozilla/5.0 (compatible ; MSIE 9.0 ; Windows NT 6.1 ; Trident/5.0 ; AppInsights

Prise en charge de TLS

Comment cette dépréciation impacte-t-elle mon comportement de test web ?

Les tests de disponibilité agissent comme un client distribué dans chacun des emplacements de test web pris en charge. Chaque fois qu’un test web est exécuté, le service de test de disponibilité tente d’atteindre le point de terminaison distant défini dans la configuration du test web. Un message Hello du client TLS est envoyé, qui contient toutes les configurations TLS actuellement prises en charge. Si le point de terminaison distant partage une configuration TLS commune avec le client de test de disponibilité, alors l’établissement de la liaison TLS réussit. Sinon, le test web échoue avec un échec d’établissement d'une liaison TLS.

Comment faire pour vérifier que mon test web n’est pas impacté ?

Pour éviter tout impact, chaque point de terminaison distant (y compris les requêtes dépendantes) avec lequel votre test web interagit doit prendre en charge au moins une combinaison de la même version du protocole, de la suite de chiffrement et de la courbe elliptique que le test de disponibilité prend en charge. Si le point de terminaison distant ne prend pas en charge la configuration TLS nécessaire, il doit être mis à jour avec la prise en charge d’une combinaison de la configuration TLS postérieure à la dépréciation mentionnée ci-dessus. Ces points de terminaison peuvent être découverts via l’affichage des Détails de transaction de votre test web (idéalement pour une exécution de test web réussie).

Comment faire pour valider la configuration TLS prise en charge par un point de terminaison distant ?

Il existe plusieurs outils pour définir la configuration TLS prise en charge par un point de terminaison. L’une des méthodes consiste à suivre l’exemple détaillé sur cette page. Si votre point de terminaison distant n’est pas disponible via l’Internet public, vous devez vous assurer de valider la configuration TLS prise en charge sur le point de terminaison distant depuis un ordinateur qui a accès à votre point de terminaison.

Remarque

Pour découvrir les étapes permettant d’activer la configuration TLS nécessaire sur votre serveur web, il est préférable de contacter l’équipe propriétaire de la plateforme d’hébergement sur laquelle votre serveur web s’exécute, si le processus n’est pas connu.

Après le 31 octobre 2024, quel sera le comportement de test web pour les tests impactés ?

Il n’existe aucun type d’exception avec lequel tous les échecs d’établissement d'une liaison TLS affectés par cette dépréciation se présenteraient. Toutefois, l’exception la plus courante qui commencerait à faire échouer votre test web serait The request was aborted: Couldn't create SSL/TLS secure channel. Vous devez également pouvoir voir les échecs liés à TLS dans l’Étape de résolution des problèmes du transport TLS pour le résultat de test web potentiellement impacté.

Puis-je voir quelle configuration TLS est actuellement utilisée par mon test web ?

La configuration TLS négociée pendant une exécution de test web ne peut pas être consultée. Tant que le point de terminaison distant prend en charge la configuration TLS courante avec les tests de disponibilité, aucun impact ne doit être observé après la dépréciation.

Quels composants la dépréciation affecte-t-elle dans le service de test de disponibilité ?

La dépréciation TLS détaillée dans ce document ne doit affecter que le comportement d’exécution des tests web de test de disponibilité après le 31 octobre 2024. Pour plus d’informations sur l’interaction avec le service de test de disponibilité pour les opérations CRUD, consultez Prise en charge TLS d’Azure Resource Manager. Cette ressource fournit plus d’informations sur les chronologies de prise en charge et de dépréciation de TLS.

Où puis-je obtenir des informations sur la prise en charge de TLS ?

Pour toute question générale sur les problème de TLS hérité, consultez Résolution des problèmes TLS.

Dépannage

Avertissement

Nous avons récemment activé TLS 1.3 dans les tests de disponibilité. Si vous voyez de nouveaux messages d’erreur par conséquent, assurez-vous que les clients s’exécutant sur Windows Server 2022 avec TLS 1.3 activé peuvent se connecter à votre point de terminaison. Si vous ne parvenez pas à le faire, vous pouvez envisager de désactiver temporairement TLS 1.3 sur votre point de terminaison afin que les tests de disponibilité reviennent aux versions TLS antérieures.
Pour plus d’informations, consultez l’article de résolution des problèmes. Consultez l’article sur la résolution des problèmes dédié.

Étapes suivantes