Share via

Beschikbaarheidstests voor Application Insights

  • Artikel

Met Application Insights kunt u terugkerende webtests instellen die de beschikbaarheid en reactiesnelheid van uw website of toepassing bewaken vanaf verschillende punten over de hele wereld. Deze beschikbaarheidstests verzenden regelmatig webaanvragen naar uw toepassing en waarschuwen u als uw toepassing niet reageert of als de reactietijd te traag is.

Voor beschikbaarheidstests zijn geen wijzigingen in de website of toepassing vereist die u test. Ze werken voor elk HTTP- of HTTPS-eindpunt dat toegankelijk is via het openbare internet, inclusief REST API's waarvan uw service afhankelijk is. Dit betekent dat u niet alleen uw eigen toepassingen, maar ook externe services kunt bewaken die essentieel zijn voor de functionaliteit van uw toepassing. U kunt maximaal 100 beschikbaarheidstests per Application Insights-resource maken.

Notitie

Beschikbaarheidstests worden versleuteld opgeslagen volgens azure-beleid voor data-at-rest .

Typen beschikbaarheidstests

Er zijn vier typen beschikbaarheidstests:

  • Standaardtest: een type beschikbaarheidstest waarmee de beschikbaarheid van een website wordt gecontroleerd door één aanvraag te verzenden, vergelijkbaar met de afgeschafte URL-pingtest. Naast het valideren of een eindpunt reageert en de prestaties meet, bevatten standaardtests ook geldigheid van TLS/SSL-certificaten, proactieve levensduurcontrole, HTTP-aanvraagwoord (bijvoorbeeld GET,HEAD en POST), aangepaste headers en aangepaste gegevens die zijn gekoppeld aan uw HTTP-aanvraag.

    Meer informatie over het maken van een standaardtest.

  • Custom TrackAvailability-test: als u besluit een aangepaste toepassing te maken om beschikbaarheidstests uit te voeren, kunt u de methode TrackAvailability() gebruiken om de resultaten naar Application Insights te verzenden.

    Leer hoe u een aangepaste TrackAvailability-test maakt.

  • (Afgeschaft) Webtest met meerdere stappen: u kunt deze opname van een reeks webaanvragen afspelen om complexere scenario's te testen. Webtests met meerdere stappen worden gemaakt in Visual Studio Enterprise en geüpload naar de portal, waar u ze kunt uitvoeren.

  • (Afgeschaft) URL-pingtest: u kunt deze test maken via Azure Portal om te controleren of een eindpunt reageert en de prestaties meet die aan dat antwoord zijn gekoppeld. U kunt ook aangepaste succescriteria instellen in combinatie met geavanceerdere functies, zoals het parseren van afhankelijke aanvragen en het toestaan van nieuwe pogingen.

Belangrijk

Er zijn twee toekomstige beschikbaarheidstests buiten gebruik gesteld:

  • Webtests met meerdere stappen: op 31 augustus 2024 worden webtests met meerdere stappen in Application Insights buiten gebruik gesteld. We adviseren gebruikers van deze tests om over te stappen op alternatieve beschikbaarheidstests vóór de buitengebruikstellingsdatum. Na deze datum nemen we de onderliggende infrastructuur op, waardoor de resterende tests met meerdere stappen worden verbroken.

  • URL-pingtests: Op 30 september 2026 worden URL-pingtests in Application Insights buiten gebruik gesteld. Bestaande URL-pingtests worden verwijderd uit uw resources. Bekijk de prijzen voor standaardtests en overgang naar het gebruik ervan vóór 30 september 2026 om ervoor te zorgen dat u beschikbaarheidstests met één stap kunt blijven uitvoeren in uw Application Insights-resources.

Een beschikbaarheidstest maken

Vereisten

Aan de slag

  1. Ga naar uw Application Insights-resource en open de beschikbaarheidservaring .

  2. Selecteer Standaardtest toevoegen in de bovenste navigatiebalk.

    Schermopname van de beschikbaarheidservaring met het tabblad Standaard toevoegen geopend.

  3. Voer uw testnaam, URL en andere instellingen in die worden beschreven in de volgende tabel en selecteer Vervolgens Maken.

    Sectie Instelling Beschrijving
    Algemene informatie
    URL De URL kan elke webpagina zijn die u wilt testen, maar moet zichtbaar zijn via het openbare internet. De URL kan een queryreeks bevatten. Zo kunt u bijvoorbeeld oefenen met uw database. Als de URL naar een omleiding is opgelost, kunnen we deze tot maximaal 10 omleidingen opvolgen.
    Afhankelijke aanvragen parseren Test aanvragen voor afbeeldingen, scripts, stijlbestanden en andere bestanden die deel uitmaken van de webpagina die worden getest. De opgenomen reactietijd is inclusief de tijd die nodig is om deze bestanden op te halen. De test mislukt als een van deze resources niet kan worden gedownload binnen de time-out voor de hele test. Als de optie niet is geselecteerd, vraagt de test alleen het bestand aan bij de URL die u hebt opgegeven. Het inschakelen van deze optie resulteert in een strengere controle. De test kan mislukken voor gevallen die mogelijk niet merkbaar zijn wanneer u handmatig door de site bladert. We parseren slechts 15 afhankelijke aanvragen.
    Nieuwe pogingen inschakelen voor fouten met beschikbaarheidstests Wanneer de test mislukt, wordt er na een kort interval opnieuw geprobeerd. Fouten worden pas gerapporteerd als er drie opeenvolgende pogingen mislukken. Daaropvolgende tests worden vervolgens met de gebruikelijke testfrequentie uitgevoerd. Volgende pogingen worden tijdelijk uitgesteld tot er weer een test slaagt. Deze regel wordt onafhankelijk toegepast op elke testlocatie. We raden deze optie aan. Gemiddeld verdwijnt ongeveer 80% van de fouten na het opnieuw proberen.
    Geldigheid van SSL-certificaat inschakelen U kunt het SSL-certificaat op uw website controleren om ervoor te zorgen dat het correct is geïnstalleerd, geldig, vertrouwd en geen fouten geeft aan een van uw gebruikers.
    Proactieve levensduurcontrole Met deze instelling kunt u een ingestelde periode definiëren voordat uw SSL-certificaat verloopt. Nadat de test is verlopen, mislukt de test.
    Testfrequentie Hiermee stelt u in hoe vaak de test wordt uitgevoerd vanaf elke testlocatie. Met een standaardfrequentie van vijf minuten en vijf testlocaties wordt uw site gemiddeld per minuut getest.
    Testlocaties Onze servers verzenden webaanvragen naar uw URL vanaf deze locaties. Ons minimum aantal aanbevolen testlocaties is vijf om ervoor te zorgen dat u problemen op uw website van netwerkproblemen kunt onderscheiden. U kunt maximaal 16 locaties selecteren.
    Standaardtestgegevens
    HTTP-aanvraagwoord Geef aan welke actie u wilt uitvoeren met uw aanvraag.
    Aanvraagbody Aangepaste gegevens die zijn gekoppeld aan uw HTTP-aanvraag. U kunt uw eigen bestanden uploaden, uw inhoud invoeren of deze functie uitschakelen.
    Aangepaste headers toevoegen Sleutel-waardeparen die de operationele parameters definiëren.
    Succescriteria
    Time-out testen Verlaag deze waarde om te worden gewaarschuwd voor trage reacties. De test wordt geteld als een fout als de antwoorden van uw site niet binnen deze periode worden ontvangen. Als u afhankelijke aanvragen parseert, moeten alle afbeeldingen, stijlbestanden, scripts en andere afhankelijke resources binnen deze periode worden ontvangen.
    HTTP-antwoord De geretourneerde statuscode is geteld als geslaagd. Het getal 200 is de code die aangeeft dat een normale webpagina wordt geretourneerd.
    Inhoudsovereenkomst Een tekenreeks, zoals 'Welkom!' We testen of er in elk antwoord een exacte hoofdlettergevoelige overeenkomst optreedt. Het moet een eenvoudige tekenreeks zijn, zonder jokertekens. Vergeet niet dat als uw pagina-inhoud verandert, u deze mogelijk moet bijwerken. Alleen Engelse tekens worden ondersteund met inhoudsovereenkomst.

Beschikbaarheidswaarschuwingen

Waarschuwingen worden standaard automatisch ingeschakeld, maar als u een waarschuwing volledig wilt configureren, moet u eerst uw beschikbaarheidstest maken.

Instelling Beschrijving
Bijna realtime We raden u aan bijna realtime waarschuwingen te gebruiken. Het configureren van dit type waarschuwing wordt uitgevoerd nadat uw beschikbaarheidstest is gemaakt.
Drempelwaarde voor waarschuwingslocatie We raden minimaal 3/5 locaties aan. De optimale relatie tussen de drempelwaarde voor waarschuwingslocatie en het aantal testlocaties is de drempelwaarde = voor de waarschuwingslocatie van testlocaties - 2, met minimaal vijf testlocaties.

Tags voor locatiepopulatie

U kunt de volgende populatietags gebruiken voor het kenmerk geolocatie wanneer u een standaardtest of URL-pingtest implementeert met behulp van Azure Resource Manager.

Provider Weergavenaam Naam van populatie
Azure
Australië - oost emea-au-syd-edge
Brazilië - zuid latam-br-gru-edge
Central US us-fl-mia-edge
Azië - oost apac-hk-hkn-azr
VS - oost us-va-ash-azr
Frankrijk - zuid (voorheen Frankrijk - centraal) emea-ch-zrh-edge
Frankrijk - centraal emea-fr-pra-edge
Japan East apac-jp-kaw-edge
Europa - noord emea-gb-db3-azr
VS - noord-centraal us-il-ch1-azr
VS - zuid-centraal us-tx-sn1-azr
Azië - zuidoost apac-sg-sin-azr
Verenigd Koninkrijk West emea-se-sto-edge
Europa -west emea-nl-ams-azr
VS - west us-ca-sjc-azr
Verenigd Koninkrijk Zuid emea-ru-msa-edge
Azure Government
USGov Virginia usgov-va-azr
US Gov - Arizona usgov-phx-azr
USGov Texas usgov-tx-azr
USDoD - oost usgov-ddeast-azr
USDoD - centraal usgov-ddcentral-azr
Microsoft Azure beheerd door 21Vianet
China - oost mc-cne-azr
China - oost 2 mc-cne2-azr
China - noord mc-cnn-azr
China - noord 2 mc-cnn2-azr

Waarschuwingen inschakelen

Notitie

Met de nieuwe geïntegreerde waarschuwingen moeten de ernst van de waarschuwingsregel en de voorkeuren voor meldingen met actiegroepenworden geconfigureerd in de ervaring met waarschuwingen. Zonder de volgende stappen ontvangt u alleen meldingen in de portal.

  1. Nadat u de beschikbaarheidstest hebt opgeslagen, opent u het contextmenu door de test die u hebt gemaakt en selecteert u vervolgens de pagina Regels openen (waarschuwingen).

    Schermopname van de beschikbaarheidservaring voor een Application Insights-resource in Azure Portal en de menuoptie Open Rules (Waarschuwingen).

  2. Open uw waarschuwing op de pagina Waarschuwingsregels en selecteer Bewerken in de bovenste navigatiebalk. Hier kunt u het ernstniveau, de regelbeschrijving en de actiegroep instellen met de meldingsvoorkeuren die u voor deze waarschuwingsregel wilt gebruiken.

    Schermopname van een waarschuwingsregelpagina in Azure Portal met Bewerken gemarkeerd.

Waarschuwingscriteria

Beschikbaarheidswaarschuwingen automatisch inschakelen één e-mail wanneer het eindpunt niet meer beschikbaar is en een andere e-mail wanneer het weer beschikbaar is. Beschikbaarheidswaarschuwingen die via deze ervaring worden gemaakt, zijn gebaseerd op statussen. Wanneer aan de waarschuwingscriteria wordt voldaan, wordt één waarschuwing gegenereerd wanneer de website wordt gedetecteerd als niet beschikbaar. Als de website nog steeds niet beschikbaar is wanneer de waarschuwingscriteria de volgende keer worden geëvalueerd, wordt er geen nieuwe waarschuwing gegenereerd.

Stel dat uw website een uur niet beschikbaar is en u een e-mailwaarschuwing instelt met een evaluatiefrequentie van 15 minuten. U ontvangt alleen een e-mailbericht wanneer de website uitvalt en een ander e-mailbericht wanneer deze weer online is. U ontvangt niet elke 15 minuten doorlopende waarschuwingen om u eraan te herinneren dat de website nog steeds niet beschikbaar is.

De waarschuwingscriteria wijzigen

Mogelijk wilt u geen meldingen ontvangen wanneer uw website slechts een korte periode offline is, bijvoorbeeld tijdens onderhoud. U kunt de evaluatiefrequentie wijzigen in een hogere waarde dan de verwachte downtime, tot 15 minuten. U kunt ook de drempelwaarde voor de waarschuwingslocatie verhogen, zodat er alleen een waarschuwing wordt geactiveerd als de website voor een bepaald aantal regio's uitvalt.

Tip

Voor langere geplande downtime moet u de waarschuwingsregel tijdelijk deactiveren of een aangepaste regel maken. Het biedt u meer opties om rekening te houden met de downtime.

Als u wijzigingen wilt aanbrengen in de locatiedrempel, aggregatieperiode en testfrequentie, gaat u naar de pagina Waarschuwingsregel bewerken (zie stap 2 onder Waarschuwingen inschakelen) en selecteert u vervolgens de voorwaarde om het venster Signaallogica configureren te openen.

Schermopname van een gemarkeerde waarschuwingsvoorwaarde en het venster Signaallogica configureren.

Een aangepaste waarschuwingsregel maken

Als u geavanceerde mogelijkheden nodig hebt, kunt u een aangepaste waarschuwingsregel maken op het tabblad Waarschuwingen. Selecteer Waarschuwingsregel maken>. Kies Metrische gegevens voor signaaltype om alle beschikbare signalen weer te geven en beschikbaarheid te selecteren.

Een aangepaste waarschuwingsregel biedt hogere waarden voor de aggregatieperiode (maximaal 24 uur in plaats van 6 uur) en de testfrequentie (maximaal 1 uur in plaats van 15 minuten). Er worden ook opties toegevoegd om de logica verder te definiëren door verschillende operators, aggregatietypen en drempelwaarden te selecteren.

  • Waarschuwing op X van de Y-locaties rapporteert fouten: de waarschuwingsregel X van de Y-locaties is standaard ingeschakeld in de nieuwe uniforme waarschuwingservaring wanneer u een nieuwe beschikbaarheidstest maakt. U kunt zich afmelden door de optie Klassiek te selecteren of door de waarschuwingsregel uit te schakelen. Configureer de actiegroepen om meldingen te ontvangen wanneer de waarschuwing wordt geactiveerd door de voorgaande stappen te volgen. Zonder deze stap ontvangt u alleen meldingen in de portal wanneer de regel wordt geactiveerd.

  • Waarschuwing over metrische gegevens over beschikbaarheid: Met behulp van de nieuwe geïntegreerde waarschuwingen kunt u ook waarschuwingen ontvangen over gesegmenteerde cumulatieve beschikbaarheid en metrische testduurgegevens:

    1. Selecteer een Application Insights-resource in de ervaring met metrische gegevens en selecteer een metrische gegevens over beschikbaarheid .

    2. Met de optie Waarschuwingen configureren in het menu gaat u naar de nieuwe ervaring waar u specifieke tests of locaties kunt selecteren waarop u waarschuwingsregels kunt instellen. U kunt hier ook de actiegroepen voor deze waarschuwingsregel configureren.

  • Waarschuwing voor aangepaste analysequery's: Met behulp van de nieuwe geïntegreerde waarschuwingen kunt u een waarschuwing ontvangen voor aangepaste logboekquery's. Met aangepaste query's kunt u een waarschuwing geven over willekeurige voorwaarden waarmee u het meest betrouwbare signaal van beschikbaarheidsproblemen krijgt. Dit is ook van toepassing als u aangepaste beschikbaarheidsresultaten verzendt met behulp van de TrackAvailability SDK.

    De metrische gegevens over beschikbaarheidsgegevens bevatten eventuele aangepaste beschikbaarheidsresultaten die u mogelijk verzendt door de TrackAvailability SDK aan te roepen. U kunt de waarschuwingen voor de ondersteuning voor metrische gegevens gebruiken om te waarschuwen voor aangepaste beschikbaarheidsresultaten.

Waarschuwingen automatiseren

Zie Een metrische waarschuwing maken met een Azure Resource Manager-sjabloon om dit proces te automatiseren met Azure Resource Manager-sjablonen.

De resultaten van uw beschikbaarheidstest bekijken

In deze sectie wordt uitgelegd hoe u de resultaten van de beschikbaarheidstest controleert in Azure Portal en hoe u een query uitvoert op de gegevens met behulp van Log Analytics. Resultaten van beschikbaarheidstests kunnen worden gevisualiseerd met weergaven lijndiagram en spreidingsplot .

Beschikbaarheid controleren

Bekijk eerst de grafiek in de beschikbaarheidservaring in Azure Portal.

Schermopname van de grafiek beschikbaarheidservaring, waarbij de wisselknop tussen lijn- en spreidingsplot wordt gemarkeerd.

Standaard wordt in de beschikbaarheidservaring een lijngrafiek weergegeven. Wijzig de weergave in Spreidingsplot (wisselknop boven de grafiek) om voorbeelden te zien van de testresultaten met daarin diagnostische teststappen. De testengine slaat diagnostische gegevens op voor tests met fouten. Bij geslaagde tests wordt diagnostische informatie voor een subset van de uitvoeringen opgeslagen. Als u de test, testnaam en locatie wilt zien, plaatst u de muisaanwijzer op een van de groene stippen of rode kruisen.

Selecteer een bepaalde test of locatie. Of u kunt de periode verminderen om meer resultaten te zien rond de periode van interesse. Gebruik Search Explorer om resultaten van alle uitvoeringen te bekijken. U kunt ook Log Analytics-query's gebruiken om aangepaste rapporten op deze gegevens uit te voeren.

Als u de details van de end-to-end-transactie wilt zien, selecteert u geslaagd of mislukt onder Inzoomen. Selecteer vervolgens een voorbeeld. U kunt ook naar de end-to-end transactiedetails gaan door een gegevenspunt in de grafiek te selecteren.

Schermopname van het selecteren van een voorbeeld van een beschikbaarheidstest.

Tests controleren en bewerken

Als u een test wilt bewerken, tijdelijk wilt uitschakelen of verwijderen, opent u het contextmenu (beletselteken) door de test en selecteert u Bewerken. Het kan tot 20 minuten duren voordat configuratiewijzigingen zijn doorgegeven aan alle testagents nadat een wijziging is aangebracht.

Tip

Mogelijk wilt u beschikbaarheidstests of de waarschuwingsregels die eraan zijn gekoppeld uitschakelen terwijl u onderhoud uitvoert op uw service.

Als u mislukte tests ziet

Open de detailweergave voor end-to-end transacties door een rood kruis op het spreidingsplot te selecteren.

Schermopname van het tabblad End-to-end transactiedetails.

Hier kunt u het volgende doen:

  • Bekijk het rapport Probleemoplossing om te bepalen wat uw test mogelijk heeft veroorzaakt.
  • De reactie inspecteren die is ontvangen van uw server.
  • Diagnose van fouten met gecorreleerde telemetrie aan de serverzijde die wordt verzameld tijdens het verwerken van de mislukte beschikbaarheidstest.
  • Houd het probleem bij door een probleem of werkitem te registreren in Git of Azure Boards. De fout bevat een koppeling naar de gebeurtenis in Azure Portal.
  • Het webtestresultaat openen in Visual Studio.

Zie de documentatie over transactiediagnose voor meer informatie over de end-to-end transactiediagnose.

Selecteer de uitzonderingsrij om de details te zien van de uitzondering aan de serverzijde waardoor de synthetische beschikbaarheidstest is mislukt. U kunt ook de momentopname voor foutopsporing ophalen voor uitgebreidere diagnostische gegevens op codeniveau.

Naast de onbewerkte resultaten kunt u ook twee belangrijke metrische gegevens over beschikbaarheid bekijken in Metrics Explorer:

  • Beschikbaarheid: Percentage van de tests die zijn geslaagd voor alle testuitvoeringen.
  • Testduur: gemiddelde testduur voor alle testuitvoeringen.

Query in Log Analytics

U kunt Log Analytics gebruiken om uw beschikbaarheidsresultaten (availabilityResults), afhankelijkheden (dependencies) en meer weer te geven. Zie het overzicht van logquery's voor meer informatie over Log Analytics.

Schermopname van beschikbaarheidsresultaten in Logboeken.

Klassieke URL-pingtests migreren naar standaardtests

Met de volgende stappen doorloopt u het proces voor het maken van standaardtests waarmee de functionaliteit van uw URL-pingtests wordt gerepliceerd. Hiermee kunt u eenvoudiger de geavanceerde functies van standaardtests gebruiken met behulp van uw eerder gemaakte URL-pingtests.

Belangrijk

Er worden kosten verbonden aan het uitvoeren van standaardtests. Zodra u een standaardtest hebt gemaakt, worden er kosten in rekening gebracht voor testuitvoeringen. Raadpleeg de prijzen van Azure Monitor voordat u dit proces start.

Vereisten

Aan de slag

  1. Maak verbinding met uw abonnement met Azure PowerShell (Connect-AzAccount + Set-AzContext).

  2. Alle URL-pingtests in het huidige abonnement weergeven:

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

  3. Zoek de URL-pingtest die u wilt migreren en noteer de resourcegroep en naam.

  4. Maak een standaardtest met dezelfde logica als de URL-pingtest met behulp van de volgende opdrachten, die werken voor zowel HTTP- als HTTPS-eindpunten.

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

    De nieuwe standaardtest bevat standaard geen waarschuwingsregels, dus er worden geen luidruchtige waarschuwingen gemaakt. Er worden geen wijzigingen aangebracht in uw URL-pingtest, zodat u erop kunt blijven vertrouwen voor waarschuwingen.

  5. Valideer de functionaliteit van de nieuwe standaardtest en werk vervolgens uw waarschuwingsregels bij die verwijzen naar de URL-pingtest om in plaats daarvan te verwijzen naar de standaardtest.

  6. Schakel de URL-pingtest uit of verwijder deze. Als u dit wilt doen met Azure PowerShell, kunt u deze opdracht gebruiken:

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

Testen achter een firewall

Als u de beschikbaarheid van eindpunten achter firewalls wilt garanderen, schakelt u openbare beschikbaarheidstests in of voert u beschikbaarheidstests uit in niet-verbonden of geen toegangsbeheerobjectscenario's.

Inschakeling van openbare beschikbaarheidstest

Zorg ervoor dat uw interne website een openbare DNS-record (Domain Name System) heeft. Beschikbaarheidstests mislukken als DNS niet kan worden omgezet. Zie Een aangepaste domeinnaam maken voor een interne toepassing voor meer informatie.

Waarschuwing

De IP-adressen die door de service voor beschikbaarheidstests worden gebruikt, worden gedeeld en kunnen uw met firewall beveiligde service-eindpunten beschikbaar maken voor andere tests. Het filteren van IP-adressen alleen beveiligt het verkeer van uw service niet, dus het is raadzaam om extra aangepaste headers toe te voegen om de oorsprong van de webaanvraag te controleren. Zie Servicetags voor virtuele netwerken voor meer informatie.

Verkeer verifiëren

Stel aangepaste headers in standaardtests in om verkeer te valideren.

  1. Maak een alfanumerieke tekenreeks zonder spaties om deze beschikbaarheidstest te identificeren (bijvoorbeeld MyAppAvailabilityTest). Van hieruit verwijzen we naar deze tekenreeks als de id van de beschikbaarheidstesttekenreeks.

  2. Voeg de aangepaste header X-Customer-InstanceId toe met de waarde ApplicationInsightsAvailability:<your availability test string identifier> in de sectie Standaardtestgegevens bij het maken of bijwerken van uw beschikbaarheidstests.

    Schermopname van aangepaste validatieheader.

  3. Zorg ervoor dat uw service controleert of binnenkomend verkeer de header en waarde bevat die in de vorige stappen zijn gedefinieerd.

U kunt ook de tekenreeks-id van de beschikbaarheidstest instellen als een queryparameter.

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

Uw firewall configureren om binnenkomende aanvragen van beschikbaarheidstests toe te laten

Notitie

Dit voorbeeld is specifiek voor het gebruik van servicetags voor netwerkbeveiligingsgroepen. Veel Azure-services accepteren servicetags, die elk verschillende configuratiestappen vereisen.

Gebruik servicetags om het inschakelen van Azure-services te vereenvoudigen zonder afzonderlijke IP-adressen te autoriseren of een up-to-date IP-lijst te onderhouden. Pas deze tags toe in Azure Firewall- en netwerkbeveiligingsgroepen, zodat de beschikbaarheidstestservice toegang heeft tot uw eindpunten. De servicetag ApplicationInsightsAvailability is van toepassing op alle beschikbaarheidstests.

  1. Als u Azure-netwerkbeveiligingsgroepen gebruikt, gaat u naar de resource van uw netwerkbeveiligingsgroep en opent u onder Instellingen de ervaring voor binnenkomende beveiligingsregels en selecteert u Vervolgens Toevoegen.

  2. Selecteer vervolgens Servicetag als bron- en ApplicationInsightsAvailability als de bronservicetag. Gebruik open poorten 80 (http) en 443 (https) voor binnenkomend verkeer van de servicetag.

Als u de toegang wilt beheren wanneer uw eindpunten zich buiten Azure bevinden of wanneer servicetags geen optie zijn, staat u de IP-adressen van onze webtestagents toe. U kunt query's uitvoeren op IP-bereiken met behulp van PowerShell, Azure CLI of een REST-aanroep met de Service Tag-API. Download het JSON-bestand voor een uitgebreide lijst met huidige servicetags en hun IP-gegevens.

  1. Open in de resource van uw netwerkbeveiligingsgroep onder Instellingen de ervaring voor binnenkomende beveiligingsregels en selecteer vervolgens Toevoegen.

  2. Selecteer vervolgens IP-adressen als bron. Voeg vervolgens uw IP-adressen toe in een door komma's gescheiden lijst in bron-IP-adres-/CIRD-bereiken.

Niet-verbonden of geen toegangsbeheerscenario's

  1. Verbind uw Application Insights-resource met uw interne service-eindpunt met behulp van Azure Private Link.

  2. Schrijf aangepaste code om uw interne server of eindpunten periodiek te testen. Verzend de resultaten naar Application Insights met behulp van de TrackAvailability() API in het kern-SDK-pakket.

Ondersteunde TLS-configuraties

Alle beschikbaarheidstests gebruiken Transport Layer Security (TLS) 1.2 en 1.3 als de gewenste versleutelingsmechanismen om de beste versleutelingstests te bieden. Daarnaast worden de volgende coderingssuites en elliptische curven ook ondersteund binnen elke versie.

TLS 1.3 is momenteel alleen beschikbaar in de beschikbaarheidstestregio's NorthCentralUS, CentralUS, EastUS, SouthCentralUS en WestUS.

Versie Coderingssuites Elliptische curven
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

TLS-configuratie wordt afgeschaft

Belangrijk

Op 1 maart 2025, in overeenstemming met de verouderde TLS-buitengebruikstelling van Azure, worden tls 1.0/1.1-protocolversies en de vermelde verouderde TLS 1.2/1.3-coderingssuites en elliptische curven buiten gebruik gesteld voor Application Insights-beschikbaarheidstests.

TLS 1.0 en TLS 1.1

TLS 1.0 en TLS 1.1 worden buiten gebruik gesteld.

TLS 1.2 en TLS 1.3

Versie Coderingssuites Elliptische curven
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		 • curve25519
TLS 1.3 • curve25519

Probleemoplossing

Waarschuwing

Tls 1.3 is onlangs ingeschakeld in beschikbaarheidstests. Als u als gevolg hiervan nieuwe foutberichten ziet, moet u ervoor zorgen dat clients die worden uitgevoerd op Windows Server 2022 waarvoor TLS 1.3 is ingeschakeld, verbinding kunnen maken met uw eindpunt. Als u dit niet kunt doen, kunt u overwegen TLS 1.3 tijdelijk uit te schakelen op uw eindpunt, zodat beschikbaarheidstests terugvallen op oudere TLS-versies.

Raadpleeg het artikel over probleemoplossing voor meer informatie.

Werkmap downtime en storingen

In deze sectie wordt een eenvoudige manier geïntroduceerd om service level agreement (SLA) te berekenen en te rapporteren voor webtests via één deelvenster glas voor uw Application Insights-resources en Azure-abonnementen. Het rapport Downtime en storing biedt krachtige vooraf gebouwde query's en gegevensvisualisaties om uw inzicht te krijgen in de connectiviteit van uw klant, de typische reactietijd van de toepassing en de downtime.

De SLA-werkmapsjabloon kan op twee manieren worden geopend vanuit uw Application Insights-resource:

  • Open de beschikbaarheidservaring en selecteer vervolgens SLA-rapport in de bovenste navigatiebalk.

  • Open de werkmapervaring en selecteer vervolgens de sjabloon Downtime & Storingen.

Flexibiliteit van parameters

De parameters die in de werkmap zijn ingesteld, zijn van invloed op de rest van het rapport.

Schermopname met parameters.

  • Subscriptions, App Insights Resourcesen Web Test: Deze parameters bepalen uw resourceopties op hoog niveau. Ze zijn gebaseerd op Log Analytics-query's en worden gebruikt in elke rapportquery.
  • Failure Threshold en Outage Window: U kunt deze parameters gebruiken om uw eigen criteria voor een servicestoring te bepalen. Een voorbeeld hiervan zijn de criteria voor een Application Insights-beschikbaarheidswaarschuwing op basis van een mislukte locatiemeteritem gedurende een gekozen periode. De gebruikelijke drempelwaarde is drie locaties gedurende een venster van vijf minuten.
  • Maintenance Period: U kunt deze parameter gebruiken om uw typische onderhoudsfrequentie te selecteren. Maintenance Window is een datum/tijd-selector voor een voorbeeldonderhoudsperiode. Alle gegevens die zich tijdens de geïdentificeerde periode voordoen, worden genegeerd in uw resultaten.
  • Availability Target %: Met deze parameter geeft u uw doeldoelstelling op en worden aangepaste waarden gebruikt.

Overzichtspagina

De overzichtspagina bevat algemene informatie over uw:

  • Totale SLA (exclusief onderhoudsperioden, indien gedefinieerd)
  • End-to-end-storingsexemplaren
  • Uitvaltijd van toepassingen

Storingsexemplaren worden vastgesteld vanaf het moment dat een test begint te mislukken totdat deze opnieuw is geslaagd, volgens uw storingsparameters. Als een test om 8:00 uur mislukt en opnieuw om 10:00 uur slaagt, wordt die hele periode van gegevens beschouwd als dezelfde storing. U kunt ook de langste storing onderzoeken die is opgetreden tijdens uw rapportageperiode.

Sommige tests kunnen worden gekoppeld aan hun Application Insights-resource voor verder onderzoek. Maar dat is alleen mogelijk in de Application Insights-resource op basis van een werkruimte.

Downtime, storingen en storingen

Er zijn nog twee tabbladen naast de pagina Overzicht :

  • Het tabblad Storingen en downtime bevat informatie over het totale aantal storingen en de totale downtime die per test is uitgesplitst.

  • Het tabblad Fouten per locatie bevat een geo-kaart met mislukte testlocaties om mogelijke probleemverbindingsgebieden te identificeren.

Andere functies

  • Aanpassing: U kunt het rapport bewerken zoals elke andere Azure Monitor-werkmap en de query's of visualisaties aanpassen op basis van de behoeften van uw team.

  • Log Analytics: De query's kunnen allemaal worden uitgevoerd in Log Analytics en worden gebruikt in andere rapporten of dashboards. Verwijder de parameterbeperking en hergebruik de kernquery.

  • Toegang en delen: het rapport kan worden gedeeld met uw teams en leidinggevenden of worden vastgemaakt aan een dashboard voor verder gebruik. De gebruiker heeft leesmachtigingen en toegang nodig tot de Application Insights-resource waarin de werkelijke werkmap is opgeslagen.

Veelgestelde vragen

In deze sectie vindt u antwoorden op veelgestelde vragen.

Algemeen

Kan ik beschikbaarheidstests uitvoeren op een intranetserver?

Beschikbaarheidstests worden uitgevoerd op aanwezigheidspunten die over de hele wereld worden gedistribueerd. Er zijn twee oplossingen:

  • Firewalldeur: aanvragen naar uw server toestaan vanuit de lange en veranderlijke lijst met webtestagents.
  • Aangepaste code: Schrijf uw eigen code om periodieke aanvragen naar uw server te verzenden vanuit uw intranet. U kunt hiervoor Visual Studio-webtests uitvoeren. De tester kan de resultaten naar Application Insights verzenden met behulp van de TrackAvailability() API.

Wat is de tekenreeks voor de gebruikersagent voor beschikbaarheidstests?

De tekenreeks van de gebruikersagent is Mozilla/5.0 (compatibel; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

TLS-ondersteuning

Hoe heeft deze afschaffing invloed op mijn webtestgedrag?

Beschikbaarheidstests fungeren als een gedistribueerde client in elk van de ondersteunde webtestlocaties. Telkens wanneer een webtest wordt uitgevoerd, probeert de beschikbaarheidstestservice het externe eindpunt te bereiken dat is gedefinieerd in de webtestconfiguratie. Er wordt een Hello-bericht voor de TLS-client verzonden dat alle momenteel ondersteunde TLS-configuratie bevat. Als het externe eindpunt een algemene TLS-configuratie deelt met de beschikbaarheidstestclient, slaagt de TLS-handshake. Anders mislukt de webtest met een TLS-handshakefout.

Hoe kan ik ervoor zorgen dat mijn webtest niet wordt beïnvloed?

Om gevolgen te voorkomen, communiceert uw webtest met elk extern eindpunt (inclusief afhankelijke aanvragen) met ten minste één combinatie van dezelfde protocolversie, cipher suite en elliptische curve die door de beschikbaarheidstest wordt uitgevoerd. Als het externe eindpunt de benodigde TLS-configuratie niet ondersteunt, moet het worden bijgewerkt met ondersteuning voor een combinatie van de hierboven genoemde TLS-configuratie na afschaffing. Deze eindpunten kunnen worden gedetecteerd door de transactiedetails van uw webtest te bekijken (ideaal voor een geslaagde uitvoering van een webtest).

Hoe kan ik valideren welke TLS-configuratie een extern eindpunt ondersteunt?

Er zijn verschillende hulpprogramma's beschikbaar om te testen welke TLS-configuratie een eindpunt ondersteunt. Een manier is om het voorbeeld te volgen dat op deze pagina wordt beschreven. Als uw externe eindpunt niet beschikbaar is via openbaar internet, moet u ervoor zorgen dat u de TLS-configuratie valideert die wordt ondersteund op het externe eindpunt vanaf een computer die toegang heeft om uw eindpunt aan te roepen.

Notitie

Voor stappen voor het inschakelen van de benodigde TLS-configuratie op uw webserver, kunt u het beste contact opnemen met het team dat eigenaar is van het hostingplatform waarop uw webserver wordt uitgevoerd als het proces niet bekend is.

Wat is het gedrag van de webtest na 1 maart 2025 voor beïnvloede tests?

Er is geen uitzonderingstype waarmee alle TLS-handshakefouten die worden beïnvloed door deze afschaffing, zichzelf zouden presenteren. De meest voorkomende uitzondering voor uw webtest zou echter mislukken The request was aborted: Couldn't create SSL/TLS secure channel. U moet ook eventuele TLS-gerelateerde fouten kunnen zien in de TLS Transport Troubleshooting Step voor het webtestresultaat dat mogelijk wordt beïnvloed.

Kan ik bekijken welke TLS-configuratie momenteel wordt gebruikt door mijn webtest?

De TLS-configuratie die is onderhandeld tijdens het uitvoeren van een webtest, kan niet worden weergegeven. Zolang het externe eindpunt ondersteuning biedt voor algemene TLS-configuratie met beschikbaarheidstests, mag er geen gevolgen worden gezien na afschaffing.

Welke onderdelen heeft de afschaffing van invloed op de beschikbaarheidstestservice?

De TLS-afschaffing die in dit document wordt beschreven, moet alleen van invloed zijn op het gedrag van de uitvoering van de webtest voor beschikbaarheidstests na 1 maart 2025. Zie Azure Resource Manager TLS-ondersteuning voor meer informatie over interactie met de beschikbaarheidstestservice voor CRUD-bewerkingen. Deze resource biedt meer informatie over de tijdlijnen voor TLS-ondersteuning en afschaffing.

Waar kan ik TLS-ondersteuning krijgen?

Zie TLS-problemen oplossen voor algemene vragen over het verouderde TLS-probleem.

Volgende stappen