Delen 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-gegevensversleuteling in ruste beleid.

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 komende beëindigingen van beschikbaarheidstests.

  • Webtests met meerdere stappen: Application Insights trekt webtests met meerdere stappen buiten gebruik op 31 augustus 2024. Als u beschikbaarheidsbewaking wilt behouden, schakelt u over naar alternatieve beschikbaarheidstests vóór deze datum. Na de buitengebruikstelling verwijdert het platform de onderliggende infrastructuur, waardoor resterende tests met meerdere stappen mislukken.
  • 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 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 wordt omgeleid, volgen we deze tot maximaal 10 omleidingen.
    Afhankelijke aanvragen parseren Met de test worden afbeeldingen, scripts, stijlbestanden en andere resources van de webpagina geladen die worden getest. De reactietijd wordt vastgelegd, inclusief de tijd die nodig is om deze bestanden op te halen. De test mislukt als niet alle resources binnen de time-out kunnen worden gedownload. Als u de optie niet inschakelt, laadt de test alleen het bestand op de opgegeven URL. Als u deze inschakelt, wordt de controle strenger, wat ertoe kan leiden dat problemen worden opgemerkt die bij handmatig bladeren niet zouden worden gedetecteerd. De test parseert maximaal 15 afhankelijke aanvragen.
    Herhaalde pogingen inschakelen voor storingen in 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 herhaalpogingen worden tijdelijk opgeschort tot het volgende succes. 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 Controleer het SSL-certificaat op uw website om de juiste installatie te bevestigen. Zorg ervoor dat deze correct, geldig, vertrouwd is en geen fouten genereert voor gebruikers. De beschikbaarheidstest valideert alleen het SSL-certificaat op de uiteindelijke omgeleide URL.
    Proactieve levensduurcontrole Met deze instelling kunt u een ingestelde periode definiëren voordat uw SSL-certificaat verloopt. Nadat het is verlopen, zal je test mislukken.
    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.
    aanvraaginhoud 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. De headers 'Host' en 'User-Agent' zijn gereserveerd in beschikbaarheidstests en kunnen niet worden gewijzigd of overschreven.
    Succescriteria
    Test-time-out 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.
    Contentmatch Een string, zoals 'Welkom!' We testen of er in elk antwoord een exact 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 voor inhoudsovereenstemmen.

Beschikbaarheidswaarschuwingen

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

Instelling Beschrijving
Bijna real-tijd We raden u aan near-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.

Aanbieder Weergavenaam Naam van populatie
Azuur
Australië - oost emea-au-syd-edge
Brazilië - zuid latam-br-gru-edge
Centraal-VS us-fl-mia-edge
Azië - oost apac-hk-hkn-azr
Oost-Amerika us-va-ash-azr
Frankrijk - zuid (voorheen Frankrijk - centraal) emea-ch-zrh-edge
Frankrijk - centraal emea-fr-pra-edge
Oost-Japan apac-jp-kaw-edge
Europa - noord emea-gb-db3-azr
VS - noord-centraal us-il-ch1-azr
het zuid-centraal deel van de VS us-tx-sn1-azr
Azië - zuidoost apac-sg-sin-azr
West-Verenigd Koninkrijk emea-se-sto-edge
West-Europa emea-nl-ams-azr
Westen van de VS us-ca-sjc-azr
Verenigd Koninkrijk Zuid emea-ru-msa-edge
Azure Government
Amerikaanse overheid Virginia usgov-va-azr
US Gov - Arizona usgov-phx-azr
USGov Texas usgov-tx-azr (Een niet-gebruikelijke term die mogelijk verwijst naar een programma of afdeling van de Amerikaanse regering in een bepaalde regio)
USDoD Oost usgov-ddeast-azr
USDoD Centraal usgov-ddcentral-azr
Microsoft Azure beheerd door 21Vianet
Oost-China mc-cne-azr
China - oost 2 mc-cne2-azr
China - noord mc-cnn-azr
China - noord 2 mc-cnn2-azr

Waarschuwingen inschakelen

Notitie

Als u waarschuwingen wilt ontvangen via uw geconfigureerde actiegroepen, stelt u de ernst van de waarschuwingsregel en de voorkeuren voor meldingen in in de geïntegreerde waarschuwingservaring. Zonder de volgende stappen uit te voeren, ontvangt u alleen meldingen in de portal.

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

    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

Automatisch geactiveerde beschikbaarheidswaarschuwingen sturen één e-mail wanneer het eindpunt niet meer beschikbaar is en nog een 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.

Aanbeveling

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 Configure signal logic venster 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 metrische ervaring, en selecteer een beschikbaarheidsmetriek.

    2. Met Configure alerts de optie in het menu gaat u naar de nieuwe ervaring waar u specifieke tests of locaties kunt selecteren waarop waarschuwingsregels moeten worden ingesteld. 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 beschikbaarheidservaringsgrafiek, waarin de wissel tussen lijn- en spreidingsplot wordt benadrukt.

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 onder InzoomenGeslaagd of Mislukt. 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.

Aanbeveling

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 Probleemoplossingsrapport om te bepalen waarom uw test mogelijk is mislukt.
  • 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 end-to-end transactiediagnose voor meer informatie.

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 Logboekanalyse

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) -RuleSslCheck:$false;

    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

Om de beschikbaarheid van eindpunten achter firewalls te garanderen, schakelt u openbare beschikbaarheidstests in of voert u beschikbaarheidstests uit in niet-verbonden of geen toegangsscenario's.

Inschakeling van openbare beschikbaarheidstesten

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

Waarschuwing

De service voor beschikbaarheidstests maakt gebruik van gedeelde IP-adressen, waarmee uw met firewall beveiligde eindpunten kunnen worden blootgesteld aan verkeer van andere tests. Als u uw service wilt beveiligen, vertrouwt u niet alleen op IP-adresfiltering. Voeg aangepaste headers toe om de oorsprong van elke 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 uw Bron. Voeg vervolgens uw IP-adressen toe in een door komma's gescheiden lijst in bron-IP-adres-/CIRD-bereiken.

Verbroken verbinding of geen toegangsscenario'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

Om de beste encryptie in zijn klasse te bieden, maakt Application Insights gebruik van Transport Layer Security (TLS) 1.2 en 1.3 als de voorkeursencryptiemechanismen. Daarnaast worden de volgende coderingssuites en elliptische curven ook ondersteund binnen elke versie.

Versie Versleutelingssuites 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

Belangrijk

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

TLS-configuraties (Transport Layer Security) uitfaseren

Belangrijk

Om de beveiliging te verbeteren, trekt Azure de volgende TLS-configuraties voor Application Insights op 1 mei 2025 terug. Deze wijziging maakt deel uit van de Azure-brede pensionering van verouderde TLS:

  • TLS 1.0- en TLS 1.1-protocolversies
  • Verouderde TLS 1.2- en TLS 1.3-coderingssuites
  • Verouderde TLS elliptische krommen

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

Werkmap Uitvaltijd en Storingen

In deze sectie introduceren we een eenvoudige manier om de service-level agreement (SLA) te berekenen en te rapporteren voor webtests via één overzichtsscherm 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 Availability-ervaring en selecteer vervolgens SLA Report in de bovenste navigatiebalk.

  • Open de Workbooks ervaring en selecteer vervolgens de Downtime & Storingen sjabloon.

Flexibiliteit van parameters

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

Schermopname die parameters toont.

  • 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)
  • Tijden van end-to-end-storingen
  • Uitvaltijd van toepassingen

Storingen worden vastgesteld vanaf het moment dat een test begint te falen totdat deze weer slaagt, 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 werkruimte-gebaseerde Application Insights-resource.

Downtime, uitval 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.

Volgende stappen