Tillgänglighetstest för Application Insights
När du har distribuerat webbappen eller webbplatsen kan du konfigurera återkommande tester för att övervaka tillgänglighet och svarstider. Application Insights skickar webbbegäranden till ditt program med jämna mellanrum från platser runt om i världen. Den kan varna dig om programmet inte svarar eller svarar för långsamt. Du kan skapa upp till 100 tillgänglighetstester per Application Insights-resurs.
Tillgänglighetstester kräver inga ändringar av den webbplats som du testar och arbetar för någon HTTP- eller HTTPS-slutpunkt som är tillgänglig från det offentliga Internet. Du kan också testa tillgängligheten för ett REST-API som din tjänst är beroende av.
Kommentar
Tillgänglighetstester lagras krypterade enligt Azure-datakryptering i viloprinciper .
Typer av tillgänglighetstester
Det finns fyra typer av tillgänglighetstester:
Standardtest: Det här är 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, ochPOST), anpassade huvuden och anpassade data som är associerade med din HTTP-begäran.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.
(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-portalen 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
Dricks
Om du för närvarande använder andra tillgänglighetstester, till exempel URL-pingtester, kan du lägga till Standard-tester tillsammans med de andra. Om du vill använda Standard-tester i stället för ett av dina andra tester lägger du till ett Standard-test och tar bort det gamla testet.
Förutsättningar
Kom igång
Gå till Application Insights-resursen och välj fönstret Tillgänglighet .
Välj Lägg till standardtest.
Ange testnamn, URL och andra inställningar som beskrivs i följande tabell. Välj sedan Skapa.
Inställning beskrivning 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. Observera att vi endast parsar upp till 15 beroende begäranden. Aktivera återförsök När testet misslyckas testas 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. Valideringstest för SSL-certifikat 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. Anpassade rubriker Nyckelvärdepar som definierar driftparen. 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.
Framgångskriterier
| Inställning | beskrivning |
|---|---|
| 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 webbplatsen inte har tagits emot under den här perioden. Om du har valt Parsa beroende begäranden måste alla bilder, formatfiler, skript och andra beroende resurser ha tagits emot inom den här perioden. |
| HTTP-svar | Den returnerade statuskoden som räknas som en framgång. Talet 200 är den kod som anger att en normal webbsida har returnerats. |
| 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
| 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 pingtest för tillgänglighets-URL med hjälp av Azure Resource Manager.
Azure
| Visningsnamn | Befolkningsnamn |
|---|---|
| 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
| Visningsnamn | Befolkningsnamn |
|---|---|
| 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
| Visningsnamn | Befolkningsnamn |
|---|---|
| Kina, östra | mc-cne-azr |
| Östra Kina 2 | mc-cne2-azr |
| Kina, norra | mc-cnn-azr |
| Norra Kina 2 | mc-cnn2-azr |
Aktivera aviseringar
Aviseringar aktiveras nu automatiskt som standard, men om du vill konfigurera en avisering helt måste du först skapa ditt tillgänglighetstest.
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.
När du har sparat tillgänglighetstestet går du till fliken Information och väljer ellipsen efter det test du gjorde. Välj sidan Öppna regler (aviseringar).
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 som du har definierat inte är tillgänglig och 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 har konfigurerat 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.
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. 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.
Ändra aviseringsvillkoren
Om du vill göra ändringar i platströskelvärdet, aggregeringsperioden och testfrekvensen väljer du villkoret på redigeringssidan för aviseringsregeln 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:
Välj en Application Insights-resurs i måttmiljön och välj ett tillgänglighetsmått.
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
Det här avsnittet beskriver hur du granskar tillgänglighetstestresultaten i Azure-portalen 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 på fliken Tillgänglighet för application insights-resursen.
Vyn Punktdiagram visar 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. Hovra över någon av de gröna/röda punkterna för att se testet, testnamnet och platsen.
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 väljer du ellipserna bredvid ett testnamn. Det kan ta upp till 20 minuter innan konfigurationsändringar sprids till alla testagenter när en ändring har gjorts.
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
Välj en röd punkt.
Från ett tillgänglighetstestresultat kan du se transaktionsinformationen för alla komponenter. Här kan du:
- Granska felsökningsrapporten för att avgöra vad som kan ha orsakat att testet misslyckades, men programmet är fortfarande tillgängligt.
- 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.
- Logga ett problem eller ett arbetsobjekt i Git eller Azure Boards för att spåra problemet. Buggen innehåller en länk till den här händelsen.
- Ö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, beroenden med mera. Mer information om Log Analytics finns i Översikt över loggfrågor.
Migrera tillgänglighetstester
I den här artikeln vägleder vi dig genom migreringsprocessen från klassiska URL-pingtester till moderna och effektiva standardtester.
Vi förenklar den här processen genom att tillhandahålla tydliga stegvisa instruktioner för att säkerställa en smidig övergång och utrusta dina program med de senaste övervakningsfunktionerna.
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
- Alla URL-pingtest i Application Insights
- Azure PowerShell-åtkomst
Kom igång
Anslut till din prenumeration med Azure PowerShell (Connect-AzAccount + Set-AzContext).
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;Leta upp det URL-pingtest som du vill migrera och registrera dess resursgrupp och namn.
Följande kommandon skapar ett standardtest med samma logik som URL-pingtestet.
Kommentar
Följande kommandon fungerar för både HTTP- och HTTPS-slutpunkter, som används i dina URL-pingtester.
$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.
När du har verifierat funktionerna i det nya standardtestet uppdaterar du aviseringsreglerna som refererar till URL-pingtestet för att referera till standardtestet i stället. Sedan inaktiverar eller tar du bort URL-pingtestet.
Om du vill ta bort ett URL-pingtest 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 rubriker i standardtillgänglighetstester för att verifiera trafik.
Generera en token eller GUID för att identifiera trafik från dina tillgänglighetstester.
Lägg till det anpassade huvudet "X-Customer-InstanceId" med värdet
ApplicationInsightsAvailability:<GUID generated in step 1>under avsnittet "Standardtestinformation" när du skapar eller uppdaterar dina tillgänglighetstester.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 token som en frågeparameter. Exempel: https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your guid>
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
ApplicationInsightsAvailabilitygäller för alla tillgänglighetstester.Om du använder Azure-nätverkssäkerhetsgrupper går du till nätverkssäkerhetsgruppens resurs och under Inställningar väljer du inkommande säkerhetsregler. Välj Lägg till.
Välj sedan Tjänsttagg som källa och välj 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.
I nätverkssäkerhetsgruppens resurs går du till Inställningar och väljer inkommande säkerhetsregler. Välj Lägg till.
Välj sedan IP-adresser som källa. Lägg sedan till dina IP-adresser i en kommaavgränsad lista i källans IP-adress/CIRD-intervall.
Frånkopplade eller inga ingressscenarier
Anslut din Application Insights-resurs till din interna tjänstslutpunkt med Hjälp av Azure Private Link.
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.
Kommentar
TLS 1.3 är för närvarande endast tillgängligt i tillgänglighetstestregionerna NorthCentralUS, CentralUS, EastUS, SouthCentralUS och WestUS.
TLS 1.2
Chiffersviter
- 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
Elliptiska kurvor
- NistP384
- NistP256
TLS 1.3
Chiffersviter
- TLS_AES_256_GCM_SHA384
- TLS_AES_128_GCM_SHA256
Elliptiska kurvor:
- NistP384
- NistP256
Inaktuell TLS-konfiguration
Varning
Den 31 oktober 2024 dras TLS 1.0/1.1-protokollversioner och nedanstående TLS 1.2/1.3 äldre chiffersviter och elliptiska kurvor tillbaka för Application Insights-tillgänglighetstester.
TLS 1.0 och TLS 1.1
Protokollversioner stöds inte längre.
TLS 1.2
Chiffersviter
- 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
Elliptiska kurvor:
- curve25519
TLS 1.3
Elliptiska kurvor
- curve25519
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.
Se den dedikerade felsökningsartikeln.
Arbetsbok för stilleståndstid, serviceavtal och avbrott
Den här artikeln beskriver 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 fönstret Tillgänglighet och välj sedan SLA-rapport överst på skärmen.
Öppna fönstret Arbetsböcker och välj sedan Stilleståndstid och avbrott.
Parameterflexitet
Parametrarna som anges i arbetsboken påverkar resten av rapporten.
Subscriptions,App Insights Resources, ochWeb 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 ThresholdochOutage 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 definieras av när ett test börjar misslyckas tills det lyckas, baserat på 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
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.
Redigera rapporten
Du kan redigera rapporten precis som andra Azure Monitor-arbetsböcker.
Du kan anpassa frågorna eller visualiseringarna baserat på teamets behov.
Log Analytics
Frågorna kan alla 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 måste ha läsbehörighet/å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?
Våra webbtester 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 ser jag 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 verifierar jag 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 31 oktober 2024?
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 31 oktober 2024. 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
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för