Testy dostupnosti Application Insights

Článek
07/16/2024

Po nasazení webové aplikace nebo webu můžete nastavit opakované testy pro monitorování dostupnosti a odezvy. Application Insights odesílá webové požadavky do vaší aplikace v pravidelných intervalech z bodů po celém světě. Může vás upozornit, pokud vaše aplikace nereaguje nebo reaguje příliš pomalu. Na prostředek Application Insights můžete vytvořit až 100 testů dostupnosti.

Testy dostupnosti nevyžadují žádné změny webu, který testujete, a pracují na jakémkoli koncovém bodu HTTP nebo HTTPS, který je přístupný z veřejného internetu. Můžete také otestovat dostupnost rozhraní REST API, na které vaše služba závisí.

Poznámka:

Testy dostupnosti se ukládají šifrovaně podle zásad neaktivních uložených dat v Azure.

Typy testů dostupnosti

Existují čtyři typy testů dostupnosti:

Standardní test: Jedná se o typ testu dostupnosti, který kontroluje dostupnost webu odesláním jednoho požadavku, podobně jako u zastaralého testu ping adresy URL. Kromě ověřování, jestli koncový bod reaguje a měří výkon, zahrnují standardní testy také platnost certifikátu TLS/SSL, proaktivní kontrolu životnosti, příkaz požadavku HTTP (například GET,HEADa POST), vlastní hlavičky a vlastní data přidružená k vašemu požadavku HTTP.
Vlastní test TrackAvailability: Pokud se rozhodnete vytvořit vlastní aplikaci pro spouštění testů dostupnosti, můžete k odeslání výsledků do Application Insights použít metodu TrackAvailability().
(Zastaralé) Vícekrokový webový test: Tuto nahrávku posloupnosti webových požadavků můžete přehrát a otestovat složitější scénáře. Vícekrokové webové testy se vytvářejí v sadě Visual Studio Enterprise a nahrají se na portál, kde je můžete spustit.
(Zastaralé) Test ping adresy URL: Tento test můžete vytvořit prostřednictvím webu Azure Portal a ověřit, jestli koncový bod reaguje a měří výkon přidružený k této odpovědi. Můžete také nastavit vlastní kritéria úspěchu v kombinaci s pokročilejšími funkcemi, jako je analýza závislých požadavků a povolení opakování.

Důležité

Existují dva nadcházející vyřazení testů dostupnosti:

Vícekrokové webové testy: 31. srpna 2024 budou vícekrokové webové testy v Application Insights vyřazeny. Doporučujeme uživatelům těchto testů přejít na alternativní testy dostupnosti před datem vyřazení. Po tomto datu převezmeme základní infrastrukturu, která rozdělí zbývající testy s více kroky.
Testy ping adresy URL: 30. září 2026 budou testy ping adresy URL v Application Insights vyřazeny. Existující testy ping adresy URL budou z vašich prostředků odebrány. Projděte si ceny standardních testů a přechod na jejich používání před 30. zářím 2026, abyste měli jistotu, že budete moct v prostředcích Application Insights dál spouštět testy dostupnosti s jedním krokem.

Tip

Pokud aktuálně používáte jiné testy dostupnosti, jako jsou testy ping adresy URL, můžete přidat standardní testy společně s ostatními testy. Pokud chcete použít standardní testy místo jednoho z ostatních testů, přidejte standardní test a odstraňte starý test.

Požadavky

Prostředek Application Insights v pracovním prostoru

Začínáme

Přejděte do prostředku Application Insights a vyberte podokno Dostupnost .
Vyberte Přidat standardní test.

Zadejte název testu, adresu URL a další nastavení popsaná v následující tabulce. Potom vyberte Vytvořit.

Nastavení	Popis
Adresa URL	Adresa URL může být libovolná webová stránka, kterou chcete otestovat, ale musí být viditelná z veřejného internetu. Adresa URL může obsahovat řetězec dotazu. To znamená, že můžete také trochu vyzkoušet svou databázi. Pokud se adresa URL přeloží na přesměrování, budeme ji sledovat až po 10 přesměrování.
Analýza závislých požadavků	Testuje obrázky, skripty, soubory stylů a další soubory, které jsou součástí webové stránky v rámci testu. Zaznamenaná doba odezvy zahrnuje i čas potřebný k získání těchto souborů. Test selže, pokud některé z těchto prostředků nejde úspěšně stáhnout během časového limitu pro celý test. Pokud tato možnost není vybraná, test požádá pouze o soubor na zadanou adresu URL. Povolení této možnosti způsobí přísnější kontrolu. Test může selhat pro případy, které nemusí být patrné při ručním procházení webu. Upozorňujeme, že analyzujeme pouze 15 závislých požadavků.
Povolení opakování	Když test selže, bude se opakovat po krátkém intervalu. Selhání je nahlášeno pouze v případě tří po sobě jdoucích neúspěšných pokusů. Následné testy jsou pak provedeny s obvyklou frekvencí testu. Opakování je dočasně pozastaveno do dalšího úspěchu. Toto pravidlo platí nezávisle na každém umístění testu. Tuto možnost doporučujeme. V průměru přibližně 80 % selhání při opakování zmizí.
Test ověření certifikátu SSL	Certifikát SSL na webu můžete ověřit, abyste měli jistotu, že je správně nainstalovaný, platný, důvěryhodný a neuděluje žádné chyby žádnému z vašich uživatelů.
Proaktivní kontrola životnosti	Toto nastavení umožňuje definovat nastavené časové období před vypršením platnosti certifikátu SSL. Po vypršení platnosti testu selže.
Frekvence testování	Nastaví, jak často se test spouští z každého testovacího umístění. S výchozí pětiminutovou frekvencí a pěti testovanými místy bude váš web testován v průměru každou minutu.
Testovací umístění	Naše servery odesílají webové požadavky na vaši adresu URL z těchto umístění. Minimální počet doporučených testovacích umístění je pět , abyste měli jistotu, že můžete rozlišit problémy na vašem webu od problémů se sítí. Můžete vybrat až 16 umístění.
Vlastní záhlaví	Páry klíčových hodnot, které definují provozní parametry.
Příkaz požadavku HTTP	Uveďte, jakou akci chcete u své žádosti provést.
Text požadavku	Vlastní data přidružená k vašemu požadavku HTTP Můžete nahrát vlastní soubory, zadat obsah nebo tuto funkci zakázat.

Kritéria úspěchu

Nastavení	Popis
Časový limit testu	Snižte tuto hodnotu, aby se zobrazila upozornění na pomalé odpovědi. Test se počítá jako selhání, pokud odpovědi z webu nebyly přijaty během tohoto období. Pokud jste vybrali možnost Analyzovat závislé požadavky, musí být v tomto období přijaty všechny obrázky, soubory stylů, skripty a další závislé prostředky.
Odpověď HTTP	Vrácený stavový kód, který se počítá jako úspěch. Číslo 200 je kód, který označuje, že byla vrácena normální webová stránka.
Shoda obsahu	Řetězec, například "Vítejte!" Testujeme, že se v každé odpovědi vyskytuje přesná shoda s rozlišováním velkých a malých písmen. Musí být prostý řetězec bez zástupných znaků. Nezapomeňte, že pokud se obsah stránky změní, budete ho muset aktualizovat. Shoda obsahu podporuje pouze anglické znaky.

Důležité

TrackAvailability() vyžaduje, aby vývojář investoval do psaní a maintaninu potenciálně složitého vlastního kódu.

Standardní testy by se měly vždy používat, pokud je to možné, protože vyžadují malou investici, bez údržby a mají několik požadavků.

Požadavky

Prostředek Application Insights v pracovním prostoru
Přístup ke zdrojovému kódu aplikace funkcí ve službě Azure Functions
Znalosti vývojářů schopné vytvářet vlastní kód pro TrackAvailability() přizpůsobené vašim konkrétním obchodním potřebám

Ukázka základního kódu

Poznámka:

Tento příklad je navržený výhradně tak, aby vám ukázal mechanismus TrackAvailability() fungování volání rozhraní API v rámci funkce Azure. Nezobrazuje vám, jak napsat základní testovací kód HTTP nebo obchodní logiku, která je nutná k tomu, aby se tento příklad přeměnil na plně funkční test dostupnosti.

Pokud si tento příklad projdete, vytvoříte ve výchozím nastavení test HTTP GET základní dostupnosti. Pokud chcete postupovat podle těchto pokynů, musíte použít vyhrazený plán , abyste povolili úpravy kódu v Editoru služby App Service.

Vytvoření funkce triggeru časovače

Vytvořte prostředek Azure Functions.
- Pokud už máte prostředek Application Insights:
  
  Azure Functions ve výchozím nastavení vytvoří prostředek Application Insights. Pokud chcete použít dříve vytvořený prostředek, musíte ho zadat během vytváření.
  
  Postupujte podle pokynů k vytvoření prostředku Azure Functions s následující úpravou:
  
  Na kartě Monitorování vyberte rozevírací seznam Application Insights a pak zadejte nebo vyberte název prostředku:
- Pokud ještě nemáte vytvořený prostředek Application Insights pro funkci aktivovanou časovačem:
  
  Při vytváření aplikace Azure Functions se ve výchozím nastavení vytvoří prostředek Application Insights za vás. Postupujte podle pokynů k vytvoření prostředku Azure Functions.
Poznámka:

Funkce můžete hostovat v plánu Consumption, Premium nebo App Service. Pokud testujete virtuální síť nebo testujete nepublikované koncové body, budete muset místo plánu Consumption použít plán Premium. Vyberte plán na kartě Hostování . Při vytváření aplikace funkcí se ujistěte, že je vybraná nejnovější verze .NET.
Vytvoření funkce triggeru časovače
1. V aplikaci funkcí vyberte kartu Funkce .
2. Vyberte Přidat. V podokně Přidat funkci vyberte následující konfigurace:
  - Vývojové prostředí: Vývoj na portálu
  - Výběr šablony: Trigger časovače
3. Výběrem možnosti Přidat vytvořte funkci triggeru časovače.

Přidání a úprava kódu v Editoru služby App Service

Přejděte do nasazené aplikace funkcí a v části Vývojové nástroje vyberte kartu Editor služby App Service.

Pokud chcete vytvořit nový soubor, klikněte pravým tlačítkem na funkci triggeru časovače (například TimerTrigger1) a vyberte Nový soubor. Pak zadejte název souboru a vyberte Enter.

Vytvořte nový soubor s názvem function.proj a vložte následující kód:

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

Vytvořte nový soubor s názvem runAvailabilityTest.csx a vložte následující kód:

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/"); 
    } 
}

Definujte proměnnou REGION_NAME prostředí jako platné umístění dostupnosti Azure.

Spuštěním následujícího příkazu v Azure CLI zobrazte seznam dostupných oblastí.
```
az account list-locations -o table
```

Do souboru run.csx zkopírujte následující kód. (Nahradíte existující kód.)

#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(); 
    } 
}

Ukázka vícekrokového webového testu kódu

Postupujte podle stejných pokynů výše a místo toho vložte následující kód do souboru 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/"); 
    } 
}

Upozornění na dostupnost

Nastavení	Popis
Téměř v reálném čase	Doporučujeme používat upozornění téměř v reálném čase. Konfigurace tohoto typu výstrahy se provede po vytvoření testu dostupnosti.
Prahová hodnota umístění upozornění	Doporučujeme minimálně 3/5 umístění. Optimální vztah mezi prahovou hodnotou umístění výstrahy a počtem testovacích umístění je prahová hodnota = umístění výstrahy – 2 s minimálně pěti testovacími umístěními.

Značky umístění

Pokud nasadíte test ping adresy URL dostupnosti pomocí Azure Resource Manageru, můžete pro atribut geografického umístění použít následující značky základního souboru.

Azure

Zobrazované jméno	Název populace
Austrálie – východ	emea-au-syd-edge
Brazílie – jih	latam-br-gru-edge
USA – střed	us-fl-mia-edge
Východní Asie	apac-hk-hkn-azr
USA – východ	us-va-ash-azr
Francie – jih (dříve Francie – střed)	emea-ch-zrh-edge
Francie – střed	emea-fr-pra-edge
Japonsko – východ	apac-jp-kaw-edge
Severní Evropa	emea-gb-db3-azr
Severní střed USA	us-il-ch1-azr
Středojižní USA	us-tx-sn1-azr
Southeast Asia	apac-sg-sin-azr
Velká Británie – západ	emea-se-sto-edge
Západní Evropa	emea-nl-ams-azr
USA – západ	us-ca-sjc-azr
Velká Británie – jih	emea-ru-msa-edge

Azure Government

Zobrazované jméno	Název populace
USGov Virginia	usgov-va-azr
USGov – Arizona	usgov-phx-azr
USGov Texas	usgov-tx-azr
USDoD – východ	usgov-ddeast-azr
USDoD – střed	usgov-ddcentral-azr

Platforma Microsoft Azure provozovaná společností 21Vianet

Zobrazované jméno	Název populace
Čína – východ	mc-cne-azr
Čína – východ 2	mc-cne2-azr
Čína – sever	mc-cnn-azr
Čína – sever 2	mc-cnn2-azr

Povolení upozornění

Upozornění jsou teď ve výchozím nastavení automaticky povolená, ale pokud chcete plně nakonfigurovat výstrahu, musíte nejprve vytvořit test dostupnosti.

Poznámka:

U nových sjednocených výstrah musí být v prostředí upozornění nakonfigurovaná závažnost pravidla upozornění a předvolby oznámení se skupinami akcí. Bez následujících kroků budete dostávat jenom oznámení na portálu.

Po uložení testu dostupnosti vyberte na kartě Podrobnosti tři tečky provedeným testem. Vyberte stránku Otevřít pravidla (Upozornění).
Nastavte úroveň závažnosti, popis pravidla a skupinu akcí s předvolbou oznámení, kterou chcete pro toto pravidlo upozornění použít.

Kritéria upozornění

Automaticky povolená upozornění na dostupnost aktivují e-mail, když je definovaný koncový bod nedostupný a až bude znovu dostupný. Upozornění dostupnosti vytvořená prostřednictvím tohoto prostředí jsou založená na stavu. Když jsou splněna kritéria upozornění, vygeneruje se jedna výstraha, když se web zjistí jako nedostupný. Pokud je web stále v výpadku při příštím vyhodnocení kritérií upozornění, nevygeneruje se nové upozornění.

Předpokládejme například, že váš web je na hodinu vypnutý a vy jste nastavili e-mailové upozornění s frekvencí vyhodnocení 15 minut. Dostanete jenom e-mail, když web přestane fungovat, a další e-mail, až bude zase online. Nebudete dostávat nepřetržitá upozornění každých 15 minut, abyste si připomněli, že web je stále nedostupný.

Možná nebudete chtít dostávat oznámení, když je váš web po krátkou dobu, například během údržby. Frekvenci vyhodnocení můžete změnit na vyšší hodnotu, než je očekávaný výpadek, až 15 minut. Můžete také zvýšit prahovou hodnotu umístění výstrahy, aby aktivovala výstrahu pouze v případě výpadku webu pro určitý počet oblastí. V případě delších plánovaných výpadků dočasně deaktivujte pravidlo upozornění nebo vytvořte vlastní pravidlo. Nabízí další možnosti pro zohlednění výpadků.

Změna kritérií upozornění

Pokud chcete změnit prahovou hodnotu umístění, agregační období a frekvenci testů, vyberte podmínku na stránce pro úpravy pravidla upozornění a otevřete okno Konfigurovat logiku signálu.

Vytvoření vlastního pravidla upozornění

Pokud potřebujete pokročilé možnosti, můžete na kartě Upozornění vytvořit vlastní pravidlo upozornění. Vyberte Vytvořit>pravidlo upozornění. Zvolte Metriky pro typ signálu, aby se zobrazily všechny dostupné signály, a vyberte Dostupnost.

Vlastní pravidlo upozornění nabízí vyšší hodnoty pro agregační období (až 24 hodin místo 6 hodin) a frekvenci testování (až 1 hodinu místo 15 minut). Přidává také možnosti pro další definování logiky výběrem různých operátorů, typů agregace a prahových hodnot.

Výstraha na X z umístění Y, která hlásí selhání: Pravidlo upozornění X z umístění Y je ve výchozím nastavení povolené v novém sjednoceném prostředí upozornění při vytváření nového testu dostupnosti. Můžete se odhlásit tak, že vyberete možnost Classic nebo zvolíte zakázání pravidla upozornění. Nakonfigurujte skupiny akcí tak, aby dostávaly oznámení, když se výstraha aktivuje podle předchozích kroků. Bez tohoto kroku budete dostávat oznámení jenom na portálu, když se pravidlo aktivuje.
Upozornění na metriky dostupnosti: Pomocí nových jednotných upozornění můžete také upozorňovat na segmentované agregované metriky dostupnosti a doby trvání testu:
1. V prostředí metrik vyberte prostředek Application Insights a vyberte metriku dostupnosti.
2. Možnost Konfigurovat výstrahy z nabídky vás přenese do nového prostředí, kde můžete vybrat konkrétní testy nebo umístění, na kterých chcete nastavit pravidla upozornění. Tady můžete také nakonfigurovat skupiny akcí pro toto pravidlo upozornění.
Upozornění na dotazy vlastní analýzy: Pomocí nových jednotných upozornění můžete upozorňovat na vlastní dotazy na protokoly. Pomocí vlastních dotazů můžete upozorňovat na libovolnou podmínku, která vám pomůže získat nejspolehlivější signál o problémech s dostupností. Platí také v případě, že odesíláte vlastní výsledky dostupnosti pomocí sady TrackAvailability SDK.

Metriky dat o dostupnosti zahrnují všechny vlastní výsledky dostupnosti, které můžete odeslat voláním sady TrackAvailability SDK. Pomocí upozorňování na podporu metrik můžete upozorňovat na výsledky vlastní dostupnosti.

Automatizace výstrah

Pokud chcete tento proces automatizovat pomocí šablon Azure Resource Manageru, přečtěte si téma Vytvoření upozornění na metriku pomocí šablony Azure Resource Manageru.

Zobrazení výsledků testu dostupnosti

Tato část vysvětluje, jak zkontrolovat výsledky testů dostupnosti na webu Azure Portal a dotazovat se na data pomocí Log Analytics. Výsledky testu dostupnosti je možné vizualizovat pomocí zobrazení spojnicového i bodového grafu .

Zkontrolovat dostupnost

Začněte tím, že si prohlédněte graf na kartě Dostupnost vašeho prostředku Application Insights.

Standardní test
Sledování dostupnosti

Snímek obrazovky se stránkou Dostupnost se zvýrazněným tlačítkem Aktualizovat

Zobrazení bodového grafu zobrazuje vzorky výsledků testu, které mají v nich podrobnosti o diagnostickém testu. V případě testů obsahujících selhání ukládá testovací modul diagnostické informace. U úspěšných testů se diagnostické informace ukládají pro celou dílčí sadu provedení. Najeďte myší na některou ze zelených nebo červených teček, abyste viděli test, název testu a umístění.

Snímek obrazovky znázorňující zobrazení Čára

Vyberte konkrétní test nebo umístění. Nebo můžete zkrátit časové období, abyste viděli více výsledků v průběhu časového období zájmu. Pomocí Průzkumníka služby Search můžete zobrazit výsledky ze všech spuštění. Nebo můžete pomocí dotazů Log Analytics spouštět vlastní sestavy s daty.

Pokud chcete zobrazit podrobnosti o komplexní transakci, vyberte v části Přejít k podrobnostem možnost Úspěšné nebo Neúspěšné. Pak vyberte ukázku. Můžete se také dostat k podrobnostem o komplexní transakci výběrem datového bodu v grafu.

Snímek obrazovky znázorňující výběr ukázkového testu dostupnosti

Kontrola a úprava testů

Pokud chcete test upravit, dočasně zakázat nebo odstranit, vyberte tři tečky vedle názvu testu. Po provedení změny může trvat až 20 minut, než se změny konfigurace rozšíří do všech testovacích agentů.

Snímek obrazovky znázorňující podrobnosti o testu Úprava a zakázání webového testu

Během údržby služby můžete chtít zakázat testy dostupnosti nebo pravidla upozornění, která jsou k nim přidružená.

Pokud se zobrazí chyby

Vyberte červenou tečku.

Snímek obrazovky znázorňující kartu Podrobnosti o celé transakci

Z výsledku testu dostupnosti můžete zobrazit podrobnosti transakce napříč všemi komponentami. Tady můžete:

Projděte si sestavu řešení potíží a zjistěte, co mohlo způsobit selhání testu, ale vaše aplikace je stále dostupná.
Kontrolovat odpověď přijatou ze serveru.
Diagnostikujte selhání s korelací telemetrie na straně serveru shromážděnou při zpracování neúspěšného testu dostupnosti.
Zapište problém nebo pracovní položku v Gitu nebo Azure Boards a sledujte problém. Chyba bude obsahovat odkaz na tuto událost.
Otevřít výsledek webového testu v sadě Visual Studio.

Další informace o prostředí komplexní diagnostiky transakcí najdete v dokumentaci k diagnostice transakcí.

Výběrem řádku výjimky zobrazíte podrobnosti o výjimce na straně serveru, která způsobila selhání testu syntetické dostupnosti. Můžete také získat snímek ladění pro bohatší diagnostiku na úrovni kódu.

Snímek obrazovky znázorňující diagnostiku na straně serveru

Kromě nezpracovaných výsledků můžete v Průzkumníku metrik zobrazit také dvě klíčové metriky dostupnosti:

Dostupnost: Procento úspěšných testů ve všech spuštěních testů.
Doba trvání testu: Průměrná doba trvání testu ve všech spuštěních testů.

Dotazování v Log Analytics

Log Analytics můžete použít k zobrazení výsledků dostupnosti, závislostí a dalších možností. Další informace o Log Analytics najdete v přehledu dotazů protokolu.

Migrace testů dostupnosti

V tomto článku vás provedeme procesem migrace z klasických testů ping adresy URL na moderní a efektivní standardní testy.

Zjednodušíme tento proces tím, že poskytneme jasné podrobné pokyny, abychom zajistili bezproblémový přechod a vybavili vaše aplikace nejaktuálnějšími možnostmi monitorování.

Migrace klasických testů ping adresy URL na standardní testy

Následující kroky vás provedou procesem vytváření standardních testů, které replikují funkce testů ping adresy URL. Umožňuje snadněji začít používat pokročilé funkce standardních testů pomocí dříve vytvořených testů url ping.

Důležité

Náklady jsou spojené se spouštěním standardních testů. Po vytvoření standardního testu se vám budou účtovat poplatky za provádění testů. Před zahájením tohoto procesu si projděte ceny služby Azure Monitor.

Požadavky

Test příkazu PING adresy URL v Application Insights
Přístup k Azure PowerShellu

Začínáme

Připojte se k předplatnému pomocí Azure PowerShellu (Connect-AzAccount + Set-AzContext).

Vypište všechny testy ping adresy URL v aktuálním předplatném:

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

Vyhledejte test ping adresy URL, který chcete migrovat, a poznamenejte si její skupinu prostředků a název.

Následující příkazy vytvoří standardní test se stejnou logikou jako test ping adresy URL.

Poznámka:

Následující příkazy fungují pro koncové body HTTP i HTTPS, které se používají v testech ping adresy 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);

Nový standardní test ve výchozím nastavení neobsahuje pravidla upozornění, takže nevytvoří hlučná upozornění. V testu ping adresy URL se neprovedou žádné změny, takže se na něj můžete nadále spoléhat na výstrahy.
Jakmile ověříte funkčnost nového standardního testu, aktualizujte pravidla upozornění, která odkazují na test ping adresy URL, aby odkazovaly na standardní test. Pak test ping adresy URL zakážete nebo odstraníte.
Pokud chcete pomocí Azure PowerShellu odstranit test ping adresy URL, můžete použít tento příkaz:
```
Remove-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
```

Testování za bránou firewall

Pokud chcete zajistit dostupnost koncového bodu za branami firewall, povolte testy veřejné dostupnosti nebo testy dostupnosti spouštět v odpojených nebo žádných scénářích příchozího přenosu dat.

Povolení testu veřejné dostupnosti

Ujistěte se, že váš interní web obsahuje veřejný záznam DNS (Domain Name System). Testy dostupnosti selžou, pokud DNS nejde přeložit. Další informace najdete v tématu Vytvoření vlastního názvu domény pro interní aplikaci.

Upozorňující

IP adresy používané službou testů dostupnosti jsou sdílené a můžou vystavit koncové body služby chráněné bránou firewall jiným testům. Filtrování IP adres samo o sobě nezabezpečuje provoz vaší služby, proto doporučujeme přidat další vlastní hlavičky pro ověření původu webové žádosti. Další informace najdete v tématu Značky služeb virtuální sítě.

Ověření provozu

Nastavte vlastní hlavičky ve standardních testech dostupnosti pro ověření provozu.

Vygenerujte token nebo identifikátor GUID pro identifikaci provozu z testů dostupnosti.
Při vytváření nebo aktualizaci testů dostupnosti přidejte vlastní hlavičku X-Customer-InstanceId s hodnotou ApplicationInsightsAvailability:<GUID generated in step 1> v části Standardní testovací informace.
Ujistěte se, že vaše služba kontroluje, jestli příchozí provoz obsahuje hlavičku a hodnotu definovanou v předchozích krocích.

Případně můžete token nastavit jako parametr dotazu. Například https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your guid>.

Konfigurace brány firewall pro povolení příchozích požadavků z testů dostupnosti

Poznámka:

Tento příklad je specifický pro použití značky služby skupiny zabezpečení sítě. Mnoho služeb Azure přijímá značky služeb, z nichž každá vyžaduje různé kroky konfigurace.

Pokud chcete zjednodušit povolování služeb Azure bez autorizace jednotlivých IP adres nebo udržování aktuálního seznamu IP adres, použijte značky služeb. Použijte tyto značky napříč službou Azure Firewall a skupinami zabezpečení sítě a povolte tak testovací službě dostupnosti přístup k vašim koncovým bodům. Značka ApplicationInsightsAvailability služby se vztahuje na všechny testy dostupnosti.
1. Pokud používáte skupiny zabezpečení sítě Azure, přejděte na prostředek skupiny zabezpečení sítě a v části Nastavení vyberte příchozí pravidla zabezpečení. Pak vyberte Přidat.
2. Dále jako zdroj vyberte značku služby a jako značku zdrojové služby vyberte ApplicationInsightsAvailability . Pro příchozí provoz ze značky služby použijte otevřené porty 80 (http) a 443 (https).
Pokud chcete spravovat přístup, když jsou vaše koncové body mimo Azure nebo když značky služeb nejsou možnost, povolte IP adresy našich agentů webového testu. Rozsahy IP adres můžete dotazovat pomocí PowerShellu, Azure CLI nebo volání REST pomocí rozhraní API značek služeb. Úplný seznam aktuálních značek služeb a jejich ip adres si stáhněte soubor JSON.
1. V prostředku skupiny zabezpečení sítě v části Nastavení vyberte příchozí pravidla zabezpečení. Pak vyberte Přidat.
2. Dále jako zdroj vyberte IP adresy . Pak přidejte své IP adresy do seznamu oddělených čárkami ve zdrojových IP adresách nebo rozsahech CIRD.

Odpojené nebo žádné scénáře příchozího přenosu dat

Připojte prostředek Application Insights k internímu koncovému bodu služby pomocí služby Azure Private Link.
Napište vlastní kód, který bude pravidelně testovat interní server nebo koncové body. Výsledky odešlete do Application Insights pomocí rozhraní API TrackAvailability() v balíčku základní sady SDK.

Podporované konfigurace protokolu TLS

K zajištění nejlepšího šifrování ve třídě používají všechny testy dostupnosti protokol TLS (Transport Layer Security) 1.2 a 1.3 jako zvolené mechanismy šifrování. Kromě toho jsou v každé verzi podporovány také následující šifrovací sady a eliptické křivky.

Poznámka:

Protokol TLS 1.3 je aktuálně dostupný pouze v oblastech testování dostupnosti NorthCentralUS, CentralUS, EastUS, SouthCentralUS a WestUS.

TLS 1.2

Šifrovací sady

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

Eliptické křivky

NistP384
NistP256

TLS 1.3

Šifrovací sady

TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256

Eliptické křivky:

NistP384
NistP256

Vyřazení konfigurace protokolu TLS

Upozorňující

Dne 31. října 2024 budou starší verze protokolu TLS a starší verze protokolu TLS protokolu TLS 1.0/1.1 a níže uvedené starší šifrovací sady TLS 1.2/1.3 a eliptické křivky vyřazeny pro testy dostupnosti Application Insights.

TLS 1.0 a TLS 1.1

Verze protokolu již nebudou podporovány.

TLS 1.2

Šifrovací sady

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

Eliptické křivky:

křivka25519

TLS 1.3

Eliptické křivky

křivka25519

Řešení problému

Upozorňující

V testech dostupnosti jsme nedávno povolili protokol TLS 1.3. Pokud se v důsledku toho zobrazují nové chybové zprávy, ujistěte se, že se klienti s povoleným protokolem TLS 1.3 s povoleným protokolem TLS 1.3 můžou připojit ke svému koncovému bodu. Pokud to nemůžete udělat, můžete zvážit dočasné zakázání protokolu TLS 1.3 ve vašem koncovém bodu, aby se testy dostupnosti vrátily ke starším verzím PROTOKOLU TLS.
Další informace najdete v článku o řešení potíží. Projděte si vyhrazený článek o řešení potíží.

Sešit výpadků a SLA

Tento článek představuje jednoduchý způsob, jak vypočítat a hlásit smlouvu o úrovni služeb (SLA) pro webové testy prostřednictvím jediného podokna skla napříč prostředky Application Insights a předplatnými Azure. Sestava výpadků nabízí výkonné předpřipravené dotazy a vizualizace dat, které vám pomůžou lépe porozumět možnostem připojení zákazníka, obvyklé době odezvy aplikací a zaznamenaným výpadkům.

K šabloně sešitu SLA můžete přistupovat z prostředku Application Insights dvěma způsoby:

Otevřete podokno Dostupnost a v horní části obrazovky vyberte sestavu SLA.
Otevřete podokno Sešity a pak vyberte Výpadek a výpadky.

Flexibilita parametrů

Parametry nastavené v sešitu ovlivňují zbytek sestavy.

Subscriptions, App Insights Resourcesa Web Test: Tyto parametry určují možnosti prostředků vysoké úrovně. Jsou založené na dotazech Log Analytics a používají se v každém dotazu sestavy.
Failure Threshold a Outage Window: Tyto parametry můžete použít k určení vlastních kritérií pro výpadek služby. Příkladem jsou kritéria pro upozornění dostupnosti Application Insights na základě čítače umístění, u které došlo k selhání během vybraného období. Typická prahová hodnota je tři místa v pětiminutovém intervalu.
Maintenance Period: Tento parametr můžete použít k výběru typické frekvence údržby. Maintenance Window je selektor data a času pro příklad období údržby. Všechna data, která se vyskytují během identifikovaného období, budou ve výsledcích ignorována.
Availability Target %: Tento parametr určuje cíl a přebírá vlastní hodnoty.

Stránka přehledu

Stránka s přehledem obsahuje základní informace o vašich:

Celková smlouva SLA (s výjimkou období údržby, pokud je definovaná)
Kompletní výpadky instancí
Výpadek aplikace

Instance výpadku jsou definovány, když se test spustí neúspěšně, dokud nebude úspěšný na základě parametrů výpadku. Pokud test začne selhává v 8:00 a úspěšně proběhne znovu v 10:00, považuje se za stejné výpadky celé období dat.

Můžete také prozkoumat nejdelší výpadek, ke kterému došlo během sledovaného období.

Některé testy se dají propojit zpět s prostředkem Application Insights, aby bylo možné provést další šetření. To je ale možné jenom v prostředku Application Insights založeném na pracovním prostoru.

Výpadky, výpadky a selhání

Karta Výpadky a výpadky obsahuje informace o celkovém výpadku instancí a celkovém výpadku rozděleném podle testu.

Karta Selhání podle umístění obsahuje geografickou mapu neúspěšných testovacích umístění, která pomáhají identifikovat potenciální problémové oblasti připojení.

Úprava sestavy

Sestavu můžete upravit stejně jako jakýkoli jiný sešit azure Monitoru.

Snímek obrazovky znázorňující výběr tlačítka Upravit pro změnu vizualizace na výsečový graf

Dotazy nebo vizualizace můžete přizpůsobit na základě potřeb vašeho týmu.

Log Analytics

Všechny dotazy je možné spouštět v Log Analytics a používat je v jiných sestavách nebo řídicích panelech.

Odeberte omezení parametrů a znovu použijte základní dotaz.

Sestavu můžete sdílet s týmy a vedoucími týmy nebo připnout na řídicí panel pro další použití. Uživatel musí mít oprávnění ke čtení nebo přístup k prostředku Application Insights, kde je uložený skutečný sešit.

Nejčastější dotazy

Tato část obsahuje odpovědi na běžné otázky.

OBECNÉ

Můžu spouštět testy dostupnosti na intranetového serveru?

Naše webové testy běží na místech přítomnosti, které jsou distribuovány po celém světě. Existují dvě řešení:

Brána firewall: Povolte požadavky na váš server z dlouhého a měnitelného seznamu agentů webového testu.
Vlastní kód: Napište vlastní kód pro odesílání pravidelných požadavků na server z intranetu. Pro tento účel můžete spustit webové testy sady Visual Studio. Tester může výsledky odeslat do Application Insights pomocí TrackAvailability() rozhraní API.

Jaký je řetězec uživatelského agenta pro testy dostupnosti?

Řetězec uživatelského agenta je Mozilla/5.0 (kompatibilní; MSIE 9.0; systém Windows NT 6.1; Trident/5.0; AppInsights)

Podpora TLS

Jaký vliv má toto vyřazení na chování webového testu?

Testy dostupnosti fungují jako distribuovaný klient v každém z podporovaných umístění webového testu. Při každém spuštění webového testu se testovací služba dostupnosti pokusí kontaktovat vzdálený koncový bod definovaný v konfiguraci webového testu. Odešle se zpráva Hello klienta TLS, která obsahuje veškerou aktuálně podporovanou konfiguraci protokolu TLS. Pokud vzdálený koncový bod sdílí společnou konfiguraci protokolu TLS s testovacím klientem dostupnosti, bude metoda handshake protokolu TLS úspěšná. V opačném případě webový test selže se selháním metody handshake protokolu TLS.

Návody ujistěte se, že můj webový test nemá vliv?

Aby nedošlo k žádnému dopadu, každý vzdálený koncový bod (včetně závislých požadavků) váš webový test komunikuje s potřebami podporovat alespoň jednu kombinaci stejné verze protokolu, sady šifer a eliptické křivky, kterou test dostupnosti dělá. Pokud vzdálený koncový bod nepodporuje potřebnou konfiguraci protokolu TLS, je potřeba ji aktualizovat o podporu pro určitou kombinaci výše uvedené konfigurace protokolu TLS po vyřazení. Tyto koncové body je možné zjistit zobrazením podrobností o transakcích webového testu (ideálně pro úspěšné spuštění webového testu).

Návody ověřit, jakou konfiguraci protokolu TLS podporuje vzdálený koncový bod?

K dispozici je několik nástrojů k otestování konfigurace protokolu TLS, kterou koncový bod podporuje. Jedním ze způsobů, jak postupovat podle příkladu, který je podrobně popsaný na této stránce. Pokud váš vzdálený koncový bod není dostupný přes veřejný internet, musíte ověřit konfiguraci protokolu TLS podporovanou ve vzdáleném koncovém bodu z počítače, který má přístup k volání koncového bodu.

Poznámka:

Postup povolení potřebné konfigurace protokolu TLS na webovém serveru je nejlepší kontaktovat tým, který vlastní hostující platformu, na které běží váš webový server, pokud proces není známý.

Po 31. říjnu 2024 bude chování webového testu ovlivněné testy?

Neexistuje žádný typ výjimky, kdy by se všechna selhání handshake protokolu TLS ovlivněná tímto vyřazením projevila. Nejběžnější výjimkou, se kterým se webový test začne spouštět, by však byla The request was aborted: Couldn't create SSL/TLS secure channel. V kroku řešení potíží s přenosem protokolu TLS byste také měli vidět případné chyby související s protokolem TLS pro výsledek webového testu, který by mohl mít vliv.

Můžu zobrazit, jakou konfiguraci protokolu TLS aktuálně používá webový test?

Konfiguraci protokolu TLS vyjednanou během provádění webového testu nelze zobrazit. Pokud vzdálený koncový bod podporuje společnou konfiguraci protokolu TLS s testy dostupnosti, neměl by se po vyřazení zobrazit žádný dopad.

Které komponenty mají vyřazení vliv ve službě testování dostupnosti?

Vyřazení protokolu TLS popsané v tomto dokumentu by mělo mít vliv pouze na chování spuštění webového testu testu dostupnosti po 31. říjnu 2024. Další informace o interakci s testovací službou dostupnosti pro operace CRUD najdete v tématu Podpora protokolu TLS Azure Resource Manageru. Tento prostředek poskytuje další podrobnosti o časových osách podpory a vyřazení protokolu TLS.

Kde získám podporu protokolu TLS?

Obecné dotazy týkající se starší verze problému s protokolem TLS najdete v tématu Řešení problémů s protokolem TLS.

Sdílet prostřednictvím

Testy dostupnosti Application Insights

Typy testů dostupnosti

Vytvoření testu dostupnosti

Požadavky

Začínáme

Kritéria úspěchu

Upozornění na dostupnost

Značky umístění

Azure

Azure Government

Platforma Microsoft Azure provozovaná společností 21Vianet

Povolení upozornění

Kritéria upozornění

Změna kritérií upozornění

Vytvoření vlastního pravidla upozornění

Automatizace výstrah

Zobrazení výsledků testu dostupnosti

Zkontrolovat dostupnost

Kontrola a úprava testů

Pokud se zobrazí chyby

Dotazování v Log Analytics

Migrace testů dostupnosti

Migrace klasických testů ping adresy URL na standardní testy

Požadavky

Začínáme

Testování za bránou firewall

Povolení testu veřejné dostupnosti

Ověření provozu

Konfigurace brány firewall pro povolení příchozích požadavků z testů dostupnosti

Odpojené nebo žádné scénáře příchozího přenosu dat

Podporované konfigurace protokolu TLS

TLS 1.2

TLS 1.3

Vyřazení konfigurace protokolu TLS

TLS 1.0 a TLS 1.1

TLS 1.2

TLS 1.3

Řešení problému

Sešit výpadků a SLA

Flexibilita parametrů

Stránka přehledu

Výpadky, výpadky a selhání

Úprava sestavy

Log Analytics

Přístup a sdílení

Nejčastější dotazy

OBECNÉ

Můžu spouštět testy dostupnosti na intranetového serveru?

Jaký je řetězec uživatelského agenta pro testy dostupnosti?

Podpora TLS

Jaký vliv má toto vyřazení na chování webového testu?

Návody ujistěte se, že můj webový test nemá vliv?

Návody ověřit, jakou konfiguraci protokolu TLS podporuje vzdálený koncový bod?

Po 31. říjnu 2024 bude chování webového testu ovlivněné testy?

Můžu zobrazit, jakou konfiguraci protokolu TLS aktuálně používá webový test?

Které komponenty mají vyřazení vliv ve službě testování dostupnosti?

Kde získám podporu protokolu TLS?

Další kroky

Váš názor

Váš názor

Další materiály