Tests de disponibilité d’Application Insights

Application Insights vous permet de configurer des tests web récurrents qui surveillent la disponibilité et la réactivité de votre site web ou application dans divers endroits du monde. Ces tests de disponibilité envoient des requêtes web à votre application à intervalles réguliers et vous alertent si votre application ne répond pas ou si le temps de réponse est trop lent.

Les tests de disponibilité ne demandent aucune modification du site web ou de l’application que vous testez. Ils fonctionnent pour n’importe quel point de terminaison HTTP ou HTTPS accessible à partir de l’Internet public, y compris les API REST dont dépend votre service. Cela signifie que vous pouvez surveiller non seulement vos propres applications, mais aussi les services externes qui sont essentiels aux fonctionnalités de votre application. Vous pouvez créer jusqu’à 100 tests de disponibilité par ressource Application Insights.

Types de tests de disponibilité

Il existe deux types de tests de disponibilité :

• Test Standard : Type de test de disponibilité qui vérifie la disponibilité d’un site web en envoyant une seule requête, similaire au test ping de l’URL déconseillé. Outre la vérification du fait qu’un point de terminaison répond et la mesure des performances, les tests standard portent également sur la validité du certificat TLS/SSL, la vérification proactive de la durée de vie, le verbe de requête HTTP (par exemple GET, HEAD et POST), les en-têtes personnalisés et les données personnalisées associées à votre requête HTTP.

  Découvrez comment créer un test standard.

• 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.

  Découvrez comment créer un test TrackAvailability personnalisé.

• (Déconseillé) Test Web à plusieurs étapes : 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.

• (Déconseillé) Test de ping d’URL à plusieurs étapes : 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.

Création d'un test de disponibilité

Alertes de disponibilité

Les alertes sont activées automatiquement par défaut, mais pour configurer entièrement une alerte, vous devez tout d’abord créer votre test de disponibilité.

Étiquettes de remplissage d’emplacement

Vous pouvez utiliser les étiquettes de remplissage suivantes pour l’attribut de géolocalisation quand vous déployez un test Standard ou un test ping d’URL en utilisant Azure Resource Manager.

Activer les alertes

1. Après avoir enregistré le test de disponibilité, ouvrez le menu contextuel par le test que vous avez effectué, puis sélectionnez Page Ouvrir les règles (alertes).

   

2. Dans la page Règles d’alerte, ouvrez votre alerte et sélectionnez Modifier dans la barre de navigation supérieure. Vous pouvez définir ici le niveau de gravité, la description des règles et le groupe d’actions disposant des préférences de notification que vous souhaitez utiliser pour cette règle d’alerte.

   

Critères d’alerte

Les alertes de disponibilité activées déclenchent automatiquement un e-mail quand le point de terminaison devient indisponible et un autre e-mail quand il redevient disponible. Les alertes de disponibilité créées à l’aide de cette expérience sont basées sur l’état. Lorsque les critères d’alerte sont remplis, une seule alerte est générée quand le site web est détecté comme n’étant pas disponible. Si le site web est toujours indisponible la prochaine fois que le critère d’alerte est évalué, aucune nouvelle alerte ne sera générée.

Par exemple, supposons que votre site web soit en panne pendant une heure et que vous avez configuré une alerte par e-mail avec une fréquence d’évaluation de 15 minutes. Vous recevez uniquement un e-mail lorsque le site web tombe en panne et un autre e-mail lorsqu’il redevient opérationnel. Vous ne recevez pas d’alertes continues toutes les 15 minutes pour vous rappeler que le site web est toujours indisponible.

Modifier les critères d’alerte

Vous ne souhaitez peut-être pas recevoir de notifications lorsque votre site web est en panne pour une courte période de temps, par exemple pendant la maintenance. Vous pouvez modifier la fréquence d’évaluation à une valeur supérieure au temps d’arrêt attendu, jusqu’à 15 minutes. Vous pouvez également augmenter le seuil d’emplacement de l’alerte, de sorte qu’il déclenche uniquement une alerte si le site web est en panne pour un nombre spécifique de régions.

Pour apporter des modifications au seuil d’emplacement, à la période d’agrégation et à la fréquence des tests, accédez à la page Modifier la règle d’alerte (voir l’étape 2 sous Activer les alertes), puis sélectionnez la condition pour ouvrir la fenêtre Configurer la logique du signal.

Créer une règle d’alerte personnalisée

Si vous avez besoin de fonctionnalités avancées, vous pouvez créer une règle d’alerte personnalisée sous l’onglet Alertes. Sélectionnez Créer>Règle d’alerte. Sélectionnez Métriques pour Type de signal afin d’afficher tous les signaux disponibles, puis Disponibilité.

Une règle d’alerte personnalisée offre des valeurs plus élevées pour la période d’agrégation (jusqu’à 24 heures au lieu de 6 heures) et la fréquence de test (jusqu’à 1 heure au lieu de 15 minutes). Elle propose également d’autres options pour mieux définir la logique en sélectionnant différents opérateurs, types d’agrégation et valeurs de seuil.

• Générer une alerte si X emplacements sur Y signalent des échecs La règle d’alerte X emplacements sur Y est activée par défaut dans l’expérience des nouvelles alertes unifiées quand vous créez un test de disponibilité. Vous pouvez refuser en sélectionnant l’option « classique » ou en choisissant de désactiver la règle d’alerte. Configurez les groupes d’actions pour recevoir des notifications lorsque l’alerte se déclenche en suivant les étapes précédentes. Sans cette étape, vous recevez uniquement les notifications du portail lorsque la règle se déclenche.

• Générer une alerte sur des métriques de disponibilité : en utilisant les nouvelles alertes unifiées, vous pouvez également générer une alerte sur les métriques de disponibilité d’agrégats segmentés et de durée des tests :

  1. Sélectionnez une ressource Application Insights dans l’expérience Métriques, puis sélectionnez une mesure de Disponibilité.

  2. L’option Configurer les alertes dans le menu vous redirige vers la nouvelle expérience où vous pouvez sélectionner des tests ou des emplacements spécifiques sur lesquels vous configurez les règles d’alerte. Ici, vous pouvez également configurer les groupes d’actions pour cette règle d’alerte.

• Générer une alerte sur des requêtes d’analytique personnalisées : en utilisant les nouvelles alertes unifiées, vous pouvez créer des alertes sur des requêtes de journaux personnalisées. Avec des requêtes personnalisées, vous pouvez créer des alertes sur une condition arbitraire qui peut vous aider à obtenir le signal le plus fiable pour des problèmes de disponibilité. Cela s’applique également si vous envoyez les résultats de disponibilité personnalisés en utilisant le Kit de développement logiciel (SDK) TrackAvailability.

  Les mesures sur les données de disponibilité incluent tous les résultats de disponibilité personnalisés que vous pouvez soumettre en appelant le Kit de développement logiciel (SDK) TrackAvailability. Vous pouvez utiliser la prise en charge de la création d’alertes sur les mesures pour créer des alertes sur les résultats de disponibilité personnalisés.

Automatiser les alertes

Pour automatiser ce processus à l’aide de modèles Azure Resource Manager, voir Créer une alerte de métrique avec un modèle Azure Resource Manager.

Consulter les résultats des tests de disponibilité

Cet section explique comment passer en revue les résultats du test de disponibilité sur le portail Azure et comment interroger les données à l’aide de Log Analytics. Les résultats des tests de disponibilité peuvent être visualisés avec des vues Courbe et Nuage de points.

Vérifier la disponibilité

Commencez par examiner le graphique de l’expérience Disponibilité dans le portail Azure.

Par défaut, l’expérience Disponibilité affiche un graphique en courbes. Remplacez la vue par Nuage de points (bouton bascule au-dessus du graphique) pour voir des exemples des résultats de test contenant des détails de l’étape de test des diagnostics. 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. Pour voir le test, son nom et la région, pointez sur les points verts ou les croix rouges.

Sélectionnez un test ou un emplacement particulier. Vous pouvez aussi réduire la période de temps pour voir plus de résultats autour de la période qui vous intéresse. Utilisez l’Explorateur de recherche pour voir les résultats de toutes les exécutions. Vous pouvez aussi utiliser des requêtes Log Analytics pour exécuter des rapports personnalisés sur ces données.

Pour voir les détails de la transaction de bout en bout, sous Explorer, sélectionnez Réussite ou Échec. Sélectionner ensuite un exemple. Vous pouvez également accéder aux détails de la transaction de bout en bout en sélectionnant un point de données sur le graphe.

Examiner et modifier des tests

Pour modifier, désactiver temporairement ou supprimer un test, ouvrez le menu contextuel (points de suspension) par le test, puis sélectionnez Modifier. La propagation de changements de configuration vers tous les agents de test peut prendre jusqu’à 20 minutes.

Si vous constatez des erreurs

Ouvrez la vue Détails de la transaction de bout en bout en sélectionnant une croix rouge sur le nuage de points.

Ici, vous pouvez :

• Passez en revue le Rapport de résolution des problèmes pour déterminer ce qui a pu entraîner l’échec de votre test.
• Vérifier la réponse reçue à partir de votre serveur.
• Diagnostiquer la 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.
• Suivez le problème en consignant un problème ou un élément de travail dans Git ou Azure Boards. Le bogue contient un lien vers l’événement dans le portail Azure.
• Ouvrir le résultat du test web dans Visual Studio.

Pour en savoir plus sur l’expérience des 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 aussi examiner deux métriques de disponibilité essentielles 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.

Requête dans Log Analytics

Vous pouvez utiliser Log Analytics pour voir les résultats de la disponibilité (availabilityResults), les dépendances (dependencies) et plus encore. Pour en savoir plus sur Log Analytics, consultez Vue d’ensemble des requêtes de journal.

Migrer des tests ping d’URL classiques vers des tests standard

Les étapes suivantes vous guident tout au long du processus de création de tests standard qui répliquent les fonctionnalités de vos tests ping d’URL. Cela vous permet de commencer plus facilement à utiliser les fonctionnalités avancées des tests standard à l’aide de vos tests ping d’URL existants.

Prérequis

Démarrage

1. Connectez-vous à votre abonnement avec Azure PowerShell (Connect-AzAccount + Set-AzContext).

2. Répertoriez tous les tests ping d’URL dans l’abonnement en cours :

   Get-AzApplicationInsightsWebTest | `
   Where-Object { $_.WebTestKind -eq "ping" } | `
   Format-Table -Property ResourceGroupName,Name,WebTestKind,Enabled;
   

3. Recherchez le test ping d’URL que vous souhaitez migrer et enregistrez son groupe de ressource et son nom.

4. Créez un test standard avec la même logique que le test ping d’URL à l’aide des commandes suivantes, qui fonctionnent pour les points de terminaison HTTP et HTTPS.

   $resourceGroup = "pingTestResourceGroup";
   $appInsightsComponent = "componentName";
   $pingTestName = "pingTestName";
   $newStandardTestName = "newStandardTestName";
   
   $componentId = (Get-AzApplicationInsights -ResourceGroupName $resourceGroup -Name $appInsightsComponent).Id;
   $pingTest = Get-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
   $pingTestRequest = ([xml]$pingTest.ConfigurationWebTest).WebTest.Items.Request;
   $pingTestValidationRule = ([xml]$pingTest.ConfigurationWebTest).WebTest.ValidationRules.ValidationRule;
   
   $dynamicParameters = @{};
   
   if ($pingTestRequest.IgnoreHttpStatusCode -eq [bool]::FalseString) {
   $dynamicParameters["RuleExpectedHttpStatusCode"] = [convert]::ToInt32($pingTestRequest.ExpectedHttpStatusCode, 10);
   }
   
   if ($pingTestValidationRule -and $pingTestValidationRule.DisplayName -eq "Find Text" `
   -and $pingTestValidationRule.RuleParameters.RuleParameter[0].Name -eq "FindText" `
   -and $pingTestValidationRule.RuleParameters.RuleParameter[0].Value) {
   $dynamicParameters["ContentMatch"] = $pingTestValidationRule.RuleParameters.RuleParameter[0].Value;
   $dynamicParameters["ContentPassIfTextFound"] = $true;
   }
   
   New-AzApplicationInsightsWebTest @dynamicParameters -ResourceGroupName $resourceGroup -Name $newStandardTestName `
   -Location $pingTest.Location -Kind 'standard' -Tag @{ "hidden-link:$componentId" = "Resource" } -TestName $newStandardTestName `
   -RequestUrl $pingTestRequest.Url -RequestHttpVerb "GET" -GeoLocation $pingTest.PropertiesLocations -Frequency $pingTest.Frequency `
   -Timeout $pingTest.Timeout -RetryEnabled:$pingTest.RetryEnabled -Enabled:$pingTest.Enabled `
   -RequestParseDependent:($pingTestRequest.ParseDependentRequests -eq [bool]::TrueString);
   

   Le nouveau test standard n’ayant pas de règles d’alerte par défaut, il ne crée pas d’alertes sonores. Aucune modification n’est apportée à votre test ping d’URL afin que vous puissiez continuer à vous y fier pour les alertes.

5. Validez les fonctionnalités du nouveau test standard, puis mettez à jour vos règles d’alerte qui font référence au test ping d’URL pour qu’elles fassent référence au test standard à la place.

6. Désactivez ou supprimez le test ping d’URL. Pour le faire avec Azure PowerShell, vous pouvez utiliser cette commande :

   Remove-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
   

Effectuer des tests derrière un pare-feu

Pour veiller à la disponibilité de points de terminaison derrière des pare-feux, activez des tests de disponibilité publics ou exécutez des tests de disponibilité dans des scénarios d’entrée déconnectés ou non.

Activation du test de disponibilité public

Vérifiez que votre site web interne dispose d’un enregistrement DNS (Domain Name System) public. Les tests de disponibilité échouent si vous ne pouvez pas résoudre le DNS. Pour plus d’informations, consultez Création d’un nom de domaine personnalisé pour une application interne.

Authentifier le trafic

Définissez des en-têtes personnalisés dans des tests standard pour valider le trafic.

1. Créez une chaîne alphanumérique sans espace pour identifier ce test de disponibilité (par exemple, MyAppAvailabilityTest). À partir de là, nous faisons référence à cette chaîne en tant qu’identificateur de chaîne de test de disponibilité.

2. Ajoutez l’en-tête personnalisé X-Customer-InstanceId avec la valeur ApplicationInsightsAvailability:<your availability test string identifier> sous la section Informations sur les tests Standard lorsque vous créez ou mettez à jour vos tests de disponibilité.

   

3. Veillez à ce que votre service vérifie si le trafic entrant inclut l’en-tête et la valeur définie lors des étapes précédentes.

Vous pouvez également définir l’identificateur de chaîne de test de disponibilité en tant que paramètre de requête.

Exemple : https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your availability test string identifier>

Configurer votre pare-feu pour autoriser les requêtes entrantes à partir des tests de disponibilité

Pour simplifier l’activation de services Azure sans autoriser des IP individuels ou maintenir une liste des IP à jour, utilisez des Étiquettes de service. Appliquez ces étiquettes dans Pare-feu Azure et des groupes de sécurité réseau, ce qui permet l’accès du service de test de disponibilité à vos points de terminaison. L’étiquette de service applique ApplicationInsightsAvailability à tous les tests de disponibilité.

1. Si vous utilisez des groupes de sécurité réseau Azure, accédez à votre ressource de groupe de sécurité réseau et sous Paramètres, ouvrez l’expérience Règles de sécurité de trafic entrant, puis sélectionnez Ajouter.

2. Ensuite, sélectionnez Étiquette de service comme Source et ApplicationInsightsAvailability comme Étiquette de service source. Utilisez les ports ouverts 80 (http) et 443 (https) pour le trafic entrant à partir de l’étiquette de service.

Pour gérer l’accès lorsque vos points de terminaison sont en dehors d’Azure ou lorsque les étiquettes de service ne sont pas une option, établissez une liste d’autorisation des adresses IP de nos agents de test web. Vous pouvez interroger des plages d’adresses IP en utilisant PowerShell, Azure CLI ou un appel REST avec l’API Étiquette de service. Pour obtenir une liste complète des étiquettes de service actuelles et de leur détails sur l’IP, téléchargez le fichier JSON.

1. Dans votre ressource de groupe de sécurité réseau, sous Paramètres, ouvrez l’expérience Règles de sécurité de trafic entrant, puis sélectionnez Ajouter.

2. Ensuite, sélectionnez Adresses IP comme Source. Ajoutez vos adresses IP dans une liste séparée par des virgules dans Plages d’adresses IP sources/CIDR.

Scénarios déconnectés ou sans entrée

1. Connectez votre ressource Application Insights à votre point de terminaison de service interne en utilisant Azure Private Link.

2. Écrivez du code personnalisé pour tester régulièrement votre serveur ou vos points de terminaison internes. Envoyez les résultats à Application Insights en utilisant l’API TrackAvailability() dans le package principal du Kit de développement logiciel (SDK).

Configurations TLS prises en charge

Pour fournir un chiffrement de classe optimale, tous les tests de disponibilité utilisent TLS (Transport Layer Security) 1.2 et 1.3 comme mécanisme de chiffrement privilégié. En outre, les suites de chiffrement et les courbes elliptiques suivantes sont également prises en charge dans chaque version.

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

Dépréciation de configuration TLS

TLS 1.0 et TLS 1.1

TLS 1.0 et 1.1 sont en cours de retrait.

TLS 1.2 et TLS 1.3

Dépannage

Classeur Temps d’arrêt et interruptions

Cette section présente un moyen simple de calculer et d’indiquer le contrat SLA pour les tests web sur un seul et même écran pour vos ressources Application Insights et vos abonnements Azure. Le rapport sur les temps d’arrêt et les interruptions offre de puissantes fonctionnalités et des visualisations de données prédéfinies pour améliorer votre compréhension de la connectivité de votre client, du temps de réponse habituel des applications et des temps d’arrêt.

Le modèle de classeur SLA est accessible à partir de votre ressource Application Insights de deux façons :

• Ouvrez l’expérience Disponibilité, puis sélectionnez Rapport SLA dans la barre de navigation supérieure.

• Ouvrez l’expérience Classeurs et sélectionnez le modèle Temps d’arrêt et interruptions.

Flexibilité des paramètres

Les paramètres définis dans le classeur influencent le reste de votre rapport.

• Subscriptions, App Insights Resources et Web Test : ces paramètres déterminent vos options générales pour les ressources. Ils sont basés sur des requêtes Log Analytics et sont utilisés dans chaque requête des rapports.
• Failure Threshold et Outage Window : vous pouvez utiliser ces paramètres pour déterminer vos propres critères pour une panne de service. Par exemple, les critères d’une alerte de disponibilité Application Insights en fonction d’un compteur d’emplacement défaillant sur une période choisie. Le seuil standard est de trois emplacements dans une fenêtre de cinq minutes.
• Maintenance Period : vous pouvez utiliser ce paramètre pour sélectionner votre fréquence de maintenance classique. Maintenance Window est un sélecteur de DateHeure pour un exemple de période de maintenance. Toutes les données qui sont générées au cours de la période identifiée sont ignorées dans vos résultats.
• Availability Target % : ce paramètre spécifie votre objectif cible et prend des valeurs personnalisées.

Page Vue d’ensemble

La page Vue d’ensemble contient des informations générales sur les éléments suivants :

• Contrat SLA total (à l’exclusion des périodes de maintenance, le cas échéant)
• Instances de panne de bout en bout
• Temps d’arrêt de l’application

Les instances d’interruption sont déterminées à partir du moment où un test commence à échouer jusqu’à ce qu’il réussisse à nouveau, en fonction de vos paramètres d’interruption. Si un test commence à échouer à 8h00 et réussit à nouveau à 10h00, cette période de données tout entière est considérée comme étant la même interruption. Vous pouvez également examiner l’interruption la plus longue qui s’est produite sur la période couverte par votre rapport.

Certains tests peuvent être reliés à leur ressource Application Insights pour une étude plus approfondie. Mais cela n’est possible que dans la ressource Application Insights basée sur l’espace de travail.

Temps d’arrêt, interruptions et défaillances

Il existe deux onglets supplémentaires en regard de la page Vue d’ensemble :

• L’onglet Interruptions et temps d’arrêt contient des informations sur le nombre total d’instances d’interruption et le nombre total de temps d’arrêt décomposés par test.

• L’onglet Défaillances par emplacement a une carte géographique des emplacements de tests ayant échoué pour aider à identifier les zones de connexion ayant des problèmes potentiels.

Autres fonctionnalités

• Personnalisation : Vous pouvez modifier le rapport comme n’importe quel autre classeur Azure Monitor et personnaliser les requêtes ou visualisations en fonction des besoins de votre équipe.

• Log Analytics : Les requêtes peuvent être toutes exécutées dans Log Analytics et être utilisées dans d’autres rapports ou tableaux de bord. Supprimez la restriction du paramètre et réutilisez la requête principale.

• Accès et partage : Le rapport peut être partagé avec vos équipes et votre direction, ou épinglé à un tableau de bord pour l’utiliser ultérieurement. L’utilisateur doit disposer d’autorisations en lecture et d’un accès à la ressource Application Insights où le classeur en question est stocké.

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 ?

Les tests de disponibilité 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.

Après le 1er mars 2025, quel sera le comportement des tests en ligne pour les tests concerné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 1er mars 2025. 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.

Étapes suivantes

• Dépannage
• Modèle Azure Resource Manager pour les tests web
• Test Web API REST