Tillgänglighetstest för Application Insights

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.

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.

Skapa ett tillgänglighetstest

Tillgänglighetsaviseringar

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

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.

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

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 .

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.

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.

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.

Om du ser fel

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

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.

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.

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.

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.

   

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

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.

Inaktuell TLS-konfiguration

TLS 1.0 och TLS 1.1

TLS 1.0 och TLS 1.1 dras tillbaka.

TLS 1.2 och TLS 1.3

Felsökning

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.

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

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

• Felsökning
• Webbtestar Azure Resource Manager-mall
• REST API för webbtest