Monitoring syntetyczny a RUM: co wyłapuje każdy z nich

Co robi każdy z nich

Monitoring syntetyczny, nazywany czasem aktywnym albo proaktywnym, wysyła zdefiniowane przez Ciebie żądanie z maszyny, którą kontrolujesz, w ustalonym przez Ciebie interwale. To żądanie może być tak proste jak HTTP GET albo tak rozbudowane jak nagrana sesja przeglądarki, która loguje się, dodaje produkt do koszyka i finalizuje zamówienie. Każde uruchomienie daje wynik niezależnie od tego, czy ktokolwiek odwiedził witrynę.

Monitoring rzeczywistych użytkowników, zwykle skracany do RUM, jest pasywny. Mały skrypt na Twoich stronach zgłasza, co zmierzyła przeglądarka podczas tej wizyty: czasy nawigacji, wczytywanie zasobów, błędy oraz Core Web Vitals w takiej postaci, w jakiej doświadczył ich odwiedzający. Danych powstaje tyle, ile wynika z Twojego ruchu, a gdy nikogo nie ma, nie powstaje nic.

Co wyłapuje monitoring syntetyczny, a czego nie wyłapuje RUM

• Awarie o 4 nad ranem albo na dowolnej stronie z małym ruchem. Jeśli nikt nie wczytuje strony, RUM nie ma czego zgłosić, a całkowita awaria to dokładnie przypadek, gdy sygnał nie może zostać wysłany
• Dostępność z miejsc, w których nie masz jeszcze użytkowników, dzięki czemu dowiadujesz się, że nowy rynek nie może się z Tobą połączyć
• Czysty punkt odniesienia. Ten sam skrypt, z tej samej lokalizacji, w tym samym interwale, więc zmiana liczby oznacza zmianę w witrynie, a nie w tym, kto akurat ją odwiedził
• Wieloetapowe procesy, których nie chciałbyś testować na rzeczywistych użytkownikach, na przykład finalizację zamówienia tworzącą prawdziwe zlecenie albo logowanie, które możesz uruchomić na koncie testowym
• Awarie wygaśnięcia i konfiguracji, które w ogóle nie docierają do przeglądarki: certyfikaty, rekordy DNS, wpisy na czarnych listach, otwarte porty
• Pierwszą awarię po wdrożeniu, zanim dotrze ruch, który by ją ujawnił

Co wyłapuje RUM, a czego nie wyłapuje monitoring syntetyczny

• Rzeczywisty rozkład urządzeń, sieci i lokalizacji. Sprawdzenie syntetyczne z połączenia w centrum danych nigdy nie odtworzy telefonu ze średniej półki na sieci komórkowej
• Skrypty firm trzecich, banery zgody i personalizację, które ładują się tylko dla prawdziwych sesji z prawdziwymi plikami cookie
• Problemy dotykające podzbiór użytkowników: jedną wersję przeglądarki, jeden region, jeden wariant testu A/B
• Które wolne strony rzeczywiście mają znaczenie, ważone liczbą osób, które je widzą
• Terenowe Core Web Vitals, których używają wyszukiwarki, w przeciwieństwie do wartości laboratoryjnych generowanych przez sprawdzenie syntetyczne

Kiedy potrzebujesz obu

Te dwa podejścia odpowiadają na różne pytania, więc podział jest zazwyczaj wyraźny. Użyj monitoringu syntetycznego do wszystkiego, w sprawie czego wezwałbyś kogoś do działania: dostępności, czasu odpowiedzi względem progu, wygaśnięcia certyfikatu i domeny oraz krytycznych procesów, na których zarabiasz. Te muszą być prawdziwe o 4 nad ranem przy zerowym ruchu i potrzebują stabilnego punktu odniesienia, względem którego można alarmować.

Użyj RUM do decydowania, co naprawić. Gdy strona jest wolna dla części osób, RUM mówi, dla których i dla ilu, a to jest informacja potrzebna do argumentu za priorytetem, której sprawdzenie syntetyczne nie dostarczy.

Praktyczne rozwiązanie to sprawdzenia syntetyczne napędzające alarmy i statystyki dostępności, a RUM napędzający listę zadań wydajnościowych. Jeśli możesz uruchomić tylko jedno, uruchom syntetyczne: niemonitorowana awaria kosztuje więcej niż niezmierzona wolna strona, a RUM nie może zgłosić niczego o stronie, która się nie wczytała.

Gdzie pasuje monitoring transakcji

Sprawdzenie transakcji to monitoring syntetyczny w swojej najbardziej szczegółowej postaci: nagrany skrypt przeglądarki, który krok po kroku przechodzi przez rzeczywistą ścieżkę użytkownika i zgłasza błąd na tym kroku, który się zepsuł, a nie na witrynie jako całości. Wyłapuje klasę awarii, którą proste sprawdzenie dostępności zgłosi jako zdrową, bo strona główna zwraca 200, podczas gdy stojący za nią formularz logowania jest zepsuty.

Ponieważ jest to sprawdzenie syntetyczne, działa według harmonogramu bez potrzeby ruchu, a ponieważ napędza je prawdziwa przeglądarka, wykonuje JavaScript, zależności firm trzecich i przekierowania, które zwykłe sprawdzenie HTTP pomija. Tak właśnie działa monitoring transakcji HostTracker, a poradnik o sprawdzeniu transakcji opisuje, jak nagrywa się skrypt i co zgłasza każdy krok.

Zamiana pomiaru w alarm

Żadne z tych podejść nie jest przydatne, dopóki coś nie zareaguje na wynik. Sprawdzenie syntetyczne ma wartość, bo działa niezależnie od tego, czy akurat obserwujesz, i bo awaria może dotrzeć do Ciebie natychmiast: HostTracker uruchamia sprawdzenia z ponad 300 punktów kontrolnych w 158 miastach, w 13 typach monitorów, i wysyła alarmy e-mailem, SMS-em, połączeniem głosowym, przez Slack, Telegram i inne kanały, gdy wynik się zmienia. Połącz to z dowolnym RUM, który już zbierasz, a będziesz mieć obie połowy: alarm, gdy witryna się psuje, i dowód na to, dla kogo była wolna. Resztę pojęć, na których opierają się oba podejścia, opisuje sekcja pojęć monitoringu.