Test di disponibilità di Application Insights

Application Insights consente di configurare test Web ricorrenti che monitorano la disponibilità e la velocità di risposta del sito Web o dell'applicazione da diversi punti del mondo. Questi test di disponibilità inviano richieste Web all'applicazione a intervalli regolari e avvisano se l'applicazione non risponde o se il tempo di risposta è troppo lento.

I test di disponibilità non richiedono modifiche al sito Web o all'applicazione che si sta testando. Funzionano per qualsiasi endpoint HTTP o HTTPS accessibile dalla rete Internet pubblica, incluse le API REST da cui dipende il servizio. Ciò significa che è possibile monitorare non solo le proprie applicazioni, ma anche i servizi esterni critici per le funzionalità dell'applicazione. È possibile creare fino a 100 test di disponibilità per ogni risorsa Application Insights.

Tipi di test di disponibilità

Sono disponibili quattro tipi di test di disponibilità:

• Test standard: un tipo di test di disponibilità che controlla la disponibilità di un sito Web inviando una singola richiesta, simile al test ping dell'URL deprecato. Oltre a convalidare la risposta di un endpoint e a misurarne le prestazioni, i test Standard includono anche la validità del certificato TLS/SSL, il controllo proattivo della durata, il verbo della richiesta HTTP (ad esempio,GET,HEAD, and POST), le intestazioni personalizzate e i dati personalizzati associati alla richiesta HTTP.

  Informazioni su come creare un test standard.

• Test TrackAvailability personalizzato: se si decide di creare un'applicazione personalizzata per eseguire test di disponibilità, è possibile usare il metodo TrackAvailability() per inviare i risultati ad Application Insights.

  Informazioni su come creare un test TrackAvailability personalizzato.

• Test Web in più passaggi (deprecato): è possibile riprodurre questa registrazione di una sequenza di richieste Web per testare scenari più complessi. I test Web in più passaggi vengono creati in Visual Studio Enterprise e caricati nel portale, in cui è possibile eseguirli.

• Test ping URL (deprecato): è possibile creare questo test tramite il portale di Azure per verificare se un endpoint risponde e misurare le prestazioni associate a tale risposta. È anche possibile impostare criteri di esito positivo personalizzati associati a funzionalità più avanzate, come l'analisi delle richieste dipendenti e la possibilità di ripetere i tentativi.

Crea test di disponibilità

Avvisi di disponibilità

Gli avvisi sono abilitati automaticamente per impostazione predefinita, ma per configurare completamente un avviso, è necessario creare inizialmente il test di disponibilità.

Tag di popolamento della posizione

È possibile usare i tag di popolamento seguenti per l'attributo di posizione geografica quando si distribuisce un test standard o un test ping URL usando Azure Resource Manager.

Attivare gli avvisi

1. Dopo aver salvato il test di disponibilità, aprire il menu di scelta rapida in base al test effettuato, quindi selezionare Apri pagina Regole (Avvisi).

   

2. Nella pagina Regole di avviso aprire l'avviso, quindi selezionare Modifica nella barra di spostamento superiore. Qui è possibile impostare il livello di gravità, la descrizione della regola e il gruppo di azioni con le preferenze di notifica da usare per questa regola di avviso.

   

Criteri di avviso

Gli avvisi di disponibilità abilitati automaticamente attivano un messaggio di posta elettronica quando l'endpoint diventa non disponibile e un altro messaggio di posta elettronica quando è nuovamente disponibile. Gli avvisi di disponibilità creati tramite questa esperienza sono basati sullo stato. Quando vengono soddisfatti i criteri di avviso, viene generato un singolo avviso quando il sito Web viene rilevato come non disponibile. Se il sito Web è ancora inattivo alla successiva valutazione dei criteri di avviso, non genererà un nuovo avviso.

Si supponga, ad esempio, che il sito Web sia inattivo per un'ora e che venga configurato un avviso di posta elettronica con una frequenza di valutazione di 15 minuti. Si riceverà un messaggio di posta elettronica solo quando il sito Web diventa inattivo e un altro messaggio di posta elettronica quando torna online. Non si riceveranno avvisi continui ogni 15 minuti per ricordare che il sito Web non è ancora disponibile.

Cambiare i criteri di avviso

Potresti non voler ricevere notifiche quando il tuo sito Web è inattivo solo per un breve periodo di tempo, ad esempio durante la manutenzione. È possibile modificare la frequenza di valutazione impostando un valore superiore al tempo di inattività previsto, fino a 15 minuti. È anche possibile aumentare la soglia di posizione dell'avviso in modo che attivi un avviso solo se il sito Web è inattivo per un numero specifico di aree.

Per apportare modifiche a soglia della posizione, periodo di aggregazione e frequenza di test, passare alla pagina Modifica regola di avviso (vedere il passaggio 2 in Abilita avvisi), quindi selezionare la condizione per aprire la finestra Configura logica del segnale.

Creare una regola di avviso personalizzata

Se sono necessarie funzionalità avanzate, è possibile creare una regola di avviso personalizzata nella scheda Avvisi. Selezionare Crea>Regola di avviso. Scegliere Metriche per Tipo di segnale per visualizzare tutti i segnali disponibili e selezionare Disponibilità.

Una regola di avviso personalizzata offre valori più elevati per il periodo di aggregazione (fino a 24 ore anziché 6 ore) e la frequenza di test (fino a 1 ora anziché 15 minuti). Aggiunge anche opzioni per definire ulteriormente la logica selezionando operatori, tipi di aggregazione e valori soglia diversi.

• Avviso per X di Y posizioni non riuscite che segnalano errori: la regola di avviso X di Y posizioni è abilitata per impostazione predefinita nella nuova esperienza di avvisi unificati quando si crea un nuovo test di disponibilità. È possibile rifiutarla esplicitamente selezionando l'opzione "classica" o scegliendo di disabilitare la regola di avviso. Configurare i gruppi di azioni per ricevere le notifiche quando viene attivato l'avviso seguendo i passaggi precedenti. Se non si esegue questa procedura, le notifiche all'interno del portale si riceveranno solo quando la regola viene attivata.

• Avviso sulle metriche di disponibilità: usando i nuovi avvisi unificati è possibile generare avvisi per la disponibilità aggregata segmentata e anche per le metriche di durata dei test:

  1. Selezionare una risorsa di Application Insights nell'esperienza delle metriche e quindi selezionare una metrica di disponibilità.

  2. L'opzione Configura avvisi disponibile nel menu consentirà di accedere alla nuova esperienza in cui è possibile selezionare test specifici o località per le quali configurare le regole di avviso. In questa schermata è anche possibile configurare i gruppi di azioni per questa regola di avviso.

• Avviso per le query di analisi personalizzate: usando i nuovi avvisi unificati, è possibile inviare avvisi sulle query di log personalizzate. Con le query personalizzate è possibile inviare avvisi per qualsiasi condizione arbitraria che consenta di ottenere il segnale più affidabile di problemi di disponibilità. È applicabile anche se si inviano risultati di disponibilità personalizzati usando TrackAvailability SDK.

  Le metriche sui dati di disponibilità includono tutti i risultati di disponibilità personalizzati che si possono inviare chiamando l'SDK TrackAvailability. È possibile usare gli avvisi per il supporto delle metriche per inviare avvisi sui risultati di disponibilità personalizzati.

Automatizzare gli avvisi

Per automatizzare questo processo con i modelli di Azure Resource Manager, vedere Creare un avviso di metrica con un modello di Azure Resource Manager.

Visualizzare i risultati dei test di disponibilità

Questa sezione illustra come esaminare i risultati del test di disponibilità nel portale di Azure ed eseguire query sui dati usando Log Analytics. I risultati dei test di disponibilità possono essere visualizzati con visualizzazioni Grafico a linee e a dispersione

Verifica disponibilità

Per iniziare, esaminare il grafico nell'esperienza Disponibilità nel portale di Azure.

Per impostazione predefinita, l'esperienza Disponibilità mostra un grafo a linee. Modificare la visualizzazione in Grafico a dispersione (alternare sopra il grafico) per visualizzare i campioni dei risultati dei test contenenti i dettagli dei passaggi di test diagnostici. Il motore di test archivia i dettagli diagnostici per i test che hanno restituito errori. Per i test riusciti, vengono archiviati i dettagli diagnostici per un subset delle esecuzioni. Per visualizzare il test, il nome del test e la posizione, passare il puntatore del mouse su uno dei punti verdi o delle croce rosse.

Selezionare un test o un percorso specifico. In alternativa, è possibile ridurre il periodo di tempo per visualizzare più risultati intorno al periodo di tempo di interesse. Usare Esplora ricerche per visualizzare i risultati di tutte le esecuzioni. In alternativa, è possibile usare le query di Log Analytics per eseguire report personalizzati su questi dati.

Per visualizzare i dettagli delle transazioni end-to-end, in Drill-into, selezionare Operazione riuscita o Non riuscita. Selezionare quindi un esempio. È anche possibile accedere ai dettagli delle transazioni end-to-end selezionando un punto dati nel grafico.

Esaminare e modificare i test

Per modificare, disabilitare temporaneamente o eliminare un test, aprire il menu di scelta rapida (puntini di sospensione) dal test, quindi selezionare Modifica. La propagazione delle modifiche alla configurazione a tutti gli agenti di test dopo aver apportato una modifica potrebbe richiedere fino a 20 minuti.

In caso di errori

Aprire la visualizzazione Dettagli transazione end-to-end selezionando una croce rossa nel Grafico a dispersione.

A questo punto è possibile:

• Esaminare il Report di risoluzione dei problemi per determinare il potenziale errore del test.
• Controllare la risposta ricevuta dal server.
• Diagnosticare l'errore con i dati di telemetria lato server correlati, raccolti durante l'elaborazione del test di disponibilità non riuscito.
• Tenere traccia del problema registrando un problema o un elemento di lavoro in Git o in Azure Boards. Il bug contiene un collegamento all'evento nel portale di Azure.
• Aprire il risultato del test Web in Visual Studio.

Per altre informazioni sull'esperienza di diagnostica delle transazioni end-to-end, vedere la documentazione sulla diagnostica delle transazioni.

Selezionare la riga dell'eccezione per visualizzare i dettagli dell'eccezione lato server che ha causato l'errore durante il test di disponibilità sintetico. È anche possibile ottenere lo snapshot di debug per una diagnostica più avanzata a livello di codice.

Oltre ai risultati non elaborati, è anche possibile visualizzare due metriche di disponibilità chiave in Esplora metriche:

• Disponibilità: percentuale dei test riusciti rispetto a tutte le esecuzioni di test.
• Durata test: durata media dei test rispetto a tutte le esecuzioni di test.

Query in Log Analytics

È possibile usare Log Analytics per visualizzare i risultati di disponibilità (availabilityResults), le dipendenze (dependencies) e altro ancora. Per altre informazioni su Log Analytics, vedere Panoramica delle query di log.

Eseguire la migrazione dei test di ping URL classici ai test standard

I passaggi seguenti illustrano il processo di creazione di test standard che replicano la funzionalità dei test ping URL. Consente di iniziare più facilmente a usare le funzionalità avanzate dei test standard usando i test ping URL creati in precedenza.

Prerequisiti

Operazioni preliminari

1. Connettersi alla sottoscrizione con Azure PowerShell (Connect-AzAccount + Set-AzContext).

2. Elencare tutti i test ping URL nella sottoscrizione corrente:

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

3. Trovare il test ping URL di cui si vuole eseguire la migrazione e registrarne il gruppo di risorse e il nome.

4. Creare un test standard con la stessa logica del test ping URL usando i comandi seguenti, i quali funzionano per gli endpoint HTTP e 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);
   

   Il nuovo test standard non include regole di avviso per impostazione predefinita, quindi non crea avvisi rumorosi. Non vengono apportate modifiche al test del ping URL in modo da poter continuare a basarsi su di esso per gli avvisi.

5. Validare la funzionalità del nuovo test standard, quindi aggiornare le regole di avviso che fanno riferimento al test ping URL per fare invece riferimento al test standard.

6. Disabilitare o eliminare il test ping URL. A tale scopo, con Azure PowerShell è possibile usare questo comando:

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

Test dietro un firewall

Per garantire la disponibilità degli endpoint dietro i firewall, abilitare test di disponibilità pubblici o eseguire test di disponibilità in scenari disconnessi o senza ingresso.

Abilitazione del test di disponibilità pubblica

Verificare che il sito Web interno abbia un record DNS (Domain Name System) pubblico. I test di disponibilità hanno esito negativo se il DNS non può essere risolto. Per altre informazioni, vedere Creare un nome di dominio personalizzato per l'applicazione interna.

Autenticare il traffico

Impostare intestazioni personalizzate nei test standard per convalidare il traffico.

1. Creare una stringa alfanumerica senza spazi per identificare questo test di disponibilità, ad esempio MyAppAvailabilityTest. Da qui in poi fare riferimento a questa stringa come identificatore della stringa del test di disponibilità.

2. Aggiungere l'intestazione personalizzata X-Customer-InstanceId con il valore ApplicationInsightsAvailability:<your availability test string identifier> nella sezione Standard test info durante la creazione o l'aggiornamento dei test di disponibilità.

   

3. Verificare che il servizio controlli se il traffico in ingresso include l'intestazione e il valore definiti nei passaggi precedenti.

In alternativa, impostare l'identificatore della stringa di test di disponibilità come parametro di query.

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

Configurare il firewall per consentire le richieste in ingresso dai test di disponibilità

Per semplificare l'abilitazione dei servizi di Azure senza autorizzare singoli indirizzi IP o mantenere un elenco di indirizzi IP aggiornati, usare i tag del servizio. Applicare questi tag tra Firewall di Azure e i gruppi di sicurezza di rete, consentendo al servizio di test di disponibilità l'accesso agli endpoint. Il tag del servizio ApplicationInsightsAvailability si applica a tutti i test di disponibilità.

1. Se si usa Gruppi di sicurezza di rete di Azure, passare alla risorsa del gruppo di sicurezza di rete e in Impostazioni aprire l'esperienza di regole di sicurezza in ingresso, quindi selezionare Aggiungi.

2. Selezionare quindi Tag del servizio come Origine e ApplicationInsightsAvailability come Tag del servizio di origine. Usare le porte 80 (http) e 443 (https) per il traffico in ingresso dal tag del servizio.

Per gestire l'accesso quando gli endpoint si trovano all'esterno di Azure o quando i tag di servizio non sono un'opzione, consentire gli indirizzi IP degli agenti di test Web. È possibile eseguire query su intervalli IP usando PowerShell, l'interfaccia della riga di comando di Azure o una chiamata REST con l'API Tag del servizio. Per un elenco completo dei tag di servizio correnti e dei relativi dettagli IP, scaricare il file JSON.

1. Nella risorsa del gruppo di sicurezza di rete, in Impostazioni, aprire l'esperienza Regole di sicurezza in ingresso e quindi selezionare Aggiungi.

2. Selezionare quindi Indirizzi IP come Origine. Poi aggiungere gli indirizzi IP in un elenco delimitato da virgole in intervalli di indirizzi IP/CIRD di origine.

Scenari di ingresso disconnessi o non presenti

1. Connettere la risorsa di Application Insights all'endpoint del servizio interno usando il collegamento privato di Azure.

2. Scrivere codice personalizzato per testare periodicamente il server o gli endpoint interni. Inviare i risultati ad Application Insights tramite l'API TrackAvailability() nel pacchetto SDK principale.

Configurazioni TLS supportate

Per fornire la crittografia ottimale in classe, tutti i test di disponibilità usano Transport Layer Security (TLS) 1.2 e 1.3 come meccanismo di crittografia preferito. Inoltre, all'interno di ogni versione sono supportati anche i pacchetti di crittografia e le curve ellittiche seguenti.

TLS 1.3 è attualmente disponibile solo nelle aree di test di disponibilità: NorthCentralUS, CentralUS, EastUS, SouthCentralUS e WestUS.

Deprecazione della configurazione TLS

TLS 1.0 e TLS 1.1

È in corso il ritiro di TLS 1.0 e 1.1.

TLS 1.2 e TLS 1.3

Risoluzione dei problemi

Cartella di lavoro tempo di inattività e interruzioni

Questa sezione presenta un modo semplice per calcolare e segnalare il contratto di servizio per i test Web tramite un unico riquadro di panoramica tra le risorse di Application Insights e le sottoscrizioni di Azure. Il report relativo a tempi di inattività e interruzioni offre potenti query e visualizzazioni dei dati predefinite per migliorare la comprensione della connettività del cliente, del tempo di risposta tipico dell'applicazione e del tempo di inattività riscontrato.

È possibile accedere al modello di cartella di lavoro del contratto di servizio dalla risorsa di Application Insights in due modi:

• Aprire l'esperienza Disponibilità, quindi selezionare Report contratto di servizio nella barra di spostamento superiore.

• Aprire l'esperienza Cartelle di lavoro, quindi selezionare il modello Tempo di inattività e interruzioni.

Flessibilità dei parametri

I parametri impostati nella cartella di lavoro influiscono sul resto del report.

• Subscriptions, App Insights Resources e Web Test: questi parametri determinano le opzioni delle risorse di alto livello. Si basano sulle query di Log Analytics e vengono usate in ogni query di report.
• Failure Threshold e Outage Window: è possibile usare questi parametri per determinare i propri criteri per un'interruzione del servizio. Un esempio è costituito dai criteri per un avviso di disponibilità di Application Insights in base a un contatore della posizione non riuscito in un periodo scelto. La soglia tipica è di tre posizioni in una finestra di cinque minuti.
• Maintenance Period: è possibile usare questo parametro per selezionare la frequenza di manutenzione tipica. Maintenance Window è un selettore datetime per un periodo di manutenzione di esempio. Tutti i dati che si verificano durante il periodo identificato verranno ignorati nei risultati.
• Availability Target %: questo parametro specifica l'obiettivo di destinazione e accetta valori personalizzati.

Pagina di panoramica

La pagina di panoramica contiene informazioni di alto livello su:

• Contratto di servizio totale (escluso i periodi di manutenzione, se definiti)
• Istanze di interruzione end-to-end
• Tempo di inattività dell'applicazione

Le istanze di interruzione vengono determinate dal momento in cui un test inizia a non riuscire fino a quando ricomincia a riuscire, in base ai parametri di interruzione. Se un test inizia con esito negativo alle 8:00 e viene eseguito di nuovo alle 10:00, l'intero periodo di dati viene considerato come la stessa interruzione. È anche possibile analizzare l'interruzione più lunga che si è verificata nel periodo di riferimento.

Alcuni test sono collegabili alla risorsa di Application Insights per ulteriori indagini. Ma questo è possibile solo nella risorsa di Application Insights basata sull'area di lavoro.

Tempi di inattività, interruzioni ed errori

Accanto alla pagina Panoramica sono disponibili altre due schede:

• La scheda Tempo di inattività e interruzioni contiene informazioni sulle istanze di interruzione totali e sul tempo di inattività totale suddiviso per test.

• La scheda Errori per posizione include una mappa geografica delle posizioni di test non riuscite per identificare le potenziali aree di connessione dei problemi.

Altre funzionalità

• Personalizzazione: è possibile modificare il report come qualsiasi altra cartella di lavoro di Monitoraggio di Azure e personalizzare le query o le visualizzazioni in base alle esigenze del team.

• Log Analytics: tutte le query possono essere eseguite in Log Analytics e usate in altri report o dashboard. Rimuovere la restrizione del parametro e riutilizzare la query principale.

• Accesso e condivisione: il report può essere condiviso con i team e la leadership o aggiunto a un dashboard per un ulteriore uso. L'utente deve disporre delle autorizzazioni di lettura e dell'accesso alla risorsa di Application Insights in cui è archiviata la cartella di lavoro effettiva.

Domande frequenti

Questa sezione fornisce le risposte alle domande comuni.

Generali

È possibile eseguire test di disponibilità in un server Intranet?

I test di disponibilità vengono eseguiti in punti di presenza distribuiti in tutto il mondo. Sono disponibili due soluzioni:

• Porta di firewall: consentire al server di ricevere richieste dall'elenco esteso e modificabile degli agenti di test Web.
• Codice personalizzato: scrivere un codice personalizzato per inviare richieste periodiche al server dall'interno della rete Intranet. A tale scopo è anche possibile eseguire test Web di Visual Studio. Il tester può inviare i risultati ad Application Insights tramite l'API TrackAvailability().

Qual è la stringa dell'agente utente per i test di disponibilità?

La stringa agente utente è Mozilla/5.0 (compatibile; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

Supporto TLS

In che modo questa deprecazione influisce sul comportamento dei test Web?

I test di disponibilità fungono da client distribuito in ognuno dei percorsi di test Web supportati. Ogni volta che un test Web viene eseguito, il servizio di test di disponibilità tenta di raggiungere l'endpoint remoto definito nella configurazione del test Web. Viene inviato un messaggio Hello client TLS che contiene tutte le configurazioni TLS attualmente supportate. Se l'endpoint remoto condivide una configurazione TLS comune con il client di test di disponibilità, l'handshake TLS ha esito positivo. In caso contrario, il test Web non riesce con un errore di handshake TLS.

Come è possibile assicurarsi che il test Web non sia interessato?

Per evitare impatti, ogni endpoint remoto (incluse le richieste dipendenti) con cui interagisce il test Web deve supportare almeno una combinazione della stessa versione del protocollo, della suite di crittografia e della curva ellittica supportata dal test di disponibilità. Se l'endpoint remoto non supporta la configurazione TLS necessaria, deve essere aggiornato con il supporto per alcune combinazioni della configurazione TLS post-deprecazione precedente. Questi endpoint possono essere individuati visualizzando i Dettagli delle transazioni del test Web (idealmente per una sua esecuzione corretta).

Come si convalida la configurazione TLS supportata da un endpoint remoto?

Sono disponibili diversi strumenti per testare la configurazione TLS supportata da un endpoint. Un modo consiste nel seguire l'esempio dettagliato in questa pagina. Se l'endpoint remoto non è disponibile tramite Internet pubblico, è necessario assicurarsi di convalidare la configurazione TLS supportata nell'endpoint remoto da un computer che ha accesso per chiamare l'endpoint.

Dopo il 1° maggio 2025, quale sarà il comportamento del test Web per i test interessati?

Non esiste un tipo di eccezione con cui si presentano tutti gli errori di handshake TLS interessati da questa deprecazione. Tuttavia, l'eccezione più comune che il test Web potrebbe incontrare in caso di errore sarebbe The request was aborted: Couldn't create SSL/TLS secure channel. Dovrebbe anche essere possibile visualizzare eventuali errori correlati a TLS nel passaggio di risoluzione dei problemi di TLS Transport per il risultato del test Web potenzialmente interessato.

È possibile visualizzare la configurazione TLS attualmente in uso dal test Web?

Non è possibile visualizzare la configurazione TLS negoziata durante l'esecuzione di un test Web. Se l'endpoint remoto supporta la configurazione TLS comune con i test di disponibilità, non dovrebbe essere riscontrato alcun impatto dopo la deprecazione.

Quali componenti influiscono sulla deprecazione nel servizio di test di disponibilità?

La deprecazione TLS descritta in questo documento deve influire solo sul comportamento di esecuzione dei test Web di test di disponibilità dopo il 1° maggio 2025. Per altre informazioni sull'interazione con il servizio di test di disponibilità per le operazioni CRUD, vedere Supporto TLS di Azure Resource Manager. Questa risorsa fornisce altri dettagli sul supporto TLS e sulle sequenze temporali di deprecazione.

Dove è possibile ottenere il supporto TLS?

Per eventuali domande generali sul problema TLS legacy, vedere Risoluzione dei problemi TLS.

Passaggi successivi

• Risoluzione dei problemi
• Modello di Azure Resource Manager per i test Web
• API REST del test Web