Sdílet prostřednictvím


Testy dostupnosti Application Insights

Application Insights umožňuje nastavit opakované webové testy, které monitorují dostupnost webu nebo aplikace a rychlost odezvy z různých bodů po celém světě. Tyto testy dostupnosti odesílají webové požadavky do vaší aplikace v pravidelných intervalech a upozorňují vás, pokud vaše aplikace nereaguje nebo pokud je doba odezvy příliš pomalá.

Testy dostupnosti nevyžadují žádné úpravy webu nebo aplikace, které testujete. Fungují pro jakýkoli koncový bod HTTP nebo HTTPS přístupný z veřejného internetu, včetně rozhraní REST API, na které vaše služba závisí. To znamená, že můžete monitorovat nejen své vlastní aplikace, ale také externí služby, které jsou důležité pro funkčnost vaší aplikace. Na prostředek Application Insights můžete vytvořit až 100 testů dostupnosti.

Poznámka:

Testy dostupnosti se ukládají šifrovaně podle zásad šifrování dat v Azure v klidu.

Typy testů dostupnosti

Existují čtyři typy testů dostupnosti:

  • Standardní test: Typ testu dostupnosti, který kontroluje dostupnost webu odesláním jednoho požadavku, podobně jako test ping zastaralé 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.

    Zjistěte, jak vytvořit standardní test.

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

    Zjistěte, jak vytvořit vlastní test 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 Azure portálu a ověřit, zda koncový bod reaguje a měřit výkon 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é

Doje k ukončení dvou plánovaných testů dostupnosti:

  • Vícekrokové webové testy: Application Insights vyřadí vícekrokové webové testy 31. srpna 2024. Pokud chcete zachovat monitorování dostupnosti, přepněte před tímto datem na alternativní testy dostupnosti. Po ukončení provozu platforma odebere základní infrastrukturu, což způsobí selhání zbývajících vícestupňových testů.
  • Testy ping adresy URL: 30. září 2026 budou testy ping adresy URL v Application Insights vyřazeny. Existující URL ping testy jsou odstraněny z vašich prostředků. 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.

Vytvoření testu dostupnosti

Požadavky

Začínáme

  1. Přejděte na prostředek Application Insights a otevřete prostředí Dostupnost.

  2. V horním navigačním panelu vyberte Přidat standardní test .

    Snímek obrazovky znázorňující uživatelskou zkušenost s dostupností, se záložkou Přidání standardního testu otevřenou.

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

    Sekce Nastavení Popis
    Základní informace
    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 adresa URL vede na přesměrování, budeme ji sledovat až deset přesměrování.
    Analýza závislých požadavků Test načte obrázky, skripty, soubory stylů a další prostředky z webové stránky, které jsou v testu. Zaznamenává dobu odezvy, včetně času načtení těchto souborů. Test selže, pokud během časového limitu nemůže stáhnout všechny prostředky. Pokud tuto možnost nepovolíte, test načte soubor pouze na zadanou adresu URL. Povolení této funkce dělá kontrolu přísnější, což může vést k selhání v situacích, které by při ručním procházení zůstaly nezachyceny. Test analyzuje až 15 závislých požadavků.
    Povolení opakování při selhání testů dostupnosti Když test selže, opakuje se 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 až do dalšího úspěšného pokusu. 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í.
    Povolení platnosti certifikátu SSL Pokud chcete potvrdit správné nastavení, ověřte na svém webu certifikát SSL. Ujistěte se, že je správně nainstalovaný, platný, důvěryhodný a negeneruje chyby pro uživatele. Test dostupnosti ověřuje pouze certifikát SSL na konečné přesměrované adrese URL.
    Proaktivní kontrola životnosti Toto nastavení umožňuje definovat nastavené časové období před vypršením platnosti certifikátu SSL. Po vypršení platnosti selže váš test.
    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í.
    Standardní testovací informace
    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.
    Přidání vlastních hlaviček Páry klíčových hodnot, které definují provozní parametry. Hlavičky Host a User-Agent jsou rezervované v testech dostupnosti a není možné je upravovat ani přepisovat.
    Kritéria úspěchu
    Č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 nejsou přijaty během tohoto období. Pokud jste vybrali Analyzovat závislé požadavky, musí být během tohoto období přijaty všechny obrázky, soubory stylů, skripty a další závislé prostředky.
    Odpověď HTTP Vrácený stavový kód se počítá jako úspěch. Číslo 200 je kód, který označuje, že se vrátí 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. Při porovnávání obsahu jsou podporovány pouze anglické znaky.

Upozornění na dostupnost

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

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 lokalit. 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 populací místa

Pokud nasazujete standardní test nebo test ping adresy URL pomocí Azure Resource Manageru, můžete pro atribut geografického umístění použít následující značky populace.

Poskytovatel Zobrazované jméno Název populace
Azure
Austrálie – východ emea-au-syd-edge
Brazílie – jih latam-br-gru-edge
Střed USA 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
Střed USA – sever us-il-ch1-azr
Střed USA – jih us-tx-sn1-azr
Jihovýchodní Asie 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
USGov Virginie usgov-va-azr
USGov – Arizona usgov-phx-azr
USGov Texas usgov-tx-azr
USDoD – východ usgov-ddeast-azr
Ústředí Ministerstva obrany Spojených států usgov-ddcentral-azr
Microsoft Azure provozovaný společností 21Vianet
Čí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í

Poznámka:

Pokud chcete dostávat výstrahy prostřednictvím nakonfigurovaných skupin akcí, nastavte závažnost pravidla upozornění a předvolby oznámení v jednotném prostředí upozornění. Bez provedení následujících kroků budete dostávat jenom oznámení na portálu.

  1. Po uložení testu dostupnosti otevřete místní nabídku vedle testu, který jste vytvořili, a pak vyberte Otevřít stránku Pravidla (Upozornění).

    Snímek obrazovky znázorňující prostředí dostupnosti prostředku Application Insights na webu Azure Portal a možnost nabídky Otevřít pravidla (upozornění)

  2. Na stránce Pravidla upozornění otevřete výstrahu a pak v horním navigačním panelu vyberte Upravit. Tady můžete nastavit úroveň závažnosti, popis pravidla a skupinu akcí s předvolbou oznámení, kterou chcete použít pro toto pravidlo upozornění.

    Snímek obrazovky zobrazující stránku pravidla upozornění na webu Azure Portal se zvýrazněnou možností Upravit

Kritéria upozornění

Automaticky povolená upozornění na dostupnost aktivují jeden e-mail, když se koncový bod stane nedostupným, a další e-mail, jakmile 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 nastavíte e-mailové upozornění s frekvencí vyhodnocení 15 minut. Dostanete e-mail jenom v případech, kdy web není dostupný, a další e-mail, když je opět dostupný. Nezískáte nepřetržitá upozornění každých 15 minut, abyste si připomněli, že web je stále nedostupný.

Změna kritérií upozornění

Možná nebudete chtít dostávat oznámení, když je váš web na krátkou dobu nedostupný, 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í.

Návod

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

Pokud chcete změnit prahovou hodnotu umístění, agregační období a frekvenci testů, přejděte na stránku Upravit pravidlo upozornění (viz krok 2 v části Povolit upozornění) a vyberte podmínku Configure signal logic a otevřete okno.

Snímek obrazovky se zvýrazněnou podmínkou upozornění a oknem 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 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.

  • Upozornění na X z Y lokalit hlásících selhání: Pravidlo upozornění 'X z Y lokalit' je ve výchozím nastavení povoleno v novém sjednoceném prostředí upozornění, když vytvoříte nový test 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 obdržíte 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 části Metriky vyberte v prostředí Application Insights prostředek a vyberte metriku Dostupnosti.

    2. Možnost Configure alerts 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 v zobrazení spojnicového grafu i zobrazení bodového grafu.

Zkontrolovat dostupnost

Začněte tím, že si prohlédněte graf v prostředí dostupnosti v Azure portálu.

Snímek obrazovky znázorňující graf prostředí dostupnosti se zvýrazněním přepínače mezi spojnicovým a bodovým grafem

Ve výchozím nastavení se v zobrazení dostupnosti zobrazuje spojnicový graf. Změňte zobrazení na Bodový graf (přepněte možnost nad grafem) a prohlédněte si vzorky výsledků testu, které obsahují podrobnosti jednotlivých kroků diagnostických testů. 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 dílčí sadu provedení. Pokud chcete zobrazit test, název testu a umístění, najeďte myší na některou ze zelených tečk nebo červených křížků.

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 na tato data.

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, otevřete místní nabídku (elipsa) vedle testu a pak vyberte Upravit. Po provedení změny může trvat až 20 minut, než se změny konfigurace rozšíří do všech testovacích agentů.

Návod

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 narazíte na chyby

Otevřete zobrazení podrobností o celém průběhu transakce výběrem červeného křížku v rozptylovém grafu.

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

Tady můžete:

  • Projděte si zprávu o potížích a zjistěte, co potenciálně způsobilo selhání testu.
  • Kontrolovat odpověď přijatou ze serveru.
  • Diagnostikujte selhání pomocí korelované telemetrie na straně serveru, která byla shromážděna během zpracování neúspěšného testu dostupnosti.
  • Sledujte problém protokolováním problému nebo pracovní položky v Gitu nebo Azure Boards. Tato chyba obsahuje odkaz na událost na webu Azure Portal.
  • 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 podrobnější diagnostiku na úrovni kódu.

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 (availabilityResults), závislostí (dependencies) a dalších. Další informace o Log Analytics najdete v přehledu dotazů protokolu.

Snímek obrazovky zobrazující výsledky dostupnosti v protokolech

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 vašich 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 za provádění testů budou účtovat poplatky. Před zahájením tohoto procesu si projděte ceny služby Azure Monitor.

Požadavky

Začínáme

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

  2. Vypište všechny URL ping testy pro aktuální předplatné.

    Get-AzApplicationInsightsWebTest | `
    Where-Object { $_.WebTestKind -eq "ping" } | `
    Format-Table -Property ResourceGroupName,Name,WebTestKind,Enabled;
    
  3. Vyhledejte test ping adresy URL, který hodláte migrovat, a poznamenejte si jeho skupinu prostředků a název.

  4. Vytvořte standardní test se stejnou logikou jako test ping adresy URL pomocí následujících příkazů, které fungují pro koncové body HTTP i HTTPS.

    $resourceGroup = "pingTestResourceGroup";
    $appInsightsComponent = "componentName";
    $pingTestName = "pingTestName";
    $newStandardTestName = "newStandardTestName";
    
    $componentId = (Get-AzApplicationInsights -ResourceGroupName $resourceGroup -Name $appInsightsComponent).Id;
    $pingTest = Get-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
    $pingTestRequest = ([xml]$pingTest.ConfigurationWebTest).WebTest.Items.Request;
    $pingTestValidationRule = ([xml]$pingTest.ConfigurationWebTest).WebTest.ValidationRules.ValidationRule;
    
    $dynamicParameters = @{};
    
    if ($pingTestRequest.IgnoreHttpStatusCode -eq [bool]::FalseString) {
    $dynamicParameters["RuleExpectedHttpStatusCode"] = [convert]::ToInt32($pingTestRequest.ExpectedHttpStatusCode, 10);
    }
    
    if ($pingTestValidationRule -and $pingTestValidationRule.DisplayName -eq "Find Text" `
    -and $pingTestValidationRule.RuleParameters.RuleParameter[0].Name -eq "FindText" `
    -and $pingTestValidationRule.RuleParameters.RuleParameter[0].Value) {
    $dynamicParameters["ContentMatch"] = $pingTestValidationRule.RuleParameters.RuleParameter[0].Value;
    $dynamicParameters["ContentPassIfTextFound"] = $true;
    }
    
    New-AzApplicationInsightsWebTest @dynamicParameters -ResourceGroupName $resourceGroup -Name $newStandardTestName `
    -Location $pingTest.Location -Kind 'standard' -Tag @{ "hidden-link:$componentId" = "Resource" } -TestName $newStandardTestName `
    -RequestUrl $pingTestRequest.Url -RequestHttpVerb "GET" -GeoLocation $pingTest.PropertiesLocations -Frequency $pingTest.Frequency `
    -Timeout $pingTest.Timeout -RetryEnabled:$pingTest.RetryEnabled -Enabled:$pingTest.Enabled `
    -RequestParseDependent:($pingTestRequest.ParseDependentRequests -eq [bool]::TrueString) -RuleSslCheck:$false;
    

    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.

  5. Ověřte funkčnost nového standardního testu, pak aktualizujte pravidla upozornění, která odkazují na test ping adresy URL, aby místo toho odkazovala na standardní test.

  6. Zakažte nebo odstraňte ping test URL. Pokud to chcete provést pomocí Azure PowerShellu, můžete použít tento příkaz:

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

Testování za firewallem

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

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.

Varování

Služba testů dostupnosti používá sdílené IP adresy, které můžou zpřístupnit koncové body chráněné bránou firewall pro provoz z jiných testů. Pokud chcete zabezpečit službu, nespoléhejte na filtrování IP adres sami. Přidejte vlastní hlavičky pro ověření původu každého webového požadavku. Další informace najdete v tématu Značky služeb virtuální sítě.

Autentizace provozu

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

  1. Vytvořte alfanumerický řetězec bez mezer k identifikaci tohoto testu dostupnosti (například MyAppAvailabilityTest). Odsud na tento řetězec odkazujeme jako na identifikátor testovacího řetězce dostupnosti.

  2. Při vytváření nebo aktualizaci testů dostupnosti přidejte vlastní hlavičku X-Customer-InstanceId s hodnotou ApplicationInsightsAvailability:<your availability test string identifier> v části Standardní testovací informace .

    Snímek obrazovky zobrazující vlastní hlavičku ověření

  3. 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ě jako parametr dotazu nastavte identifikátor řetězce testu dostupnosti.

Příklad: https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your availability test string identifier>

Nakonfigurujte bránu firewall tak, aby umožňovala příchozí požadavky 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 do prostředku skupiny zabezpečení sítě a v části Nastavení otevřete sekci Příchozí bezpečnostní pravidla a pak vyberte Přidat.

  2. Dále jako Zdroj vyberte Service Tag a jako značku zdrojové služby vyberte ApplicationInsightsAvailability. Pro příchozí provoz z tagu 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ž nejsou značky služeb volbou, přidejte IP adresy našich agentů webového testu na seznam povolených. Rozsahy IP adres můžete dotazovat pomocí PowerShellu, Azure CLI nebo volání REST pomocí Service Tag API. Ú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í otevřete nabídku příchozí pravidla zabezpečení a vyberte pak Přidat.

  2. Pak jako zdroj vyberte IP adresy. Pak přidejte své IP adresy do seznamu oddělených čárkami v poli zdrojové IP adresy/rozsahy CIDR.

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

  1. Připojte prostředek Application Insights k internímu koncovému bodu služby pomocí služby Azure Private Link.

  2. Napište vlastní kód, který bude pravidelně testovat váš 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

Application Insights používá protokol TLS (Transport Layer Security) 1.2 a 1.3. Kromě toho jsou v každé verzi podporovány také následující šifrovací sady a eliptické křivky.

Verze Šifrovací sady Eliptické křivky
TLS 1.2 • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (protokol pro zabezpečenou komunikaci)
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• NistP384
• NistP256
TLS 1.3 • TLS_AES_256_GCM_SHA384
• TLS_AES_128_GCM_SHA256
• NistP384
• NistP256

Důležité

Protokol TLS 1.3 je v současné době dostupný jenom v oblastech testování dostupnosti NorthCentralUS, CentralUS, EastUS, SouthCentralUS a WestUS.

Vyřazení konfigurací TLS (Transport Layer Security)

Důležité

Azure blokuje následující konfigurace PROTOKOLU TLS pro Application Insights 1. května 2025, aby zlepšila zabezpečení. Tato změna je součástí vyřazení protokolu TLS na úrovni Azure:

  • Verze protokolu TLS 1.0 a TLS 1.1
  • Starší šifrovací sady TLS 1.2 a TLS 1.3
  • Starší eliptické křivky TLS

TLS 1.0 a TLS 1.1

Protokoly TLS 1.0 a TLS 1.1 jsou vyřazovány.

TLS 1.2 a TLS 1.3

Verze Šifrovací sady Eliptické křivky
TLS 1.2 * TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
* TLS_RSA_WITH_AES_256_GCM_SHA384
* TLS_RSA_WITH_AES_128_GCM_SHA256
* TLS_RSA_WITH_AES_256_CBC_SHA256
* TLS_RSA_WITH_AES_128_CBC_SHA256
* TLS_RSA_WITH_AES_256_CBC_SHA
* TLS_RSA_WITH_AES_128_CBC_SHA
* křivka25519
TLS 1.3 * křivka25519

Sešit prostojů a výpadků

Tato část 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. Zpráva o prostojích a výpadcích nabízí výkonné předpřipravené dotazy a vizualizace dat, které vám pomůžou lépe porozumět konektivitě zákazníka, typické době odezvy aplikací a zažitým výpadkům.

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

  • Otevřete prostředí Dostupnost a pak v horním navigačním panelu vyberte SLA report.

  • Otevřete prostředí Sešity a poté vyberte šablonu Prostoje a výpadky.

Flexibilita parametrů

Parametry nastavené v sešitu ovlivňují zbytek vašich zpráv.

 Snímek obrazovky zobrazující parametry

  • Subscriptions, App Insights Resources a Web Test: Tyto parametry určují možnosti vyšší úrovně zdrojů. Jsou založeny na dotazech Log Analytics a používají se v každém dotazu v sestavách.
  • 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í, se ve výsledcích ignorují.
  • 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í případy výpadků
  • Výpadek aplikace

Případy výpadků se určují od okamžiku, kdy test začne selhávat, až dokud opět úspěšně neprojde podle vašich parametrů výpadku. Pokud test začne selhávat v 8:00 a úspěšně proběhne znovu v 10:00, považuje se celé časové období za stejný výpadek. 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.

Prostoje, výpadky a selhání

Vedle stránky Přehled jsou ještě dvě další karty:

  • Karta Výpadky a prostoj obsahuje informace o celkovém počtu výpadků a celkovém prostoji 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í.

Další funkce

  • Přizpůsobení: Sestavu můžete upravit stejně jako jakýkoli jiný sešit služby Azure Monitor a přizpůsobit dotazy nebo vizualizace podle 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.

  • Přístup a sdílení: 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 potřebuje oprávnění ke čtení a přístup k prostředku Application Insights, kde je uložený skutečný sešit.

Další kroky