Udostępnij za pośrednictwem

Testy dostępności usługi Application Insights

  • Artykuł

Po wdrożeniu aplikacji internetowej lub witryny internetowej można skonfigurować testy cykliczne, aby monitorować dostępność i czas odpowiedzi. Usługa Application Insights wysyła żądania internetowe do aplikacji w regularnych odstępach czasu z punktów na całym świecie. Może ona otrzymywać alerty, jeśli aplikacja nie odpowiada lub reaguje zbyt wolno. Możesz utworzyć maksymalnie 100 testów dostępności na zasób usługi Application Insights.

Testy dostępności nie wymagają żadnych zmian w testowej witrynie internetowej i działają dla dowolnego punktu końcowego HTTP lub HTTPS dostępnego z publicznego Internetu. Możesz również przetestować dostępność interfejsu API REST, od którego zależy Twoja usługa.

Uwaga

Testy dostępności są przechowywane zaszyfrowane zgodnie z zasadami przechowywania szyfrowania danych platformy Azure.

Typy testów dostępności

Istnieją cztery typy testów dostępności:

  • Test standardowy: jest to typ testu dostępności, który sprawdza dostępność witryny internetowej, wysyłając pojedyncze żądanie, podobnie jak w przypadku przestarzałego testu ping adresu URL. Oprócz sprawdzania, czy punkt końcowy odpowiada i mierzy wydajność, testy standardowe obejmują również ważność certyfikatu TLS/SSL, proaktywne sprawdzanie okresu istnienia, czasownik żądania HTTP (na przykład GET,HEAD i POST), nagłówki niestandardowe i niestandardowe dane skojarzone z żądaniem HTTP.

  • Niestandardowy test TrackAvailability: jeśli zdecydujesz się utworzyć aplikację niestandardową do uruchamiania testów dostępności, możesz użyć metody TrackAvailability(), aby wysłać wyniki do usługi Application Insights.

  • (Przestarzałe) Wieloetapowy test internetowy: możesz odtworzyć to nagranie sekwencji żądań internetowych w celu przetestowania bardziej złożonych scenariuszy. Testy internetowe wieloetapowe są tworzone w programie Visual Studio Enterprise i przekazywane do portalu, w którym można je uruchomić.

  • (Przestarzałe) Test ping adresu URL: możesz utworzyć ten test za pośrednictwem witryny Azure Portal, aby sprawdzić, czy punkt końcowy odpowiada i zmierzyć wydajność skojarzona z tą odpowiedzią. Można również ustawić niestandardowe kryteria sukcesu w połączeniu z bardziej zaawansowanymi funkcjami, takimi jak analizowanie żądań zależnych i zezwalanie na ponawianie prób.

Ważne

Istnieją dwa nadchodzące testy dostępności wycofywania:

  • Wieloetapowe testy internetowe: 31 sierpnia 2024 r. testy wieloetapowe w usłudze Application Insights zostaną wycofane. Zalecamy użytkownikom tych testów przejście do alternatywnych testów dostępności przed datą wycofania. Po tej dacie usuniemy podstawową infrastrukturę, która spowoduje przerwanie pozostałych testów wieloetapowych.

  • Testy ping adresu URL: 30 września 2026 r. testy ping adresu URL w usłudze Application Insights zostaną wycofane. Istniejące testy ping adresu URL zostaną usunięte z zasobów. Zapoznaj się z cennikiem standardowych testów i przejścia na korzystanie z nich przed 30 września 2026 r., aby upewnić się, że możesz nadal uruchamiać testy dostępności jednoetapowej w zasobach usługi Application Insights.

Tworzenie testu dostępności

Napiwek

Jeśli obecnie używasz innych testów dostępności, takich jak testy ping adresu URL, możesz dodać testy standardowe obok innych. Jeśli chcesz używać testów standardowych zamiast jednego z innych testów, dodaj test w warstwie Standardowa i usuń stary test.

Wymagania wstępne

Rozpocznij

  1. Przejdź do zasobu usługi Application Insights i wybierz okienko Dostępność .

  2. Wybierz pozycję Dodaj test standardowy.

    Zrzut ekranu przedstawiający okienko Dostępność z otwartą kartą Dodaj test w warstwie Standardowa.

  3. Wprowadź nazwę testu, adres URL i inne ustawienia opisane w poniższej tabeli. Następnie wybierz przycisk Utwórz.

    Ustawienie opis
    Adres URL Adres URL może być dowolną stroną internetową, którą chcesz przetestować, ale musi być widoczny z publicznego Internetu. Adres URL może zawierać ciąg zapytania. Możesz więc np. szybko sprawdzić działanie bazy danych. Jeśli adres URL jest rozpoznawany jako przekierowanie, zostanie prześledzonych maksymalnie 10 przekierowań.
    Analizowanie żądań zależnych Przetestuj żądania obrazów, skryptów, plików stylów i innych plików, które są częścią testowej strony internetowej. Rejestrowany czas odpowiedzi obejmuje czas poświęcony na pobieranie tych plików. Test zakończy się niepowodzeniem, jeśli nie można pomyślnie pobrać któregokolwiek z tych zasobów w przedziale czasu dla całego testu. Jeśli ta opcja nie jest zaznaczona, test żąda tylko pliku pod podanym adresem URL. Włączenie tej opcji powoduje ostrzejsze sprawdzanie. Test może zakończyć się niepowodzeniem w przypadku przypadków, które mogą nie być zauważalne podczas ręcznego przeglądania witryny. Należy pamiętać, że analizujemy tylko maksymalnie 15 żądań zależnych.
    Włączanie ponownych prób Gdy test zakończy się niepowodzeniem, zostanie ponowiony po krótkim interwale. Błąd jest zgłaszany dopiero wtedy, gdy trzy kolejne próby się nie powiodą. Kolejne testy są następnie wykonywane ze zwykłą częstotliwością. Ponawianie prób jest tymczasowo wstrzymane do czasu następnego sukcesu. Ta reguła jest stosowana niezależnie w każdej lokalizacji testu. Zalecamy tę opcję. Średnio około 80% błędów znika po ponowieniu testu.
    Test weryfikacji certyfikatu SSL Możesz zweryfikować certyfikat SSL w witrynie internetowej, aby upewnić się, że został poprawnie zainstalowany, prawidłowy, zaufany i nie powoduje żadnych błędów dla żadnego użytkownika.
    Proaktywne sprawdzanie okresu istnienia To ustawienie umożliwia zdefiniowanie określonego okresu czasu przed wygaśnięciem certyfikatu SSL. Po wygaśnięciu test zakończy się niepowodzeniem.
    Częstotliwość testowania Określa częstotliwość uruchamiania testu z każdej lokalizacji testu. Przy domyślnej częstotliwości równej 5 minut i 5 lokalizacjach testu witryna będzie testowana średnio co minutę.
    Lokalizacje testowe Nasze serwery wysyłają żądania internetowe do Twojego adresu URL z tych lokalizacji. Minimalna liczba zalecanych lokalizacji testowych wynosi pięć , aby upewnić się, że można odróżnić problemy w witrynie internetowej od problemów z siecią. Wybrać można maksymalnie 16 lokalizacji.
    Nagłówki niestandardowe Pary klucz-wartość definiujące parametry operacyjne.
    Czasownik żądania HTTP Określ, jaką akcję chcesz wykonać z żądaniem.
    Treść żądania Dane niestandardowe skojarzone z żądaniem HTTP. Możesz przekazać własne pliki, wprowadzić zawartość lub wyłączyć tę funkcję.

Kryterium sukcesu

Ustawienie opis
Limit czasu testu Zmniejsz tę wartość, aby otrzymywać alerty dotyczące powolnych odpowiedzi. Test jest liowany jako błąd, jeśli odpowiedzi z witryny nie zostały odebrane w tym okresie. W przypadku wybrania opcji Przeanalizuj żądania zależne wszystkie obrazy, pliki stylów, skrypty i inne zasoby zależne muszą zostać odebrane w tym okresie.
Odpowiedź HTTP Zwrócony kod stanu, który jest liowany jako sukces. Numer 200 to kod wskazujący, że zwracana jest normalna strona internetowa.
Dopasowanie zawartości Ciąg, taki jak "Witamy!" Sprawdzamy, czy w każdej odpowiedzi występuje dokładne dopasowanie uwzględniające wielkość liter. Musi to być zwykły ciąg znaków bez symboli wieloznacznych. Nie zapomnij, że jeśli zawartość strony ulegnie zmianie, może być konieczne jej zaktualizowanie. Tylko znaki angielskie są obsługiwane z dopasowaniem zawartości.

Alerty dostępności

Ustawienie opis
Niemal w czasie rzeczywistym Zalecamy używanie alertów niemal w czasie rzeczywistym. Skonfigurowanie tego typu alertu jest wykonywane po utworzeniu testu dostępności.
Próg lokalizacji alertu Zalecamy co najmniej 3/5 lokalizacji. Optymalną relacją między progiem lokalizacji alertu a liczbą lokalizacji testowych jest liczba progów = lokalizacji alertów — 2, z co najmniej pięcioma lokalizacjami testowymi.

Tagi populacji lokalizacji

Podczas wdrażania testu ping adresu URL dostępności przy użyciu usługi Azure Resource Manager można użyć następujących tagów populacji dla atrybutu lokalizacji geograficznej.

Azure

Display name Nazwa populacji
Australia Wschodnia emea-au-syd-edge
Brazylia Południowa latam-br-gru-edge
Środkowe stany USA us-fl-mia-edge
Azja Wschodnia apac-hk-hkn-azr
Wschodnie stany USA us-va-ash-azr
Francja Południowa (dawniej Francja Środkowa) emea-ch-zrh-edge
Francja Środkowa emea-fr-pra-edge
Japonia Wschodnia apac-jp-kaw-edge
Europa Północna emea-gb-db3-azr
Północno-środkowe stany USA us-il-ch1-azr
South Central US us-tx-sn1-azr
Southeast Asia apac-sg-sin-azr
Zachodnie Zjednoczone Królestwo emea-se-sto-edge
West Europe emea-nl-ams-azr
Zachodnie stany USA us-ca-sjc-azr
Południowe Zjednoczone Królestwo emea-ru-msa-edge

Azure Government

Display name Nazwa populacji
USGov Wirginia usgov-va-azr
Administracja USA — Arizona usgov-phx-azr
USGov Teksas usgov-tx-azr
UsDoD Wschód usgov-ddeast-azr
USDoD Central usgov-ddcentral-azr

Platforma Microsoft Azure obsługiwana przez firmę 21Vianet

Display name Nazwa populacji
Chiny Wschodnie mc-cne-azr
Chiny Wschodnie 2 mc-cne2-azr
Chiny Północne mc-cnn-azr
Chiny Północne 2 mc-cnn2-azr

Włączanie alertów

Alerty są teraz domyślnie automatycznie włączone, ale aby w pełni skonfigurować alert, musisz początkowo utworzyć test dostępności.

Uwaga

W przypadku nowych ujednoliconych alertów ważność reguły alertu i preferencje powiadomień z grupami akcji muszą być skonfigurowane w środowisku alertów. Bez poniższych kroków otrzymasz tylko powiadomienia w portalu.

  1. Po zapisaniu testu dostępności na karcie Szczegóły wybierz wielokropek wykonany przez wykonany test. Wybierz stronę Otwórz reguły (alerty).

    Zrzut ekranu przedstawiający okienko Dostępność zasobu usługi Application Insights w witrynie Azure Portal i opcję menu strony Otwórz reguły (alerty).

  2. Ustaw poziom ważności, opis reguły i grupę akcji, które mają preferencje powiadomień, których chcesz użyć dla tej reguły alertu.

Kryteria alertu

Automatycznie włączone alerty dostępności wyzwalają wiadomość e-mail, gdy zdefiniowany punkt końcowy jest niedostępny i kiedy będzie ponownie dostępny. Alerty dotyczące dostępności tworzone za pomocą tego środowiska są oparte na stanie. Po spełnieniu kryteriów alertu zostanie wygenerowany pojedynczy alert, gdy witryna internetowa zostanie wykryta jako niedostępna. Jeśli witryna internetowa jest nadal w dół przy następnym ocenie kryteriów alertu, nie wygeneruje nowego alertu.

Załóżmy na przykład, że witryna internetowa nie działa przez godzinę i skonfigurowaliśmy alert e-mail z częstotliwością oceny 15 minut. Otrzymasz wiadomość e-mail tylko wtedy, gdy witryna internetowa ulegnie awarii, a inna wiadomość e-mail, gdy wróci do trybu online. Nie będziesz otrzymywać ciągłych alertów co 15 minut, aby przypomnieć, że witryna internetowa jest nadal niedostępna.

Możesz nie chcieć otrzymywać powiadomień, gdy witryna internetowa nie działa tylko przez krótki czas, na przykład podczas konserwacji. Częstotliwość oceny można zmienić na wyższą wartość niż oczekiwany przestój, maksymalnie 15 minut. Można również zwiększyć próg lokalizacji alertu, aby wyzwalał alert tylko wtedy, gdy witryna internetowa nie działa dla określonej liczby regionów. W przypadku dłuższych zaplanowanych przestojów tymczasowo dezaktywuj regułę alertu lub utwórz regułę niestandardową. Zapewnia ona więcej opcji, aby uwzględnić przestój.

Zmienianie kryteriów alertu

Aby wprowadzić zmiany w progu lokalizacji, okresie agregacji i częstotliwości testowania, wybierz warunek na stronie edycji reguły alertu, aby otworzyć okno "Konfigurowanie logiki sygnału".

Tworzenie niestandardowej reguły alertu

Jeśli potrzebujesz zaawansowanych możliwości, możesz utworzyć niestandardową regułę alertu na karcie Alerty . Wybierz pozycję Utwórz>regułę alertu. Wybierz pozycję Metryki dla pozycji Typ sygnału, aby wyświetlić wszystkie dostępne sygnały i wybrać pozycję Dostępność.

Niestandardowa reguła alertu oferuje wyższe wartości dla okresu agregacji (do 24 godzin zamiast 6 godzin) oraz częstotliwość testu (do 1 godziny zamiast 15 minut). Dodaje również opcje do dalszego definiowania logiki, wybierając różne operatory, typy agregacji i wartości progowe.

  • Alert dotyczący lokalizacji X poza Y zgłasza błędy: reguła alertu X z lokalizacji Y jest domyślnie włączona w nowym ujednoliconym środowisku alertów podczas tworzenia nowego testu dostępności. Możesz zrezygnować, wybierając opcję "klasyczną" lub wybierając opcję wyłączenia reguły alertu. Skonfiguruj grupy akcji, aby otrzymywać powiadomienia, gdy alert jest wyzwalany, wykonując powyższe kroki. Bez tego kroku otrzymasz powiadomienia w portalu tylko wtedy, gdy reguła jest wyzwalana.

  • Alert dotyczący metryk dostępności: korzystając z nowych ujednoliconych alertów, możesz również otrzymywać alerty dotyczące zagregowanej dostępności segmentowanej i metryk czasu trwania testu:

    1. Wybierz zasób usługi Application Insights w środowisku metryk i wybierz metrykę Dostępność .

    2. Opcja Konfiguruj alerty z menu umożliwia przejście do nowego środowiska, w którym można wybrać określone testy lub lokalizacje, w których można skonfigurować reguły alertów. Możesz również skonfigurować grupy akcji dla tej reguły alertu tutaj.

  • Alert dotyczący niestandardowych zapytań analitycznych: przy użyciu nowych ujednoliconych alertów można otrzymywać alerty dotyczące niestandardowych zapytań dzienników. W przypadku zapytań niestandardowych można otrzymywać alerty dotyczące dowolnych warunków, które ułatwiają uzyskanie najbardziej niezawodnego sygnału problemów z dostępnością. Dotyczy to również wysyłania niestandardowych wyników dostępności przy użyciu zestawu SDK TrackAvailability.

    Metryki dotyczące danych dostępności obejmują wszystkie niestandardowe wyniki dostępności, które można przesłać, wywołując zestaw TrackAvailability SDK. Możesz użyć obsługi alertów dotyczących metryk, aby otrzymywać alerty dotyczące niestandardowych wyników dostępności.

Automatyzowanie alertów

Aby zautomatyzować ten proces za pomocą szablonów usługi Azure Resource Manager, zobacz Tworzenie alertu dotyczącego metryk przy użyciu szablonu usługi Azure Resource Manager.

Wyświetlanie wyników testów dostępności

W tej sekcji wyjaśniono, jak przeglądać wyniki testów dostępności w witrynie Azure Portal i wykonywać zapytania dotyczące danych przy użyciu usługi Log Analytics. Wyniki testu dostępności można wizualizować przy użyciu widoków Wykres liniowy i punktowy .

Sprawdź dostępność

Zacznij od przejrzenia wykresu na karcie Dostępność zasobu usługi Application Insights.

Zrzut ekranu przedstawiający stronę Dostępność z wyróżnionym przyciskiem Odśwież.

Widok Wykres punktowy przedstawia przykłady wyników testu, które zawierają szczegółowe informacje o kroku testu diagnostycznego. Aparat testowy przechowuje szczegółowe informacje diagnostyczne dla testów z błędami. W przypadku udanych testów szczegółowe informacje diagnostyczne są przechowywane dla podzbioru wykonań. Umieść kursor na dowolnej z zielonych/czerwonych kropek, aby wyświetlić test, nazwę testu i lokalizację.

Zrzut ekranu przedstawiający widok Wiersz.

Wybierz określony test lub lokalizację. Możesz też skrócić okres, aby wyświetlić więcej wyników w okresie zainteresowania. Użyj Eksploratora wyszukiwania, aby wyświetlić wyniki ze wszystkich wykonań. Możesz też użyć zapytań usługi Log Analytics do uruchamiania niestandardowych raportów dotyczących tych danych.

Aby wyświetlić szczegółowe informacje dotyczące kompleksowej transakcji, w obszarze Przechodzenie do szczegółów wybierz pozycję Powodzenie lub Niepowodzenie. Następnie wybierz przykład. Możesz również przejść do szczegółów kompleksowej transakcji, wybierając punkt danych na grafie.

Zrzut ekranu przedstawiający wybieranie przykładowego testu dostępności.

Zrzut ekranu przedstawiający szczegóły transakcji kompleksowej.

Sprawdzanie i edytowanie testów

Aby edytować, tymczasowo wyłączyć lub usunąć test, wybierz wielokropek obok nazwy testu. Propagacja zmian konfiguracji do wszystkich agentów testowych po wprowadzeniu zmiany może potrwać do 20 minut.

Zrzut ekranu przedstawiający widok szczegółów testu. Edytowanie i wyłączanie testu internetowego.

Możesz wyłączyć testy dostępności lub skojarzone z nimi reguły alertów podczas przeprowadzania konserwacji usługi.

Jeśli widzisz błędy

Wybierz czerwoną kropkę.

Zrzut ekranu przedstawiający kartę Szczegóły transakcji kompleksowej.

Na podstawie wyniku testu dostępności można zobaczyć szczegóły transakcji we wszystkich składnikach. W tym miejscu możesz:

  • Przejrzyj raport rozwiązywania problemów, aby określić, co mogło spowodować niepowodzenie testu, ale aplikacja jest nadal dostępna.
  • Zbadać odpowiedź odebraną z serwera.
  • Zdiagnozuj błąd z skorelowaną telemetrią po stronie serwera zebranymi podczas przetwarzania nieudanego testu dostępności.
  • Zarejestruj problem lub element roboczy w usłudze Git lub usłudze Azure Boards, aby śledzić problem. Błąd będzie zawierać link do tego zdarzenia.
  • Otworzyć wynik testu sieci Web w programie Visual Studio.

Aby dowiedzieć się więcej na temat kompleksowej diagnostyki transakcji, zobacz dokumentację diagnostyki transakcji.

Wybierz wiersz wyjątku, aby wyświetlić szczegóły wyjątku po stronie serwera, który spowodował niepowodzenie syntetycznego testu dostępności. Migawkę debugowania można również uzyskać w celu uzyskania bardziej rozbudowanej diagnostyki na poziomie kodu.

Zrzut ekranu przedstawiający diagnostykę po stronie serwera.

Oprócz nieprzetworzonych wyników można również wyświetlić dwie kluczowe metryki dostępności w Eksploratorze metryk:

  • Dostępność: procent testów zakończonych powodzeniem we wszystkich wykonaniach testów.
  • Czas trwania testu: średni czas trwania testu we wszystkich wykonaniach testów.

Wykonywanie zapytań w usłudze Log Analytics

Możesz użyć usługi Log Analytics, aby wyświetlić wyniki dostępności, zależności i nie tylko. Aby dowiedzieć się więcej o usłudze Log Analytics, zobacz Omówienie zapytań dzienników.

Zrzut ekranu przedstawiający wyniki dostępności.

Zrzut ekranu przedstawiający kartę Nowe zapytanie z zależnościami ograniczonymi do 50.

Migrowanie testów dostępności

W tym artykule przeprowadzimy Cię przez proces migracji z klasycznych testów ping adresu URL do nowoczesnych i wydajnych testów standardowych.

Upraszczamy ten proces, zapewniając jasne instrukcje krok po kroku, aby zapewnić bezproblemowe przejście i wyposażenie aplikacji w najbardziej aktualne możliwości monitorowania.

Migrowanie klasycznych testów ping adresu URL do standardowych testów

W poniższych krokach przedstawiono proces tworzenia standardowych testów replikujących funkcjonalność testów ping adresu URL. Umożliwia to łatwiejsze rozpoczęcie korzystania z zaawansowanych funkcji standardowych testów przy użyciu wcześniej utworzonych testów ping adresu URL.

Ważne

Koszt jest skojarzony z uruchamianiem standardowych testów. Po utworzeniu testu standardowego opłaty będą naliczane za wykonania testów. Przed rozpoczęciem tego procesu zapoznaj się z cennikiem usługi Azure Monitor.

Wymagania wstępne

Rozpocznij

  1. Połącz się z subskrypcją przy użyciu programu Azure PowerShell (Connect-AzAccount + Set-AzContext).

  2. Wyświetl listę wszystkich testów ping adresu URL w bieżącej subskrypcji:

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

  3. Znajdź test ping adresu URL, który chcesz migrować, i zarejestruj jego grupę zasobów i nazwę.

  4. Następujące polecenia umożliwiają utworzenie standardowego testu z tą samą logiką co test ping adresu URL.

    Uwaga

    Następujące polecenia działają zarówno dla punktów końcowych HTTP, jak i HTTPS, które są używane w testach ping adresu URL.

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

  5. Nowy test standardowy nie ma domyślnie reguł alertów, więc nie tworzy hałaśliwych alertów. Nie wprowadzono żadnych zmian w teście ping adresu URL, dzięki czemu możesz nadal polegać na nim w przypadku alertów.

  6. Po zweryfikowaniu funkcjonalności nowego testu standardowego zaktualizuj reguły alertów odwołujące się do testu ping adresu URL, aby odwoływać się do standardowego testu. Następnie wyłączysz lub usuniesz test ping adresu URL.

  7. Aby usunąć test ping adresu URL za pomocą programu Azure PowerShell, możesz użyć następującego polecenia:

    Remove-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;

Testowanie za zaporą

Aby zapewnić dostępność punktu końcowego za zaporami, włącz publiczne testy dostępności lub uruchom testy dostępności w scenariuszach rozłączenia lub braku ruchu przychodzącego.

Włączanie testu dostępności publicznej

Upewnij się, że wewnętrzna witryna internetowa ma publiczny rekord systemu nazw domen (DNS). Testy dostępności kończą się niepowodzeniem, jeśli nie można rozpoznać systemu DNS. Aby uzyskać więcej informacji, zobacz Tworzenie niestandardowej nazwy domeny dla aplikacji wewnętrznej.

Ostrzeżenie

Adresy IP używane przez usługę testów dostępności są współużytkowane i mogą uwidaczniać punkty końcowe usługi chronionej przez zaporę innym testom. Filtrowanie adresów IP nie zabezpiecza ruchu usługi, dlatego zaleca się dodanie dodatkowych nagłówków niestandardowych w celu zweryfikowania źródła żądania internetowego. Aby uzyskać więcej informacji, zobacz Tagi usługi dla sieci wirtualnej.

Uwierzytelnianie ruchu

Ustaw nagłówki niestandardowe w standardowych testach dostępności, aby zweryfikować ruch.

  1. Wygeneruj token lub identyfikator GUID, aby zidentyfikować ruch z testów dostępności.

  2. Dodaj nagłówek niestandardowy "X-Customer-InstanceId" z wartością ApplicationInsightsAvailability:<GUID generated in step 1> w sekcji "Standardowe informacje testowe" podczas tworzenia lub aktualizowania testów dostępności.

  3. Upewnij się, że usługa sprawdza, czy ruch przychodzący zawiera nagłówek i wartość zdefiniowaną w poprzednich krokach.

    Zrzut ekranu przedstawiający niestandardowy nagłówek weryfikacji.

Alternatywnie ustaw token jako parametr zapytania. Na przykład https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your guid>.

Konfigurowanie zapory w celu zezwolenia na żądania przychodzące z testów dostępności

Uwaga

Ten przykład jest specyficzny dla użycia tagów usługi sieciowej grupy zabezpieczeń. Wiele usług platformy Azure akceptuje tagi usług, z których każdy wymaga różnych kroków konfiguracji.

  • Aby uprościć włączanie usług platformy Azure bez autoryzowania poszczególnych adresów IP lub obsługi aktualnej listy adresów IP, użyj tagów usługi. Zastosuj te tagi w usłudze Azure Firewall i sieciowych grupach zabezpieczeń, umożliwiając dostęp usługi testowej dostępności do punktów końcowych. Tag ApplicationInsightsAvailability usługi ma zastosowanie do wszystkich testów dostępności.

    1. Jeśli używasz sieciowych grup zabezpieczeń platformy Azure, przejdź do zasobu sieciowej grupy zabezpieczeń i w obszarze Ustawienia wybierz pozycję Reguły zabezpieczeń dla ruchu przychodzącego. Następnie wybierz pozycję Dodaj.

      Zrzut ekranu przedstawiający kartę Reguły zabezpieczeń dla ruchu przychodzącego w zasobie sieciowej grupy zabezpieczeń.

    2. Następnie wybierz pozycję Tag usługi jako źródło i wybierz pozycję ApplicationInsightsAvailability jako tag usługi źródłowej. Użyj otwartych portów 80 (http) i 443 (https) dla ruchu przychodzącego z tagu usługi.

      Zrzut ekranu przedstawiający kartę Dodawanie reguł zabezpieczeń dla ruchu przychodzącego ze źródłem tagu usługi.

  • Aby zarządzać dostępem, gdy punkty końcowe znajdują się poza platformą Azure lub gdy tagi usług nie są opcją, dodaj adresy IP naszych agentów testów internetowych. Zakresy adresów IP można wykonywać za pomocą programu PowerShell, interfejsu wiersza polecenia platformy Azure lub wywołania REST przy użyciu interfejsu API tagów usługi. Aby uzyskać kompleksową listę bieżących tagów usługi i ich szczegółów adresu IP, pobierz plik JSON.

    1. W zasobie sieciowej grupy zabezpieczeń w obszarze Ustawienia wybierz pozycję Reguły zabezpieczeń dla ruchu przychodzącego. Następnie wybierz pozycję Dodaj.

    2. Następnie wybierz pozycję Adresy IP jako źródło. Następnie dodaj swoje adresy IP na liście rozdzielanej przecinkami w źródłowych zakresach adresów IP/CIRD.

      Zrzut ekranu przedstawiający kartę Dodawanie reguł zabezpieczeń dla ruchu przychodzącego ze źródłem adresów IP.

Scenariusze rozłączenia lub braku ruchu przychodzącego

  1. Połącz zasób usługi Application Insights z wewnętrznym punktem końcowym usługi przy użyciu usługi Azure Private Link.

  2. Pisanie niestandardowego kodu w celu okresowego testowania wewnętrznego serwera lub punktów końcowych. Wyślij wyniki do usługi Application Insights przy użyciu interfejsu API TrackAvailability() w podstawowym pakiecie SDK.

Obsługiwane konfiguracje protokołu TLS

Aby zapewnić najlepsze w klasie szyfrowanie, wszystkie testy dostępności używają protokołu Transport Layer Security (TLS) 1.2 i 1.3 jako wybranych mechanizmów szyfrowania. Ponadto w każdej wersji obsługiwane są również następujące zestawy szyfrowania i krzywe wielokropka.

Uwaga

Protokół TLS 1.3 jest obecnie dostępny tylko w regionach testu dostępności NorthCentralUS, CentralUS, EastUS, SouthCentralUS i WestUS.

TLS 1.2

Zestawy szyfrowania

  • 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

Krzywe wielokropowe

  • NistP384
  • NistP256

TLS 1.3

Zestawy szyfrowania

  • TLS_AES_256_GCM_SHA384
  • TLS_AES_128_GCM_SHA256

Krzywe wielokropowe:

  • NistP384
  • NistP256

Przestarzała konfiguracja protokołu TLS

Ostrzeżenie

31 października 2024 r. zgodnie z wycofaniem starszej wersji protokołu TLS na platformie Azure, wersje protokołu TLS 1.0/1.1 i wymienione poniżej wersje protokołu TLS 1.2/1.3 starsze zestawy szyfrowania i krzywe wielokropków zostaną wycofane na potrzeby testów dostępności usługi Application Insights.

Protokoły TLS 1.0 i TLS 1.1

Wersje protokołu nie będą już obsługiwane.

TLS 1.2

Zestawy szyfrowania

  • 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

Krzywe wielokropowe:

  • krzywa25519

TLS 1.3

Krzywe wielokropowe

  • krzywa25519

Rozwiązywanie problemów

Ostrzeżenie

Ostatnio włączyliśmy protokół TLS 1.3 w testach dostępności. Jeśli w rezultacie są wyświetlane nowe komunikaty o błędach, upewnij się, że klienci działający w systemie Windows Server 2022 z włączonym protokołem TLS 1.3 mogą łączyć się z punktem końcowym. Jeśli nie możesz tego zrobić, możesz rozważyć tymczasowe wyłączenie protokołu TLS 1.3 w punkcie końcowym, aby testy dostępności wróciły do starszych wersji protokołu TLS.
Aby uzyskać dodatkowe informacje, zapoznaj się z artykułem dotyczącym rozwiązywania problemów. Zobacz dedykowany artykuł dotyczący rozwiązywania problemów.

Skoroszyt przestojów, umów SLA i awarii

W tym artykule przedstawiono prosty sposób obliczania i raportowania umowy dotyczącej poziomu usług (SLA) na potrzeby testów internetowych za pomocą jednego okienka szkła w zasobach usługi Application Insights i subskrypcjach platformy Azure. Raport o przestojach i awariach udostępnia zaawansowane, wstępnie utworzone zapytania i wizualizacje danych, pozwalające lepiej zrozumieć łączność klienta, typowy czas odpowiedzi aplikacji i występowanie przestojów.

Dostęp do szablonu skoroszytu umowy SLA można uzyskać z zasobu usługi Application Insights na dwa sposoby:

  • Otwórz okienko Dostępność, a następnie wybierz pozycję Raport umowy SLA w górnej części ekranu.

    Zrzut ekranu przedstawiający kartę **Dostępność** z wyróżnionym raportem SLA.

  • Otwórz okienko Skoroszyty, a następnie wybierz pozycję Przestoje i awarie.

    Zrzut ekranu przedstawiający galerię skoroszytów z wyróżnionym skoroszytem Przestój i awarie.

Elastyczność parametrów

Parametry ustawione w skoroszycie mają wpływ na pozostałą część raportu.

Zrzut ekranu przedstawiający parametry.

  • Subscriptions, App Insights Resourcesi Web Test: Te parametry określają opcje zasobów wysokiego poziomu. Są one oparte na zapytaniach usługi Log Analytics i są używane w każdym zapytaniu raportu.
  • Failure Threshold i Outage Window: Możesz użyć tych parametrów, aby określić własne kryteria awarii usługi. Przykładem jest kryteria alertu dostępności usługi Application Insights opartego na liczniku lokalizacji, który zakończył się niepowodzeniem w wybranym okresie. Typowy próg to trzy lokalizacje w ciągu pięciu minut.
  • Maintenance Period: Możesz użyć tego parametru, aby wybrać typową częstotliwość konserwacji. Maintenance Window to selektor daty/godziny dla przykładowego okresu konserwacji. Wszystkie dane, które występują w określonym okresie, zostaną zignorowane w wynikach.
  • Availability Target %: ten parametr określa cel docelowy i przyjmuje wartości niestandardowe.

Strona omówienia

Strona przeglądu zawiera ogólne informacje o Twoim:

  • Łączna umowa SLA (z wyłączeniem okresów konserwacji, jeśli jest zdefiniowana)
  • Kompleksowe wystąpienia awarii
  • Przestój aplikacji

Wystąpienia awarii są definiowane przez czas, gdy test rozpoczyna się niepowodzeniem, dopóki nie powiedzie się, na podstawie parametrów awarii. Jeśli test rozpocznie się niepowodzeniem o godzinie 8:00 i ponownie zakończy się powodzeniem o godzinie 10:00, cały okres danych jest uznawany za tę samą awarię.

Zrzut ekranu przedstawiający stronę przeglądu z wyświetloną tabelą Przegląd według testu.

Możesz również zbadać najdłuższą awarię, która wystąpiła w okresie raportowania.

Niektóre testy można połączyć z zasobem usługi Application Insights w celu dalszego zbadania. Jednak jest to możliwe tylko w zasobie usługi Application Insights opartym na obszarze roboczym.

Przestoje, awarie i awarie

Karta Awarie i przestój zawiera informacje na temat całkowitej awarii wystąpień i łącznego przestoju podzielonego na test.

Zrzut ekranu przedstawiający kartę Przestoje i przestój w skoroszycie przestojów i przestojów.

Karta Błędy według lokalizacji zawiera geograficzną mapę lokalizacji testowania, które nie powiodły się, aby ułatwić zidentyfikowanie potencjalnych obszarów połączenia problemów.

Zrzut ekranu przedstawiający kartę Niepowodzenie według lokalizacji w skoroszycie przestojów i awarii.

Edytowanie raportu

Raport można edytować tak jak każdy inny skoroszyt usługi Azure Monitor.

Zrzut ekranu przedstawiający wybieranie przycisku Edytuj, aby zmienić wizualizację na wykres kołowy.

Zapytania lub wizualizacje można dostosować na podstawie potrzeb twojego zespołu.

Zrzut ekranu przedstawiający zmianę wizualizacji na wykres kołowy.

Log Analytics

Wszystkie zapytania mogą być uruchamiane w usłudze Log Analytics i używane w innych raportach lub pulpitach nawigacyjnych.

Zrzut ekranu przedstawiający sposób uzyskiwania dostępu do zapytania dziennika.

Usuń ograniczenie parametru i użyj ponownie podstawowego zapytania.

Zrzut ekranu przedstawiający zapytanie dziennika, które można użyć ponownie.

Dostęp i udostępnianie

Raport może być udostępniany zespołom i kierownictwu lub przypięty do pulpitu nawigacyjnego w celu dalszego użycia. Użytkownik musi mieć uprawnienia do odczytu/dostępu do zasobu usługi Application Insights, w którym jest przechowywany rzeczywisty skoroszyt.

Zrzut ekranu przedstawiający okienko Udostępnij szablon.

Często zadawane pytania

Ta sekcja zawiera odpowiedzi na typowe pytania.

Ogólne

Czy mogę uruchomić testy dostępności na serwerze intranetowym?

Nasze testy internetowe są uruchamiane w punktach obecności, które są dystrybuowane na całym świecie. Istnieją dwa rozwiązania:

  • Drzwi zapory: zezwalaj na żądania do serwera z długiej i możliwej do zmiany listy agentów testów sieci Web.
  • Kod niestandardowy: napisz własny kod, aby wysyłać okresowe żądania do serwera z wewnątrz intranetu. W tym celu można uruchomić testy internetowe programu Visual Studio. Tester może wysłać wyniki do usługi Application Insights przy użyciu interfejsu TrackAvailability() API.

Jaki jest ciąg agenta użytkownika na potrzeby testów dostępności?

Ciąg agenta użytkownika to Mozilla/5.0 (zgodne; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

Obsługa protokołu TLS

Jak to wycofanie ma wpływ na zachowanie testu internetowego?

Testy dostępności działają jako klient rozproszony w każdej z obsługiwanych lokalizacji testów sieci Web. Za każdym razem, gdy test internetowy jest wykonywany, usługa testu dostępności próbuje skontaktować się z zdalnym punktem końcowym zdefiniowanym w konfiguracji testu internetowego. Zostanie wysłana wiadomość Hello klienta TLS zawierająca całą obecnie obsługiwaną konfigurację protokołu TLS. Jeśli zdalny punkt końcowy współużytkuje wspólną konfigurację protokołu TLS z klientem testowym dostępności, uzgadnianie protokołu TLS powiedzie się. W przeciwnym razie test internetowy kończy się niepowodzeniem z błędem uzgadniania protokołu TLS.

Jak mogę upewnić się, że mój test internetowy nie ma wpływu?

Aby uniknąć jakiegokolwiek wpływu, każdy zdalny punkt końcowy (w tym żądania zależne) test internetowy wchodzi w interakcję z musi obsługiwać co najmniej jedną kombinację tej samej wersji protokołu, pakietu szyfrowania i krzywej wielokropka, którą wykonuje test dostępności. Jeśli zdalny punkt końcowy nie obsługuje wymaganej konfiguracji protokołu TLS, należy go zaktualizować z obsługą niektórych kombinacji wymienionej powyżej konfiguracji protokołu TLS po zakończeniu obsługi. Te punkty końcowe można odnaleźć, wyświetlając szczegóły transakcji testu internetowego (najlepiej w przypadku pomyślnego wykonania testu internetowego).

Jak mogę sprawdzić, jaka konfiguracja protokołu TLS obsługuje zdalny punkt końcowy?

Dostępnych jest kilka narzędzi do testowania konfiguracji protokołu TLS obsługiwanej przez punkt końcowy. Jednym ze sposobów jest wykonanie przykładu opisanego na tej stronie. Jeśli zdalny punkt końcowy nie jest dostępny za pośrednictwem Publicznego Internetu, należy sprawdzić poprawność konfiguracji protokołu TLS obsługiwanej w zdalnym punkcie końcowym z komputera, który ma dostęp do wywołania punktu końcowego.

Uwaga

Aby wykonać kroki umożliwiające włączenie wymaganej konfiguracji protokołu TLS na serwerze internetowym, najlepiej skontaktować się z zespołem, który jest właścicielem platformy hostingu, na którą działa serwer internetowy, jeśli proces nie jest znany.

Po 31 października 2024 r. jakie będzie zachowanie testu internetowego dla testów, których dotyczy problem?

Nie ma żadnego typu wyjątku, z którego wszystkie błędy uzgadniania PROTOKOŁU TLS, na które ma wpływ wycofanie. Jednak najczęstszym wyjątkiem, z powodu których test internetowy rozpoczyna się niepowodzeniem, jest .The request was aborted: Couldn't create SSL/TLS secure channel W kroku rozwiązywania problemów z transportem TLS powinien być również widoczny dowolny błąd związany z protokołem TLS dla wyniku testu sieci Web, którego potencjalnie dotyczy problem.

Czy mogę wyświetlić, jaka konfiguracja protokołu TLS jest obecnie używana przez mój test internetowy?

Nie można wyświetlić konfiguracji protokołu TLS wynegocjowanej podczas wykonywania testu internetowego. Jeśli zdalny punkt końcowy obsługuje wspólną konfigurację protokołu TLS z testami dostępności, nie powinno być widoczne żadne skutki po zakończeniu obsługi.

Które składniki mają wpływ na wycofanie w usłudze testów dostępności?

Wycofanie protokołu TLS opisane w tym dokumencie powinno mieć wpływ tylko na zachowanie wykonywania testu dostępności w internecie po 31 października 2024 r. Aby uzyskać więcej informacji na temat interakcji z usługą testową dostępności dla operacji CRUD, zobacz Obsługa protokołu TLS w usłudze Azure Resource Manager. Ten zasób zawiera więcej szczegółów dotyczących obsługi protokołu TLS i przestarzałych osi czasu.

Gdzie mogę uzyskać pomoc techniczną protokołu TLS?

Aby uzyskać ogólne pytania dotyczące starszego problemu z protokołem TLS, zobacz Rozwiązywanie problemów z protokołem TLS.

Następne kroki