Application Insights-Verfügbarkeitstests

2025-06-05

Mit Application Insights können Sie wiederkehrende Webtests einrichten, die die Verfügbarkeit und Reaktionsfähigkeit Ihrer Website oder Anwendung von verschiedenen Punkten auf der ganzen Welt aus überwachen. Diese Verfügbarkeitstests senden in regelmäßigen Abständen Webanforderungen an Ihre Anwendung und benachrichtigen Sie, wenn Ihre Anwendung nicht reagiert oder die Antwortzeit zu lang ist.

Verfügbarkeitstests erfordern keine Änderungen an der Website oder Anwendung, die Sie testen. Sie funktionieren für jeden HTTP- oder HTTPS-Endpunkt, auf den über das öffentliche Internet zugegriffen werden kann, einschließlich REST-APIs, von denen Ihr Dienst abhängt. Dies bedeutet, dass Sie nicht nur Ihre eigenen Anwendungen, sondern auch externe Dienste überwachen können, die für die Funktionalität Ihrer Anwendung von entscheidender Bedeutung sind. Sie können bis zu 100 Verfügbarkeitstests pro Application Insights-Ressource erstellen.

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

Erfahren Sie, wie Sie einen Standardtest erstellen.
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.

Erfahren Sie, wie Sie einen benutzerdefinierten TrackAvailability-Test erstellen.
(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: Application Insights eingestellt mehrstufige Webtests am 31. August 2024. Um die Verfügbarkeitsüberwachung aufrechtzuerhalten, wechseln Sie vor diesem Datum zu alternativen Verfügbarkeitstests. Nach der Deaktivierung entfernt die Plattform die zugrunde liegende Infrastruktur, was dazu führt, dass verbleibende mehrstufige Tests fehlschlagen.
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.

Voraussetzungen

Arbeitsbereichsbasierte Application Insights-Ressource

Erste Schritte

Wechseln Sie zur Application Insights-Ressource, und öffnen Sie den Bereich Verfügbarkeit.
Wählen Sie in der oberen Navigationsleiste Standardtest hinzufügen aus.

Geben Sie den Namen Ihres Tests, die URL und andere Einstellungen ein, die in der folgenden Tabelle beschrieben sind, und klicken Sie auf Erstellen.

Abschnitt	Einstellung	Beschreibung
Basic Information (Grundlegende Informationen)
	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 ein bisschen nutzen. Wenn die URL in eine Umleitung aufgelöst wird, werden bis zu 10 Umleitungen verfolgt.
	Abhängige Anforderungen analysieren	Der Test lädt Bilder, Skripts, Formatvorlagendateien und andere Ressourcen von der Webseite, die getestet wird. Sie zeichnet die Antwortzeit auf, einschließlich der Zeit zum Abrufen dieser Dateien. Der Test schlägt fehl, wenn nicht alle Ressourcen innerhalb des Timeouts heruntergeladen werden können. Wenn Sie die Option nicht aktivieren, lädt der Test nur die Datei unter der angegebenen URL. Wenn Sie die Überprüfung aktivieren, wird sie strenger und kann in Situationen fehlschlagen, die beim manuellen Durchsuchen nicht erkannt würden. Der Test analysiert bis zu 15 abhängige Anforderungen.
	Wiederholungen für Verfügbarkeitstestfehler aktivieren	Wenn der Test fehlschlägt, 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.
	SSL-Zertifikatgültigkeit aktivieren	Um das richtige Setup zu bestätigen, überprüfen Sie das SSL-Zertifikat auf Ihrer Website. Stellen Sie sicher, dass sie ordnungsgemäß, gültig, vertrauenswürdig installiert ist und keine Fehler für Benutzer generiert. Der Verfügbarkeitstest überprüft nur das SSL-Zertifikat auf der endgültigen umgeleiteten URL.
	Proaktive Lebensdauerüberprüfung	Mit dieser Einstellung können Sie einen festgelegten Zeitraum definieren, nach dem Ihr SSL-Zertifikat abläuft. Nach Ablauf wird Ihr Test fehlschlagen.
	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.
Informationen zum Standardtest
	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.
	Benutzerdefinierte Header hinzufügen	Schlüssel-Wert-Paare zur Definition der Betriebsparameter. Die Header "Host" und "User-Agent" sind in Verfügbarkeitstests reserviert und können nicht geändert oder überschrieben werden.
Erfolgskriterien
	Test-Timeout	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 werden. Wenn Sie Abhängige Anforderungen analysieren ausgewählt haben, müssen alle Bilder, Stildateien, Skripte und andere abhängige Ressourcen innerhalb dieses Zeitraums eingehen.
	HTTP-Antwort	Der zurückgegebene Statuscode wird als Erfolg gewertet. Die Zahl 200 ist der Code, der angibt, dass eine normale Webseite zurückgegeben wird.
	Inhaltsübereinstimmung	Eine Zeichenfolge, z. B. „Willkommen!“ Wir vergewissern uns, dass in jeder Antwort eine exakte Übereinstimmung unter Berücksichtigung der Groß-und Kleinschreibung vorkommt. Dies muss eine einfache Zeichenfolge 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 für Entwickler in das Schreiben und Verwalten potenziell komplexer benutzerdefinierter Code.

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

Dieses Beispiel wurde ausschließlich dazu entworfen, die Funktionsweise des API-Aufrufs TrackAvailability() innerhalb einer Azure Functions-App zu veranschaulichen. Es zeigt nicht, wie der zugrunde liegende HTTP-Testcode oder die Geschäftslogik geschrieben wird, der bzw. die erforderlich ist, um dieses Beispiel in einen voll funktionsfähigen Verfügbarkeitstest umzuwandeln.

Voraussetzungen

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

Erste Schritte

Hinweis

Für diese Anleitung benötigen Sie entweder den App Service- oder den Functions Premium-Plan, um Code im App Service-Editor bearbeiten zu können. Sie müssen auch eine Laufzeitversion auswählen, die das In-Process-Modell unterstützt.

Wenn Sie hinter einem virtuellen Netzwerk testen oder nicht lizenzierte Endpunkte testen, müssen Sie den Functions Premium-Plan verwenden.

Erstellen einer Timertriggerfunktion

Erstellen Sie eine Azure Functions-Ressource, und bedenken Sie dabei die folgenden Hinweise:
- Wenn Sie noch keine Application Insights-Ressource für Ihre von einem Timer ausgelöste Funktion haben, wird sie standardmäßig erstellt, wenn Sie eine Azure Functions-App erstellen.
- Wenn Sie bereits über eine Application Insights-Ressource verfügen, wechseln Sie zur Registerkarte Überwachung, während Sie die Azure Functions-App erstellen, und wählen Sie den Namen Ihrer bestehenden Ressource aus dem Application Insights-Dropdown aus, oder geben Sie diesen ein:
Folgen Sie den Anweisungen zum Erstellen einer von einem Timer ausgelösten Funktion.

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

Wechseln Sie zu Ihrer bereitgestellten Azure Functions-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/"); 
    } 
}

Ersetzen Sie den in run.csx vorhandenen Code durch den folgenden:

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

Hinweis

Tests, die mit TrackAvailability() erstellt wurden, werden mit CUSTOM neben dem Testnamen angezeigt.

Screenshot der Verfügbarkeitserfahrung mit zwei verschiedenen aufgelisteten Tests.

Verfügbarkeitswarnungen

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

Einstellung	Beschreibung
Nahezu in Echtzeit	Es wird empfohlen, Warnungen in nahezu Echtzeit zu verwenden. Die Konfiguration dieser Art von Warnung erfolgt, nachdem Ihr Verfügbarkeitstest erstellt wurde.
Schwellenwert für den Alarmstandort	Wir empfehlen mindestens 3 von 5 Standorten. Das optimale Verhältnis zwischen dem Schwellenwert für den Warnstandort und der Anzahl der Teststandorte ist Schwellenwert für den Warnstandort = Anzahl der Teststandorte minus 2, mit einer Mindestanzahl von fünf Teststandorten.

Auffüllungstags für den Standort

Beim Bereitstellen eines Standard- oder URL-Pingtests mithilfe von Azure Resource Manager können für das geografische Standortattribut die folgenden Populationstags verwendet werden.

Anbieter	Anzeigename	Populationsname
Azurblau
	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
	Ost-USA	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
	Vereinigtes Königreich, 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
	USGov, Virginia	usgov-va-azr
	USGov Arizona	usgov-phx-azr
	USGov Texas	usgov-tx-azr
	USDoD, Osten	usgov-ddeast-azr
	USDoD, Mitte	usgov-ddcentral-azr
Microsoft Azure, betrieben von 21Vianet
	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

Hinweis

Um Warnungen über Ihre konfigurierten Aktionsgruppen zu erhalten, legen Sie den Schweregrad der Warnungsregel und die Benachrichtigungseinstellungen in der einheitlichen Warnungsumgebung fest. Ohne die folgenden Schritte auszuführen, erhalten Sie nur In-Portal-Benachrichtigungen.

Nachdem Sie den Verfügbarkeitstest gespeichert haben, öffnen Sie das Kontextmenü neben dem erstellten Test und wählen Sie die Seite Regeln (Warnungen) öffnen aus.
Öffnen Sie die Benachrichtigung auf der Seite Warnungsregel, und wählen Sie dann in der oberen Navigationsleiste Bearbeiten aus. Hier können Sie den Schweregrad, die Regelbeschreibung und die Aktionsgruppe festlegen, die über die Benachrichtigungseinstellungen verfügen, die Sie für diese Warnungsregel verwenden möchten.

Benachrichtigungskriterien

Automatisch aktivierte Verfügbarkeitswarnungen lösen eine E-Mail aus, wenn der Endpunkt nicht verfügbar wird, und eine weitere E-Mail, sobald 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 fällt eine Stunde lang aus, und Sie richten eine E-Mail-Warnung mit einer Auswertungsintervall von 15 Minuten ein. In diesem Fall erhalten Sie nur eine E-Mail, wenn die Website ausfällt, sowie eine weitere, wenn sie wieder online ist. Sie erhalten keine Warnungen im 15-Minuten-Takt, um Sie daran zu erinnern, dass die Website noch immer nicht verfügbar ist.

Ändern der Warnungskriterien

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.

Tipp

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.

Um Änderungen am Standortschwellenwert, dem Aggregationszeitraum und der Testhäufigkeit vorzunehmen, wechseln Sie zur Seite " Warnungsregel bearbeiten " (siehe Schritt 2 unter " Benachrichtigungen aktivieren"), und wählen Sie dann die Bedingung aus, um das Configure signal logic Fenster 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 diesen Schritt 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. Mit Configure alerts der Option aus dem Menü gelangen Sie zur neuen Oberfläche, in der Sie bestimmte Tests oder Speicherorte auswählen können, an denen 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.

Ihre Verfügbarkeitstestergebnisse anzeigen

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 der Linienansicht als auch in der Streudiagramm-Ansicht visualisiert werden.

Überprüfen der Verfügbarkeit

Prüfen Sie zunächst das Diagramm im Bereich Verfügbarkeit im Azure-Portal.

Standardmäßig wird im Bereich „Verfügbarkeit“ ein Liniendiagramm angezeigt. Ändern Sie die Ansicht in Punktdiagramm (Umschaltfläche über dem Diagramm), um Beispiele der Testergebnisse anzuzeigen, die die Details der Diagnosetestschritte 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. Um den Test, den Namen des Tests und den Standort anzuzeigen, bewegen Sie den Mauszeiger über einen der grünen Punkte oder roten Kreuze.

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, das die Auswahl eines Beispiel-Tests zur Verfügbarkeit zeigt

Überprüfen und Bearbeiten von Tests

Um einen Test zu bearbeiten, vorübergehend zu deaktivieren oder zu löschen, öffnen Sie das Kontextmenü (Auslassungspunkte) neben dem Test, und wählen Sie Bearbeiten aus. Es kann bis zu 20 Minuten dauern, bis Konfigurationsänderungen an alle Test-Agent weitergegeben werden.

Tipp

Sie sollten möglicherweise Verfügbarkeitstests oder die damit verknüpften Warnungsregeln deaktivieren, während Sie Wartungsarbeiten an Ihrem Dienst durchführen.

Wenn Sie Fehler sehen

Öffnen Sie die Ansicht End-to-End-Transaktionsdetails, indem Sie ein rotes Kreuz im Streudiagramm auswählen.

Hier können Sie:

Lesen Sie den Problembehandlungsbericht, um den Grund für das Fehlschlagen des Tests zu ermitteln.
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.
Verfolgen Sie das Problem nach, indem Sie ein Issue oder ein Arbeitselement in Git oder Azure Boards erstellen. Der Fehler enthält einen Link zum Ereignis im Azure-Portal.
Ö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.

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 Ihre Verfügbarkeitsergebnisse (availabilityResults), Abhängigkeiten (dependencies) und mehr mit Log Analytics anzeigen. Weitere Informationen zu Log Analytics finden Sie unter Übersicht über Protokollabfragen.

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. Es ermöglicht Ihnen, die erweiterten Funktionen von Standardtests mit Ihren zuvor erstellten URL-Pingtests einfacher zu nutzen.

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

Jeder URL-Pingtest innerhalb von Application Insights
Zugriff auf Azure PowerShell

Erste Schritte

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

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-Pingtest, den Sie migrieren möchten, und notieren Sie seine Ressourcengruppe und seinen Namen.

Erstellen Sie mithilfe der folgenden Befehle, die für HTTP- und HTTPS-Endpunkte funktionieren, einen Standardtest mit der gleichen Logik wie der URL-Pingtest.

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

Der neue Standardtest verfügt im Standardzustand nicht über Warnungsregeln, sodass keine störenden Benachrichtigungen erstellt werden. Es werden keine Änderungen an Ihrem URL-Pingtest vorgenommen. Sie können ihn daher weiterhin für Warnungen verwenden.

Überprüfen Sie die Funktionalität des neuen Standardtests, und aktualisieren Sie die Warnungsregeln, die auf den URL-Pingtest verweisen, sodass diese stattdessen auf den Standardtest verweisen.
Deaktivieren oder löschen Sie den URL-Pingtest. Wenn Sie dazu Azure PowerShell verwenden möchten, können Sie diesen 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 Erstellen eines benutzerdefinierten Domainnamens für interne Anwendungen.

Warnung

Der Verfügbarkeitstestdienst verwendet freigegebene IP-Adressen, die Ihre firewallgeschützten Endpunkte für den Datenverkehr aus anderen Tests verfügbar machen können. Um Ihren Dienst zu schützen, verlassen Sie sich nicht allein auf die IP-Adressfilterung. Fügen Sie benutzerdefinierte Header hinzu, um den Ursprung jeder Webanforderung zu überprüfen. Weitere Informationen finden Sie unter Diensttags für virtuelle Netzwerke.

Authentifizieren von Datenverkehr

Legen Sie benutzerdefinierte Header in Standardtests fest, um den Datenverkehr zu überprüfen.

Erstellen Sie eine alphanumerische Zeichenfolge ohne Leerzeichen als Bezeichner für diesen Verfügbarkeitstest (z. B. MyAppAvailabilityTest). Ab jetzt bezeichnen wir diese Zeichenfolge als availability test string identifier (Zeichenfolgenbezeichner des Verfügbarkeitstests).
Fügen Sie den benutzerdefinierten Header X-Customer-InstanceId mit dem Wert ApplicationInsightsAvailability:<your availability test string identifier> unterhalb des Abschnitts Informationen zum Standardtest hinzu, wenn Sie 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 stattdessen den Zeichenfolgenbezeichner des Verfügbarkeitstests als Abfrageparameter fest.

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

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. Der Dienst-Tag ApplicationInsightsAvailability gilt für alle Verfügbarkeitstests.

Wenn Sie Azure-Netzwerksicherheitsgruppen verwenden, wechseln Sie zu Ihrer Netzwerksicherheitsgruppenressource, und öffnen Sie unter Einstellungen den Bereich Sicherheitsregeln für eingehenden Datenverkehr, und wählen Sie Hinzufügen aus.
Wählen Sie dann Diensttag als Quelle und ApplicationInsightsAvailability als Quelldiensttag aus. Verwenden Sie die offenen Ports 80 (HTTP) und 443 (HTTPS) für eingehenden Datenverkehr vom Service Tag.

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.

Öffnen Sie in Ihrer Netzwerksicherheitsgruppenressource unter Einstellungen den Bereich Sicherheitsregeln für eingehenden Datenverkehr, und wählen Sie Hinzufügen aus.
Wählen Sie als Nächstes IP-Adressen als Quelle aus. Fügen Sie anschließend unter Quell-IP-Adresse/CIDR-Bereiche Ihre IP-Adressen in einer durch Kommas getrennten Liste hinzu.

Getrenntes Szenario oder Szenario ohne eingehende Daten

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

Für eine erstklassige Verschlüsselung verwendet Application Insights TLS 1.2 und 1.3 (Transport Layer Security) als Verschlüsselungsmechanismus. Darüber hinaus werden die folgenden Verschlüsselungssammlungen und Elliptische Kurven auch in jeder Version unterstützt.

Version	Verschlüsselungsverfahren	Elliptische Kurven
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

Wichtig

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

Veraltete TLS-Konfigurationen (Transport Layer Security)

Wichtig

Um die Sicherheit zu verbessern, werden die folgenden TLS-Konfigurationen für Application Insights am 1. Mai 2025 eingestellt. Diese Änderung ist Teil der Azure-weiten Abschaffung des Legacy-TLS:

TLS 1.0- und TLS 1.1-Protokollversionen
Ältere TLS 1.2- und TLS 1.3-Verschlüsselungssammlungen
Legacy-TLS-elliptische Kurven

TLS 1.0 und TLS 1.1

TLS 1.0 und TLS 1.1 werden eingestellt.

TLS 1.2 und TLS 1.3

Version	Verschlüsselungsverfahren	Elliptische Kurven
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

Arbeitsmappe zu Downtime und Ausfällen

In diesem Abschnitt wird eine einfache Methode vorgestellt, mit der Sie das Service-Level-Agreement (SLA) für Webtests über eine einheitliche 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 in der oberen Navigationsleiste SLA-Bericht aus.
Öffnen Sie den Bereich Arbeitsmappen, und wählen Sie die Vorlage Downtime und Ausfälle aus.

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 gemäß Ihrer Ausfallparameter ab dem Zeitpunkt ermittelt, an dem ein Test fehlschlägt, bis er wieder erfolgreich bestanden wird. 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.

Einige Tests können mit ihrer Application Insights-Ressource verknüpft werden, um weitere Untersuchungen durchzuführen. Dies ist jedoch nur in einer arbeitsbereichsbasierten Application Insights-Ressource möglich.

Downtime, Ausfälle und Fehler

Es gibt zwei weitere Registerkarten neben der Seite Übersicht:

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.

Weitere Features

Anpassung: Sie können den Bericht wie jede andere Azure Monitor-Arbeitsmappe bearbeiten und 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.
Zugriff und Freigabe: Sie können den Bericht mit Ihren Teams und Vorgesetzten teilen oder zur weiteren Verwendung an ein Dashboard anheften. Der Benutzer muss über Leseberechtigungen und Zugriff auf die Application Insights-Ressource verfügen, in der die eigentliche Arbeitsmappe gespeichert ist.

Nächste Schritte

Informationen zur Überprüfung häufig gestellter Fragen (FAQ) finden Sie unter Verfügbarkeitstests faq und TLS-Unterstützung für Verfügbarkeitstests
Problembehandlung
Webtests: Azure Resource Manager-Vorlage
Webtest-REST-API

Freigeben über

Application Insights-Verfügbarkeitstests

Arten von Verfügbarkeitstests

Verfügbarkeitstest erstellen

Voraussetzungen

Erste Schritte

Verfügbarkeitswarnungen

Auffüllungstags für den Standort

Aktivieren von Warnungen

Benachrichtigungskriterien

Ändern der Warnungskriterien

Erstellen einer benutzerdefinierten Warnungsregel

Automatisieren von Warnungen

Ihre Verfügbarkeitstestergebnisse anzeigen

Überprüfen der Verfügbarkeit

Überprüfen und Bearbeiten von Tests

Wenn Sie Fehler sehen

Abfragen in Log Analytics

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

Unterstützte TLS-Konfigurationen

Veraltete TLS-Konfigurationen (Transport Layer Security)

TLS 1.0 und TLS 1.1

TLS 1.2 und TLS 1.3

Arbeitsmappe zu Downtime und Ausfällen

Parameterflexibilität

Seite „Übersicht“

Downtime, Ausfälle und Fehler

Weitere Features

Nächste Schritte

Feedback

Zusätzliche Ressourcen