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.
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.
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.
Ga naar uw Application Insights-resource en open de beschikbaarheidservaring .
Selecteer Standaardtest toevoegen in de bovenste navigatiebalk.
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.
Belangrijk
TrackAvailability() vereist dat ontwikkelaars investeren in het schrijven en beheren van mogelijk complexe aangepaste code.
Standaardtests moeten altijd, indien mogelijk, worden gebruikt, omdat ze weinig investeringen, geen onderhoud vereisen en weinig vereisten hebben.
Dit voorbeeld is alleen ontworpen om u te laten zien hoe de TrackAvailability() API-aanroep werkt in een Azure Functions-app. Het laat niet zien hoe u de onderliggende HTTP-testcode of bedrijfslogica schrijft die is vereist om dit voorbeeld om te zetten in een volledig functionele beschikbaarheidstest.
Ontwikkelaarsexpertise voor het ontwerpen van aangepaste code voor TrackAvailability(), afgestemd op uw specifieke bedrijfsbehoeften
Aan de slag
Notitie
Als u deze instructies wilt volgen, moet u het App Service-plan of het Functions Premium-plan gebruiken om bewerkingscode toe te staan in app service-editor.
Als u achter een virtueel netwerk test of niet-openbare eindpunten test, moet u het Functions Premium-abonnement gebruiken.
Als u nog geen Application Insights-resource hebt voor uw door timer geactiveerde functie, wordt deze standaard gemaakt wanneer u een Azure Functions-app maakt.
Als u al een Application Insights-resource hebt, gaat u naar het tabblad Bewaking tijdens het maken van de Azure Functions-app en selecteert of voert u de naam van uw bestaande resource in de vervolgkeuzelijst Application Insights in:
Code toevoegen en bewerken in de App Service-editor
Ga naar uw geïmplementeerde Azure Functions-app en selecteer onder Ontwikkelhulpprogramma's het tabblad App Service-editor .
Als u een nieuw bestand wilt maken, klikt u met de rechtermuisknop onder de timertriggerfunctie (bijvoorbeeld TimerTrigger1) en selecteert u Nieuw bestand. Voer vervolgens de naam van het bestand in en selecteer Enter.
Maak een nieuw bestand met de naam function.proj en plak de volgende code:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.ApplicationInsights" Version="2.15.0" /> <!-- Ensure you’re using the latest version -->
</ItemGroup>
</Project>
Maak een nieuw bestand met de naam runAvailabilityTest.csx en plak de volgende code:
using System.Net.Http;
public async static Task RunAvailabilityTestAsync(ILogger log)
{
using (var httpClient = new HttpClient())
{
// TODO: Replace with your business logic
await httpClient.GetStringAsync("https://www.bing.com/");
}
}
Vervang de bestaande code in run.csx door het volgende:
#load "runAvailabilityTest.csx"
using System;
using System.Diagnostics;
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.Channel;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.ApplicationInsights.Extensibility;
private static TelemetryClient telemetryClient;
// =============================================================
// ****************** DO NOT MODIFY THIS FILE ******************
// Business logic must be implemented in RunAvailabilityTestAsync function in runAvailabilityTest.csx
// If this file does not exist, add it first
// =============================================================
public async static Task Run(TimerInfo myTimer, ILogger log, ExecutionContext executionContext)
{
if (telemetryClient == null)
{
// Initializing a telemetry configuration for Application Insights based on connection string
var telemetryConfiguration = new TelemetryConfiguration();
telemetryConfiguration.ConnectionString = Environment.GetEnvironmentVariable("APPLICATIONINSIGHTS_CONNECTION_STRING");
telemetryConfiguration.TelemetryChannel = new InMemoryChannel();
telemetryClient = new TelemetryClient(telemetryConfiguration);
}
string testName = executionContext.FunctionName;
string location = Environment.GetEnvironmentVariable("REGION_NAME");
var availability = new AvailabilityTelemetry
{
Name = testName,
RunLocation = location,
Success = false,
};
availability.Context.Operation.ParentId = Activity.Current.SpanId.ToString();
availability.Context.Operation.Id = Activity.Current.RootId;
var stopwatch = new Stopwatch();
stopwatch.Start();
try
{
using (var activity = new Activity("AvailabilityContext"))
{
activity.Start();
availability.Id = Activity.Current.SpanId.ToString();
// Run business logic
await RunAvailabilityTestAsync(log);
}
availability.Success = true;
}
catch (Exception ex)
{
availability.Message = ex.Message;
throw;
}
finally
{
stopwatch.Stop();
availability.Duration = stopwatch.Elapsed;
availability.Timestamp = DateTimeOffset.UtcNow;
telemetryClient.TrackAvailability(availability);
telemetryClient.Flush();
}
}
Notitie
Tests die zijn gemaakt met TrackAvailability() , worden weergegeven met AANGEPAST naast de testnaam.
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.
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.
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).
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.
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.
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:
Selecteer een Application Insights-resource in de ervaring met metrische gegevens en selecteer een metrische gegevens over beschikbaarheid .
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.
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.
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.
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.
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.
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.
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.
Zoek de URL-pingtest die u wilt migreren en noteer de resourcegroep en naam.
Maak een standaardtest met dezelfde logica als de URL-pingtest met behulp van de volgende opdrachten, die werken voor zowel HTTP- als HTTPS-eindpunten.
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.
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.
Schakel de URL-pingtest uit of verwijder deze. Als u dit wilt doen met Azure PowerShell, kunt u deze opdracht gebruiken:
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.
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.
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.
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.
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.
Open in de resource van uw netwerkbeveiligingsgroep onder Instellingen de ervaring voor binnenkomende beveiligingsregels en selecteer vervolgens Toevoegen.
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
Verbind uw Application Insights-resource met uw interne service-eindpunt met behulp van Azure Private Link.
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.
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.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.
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:
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.