Application Insights-Verfügbarkeitstests

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.

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.

Verfügbarkeitstest erstellen

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.

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.

Aktivieren von Warnungen

1. Nachdem Sie den Verfügbarkeitstest gespeichert haben, öffnen Sie daneben das Kontextmenü, und wählen Sie die Seite zum Öffnen von Regeln (Warnungen) aus.

   

2. Ö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, die gesendet wird, wenn der Endpunkt nicht verfügbar sowie wenn er wieder verfügbar wird. Ü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.

Um Änderungen am Standortschwellenwert, dem Aggregationszeitraum und der Testhäufigkeit vorzunehmen, öffnen Sie die Seite Warnungsregel bearbeiten (vgl. Schritt 2 unter Aktivieren der Warnungsregel), und wählen Sie die Bedingung 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 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. 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

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.

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

Anleitung zum Vorgehen bei Fehlern

Öffnen Sie die Ansicht ausführliche Transaktionsdetails, indem Sie ein rotes Kreuz im Punktdiagramm auswählen.

Mögliche nächste Schritte:

• 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 einen 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. Dies erleichtert Ihnen die ersten Schritte mit den erweiterten Features von Standardtests unter Verwendung Ihrer zuvor erstellten URL-Pingtests.

Voraussetzungen

Erste Schritte

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

2. Auflisten aller URL-Ping-Tests im aktuellen Abonnement:

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

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

4. 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);
   

   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.

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

6. 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 Hinzufügen eines A-Datensatzes für Ihre benutzerdefinierte Domäne.

Authentifizieren von Datenverkehr

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

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

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

   

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

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 Netzwerksicherheitsgruppenressource, und öffnen Sie unter Einstellungen den Bereich Sicherheitsregeln für eingehenden Datenverkehr, und wählen Sie Hinzufügen aus.

2. 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 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. Öffnen Sie in Ihrer Netzwerksicherheitsgruppenressource unter Einstellungen den Bereich Sicherheitsregeln für eingehenden Datenverkehr, und wählen Sie Hinzufügen aus.

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

1. Verbinden Sie Ihre Application Insights-Ressource mithilfe von Azure Private Link mit Ihrem internen Dienstendpunkt.

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

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

Veraltete TLS-Konfiguration

TLS 1.0 und TLS 1.1

TLS 1.0 und TLS 1.1 werden eingestellt.

TLS 1.2 und TLS 1.3

Problembehandlung

Arbeitsmappe zu Downtime und Ausfällen

In diesem Abschnitt wird eine einfache Methode vorgestellt, mit der Sie die Vereinbarung zum Servicelevel 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 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 entsprechend ihren Ausfallparametern ab dem Zeitpunkt ermittelt, an dem ein Test fehlschlägt, bis er erneut 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.

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

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.

Häufig gestellte Fragen

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

Allgemein

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

Verfügbarkeitstests werden auf Anwesenheitspunkten ausgeführt, die auf der ganzen Welt 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.

Was ist nach dem 1. Mai 2025 das Webtestverhalten für betroffene Tests?

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-Einstellung sollte sich nur auf das Ausführungsverhalten des Verfügbarkeitstest-Webtests nach dem 1. Mai 2025 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.

Nächste Schritte

• Problembehandlung
• Webtests: Azure Resource Manager-Vorlage
• Webtest-REST-API