Dela via

Tillgänglighetstest för Application Insights

  • Artikel

Med Application Insights kan du konfigurera återkommande webbtester som övervakar webbplatsens eller programmets tillgänglighet och svarstider från olika platser runt om i världen. Dessa tillgänglighetstester skickar webbbegäranden till ditt program med jämna mellanrum och varnar dig om programmet inte svarar eller om svarstiden är för långsam.

Tillgänglighetstester kräver inga ändringar av webbplatsen eller programmet som du testar. De fungerar för alla HTTP- eller HTTPS-slutpunkter som är tillgängliga från det offentliga Internet, inklusive REST-API:er som din tjänst är beroende av. Det innebär att du inte bara kan övervaka dina egna program utan även externa tjänster som är viktiga för programmets funktioner. Du kan skapa upp till 100 tillgänglighetstester per Application Insights-resurs.

Kommentar

Tillgänglighetstester lagras krypterade enligt Azure-datakryptering i viloprinciper .

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, ungefär som det inaktuella URL-pingtestet. Förutom att verifiera om en slutpunkt svarar och mäter prestandan innehåller Standard-tester även TLS/SSL-certifikatets giltighet, proaktiv livslängdskontroll, HTTP-begärandeverb (till exempel GET,HEAD, och POST), anpassade huvuden och anpassade data som är associerade med din HTTP-begäran.

    Lär dig hur du skapar ett standardtest.

  • Anpassat TrackAvailability-test: Om du väljer att skapa ett anpassat program för att köra tillgänglighetstester kan du använda metoden TrackAvailability() för att skicka resultatet till Application Insights.

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

  • (Inaktuell) Webbtest i flera steg: Du kan spela upp den här inspelningen av en sekvens med webbbegäranden för att testa mer komplexa scenarier. Webbtester i flera steg skapas i Visual Studio Enterprise och laddas upp till portalen, där du kan köra dem.

  • (Inaktuell) URL-pingtest: Du kan skapa det här testet via Azure Portal för att verifiera om en slutpunkt svarar och mäta prestanda som är associerad med det svaret. Du kan också ange anpassade framgångsvillkor i kombination med mer avancerade funktioner, som att parsa beroende begäranden och tillåta återförsök.

Viktigt!

Det finns två kommande tillgänglighetstester som dras tillbaka:

  • Webbtester i flera steg: Den 31 augusti 2024 dras webbtester i flera steg i Application Insights tillbaka. Vi rekommenderar att användarna av dessa tester övergår till alternativa tillgänglighetstester före slutdatumet. Efter det här datumet kommer vi att ta ned den underliggande infrastrukturen som kommer att bryta återstående tester i flera steg.

  • URL-pingtester: Den 30 september 2026 dras URL-pingtest i Application Insights tillbaka. Befintliga URL-pingtester tas bort från dina resurser. Granska prissättningen för standardtester och övergå till att använda dem före den 30 september 2026 för att se till att du kan fortsätta att köra tillgänglighetstester i ett steg i dina Application Insights-resurser.

Skapa ett tillgänglighetstest

Förutsättningar

Kom igång

  1. Gå till din Application Insights-resurs och öppna tillgänglighetsupplevelsen.

  2. Välj Lägg till standardtest i det övre navigeringsfältet.

    Skärmbild som visar tillgänglighetsupplevelsen med fliken Lägg till standardtest öppen.

  3. Ange testnamnet, URL:en och andra inställningar som beskrivs i följande tabell och välj sedan Skapa.

    Avsnitt Inställning beskrivning
    Grundläggande information
    URL URL:en kan vara vilken webbsida som helst som du vill testa, men den måste vara synlig från det offentliga Internet. URL: en kan innehålla en frågesträng. Du kan arbeta med din databas om du vill. Om URL-adressen matchar en omdirigering följer vi den upp till tio omdirigeringar.
    Parsa beroende begäranden Testa begäranden av bilder, skript, formatfiler och andra filer som är en del av webbsidan under test. Den registrerade svarstiden innefattar den tid det tar att hämta dessa filer. Testet misslyckas om någon av dessa resurser inte kan laddas ned inom tidsgränsen för hela testet. Om alternativet inte är markerat begär testet endast filen på den URL som du angav. Om du aktiverar det här alternativet blir kontrollen striktare. Testet kan misslyckas för fall, vilket kanske inte märks när du bläddrar manuellt på webbplatsen. Vi parsar endast upp till 15 beroende begäranden.
    Aktivera återförsök för tillgänglighetstestfel När testet misslyckas försöker det igen efter ett kort intervall. Ett fel rapporteras endast om tre på varandra följande försök misslyckas. Efterföljande tester utförs sedan med den vanliga testfrekvensen. Återförsök pausas tillfälligt tills nästa lyckade test. Den här regeln tillämpas separat på varje testplats. Vi rekommenderar det här alternativet. I genomsnitt försvinner ca 80 % av felen vid återförsök.
    Aktivera SSL-certifikatets giltighet Du kan verifiera SSL-certifikatet på webbplatsen för att se till att det är korrekt installerat, giltigt, betrott och inte ger några fel till någon av dina användare.
    Proaktiv livslängdskontroll Med den här inställningen kan du definiera en angiven tidsperiod innan SSL-certifikatet upphör att gälla. När det har upphört att gälla misslyckas testet.
    Testfrekvens Anger hur ofta testet körs från varje testplats. Med en standardfrekvens på fem minuter och fem testplatser testas din webbplats i genomsnitt varje minut.
    Testplatser Våra servrar skickar webbbegäranden till din URL från dessa platser. Vårt minsta antal rekommenderade testplatser är fem för att se till att du kan skilja problem på din webbplats från nätverksproblem. Du kan välja upp till 16 platser.
    Standardtestinformation
    HTTP-begärandeverb Ange vilken åtgärd du vill vidta med din begäran.
    Begärandetext Anpassade data som är associerade med din HTTP-begäran. Du kan ladda upp dina egna filer, ange ditt innehåll eller inaktivera den här funktionen.
    Lägga till anpassade rubriker Nyckelvärdepar som definierar driftparen.
    Framgångsvillkor
    Tidsgräns för test Minska det här värdet för att få aviseringar om långsamma svar. Testet räknas som ett fel om svaren från din webbplats inte tas emot inom den här perioden. Om du har valt Parsa beroende begäranden måste alla bilder, formatfiler, skript och andra beroende resurser tas emot inom den här perioden.
    HTTP-svar Den returnerade statuskoden räknas som en framgång. Talet 200 är koden som anger att en normal webbsida returneras.
    Innehållsmatchning En sträng, som "Välkommen!" Vi testar att en exakt skiftlägeskänslig matchning sker i varje svar. Den måste vara en enkel sträng utan jokertecken. Glöm inte att om sidinnehållet ändras kan du behöva uppdatera det. Endast engelska tecken stöds med innehållsmatchning.

Tillgänglighetsaviseringar

Aviseringar aktiveras automatiskt som standard, men om du vill konfigurera en avisering helt måste du först skapa ditt tillgänglighetstest.

Inställning beskrivning
Nära realtid Vi rekommenderar att du använder aviseringar i nära realtid. Du konfigurerar den här typen av avisering när tillgänglighetstestet har skapats.
Tröskelvärde för aviseringsplats Vi rekommenderar minst 3/5 platser. Den optimala relationen mellan tröskelvärdet för aviseringsplatser och antalet testplatser är tröskelvärdet = för aviseringsplats för testplatser – 2, med minst fem testplatser.

Platspopulationstaggar

Du kan använda följande populationstaggar för attributet geo-location när du distribuerar ett standardtest eller url-pingtest med hjälp av Azure Resource Manager.

Provider Visningsnamn Befolkningsnamn
Azure
Australien, östra emea-au-syd-edge
Brasilien, södra latam-br-gru-edge
Centrala USA us-fl-mia-edge
Asien, östra apac-hk-hkn-azr
USA, östra us-va-ash-azr
Frankrike, södra (tidigare Frankrike, centrala) emea-ch-zrh-edge
Centrala Frankrike emea-fr-pra-edge
Japan, östra apac-jp-kaw-edge
Europa, norra emea-gb-db3-azr
Norra centrala USA us-il-ch1-azr
USA, södra centrala us-tx-sn1-azr
Sydostasien apac-sg-sin-azr
Västra Storbritannien emea-se-sto-edge
Västeuropa emea-nl-ams-azr
Västra USA us-ca-sjc-azr
Södra Storbritannien emea-ru-msa-edge
Azure Government
USGov Virginia usgov-va-azr
USGov Arizona usgov-phx-azr
USGov Texas usgov-tx-azr
USDoD, östra usgov-ddeast-azr
USDoD Central usgov-ddcentral-azr
Microsoft Azure drivs av 21Vianet
Kina, östra mc-cne-azr
Östra Kina 2 mc-cne2-azr
Kina, norra mc-cnn-azr
Norra Kina 2 mc-cnn2-azr

Aktivera aviseringar

Kommentar

Med de nya enhetliga aviseringarna måste aviseringsregelns allvarlighetsgrad och meddelandeinställningar med åtgärdsgrupperkonfigureras i aviseringsupplevelsen. Utan följande steg får du bara meddelanden i portalen.

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

    Skärmbild som visar tillgänglighetsupplevelsen för en Application Insights-resurs i menyalternativet Azure Portal och Ö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.

    Skärmbild som visar en aviseringsregelsida i Azure Portal med Redigera markerad.

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 aviseringsvillkoren uppfylls genereras en enda avisering när webbplatsen identifieras som otillgänglig. Om webbplatsen fortfarande ligger nere nästa gång aviseringskriterierna utvärderas genereras ingen ny avisering.

Anta till exempel att webbplatsen är nere i en timme och att du konfigurerar en e-postavisering med en utvärderingsfrekvens på 15 minuter. Du får bara ett e-postmeddelande när webbplatsen slutar fungera och ett annat e-postmeddelande när den är online igen. Du får inga kontinuerliga aviseringar var 15:e minut för att påminna dig om att webbplatsen fortfarande inte är tillgänglig.

Ändra aviseringsvillkoren

Du kanske inte vill ta emot meddelanden när webbplatsen är nere under en kort tidsperiod, 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 tröskelvärdet för aviseringsplats så att det bara utlöser en avisering om webbplatsen är nere för ett visst antal regioner.

Dricks

För längre schemalagda driftstopp inaktiverar du tillfälligt aviseringsregeln eller skapar en anpassad regel. Det ger dig fler alternativ för att ta hänsyn till stilleståndstiden.

Om du vill göra ändringar i platströskelvärdet, aggregeringsperioden och testfrekvensen går du till sidan Redigera aviseringsregel (se steg 2 under Aktivera aviseringar) och väljer sedan villkoret för att öppna fönstret Konfigurera signallogik .

Skärmbild som visar ett markerat aviseringsvillkor och fönstret Konfigurera signallogik.

Skapa en anpassad aviseringsregel

Om du behöver avancerade funktioner kan du skapa en anpassad aviseringsregel på fliken Aviseringar. Välj Skapa> aviseringsregel. Välj Mått 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 operatorer, aggregeringstyper och tröskelvärden.

  • Avisering på X av Y-platser rapporterar fel: Aviseringsregeln X av Y-platser är aktiverad som standard i den nya enhetliga aviseringsupplevelsen 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.

  • Avisering om tillgänglighetsmått: Genom att använda de nya enhetliga aviseringarna kan du också avisera om segmenterad aggregeringstillgänglighet och mått för testvaraktighet:

    1. Välj en Application Insights-resurs i måttmiljön och välj ett tillgänglighetsmått.

    2. Alternativet Konfigurera aviseringar på menyn tar dig till den nya upplevelsen där du kan välja specifika tester eller platser där du vill konfigurera aviseringsregler. Du kan också konfigurera åtgärdsgrupperna för den här aviseringsregeln här.

  • Avisering om anpassade analysfrågor: Med hjälp av de nya enhetliga aviseringarna kan du avisera om anpassade loggfrågor. Med anpassade frågor kan du avisera om godtyckliga villkor som hjälper dig att få den mest tillförlitliga signalen om tillgänglighetsproblem. Det gäller även om du skickar anpassade tillgänglighetsresultat med hjälp av TrackAvailability SDK.

    Måtten för tillgänglighetsdata innehåller alla anpassade tillgänglighetsresultat som du kan skicka genom att anropa TrackAvailability SDK. Du kan använda aviseringar för måttstöd för att avisera om anpassade tillgänglighetsresultat.

Automatisera aviseringar

Information om hur du automatiserar den här processen med Azure Resource Manager-mallar finns i Skapa en måttavisering med en Azure Resource Manager-mall.

Visa tillgänglighetstestresultat

I det här avsnittet beskrivs hur du granskar tillgänglighetstestresultaten i Azure Portal och frågar efter data med Log Analytics. Tillgänglighetstestresultat kan visualiseras med både linje- och punktdiagramvyer .

Kontrollera tillgänglighet

Börja med att granska diagrammet i tillgänglighetsupplevelsen i Azure Portal.

Skärmbild som visar diagrammet Tillgänglighetsupplevelse som markerar växlingsknappen mellan linje- och punktdiagrammet.

Som standard visar tillgänglighetsupplevelsen ett linjediagram. Ändra vyn till Punktdiagram (växla ovanför grafen) om du vill se exempel på testresultat som innehåller detaljerad information om diagnostiska teststeg. Testmotorn lagrar diagnosinformation för tester som innehåller fel. För lyckade tester lagras diagnosinformation för en delmängd av körningarna. Om du vill se testet, testnamnet och platsen hovrar du över någon av de gröna punkterna eller röda korsen.

Välj ett visst test eller en viss plats. Eller så kan du minska tidsperioden för att se fler resultat runt den aktuella tidsperioden. 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.

Om du vill se transaktionsinformationen från slutpunkt till slutpunkt går du till Detaljnivå och väljer Lyckad eller Misslyckad. Välj sedan ett exempel. Du kan också komma till transaktionsinformationen från slutpunkt till slutpunkt genom att välja en datapunkt i diagrammet.

Skärmbild som visar hur du väljer ett exempel på tillgänglighetstest.

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 innan konfigurationsändringar sprids till alla testagenter när en ändring har gjorts.

Dricks

Du kanske vill inaktivera tillgänglighetstester eller de aviseringsregler som är associerade med dem medan du utför underhåll på din tjänst.

Om du ser fel

Öppna vyn Transaktionsinformation från slutpunkt till slutpunkt genom att välja ett rött kors i punktdiagrammet.

Skärmbild som visar fliken Transaktionsinformation från slutpunkt till slutpunkt.

Här kan du:

  • Granska felsökningsrapporten för att ta reda på vad som kan ha orsakat att testet misslyckades.
  • Kontrollera de svar som mottas från servern.
  • Diagnostisera fel med korrelerad telemetri på serversidan som samlas in vid bearbetning av det misslyckade tillgänglighetstestet.
  • Spåra problemet genom att logga ett problem eller ett arbetsobjekt i Git eller Azure Boards. Felet innehåller en länk till händelsen i Azure Portal.
  • Öppna resultatet av webbtestet i Visual Studio.

Mer information om transaktionsdiagnostik från slutpunkt till slutpunkt finns i dokumentationen för transaktionsdiagnostik.

Välj undantagsraden för att se information om undantaget på serversidan som gjorde att det syntetiska tillgänglighetstestet misslyckades. Du kan också hämta felsökningsögonblicksbilden för mer omfattande diagnostik på kodnivå.

Förutom rådataresultaten kan du också visa två viktiga tillgänglighetsmått i Metrics Explorer:

  • Tillgänglighet: Procentandel av testerna som lyckades i alla testkörningar.
  • Testvaraktighet: Genomsnittlig testvaraktighet för alla testkörningar.

Fråga i Log Analytics

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.

Skärmbild som visar tillgänglighetsresultat i loggar.

Migrera klassiska URL-pingtester till standardtester

Följande steg beskriver hur du skapar standardtester som replikerar funktionerna i dina URL-pingtester. Det gör att du enklare kan börja använda avancerade funktioner i standardtester med hjälp av dina tidigare skapade URL-pingtester.

Viktigt!

En kostnad är associerad med att köra standardtester. När du har skapat ett standardtest debiteras du för testkörningar. Se Priser för Azure Monitor innan du påbörjar den här processen.

Förutsättningar

Kom igång

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

  2. Visa en lista över alla URL-pingtester i den aktuella prenumerationen:

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

  3. Leta upp det URL-pingtest som du vill migrera och registrera dess resursgrupp och namn.

  4. Skapa ett standardtest med samma logik som URL-pingtestet med hjälp av 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);

    Det nya standardtestet har inte aviseringsregler som standard, så det skapar inte aviseringar med brus. Inga ändringar görs i url-pingtestet så att du kan fortsätta att förlita dig på det för aviseringar.

  5. Verifiera funktionerna i det nya standardtestet och uppdatera sedan aviseringsreglerna som refererar till URL-pingtestet för att referera till standardtestet i stället.

  6. Inaktivera eller ta bort URL-pingtestet. Om du vill göra det med Azure PowerShell kan du använda det här kommandot:

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

Testa bakom en brandvägg

För att säkerställa slutpunktstillgänglighet bakom brandväggar aktiverar du tester av offentlig tillgänglighet eller kör tillgänglighetstester i frånkopplade eller inga ingressscenarier.

Testaktivering av offentlig tillgänglighet

Kontrollera att din interna webbplats har en offentlig DNS-post (Domain Name System). Tillgänglighetstester misslyckas om DNS inte kan matchas. Mer information finns i Skapa ett anpassat domännamn för internt program.

Varning

IP-adresserna som används av tillgänglighetstesttjänsten delas och kan exponera dina brandväggsskyddade tjänstslutpunkter för andra tester. Enbart IP-adressfiltrering skyddar inte tjänstens trafik, så vi rekommenderar att du lägger till extra anpassade rubriker för att verifiera webbbegärans ursprung. Mer information finns i Tjänsttaggar för virtuellt nätverk.

Autentisera trafik

Ange anpassade huvuden i standardtester för att verifiera trafik.

  1. Skapa en alfanumerisk sträng utan blanksteg för att identifiera det här tillgänglighetstestet (till exempel MyAppAvailabilityTest). Härifrån refererar vi till den här strängen som tillgänglighetsteststrängsidentifierare.

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

    Skärmbild som visar anpassat valideringshuvud.

  3. Kontrollera att tjänsten kontrollerar om inkommande trafik innehåller huvudet och värdet som definierats i föregående steg.

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 brandväggen för att tillåta inkommande begäranden från tillgänglighetstester

Kommentar

Det här exemplet är specifikt för användning av tjänsttaggar för nätverkssäkerhetsgrupp. Många Azure-tjänster accepterar tjänsttaggar som var och en kräver olika konfigurationssteg.

Om du vill förenkla aktiveringen av Azure-tjänster utan att auktorisera enskilda IP-adresser eller underhålla en uppdaterad IP-lista använder du tjänsttaggar. Använd dessa taggar i Azure Firewall och nätverkssäkerhetsgrupper, vilket ger tillgänglighetstesttjänsten åtkomst till dina slutpunkter. Tjänsttaggen ApplicationInsightsAvailability gäller för alla tillgänglighetstester.

  1. Om du använder Azure-nätverkssäkerhetsgrupper går du till nätverkssäkerhetsgruppens resurs och under Inställningar öppnar du funktionen Inkommande säkerhetsregler och väljer sedan Lägg till.

  2. Välj sedan Tjänsttagg som Källa och ApplicationInsightsAvailability som källtjänsttagg. Använd öppna portar 80 (http) och 443 (https) för inkommande trafik från tjänsttaggen.

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 köra frågor mot IP-intervall med hjälp av PowerShell, Azure CLI eller ett REST-anrop med API:et för tjänsttagg. En omfattande lista över aktuella tjänsttaggar och deras IP-information finns i JSON-filen.

  1. I nätverkssäkerhetsgruppens resurs går du till Inställningar, öppnar funktionen Inkommande säkerhetsregler och väljer sedan Lägg till.

  2. Välj sedan IP-adresser som 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 ingressscenarier

  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 slutpunkter. Skicka resultatet till Application Insights med hjälp av API:et TrackAvailability() i SDK-kärnpaketet.

TLS-konfigurationer som stöds

För att tillhandahålla förstklassig kryptering använder alla tillgänglighetstester Transport Layer Security (TLS) 1.2 och 1.3 som valfria krypteringsmekanismer. Dessutom stöds även följande chiffersviter och elliptiska kurvor i varje version.

TLS 1.3 är för närvarande endast tillgängligt i tillgänglighetstestregionerna NorthCentralUS, CentralUS, EastUS, SouthCentralUS och WestUS.

Version Chiffreringssviter Elliptiska kurvor
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
• 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

Inaktuell TLS-konfiguration

Viktigt!

Den 1 mars 2025 kommer TLS 1.0/1.1-protokollversioner och de listade TLS 1.2/1.3-äldre chiffersviterna och Elliptiska kurvorna att dras tillbaka för Application Insights-tillgänglighetstester.

TLS 1.0 och TLS 1.1

TLS 1.0 och TLS 1.1 dras tillbaka.

TLS 1.2 och TLS 1.3

Version Chiffreringssviter Elliptiska kurvor
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		 • kurva25519
TLS 1.3 • kurva25519

Felsökning

Varning

Vi har nyligen aktiverat TLS 1.3 i tillgänglighetstester. Om du ser nya felmeddelanden som ett resultat kontrollerar du att klienter som körs på Windows Server 2022 med TLS 1.3 aktiverat kan ansluta till slutpunkten. Om du inte kan göra detta kan du tillfälligt inaktivera TLS 1.3 på slutpunkten så att tillgänglighetstesterna återgår till äldre TLS-versioner.

Mer information finns i felsökningsartikeln.

Arbetsbok för driftstopp och avbrott

I det här avsnittet beskrivs ett enkelt sätt att beräkna och rapportera serviceavtal (SLA) för webbtester via en enda fönsterruta i dina Application Insights-resurser och Azure-prenumerationer. Rapporten om stilleståndstid och avbrott har kraftfulla fördefinierade frågor och datavisualiseringar som ger bättre förståelse för kundens anslutning, normala svarstider i appar och upplevda stilleståndstid.

Du kan komma åt SLA-arbetsboksmallen från Application Insights-resursen på två sätt:

  • Öppna tillgänglighetsupplevelsen och välj sedan SLA-rapport i det övre navigeringsfältet.

  • Öppna arbetsboken och välj sedan mallen Avbrott och avbrott.

Parameterflexitet

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

Skärmbild som visar parametrar.

  • Subscriptions, App Insights Resources, och Web Test: Dessa parametrar avgör dina resursalternativ på hög nivå. 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 den här parametern för att välja din vanliga underhållsfrekvens. Maintenance Window är en datetime-väljare för en exempelunderhållsperiod. Alla data som inträffar under den identifierade perioden ignoreras i dina resultat.
  • Availability Target %: Den här parametern anger målmålet och tar anpassade värden.

Översiktssidan

Översiktssidan innehåller information på hög nivå om din:

  • Totalt serviceavtal (exklusive underhållsperioder, om det definieras)
  • Instanser av avbrott från slutpunkt till slutpunkt
  • Programavbrott

Avbrottsinstanser bestäms från det ögonblick då ett test börjar misslyckas tills det lyckas 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 avbrott som inträffade under rapporteringsperioden.

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

Stilleståndstid, avbrott och fel

Det finns ytterligare två flikar bredvid sidan Översikt :

  • Fliken Avbrott och stilleståndstid innehåller information om totala avbrottsinstanser och total stilleståndstid uppdelad efter test.

  • Fliken Fel efter plats har en geo-karta över misslyckade testplatser för att identifiera potentiella problemanslutningsområden.

Andra funktioner

  • Anpassning: Du kan redigera rapporten på samma sätt som andra Azure Monitor-arbetsböcker och anpassa frågorna eller visualiseringarna baserat på teamets behov.

  • Log Analytics: Alla frågor kan köras i Log Analytics och användas i andra rapporter eller instrumentpaneler. Ta bort parameterbegränsningen och återanvänd kärnfrågan.

  • Åtkomst och delning: Rapporten kan delas med dina team och ditt ledarskap 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 lagras.

Vanliga frågor och svar

Det här avsnittet innehåller svar på vanliga frågor.

Allmänt

Kan jag köra tillgänglighetstester på en intranätserver?

Tillgänglighetstester körs på närvaropunkter som distribueras över hela världen. Det finns två lösningar:

  • Brandväggsdörr: Tillåt begäranden till servern från den långa och ändringsbara listan över webbtestagenter.
  • Anpassad kod: Skriv din egen kod för att skicka periodiska begäranden till servern inifrån intranätet. Du kan köra Visual Studio-webbtester för det här ändamålet. Testaren kan skicka resultatet till Application Insights med hjälp av API:et TrackAvailability() .

Vad är användaragentsträngen för tillgänglighetstester?

Användaragentsträngen är Mozilla/5.0 (kompatibel; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

TLS-support

Hur påverkar den här utfasningen mitt beteende för webbtest?

Tillgänglighetstester fungerar som en distribuerad klient på var och en av de webbtestplatser som stöds. Varje gång ett webbtest körs försöker tillgänglighetstesttjänsten nå ut till den fjärrslutpunkt som definierats i webbtestkonfigurationen. Ett hello-meddelande för TLS-klienten skickas som innehåller all TLS-konfiguration som stöds. Om fjärrslutpunkten delar en gemensam TLS-konfiguration med tillgänglighetstestklienten lyckas TLS-handskakningen. Annars misslyckas webbtestet med ett TLS-handskakningsfel.

Hur gör jag för att se till att webbtestet inte påverkas?

För att undvika påverkan interagerar varje fjärrslutpunkt (inklusive beroende begäranden) som ditt webbtest med behöver ha stöd för minst en kombination av samma protokollversion, chiffersvit och elliptisk kurva som tillgänglighetstestet gör. Om fjärrslutpunkten inte stöder den nödvändiga TLS-konfigurationen måste den uppdateras med stöd för någon kombination av ovanstående TLS-konfiguration efter utfasningen. Dessa slutpunkter kan identifieras genom att visa transaktionsinformation för ditt webbtest (helst för en lyckad webbtestkörning).

Hur gör jag för att verifiera vilken TLS-konfiguration en fjärrslutpunkt stöder?

Det finns flera tillgängliga verktyg för att testa vilken TLS-konfiguration som en slutpunkt stöder. Ett sätt är att följa exemplet som beskrivs på den här sidan. Om fjärrslutpunkten inte är tillgänglig via det offentliga Internet måste du kontrollera att du verifierar den TLS-konfiguration som stöds på fjärrslutpunkten från en dator som har åtkomst till att anropa slutpunkten.

Kommentar

För steg för att aktivera den nödvändiga TLS-konfigurationen på webbservern är det bäst att kontakta det team som äger den värdplattform som webbservern körs på om processen inte är känd.

Vad kommer webbtestbeteendet att vara för påverkade tester efter den 1 mars 2025?

Det finns ingen undantagstyp som alla TLS-handskakningsfel som påverkas av den här utfasningen skulle visa sig. Det vanligaste undantaget som webbtestet skulle börja misslyckas med är The request was aborted: Couldn't create SSL/TLS secure channeldock . Du bör också kunna se eventuella TLS-relaterade fel i felsökningssteget för TLS-transport för det webbtestresultat som kan påverkas.

Kan jag visa vilken TLS-konfiguration som för närvarande används av mitt webbtest?

Det går inte att visa TLS-konfigurationen som förhandlades under en webbtestkörning. Så länge fjärrslutpunkten stöder gemensam TLS-konfiguration med tillgänglighetstester bör ingen påverkan visas efter utfasningen.

Vilka komponenter påverkar utfasningen i tillgänglighetstesttjänsten?

TLS-utfasningen som beskrivs i det här dokumentet bör endast påverka körningsbeteendet för webbtest för tillgänglighetstest efter den 1 mars 2025. Mer information om hur du interagerar med tillgänglighetstesttjänsten för CRUD-åtgärder finns i Azure Resource Manager TLS-support. Den här resursen innehåller mer information om tidslinjer för TLS-stöd och utfasning.

Var kan jag få TLS-stöd?

Allmänna frågor om det äldre TLS-problemet finns i Lösa TLS-problem.

Nästa steg