Test di disponibilità di Application Insights
Dopo aver distribuito l'app Web o il sito Web, è possibile configurare test ricorrenti per monitorare la disponibilità e la velocità di risposta. Application Insights invia richieste Web all'applicazione a intervalli regolari da diversi punti in tutto il mondo. Può inviare un avviso se l'applicazione non risponde o se risponde troppo lentamente. È possibile creare fino a 100 test di disponibilità per ogni risorsa Application Insights.
I test di disponibilità non richiedono modifiche al sito Web di cui si sta testando e funzionano per qualsiasi endpoint HTTP o HTTPS accessibile dalla rete Internet pubblica. È anche possibile testare la disponibilità di un'API REST da cui dipende il servizio.
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: si tratta di 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 se un endpoint risponde e misura le prestazioni, i test standard includono anche la validità del certificato TLS/SSL, il controllo proattivo della durata, il verbo di richiesta HTTP (ad esempio,
GET
,HEAD
ePOST
), intestazioni personalizzate e dati personalizzati associati alla richiesta HTTP.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.
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à
Suggerimento
Se attualmente si usano altri test di disponibilità, ad esempio i test ping URL, è possibile aggiungere test Standard insieme agli altri. Se si vogliono usare test Standard anziché uno degli altri test, aggiungere un test Standard ed eliminare il test precedente.
Prerequisiti
Operazioni preliminari
Passare alla risorsa di Application Insights e selezionare il riquadro Disponibilità.
Selezionare Aggiungi test standard.
Immettere il nome del test, l'URL e altre impostazioni descritte nella tabella seguente. Quindi, selezionare Crea.
Impostazione Descrizione 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. Si noti che vengono analizzate solo fino a 15 richieste dipendenti. Abilita nuovi tentativi Quando il test non riesce, viene ritentato 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. Test di convalida 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à. Intestazioni personalizzate Coppie di valori chiave che definiscono i parametri operativi. 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à.
Criteri di successo
Impostazione | Descrizione |
---|---|
Timeout 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 sono state 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 stati ricevuti entro questo periodo. |
Risposta HTTP | Il codice di stato restituito che indica un'operazione riuscita. Il numero 200 è il codice che indica che è stata 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à
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 geo-location quando si distribuisce un test ping URL di disponibilità usando Azure Resource Manager.
Azure
Nome visualizzato | Nome popolazione |
---|---|
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
Nome visualizzato | Nome popolazione |
---|---|
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
Nome visualizzato | Nome popolazione |
---|---|
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
Gli avvisi sono ora abilitati automaticamente per impostazione predefinita, ma per configurare completamente un avviso, è necessario creare inizialmente il test di disponibilità.
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.
Dopo aver salvato il test di disponibilità, nella scheda Dettagli selezionare i puntini di sospensione dal test eseguito. Selezionare la pagina Apri regole (avvisi).
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 definito non è disponibile e 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 sia stato configurato un avviso di posta elettronica con una frequenza di valutazione di 15 minuti. Riceverai 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.
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 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à.
Cambiare i criteri di avviso
Per apportare modifiche alla soglia della posizione, al periodo di aggregazione e alla frequenza di test, selezionare la condizione nella pagina di modifica della regola di avviso 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:
Selezionare una risorsa di Application Insights nell'esperienza delle metriche e quindi selezionare una metrica di disponibilità.
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 nella scheda Disponibilità della risorsa di Application Insights.
La vista grafico a dispersione mostra esempi dei risultati dei test con dettagli 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. Passare il puntatore del mouse su uno dei punti verdi/rossi per visualizzare il test, il nome del test e la posizione.
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, selezionare i puntini di sospensione accanto a un nome di test. La propagazione delle modifiche alla configurazione a tutti gli agenti di test dopo aver apportato una modifica potrebbe richiedere fino a 20 minuti.
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
Selezionare un punto rosso.
Dal risultato di un test di disponibilità è possibile visualizzare i dettagli delle transazioni in tutti i componenti. A questo punto è possibile:
- Esaminare il report sulla risoluzione dei problemi per determinare cosa potrebbe aver causato l'esito negativo del test, ma l'applicazione è ancora disponibile.
- 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.
- Registrare un problema o elemento di lavoro in Git o Azure Boards per tenere traccia del problema. Il bug conterrà un collegamento a questo evento.
- 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à, le dipendenze e altro ancora. Per altre informazioni su Log Analytics, vedere Panoramica delle query di log.
Migrare test di disponibilità
In questo articolo viene illustrato il processo di migrazione dai test ping URL classici ai test standard moderni ed efficienti.
Questo processo viene semplificato fornendo istruzioni dettagliate chiare per garantire una transizione senza problemi e fornire alle applicazioni le funzionalità di monitoraggio più aggiornate.
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
- Qualsiasi test ping URL in Application Insights
- Accesso ad Azure PowerShell
Operazioni preliminari
Connettersi alla sottoscrizione con Azure PowerShell (Connect-AzAccount + Set-AzContext).
Elencare tutti i test ping URL nella sottoscrizione corrente:
Get-AzApplicationInsightsWebTest | ` Where-Object { $_.WebTestKind -eq "ping" } | ` Format-Table -Property ResourceGroupName,Name,WebTestKind,Enabled;
Trovare il test ping URL di cui si vuole eseguire la migrazione e registrarne il gruppo di risorse e il nome.
I comandi seguenti creano un test standard con la stessa logica del test ping URL.
Nota
I comandi seguenti funzionano sia per gli endpoint HTTP che per quelli HTTPS, usati nei test ping URL.
$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.
Dopo aver convalidato la funzionalità del nuovo test standard, aggiornare le regole di avviso che fanno riferimento al test ping URL per fare riferimento al test standard. Quindi si disabilita o si elimina il test ping URL.
Per eliminare un test ping URL 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 di disponibilità standard per convalidare il traffico.
Generare un token o un GUID per identificare il traffico dai test di disponibilità.
Aggiungere l'intestazione personalizzata "X-Customer-InstanceId" con il valore
ApplicationInsightsAvailability:<GUID generated in step 1>
nella sezione "Standard test info" durante la creazione o l'aggiornamento dei test di disponibilità.Verificare che il servizio controlli se il traffico in ingresso include l'intestazione e il valore definiti nei passaggi precedenti.
In alternativa, impostare il token come parametro di query. Ad esempio: https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your guid>
.
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à.Se si usano i gruppi di sicurezza di rete di Azure, passare alla risorsa del gruppo di sicurezza di rete e in Impostazioni selezionare le regole di sicurezza in ingresso. Selezionare Aggiungi.
Selezionare quindi Tag del servizio come origine e selezionare 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.
Nella risorsa del gruppo di sicurezza di rete, in Impostazioni selezionare regole di sicurezza in ingresso. Selezionare Aggiungi.
Selezionare quindi Indirizzi IP come origine. Aggiungere quindi gli indirizzi IP in un elenco delimitato da virgole negli intervalli di indirizzi IP/CIRD di origine.
Scenari di ingresso disconnessi o non presenti
Connettere la risorsa di Application Insights all'endpoint del servizio interno usando il collegamento privato di Azure.
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.
Nota
TLS 1.3 è attualmente disponibile solo nelle aree di test di disponibilità: NorthCentralUS, CentralUS, EastUS, SouthCentralUS e WestUS.
TLS 1.2
Pacchetti di crittografia
- 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
Curve ellittiche
- NistP384
- NistP256
TLS 1.3
Pacchetti di crittografia
- TLS_AES_256_GCM_SHA384
- TLS_AES_128_GCM_SHA256
Curve ellittiche:
- NistP384
- NistP256
Deprecazione della configurazione TLS
Avviso
Il 31 ottobre 2024, in linea con la deprecazione di TLS legacy in Azure, le versioni del protocollo TLS 1.0/1.1 e le suite di crittografia e le curve ellittiche TLS 1.2/1.3 legacy elencate di seguito verranno ritirate per i test di disponibilità di Application Insights.
TLS 1.0 e TLS 1.1
Le versioni del protocollo non saranno più supportate
TLS 1.2
Pacchetti di crittografia
- 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
Curve ellittiche:
- curve25519
TLS 1.3
Curve ellittiche
- 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.
Vedere l'articolo sulla risoluzione dei problemi dedicato.
Cartella di lavoro Tempi di inattività, contratto di servizio e interruzioni
Questo articolo 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 il riquadro Disponibilità, quindi selezionare Report contratto di servizio nella parte superiore della schermata.
Aprire il riquadro Cartelle di lavoro, quindi selezionare Tempo di inattività e interruzioni.
Flessibilità dei parametri
I parametri impostati nella cartella di lavoro influiscono sul resto del report.
Subscriptions
,App Insights Resources
eWeb 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
eOutage 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 definite dal momento in cui un test inizia a fallire fino a quando non viene risolto, 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
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.
Modificare il report
È possibile modificare il report come qualsiasi altra cartella di lavoro di Monitoraggio di Azure.
È possibile personalizzare le query o le visualizzazioni in base alle esigenze del team.
Log Analytics
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 dell'autorizzazione di lettura/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 Web vengono eseguiti in punti di presenza distribuiti in tutto il globo. 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 31 ottobre 2024, 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 influirà solo sul comportamento di esecuzione dei test Web di test di disponibilità dopo il 31 ottobre 2024. 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
Commenti e suggerimenti
https://aka.ms/ContentUserFeedback.
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedereInvia e visualizza il feedback per