Diagnozowanie niepowodzenia testu ping w monitorowaniu dostępności usługi Application Insights

W tym artykule omówiono sposób uzyskiwania dostępu do raportu rozwiązywania problemów usługi Application Insights. Ten raport umożliwia łatwe diagnozowanie typowych problemów, które powodują niepowodzenie testów ping.

Uwaga

Wiele problemów związanych z testami internetowymi jest spowodowanych nieaktualnymi lub nieaktualnymi rekordami DNS. Jako pierwszy krok rozwiązywania problemów zalecamy opróżnienie pamięci podręcznej DNS na komputerze lokalnym.

W systemie Windows uruchom polecenie ipconfig /flushdns . W przypadku innych systemów operacyjnych równoważne polecenie jest inne.

Wyświetlanie raportu dotyczącego rozwiązywania problemów z usługą Application Insights

Aby wyświetlić raport rozwiązywania problemów z usługą Application Insights, wykonaj następujące kroki:

1. Na stronie Dostępność zasobu usługi Application Insights znajdź nagłówek Wybierz test dostępności . W tym nagłówku wybierz nazwę indywidualnego testu dostępności lub wybierz pozycję Ogólne , aby wyświetlić połączone wyniki wszystkich nazw testów.

2. Wykonaj jedną z następujących akcji:

   • W okienku Wyniki dostępności dla nazwy testu znajdź nagłówek Przechodzenie do szczegółów, a następnie wybierz przycisk Niepowodzenie . Następnie w okienku Kliknij przykładowy test dostępności wybierz przebieg testu (reprezentujący określony region i godzinę) dla nazwy testu.

   • Na wykresie dostępności wybierz widok Wykres punktowy , a następnie wybierz jeden z punktów na wykresie wykresu punktowego.

3. Na stronie Szczegóły transakcji kompleksowej wybierz zdarzenie, a następnie wybierz dowolne miejsce w tabeli Właściwości dostępności , aby otworzyć sekcję Podsumowanie raportu rozwiązywania problemów .

4. W sekcji Podsumowanie raportu rozwiązywania problemów znajdź odpowiednią nazwę błędu, a następnie wybierz link Przejdź do kroku dla tego elementu, aby wyświetlić szczegóły raportu rozwiązywania problemów .

Użyj raportu rozwiązywania problemów, aby określić możliwe przyczyny awarii

W poniższej tabeli wymieniono kroki, komunikaty o błędach i możliwe przyczyny, które można znaleźć w raporcie.

Krok	Komunikat o błędzie	Możliwa przyczyna
Ponowne użycie połączenia	Dla tego problemu nie jest zwracany żaden konkretny komunikat o błędzie.	Krok testu internetowego zależy od wcześniej ustanowionego połączenia. W związku z tym nie jest wymagany żaden krok DNS, połączenia ani protokołu SSL.
Rozpoznawanie nazw DNS	Nie można rozpoznać nazwy zdalnej: "<twój-adres URL>"	Proces rozpoznawania nazw DNS kończy się niepowodzeniem. Najprawdopodobniej miało to miejsce z powodu błędnie skonfigurowanych rekordów DNS lub tymczasowych błędów serwera DNS.
Ustanowienie połączenia	Próba połączenia nie powiodła się, ponieważ połączona strona nie odpowiedziała prawidłowo po upływie określonego czasu.	Serwer nie odpowiada na żądanie HTTP. Częstą przyczyną jest to, że zapora na serwerze blokuje naszych agentów testowych. Aby przetestować usługę Azure Virtual Network, dodaj tag usługi dostępności do swojego środowiska.
Transport TLS	Klient i serwer nie mogą się komunikować, ponieważ nie posiadają wspólnego algorytmu.	Obsługiwane są tylko protokoły TLS 1.0, 1.1 i 1.2. Protokół SSL nie jest obsługiwany. Ten krok nie weryfikuje certyfikatów SSL, tylko ustanawia bezpieczne połączenie. Ten krok jest wyświetlany tylko wtedy, gdy wystąpi błąd.
Odbieranie nagłówka odpowiedzi	Nie można odczytać danych z połączenia transportowego. Połączenie zostało zamknięte.	Serwer zatwierdza błąd protokołu w nagłówku odpowiedzi. Na przykład serwer zamyka połączenie, jeśli odpowiedź nie jest w pełni odczytana.
Treść odpowiedzi odbierania	Nie można odczytać danych z połączenia transportowego: połączenie zostało zamknięte.	Serwer zatwierdza błąd protokołu w treści odpowiedzi. Na przykład serwer zamyka połączenie, jeśli odpowiedź nie jest w pełni odczytana lub rozmiar fragmentu jest nieprawidłowy w treści odpowiedzi fragmentu.
Sprawdzanie poprawności limitu przekierowania	Ta strona internetowa ma zbyt wiele przekierowań. Ta pętla zostanie zakończona w tym miejscu, ponieważ to żądanie przekroczyło limit dla przekierowywania automatycznego.	Przekierowywanie jest ograniczone do 10 na test.
Sprawdzanie poprawności kodu stanu	200 - OK nie jest zgodny z oczekiwanym stanem 400 - BadRequest.	Zwrócony kod stanu jest liczony jako powodzenie. Kod "200" wskazuje, że zwrócono normalną stronę internetową.
Sprawdzanie poprawności zawartości	Wymagany tekst "<expected-response-text>" nie pojawił się w odpowiedzi.	Ciąg nie jest dokładnym dopasowaniem uwzględniającym wielkość liter w odpowiedzi. Na przykład ciąg "Welcome!" musi być zwykłym ciągiem bez symboli wieloznaczowych (takich jak gwiazdka). W przypadku zmiany zawartości strony może być konieczne zaktualizowanie ciągu. Dopasowanie zawartości obsługuje tylko znaki angielskie. Dopasowanie zawartości również kończy się niepowodzeniem, jeśli treść odpowiedzi ma długość ponad 1 000 000 bajtów. Gdy klient odczytuje tę liczbę bajtów, przestaje odczytywać treść odpowiedzi i porzuca połączenie. Z powodu tego zachowania na serwerze występuje ClientConnectionFailure wyjątek, nawet jeśli klient zwraca kod stanu powodzenia.

Uwaga

Jeśli krok ponownego użycia połączenia jest obecny, następujące kroki nie będą obecne:

• Rozpoznawanie nazw DNS
• Ustanowienie połączenia
• Transport TLS

Następne kroki

• Użyj funkcji TrackAvailability , aby przesłać niestandardowe testy dostępności.

• Dowiedz się więcej o testach ping adresów URL.

Skontaktuj się z nami, aby uzyskać pomoc

Jeśli masz pytania lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pytanie w społeczności wsparcia dla platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii platformy Azure.