Monitoring dostępności strony: wiedz przed klientem
Najgorszy sposób na dowiedzenie się o awarii to wiadomość od klienta. Drugi najgorszy to alert przychodzący tak często, że po miesiącu przestajesz go czytać. Dobrze ustawiony monitoring mieści się pomiędzy tymi skrajnościami i to ustawienie, a nie wybór narzędzia, decyduje o tym, czy będzie z niego pożytek. Poniżej praktyczne podejście do tego, co mierzyć, jak często i kiedy naprawdę dzwonić.
Kod 200 potrafi kłamać
Najprostszy monitoring odpytuje adres strony i sprawdza, czy serwer odpowiedział kodem 200. Problem w tym, że bardzo wiele awarii daje poprawny kod odpowiedzi.
Strona z błędem połączenia z bazą potrafi zwrócić 200 razem z komunikatem o błędzie w treści. Sklep z zepsutym koszykiem odpowiada 200 na stronie głównej. Serwis przejęty przez skrypt przekierowujący też odpowie 200. We wszystkich tych przypadkach monitoring oparty o sam kod pokaże zielone światło.
Rozwiązanie jest banalne: każ narzędziu szukać w odpowiedzi konkretnego fragmentu treści, który występuje wyłącznie na działającej stronie. Numer telefonu w stopce, nazwa firmy w nagłówku, cokolwiek stabilnego. Jeśli tego fragmentu nie ma, traktuj to jak awarię, niezależnie od kodu. O tym, co oznaczają poszczególne kody, pisaliśmy we wpisie o kodach odpowiedzi HTTP.
Ile przestoju mieści się w SLA
Warto przeliczyć deklarowane wartości na minuty, bo dopiero wtedy stają się zrozumiałe. Przy SLA na poziomie 99,9%, jak w pakietach hostingowych RapidDC, dopuszczalny przestój to około 43 minuty miesięcznie. Przy 99% to już ponad 7 godzin miesięcznie.
Ta różnica między dziewiątkami jest znacznie większa, niż sugeruje zapis. Dlatego przy porównywaniu ofert patrz na liczbę miejsc po przecinku, a nie na samo hasło o wysokiej dostępności. I dlatego własny monitoring ma sens nawet przy dobrym SLA: to Ty musisz wiedzieć, czy te 43 minuty się wykorzystało.
Częstotliwość i próg, czyli jak nie zwariować
Dwa ustawienia decydują o tym, czy alerty są użyteczne.
Częstotliwość sprawdzania. Co minutę dla serwisów, gdzie liczy się każda minuta, co pięć minut dla większości stron firmowych. Częściej niż co minutę rzadko ma sens i tylko zwiększa szansę na fałszywy alarm.
Próg potwierdzenia. To najważniejsze ustawienie w całym monitoringu. Nigdy nie wysyłaj alertu po pierwszym nieudanym sprawdzeniu. Pojedyncze chybienie zdarza się z powodu chwilowego problemu sieciowego u sprawdzającego, nie u Ciebie. Ustaw dwa albo trzy kolejne niepowodzenia, najlepiej z różnych lokalizacji, zanim cokolwiek zadzwoni.
Do tego jedna zasada organizacyjna: alert musi mieć adresata. Powiadomienie wysyłane na skrzynkę, którą czyta cały zespół, w praktyce nie jest czytane przez nikogo.
Rzeczy, o których lepiej wiedzieć dwa tygodnie wcześniej
Część problemów da się zobaczyć z dużym wyprzedzeniem i to właśnie te powiadomienia mają najlepszy stosunek wartości do hałasu:
- data wygaśnięcia certyfikatu SSL, sprawdzana codziennie z alertem na dwa tygodnie przed,
- data wygaśnięcia domeny, pilnowana niezależnie od przypomnień rejestratora,
- zajętość dysku z alertem przy 80%, bo serwer bez wolnego miejsca zatrzymuje się w sposób trudny do zdiagnozowania,
- rosnący czas odpowiedzi, który zwykle narasta tygodniami, zanim zamieni się w awarię.
Certyfikaty w pakietach RapidDC odnawiają się automatycznie, ale jeśli obsługujesz serwisy klientów na różnych infrastrukturach, jedno wspólne miejsce pilnujące dat oszczędza naprawdę nieprzyjemnych rozmów. Dlaczego brak ważnego certyfikatu jest problemem także dla zaufania użytkowników, opisaliśmy we wpisie o certyfikacie SSL.
Monitoruj nie tylko stronę główną
Strona główna jest zwykle najprostsza i najlepiej zbuforowana, więc pada ostatnia. Warto obserwować dodatkowo:
- Jedną podstronę generowaną dynamicznie, na przykład listę produktów albo wyniki wyszukiwania.
- Ścieżkę krytyczną biznesowo: formularz kontaktowy albo koszyk.
- Punkt końcowy API, jeśli obsługujesz aplikację mobilną albo integracje.
- Panel logowania, oddzielnie od części publicznej.
Przy sprawdzaniu podstrony dynamicznej pamiętaj, żeby nie generować sobie sztucznego ruchu w statystykach i nie trafić na własne zabezpieczenia blokujące powtarzalne żądania. Najprościej dodać adres monitoringu do listy wykluczeń.
Podsumowanie
Monitoring, który budzi za często, jest gorszy od żadnego, bo uczy ignorowania powiadomień. Sprawdzaj treść, nie kod. Potwierdzaj awarię przed wysłaniem alertu. Osobno pilnuj dat, które da się przewidzieć.
Solidna podstawa to serwer, który po prostu działa: hosting RapidDC pracuje z SLA 99,9% i łączem 1 Gbps, a serwery VPS dokładają bezpłatny antyDDoS i wsparcie techniczne dostępne całą dobę. Jak sprawdzić dostępność samodzielnie i jednorazowo, pokazaliśmy we wpisie o tym, jak sprawdzić uptime serwera.
FAQ – najczęściej zadawane pytania o monitoring dostępności
Jak często powinienem sprawdzać stronę?
Co pięć minut wystarcza większości serwisów firmowych. Co minutę wybieraj tam, gdzie przestój przekłada się bezpośrednio na sprzedaż. Częstsze sprawdzanie rzadko daje przewagę, a podnosi liczbę fałszywych alarmów.
Czym różni się monitoring zewnętrzny od tego na serwerze?
Zewnętrzny sprawdza, czy strona jest widoczna z internetu, więc wykryje też awarię sieci i problem z DNS. Monitoring działający na samym serwerze zamilknie razem z nim. Oba są przydatne, ale zewnętrzny jest ważniejszy.
Dlaczego dostaję alerty o awariach, których nie było?
Najczęściej z powodu wysyłania powiadomienia po jednym nieudanym sprawdzeniu. Ustaw potwierdzenie z dwóch lub trzech kolejnych prób, najlepiej z różnych lokalizacji, a liczba fałszywych alarmów spadnie niemal do zera.
Czy monitoring obciąża serwer?
Przy rozsądnej częstotliwości praktycznie nie. Jedno żądanie co pięć minut to znikomy ułamek normalnego ruchu. Uwagę zwróć tylko na sprawdzanie kosztownych podstron, na przykład wyszukiwarki na dużym katalogu.
Co powinien zawierać dobry alert?
Nazwę serwisu, rodzaj problemu, czas wystąpienia i adres, który zawiódł. Alert o treści „strona nie działa” bez tych informacji wymaga dochodzenia, a właśnie w takim momencie czasu jest najmniej.
Artykuł powstał z wykorzystaniem narzędzi sztucznej inteligencji (AI) pod nadzorem zespołu RapidDC. Grafika ilustracyjna została wygenerowana przez AI.