Kontrola dostępności działa na zasadzie „pull”: usługa monitorująca regularnie wysyła żądanie do Twojej strony lub API i powiadamia Cię, gdy odpowiedź jest błędna albo jej brak. Heartbeat działa na zasadzie „push”: Twoje zadanie lub usługa przy każdym uruchomieniu wysyła żądanie do usługi monitorującej, a alert przychodzi, gdy to żądanie nie dotrze. Kontroli dostępności używaj do wszystkiego, z czym ludzie łączą się przez sieć, a heartbeatów do pracy wykonywanej według harmonogramu albo bez publicznego adresu. Większość konfiguracji potrzebuje obu.
Łatwo je pomylić, bo oba sprowadzają się do „alertu, gdy coś jest nie tak”. Widzą jednak inne awarie, a użycie jednego tam, gdzie potrzebne jest drugie, zostawia martwy punkt, który ujawnia się dopiero wtedy, gdy coś się zepsuje.
Jak działa kontrola dostępności
Klientem jest usługa monitorująca. Co minutę albo w dowolnie wybranym odstępie pobiera adres URL, pinguje hosta lub otwiera port i ocenia odpowiedź: kod statusu, czas odpowiedzi, słowo kluczowe na stronie, certyfikat. Jeśli kontrola się nie powiedzie, a druga kontrola to potwierdzi, dostajesz alert. To odmiana monitorowania syntetycznego: robot robi to, co zrobiłby odwiedzający.
Wykrywa: stronę lub API, które nie działa, działa wolno, zwraca błędy, pokazuje złą treść albo przestało działać przez wygasły certyfikat lub zmianę DNS. Wszystko, na co trafiłby odwiedzający.
Nie widzi: niczego, co nie odpowiada na żądania. Kopii zapasowej, która się nie wykonała, zawieszonego workera kolejki, importu, który padł o 02:00. Strona dalej działa, więc każda kontrola przechodzi.
Jak działa heartbeat
Klientem jest Twoje zadanie. Informujesz usługę monitorującą, kiedy zadanie ma się uruchamiać, a zadanie po zakończeniu wywołuje unikalny adres ping. Jeśli ping spóźni się o więcej niż wybrany okres karencji, dostajesz alert. Idea to tzw. dead man’s switch: sygnałem jest cisza. Dlatego monitorowanie heartbeat nazywa się też monitorowaniem typu push albo dead man’s switch.
0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 –retry 3 -o /dev/null https://app.uptimecheck.com/api/hb/your-token
Wykrywa: zadania, które się nie uruchomiły, padły przed końcem, wykonały się według złego harmonogramu albo, przy pingu startowym, trwały o wiele za długo. Gdy ping zawiera kod wyjścia, wykrywa też zadania, które się wykonały, ale zakończyły błędem.
Nie widzi: czy ktokolwiek może połączyć się z Twoją usługą. Zadanie na serwerze może spokojnie wysyłać pingi, podczas gdy strona na tym samym serwerze odpowiada każdemu odwiedzającemu błędem 502.
Porównanie
Kontrola dostępnościHeartbeatKto wysyła żądanieUsługa monitorującaTwoje zadanie lub usługaAlert, gdyOdpowiedź jest błędna, wolna lub jej brakPing się spóźnia albo zgłasza błądWymaga publicznego adresuTakNie, wystarczy wychodzący HTTPSKonfiguracjaAdres URL, host lub portHarmonogram, okres karencji i jedno żądanie w zadaniuWidziTo, czego doświadczają odwiedzający i klienci APICzy praca w tle się wykonała i jak się zakończyłaNie widziPracy, która nie odpowiada na żądaniaCzy ktokolwiek może połączyć się z usługą
Kiedy używać kontroli dostępności
Strona główna i strony, które zarabiają: koszyk i płatność, rejestracja, logowanie.
Publiczne API i odbiorniki webhooków, z kontrolą kodu statusu i zwracanego JSON-a.
Endpoint health check, który przy każdym żądaniu sprawdza bazę danych i inne zależności.
Usługi na innych portach, np. serwer pocztowy, z kontrolą portu.
Prosta zasada: jeśli wywołuje to człowiek albo inny system, sprawdzaj to z zewnątrz, tak jak oni.
Kiedy używać heartbeatu
Zadania cron: kopie zapasowe baz danych i plików, nocne importy i eksporty, generowanie raportów, rozliczenia.
Zadania harmonogramowane w innej postaci: zadanie w Harmonogramie zadań Windows, Kubernetes CronJob, workflow GitHub Actions uruchamiany według harmonogramu, funkcja serverless wywoływana timerem.
Skrypty odnawiania certyfikatów i synchronizacje danych między systemami.
Wszystko za zaporą lub NAT-em, do czego nie da się dotrzeć z zewnątrz, ale co może wysłać wychodzące żądanie HTTPS.
Długo działające workery
Worker kolejki czy demon nie działa według harmonogramu, ale też może wysyłać heartbeat. Wysyłaj ping z pętli głównej co kilka minut i ustaw w monitorze interwał zamiast wyrażenia cron. Jeśli pętla się zawiesi, proces zostanie zabity albo serwer zrestartuje się bez jego ponownego uruchomienia, pingi ustaną, a Ty się o tym dowiesz. Wysyłaj ping z pętli, która wykonuje pracę, a nie z osobnego wątku, bo inaczej zawieszony worker dalej będzie zgłaszał, że wszystko w porządku.
Kiedy potrzebujesz obu
Większość prawdziwych usług ma frontowe drzwi i zaplecze. Monitoruj każde z nich narzędziem, które je widzi:
Sklep internetowy: kontrole dostępności strony głównej i koszyka oraz heartbeaty dla nocnego eksportu zamówień i kopii zapasowej bazy danych.
Produkt SaaS: kontrola dostępności endpointu health API oraz heartbeaty dla workera kolejki i zadania wysyłającego faktury.
Usługa wewnętrzna: brak publicznego adresu, więc heartbeat z samej usługi plus kontrole dostępności publicznych stron, które zależą od jej danych.
Alternatywą jest udostępnienie statusu zadań przez endpoint health, np. tak, by kontrola nie przechodziła, gdy ostatnia kopia zapasowa jest starsza niż 25 godzin. To działa, ale wiąże dostępność strony z kopiami zapasowymi, więc spóźniony backup pojawia się w raportach jako niedostępność strony. Osobny heartbeat trzyma oba sygnały, a także osoby, które dostają każdy z alertów, osobno.
Jak dobrać czasy
Interwał kontroli dostępności: co minutę dla stron, które zarabiają, bo interwał to najdłuższy czas, przez jaki możesz nie wiedzieć o awarii. Mniej krytyczne strony mogą mieć dłuższy interwał.
Okres karencji heartbeatu: dłuższy niż normalne wahania czasu zakończenia zadania. Kopia zapasowa, która startuje o 03:00, trwa od 5 do 20 minut i wysyła ping na końcu, potrzebuje co najmniej 20 minut karencji; 30 daje zapas na wolniejszą noc.
Maksymalny czas wykonania: przy pingu startowym alert przychodzi, gdy przebieg trwa znacznie dłużej niż zwykle. Zawieszone zadanie też nigdy nie wyśle pingu końcowego, ale ten alert przychodzi, gdy tylko minie limit.
Strefa czasowa: harmonogram cron działa w strefie czasowej serwera, często UTC. Ustaw w monitorze tę samą, bo inaczej przez zmianę czasu dwa razy w roku będzie oczekiwał zadania godzinę za wcześnie lub za późno. Narzędzie do wyrażeń cron pokazuje, kiedy harmonogram faktycznie się uruchamia.
Częste błędy
Ping tylko na starcie. Zadanie, które wystartuje i padnie, i tak się zgłosi. Wysyłaj ping na końcu albo oba.
Ping nawet przy błędzie zadania. backup.sh; curl … wysyła ping bez względu na wynik. Użyj && albo wysyłaj kod wyjścia, by błąd został zgłoszony jako błąd.
Ping, który może zawiesić zadanie. Ustaw w curl limit czasu i ponowienia (-m 10 –retry 3), żeby wolna sieć ani nie blokowała zadania, ani nie gubiła pingu.
Heartbeat dla publicznej strony. Serwer, który wysyła pingi na zewnątrz, dowodzi tylko, że ma dostęp do internetu, a nie że odwiedzający mają dostęp do niego.
Monitorowanie demona cron zamiast zadania. Demon może działać bez zarzutu, podczas gdy jedno zadanie co noc kończy się błędem. Każde ważne zadanie dostaje własny heartbeat.
Więcej o heartbeatach w poradnikach jak monitorować zadania cron i jak zapobiegać pominiętym zadaniom cron.
Oba w jednym miejscu z Uptimecheck
Uptimecheck obsługuje oba rodzaje monitorów na jednym koncie, z tymi samymi kanałami alertów i tą samą historią incydentów.
Monitorowanie dostępności: kontrole HTTP(S), ping i portów nawet co minutę ze Sztokholmu, Londynu i Nowego Jorku, a każda awaria jest potwierdzana z drugiej lokalizacji przed wysłaniem alertu. Kontrole HTTP mogą sprawdzać kod statusu, słowo kluczowe, pola JSON i nagłówki.
Monitorowanie zadań cron: wyrażenie crontab w Twojej strefie czasowej, z uwzględnieniem zmiany czasu, albo prosty interwał; okres karencji od 1 minuty do 6 godzin; pingi /start z maksymalnym czasem wykonania od 1 minuty do 24 godzin; /fail lub kod wyjścia, by zgłosić, jak zakończył się przebieg; a wynik zadania, wysłany razem z pingiem, widać w alercie.
Limity: Start obejmuje 15 monitorów dostępności i 10 zadań cron, Professional 100 i 50, Business 250 i 150. Zobacz cennik.
Jak to skonfigurować, opisujemy w artykułach jak monitorować zadanie cron za pomocą heartbeatu i przykłady pingów zadań cron dla Laravel, Kubernetes, GitHub Actions, systemd i Windows. Dyski i pamięć serwera pod spodem obejmiesz monitorowaniem serwerów.
Pilnuj frontowych drzwi i zaplecza. Wypróbuj Uptimecheck za darmo przez 14 dni, bez karty kredytowej.