Application Insights-Verfügbarkeitstests

Artikel
07/19/2024

Nachdem Sie die Web-App oder Website bereitgestellt haben, können Sie regelmäßige Tests einrichten, um die Verfügbarkeit und Reaktionszeit zu überwachen. Application Insights sendet regelmäßig Webanforderungen von verschiedenen Punkten auf der ganzen Welt an Ihre Anwendung. Außerdem kann dieser Dienst Sie warnen, wenn Ihre Anwendung nicht oder zu langsam reagieren sollte. Sie können bis zu 100 Verfügbarkeitstests pro Application Insights-Ressource erstellen.

Verfügbarkeitstests erfordern keine Änderungen an der zu testenden Website und funktionieren für jeden HTTP- oder HTTPS-Endpunkt, der über das öffentliche Internet zugänglich ist. Sie können auch die Verfügbarkeit einer REST-API testen, von der Ihr Dienst abhängig ist.

Hinweis

Verfügbarkeitstests werden gemäß Richtlinien für die Azure-Verschlüsselung ruhender Daten verschlüsselt gespeichert.

Arten von Verfügbarkeitstests

Es gibt vier Arten von Verfügbarkeitstests:

Standardtest: Hierbei handelt es sich um eine Art Verfügbarkeitstest, bei dem die Verfügbarkeit einer Website durch Senden einer einzelnen Anforderung überprüft wird, ähnlich wie beim veralteten URL-Pingtest. Neben dem Überprüfen der Reaktion eines Endpunkts und dem Messen der Leistung prüfen Standardtests auch die Gültigkeit des TLS/SSL-Zertifikats, führen eine proaktive Lebensdauerüberprüfung durch und prüfen das HTTP-Anforderungsverb (z. B. GET, HEAD und POST), benutzerdefinierte Header sowie benutzerdefinierte Daten, die Ihrer HTTP-Anforderung zugeordnet sind.
Benutzerdefinierter TrackAvailability-Test: Wenn Sie eine benutzerdefinierte Anwendung zum Ausführen von Verfügbarkeitstests erstellen möchten, können Sie die TrackAvailability()-Methode verwenden, um die Ergebnisse an Application Insights zu senden.
(Veraltet) Mehrstufiger Webtest: Sie können diese Aufzeichnung einer Sequenz von Webanforderungen wiedergeben, um komplexere Szenarien zu testen. Mehrstufige Webtests werden in Visual Studio Enterprise erstellt und ins Portal hochgeladen, wo Sie sie ausführen können.
(Veraltet) URL-Pingtest: Sie können diesen Test über das Azure-Portal erstellen, um zu überprüfen, ob ein Endpunkt antwortet, und die mit dieser Antwort verbundene Leistung zu messen. Sie können außerdem benutzerdefinierte Erfolgskriterien festlegen, die an erweiterte Features wie das Analysieren von abhängigen Anforderungen und das Zulassen von Wiederholungsversuchen gekoppelt sind.

Wichtig

Zwei Verfügbarkeitstests werden demnächst eingestellt:

Mehrstufige Webtests: Am 31. August 2024 werden Webtests mit mehreren Schritten in Application Insights eingestellt. Wir empfehlen Benutzern dieser Tests, vor dem Ausmusterungstermin auf alternative Verfügbarkeitstests umzusteigen. Nach diesem Datum wird die zugrunde liegende Infrastruktur außer Betrieb genommen, was dazu führt, dass die verbleibenden Tests mit mehreren Schritten nicht mehr funktionieren.
URL-Pingtests: Am 30. September 2026 werden URL-Pingtests in Application Insights eingestellt. Vorhandene URL-Pingtests werden aus Ihren Ressourcen entfernt. Überprüfen Sie die Preise für Standardtests und den Übergang zu deren Verwendung vor dem 30. September 2026, um sicherzustellen, dass Sie weiterhin Einzelschritt-Verfügbarkeitstests in Ihren Application Insights-Ressourcen ausführen können.

Tipp

Wenn Sie derzeit andere Verfügbarkeitstests wie z. B. URL-Pingtests verwenden, könnten Sie Standardtests zusätzlich hinzufügen. Wenn Sie Standardtests anstelle eines Ihrer anderen Tests verwenden möchten, fügen Sie einen Standardtest hinzu, und löschen Sie Ihren alten Test.

Voraussetzungen

Arbeitsbereichsbasierte Application Insights-Ressource

Erste Schritte

Wechseln Sie zur Application Insights-Ressource, und wählen Sie den Bereich Verfügbarkeit aus.
Wählen Sie Standardtest hinzufügen aus.

Geben Sie Ihren Testnamen, die URL und andere Einstellungen ein, die in der folgenden Tabelle beschrieben sind. Wählen Sie anschließend Erstellen.

Einstellung	BESCHREIBUNG
URL	Die URL kann zu einer beliebigen Webseite führen, die Sie testen möchten, aber sie muss im öffentlichen Internet sichtbar sein. Die URL kann eine Abfragezeichenfolge enthalten. So können Sie beispielsweise Ihre Datenbank abfragen. Wenn die URL in eine Umleitung aufgelöst wird, werden bis zu 10 Umleitungen verfolgt.
Abhängige Anforderungen analysieren	Der Test fordert Bilder, Skripts, Formatdateien und andere Dateien an, die Teil der zu testenden Webseite sind. Die aufgezeichnete Antwortzeit enthält auch die Zeit, die zum Abrufen dieser Dateien erforderlich ist. Der Test führt zu einem Fehler, wenn eine dieser Ressourcen innerhalb des Zeitlimits für den gesamten Test nicht erfolgreich heruntergeladen werden kann. Wenn die Option nicht ausgewählt ist, wird beim Test nur die Datei unter der von Ihnen angegebenen URL angefordert. Wenn diese Option aktiviert wird, wird strenger geprüft. Der Test könnte in Fällen fehlschlagen, die möglicherweise beim manuellen Durchsuchen der Website nicht auffallen würden. Bitte beachten Sie, dass wir nur bis zu 15 abhängige Anfragen analysieren.
Enable retries (Wiederholungen aktivieren)	Wenn der Test nicht erfolgreich ist, wird er nach kurzer Zeit wiederholt. Nur wenn drei aufeinander folgende Versuche scheitern, wird ein Fehler gemeldet. Nachfolgende Tests werden dann in der üblichen Häufigkeit ausgeführt. Die Wiederholung wird bis zum nächsten Erfolg vorübergehend eingestellt. Diese Regel wird an jedem Teststandort unabhängig angewendet. Es wird empfohlen, diese Option zu verwenden. Im Durchschnitt treten ca. 80% der Fehler bei einer Wiederholung nicht mehr auf.
Test zur SSL-Zertifikatüberprüfung	Sie können das SSL-Zertifikat auf Ihrer Website überprüfen, um sicherzustellen, dass es ordnungsgemäß installiert, gültig und vertrauenswürdig ist und bei Ihren Benutzern keine Fehler verursacht.
Proaktive Lebensdauerüberprüfung	Mit dieser Einstellung können Sie einen festgelegten Zeitraum definieren, nach dem Ihr SSL-Zertifikat abläuft. Nach Ablauf verursacht der Test einen Fehler.
Testhäufigkeit	Legt fest, wie oft der Test von jedem Teststandort aus ausgeführt wird. Mit einer Standardfrequenz von fünf Minuten und fünf Teststandorten wird Ihre Website im Durchschnitt jede Minute getestet.
Teststandorte	Unsere Server senden von diesen Orten aus Webanforderungen an Ihre URL. Es wird empfohlen, mindestens fünf Teststandorte festzulegen, um sicherzustellen, dass Sie Probleme mit Ihrer Website von Netzwerkproblemen unterscheiden können. Sie können bis zu 16 Standorte auswählen.
Benutzerdefinierte Header	Schlüssel-Wert-Paare zur Definition der Betriebsparameter.
HTTP-Anforderungsverb	Geben Sie an, welche Aktion Sie mit Ihrer Anforderung ergreifen möchten.
Anforderungstext	Benutzerdefinierte Daten, die Ihrer HTTP-Anforderung zugeordnet sind. Sie können Ihre eigenen Dateien hochladen, Ihre Inhalte eingeben oder dieses Feature deaktivieren.

Erfolgskriterien

Einstellung	BESCHREIBUNG
Testtimeout	Reduzieren Sie diesen Wert, um über langsame Antworten benachrichtigt zu werden. Der Test wird als ein Fehler gezählt, wenn die Antworten von Ihrer Website nicht innerhalb dieses Zeitraums empfangen wurden. Wenn Sie Abhängige Anfragen parsen ausgewählt haben, müssen alle Bilder, Stildateien, Skripte und andere abhängige Ressourcen innerhalb dieses Zeitraums eingegangen sein.
HTTP-Antwort	Der zurückgegebene Statuscode, der als Erfolg gezählt wird. Die Zahl 200 ist der Code, der angibt, dass eine normale Webseite zurückgegeben wurde.
Inhaltsübereinstimmung	Eine Zeichenfolge, z. B. „Willkommen!“ – Mit diesem Test vergewissern Sie sich, dass in jeder Antwort eine exakte Übereinstimmung unter Berücksichtigung der Groß- und Kleinschreibung vorkommt. Dies muss eine Zeichenfolge in Klartext, ohne Platzhalter sein. Vergessen Sie nicht, diese zu aktualisieren, wenn sich der Seiteninhalt ändert. Beim Inhaltsabgleich werden nur englische Zeichen unterstützt.

Wichtig

TrackAvailability() erfordert eine Investition der Entwickler*innen in das Schreiben und Verwalten von potenziell komplexem benutzerdefiniertem Code.

Nach Möglichkeit sollten immer Standardtests verwendet werden, da sie nur geringe Investitionen, keine Wartung und nur wenige Voraussetzungen erfordern.

Voraussetzungen

Arbeitsbereichsbasierte Application Insights-Ressource
Zugriff auf den Quellcode einer Funktions-App in Azure Functions
Entwicklerkenntnisse zum Erstellen von benutzerdefiniertem Code für TrackAvailability(), der auf Ihre spezifischen Geschäftsanforderungen zugeschnitten ist

Grundlegendes Codebeispiel

Hinweis

Dieses Beispiel wurde ausschließlich dazu entworfen, die Funktionsweise des API-Aufrufs TrackAvailability() innerhalb einer Azure-Funktion zu veranschaulichen. Es dient nicht zur Veranschaulichung des Schreibens des zugrunde liegenden HTTP-Testcodes bzw. der Geschäftslogik, die erforderlich ist, um dieses Beispiel in einen voll funktionsfähigen Verfügbarkeitstest umzuwandeln.

Wenn Sie dieses Beispiel durchgehen, erstellen Sie standardmäßig einen HTTP GET-Test für einfache Verfügbarkeit. Zum Befolgen dieser Anweisungen müssen Sie den dedizierten Plan verwenden, um die Bearbeitung von Code im App Service-Editor zu ermöglichen.

Erstellen einer Timertriggerfunktion

Erstellen Sie eine Azure Functions-Ressource.
- Wenn Sie schon eine Application Insights-Ressource verwenden:
  
  Azure Functions erstellt standardmäßig eine Application Insights-Ressource. Wenn Sie jedoch eine zuvor erstellte Ressource verwenden möchten, müssen Sie dies während der Erstellung angeben.
  
  Folgen Sie den Anweisungen zur Erstellung einer Azure Functions-Ressource mit den folgenden Modifikationen:
  
  Wählen Sie auf der Registerkarte Überwachung das Dropdownfeld Application Insights aus, und geben Sie dann den Namen Ihrer Ressource ein, oder wählen Sie ihn aus:
- Falls Sie noch keine Application Insights-Ressource für ihre per Timer ausgelöste Funktion erstellt haben:
  
  Wenn Sie Ihre Azure Functions-Anwendung erstellen, wird standardmäßig eine Application Insights-Ressource für Sie erstellt. Folgen Sie den Anweisungen zur Erstellung einer Azure Functions-Ressource.
Hinweis

Sie können Ihre Funktionen in einem Verbrauchs-, Premium- oder App Service-Plan hosten. Wenn Sie hinter einem virtuellen Netzwerk testen oder nicht öffentliche Endpunkte testen, müssen Sie anstelle des Verbrauchsplans den Premium-Plan verwenden. Wählen Sie auf der Registerkarte Hosting Ihren Plan aus. Stellen Sie sicher, dass beim Erstellen der Funktions-App die neueste .NET-Version ausgewählt ist.
Erstellen Sie eine Timertriggerfunktion.
1. Wählen Sie in Ihrer Funktions-App die Registerkarte Funktionen aus.
2. Wählen Sie Hinzufügen. Wählen Sie im Bereich Funktion hinzufügen die folgenden Konfigurationen aus:
  - Entwicklungsumgebung: Im Portal entwickeln
  - Vorlage auswählen: Timertrigger
3. Wählen Sie Hinzufügen aus, um die Timertriggerfunktion zu erstellen.

Hinzufügen und Bearbeiten von Code im App Service-Editor

Wechseln Sie zu Ihrer bereitgestellten Funktions-App, und wählen Sie unter Entwicklungstools die Registerkarte App Service-Editor aus.

Um eine neue Datei zu erstellen, klicken Sie mit der rechten Maustaste unter Ihrer Timertriggerfunktion (z. B. TimerTrigger1), und wählen Sie Neue Datei aus. Geben Sie dann den Namen der Datei ein, und wählen Sie die EINGABETASTE aus.

Erstellen Sie eine neue Datei namens function.proj, und fügen Sie den folgenden Code ein:

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

Erstellen Sie eine neue Datei namens runAvailabilityTest.csx, und fügen Sie den folgenden Code ein:

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/"); 
    } 
}

Definieren Sie die Umgebungsvariable REGION_NAME als einen gültigen Azure-Verfügbarkeitsstandort.

Führen Sie den folgenden Befehl in der Azure CLI aus, um verfügbare Regionen aufzulisten.
```
az account list-locations -o table
```

Kopieren Sie den folgenden Code in die Datei run.csx. (Sie ersetzen den bereits vorhandenen Code.)

#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, please 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(); 
    } 
}

Beispiel für mehrstufigen Webtestcode

Befolgen Sie die gleichen obigen Anweisungen, und fügen Sie stattdessen den folgenden Code in die Datei runAvailabilityTest.csx ein:

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/"); 

        // TODO: Replace with your business logic for an additional monitored endpoint, and logic for additional steps as needed
        await httpClient.GetStringAsync("https://www.learn.microsoft.com/"); 
    } 
}

Verfügbarkeitswarnungen

Einstellung	BESCHREIBUNG
Nahezu in Echtzeit	Es wird empfohlen, Warnungen in Quasi-Echtzeit zu verwenden. Diese Art von Warnung ist bereits vollständig konfiguriert, sobald Sie einen Verfügbarkeitstest erstellt haben.
Schwellenwert für den Warnungsspeicherort	Es wird ein Mindestwert von 3/5 Standorten empfohlen. Das optimale Verhältnis zwischen dem Schwellenwert für den Warnungsspeicherort und der Anzahl von Teststandorten lautet Warnungsschwellenwert für Standort = Anzahl von Teststandorten -2, bei einer Mindestanzahl von fünf Teststandorten.

Auffüllungstags für den Standort

Beim Bereitstellen eines URL-Pingtests für die Verfügbarkeit mithilfe von Azure Resource Manager können für das Attribut für den geografischen Standort die folgenden Auffüllungstags verwendet werden.

Azure

`Display name`	Auffüllungsname
Australien (Osten)	emea-au-syd-edge
Brasilien Süd	latam-br-gru-edge
USA (Mitte)	us-fl-mia-edge
Asien, Osten	apac-hk-hkn-azr
East US	us-va-ash-azr
Frankreich, Süden (ehemals Frankreich, Mitte)	emea-ch-zrh-edge
Frankreich, Mitte	emea-fr-pra-edge
Japan, Osten	apac-jp-kaw-edge
Nordeuropa	emea-gb-db3-azr
USA Nord Mitte	us-il-ch1-azr
USA Süd Mitte	us-tx-sn1-azr
Asien, Südosten	apac-sg-sin-azr
UK, Westen	emea-se-sto-edge
Europa, Westen	emea-nl-ams-azr
USA (Westen)	us-ca-sjc-azr
UK, Süden	emea-ru-msa-edge

Azure Government

`Display name`	Auffüllungsname
US Government, Virginia	usgov-va-azr
US Gov Arizona	usgov-phx-azr
USGov Texas	usgov-tx-azr
USDoD, Osten	usgov-ddeast-azr
USDoD, Mitte	usgov-ddcentral-azr

Microsoft Azure von 21Vianet

`Display name`	Auffüllungsname
China, Osten	mc-cne-azr
China, Osten 2	mc-cne2-azr
China, Norden	mc-cnn-azr
China, Norden 2	mc-cnn2-azr

Aktivieren von Warnungen

Warnungen werden jetzt zwar standardmäßig automatisch aktiviert, aber um sie vollständig zu konfigurieren, müssen Sie zunächst einen Verfügbarkeitstest erstellen.

Hinweis

Mit den neuen einheitlichen Warnungen, müssen der Schweregrad der Warnungsregel sowie die Benachrichtigungseinstellungen mit Aktionsgruppen in der Warnungserfahrung konfiguriert werden. Ohne die folgenden Schritten werden Sie nur portalinterne Benachrichtigungen erhalten.

Nachdem Sie den Verfügbarkeitstest gespeichert haben, wählen Sie auf der Registerkarte Details die Auslassungspunkte neben dem Test aus, den Sie erstellt haben. Wählen Sie Seite zum Öffnen von Regeln (Warnungen) aus.
Legen Sie den Schweregrad, die Regelbeschreibung und die Aktionsgruppe fest, die über die Benachrichtigungseinstellungen verfügt, die Sie für diese Warnungsregel verwenden möchten.

Benachrichtigungskriterien

Automatisch aktivierte Verfügbarkeitswarnungen lösen eine E-Mail aus, wenn der von Ihnen definierte Endpunkt nicht verfügbar ist, sowie wenn er wieder verfügbar ist. Über diese Oberfläche erstellte Verfügbarkeitswarnungen sind zustandsbasiert. Bei Erfüllung der Warnungskriterien wird eine einzelne Warnung generiert, wenn die Website als nicht mehr verfügbar erkannt wird. Falls die Website bei der nächsten Auswertung der Warnungskriterien immer noch nicht verfügbar ist, wird keine neue Warnung generiert.

Angenommen, Ihre Website ist eine Stunde lang ausgefallen, und Sie haben eine E-Mail-Warnung mit einer Auswertungsintervall von 15 Minuten eingerichtet. Dann werden Sie nur eine E-Mail erhalten, wenn die Website ausfällt sowie eine weitere, wenn sie wieder online ist. Sie erhalten aber nicht alle 15 Minuten eine Warnung, um Sie daran zu erinnern, dass die Website noch immer nicht verfügbar ist.

Möglicherweise möchten Sie keine Benachrichtigungen erhalten, wenn Ihre Website nur für einen kurzen Zeitraum ausgefallen ist, z. B. während einer Wartung. Sie können dann das Auswertungsintervall auf einen höheren Wert als die erwartete Ausfallzeit ändern (bis zu 15 Minuten). Sie können auch den Standortschwellenwert für die Warnung erhöhen, sodass eine Warnung nur ausgelöst wird, wenn die Website in einer bestimmten Anzahl Regionen ausfällt. Bei längeren geplanten Ausfallzeiten können Sie die Warnungsregel vorübergehend deaktivieren oder eine benutzerdefinierte Regel erstellen. Dadurch erhalten Sie weitere Möglichkeiten, die Ausfallzeiten zu berücksichtigen.

Ändern der Warnungskriterien

Um Änderungen am Standortschwellenwert, dem Aggregationszeitraum und der Testhäufigkeit vorzunehmen, wählen Sie die Bedingung auf der Bearbeitungsseite der Warnungsregel aus, um das Fenster „Signallogik konfigurieren“ zu öffnen.

Erstellen einer benutzerdefinierten Warnungsregel

Wenn Sie erweiterte Funktionen benötigen, können Sie eine benutzerdefinierte Warnungsregel auf der Registerkarte Warnungen erstellen. Wählen hierfür Sie Warnungsregel>erstellen aus. Wählen Sie Metriken für den Signaltyp, um alle verfügbaren Signale anzuzeigen, und dann Verfügbarkeit aus.

Eine benutzerdefinierte Warnungsregel bietet höhere Werte für den Aggregationszeitraum (bis zu 24 Stunden statt sechs Stunden) und die Testhäufigkeit (bis zu einer Stunde statt 15 Minuten). Außerdem fügt sie Optionen hinzu, um die Logik noch weiter zu definieren, indem verschiedene Operatoren, Aggregationstypen und Schwellenwerte ausgewählt werden.

Warnung bei X von Y Standorten, die Fehler melden: Die Warnungsregel „X von Y Standorten“ ist auf der neuen einheitlichen Benutzeroberfläche für Warnungen standardmäßig aktiviert, wenn Sie einen neuen Verfügbarkeitstest erstellen. Sie können sich dagegen entscheiden, indem Sie die „klassische“ Option auswählen oder die Warnungsregel deaktivieren. Konfigurieren Sie die Aktionsgruppen, um Benachrichtigungen zu empfangen, wenn die Warnung ausgelöst wird, indem Sie die vorherigen Schritte ausführen. Ohne diese Schritte erhalten Sie nur portalinterne Benachrichtigungen, wenn die Regel ausgelöst wird.
Warnung bei Verfügbarkeitsmetriken: Mithilfe der neuen einheitlichen Warnungen können Sie sowohl bei segmentierter aggregierter Verfügbarkeit als auch bei Testdauermetriken warnen:
1. Wählen Sie eine Application Insights-Ressource in der Oberfläche Metriken und dann eine Verfügbarkeitsmetrik aus.
2. Die Option Warnungen konfigurieren aus diesem Menü, führt Sie zur neuen Oberfläche, wo Sie bestimmte Tests oder Standorte auswählen können, für die Warnungsregeln eingerichtet werden sollen. Sie können hier außerdem die Aktionsgruppen für diese Warnungsregel konfigurieren.
Warnung bei benutzerdefinierten Analyseabfragen: Mithilfe der neuen einheitlichen Warnungen können Sie bei benutzerdefinierten Protokollabfragen warnen. Mit benutzerdefinierten Abfragen können Sie bei jeder beliebigen Bedingung warnen, die Ihnen hilft, das zuverlässigste Signal für Verfügbarkeitsprobleme abzurufen. Diese Funktionalität ist auch anwendbar, wenn Sie benutzerdefinierte Verfügbarkeitsergebnisse mithilfe des TrackAvailability SDK senden.

Die Metriken zu Verfügbarkeitsdaten umfassen alle benutzerdefinierten Verfügbarkeitsergebnisse, die Sie möglicherweise durch Aufrufen des TrackAvailability SDKs übermitteln. Sie können die Unterstützung für Warnungen bei Metriken verwenden, um bei benutzerdefinierten Verfügbarkeitsergebnissen zu warnen.

Automatisieren von Warnungen

Informationen zur Automatisierung dieses Prozesses mit Azure Resource Manager-Vorlagen finden Sie unter Erstellen einer Metrikwarnung mit Azure Resource Manager-Vorlagen.

Anzeigen der Verfügbarkeitstestergebnisse

In diesem Abschnitt wird erläutert, wie Verfügbarkeitstestergebnisse im Azure-Portal überprüft und die Daten mithilfe von Log Analytics abgefragt werden. Verfügbarkeitstestergebnisse können sowohl in Linienansicht als auch in Punktdiagrammen visualisiert werden.

Überprüfen der Verfügbarkeit

Überprüfen Sie zunächst das Diagramm auf der Registerkarte Verfügbarkeit Ihrer Application Insights-Ressource.

Standardtest
TrackAvailability

Screenshot der Seite „Verfügbarkeit“ mit hervorgehobener Schaltfläche „Aktualisieren“

Das Punktdiagramm zeigt Stichproben der Testergebnisse an, die Diagnosedetails zu Testschritten enthalten. Die Test-Engine speichert Diagnosedetails für Tests mit Fehlern. Für erfolgreiche Tests werden Diagnosedetails für eine Teilmenge der Ausführungen gespeichert. Bewegen Sie den Mauszeiger über einen der grünen oder roten Punkte, um den Test, den Testnamen und den Standort anzuzeigen.

Screenshot der Linienansicht

Wählen Sie einen bestimmten Test oder Standort aus. Oder verringern Sie den Zeitraum, um weitere Ergebnisse um den gewünschten Zeitraum anzuzeigen. Verwenden Sie den Such-Explorer, um Ergebnisse aus allen Ausführungen anzuzeigen. Sie können auch Log Analytics-Abfragen verwenden, um benutzerdefinierte Berichte für diese Daten auszuführen.

Wählen Sie zum Anzeigen der End-to-End-Transaktionsdetails unter Drilldown die Option Erfolgreich oder Fehler aus. Wählen Sie dann ein Beispiel aus. Sie können auf die End-to-End-Transaktionsdetails auch zugreifen, indem Sie im Graphen einen Datenpunkt auswählen.

Screenshot des Auswählens eines Beispiels für einen Verfügbarkeitstest.

Überprüfen und Bearbeiten von Tests

Wenn Sie einen Test bearbeiten, vorübergehend deaktivieren oder löschen möchten, klicken Sie auf die drei Punkte neben dem jeweiligen Testnamen. Es kann bis zu 20 Minuten dauern, bis Konfigurationsänderungen an alle Test-Agent weitergegeben werden.

Screenshot der Testdetailansicht. Webtest bearbeiten und deaktivieren.

Eventuell möchten Sie Verfügbarkeitstests oder die damit verknüpften Warnungsregeln deaktivieren, während Sie Ihren Dienst warten.

Anleitung zum Vorgehen bei Fehlern

Einen roten Punkt auswählen.

Screenshot: Registerkarte „End-to-End-Transaktionsdetails“

Aus einem Verfügbarkeitstestergebnis können Sie die Transaktionsdetails für alle Komponenten ablesen. Mögliche nächste Schritte:

Überprüfen Sie den Bericht zur Problembehandlung, um zu ermitteln, was möglicherweise dazu geführt hat, dass der Test fehlschlägt, obwohl Ihre Anwendung aber weiterhin verfügbar ist.
Untersuchen Sie die vom Server erhaltene Antwort.
Diagnostizieren Sie den Fehler mit korrelierten serverseitigen Telemetriedaten, die während der Verarbeitung des fehlerhaften Verfügbarkeitstests gesammelt wurden.
Protokollieren Sie in Git oder Azure Boards ein Problem oder ein Arbeitselement, um das Problem nachzuverfolgen. Der Fehler enthält einen Link zu diesem Ereignis.
Öffnen Sie das Webtestergebnis in Visual Studio.

Weitere Informationen zur umfassenden Transaktionsdiagnose finden Sie in der Dokumentation zur Transaktionsdiagnose.

Wählen Sie die Ausnahmezeile aus, um Details zur serverseitigen Ausnahme anzuzeigen, die beim synthetischen Verfügbarkeitstest zu dem Fehler geführt hat. Sie können auch die Debugmomentaufnahme abrufen, um eine umfangreichere Diagnose auf Codeebene durchzuführen.

Screenshot der serverseitigen Diagnose

Zusätzlich zu den Rohergebnissen können Sie im Metrik-Explorer zwei wichtige Verfügbarkeitsmetriken abrufen:

Verfügbarkeit: Prozentsatz der erfolgreichen Tests für alle Testausführungen
Testdauer: Durchschnittliche Testdauer für alle Ausführungen

Abfragen in Log Analytics

Sie können Log Analytics verwenden, um Ihre Verfügbarkeitsergebnisse, Abhängigkeiten und mehr anzuzeigen. Weitere Informationen zu Log Analytics finden Sie unter Übersicht über Protokollabfragen.

Migrieren von Verfügbarkeitstests

In diesem Artikel führen wir Sie durch den Prozess der Migration von klassischen URL-Pingtests zu den modernen und effizienten Standardtests.

Wir vereinfachen diesen Prozess, indem wir klare Schritt-für-Schritt-Anweisungen bereitstellen, die einen nahtlosen Übergang sicherstellen und Ihre Anwendungen mit den neuesten Überwachungsfunktionen ausstatten.

Migrieren klassischer URL-Pingtests zu Standardtests

Die folgenden Schritte führen Sie durch den Prozess der Erstellung von Standardtests, die die Funktionalität Ihrer URL-Pingtests replizieren. Dies erleichtert Ihnen die ersten Schritte mit den erweiterten Features von Standardtests unter Verwendung Ihrer zuvor erstellten URL-Pingtests.

Wichtig

Mit der Ausführung von Standardtests sind Kosten verbunden. Nachdem Sie einen Standardtest erstellt haben, werden Ihnen Testausführungen in Rechnung gestellt. Informieren Sie sich auf der Seite Azure Monitor – Preise, bevor Sie mit diesem Prozess beginnen.

Voraussetzungen

Ein beliebiger URL-Pingtests in Application Insights
Zugriff auf Azure PowerShell

Erste Schritte

Stellen Sie mit Azure PowerShell (Connect-AzAccount + Set-AzContext) eine Verbindung mit Ihrem Abonnement her.

Auflisten aller URL-Ping-Tests im aktuellen Abonnement:

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

Suchen Sie nach dem URL-Ping-Test, den Sie migrieren möchten, und notieren Sie seine Ressourcengruppe und seinen Namen.

Die folgenden Befehle erstellen einen Standardtest mit der gleichen Logik wie der URL-Pingtest.

Hinweis

Die folgenden Befehle funktionieren sowohl für HTTP- als auch für HTTPS-Endpunkte, die in Ihren URL-Pingtests verwendet werden.

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

Der neue Standardtest verfügt standardmäßig nicht über Warnungsregeln, sodass keine falsch positiven Warnungen erstellt werden. Es werden keine Änderungen an Ihrem URL-Pingtest vorgenommen. Sie können ihn daher weiterhin für Warnungen verwenden.
Nachdem Sie die Funktionalität des neuen Standardtests überprüft haben, aktualisieren Sie Ihre Warnungsregeln, die auf den URL-Pingtest verweisen, um stattdessen auf den Standardtest zu verweisen. Anschließend deaktivieren oder löschen Sie den URL-Pingtest.
Um einen URL-Pingtest mit Azure PowerShell zu löschen, können Sie den folgenden Befehl verwenden:
```
Remove-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
```

Testen hinter einer Firewall

Um die Endpunktverfügbarkeit hinter Firewalls sicherzustellen, aktivieren Sie öffentliche Verfügbarkeitstests, oder führen Sie Verfügbarkeitstests in getrennten Szenarien oder in Szenarien ohne eingehenden Datenverkehr aus.

Aktivierung öffentlicher Verfügbarkeitstests

Stellen Sie sicher, dass Ihre interne Website über einen öffentlichen DNS-Eintrag (Domain Name System) verfügt. Verfügbarkeitstests schlagen fehl, wenn der DNS-Eintrag nicht aufgelöst werden kann. Weitere Informationen finden Sie unter Hinzufügen eines A-Datensatzes für Ihre benutzerdefinierte Domäne.

Warnung

Die vom Verfügbarkeitstestdienst verwendeten IP-Adressen werden freigegeben und können Ihre durch eine Firewall geschützten Dienstendpunkte anderen Tests zur Verfügung stellen. Die IP-Adressfilterung allein schützt den Datenverkehr Ihres Diensts nicht, daher wird empfohlen, zusätzliche benutzerdefinierte Header hinzuzufügen, um den Ursprung der Webanforderung zu überprüfen. Weitere Informationen finden Sie unter Diensttags für virtuelle Netzwerke.

Authentifizieren von Datenverkehr

Legen Sie benutzerdefinierte Header in Standardverfügbarkeitstests fest, um Datenverkehr zu überprüfen.

Generieren Sie ein Token oder eine GUID, um den Datenverkehr von Ihren Verfügbarkeitstests zu identifizieren.
Fügen Sie den benutzerdefinierten Header „X-Customer-InstanceId“ mit dem Wert ApplicationInsightsAvailability:<GUID generated in step 1> unterhalb des Abschnitts „Standardtestinformationen“ hinzu, wenn Sie Ihre Verfügbarkeitstests erstellen oder aktualisieren.
Stellen Sie sicher, dass Ihr Dienst überprüft, ob eingehender Datenverkehr den in den vorherigen Schritten definierten Header und Wert enthält.

Legen Sie alternativ das Token als Abfrageparameter fest. Beispiel: https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your guid>.

Konfigurieren Sie die Firewall so, dass eingehende Anforderungen von Verfügbarkeitstests zugelassen werden.

Hinweis

Dieses Beispiel gilt spezifisch für die Verwendung der Diensttags von Netzwerksicherheitsgruppen. Viele Azure-Dienste akzeptieren Diensttags, die jeweils unterschiedliche Konfigurationsschritte erfordern.

Verwenden Sie Diensttags, um die Aktivierung von Azure-Diensten zu vereinfachen, ohne einzelne IPs zu autorisieren oder eine aktuelle IP-Liste zu verwalten. Wenden Sie diese Tags auf Azure Firewall und Netzwerksicherheitsgruppen an, sodass der Verfügbarkeitstestdienst auf Ihre Endpunkte zugreifen kann. Das Diensttag ApplicationInsightsAvailability gilt für alle Verfügbarkeitstests.
1. Wenn Sie Azure-Netzwerksicherheitsgruppen verwenden, wechseln Sie zu Ihrer Ressource für Netzwerksicherheitsgruppen, und wählen Sie unter Einstellungen die Option Eingangssicherheitsregeln aus. Wählen Sie anschließend Hinzufügen.
2. Wählen Sie als Nächstes Diensttag als Quelle und ApplicationInsightsAvailability als Quelldiensttag aus. Verwenden Sie die offenen Ports 80 (HTTP) und 443 (HTTPS) für eingehenden Datenverkehr vom Diensttag.
Um den Zugriff zu verwalten, wenn sich Ihre Endpunkte außerhalb von Azure befinden oder Diensttags keine Option sind, setzen Sie die IP-Adressen unserer Webtest-Agents auf die Positivliste. Sie können IP-Adressbereiche mithilfe von PowerShell, der Azure CLI oder eines REST-Aufrufs mit der Diensttag-API abfragen. Eine umfassende Liste der aktuellen Diensttags und ihrer IP-Adressdetails können Sie in dieser JSON-Datei herunterladen.
1. Wählen Sie in Ihrer Ressource für Netzwerksicherheitsgruppen unter Einstellungen die Option Eingangssicherheitsregeln aus. Wählen Sie anschließend Hinzufügen.
2. Wählen Sie als Nächstes IP-Adressen als Quelle aus. Fügen Sie anschließend unter „Quell-IP-Adressen/CIDR-Bereiche“ Ihre IP-Adressen in einer durch Kommas getrennten Liste hinzu.

Getrenntes Szenario oder Szenario ohne Zugriff

Verbinden Sie Ihre Application Insights-Ressource mithilfe von Azure Private Link mit Ihrem internen Dienstendpunkt.
Schreiben Sie benutzerdefinierten Code zum regelmäßigen Testen Ihres internen Servers oder der Endpunkte. Senden Sie die Ergebnisse mithilfe der TrackAvailability()-API im Core SDK-Paket an Application Insights.

Unterstützte TLS-Konfigurationen

Um eine erstklassige Verschlüsselung bereitzustellen, verwenden alle Verfügbarkeitstests Transport Layer Security (TLS) 1.2 und 1.3 höher als Verschlüsselungsmechanismus. Darüber hinaus werden die folgenden Verschlüsselungssammlungen und Elliptische Kurven auch in jeder Version unterstützt.

Hinweis

TLS 1.3 ist derzeit nur in folgenden Verfügbarkeitstestregionen verfügbar: NorthCentralUS, CentralUS, EastUS, SouthCentralUS und WestUS.

TLS 1.2

Verschlüsselungssammlungen

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 Kurven

NistP384
NistP256

TLS 1.3

Verschlüsselungssammlungen

TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256

Elliptische Kurven:

NistP384
NistP256

Veraltete TLS-Konfiguration

Warnung

Am 31. Oktober 2024 werden in Übereinstimmung mit der Abkündigung von TLS in Azure TLS 1.0/1.1-Protokollversionen und die unten aufgeführten veralteten TLS 1.2/1.3-Verschlüsselungsverfahren und Elliptische Kurven für Anwendungseinblick-Verfügbarkeitstests eingestellt.

TLS 1.0 und TLS 1.1

Protokollversionen werden nicht mehr unterstützt.

TLS 1.2

Verschlüsselungssammlungen

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 Kurven:

curve25519

TLS 1.3

Elliptische Kurven

curve25519

Problembehandlung

Warnung

Wir haben TLS 1.3 kürzlich in Verfügbarkeitstests aktiviert. Wenn daher neue Fehlermeldungen angezeigt werden, stellen Sie sicher, dass Clients, die unter Windows Server 2022 mit aktiviertem TLS 1.3 ausgeführt werden, eine Verbindung mit Ihrem Endpunkt herstellen können. Wenn Sie dies nicht tun können, können Sie die vorübergehende Deaktivierung von TLS 1.3 auf Ihrem Endpunkt in Betracht ziehen, damit Verfügbarkeitstests auf ältere TLS-Versionen zurückgreifen.
Weitere Informationen finden Sie im Artikel über Problembehandlung. Informationen finden Sie in dem dedizierten Artikel zur Problembehandlung.

Arbeitsmappe für Downtime, SLA und Ausfälle

In diesem Artikel wird eine einfache Methode vorgestellt, mit der Sie die Vereinbarung zum Servicelevel (Service Level Agreement, SLA) für Webtests über eine einzelne zentralisierte Benutzeroberfläche in Ihren Application Insights-Ressourcen und Azure-Abonnements berechnen und melden können. Der Bericht zu Downtime und Ausfällen bietet leistungsstarke vorgefertigte Abfragen und Datenvisualisierungen, die Ihnen ein besseres Verständnis der Konnektivität Ihrer Kunden, der typischen Antwortzeiten von Anwendungen und der aufgetretenen Ausfallzeiten ermöglichen.

Die SLA-Arbeitsmappenvorlage kann über Ihre Application Insights-Ressource auf zwei Arten aufgerufen werden:

Öffnen Sie den Bereich Verfügbarkeit, und wählen Sie dann am oberen Bildschirmrand SLA-Bericht aus.
Öffnen Sie den Bereich Arbeitsmappen, und wählen Sie dann Downtime und Ausfälleaus.

Parameterflexibilität

Die in der Arbeitsmappe festgelegten Parameter beeinflussen den Rest des Berichts.

Subscriptions, App Insights Resources und Web Test: Diese Parameter legen allgemeine Ressourcenoptionen fest. Sie basieren auf Log Analytics-Abfragen und werden in jeder Berichtsabfrage verwendet.
Failure Threshold und Outage Window: Mit diesen Parametern können Sie eigene Kriterien für einen Dienstausfall festlegen. Ein Beispiel für ein solches Kriterium wäre etwa eine Application Insights-Verfügbarkeitswarnung, die auf einem Zähler für ausgefallene Standorte innerhalb eines bestimmten Zeitraums basiert. Der typische Schwellenwert beträgt drei Standorte in einem Zeitfenster von fünf Minuten.
Maintenance Period: Mit diesem Parameter können Sie Ihre typische Wartungshäufigkeit angeben. Maintenance Window ist ein Datumsselektor für einen beispielhaften Wartungszeitraum. Alle Daten, die während des identifizierten Zeitraums auftreten, werden in den Ergebnissen ignoriert.
Availability Target %: Dieser Parameter gibt Ihren angestrebten Zielwert an und akzeptiert benutzerdefinierte Werte.

Seite „Übersicht“

Die Übersichtsseite enthält allgemeine Informationen:

SLA gesamt (ohne Wartungszeiträume, sofern definiert)
End-to-End-Ausfallinstanzen
Anwendungsdowntime

Ausfallinstanzen werden, basierend auf Ihren Ausfallparametern, durch den Zeitraum ab dem ersten Auftreten von Fehlern für einen Test bis zur erfolgreichen Beendigung des Tests definiert. Wenn bei einem Test ab 8:00 Uhr Fehler auftreten und der Test um 10:00 Uhr erfolgreich fortgesetzt werden kann, wird dieser gesamte Datenzeitraum als Ausfall gewertet.

Sie können auch den längsten Ausfall untersuchen, der innerhalb Ihres Berichtszeitraums aufgetreten ist.

Für einige Tests können Sie zur weiteren Untersuchung eine Verknüpfung zurück zur Application Insights-Ressource einfügen. Dies ist jedoch nur in einer arbeitsbereichsbasierten Application Insights-Ressource möglich.

Downtime, Ausfälle und Fehler

Auf der Registerkarte Ausfälle und Downtime finden Sie Informationen zu den Ausfällen insgesamt sowie die nach Test aufgeschlüsselte Gesamtausfallzeit.

Die Registerkarte Fehler nach Standort umfasst eine geografische Karte mit den Teststandorten, an denen ein Fehler aufgetreten ist, um Sie bei der Identifizierung potenziell problematische Verbindungsbereiche zu unterstützen.

Bearbeiten des Berichts

Sie können den Bericht wie jede andere Azure Monitor-Arbeitsmappe bearbeiten.

Screenshot der Auswahl der Schaltfläche „Bearbeiten“ zum Ändern der Visualisierung in ein Kreisdiagramm.

Sie können die Abfragen oder Visualisierungen basierend auf den Anforderungen Ihres Teams anpassen.

Log Analytics

Die Abfragen können alle in Log Analytics ausgeführt und in anderen Berichten oder auf anderen Dashboards verwendet werden.

Entfernen Sie die Parametereinschränkung, und verwenden Sie die Core-Abfrage.

Sie können den Bericht mit Ihren Teams und der Geschäftsführung teilen oder zur weiteren Verwendung an ein Dashboard anheften. Der Benutzer muss über Leseberechtigung/Zugriff auf die Application Insights-Ressource verfügen, in der die eigentliche Arbeitsmappe gespeichert ist.

Häufig gestellte Fragen

Dieser Abschnitt enthält Antworten auf häufig gestellte Fragen.

Allgemein

Kann ich Verfügbarkeitstests auf einem Intranetserver ausführen?

Unsere Webtests werden auf Points of Presence aufgeführt, die über den gesamten Globus verteilt sind. Es gibt zwei Lösungen:

Tür in der Firewall: Lassen Sie Anforderungen von der umfangreichen und änderbaren Liste von Webtest-Agents an Ihren Server zu.
Benutzerdefinierter Code: Schreiben Sie eigenen Code, um aus dem Intranet regelmäßig Anforderungen an den Server zu senden. Sie können zu diesem Zweck Visual Studio-Webtests ausführen. Der Tester kann die Ergebnisse mithilfe der TrackAvailability()-API an Application Insights senden.

Was ist die Benutzer-Agent-Zeichenfolge für Verfügbarkeitstests?

Die Zeichenfolge des Benutzer-Agenten lautet: Mozilla/5.0 (kompatibel; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights).

TLS-Unterstützung

Wie wirkt sich diese Abkündigung auf mein Webtestverhalten aus?

Verfügbarkeitstests dienen als verteilter Client an jedem der unterstützten Webtestspeicherorte. Jedes Mal, wenn ein Webtest ausgeführt wird, versucht der Verfügbarkeitstestdienst, sich an den Remoteendpunkt zu wenden, der in der Webtestkonfiguration definiert ist. Es wird eine TLS-Client-Hello-Nachricht gesendet, die alle derzeit unterstützten TLS-Konfigurationen enthält. Wenn der Remoteendpunkt eine gemeinsame TLS-Konfiguration mit dem Verfügbarkeitstestclient gemeinsam verwendet, ist der TLS-Handshake erfolgreich. Andernfalls schlägt der Webtest mit einem TLS-Handshake-Fehler fehl.

Wie kann ich sicherstellen, dass mein Webtest nicht betroffen ist?

Um Auswirkungen zu vermeiden, muss jeder Remoteendpunkt (einschließlich abhängiger Anforderungen), mit denen Ihr Webtest interagiert, mindestens eine Kombination aus derselben Protokollversion, Verschlüsselungssammlungen und Elliptische Kurven unterstützen, die der Verfügbarkeitstest durchführt. Wenn der Remoteendpunkt die erforderliche TLS-Konfiguration nicht unterstützt, muss er mit Unterstützung für eine Kombination der oben genannten nach der Abkündigung der TLS-Konfiguration aktualisiert werden. Diese Endpunkte können durch Anzeigen der Transaktionsdetails Ihres Webtests ermittelt werden (idealerweise für eine erfolgreiche Webtestausführung).

Wie kann ich überprüfen, welche TLS-Konfiguration ein Remoteendpunkt unterstützt?

Es stehen mehrere Tools zur Verfügung, um zu testen, welche TLS-Konfiguration ein Endpunkt unterstützt. Eine Möglichkeit wäre, dem auf dieser Seite detaillierten Beispiel zu folgen. Wenn Ihr Remoteendpunkt nicht über das öffentliche Internet verfügbar ist, müssen Sie sicherstellen, dass Sie die TLS-Konfiguration überprüfen, die auf dem Remoteendpunkt von einem Computer unterstützt wird, auf den der Endpunkt zugreifen kann.

Hinweis

Für Schritte zum Aktivieren der erforderlichen TLS-Konfiguration auf Ihrem Webserver empfiehlt es sich, sich an das Team zu wenden, das die Hostplattform besitzt, auf der Ihr Webserver ausgeführt wird, wenn der Prozess nicht bekannt ist.

Nach dem 31. Oktober 2024, was wird das Webtestverhalten für betroffene Tests sein?

Es gibt keinen Ausnahmetyp, bei dem sich alle von dieser Abkündigung betroffenen TLS-Handshake-Fehler selbst darstellen. Die häufigste Ausnahme, mit der Ihr Webtest fehlschlägt, wäre jedoch The request was aborted: Couldn't create SSL/TLS secure channel. Außerdem sollten Sie alle TLS-bezogenen Fehler im TLS-Transport-Problembehandlungsschritt für das Webtestergebnis sehen können, das potenziell beeinträchtigt wird.

Kann ich anzeigen, welche TLS-Konfiguration derzeit von meinem Webtest verwendet wird?

Die TLS-Konfiguration, die während einer Webtestausführung ausgehandelt wurde, kann nicht angezeigt werden. Solange der Remoteendpunkt allgemeine TLS-Konfigurationen mit Verfügbarkeitstests unterstützt, sollten nach der Abkündigung keine Auswirkungen angezeigt werden.

Welche Komponenten wirken sich auf die Abkündigung im Verfügbarkeitstestdienst aus?

Die in diesem Dokument beschriebene TLS-Abkündigung sollte sich nur auf das Ausführungsverhalten des Verfügbarkeitstest-Webtests nach dem 31. Oktober 2024 auswirken. Weitere Informationen zur Interaktion mit dem Verfügbarkeitstestdienst für CRUD-Vorgänge finden Sie unter Azure Resource Manager TLS Support. Diese Ressource enthält weitere Details zu TLS-Support und zu Abkündigungs-Zeitachsen.

Wo erhalte ich TLS-Unterstützung?

Allgemeine Fragen zum Legacy-TLS-Problem finden Sie unter Lösen von TLS-Problemen.

Freigeben über

Application Insights-Verfügbarkeitstests

Arten von Verfügbarkeitstests

Verfügbarkeitstest erstellen

Voraussetzungen

Erste Schritte

Erfolgskriterien

Verfügbarkeitswarnungen

Auffüllungstags für den Standort

Azure

Azure Government

Microsoft Azure von 21Vianet

Aktivieren von Warnungen

Benachrichtigungskriterien

Ändern der Warnungskriterien

Erstellen einer benutzerdefinierten Warnungsregel

Automatisieren von Warnungen

Anzeigen der Verfügbarkeitstestergebnisse

Überprüfen der Verfügbarkeit

Überprüfen und Bearbeiten von Tests

Anleitung zum Vorgehen bei Fehlern

Abfragen in Log Analytics

Migrieren von Verfügbarkeitstests

Migrieren klassischer URL-Pingtests zu Standardtests

Voraussetzungen

Erste Schritte

Testen hinter einer Firewall

Aktivierung öffentlicher Verfügbarkeitstests

Authentifizieren von Datenverkehr

Konfigurieren Sie die Firewall so, dass eingehende Anforderungen von Verfügbarkeitstests zugelassen werden.

Getrenntes Szenario oder Szenario ohne Zugriff

Unterstützte TLS-Konfigurationen

TLS 1.2

TLS 1.3

Veraltete TLS-Konfiguration

TLS 1.0 und TLS 1.1

TLS 1.2

TLS 1.3

Problembehandlung

Arbeitsmappe für Downtime, SLA und Ausfälle

Parameterflexibilität

Seite „Übersicht“

Downtime, Ausfälle und Fehler

Bearbeiten des Berichts

Log Analytics

Zugriff und Freigabe

Häufig gestellte Fragen

Allgemein

Kann ich Verfügbarkeitstests auf einem Intranetserver ausführen?

Was ist die Benutzer-Agent-Zeichenfolge für Verfügbarkeitstests?

TLS-Unterstützung

Wie wirkt sich diese Abkündigung auf mein Webtestverhalten aus?

Wie kann ich sicherstellen, dass mein Webtest nicht betroffen ist?

Wie kann ich überprüfen, welche TLS-Konfiguration ein Remoteendpunkt unterstützt?

Nach dem 31. Oktober 2024, was wird das Webtestverhalten für betroffene Tests sein?

Kann ich anzeigen, welche TLS-Konfiguration derzeit von meinem Webtest verwendet wird?

Welche Komponenten wirken sich auf die Abkündigung im Verfügbarkeitstestdienst aus?

Wo erhalte ich TLS-Unterstützung?

Nächste Schritte

Feedback

Feedback

Zusätzliche Ressourcen