Condividi tramite

Test di disponibilità di Application Insights

  • Articolo

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.

Nota

I test di disponibilità vengono archiviati crittografati, in base ai criteri di crittografia dei dati inattivi di Azure.

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.

Importante

Due test di disponibilità verranno ritirati a breve:

  • Test Web in più passaggi: il 31 agosto 2024 i test Web in più passaggi in Application Insights verranno ritirati. È consigliabile che gli utenti di questi test passino a test di disponibilità alternativi prima della data di ritiro. Dopo questa data, verrà eseguita l'interruzione dell'infrastruttura sottostante che interromperà i test in più passaggi rimanenti.

  • Test ping URL: il 30 settembre 2026 i test ping URL in Application Insights verranno ritirati. I test ping URL esistenti verranno rimossi dalle risorse. Esaminare i prezzi per i test standard ed eseguire la transizione in modo da usarli prima del 30 settembre 2026 per assicurarsi di poter continuare a eseguire test di disponibilità in passaggi singoli nelle risorse di Application Insights.

Crea test di disponibilità

Prerequisiti

Operazioni preliminari

  1. Passare alla risorsa di Application Insights e aprire l'esperienza Disponibilità.

  2. Selezionare Aggiungi test Standard nella barra di spostamento superiore.

    Screenshot che mostra l'esperienza Disponibilità con la scheda Aggiungi test standard aperta.

  3. Immettere il nome del test, l'URL e altre impostazioni descritte nella tabella seguente, quindi selezionare Crea.

    Sezione Impostazione Descrizione
    Informazioni di base
    URL L'URL può essere qualsiasi pagina Web che si vuole testare, ma deve essere visibile da Internet pubblico. L'URL può includere una stringa di query. In questo modo, ad esempio, è possibile esercitarsi nell'uso del database. Se l'URL comporta un reindirizzamento, l'operazione viene effettuata fino a un numero massimo di 10 reindirizzamenti.
    Analizza richieste dipendenti Il test richiede immagini, script, file di stile e altri file che fanno parte della pagina Web sottoposta a test. Il tempo di risposta registrato include il tempo impiegato per ottenere questi file. Il test avrà esito negativo se non è possibile scaricare una di queste risorse entro il timeout definito per l'intero test. Se l'opzione non viene selezionata, il test richiede solo il file in corrispondenza dell'URL specificato. L'abilitazione di questa opzione comporta un controllo più rigoroso. Il test potrebbe non riuscire per maiuscole/minuscole, che potrebbero non essere evidenti quando si esplora manualmente il sito. Vengono analizzate solo fino a 15 richieste dipendenti.
    Abilitare nuovi tentativi in caso di test di disponibilità non superati Quando il test non riesce, vi è un nuovo tentativo dopo un breve intervallo. Un errore viene segnalato solo se tre tentativi successivi non riescono. I test successivi vengono quindi eseguiti in base alla frequenza di test normale. I nuovi tentativi saranno temporaneamente sospesi fino al completamento successivo. Questa regola viene applicata in modo indipendente in ogni località di test. Questa opzione è consigliata. In media, circa l'80% degli errori non si ripresenta al nuovo tentativo.
    Abilita validità del certificato SSL È possibile verificare il certificato SSL nel sito Web per assicurarsi che sia installato correttamente, valido, attendibile e non restituisca errori a nessuno degli utenti.
    Controllo proattivo della durata Questa impostazione consente di definire un periodo di tempo impostato prima della scadenza del certificato SSL. Dopo la scadenza, il test avrà esito negativo.
    Frequenza test impostare la frequenza di esecuzione del test da ogni località di test. Con una frequenza predefinita di cinque minuti e cinque località di test, il sito verrà testato in media ogni minuto.
    Località di test I server inviano richieste Web all'URL da queste posizioni. Il numero minimo di località di test consigliate è cinque per essere certi di poter distinguere i problemi del sito Web da quelli della rete. È possibile selezionare fino a 16 località.
    Informazioni sui test standard
    Verbo richiesta HTTP Indicare l'azione da eseguire con la richiesta.
    Testo della richiesta Dati personalizzati associati alla richiesta HTTP. È possibile caricare i propri file, immettere il contenuto o disabilitare questa funzionalità.
    Aggiungere intestazioni personalizzate Coppie di valori chiave che definiscono i parametri operativi.
    Criteri di superamento
    Timeout dei test ridurre questo valore per ricevere avvisi in merito alle risposte lente. Il test viene conteggiato come non riuscito se le risposte dal sito non vengono ricevute entro questo periodo. Se è stata selezionata l'opzione Analizza richieste dipendenti, è necessario che tutti gli script, i file di stile, le immagini e le altre risorse dipendenti siano ricevute entro questo periodo.
    Risposta HTTP Il codice di stato restituito contava come operazione riuscita. Il numero 200 è il codice che indica che viene restituita una normale pagina Web.
    Il contenuto corrisponde a Una stringa, ad esempio "Benvenuto". Verifichiamo che in ogni risposta ci una corrispondenza esatta di maiuscolo e minuscolo. Deve trattarsi di una stringa di testo normale, senza caratteri jolly. È importante ricordare che, se il contenuto cambia, potrebbe essere necessario aggiornare la stringa. Con la corrispondenza del contenuto sono supportati solo i caratteri inglesi.

Avvisi di disponibilità

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

Impostazione Descrizione
Near real-time Si consiglia di usare gli avvisi near real-time. La configurazione di questo tipo di avviso viene eseguita dopo la creazione del test di disponibilità.
Soglia località di avviso Si consiglia un minimo di 3-5 posizioni. Il rapporto ottimale tra la soglia località di avviso e il numero di località di test è dato da soglia località di avviso = numero di località di test - 2, con un numero minimo pari a cinque località di test.

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.

Provider Nome visualizzato Nome popolazione
Azure
Australia orientale emea-au-syd-edge
Brasile meridionale latam-br-gru-edge
Stati Uniti centrali us-fl-mia-edge
Asia orientale apac-hk-hkn-azr
Stati Uniti orientali us-va-ash-azr
Francia meridionale (in precedenza Francia centrale) emea-ch-zrh-edge
Francia centrale emea-fr-pra-edge
Giappone orientale apac-jp-kaw-edge
Europa settentrionale emea-gb-db3-azr
Stati Uniti centro-settentrionali us-il-ch1-azr
Stati Uniti centro-meridionali us-tx-sn1-azr
Asia sud-orientale apac-sg-sin-azr
Regno Unito occidentale emea-se-sto-edge
Europa occidentale emea-nl-ams-azr
Stati Uniti occidentali us-ca-sjc-azr
Regno Unito meridionale emea-ru-msa-edge
Azure Government
USGov Virginia usgov-va-azr
USGov Arizona usgov-phx-azr
USGov Texas usgov-tx-azr
Stati uniti orientali DoD usgov-ddeast-azr
Stati Uniti centrali DoD usgov-ddcentral-azr
Microsoft Azure gestito da 21Vianet
Cina orientale mc-cne-azr
Cina orientale 2 mc-cne2-azr
Cina settentrionale mc-cnn-azr
Cina settentrionale 2 mc-cnn2-azr

Attivare gli avvisi

Nota

con i nuovi avvisi unificati, la gravità delle regole di avviso e le preferenze di notifica con gruppi di azionidevono essere configurate nell'esperienza degli avvisi. Se non si esegue la procedura seguente, si riceveranno notifiche solo all'interno del portale.

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

    Screenshot che mostra l'esperienza Disponibilità per una risorsa di Application Insights nel portale di Azure e l'opzione di menu Apri 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.

    Screenshot che mostra una pagina della regola di avviso nel portale di Azure con l'opzione Modifica evidenziata.

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.

Suggerimento

Per tempi di inattività pianificati più lunghi, disattivare temporaneamente la regola di avviso o creare una regola personalizzata. Offre più opzioni per tenere conto del tempo di inattività.

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.

Screenshot che mostra una condizione di avviso evidenziata e 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.

Screenshot che mostra il grafo dell'esperienza Disponibilità, evidenziando l'interruttore tra la linea e il grafico a dispersione.

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.

Screenshot che mostra la selezione di un test di disponibilità di esempio.

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.

Suggerimento

Può essere necessario disabilitare i test di disponibilità o le regole di avviso associate ai test durante le operazioni di manutenzione del servizio.

In caso di errori

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

Screenshot che mostra la scheda dei dettagli delle transazioni end-to-end.

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.

Screenshot che mostra i risultati della disponibilità in 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.

Importante

Un costo è associato all'esecuzione di test standard. Dopo aver creato un test standard, verranno addebitati i costi per le esecuzioni di test. Fare riferimento ai prezzi di Monitoraggio di Azure prima di iniziare questo processo.

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.

Avviso

Gli indirizzi IP usati dal servizio test di disponibilità vengono condivisi e possono esporre gli endpoint di servizio protetti dal firewall ad altri test. Il filtro degli indirizzi IP da solo non protegge il traffico del servizio, quindi è consigliabile aggiungere intestazioni personalizzate aggiuntive per verificare l'origine della richiesta Web. Per altre informazioni, vedere Tag del servizio di rete virtuale.

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

    Screenshot che mostra l'intestazione di convalida personalizzata.

  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à

Nota

Questo esempio è specifico dell'utilizzo dei tag del servizio del gruppo di sicurezza di rete. Molti servizi di Azure accettano tag di servizio, ognuno dei quali richiede passaggi di configurazione diversi.

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.

Versione Pacchetti di crittografia Curve ellittiche
TLS 1.2 • 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		 • NistP384
• NistP256
TLS 1.3 • TLS_AES_256_GCM_SHA384
• TLS_AES_128_GCM_SHA256		 • NistP384
• NistP256

Deprecazione della configurazione TLS

Importante

Il 1° marzo 2025, in linea con il ritiro legacy di TLS a livello di Azure, le versioni del protocollo TLS 1.0/1.1 e le versioni del protocollo TLS 1.2/1.3 legacy e le curve ellittiche verranno ritirati per i test di disponibilità di Application Insights.

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

Versione Pacchetti di crittografia Curve ellittiche
TLS 1.2 • 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		 • curve25519
TLS 1.3 • curve25519

Risoluzione dei problemi

Avviso

TLS 1.3 è stato abilitato di recente nei test di disponibilità. Se vengono visualizzati nuovi messaggi di errore, assicurarsi che i client in esecuzione in Windows Server 2022 con TLS 1.3 abilitato possano connettersi all'endpoint. Se non è possibile eseguire questa operazione, è possibile disabilitare temporaneamente TLS 1.3 nell'endpoint in modo che i test di disponibilità rientrino nelle versioni TLS precedenti.

Per altre informazioni, vedere l'articolo sulla 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.

Screenshot che mostra i parametri.

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

Nota

Per i passaggi per abilitare la configurazione TLS necessaria nel server Web, è consigliabile contattare il team proprietario della piattaforma di hosting in cui viene eseguito il server Web se il processo non è noto.

Dopo il 1° marzo 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° marzo 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