Share via

Beschikbaarheidstests voor Application Insights

  • Artikel

Nadat u uw web-app of website hebt geïmplementeerd, kunt u terugkerende tests instellen om de beschikbaarheid en reactiesnelheid te bewaken. Application Insights verzendt regelmatig webaanvragen naar uw toepassing vanaf punten over de hele wereld. Het kan u waarschuwen als uw toepassing niet reageert of te langzaam reageert. U kunt maximaal 100 beschikbaarheidstests per Application Insights-resource maken.

Voor beschikbaarheidstests zijn geen wijzigingen vereist voor de website die u test en werkt voor een HTTP- of HTTPS-eindpunt dat toegankelijk is via het openbare internet. U kunt ook de beschikbaarheid van een REST API testen waarvan uw service afhankelijk is.

Notitie

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

Typen beschikbaarheidstests

Er zijn vier typen beschikbaarheidstests:

  • Standaardtest: dit is 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.

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

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

Tip

Als u momenteel andere beschikbaarheidstests gebruikt, zoals URL-pingtests, kunt u standaardtests naast de andere toevoegen. Als u Standard-tests wilt gebruiken in plaats van een van uw andere tests, voegt u een Standaardtest toe en verwijdert u uw oude test.

Vereisten

Aan de slag

  1. Ga naar uw Application Insights-resource en selecteer het deelvenster Beschikbaarheid .

  2. Selecteer Standaardtest toevoegen.

    Schermopname van het deelvenster Beschikbaarheid met het tabblad Standaard toevoegen geopend.

  3. Voer uw testnaam, URL en andere instellingen in die worden beschreven in de volgende tabel. Ten slotte selecteert u Maken.

    Instelling Beschrijving
    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. Houd er rekening mee dat we maximaal 15 afhankelijke aanvragen parseren.
    Nieuwe pogingen inschakelen Wanneer de test mislukt, wordt deze 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.
    SSL-certificaatvalidatietest 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.
    Aangepaste headers Sleutel-waardeparen die de operationele parameters definiëren.
    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.

Slagingscriteria

Instelling Beschrijving
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 zijn ontvangen. Als u afhankelijke aanvragen parseert, moeten alle afbeeldingen, stijlbestanden, scripts en andere afhankelijke resources binnen deze periode zijn ontvangen.
HTTP-antwoord De geretourneerde statuscode die wordt geteld als een succes. Het getal 200 is de code die aangeeft dat er een normale webpagina is 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

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 pingtest voor beschikbaarheids-URL's implementeert met behulp van Azure Resource Manager.

Azure

Weergavenaam Naam van populatie
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

Weergavenaam Naam van populatie
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

Weergavenaam Naam van populatie
China - oost mc-cne-azr
China - oost 2 mc-cne2-azr
China - noord mc-cnn-azr
China - noord 2 mc-cnn2-azr

Waarschuwingen inschakelen

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

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, selecteert u op het tabblad Details het beletselteken voor de test die u hebt gemaakt. Selecteer de pagina Regels openen (waarschuwingen).

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

  2. Stel het ernstniveau, de beschrijving van de regel en de actiegroep in met de meldingsvoorkeuren die u voor deze waarschuwingsregel wilt gebruiken.

Waarschuwingscriteria

Beschikbaarheidswaarschuwingen die automatisch zijn ingeschakeld, activeren een e-mail wanneer het eindpunt dat u hebt gedefinieerd niet beschikbaar is en 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 hebt ingesteld met een evaluatiefrequentie van 15 minuten. U ontvangt alleen een e-mail wanneer de website uitvalt en een andere e-mail 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.

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

De waarschuwingscriteria wijzigen

Als u wijzigingen wilt aanbrengen in de locatiedrempel, aggregatieperiode en testfrequentie, selecteert u de voorwaarde op de bewerkingspagina van de waarschuwingsregel om het venster Signaallogica configureren te openen.

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 op het tabblad Beschikbaarheid van uw Application Insights-resource.

Schermopname van de pagina Beschikbaarheid met de knop Vernieuwen gemarkeerd.

In de weergave Spreidingsplot ziet u voorbeelden van de testresultaten met daarin diagnostische teststapdetails. De testengine slaat diagnostische gegevens op voor tests met fouten. Bij geslaagde tests wordt diagnostische informatie voor een subset van de uitvoeringen opgeslagen. Beweeg de muisaanwijzer over een van de groene/rode stippen om de test, testnaam en locatie weer te geven.

Schermopname van de lijnweergave.

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.

Schermopname van end-to-end transactiegegevens.

Tests controleren en bewerken

Als u een test wilt bewerken, tijdelijk wilt uitschakelen of verwijderen, selecteert u het beletselteken naast een testnaam. Het kan tot 20 minuten duren voordat configuratiewijzigingen zijn doorgegeven aan alle testagents nadat een wijziging is aangebracht.

Schermopname van de details van de test weergeven. Een webtest bewerken en uitschakelen.

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

Als u mislukte tests ziet

Selecteer een rode stip.

Schermopname van het tabblad End-to-end transactiedetails.

Vanuit een resultaat van een beschikbaarheidstest ziet u de transactiedetails voor alle onderdelen. Hier kunt u het volgende doen:

  • Bekijk het probleemoplossingsrapport om te bepalen wat uw test mogelijk heeft veroorzaakt, maar uw toepassing is nog steeds beschikbaar.
  • 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.
  • Registreer een probleem of werkitem in Git of Azure Boards om het probleem bij te houden. De bug bevat een koppeling naar deze gebeurtenis.
  • 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.

Schermopname van diagnostische gegevens aan de serverzijde.

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, afhankelijkheden en meer weer te geven. Zie het overzicht van logquery's voor meer informatie over Log Analytics.

Schermopname van beschikbaarheidsresultaten.

Schermopname van het tabblad Nieuwe query met afhankelijkheden beperkt tot 50.

Beschikbaarheidstests migreren

In dit artikel wordt u begeleid bij het migreren van klassieke URL-pingtests naar de moderne en efficiënte standaardtests.

We vereenvoudigen dit proces door duidelijke stapsgewijze instructies te bieden om een naadloze overgang te garanderen en uw toepassingen uit te rusten met de meest recente bewakingsmogelijkheden.

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 Ping Test die u wilt migreren en noteer de resourcegroep en naam.

  4. Met de volgende opdrachten maakt u een standaardtest met dezelfde logica als de URL-pingtest.

    Notitie

    De volgende opdrachten werken voor zowel HTTP- als HTTPS-eindpunten, die worden gebruikt in uw URL-pingtests.

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

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

  6. Zodra u de functionaliteit van de nieuwe standaardtest hebt gevalideerd, werkt u de waarschuwingsregels bij die verwijzen naar de URL-pingtest om in plaats daarvan te verwijzen naar de standaardtest. Vervolgens schakelt u de URL-pingtest uit of verwijdert u deze.

  7. Als u een URL-pingtest wilt verwijderen 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 standaard beschikbaarheidstests in om verkeer te valideren.

  1. Genereer een token of GUID om verkeer van uw beschikbaarheidstests te identificeren.

  2. Voeg de aangepaste header X-Customer-InstanceId toe met de waarde ApplicationInsightsAvailability:<GUID generated in step 1> in de sectie Standaardtestgegevens bij het maken of bijwerken van uw beschikbaarheidstests.

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

    Schermopname van aangepaste validatieheader.

U kunt het token ook instellen als een queryparameter. Bijvoorbeeld: https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your guid>.

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.

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.

Notitie

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

TLS 1.2

Coderingssuites

  • 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

Elliptische curven

  • NistP384
  • NistP256

TLS 1.3

Coderingssuites

  • TLS_AES_256_GCM_SHA384
  • TLS_AES_128_GCM_SHA256

Elliptische curven:

  • NistP384
  • NistP256

TLS-configuratie wordt afgeschaft

Waarschuwing

Op 31 oktober 2024, in overeenstemming met de verouderde TLS-afschaffing van Azure, worden tls 1.0/1.1-protocolversies en de onderstaande vermelde tls 1.2/1.3 verouderde coderingssuites en elliptische curven buiten gebruik gesteld voor Application Insights-beschikbaarheidstests.

TLS 1.0 en TLS 1.1

Protocolversies worden niet meer ondersteund.

TLS 1.2

Coderingssuites

  • 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

Elliptische curven:

  • curve25519

TLS 1.3

Elliptische curven

  • 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 met TLS 1.3 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. Zie het speciale artikel over probleemoplossing.

Werkmap met downtime, SLA en storingen

In dit artikel 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 het deelvenster Beschikbaarheid en selecteer vervolgens SLA-rapport boven aan het scherm.

    Schermopname van het tabblad **Beschikbaarheid** met SLA-rapport gemarkeerd.

  • Open het deelvenster Werkmappen en selecteer vervolgens Downtime & Storingen.

    Schermopname van de werkmapgalerie met de werkmap Downtime & Storingen gemarkeerd.

Flexibiliteit van parameters

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

Schermopname van 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 gedefinieerd wanneer een test mislukt totdat deze is geslaagd, op basis van 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.

Schermopname van een overzichtspagina met de overzichtstabel per test.

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

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

Schermopname van het tabblad Storingen en downtime in de werkmap downtime en storingen.

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

Schermopname van het tabblad Failure by Location in de werkmap downtime en storingen.

Het rapport bewerken

U kunt het rapport bewerken zoals elke andere Azure Monitor-werkmap.

Schermopname van het selecteren van de knop Bewerken om de visualisatie te wijzigen in een cirkeldiagram.

U kunt de query's of visualisaties aanpassen op basis van de behoeften van uw team.

Schermopname van het wijzigen van de visualisatie in een cirkeldiagram.

Log Analytics

De query's kunnen allemaal worden uitgevoerd in Log Analytics en worden gebruikt in andere rapporten of dashboards.

Schermopname van het openen van een logboekquery.

Verwijder de parameterbeperking en hergebruik de kernquery.

Schermopname van een logboekquery die u opnieuw kunt gebruiken.

Toegang en delen

Het rapport kan worden gedeeld met uw teams en leiderschap of worden vastgemaakt aan een dashboard voor verder gebruik. De gebruiker moet leesmachtigingen/-toegang hebben tot de Application Insights-resource waar de werkelijke werkmap is opgeslagen.

Schermopname van het deelvenster Sjabloon delen.

Veelgestelde vragen

In deze sectie vindt u antwoorden op veelgestelde vragen.

Algemeen

Kan ik beschikbaarheidstests uitvoeren op een intranetserver?

Onze webtests 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 31 oktober 2024 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 31 oktober 2024. 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