Strona może „działać”, a mimo to być zepsuta: serwer odpowiada kodem HTTP 200, ale na stronie widać błąd bazy danych, pustą listę produktów albo domyślną stronę firmy hostingowej. Sprawdzenie, które patrzy tylko na kod statusu, przepuści każdy z tych przypadków. Monitorowanie słów kluczowych zamyka tę lukę, bo sprawdza też treść: tekst, który musi być na stronie, na przykład „Dodaj do koszyka”, albo tekst, którego być na niej nie może, na przykład „Fatal error”. Jeśli warunek nie jest spełniony, strona jest traktowana jako niedostępna, a Ty dostajesz alert.
Jak strona może działać i jednocześnie być zepsuta
Kod statusu ustawia to, co odpowiada na żądanie, a to nie zawsze jest ta część stosu, która zawiodła. Wszystkie poniższe sytuacje zdarzają się przy kodzie 200 albo przy kodzie, który Twój monitor akceptuje:
Strona błędu aplikacji. Niektóre frameworki, motywy i własne strony błędów wyświetlają błędy z kodem 200 zamiast kodu 5xx.
Pusta strona. Krytyczny błąd PHP przy wyłączonym wyświetlaniu błędów może dać pustą odpowiedź, a cache może zapisać i serwować pustą stronę.
Brakujące dane. Sklep się ładuje, ale API produktów za nim zawiodło, więc w każdej kategorii widać „Nie znaleziono produktów”.
Niewłaściwa witryna. Po zmianie hostingu lub DNS domena trafia na stronę domyślną, taką jak „Welcome to nginx!”, albo na stronę parkingową.
Pozostawiona strona konserwacji. Wtyczka trybu konserwacji, która odpowiada kodem 200 zamiast 503, dla sprawdzenia statusu wygląda jak działająca strona.
Podmieniona lub zainfekowana strona. Atakujący podmienia treść albo dodaje linki spamowe, a serwer nadal odpowiada normalnie.
Google nazywa stronę, która mówi „nie znaleziono” albo nic nie pokazuje, a odpowiada kodem 200, soft 404, i takie strony mogą wypaść z wyników wyszukiwania. Użytkownicy po prostu widzą zepsutą stronę.
Jak działa monitorowanie słów kluczowych
Przy każdym sprawdzeniu monitor pobiera stronę, odczytuje HTML zwrócony przez serwer i szuka w nim Twojego tekstu. Są dwa tryby:
Musi zawierać: sprawdzenie kończy się niepowodzeniem, gdy tekstu brakuje. Użyj go jako dowodu, że strona działa, na przykład etykiety przycisku albo nazwy produktu.
Nie może zawierać: sprawdzenie kończy się niepowodzeniem, gdy tekst się pojawi. Używaj go do znanych komunikatów o błędach.
Liczą się dwa szczegóły. Sprawdzenie czyta źródło HTML, a nie stronę widoczną w przeglądarce, więc tekstu dodanego później przez JavaScript tam nie ma. Poza tym dopasowanie jest zwykle dokładne, z uwzględnieniem wielkości liter. Krótką definicję znajdziesz w haśle słownika o monitorowaniu słów kluczowych.
Jak wybrać dobre słowo kluczowe
Dobre słowo kluczowe typu „musi zawierać” pojawia się tylko wtedy, gdy strona działa, i nie zmienia się z dnia na dzień. To wyklucza ceny, daty, stany magazynowe, liczniki i wszystko, co jest objęte testem A/B. Wybieraj tekst, który aplikacja generuje ze swoich danych lub szablonów, więc znika, gdy aplikacja zawiedzie, a nie tekst ze statycznego nagłówka, który cache mógłby nadal serwować.
StronaMusi zawieraćDlaczego to działaStrona produktuDodaj do koszykaWyświetla się tylko wtedy, gdy działają produkt i koszykStrona kategoriiNazwa produktu, który zawsze jest dostępnyZnika, gdy nie wczytają się dane produktówStrona logowaniaNie pamiętasz hasła?Część prawdziwego formularza logowania, a nie strony błęduBlog lub strona z aktualnościamiWiersz ze stopki generowanej przez CMSZnika, gdy CMS nie może połączyć się z bazą danychEndpoint health check”status”:”ok”Zapisywany przez aplikację po sprawdzeniu jej zależności
W przypadku API lub endpointu health check sprawdzenie JSON, na przykład $.status równe ok, jest dokładniejsze niż słowo kluczowe, bo nie zależy od odstępów ani kolejności pól.
Sprawdzenia „nie może zawierać” dla komunikatów o błędach
Sprawdzenie negatywne wyłapuje awarie, które potrafisz nazwać z góry. Przydatne ciągi znaków, zależnie od Twojego stosu:
Error establishing a database connection w WordPressie. Rdzeń wysyła go z kodem 500, ale własna strona db-error.php może tego nie robić.
Fatal error lub Parse error na stronach PHP, które wyświetlają błędy.
Welcome to nginx! albo tytuł domyślnej strony Twojego hostingu, żeby wyłapać domenę wskazującą na niewłaściwy serwer.
Słowa spamowe, które nie mają prawa pojawić się na Twojej stronie, jako prosty alarm na wstrzykniętą treść.
Uważaj na strony, na których taki ciąg może pojawić się zupełnie zasadnie. Wpis na blogu o błędach bazy danych albo artykuł pomocy cytujący komunikat o błędzie za każdym razem oblałby sprawdzenie „nie może zawierać”. W razie wątpliwości bezpieczniejsze jest sprawdzenie pozytywne na tekście, który dowodzi, że strona działa, bo wyłapuje też awarie, których nie przewidziałeś.
Przetestuj słowo kluczowe, zanim na nim polegniesz
Sprawdź, co serwer faktycznie wysyła, a nie to, co pokazuje przeglądarka. W terminalu:
curl -s –compressed https://example.com/product/blue-mug | grep -c „Add to cart”
Wynik 0 oznacza, że monitor też go nie znajdzie. Najczęstsze przyczyny:
Tekst renderuje JavaScript. Wyświetl źródło strony (nie inspektor), żeby zobaczyć HTML zwracany przez serwer, i wybierz tekst, który w nim jest.
Encje HTML. „Terms & Conditions” na ekranie to w źródle często Terms & Conditions, a cudzysłowy typograficzne też mogą być zakodowane. Wybierz tekst bez znaków specjalnych albo skopiuj go ze źródła.
Wielkość liter i odstępy. Przycisk zapisany wielkimi literami za pomocą CSS w HTML nadal brzmi „Add to cart”. Łamania wierszy wewnątrz tekstu też psują dokładne dopasowanie.
Monitor widzi inną stronę. Strony, które wybierają język lub walutę na podstawie lokalizacji albo pokazują nieznanym klientom wyzwanie antybotowe, mogą wysyłać monitorowi inny HTML niż ten, który widzisz przy biurku.
Kiedy słowo kluczowe nie wystarczy
Treść zależy od JavaScriptu. Aplikacje typu single-page wysyłają niewiele HTML. Sprawdzaj je flow w prawdziwej przeglądarce, który uruchamia JavaScript, zanim zacznie szukać tekstu.
Awaria pojawia się kilka kroków dalej. Strona produktu działa, ale dodawanie do koszyka już nie. Wieloetapowe sprawdzenie syntetyczne przechodzi całą ścieżkę i sprawdza każdy krok.
Strona jest bardzo duża. Monitory zwykle czytają tylko początkową część odpowiedzi. Szukaj tekstu blisko początku albo sprawdzaj mniejszy endpoint.
Strona jest wolna, a nie zepsuta. To kwestia czasu odpowiedzi; zamiast słowa kluczowego ustaw limit wolnej odpowiedzi.
Lista kontrolna tego, co monitorować na stronie podpowiada, które strony zasługują na sprawdzenie treści, a poradnik jak ograniczyć fałszywe alerty opisuje resztę dostrajania.
Sprawdzenia słów kluczowych w Uptimecheck
Każdy monitor HTTP(S) w ramach monitorowania dostępności Uptimecheck może mieć sprawdzenie słowa kluczowego obok oczekiwanych kodów statusu:
Zawiera lub nie zawiera: jedno słowo kluczowe na monitor, dopasowywane dokładnie, z uwzględnieniem wielkości liter, w pierwszych 2 MB odpowiedzi. Potrzebujesz sprawdzenia pozytywnego i negatywnego na tej samej stronie? Dodaj drugi monitor.
Sprawdzenia JSON i nagłówków: do 10 na monitor, na przykład $.status równe ok albo nagłówek Content-Type zawierający json, dla API i endpointów health check.
Żądanie testowe: zobacz odpowiedź i to, czy sprawdzenia przechodzą, zanim zapiszesz monitor.
Potwierdzone i wyjaśnione: nieudane sprawdzenie jest powtarzane, zanim otworzy się incydent, a incydent mówi, co było nie tak, na przykład że oczekiwanego tekstu nie było na stronie albo że strona wróciła pusta, i pokazuje początek odpowiedzi.
JavaScript i ścieżki użytkownika: flow sprawdzają tekst na każdym kroku, a flow w prawdziwej przeglądarce widzą tekst renderowany przez JavaScript i robią zrzut ekranu kroku, który zawiódł.
Sprawdzenia działają nawet co minutę ze Sztokholmu, Londynu i Nowego Jorku, więc strona, która zmienia język zależnie od lokalizacji, pokazuje Uptimecheck wersję serwowaną w Szwecji, Wielkiej Brytanii lub USA; wybierz słowo kluczowe, które jest takie samo w każdej wersji, albo wysyłaj nagłówki wybierające język. Jak to skonfigurować, przeczytasz w artykule jak dodać pierwszy monitor, a jeśli monitor zgłasza awarię, choć strona u Ciebie działa, zajrzyj do artykułu dlaczego monitor może pokazywać awarię, gdy strona działa.
Niech „działa” znaczy naprawdę działa. Wypróbuj Uptimecheck za darmo przez 14 dni, bez karty kredytowej.