Monitorowanie syntetyczne: automatyczny pomiar czasu ładowania z różnych regionów

Co pokazuje Synthetic Monitoring

Synthetic Monitoring automatycznie i regularnie przeprowadza ustalone testy strony internetowej. Jednym z Sprawdź opisuje przy tym między innymi cel, harmonogram, punkty pomiarowe oraz kryteria sukcesu. Każda operacja przeprowadzona w danym punkcie pomiarowym generuje odrębny wynik: konfiguracji nie należy zatem utożsamiać z pojedynczym pomiarem.

Natomiast jednorazowy globalny test wydajności pokazuje jedynie chwilowy obraz sytuacji w warunkach tego przebiegu. Powtarzane Monitorowanie stron internetowych pokazuje, czy odchylenie pojawia się ponownie oraz jak zmieniają się wyniki w czasie. Aby takie porównania były miarodajne, należy zapewnić rozpoznawalność celu, środowiska pomiarowego i lokalizacji.

Publiczny punkt pomiarowy w centrum danych w chmurze sprawdza stronę internetową z określonego regionu i infrastruktury. Jego połączenie nie odpowiada jednak automatycznie prywatnemu dostępowi do Internetu na miejscu. Na wynik mogą wpływać routing, opóźnienia sieciowe oraz odległość od infrastruktury dostarczającej treści; powolny przebieg testu odnosi się zatem przede wszystkim do tej konkretnej ścieżki pomiarowej.

A prywatna próba odpowiada na inne pytanie: pozwala sprawdzić, czy aplikacja jest dostępna z sieci prywatnej. Ma to znaczenie na przykład w przypadku usług wewnętrznych, ale nie potwierdza ich dostępności z publicznej sieci internetowej. Z drugiej strony pomyślny wynik sprawdzenia publicznego nie oznacza, że dostęp z każdej sieci firmowej będzie działał.

Dlatego podczas planowania warto sformułować każde sprawdzenie jako konkretne pytanie: czy strona produktu jest dostępna z ważnego regionu docelowego i czy wyświetla się tam oczekiwana treść? Odpowiedź dotyczy wybranych punktów pomiarowych i warunków testowych. Stanowi ona powtarzalną wskazówkę, ale nie jest pełnym odzwierciedleniem wszystkich odwiedzających i ich urządzeń.

HTTP, przeglądarki i ścieżki użytkownika

A Sprawdzenie HTTP sprawdza punkt końcowy i ocenia na przykład kod statusu lub odpowiedź. W przypadku strony produktu może szybko wykazać, że serwer nie odpowiada zgodnie z oczekiwaniami. Jeśli zwraca kod HTTP 200, oznacza to jedynie spełnienie sprawdzonego kryterium odpowiedzi: pozostaje jednak otwarte pytanie, czy interfejs jest widoczny i czy można z niego korzystać.

Test przeglądarki polega na załadowaniu tej samej strony produktu w zautomatyzowanej przeglądarce. Pozwala on sprawdzić, czy pojawia się oczekiwany nagłówek, oraz zebrać dane pomiarowe dotyczące przeglądarki. Jeśli test ten zakończy się niepowodzeniem, mimo że status HTTP wskazuje na pomyślne wykonanie, warto zbadać renderowanie i zawartość strony. Jednak sama ta rozbieżność nie wskazuje jeszcze na konkretną przyczynę błędu.

A Sprawdź trasę wykracza poza samo ładowanie strony i wykonuje określone czynności. Na przykład podczas logowania otwiera stronę logowania, loguje się na odpowiednie konto testowe, a następnie sprawdza oczekiwany element. Dopiero to ostatnie kryterium potwierdza, że w testowanym procesie strona logowania była nie tylko dostępna.

Nawet pomyślnie zakończona ścieżka potwierdza jedynie faktycznie wykonane kroki i spełnione warunki. Niesprawdzone resetowanie hasła lub inna przeglądarka mogą mimo to powodować problemy. Dlatego wybierz kilka procesów istotnych dla działalności firmy i sformułuj dla każdego kroku wynik, który można zweryfikować, zamiast wyciągać wnioski dotyczące całej usługi na podstawie pomyślnego wyświetlenia strony.

Dodatkowa kontrola wizualna pozwala wykryć zmiany w wyglądzie, których nie wychwyci pojedyncza kontrola elementów. W tym celu można na przykład porównać zrzuty ekranu; następnie należy zinterpretować wszelkie rozbieżności, ponieważ nie każda widoczna zmiana jest błędem. Dalsze podejścia opisano w artykule poświęconym Weryfikacja wizualna i zautomatyzowane kontrole witryn.

Jak prawidłowo rozróżniać czasy ładowania

„Termin “czas ładowania” bez dodatkowych wyjaśnień nie odnosi się do żadnej jednoznacznie porównywalnej wielkości. Podczas wyświetlania strony na początku istotny jest czas do pierwszej odpowiedzi serwera: pomaga on ocenić opóźnienia występujące przed otrzymaniem odpowiedzi. Nie wskazuje on jednak, kiedy przeglądarka wyświetliła coś widocznego lub kiedy strona została w pełni przetworzona.

Pierwsza widoczna wizualizacja przedstawia późniejszy etap: przeglądarka po raz pierwszy wyświetla zawartość. Może to być już niewielki fragment tekstu lub inny wczesny element, podczas gdy najważniejsza treść strony nadal nie jest dostępna. Dlatego też wczesne wyświetlenie strony nie oznacza automatycznie, że strona produktu jest gotowa do szybkiego użytkowania.

Der Farba o największej zawartości (LCP) uwzględnia moment, w którym największy istotny element treści staje się widoczny w widocznym obszarze. W przypadku strony produktu może to być na przykład duże zdjęcie produktu. LCP należy porównywać wyłącznie z odpowiednio oznaczonymi wartościami LCP oraz odnotowywać warunki pracy przeglądarki i sieci; czas oczekiwania na odpowiedź serwera jest mierzony w innej fazie.

Die Czas trwania scenariusza nie jest to jednak automatycznie czas ładowania pojedynczej strony. Skrypt może wywoływać wiele stron, czekać na pojawienie się elementów i przeprowadzać proces logowania. W przypadku testów przeglądarkowych Grafana-k6 podany czas trwania skryptu zazwyczaj nie obejmuje fazy uruchamiania k6; takie ograniczenia narzędzia również należy uwzględnić przy interpretacji wyników.

Wskaźnik „Interaction to Next Paint” (w skrócie INP) odnosi się do reakcji na interakcje. W tym kontekście symulowany przebieg może analizować jedynie te interakcje, które faktycznie wykonuje. Zautomatyzowane kliknięcie w określonych warunkach nie odzwierciedla zatem rozkładu doświadczeń wszystkich rzeczywistych użytkowników, którzy korzystają z innych urządzeń, połączeń i ścieżek nawigacji.

Plan pomiarów dla regionów docelowych

Rozpocznij plan pomiarów od stron i procesów, których awaria miałaby znaczenie dla Twojej działalności. Mogą to być strona produktu, proces rejestracji lub interfejs. Następnie wybierz regiony pomiarowe zgodnie z Twoimi rynkami docelowymi: dodatkowa lokalizacja jest szczególnie przydatna, jeśli obejmuje ważny region użytkowników lub uzupełnia istniejący pomiar regionalny.

Dla podobną kontrolę Zapisz nazwę przeglądarki i jej wersję, sposób wyświetlania na urządzeniu, warunki sieciowe oraz stan pamięci podręcznej. Udokumentuj również interwał i limit czasu, a także oczekiwaną odpowiedź lub widoczny element. Dzięki temu będzie można później ustalić, czy ewentualne odchylenie mogło zbiegać się w czasie ze zmianą warunków pomiarowych.

Poniższa tabela stanowi przykład koncepcyjny, a nie rzeczywisty lub ogólnie zalecany plan działania. Odstępy czasowe i warunki alarmowe należy dostosować do znaczenia swojej witryny oraz możliwości wybranego serwisu.

Tabela stanowi jedynie punkt wyjścia: w konfiguracji kontroli należy uzupełnić konkretny limit czasowy oraz pozostałe warunki pomiaru. Alarm regionalny ma sens sam w sobie, nawet jeśli inne lokalizacje zgłaszają pomyślne wyniki. Należy przy tym pamiętać, że punkt pomiarowy w chmurze niekoniecznie oznacza prywatne łącze internetowe w tym samym regionie.

Konfigurowanie kontroli i procedur testowych

Aby przetestować własną stronę, możesz najpierw utworzyć test HTTP, który sprawdzi oczekiwany kod statusu. Dodaj test przeglądarki, który wyświetli tę samą stronę i sprawdzi, czy pojawia się oczekiwany nagłówek. Pierwsza kontrola sprawdza odpowiedź punktu końcowego; druga dodatkowo wskazuje, czy oczekiwana treść pojawia się w przeglądarce.

Dla każdego uruchomienia należy odnotować miejsce pomiaru, czas, wynik oraz odpowiedni czas trwania. Jeśli sprawdzanie przeglądarki zakończy się niepowodzeniem pomimo pomyślnego wyniku sprawdzania HTTP, należy przeanalizować zawartość i renderowanie, zamiast od razu zakładać konkretny błąd. Sprawdź również, czy nagłówek został celowo zmieniony, czy też limit czasu został ustawiony zbyt krótko.

Aby się zarejestrować, należy rozwinąć Podróż wywołanie przeglądarki w celu wprowadzenia danych i sprawdzenia po zalogowaniu. Użyj oddzielnego konta testowego z jak najmniejszymi uprawnieniami i sprawdź stabilny, nieosobowy element w obszarze zalogowanym. Samo pomyślne wywołanie strony logowania nie potwierdza, że logowanie działa.

Wybierz stabilne selektory i celowo czekaj na oczekiwane treści, zamiast polegać wyłącznie na stałej przerwie. Dane dostępowe przechowuj w menedżerze kluczy tajnych danej usługi, a nie w skrypcie ani w logach. Po wprowadzeniu zmian w interfejsie sprawdź, czy selektory i kryteria powodzenia nadal odpowiadają przewidzianemu przebiegowi procesu.

Ogranicz przebieg testów do bezpiecznych działań: regularnie przeprowadzana ścieżka użytkownika nie powinna powodować prawdziwych zamówień ani płatności. Jeśli nie da się uniknąć operacji zapisu, należy ją przeprowadzić w środowisku testowym przeznaczonym specjalnie do tego celu lub w ramach kontrolowanego procesu testowego. Należy również określić, kto będzie analizował nieudane przebiegi testów i zarządzał danymi testowymi.

Porównanie narzędzi i modeli operacyjnych

Przy wyborze narzędzia należy rozróżnić między zarządzaną usługą monitorowania a narzędziem, które na początku wykonuje jedynie test. Decydujące znaczenie ma nie tylko to, czy dana przeglądarka jest obsługiwana: potrzebne są również odpowiednie lokalizacje, regularne uruchamianie, przechowywanie wyników oraz system powiadomień dostosowany do Twojej działalności.

Grafana Cloud Monitorowanie syntetyczne łączy konfiguracje testów z publicznymi i prywatnymi punktami pomiarowymi oraz obsługuje testy przeglądarek oparte na k6. Publiczne i prywatne punkty pomiarowe odpowiadają na różne pytania dotyczące dostępności. Sprawdź również z wyprzedzeniem dostępne częstotliwości kontroli: kontrole przeglądarek i skryptów podlegają innym ograniczeniom niż niektóre proste kontrole punktów końcowych.

Wykonane lokalnie Moduł przeglądarki k6 należy to traktować oddzielnie. W tym celu potrzebujesz k6 oraz przeglądarki opartej na Chromium; lokalne uruchomienie skryptu nie konfiguruje automatycznie regionalnych punktów pomiarowych ani stałego harmonogramu. W przypadku monitorowania rozproszonego musiałbyś dodatkowo zorganizować wykonanie, infrastrukturę i zarządzanie wynikami lub skorzystać z odpowiedniej usługi.

AWS CloudWatch Synthetics uruchamia zaplanowane testy typu „canary”. Te Funkcja obsługi wielu lokalizacji replikuje instancję Canary w wybranych regionach AWS i agreguje wyniki w regionie głównym. Przed wdrożeniem sprawdź udokumentowane minimalne wersje obsługiwanych środowisk uruchomieniowych Node.js Puppeteer lub Playwright, a także oddzielną dostępność tej funkcji w poszczególnych regionach.

Urządzenia pomiarowe obsługiwane we własnym zakresie zapewniają większą kontrolę nad lokalizacją i otoczeniem, ale wymagają również konserwacji, aktualizacji i monitorowania infrastruktury pomiarowej. W przypadku wszystkich modeli operacyjnych porównaj faktycznie oferowane lokalizacje, koszty zależne od wykorzystania oraz warunki przechowywania danych. Zwróć szczególną uwagę na to, gdzie przechowywane są zrzuty ekranu i protokoły oraz czy jest to zgodne z Twoimi wymogami dotyczącymi ochrony danych.

Racjonalna analiza wyników regionalnych

Porównaj wyniki regionalne dla tej samej strony i tego samego okresu. Przeglądarka, wersja, warunki sieciowe i stan pamięci podręcznej powinny być identyczne; w przeciwnym razie różnica może wynikać ze środowiska pomiarowego, a nie z sposobu dostarczania treści. Punkt pomiarowy w chmurze odzwierciedla ponadto konkretną lokalizację i ścieżkę sieciową, a nie wszystkie połączenia w danym regionie.

W przypadku kolejnych pomyślnych pomiarów wyświetla się Mediana wartość średnią posortowanych wyników. Górny percentyl, na przykład 95. percentyl, pozwala dostrzec wolniejsze przebiegi: 95 procent analizowanych wartości nie przekracza tej wartości. Należy odnotować okres i liczbę pomiarów, aby zachować przejrzystość co do zakresu analizy.

W przypadku niewielkiej liczby przebiegów pojedyncze, wolniejsze wywołanie może znacząco wpłynąć na górny percentyl. Dlatego przed stwierdzeniem trwałego pogorszenia wyników w danym regionie należy sprawdzić przebieg czasowy i porównać kilka okien pomiarowych. Również zmiana punktu pomiarowego lub wersji przeglądarki powinna zostać uwzględniona w analizie jako potencjalny czynnik zakłócający.

Zatrzymaj się nieudane próby wyświetlane oddzielnie, na przykład jako liczba błędów i odsetek wszystkich operacji. Statystyka czasu ładowania, która uwzględnia wyłącznie pomyślne wywołania, może w przeciwnym razie błędnie przedstawiać region z częstymi przekroczeniami limitu czasu jako działający prawidłowo. W przypadku niepowodzenia bez prawidłowej wartości czasu ładowania nie można po prostu przyjąć standardowego czasu ładowania.

Monitorowanie rzeczywistych użytkowników uzupełnia kontrolowane testy o doświadczenia prawdziwych odwiedzających. Raport Chrome UX udostępnia dane terenowe w ramach 28-dniowego okna kroczącego; nie obejmuje on jednak wszystkich stron ani grup użytkowników. Ta długoterminowa perspektywa nie zastępuje zatem aktualnego alarmu syntetycznego ani nie można jej bezpośrednio utożsamiać z pojedynczym przebiegiem testowym.

Alarmy i regionalne wykrywanie usterek

A alarm globalny może agregować powtarzające się błędy z wielu lokalizacji. Pomaga to odróżnić incydent o szerszym zasięgu od pojedynczej awarii punktu pomiarowego. Jednocześnie należy zdefiniować regionalny warunek alarmowy: jeśli zawiedzie ważny rynek docelowy, sukcesy innych regionów nie mogą przesłaniać tego problemu.

Wybierz liczbę powtórzeń i przedział czasowy odpowiednio do znaczenia procesu. Kilka nieudanych testów z rzędu może zniwelować krótkotrwałe odchylenia, ale opóźnia zgłoszenie. Należy również monitorować same punkty pomiarowe i sprawdzić, czy awaria dotyczy jednej próbki, czy też ma wpływ na inne testy w tej samej lokalizacji.

Jeśli strona produktu działa wolno tylko w jednej lokalizacji, zacznij od porównania podobnych sesji i momentu wystąpienia odchylenia. Następnie sprawdź rozpoznawanie adresów DNS, dostarczanie treści przez CDN, czasy ładowania zasobów oraz czas odpowiedzi serwera. Różne ścieżki sieciowe i odległość od infrastruktury mogą wpływać na regionalne poziomy odniesienia; sam odczyt pomiarowy nie pozwala jeszcze zidentyfikować przyczyny.

W przypadku zasobów z innych serwisów Origins szczegóły pomiaru przeglądarki mogą być ograniczone. Bez odpowiedniego Timing-Allow-Origin-W nagłówkach poszczególne wartości interfejsu API Resource Timing mogą wynosić zero. Nie oznacza to automatycznie, że połączenie było wyjątkowo szybkie; najpierw sprawdź, jakie dane udostępnia serwer zewnętrzny do celów pomiaru.

Aby przejść do kolejnego poziomu analizy, należy powiązać czas, region i dany proces z dostępnymi logami i śladami. W ten sposób można na przykład wyszukać powolne zapytanie, nie traktując jednak samej korelacji jako dowodu przyczyny. Jak współdziałają metryki, logi i ślady, wyjaśnia artykuł poświęcony Obserwowalność w hostingu.

Prowadzić monitorowanie w sposób ciągły

Zacznij od prostych testów punktów końcowych dla kluczowych, publicznie dostępnych celów, a następnie uzupełnij je ukierunkowanymi ścieżkami przeglądarki dla stron o znaczeniu krytycznym dla działalności lub procesów logowania. Test HTTP może być uruchamiany częściej, podczas gdy bardziej rozbudowany test przeglądarkowy sprawdza wybrane funkcje. Częstotliwość testów dostosowujesz do pożądanego czasu wykrycia, limitów usług i kosztów, a nie do stałej wartości w minutach.

Określ dla każdego warunku Kompetencje: Kto otrzymuje alarm, kto sprawdza daną usługę i kto zajmuje się punktem pomiarowym? Należy również odnotować, kiedy alarm jest przekazywany dalej i gdzie można znaleźć związane z nim wyniki. Kontrola bez reakcji na powtarzające się błędy dostarcza wprawdzie danych, ale nie rozwiązuje problemu.

Po wprowadzeniu zmian w interfejsie sprawdź, czy selektory i oczekiwane treści nadal pasują do przebiegu skryptu. W skrypcie należy czekać na pojawienie się wymaganego elementu, zamiast polegać wyłącznie na stałym opóźnieniu. Należy dokumentować zmiany w przeglądarce, profilu sieciowym lub ustawieniach pamięci podręcznej, aby późniejsze porównania nie mieszały ze sobą różnych warunków pomiarowych w sposób niezauważalny.

Traktuj zrzuty ekranu i protokoły jako potencjalnie wrażliwe dane: mogą one zawierać treści z sesji lub informacje z aplikacji. Ogranicz dostęp i okres przechowywania zgodnie z przeznaczeniem oraz sprawdź, co faktycznie rejestruje test. Do logowania używaj ograniczonego konta testowego, a dane dostępowe przechowuj jako sekrety, a nie w skrypcie.

Sprawdzaj regularnie, czy Miejsca pomiarów czy nadal odpowiadają one Twoim rynkom docelowym oraz czy taryfy, przechowywanie danych i wymogi dotyczące ochrony danych nadal pozwalają na prowadzenie działalności. W przypadku serwerów testowych obsługiwanych we własnym zakresie dochodzi jeszcze aktualizacja i monitorowanie środowiska. Sam skrypt przeglądarkowy k6 uruchomiony lokalnie nie zapewnia jeszcze trwałej, rozproszonej infrastruktury monitorującej.