Pytanie, jak monitorować dostępność serwera, pojawia się zwykle po pierwszej dłuższej awarii — gdy o niedziałającej stronie informuje klient, a nie administrator. Monitoring odwraca tę kolejność: powiadomienie przychodzi w 30–60 sekund od zdarzenia, zanim użytkownik porzuci koszyk lub formularz. Wiedza o tym, jak monitorować dostępność serwera, sprowadza się do trzech decyzji: co dokładnie sprawdzamy, jak często i kto ma zostać obudzony w środku nocy. Techniczna strona jest prostsza, niż się wydaje — ping, zapytanie HTTP, test portu i kontrola treści odpowiedzi wykrywają zdecydowaną większość realnych problemów. Trudniejsze bywa ustalenie progów, które nie generują fałszywych alarmów i nie usypiają czujności zespołu. Ten przewodnik prowadzi przez metody pomiaru, konkretne narzędzia z widełkami cenowymi, wpływ warstwy hostingowej i domenowej oraz pułapki, przez które panel pokazuje zieloną ikonę przy realnie zepsutej usłudze. Każdy element opisano tak, by dało się go wdrożyć w jedno popołudnie.
Dostępność serwera w liczbach: uptime, SLA i koszt przestoju
Dostępność opisuje procent czasu, w którym usługa odpowiada poprawnie. Różnica między 99% a 99,9% wygląda kosmetycznie, lecz oznacza 3,65 dnia przestoju rocznie zamiast 8 godzin i 45 minut. Poziom 99,99% zostawia już tylko 52 minuty budżetu awaryjnego w skali dwunastu miesięcy, wliczając w to planowane prace serwisowe.
Umowy SLA u dostawców hostingu deklarują najczęściej 99,9% i przewidują rekompensatę w formie przedłużenia abonamentu, nie zwrotu utraconych przychodów. Żeby taką rekompensatę wyegzekwować, potrzebny jest niezależny dowód: raport z zewnętrznego systemu monitoringu ze znacznikami czasu i kodami odpowiedzi, a nie zrzut ekranu przeglądarki wykonany po fakcie.
Koszt przestoju liczy się prosto. Sklep z obrotem 60 000 zł miesięcznie traci średnio 83 zł za każdą godzinę niedostępności, a w piątkowy wieczór wielokrotność tej kwoty. Do strat bezpośrednich dochodzi ryzyko spadku pozycji w wyszukiwarce, gdy robot indeksujący wielokrotnie trafia na serię odpowiedzi 503.
| Poziom dostępności | Przestój w roku | Przestój w miesiącu | Typowe zastosowanie |
|---|---|---|---|
| 99,0% | 3 dni 15 godz. | 7 godz. 18 min | blog, strona wizytówka |
| 99,5% | 1 dzień 19 godz. | 3 godz. 39 min | strona firmowa |
| 99,9% | 8 godz. 45 min | 43 min | sklep, aplikacja SaaS |
| 99,95% | 4 godz. 22 min | 21 min | system rezerwacji, API |
| 99,99% | 52 min | 4 min | bramka płatnicza |
Metody pomiaru: od pinga po kontrolę treści odpowiedzi
Ping ICMP jest najtańszy obliczeniowo i najbardziej mylący. Maszyna potrafi odpowiadać na pakiety ICMP, gdy proces PHP-FPM leży, baza danych odrzuca połączenia, a przeglądarka pokazuje pusty ekran. Wiele firm blokuje zresztą ICMP na firewallu, przez co sprawny serwer wygląda w panelu na trwale niedostępny.
Test HTTP lub HTTPS daje obraz znacznie bliższy doświadczeniu użytkownika. Sprawdzarka wysyła zapytanie GET, oczekuje kodu 200 i mierzy czas odpowiedzi z rozbiciem na rozwiązanie DNS, uścisk TLS oraz pobranie pierwszego bajtu. Próg alertu ustawia się zwykle na 3 sekundy dla TTFB i dwie kolejne nieudane próby.
Najpewniejszy wariant to kontrola treści: monitor pobiera stronę i szuka w kodzie konkretnego ciągu, na przykład nazwy kategorii lub etykiety przycisku koszyka. Ten test wyłapuje sytuacje, w których serwer zwraca poprawne 200 razem z komunikatem o błędzie bazy albo stroną w trybie konserwacji.
Monitoring zewnętrzny kontra agent zainstalowany na serwerze
Sondy zewnętrzne odpowiadają na pytanie, czy usługa jest widoczna z internetu, i wykrywają problemy z routingiem, DNS oraz zaporą. Agent lokalny, taki jak Netdata czy Zabbix Agent, raportuje obciążenie procesora, zajętość RAM, kolejkę dyskową i liczbę procesów. Dopiero razem pozwalają odróżnić awarię łącza od przeciążenia maszyny.
Rozsądny zestaw minimalny to trzy sondy zewnętrzne z różnych lokalizacji, sprawdzające stronę główną, jeden adres API oraz port 3306 lub 5432 bazy danych. Alert wysyłany jest wtedy, gdy co najmniej dwie lokalizacje zgłoszą błąd, co eliminuje większość fałszywych powiadomień wywołanych chwilową awarią pojedynczego węzła.
Narzędzia monitoringu i realne widełki cenowe
Bezpłatne plany wystarczają zaskakująco często. UptimeRobot w wersji darmowej obsługuje 50 monitorów z interwałem 5 minut i powiadomieniami e-mail, Uptime Kuma instaluje się na własnym VPS w kilkanaście minut, a Healthchecks.io pilnuje zadań cron. Ograniczeniem bywa brak SMS-ów i krótka historia zdarzeń.
Plany płatne kupuje się dla interwału 30-sekundowego, powiadomień głosowych oraz publicznych stron statusu. Better Stack, Pingdom czy StatusCake mieszczą się w widełkach około 40–250 zł miesięcznie przy kilkunastu monitorach. Za tę kwotę otrzymuje się także harmonogram dyżurów, eskalację do drugiej osoby i raporty zgodne z zapisami SLA.
Wariant samodzielny opiera się na Zabbiksie, Prometheusie z Alertmanagerem lub Grafanie Loki uruchomionych na osobnym serwerze VPS za 20–60 zł miesięcznie. Kluczowa zasada brzmi: system monitorujący nigdy nie może stać na tej samej maszynie ani u tego samego dostawcy, co monitorowana usługa.
- Sonda HTTPS strony głównej co 60 sekund z kontrolą frazy w treści.
- Sonda TCP portu bazy danych oraz portu 22 lub panelu administracyjnego.
- Kontrola daty wygaśnięcia certyfikatu z alertem na 21 dni przed końcem.
- Kontrola daty wygaśnięcia domeny z alertem na 45 dni przed terminem.
- Heartbeat kopii zapasowej: brak sygnału po 26 godzinach uruchamia alarm.
Hosting i domena jako źródła awarii poza samym serwerem
Zanim zaczniesz szukać winowajcy w kodzie, sprawdź warstwę infrastruktury. To, czym różni się VPS od hostingu współdzielonego, ma tu bezpośrednie przełożenie: na współdzielonym koncie sąsiednia witryna potrafi wyczerpać limit procesów i wywołać błąd 508, którego nie naprawisz żadną optymalizacją własnej aplikacji.
Pytanie, jak wybrać hosting pod WordPress, sprowadza się do parametrów mierzalnych: liczby jednoczesnych procesów PHP, wersji PHP powyżej 8.2, obecności OPcache i Redisa, limitu wejść-wyjść na dysku oraz codziennej kopii zapasowej przechowywanej poza serwerem. Deklarowany nielimitowany transfer nie mówi nic o stabilności.
Gdy statystyki z monitoringu pokazują powtarzalne przestoje w godzinach szczytu, temat, jak przenieść stronę na inny hosting, przestaje być teoretyczny. Migrację planuje się przy obniżonym TTL rekordów do 300 sekund, z kopią bazy i plików, testem na adresie tymczasowym oraz przełączeniem DNS poza godzinami największego ruchu.
Domena i rekordy DNS pod stałą kontrolą
Sprawdzenie, jak sprawdzić kto jest właścicielem domeny, zajmuje chwilę w bazie WHOIS lub RDAP i bywa ratunkiem, gdy kontakt techniczny wskazuje na byłą agencję. Równie istotne jest to, jak przedłużyć domenę po wygaśnięciu: po dacie ważności biegnie zwykle 30-dniowa karencja, a późniejsze przywrócenie kosztuje kilkaset złotych.
Wiedza o tym, jak skonfigurować rekordy DNS domeny, decyduje o czasie powrotu po awarii. Rekord A wskazuje adres IP, MX kieruje pocztę, a odpowiedź na pytanie, co to jest rekord CNAME, brzmi: alias przekazujący zapytanie do innej nazwy, wygodny przy CDN, lecz niedozwolony w korzeniu domeny.
Certyfikaty, przekierowania i łącze, czyli ciche zabójcy dostępności
Wygasły certyfikat wygląda dla odwiedzającego jak awaria serwera, choć usługa działa bez zarzutu. Kwestia, jak zainstalować certyfikat SSL na serwerze, kończy się dziś zwykle na Certbocie, bo darmowy certyfikat SSL Let’s Encrypt wydawany jest na 90 dni i odnawiany automatycznie. Monitoring musi jednak weryfikować skuteczność tego odnowienia.
Druga cicha przyczyna to błędna reguła kierująca ruch. Temat, jak ustawić przekierowanie 301 w htaccess, wraca przy każdej zmianie adresów, a literówka w wyrażeniu regularnym tworzy pętlę zakończoną błędem ERR_TOO_MANY_REDIRECTS. Monitor śledzący łańcuch przekierowań powinien alarmować, gdy przekroczy on trzy przeskoki.
Zdarza się też, że problem leży po stronie obserwatora. Zanim zgłosisz awarię, ustal, jak sprawdzić prędkość internetu rzetelnie: pomiar kablem, przy wyłączonych pobieraniach, powtórzony na dwóch serwerach testowych. Gdy wyniki spadają tylko bezprzewodowo, właściwym tematem jest raczej to, jak wzmocnić sygnał WiFi w domu, niż stan serwerowni.
Jak często powinien działać sprawdzian dostępności serwera?
Interwał dobiera się do kosztu minuty przestoju. Dla bloga firmowego wystarczy sprawdzanie co 5 minut, bo różnica między wykryciem awarii po minucie a po pięciu nie zmienia niczego biznesowo. Sklep internetowy i systemy rezerwacji uzasadniają interwał 60-sekundowy, a bramki płatnicze oraz publiczne API pilnuje się co 30 sekund z kilku lokalizacji równocześnie. Kluczowa jest przy tym reguła potwierdzania: alert wysyłany dopiero po dwóch kolejnych niepowodzeniach z co najmniej dwóch różnych sond. Bez tego zabezpieczenia zespół dostaje kilkanaście powiadomień tygodniowo o zdarzeniach trwających sekundy, po miesiącu przestaje je czytać, a prawdziwa awaria ginie w szumie.
Czy darmowe narzędzia do monitoringu wystarczą małej firmie?
W większości przypadków tak, pod dwoma warunkami. Po pierwsze, plan bezpłatny musi oferować interwał nie dłuższy niż 5 minut i powiadomienia na kanał, który realnie sprawdzasz — sam e-mail o trzeciej nad ranem nikogo nie obudzi, więc warto podpiąć integrację z komunikatorem zespołowym lub aplikacją mobilną. Po drugie, monitoring nie może działać na tej samej infrastrukturze co witryna, bo awaria serwerowni wyłączy wtedy również system alarmowy. Do płatnego planu przechodzi się zwykle wtedy, gdy potrzebny jest SMS, harmonogram dyżurów, publiczna strona statusu dla klientów albo dłuższa historia zdarzeń do rozliczenia SLA z dostawcą.
Co zrobić, gdy monitoring zgłasza awarię, a strona działa?
Zacznij od odtworzenia warunków sondy, a nie własnej przeglądarki. Wykonaj zapytanie narzędziem curl z pominięciem pamięci podręcznej i obejrzyj pełne nagłówki oraz kod odpowiedzi. Sprawdź, czy zapora lub system antybotowy nie blokuje adresów IP sondy albo jej identyfikatora przeglądarki, co jest najczęstszą przyczyną rozbieżności. Zweryfikuj następnie rozwiązywanie nazwy z zewnętrznego resolvera, ponieważ lokalna pamięć podręczna DNS może przechowywać stary, wciąż działający adres. Jeśli wszystko wygląda poprawnie, ustaw sondę na kontrolę treści zamiast samego kodu odpowiedzi i dodaj drugą lokalizację testową — dwa niezależne punkty pomiaru rozstrzygają spór między panelem a subiektywnym wrażeniem.