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.
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,HEADundPOST), 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.
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: 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.
Verfügbarkeitstest erstellen
Voraussetzungen
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 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. Wir parsen nur 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 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. 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. Erfolgskriterien 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 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 als Erfolg gezählt. Die Zahl 200 ist der Code, der angibt, dass eine normale Webseite zurückgegeben wird. 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.
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 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 Standard- oder URL-Pingtests mithilfe von Azure Resource Manager können für das geografische Standortattribut die folgenden Populationstags verwendet werden.
| Anbieter | Anzeigename | Auffüllungsname |
|---|---|---|
| Azure | ||
| 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 | ||
| 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, 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
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, öffnen Sie daneben das Kontextmenü, und wählen Sie die Seite zum Öffnen von Regeln (Warnungen) 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, 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.
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, ö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:
Wählen Sie eine Application Insights-Ressource in der Oberfläche Metriken und dann eine Verfügbarkeitsmetrik aus.
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.
Tipp
Eventuell möchten Sie Verfügbarkeitstests oder die damit verknüpften Warnungsregeln deaktivieren, während Sie Ihren Dienst warten.
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.
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 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);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.
Ü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 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 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. Das Diensttag 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 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.
Ö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 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.
TLS 1.3 ist derzeit nur in folgenden Verfügbarkeitstestregionen verfügbar: NorthCentralUS, CentralUS, EastUS, SouthCentralUS und WestUS.
| Version | Verschlüsselungssammlungen | 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 |
Veraltete TLS-Konfiguration
Wichtig
Am 1. März 2025 werden die Versionen 1.0/1.1 des TLS-Protokolls und die aufgeführten veralteten Verschlüsselungsverfahren und elliptischen Kurven, die auf TLS 1.2/1.3 basieren, im Rahmen der Azure-weiten Einstellung von TLS für Application Insights-Verfügbarkeitstests eingestellt.
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üsselungssammlungen | 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 |
Problembehandlung
Warnung
Wir haben TLS 1.3 kürzlich in Verfügbarkeitstests aktiviert. Wenn Ihnen infolge 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 zur 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 ResourcesundWeb Test: Diese Parameter legen allgemeine Ressourcenoptionen fest. Sie basieren auf Log Analytics-Abfragen und werden in jeder Berichtsabfrage verwendet.Failure ThresholdundOutage 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 Windowist 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.
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 1. März 2025, 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 1. März 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.