Jak działa monitorowanie dostępności witryn w 2026 roku

Usługa osiągająca 99,99% dostępności jest niedostępna przez niespełna 53 minuty rocznie. Spadek do 99,9% oznacza utratę ponad ośmiu godzin. Monitorowanie dostępności to niewielki element infrastruktury, który wychwytuje te minuty w momencie ich wystąpienia. Ten przewodnik wyjaśnia, jak to działa, co monitorować, jak często sprawdzać i jakie błędy zamieniają przydatne narzędzie w szum tła.

Co właściwie robi monitor dostępności

Monitor dostępności działa w prostej pętli. Z serwera znajdującego się gdzieś w publicznym internecie wysyła zapytanie do wskazanego przez Ciebie celu. Rejestruje odpowiedź, kod statusu i czas trwania pełnego obiegu. Następnie czeka określony interwał i próbuje ponownie.

Sonda celowo znajduje się poza Twoją infrastrukturą. Gdybyś monitorował z wnętrza własnej sieci, nie wychwyciłbyś awarii, które od środka wyglądają poprawnie, ale faktycznie blokują prawdziwych użytkowników. To różnica między monitorowaniem syntetycznym (zewnętrzna sonda) a monitorowaniem rzeczywistych użytkowników (telemetria od prawdziwych odwiedzających). Większość zespołów stosuje oba. Monitorowanie dostępności to strona syntetyczna.

Co właściwie można monitorować

Współczesne narzędzia do monitorowania obejmują znacznie więcej niż HTTP. Dziewięć typów sond dostępnych na rynku odpowiada na nieco inne pytania.

• HTTP zwraca kod statusu i czas odpowiedzi dla dowolnego adresu URL.
• Ping (ICMP) sprawdza, czy host odpowiada na poziomie sieciowym.
• SSL sprawdza, ile dni pozostało do wygaśnięcia Twojego certyfikatu.
• DNS weryfikuje, czy rekordy A, AAAA, MX, TXT lub NS nadal rozwiązują się do oczekiwanych wartości.
• Port TCP sprawdza, czy usługa nasłuchuje na danym porcie lub czy port, który powinien być zamknięty, nagle nie został otwarty.
• WHOIS śledzi datę wygaśnięcia rejestracji Twojej nazwy domeny.
• Blacklist sprawdza, czy Twój IP wysyłający trafił na listy Spamhaus, SORBS lub podobne.
• Heartbeat odwraca relację: to Twoje zadanie wysyła ping do monitora, a Ty otrzymujesz alert, gdy przestanie to robić.

Jak często sprawdzać

Częstotliwość sprawdzania to kompromis między dokładnością a szumem. Szybsza kadencja wychwytuje krótsze awarie, ale generuje więcej fałszywych alarmów wynikających z chwilowych zakłóceń sieciowych. Wolniejsza kadencja wygładza szum, ale pomija krótkie awarie, które i tak wliczają się do Twojego budżetu błędów.

Pragmatyczne ustawienie domyślne: 60 sekund dla HTTP i pingu na ważnych usługach, 5 minut dla stron o niskim priorytecie, 15 minut dla SSL, co godzinę dla WHOIS. Schodź do 30 sekund tylko dla usług, w których przestój wymiernie kosztuje pieniądze za każdą minutę. Zejście poniżej 30 sekund rzadko poprawia rezultat, a często prowadzi do zmęczenia alertami.

Trasowanie alertów bez szumu

Alert, którego nikt nie czyta, jest gorszy niż brak alertu. Trzy zasady wystarczają większości zespołów.

• Domyślnie wysyłaj alerty DOWN do jednego kanału, najlepiej tego, który Twój zespół już sprawdza (Slack, Discord, Telegram lub e-mail).
• Stosuj regułę progową wymagającą co najmniej 3 kolejnych niepowodzeń przed wywołaniem pagera. Jedno chybione sprawdzenie to szum. Trzy z rzędu to sygnał.
• Trasuj krytyczne usługi do narzędzia pagującego (PagerDuty, Opsgenie) za pomocą podpisanego webhooka. Wszystko inne kieruj do czatu. Potwierdzaj incydenty, aby wyciszyć pager, gdy zajmie się nimi człowiek.

Błędy, które zabijają programy monitorowania dostępności

Pierwszy błąd to monitorowanie wyłącznie strony głównej. Działająca strona główna nie mówi prawie nic o procesie zamówienia ani o API, z którym komunikuje się Twoja aplikacja mobilna. Dodaj konkretne monitory HTTP dla adresów URL najważniejszych dla przychodów lub obciążenia wsparcia.

Drugi błąd to ciche rozsyłanie. Każdy monitor uruchamia każdy kanał, potem każdy członek zespołu wycisza te najbardziej hałaśliwe, a prawdziwy incydent pojawia się w wyciszonym kanale. Zdefiniuj jedną domyślną trasę, kieruj wyjątki do konkretnych osób i przeglądaj reguły co kwartał.

10-minutowa konfiguracja początkowa

Jeśli zaczynasz od zera, praktyczna sekwencja jest krótka. Utwórz monitor HTTP dla głównego adresu URL z interwałem 60 sekund. Utwórz monitor SSL dla tej samej nazwy hosta z 30-dniowym oknem ostrzegawczym. Utwórz jedną regułę powiadomień, która kieruje alerty DOWN do czatu zespołu. Dodaj stronę statusu, jeśli masz zewnętrznych użytkowników, którym zależy na dostępności. Dodaj heartbeaty dla zadań cron obsługujących rozliczenia, raporty i kopie zapasowe. Jesteś już ponad medianą operatorów.