Test di disponibilità di Application Insights

Articolo
07/24/2024

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 e POST), 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.

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

Risorsa di Application Insights basata sull'area di lavoro

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.

Importante

TrackAvailability() richiede un investimento per gli sviluppatori nella scrittura e nella maintanining di codice personalizzato potenzialmente complesso.

I test standard devono essere sempre usati se possibile in quanto richiedono poco investimento, nessuna manutenzione e hanno alcuni prerequisiti.

Prerequisiti

Risorsa di Application Insights basata sull'area di lavoro
Accesso al codice sorgente di un'app per le funzioni in Funzioni di Azure
Competenze per gli sviluppatori in grado di creare codice personalizzato per TrackAvailability(), personalizzato in base alle esigenze aziendali specifiche

Esempio di codice di base

Nota

Questo esempio è progettato esclusivamente per illustrare i meccanismi di funzionamento della chiamata API TrackAvailability() all'interno di una funzione di Azure. Non viene illustrato come scrivere il codice di test HTTP sottostante o la logica di business necessaria per trasformare questo esempio in un test di disponibilità completamente funzionale.

Per impostazione predefinita, se si esegue questo esempio, si creerà un test HTTP GET di disponibilità di base. Per seguire queste istruzioni, è necessario usare il piano dedicato per consentire la modifica del codice nell'editor del servizio app.

Creare una funzione trigger timer

Creare una risorsa di Funzioni di Azure.
- Se si dispone già di una risorsa di Application Insights:
  
  Per impostazione predefinita, Funzioni di Azure crea una risorsa di Application Insights. Se si vuole usare una risorsa creata in precedenza, è necessario specificare che durante la creazione.
  
  Seguire le istruzioni su come creare una risorsa di Funzioni di Azure con la modifica seguente:
  
  Nella scheda Monitoraggio, selezionare la casella di riepilogo a discesa Application Insights e quindi immettere o selezionare il nome della risorsa:
- Se non è ancora stata creata una risorsa di Application Insights per la funzione attivata dal timer:
  
  Per impostazione predefinita, quando si crea l'applicazione Funzioni di Azure, viene creata automaticamente una risorsa di Application Insights. Seguire le istruzioni su come creare una risorsa di Funzioni di Azure.
Nota

È possibile ospitare le funzioni in un piano di servizio app, Premium o a consumo. Se si esegue il test dietro una rete virtuale o si testano endpoint non pubblici, è necessario usare il piano Premium al posto del piano a consumo. Selezionare il piano nella scheda Hosting. Assicurarsi che la versione più recente di .NET sia selezionata quando si crea l'app per le funzioni.
Creare una funzione trigger timer.
1. Nell'app per le funzioni selezionare la scheda Funzioni.
2. Selezionare Aggiungi. Nel riquadro Aggiungi funzione selezionare le configurazioni seguenti:
  - Ambiente di sviluppo: Sviluppare nel portale
  - Selezionare un modello: Trigger timer
3. Selezionare Aggiungi per creare la funzione trigger timer.

Aggiungere e modificare il codice nell'editor del servizio app

Passare all'app per le funzioni distribuita e in Strumenti di sviluppo, selezionare la scheda Editor del servizio app.

Per creare un nuovo file, fare clic con il pulsante destro del mouse sotto la funzione trigger timer (ad esempio TimerTrigger1) e selezionare Nuovo file. Immettere quindi il nome del file e selezionare INVIO.

Creare un nuovo file denominato function.proj e incollare il codice seguente:

<Project Sdk="Microsoft.NET.Sdk"> 
    <PropertyGroup> 
        <TargetFramework>netstandard2.0</TargetFramework> 
    </PropertyGroup> 
    <ItemGroup> 
        <PackageReference Include="Microsoft.ApplicationInsights" Version="2.15.0" /> <!-- Ensure you’re using the latest version --> 
    </ItemGroup> 
</Project>

Creare un nuovo file denominato runAvailabilityTest.csx e incollare il codice seguente:

using System.Net.Http; 

public async static Task RunAvailabilityTestAsync(ILogger log) 
{ 
    using (var httpClient = new HttpClient()) 
    { 
        // TODO: Replace with your business logic 
        await httpClient.GetStringAsync("https://www.bing.com/"); 
    } 
}

Definire la variabile di ambiente REGION_NAME come posizione di disponibilità di Azure valida.

Eseguire il comando seguente nell'interfaccia della riga di comando di Azure per elencare le aree disponibili.
```
az account list-locations -o table
```

Copiare il codice seguente nel file run.csx. Sostituire il codice preesistente.

#load "runAvailabilityTest.csx" 

using System; 

using System.Diagnostics; 

using Microsoft.ApplicationInsights; 

using Microsoft.ApplicationInsights.Channel; 

using Microsoft.ApplicationInsights.DataContracts; 

using Microsoft.ApplicationInsights.Extensibility; 

private static TelemetryClient telemetryClient; 

// ============================================================= 

// ****************** DO NOT MODIFY THIS FILE ****************** 

// Business logic must be implemented in RunAvailabilityTestAsync function in runAvailabilityTest.csx 

// If this file does not exist, please add it first 

// ============================================================= 

public async static Task Run(TimerInfo myTimer, ILogger log, ExecutionContext executionContext) 

{ 
    if (telemetryClient == null) 
    { 
        // Initializing a telemetry configuration for Application Insights based on connection string 

        var telemetryConfiguration = new TelemetryConfiguration(); 
        telemetryConfiguration.ConnectionString = Environment.GetEnvironmentVariable("APPLICATIONINSIGHTS_CONNECTION_STRING"); 
        telemetryConfiguration.TelemetryChannel = new InMemoryChannel(); 
        telemetryClient = new TelemetryClient(telemetryConfiguration); 
    } 

    string testName = executionContext.FunctionName; 
    string location = Environment.GetEnvironmentVariable("REGION_NAME"); 
    var availability = new AvailabilityTelemetry 
    { 
        Name = testName, 

        RunLocation = location, 

        Success = false, 
    }; 

    availability.Context.Operation.ParentId = Activity.Current.SpanId.ToString(); 
    availability.Context.Operation.Id = Activity.Current.RootId; 
    var stopwatch = new Stopwatch(); 
    stopwatch.Start(); 

    try 
    { 
        using (var activity = new Activity("AvailabilityContext")) 
        { 
            activity.Start(); 
            availability.Id = Activity.Current.SpanId.ToString(); 
            // Run business logic 
            await RunAvailabilityTestAsync(log); 
        } 
        availability.Success = true; 
    } 

    catch (Exception ex) 
    { 
        availability.Message = ex.Message; 
        throw; 
    } 

    finally 
    { 
        stopwatch.Stop(); 
        availability.Duration = stopwatch.Elapsed; 
        availability.Timestamp = DateTimeOffset.UtcNow; 
        telemetryClient.TrackAvailability(availability); 
        telemetryClient.Flush(); 
    } 
}

Codice di esempio di test Web in più passi

Seguire le stesse istruzioni precedenti e invece incollare il codice seguente nel file runAvailabilityTest.csx:

using System.Net.Http; 

public async static Task RunAvailabilityTestAsync(ILogger log) 
{ 
    using (var httpClient = new HttpClient()) 
    { 
        // TODO: Replace with your business logic 
        await httpClient.GetStringAsync("https://www.bing.com/"); 

        // TODO: Replace with your business logic for an additional monitored endpoint, and logic for additional steps as needed
        await httpClient.GetStringAsync("https://www.learn.microsoft.com/"); 
    } 
}

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:
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 nella scheda Disponibilità della risorsa di Application Insights.

Test Standard
TrackAvailability

Screenshot che mostra la pagina Disponibilità con il pulsante Aggiorna evidenziato.

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.

Screenshot che mostra la vista Linea.

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

Screenshot che mostra i dettagli del test di visualizzazione. Modificare e disabilitare un test Web.

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.

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

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.

Screenshot che mostra la diagnostica lato server.

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à.
1. 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.
2. 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.
1. Nella risorsa del gruppo di sicurezza di rete, in Impostazioni selezionare regole di sicurezza in ingresso. Selezionare Aggiungi.
2. 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 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 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.

Screenshot che mostra la selezione del pulsante Modifica per modificare la visualizzazione in un grafico a torta.

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

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.

Condividi tramite

Test di disponibilità di Application Insights

Tipi di test di disponibilità

Crea test di disponibilità

Prerequisiti

Operazioni preliminari

Criteri di successo

Avvisi di disponibilità

Tag di popolamento della posizione

Azure

Azure Government

Microsoft Azure gestito da 21Vianet

Attivare gli avvisi

Criteri di avviso

Cambiare i criteri di avviso

Creare una regola di avviso personalizzata

Automatizzare gli avvisi

Visualizzare i risultati dei test di disponibilità

Verifica disponibilità

Esaminare e modificare i test

In caso di errori

Query in Log Analytics

Migrare test di disponibilità

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

Prerequisiti

Operazioni preliminari

Test dietro un firewall

Abilitazione del test di disponibilità pubblica

Autenticare il traffico

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

Scenari di ingresso disconnessi o non presenti

Configurazioni TLS supportate

TLS 1.2

TLS 1.3

Deprecazione della configurazione TLS

TLS 1.0 e TLS 1.1

TLS 1.2

TLS 1.3

Risoluzione dei problemi

Cartella di lavoro Tempi di inattività, contratto di servizio e interruzioni

Flessibilità dei parametri

Pagina di panoramica

Tempi di inattività, interruzioni ed errori

Modificare il report

Log Analytics

Accesso e condivisione

Domande frequenti

Generali

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

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

Supporto TLS

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

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

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

Dopo il 31 ottobre 2024, quale sarà il comportamento del test Web per i test interessati?

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

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

Dove è possibile ottenere il supporto TLS?

Passaggi successivi

Commenti e suggerimenti

Commenti e suggerimenti

Risorse aggiuntive