Monitoring dostępności strony z ponad 300 lokalizacji na całym świecie

Sześć kart powyżej to miejsce, w którym zaczyna większość kont. Pełny katalog to czternaście typów monitorów, które dzielą tę samą flotę lokalizacji, ten sam protokół potwierdzania i to samo kierowanie alertów - nie używasz jednego narzędzia do dostępności, a drugiego do certyfikatów.

Sprawdzenia sieciowe są wykonywane z publicznej floty ponad 300 lokalizacji. Sprawdzenia infrastruktury - zapytanie do bazy danych, licznik wydajności i SNMP - przechodzą zamiast tego przez dedykowanych agentów, bo potrzebują poświadczeń i dostępu do Twojej sieci, a nie geografii.

Ma to znaczenie, bo najczęstsze powody, dla których sprawdzenie „kończy się niepowodzeniem”, nie mają nic wspólnego z Twoim serwerem:

• Zepsuła się ścieżka, nie strona. Dostawca tranzytu źle kieruje ruch przez dziewięćdziesiąt sekund, podczas gdy każda inna sieć nadal do Ciebie dociera.
• Zepsuła się strona, ale tylko dla części osób. Węzeł CDN w jednym regionie serwuje nieaktualne błędy albo reguła zapory blokuje cały kraj - a punkt obserwacji w niewłaściwym miejscu uznaje, że „wszystko w porządku”.
• Zepsuła się sonda. Bez drugiej opinii uszkodzony węzeł i uszkodzona strona wyglądają tak samo.

Monitorowanie rozproszone odpowiada na wszystkie trzy przypadki tak samo: zapytać kilka niezależnych miejsc, a potem porównać. Aby wykonać to porównanie jednorazowo, od razu, użyj bezpłatnego sprawdzenia HTTP z wielu lokalizacji.

1. Monitor przychodzi na swoją kolej. Interwały wahają się od jednej minuty do 24 godzin, domyślnie trzy, a zaległa praca jest przejmowana w sposób ciągły, a nie w oknach wsadowych.
2. Lokalizacja jest wybierana z wybranych przez Ciebie grup. Wybierasz grupy, a nie maszyny, więc sprawdzenie rotuje w obrębie grupy zamiast przywiązywać się do jednej maszyny.
3. Sprawdzenie jest wykonywane. Lokalizacja wykonuje prawdziwe żądanie - pobranie HTTP, ping ICMP, uzgadnianie TCP, załadowanie strony w przeglądarce - i zwraca wynik, rozbicie czasów oraz, tam gdzie to ma sens, treść odpowiedzi.
4. Zmiana stanu uruchamia potwierdzanie, a nie alert. Tylko potwierdzona zmiana otwiera lub zamyka okres przestoju.

Grupy, na które można skierować monitor, mają nazwy i można je wybrać w interfejsie oraz w API:

Nowy monitor startuje na Europie Zachodniej, Europie Wschodniej i Ameryce Północnej. Grupy można łączyć i odejmować: allworld z -russia oznacza „wszędzie oprócz Rosji”, i tak wyłączasz krajowy routing jednego państwa z Twoich alertów.

Pojedyncze nieudane sprawdzenie nigdy nie wysyła alertu. Gdy wynik różni się od bieżącego stanu monitora, HostTracker otwiera sesję potwierdzającą i wstrzymuje alert, dopóki nie odpowiedzą inne lokalizacje:

1. Poczekać dziesięć sekund. Cel, który właśnie zmienił stan, najmniej potrzebuje fali dodatkowego ruchu, a wiele zakłóceń mija przed dziesiątą sekundą.
2. Rozłożyć ponowne sprawdzenie. Do siedmiu lokalizacji jest losowanych z przetasowanej puli i uruchamianych w odstępach dwóch sekund, więc ponowne sprawdzenia są rozłożone w czasie, a nie tylko w przestrzeni. Jeśli wolnych zaufanych lokalizacji jest za mało, kworum jest uzupełniane do minimum trzech.
3. Posortować odpowiedzi przed ich zliczeniem. Lokalizacja, która nie mogła wykonać sprawdzenia, nie jest liczona i nie jest karana. Ta, która zwraca bezużyteczny wynik, również nie jest liczona, zostaje oznaczona i wysyłana jest jej zastępczyni.
4. Zastosować regułę zgodności. Domyślnie decyduje większość. Dla każdego monitora możesz wymagać, by co najmniej ustalona liczba lokalizacji zgłosiła awarię, wymagać pełnej zgodności w obu kierunkach albo wymagać pełnej zgodności dla awarii, podczas gdy powroty do działania potwierdza większość.
5. Ocenić lokalizacje względem werdyktu. Lokalizacja, która ciągle się różni, dostaje punkt nieufności z odliczaniem, jest pomijana, dopóki ono trwa, i odzyskuje miejsce w miarę wygasania odliczania. Tak niestabilny węzeł sam się wycofuje.
6. Jeśli nie wróciło nic, co można zliczyć, nikt nie jest budzony. Sesja kończy się bez werdyktu, a bazowe sprawdzenie jest ponawiane później.

Ma też wyłącznik: sprawdzenie, którego wynik jest jednoznaczny samo w sobie (zapytanie do bazy danych albo zwróciło wiersz, albo nie), całkowicie pomija potwierdzanie.

Najmocniejszy argument za monitorowaniem z wielu lokalizacji to nie awaria, którą zauważają wszyscy, ale ta, którą zauważają tylko niektórzy. Działa w Europie, nie działa w Ameryce Północnej - wygląda to tak:

To ilustracja, ale właśnie taki kształt ma prawdziwy wynik dla każdej lokalizacji. Domyślna reguła większości nie uznaje tego za awarię globalną, bo nią nie jest. Zapisuje natomiast, które lokalizacje zawiodły, w której sekundzie i z jakim błędem - dowody ze znacznikiem czasu, zebrane spoza sieci Twojego dostawcy, i to właśnie sprawia, że nadają się do zgłoszenia w supporcie.

Aby dostać alert o awarii regionalnej, a nie tylko mieć ją w dzienniku: ustaw regułę potwierdzania na „co najmniej tyle lokalizacji zgłasza awarię” albo uruchom drugi monitor przypięty do tego regionu, gdzie awaria jest większością. Diagnozujesz właśnie hosta? Globalny test ping pokazuje ten obraz jednym kliknięciem.

Alertowanie opiera się na własnym opóźnieniu każdego kontaktu, a nie na jednej globalnej regule. Każdy kontakt wybiera, kiedy chce się dowiedzieć o awarii: od razu albo po 3, 5, 15, 30 lub 60 minutach ciągłej awarii, albo po 3, 6, 12 lub 24 godzinach. Ta drabina zamienia listę kontaktów w politykę eskalacji bez osobnego produktu do dyżurów - minuta 0 do kanału zespołu, minuta 5 do telefonu dyżurnego inżyniera, minuta 30 do lidera inżynierii, godzina 3 do właściciela konta.

Kanały dla każdego szczebla: e-mail, SMS, połączenie głosowe, powiadomienie push w przeglądarce, Slack, Telegram, Discord, Viber i podpisane webhooki - to przez webhook alerty docierają do menedżera incydentów, systemu zgłoszeń lub dowolnego wewnętrznego narzędzia z przychodzącym adresem URL.

Monitoring, który tylko alarmuje, to połowa produktu. Drugą połową jest zapis, który po sobie zostawia - to, czego używasz w sporze z hostingiem, przy roszczeniu o kredyt SLA lub w przeglądzie po incydencie.

• Wyniki sprawdzeń dla każdej lokalizacji ze statusem, czasem odpowiedzi i tekstem błędu, przechowywane jako historia, a nie tylko bieżący stan.
• Okresy przestoju z potwierdzonym początkiem, potwierdzonym końcem i śladem potwierdzenia za oboma.
• Cykliczne raporty uptime wysyłane e-mailem w ustawionym przez Ciebie rytmie.
• Eksport SLA i odznaka uptime publikowane bezpośrednio ze strony statusu.
• Okna serwisowe, aby planowane prace nie zanieczyszczały wskaźnika dostępności, który później musisz obronić.

Dowód zewnętrzny ma wagę właśnie dlatego, że jest zewnętrzny: dostawca może zlekceważyć Twoje własne logi serwera, ale zapis ze znacznikami czasu o awariach widzianych z kilku niezależnych sieci, z których żadna nie jest Twoja, trudniej podważyć.

Najszybszy sposób na zmniejszenie liczby zgłoszeń do supportu podczas incydentu to przestać zmuszać ludzi do pytania. Strona statusu zamienia monitory, które już uruchamiasz, w publiczne komponenty, aktualizuje je z tych samych potwierdzonych wyników, które uruchamiają Twoje alerty, i jest hostowana za Ciebie pod własnym adresem - bez dodatkowego hostingu i bez pracy z DNS. Incydenty i okna serwisowe są tam publikowane, a odwiedzający mogą się subskrybować.

Strony statusu są wliczone w każdy plan, także bezpłatny, podobnie jak publikowanie pod własną domeną. HostTracker prowadzi własną na tym samym mechanizmie - status.host-tracker.com jest działającym przykładem - a przegląd stron statusu opisuje resztę.

Każde twierdzenie na tej stronie można sprawdzić bez konta, bo bezpłatne narzędzia natychmiastowe działają na tej samej flocie co płatne monitory. Skieruj jedno na stronę, o której wiesz, że jest zdrowa, potem na taką, o której wiesz, że nie jest, i sam przeczytaj wyniki dla każdej lokalizacji.

• Bezpłatne sprawdzenie HTTP z wielu lokalizacji - kod statusu, czas odpowiedzi i nagłówki dla każdej lokalizacji.
• Uruchom globalny test ping - osiągalność, opóźnienie i utrata pakietów na poziomie sieci, gdzie problemy z routingiem pojawiają się najwcześniej.

Takich bezpłatnych narzędzi jest jedenaście, a każde to ręczna wersja typu monitora, który możesz później ustawić według harmonogramu.

Lokalizacje są pełnoprawnym parametrem, a nie ustawieniem ukrytym w formularzu. Wykonanie sprawdzenia z nazwanych regionów przez REST:

curl -X POST https://api2.host-tracker.com/check \
  -H "Authorization: Bearer $HT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com", "type": "http", "pools": ["westeurope", "asia"]}'

Identyfikatory z tabeli regionów trafiają do pools, a te same wartości działają przy tworzeniu monitora cyklicznego. Wokół tego interfejsu REST są oficjalne biblioteki dla TypeScript, Python, Go i .NET, klient wiersza poleceń ht, GitHub Action oraz serwer MCP, dzięki któremu asystent AI może tworzyć monitory i bezpośrednio czytać wyniki - wszystko wygenerowane z jednego dokumentu OpenAPI.

Trzy sposoby korzystania z sieci, a flota jest w nich taka sama - plan bezpłatny nie jest sprawdzany z mniejszej liczby miejsc niż płatne.

Okres próbny to uczciwy sposób oceny: 30 dni, sto monitorów, bez karty - dość, by uruchomić HostTracker obok tego, czego używasz dziś, i porównać alerty, które faktycznie wysłały oba. Pełne limity dla każdego planu: plany monitorowania stron internetowych HostTracker.

Tylko kolumny, które można zweryfikować na opublikowanej stronie. Na podstawie cenników i dokumentacji każdego dostawcy, sierpień 2026 - zweryfikuj wszystko, od czego zależy decyzja.

Tam, gdzie nie jesteśmy z przodu, tabela to mówi: plan bezpłatny UptimeRobot zawiera więcej monitorów niż nasz, a ich hostowany serwer MCP pojawił się z OAuth wcześniej niż nasz. Powody, by wybrać tę sieć, to pierwsze trzy wiersze.

Dane o sieci, protokole i planach na tej stronie ostatnio sprawdzono 30 sierpnia 2026. HostTracker prowadzi tę rozproszoną sieć monitorowania od 2004 roku.