Tillgänglighetstester för Application Insights

Application Insights gör det möjligt för dig att ställa in återkommande webbtester som övervakar din webbplats eller applikations tillgänglighet och responsivitet från olika platser runt om i världen. Dessa tillgänglighetstester skickar webbfrågor till din applikation med jämna mellanrum och meddelar dig om din applikation inte svarar eller om svarstiden är för långsam.

Tillgänglighetstester kräver inga ändringar på hemsidan eller applikationen som du testar. De fungerar för alla HTTP- eller HTTPS-endpunkter som är tillgängliga från det publika internet, inklusive REST API:er som din tjänst är beroende av. Detta innebär att du kan övervaka inte bara dina egna applikationer utan även externa tjänster som är avgörande för funktionaliteten hos dina applikationer. Du kan skapa upp till 100 tillgänglighetstester per Application Insights-resurs.

Typer av tillgänglighetstester

Det finns fyra typer av tillgänglighetstester.

• Standardtest: En typ av tillgänglighetstest som kontrollerar tillgängligheten för en webbplats genom att skicka en enda begäran, liknande det föråldrade URL-pingtestet. Förutom att validera om en slutpunkt svarar och mäta prestanda, inkluderar standardtester också giltigheten av TLS/SSL-certifikat, proaktiv livstidskontroll, HTTP-begärans verb (till exempel GET, HEAD, och POST), anpassade headers och anpassad data kopplad till din HTTP-begäran.

  Lär dig hur man skapar ett standardtest.

• Anpassat TrackAvailability-test: Om du bestämmer dig för att skapa en anpassad applikation för att köra tillgänglighetstest, kan du använda TrackAvailability()-metoden för att skicka resultaten till Application Insights.

  Lär dig hur du skapar ett anpassat TrackAvailability-test.

• (Föråldrad) Flerstegs webbaserat test: Du kan spela upp denna inspelning av en sekvens av webbfrågor för att testa mer komplexa scenarier. Flerstegswebbtester skapas i Visual Studio Enterprise och laddas upp till portalen, där du kan köra dem.

• (Föråldrad) URL-pingtest: Du kan skapa detta test via Azure-portalen för att kontrollera om en slutpunkt svarar och mäta prestandan i samband med det svaret. Du kan också ställa in egna framgångskriterier tillsammans med mer avancerade funktioner, som att tolka beroende förfrågningar och tillåta omförsök.

Skapa ett tillgänglighetstest

Tillgänglighetsaviseringar

Varningar är aktiverade som standard, men för att fullt ut konfigurera en varning måste du först skapa ditt tillgänglighetstest.

Befolkningsetiketter för plats

Du kan använda följande populationstaggar för geolokaliseringsattributet när du distribuerar ett standardtest eller URL-pingtest med Azure Resource Manager.

Aktivera aviseringar

1. När du har sparat tillgänglighetstestet öppnar du snabbmenyn efter det test du gjorde och väljer sedan sidan Öppna regler (aviseringar).

   

2. Öppna aviseringen på sidan Aviseringsregler och välj sedan Redigera i det övre navigeringsfältet. Här kan du ange allvarlighetsgrad, regelbeskrivning och åtgärdsgrupp som har de meddelandeinställningar som du vill använda för den här aviseringsregeln.

   

Aviseringsvillkor

Automatiskt aktiverade tillgänglighetsaviseringar utlöser ett e-postmeddelande när slutpunkten blir otillgänglig och ett annat e-postmeddelande när den är tillgänglig igen. Tillgänglighetsaviseringar som skapas via den här upplevelsen är tillståndsbaserade. När larmkriterierna uppfylls genereras ett enda larm när webbplatsen upptäcks som otillgänglig. Om webbplatsen fortfarande är nere nästa gång larmkriterierna utvärderas, kommer det inte att generera en ny varning.

Anta till exempel att din webbplats är nere i en timme och du ställer in ett e-postmeddelande med en utvärderingsfrekvens på 15 minuter. Du får endast ett e-postmeddelande när webbplatsen går ner och ytterligare ett mail när den är online igen. Du får inte kontinuerliga aviseringar var 15:e minut för att påminna dig om att webbplatsen fortfarande är otillgänglig.

Ändra larmkriterierna

Du kanske inte vill få aviseringar när din webbplats är nere under en kort period, till exempel under underhåll. Du kan ändra utvärderingsfrekvensen till ett högre värde än den förväntade stilleståndstiden, upp till 15 minuter. Du kan också öka gränsvärdet för varningar baserat på plats, så att en varning endast utlöses om webbplatsen är nere i ett visst antal regioner.

För att göra ändringar i platsgränsvärdet, aggregeringsperioden och testfrekvensen, gå till sidan Redigera larmregel (se steg 2 under Aktivera larm), och välj sedan villkoret för att öppna Configure signal logic-fönstret.

Skapa en anpassad varningsregel

Om du behöver avancerade funktioner kan du skapa en anpassad aviseringsregel på fliken Aviseringar . Välj Skapa>aviseringsregel. Välj Mätvärden för Signaltyp för att visa alla tillgängliga signaler och välj Tillgänglighet.

En anpassad aviseringsregel erbjuder högre värden för aggregeringsperioden (upp till 24 timmar i stället för 6 timmar) och testfrekvensen (upp till 1 timme i stället för 15 minuter). Den lägger också till alternativ för att ytterligare definiera logiken genom att välja olika operatörer, aggregeringstyper och tröskelvärden.

• Larm på X av Y platser rapporterar fel: Larmregeln för X av Y platser är aktiverad som standard i den nya enhetliga varningsupplevelsen när du skapar ett nytt tillgänglighetstest. Du kan välja bort genom att välja alternativet "klassisk" eller genom att välja att inaktivera aviseringsregeln. Konfigurera åtgärdsgrupperna för att ta emot meddelanden när aviseringen utlöses genom att följa föregående steg. Utan det här steget får du bara meddelanden i portalen när regeln utlöses.

• Varna om tillgänglighetsmått: Genom att använda de nya enhetliga varningarna kan du också varna om segmenterade aggregerade tillgänglighets- och testlängdmått.

  1. Välj en Application Insights-resurs i Mätdata-upplevelsen och välj en Tillgänglighets-mätning.

  2. Alternativet Configure alerts från menyn tar dig till den nya upplevelsen där du kan välja specifika tester eller platser för att ställa in varningsregler. Du kan även konfigurera åtgärdsgrupperna för denna varningsregel här.

• Varning för anpassade analysfrågor: Genom att använda de nya enhetliga varningarna kan du varna för anpassade loggfrågor. Med anpassade frågor kan du få varningar baserade på godtyckliga villkor som hjälper dig att få det mest tillförlitliga tecknet på tillgänglighetsproblem. Det är också tillämpligt om du skickar anpassade tillgänglighetsresultat med hjälp av TrackAvailability SDK.

  Mätvärdena för tillgänglighetsdata inkluderar eventuella anpassade tillgänglighetsresultat som du kan skicka in genom att anropa TrackAvailability SDK. Du kan använda övervakning av mätvärdesstöd för att varna om anpassade tillgänglighetsresultat.

Automatisera aviseringar

För att automatisera denna process med Azure Resource Manager-mallar, se Skapa ett metriskt larm med en Azure Resource Manager-mall.

Se dina tillgänglighetstestresultat

Den här sektionen förklarar hur man granskar resultat för tillgänglighetstester i Azure-portalen och frågar datan med hjälp av Log Analytics. Testresultat för tillgänglighet kan visualiseras med både linjediagram och punktdiagram vyer.

Kontrollera tillgänglighet

Börja med att granska grafen i Tillgänglighet-upplevelsen i Azure-portalen.

Som standard visar tillgänglighetsupplevelsen ett linjediagram. Byt visning till Spridningsdiagram (växla ovanför diagrammet) för att se exempel på testresultat som innehåller detaljerade diagnostiska teststeg. Testmotorn lagrar diagnostisk information för tester som har misslyckats. För lyckade tester lagras diagnostiska detaljer för en delmängd av körningarna. För att se testet, testnamnet och platsen, hovra över någon av de gröna punkterna eller röda kryssen.

Välj ett särskilt test eller en plats. Eller kan du förkorta tidsperioden för att se fler resultat kring den tidsperiod du är intresserad av. Använd Sökutforskaren för att se resultat från alla körningar. Eller så kan du använda Log Analytics-frågor för att köra anpassade rapporter på dessa data.

För att se fullständiga transaktionsdetaljer, under Detaljnivå, välj Lyckad eller Misslyckad. Välj sedan ett exempel. Du kan också komma åt detaljerna om transaktionen från början till slut genom att välja en datapunkt på grafen.

Inspektera och redigera tester

Om du vill redigera, tillfälligt inaktivera eller ta bort ett test öppnar du snabbmenyn (ellipsen) efter testet och väljer sedan Redigera. Det kan ta upp till 20 minuter för konfigurationsändringar att sprida sig till alla testagenter efter att en ändring har gjorts.

Om du ser fel

Öppna vyn End-to-end-transaktionsdetaljer genom att välja ett rött kryss i Spridningsdiagrammet.

Här kan du

• Granska Felsökningsrapporten för att avgöra vad som eventuellt orsakade att ditt test misslyckades.
• Kontrollera svaret som mottagits från din server.
• Diagnostisera fel med korrelerad telemetri på serversidan som samlas in vid bearbetning av det misslyckade tillgänglighetstestet.
• Spåra problemet genom att logga ett ärende eller arbetsuppgift i Git eller Azure Boards. Buggen innehåller en länk till händelsen i Azure-portalen.
• Öppna web testresultatet i Visual Studio.

För att lära dig mer om upplevelsen av end-to-end-transaktionsdiagnostik, se dokumentationen för transaktionsdiagnostik.

Välj rad med undantag för att se detaljerna kring serverundantaget som fick det syntetiska tillgänglighetstestet att misslyckas. Du kan också hämta felsökningsögonblicksbilden för mer omfattande diagnostik på kodnivå.

Förutom de råa resultaten kan du också se två viktiga tillgänglighetssiffror i metrics explorer:

• Tillgänglighet: Procentandelen av testerna som lyckades över alla testkörningar.
• Testvaraktighet: Genomsnittlig testvaraktighet över alla testutföranden.

Fråga i Logganalys

Du kan använda Log Analytics för att visa dina tillgänglighetsresultat (availabilityResults), beroenden (dependencies) med mera. Mer information om Log Analytics finns i Översikt över loggfrågor.

Migrera klassiska URL-pingtester till standardtester

De följande stegen leder dig genom processen att skapa standardtester som replikerar funktionaliteten i dina URL-pingtester. Det möjliggör för dig att enklare börja använda de avancerade funktionerna hos standardtesterna med hjälp av dina tidigare skapade URL-pingtester.

Prerequisites

Upptäck URL-pingtester

Identifiera URL-pingtester med följande fråga i Azure Resource Graph Explorer.

resources
| where subscriptionId == "<subscriptionId>"
| where ['type'] == "microsoft.insights/webtests"
| extend testKind = tostring(properties.Kind)
| where testKind == "ping"

Påbörja migrering

1. Anslut till din prenumeration med Azure PowerShell (Connect-AzAccount + Set-AzContext).

2. Lista alla URL-pingtester i den aktuella prenumerationen.

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

3. Hitta URL-pingtestet du vill migrera och notera dess resursgrupp och namn.

4. Skapa ett standardtest med samma logik som URL-pingtestet genom att använda följande kommandon, som fungerar för både HTTP- och HTTPS-slutpunkter.

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

   Det nya standardtestet har inte varningsregler som standard, så det skapar inte störande varningar. Inga ändringar görs i ditt URL-pingtest så du kan fortsätta lita på det för aviseringar.

5. Validera funktionaliteten hos det nya standardtestet och uppdatera dina varningsregler som refererar till URL-pingtestet så att de istället refererar till standardtestet.

6. Inaktivera eller ta bort URL-pingtestet. För att göra detta med Azure PowerShell kan du använda följande kommando:

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

Testa bakom en brandvägg

För att säkerställa tillgängligheten av slutpunkter bakom brandväggar, aktivera offentliga tillgänglighetstester eller kör tillgänglighetstester i frånkopplade eller inget inkommande trafikscenarier.

Aktivering av tillgänglighetstest för allmänheten

Se till att din interna webbplats har en offentlig Domainnamnssystem (DNS)-post. Tillgänglighetstester misslyckas om DNS inte kan lösas. För mer information, se Skapa ett anpassat domännamn för intern applikation.

Autentisera trafik

Ställ in anpassade rubriker i standardtester för att validera trafik.

1. Skapa en alfanumerisk sträng utan mellanslag för att identifiera detta tillgänglighetstest (till exempel, MyAppAvailabilityTest). Från och med nu refererar vi till denna sträng som tillgänglighetsteststrängsidentifierare.

2. Lägg till den anpassade rubriken X-Customer-InstanceId med värdet ApplicationInsightsAvailability:<your availability test string identifier> under avsnittet Standard testinfo när du skapar eller uppdaterar dina tillgänglighetstester.

   

3. Se till att din tjänst kontrollerar om inkommande trafik inkluderar den header och det värde som definierades i de tidigare stegen.

Du kan också ange tillgänglighetsteststrängens identifierare som en frågeparameter.

Exempel:https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your availability test string identifier>

Konfigurera din brandvägg för att tillåta inkommande förfrågningar från tillgänglighetstester.

För att förenkla aktivering av Azure-tjänster utan att behöva auktorisera enskilda IP-adresser eller upprätthålla en uppdaterad IP-lista, använd Servicetaggar. Applicera dessa taggar över Azure Firewall och nätverkssäkerhetsgrupper, så att tillgänglighetstesttjänsten får åtkomst till dina slutpunkter. Servicetagg ApplicationInsightsAvailability gäller för alla tillgänglighetstester.

1. Om du använder Azures nätverkssäkerhetsgrupper, gå till resursen för din nätverkssäkerhetsgrupp och under Inställningar, öppna upplevelsen för Inkommande säkerhetsregler och välj sedan Lägg till.

2. Sedan, välj Tjänstetikett som Källa och ApplicationInsightsAvailability som Källans tjänstetikett. Använd öppna portar 80 (http) och 443 (https) för inkommande trafik från tjänstetiketten.

Om du vill hantera åtkomst när dina slutpunkter ligger utanför Azure eller när tjänsttaggar inte är ett alternativ, tillåtlista IP-adresserna för våra webbtestagenter. Du kan fråga IP-intervall med hjälp av PowerShell, Azure CLI eller ett REST-anrop med Service Tag API. För en omfattande lista över aktuella tjänsttaggar och deras IP-detaljer, ladda ner JSON-filen.

1. I din nätverkssäkerhetsgruppsresurs, under Inställningar, öppna upplevelsen för Inkommande säkerhetsregler och välj sedan Lägg till.

2. Nästa steg är att välja IP-adresser som din källa. Lägg sedan till dina IP-adresser i en kommaavgränsad lista i KÄLL-IP-adress/CIRD-intervall.

Frånkopplade eller inga inkommande scenarier

1. Anslut din Application Insights-resurs till din interna tjänstslutpunkt med hjälp av Azure Private Link.

2. Skriv anpassad kod för att regelbundet testa din interna server eller dina ändpunkter. Skicka resultaten till Application Insights med hjälp av TrackAvailability()-API:n i kärn-SDK-paketet.

Stödda TLS-konfigurationer

Application Insights använder TLS (Transport Layer Security) 1.2 och 1.3. Dessutom stöds följande krypteringssviter och elliptiska kurvor i varje version.

Inaktuella TLS-konfigurationer (Transport Layer Security)

TLS 1.2 och TLS 1.3

Driftstopp & störningar arbetsbok

Denna sektion presenterar ett enkelt sätt att beräkna och rapportera servicenivåavtal (SLA) för webbtester genom en enhetlig översikt över dina Application Insights-resurser och Azure-abonnemang. Driftstopp- och avbrottsrapporten erbjuder kraftfulla fördefinierade frågor och datavisualiseringar för att förbättra din förståelse av kundens uppkoppling, typiska svarstider för applikationer och upplevda driftstopp.

SLA-arbetsboksmallen kan nås från din Application Insights-resurs på två sätt:

• Öppna Tillgänglighetsupplevelsen, välj sedan SLA-rapport från den övre navigeringslisten.

• Öppna upplevelsen Arbetsböcker, och välj sedan mallen Downtime & Outages.

Parameterflexitet

Parametrarna som anges i arbetsboken påverkar resten av rapporten.

• Subscriptions, App Insights Resources och Web Test: Dessa parametrar bestämmer dina övergripande resursalternativ. De baseras på Log Analytics-frågor och används i varje rapportfråga.
• Failure Threshold och Outage Window: Du kan använda dessa parametrar för att fastställa dina egna kriterier för ett tjänststopp. Ett exempel är kriterierna för en Application Insights-tillgänglighetsavisering baserat på en felande platsräknare under en vald period. Det typiska tröskelvärdet är tre platser under ett femminutersfönster.
• Maintenance Period: Du kan använda denna parameter för att välja din typiska underhållsfrekvens.  Maintenance Window är en datum- och tidväljare för en exempelperiod för underhåll. All data som uppstår under den identifierade perioden ignoreras i dina resultat.
• Availability Target %: Denna parameter specificerar ditt mål och tillåter anpassade värden.

Översiktssida

Översiktssidan innehåller övergripande information om din:

• Total SLA (exklusive underhållsperioder, om sådana är definierade)
• Helvägs avbrottstillfällen
• Programavbrott

Avbrottsinstanser fastställs från det ögonblick testet börjar misslyckas tills det framgångsrikt klaras igen, enligt dina avbrottsparametrar. Om ett test börjar misslyckas klockan 08:00 och lyckas igen kl. 10:00 betraktas hela dataperioden som samma avbrott. Du kan också undersöka det längsta avbrottet som inträffade under din rapporteringsperiod.

Vissa tester kan länkas tillbaka till deras Application Insights-resurs för vidare undersökning. Men det är bara möjligt i workspace-baserade Application Insights-resursen.

Stillestånd, avbrott och fel

Det finns två fler flikar bredvid sidan Översikt.

• Outages & Downtime-fliken innehåller information om totala avbrottsfall och total stilleståndstid uppdelad per test.

• Fliken Fel efter plats har en geo-karta över misslyckade testplatser för att hjälpa identifiera potentiella problemområden med anslutningar.

Andra funktioner

• Anpassning: Du kan redigera rapporten som vilken annan Azure Monitor-arbetsbok som helst och anpassa frågorna eller visualiseringarna baserat på ditt teams behov.

• Log Analytics: Frågorna kan alla köras i Log Analytics och användas i andra rapporter eller instrumentpaneler. Ta bort parametrarnas begränsning och återanvänd kärnfrågan.

• Åtkomst och delning: Rapporten kan delas med dina team och ledning eller fästas på en instrumentpanel för vidare användning. Användaren behöver läsbehörighet och åtkomst till Application Insights-resursen där den faktiska arbetsboken är lagrad.

Nästa steg

• Granska vanliga frågor och svar, se Vanliga frågor och svar om tillgänglighetstester och TLS-support för vanliga frågor och svar om tillgänglighetstester
• Felsöka tillgänglighetsproblem
• Utforska Azure Resource Manager-mall för webbtester
• Läs mer om REST API för webbtest