Monitoring cronów (heartbeat)

Problem z zaplanowanymi zadaniami

Okrutną cechą cronów jest to, że gdy padają, nic Ci tego nie powie. Aplikacja webowa nadal serwuje requesty, strona główna wygląda OK, monitoring świeci na zielono - ale gdzieś na serwerze nocny backup nie odpalił od dwóch tygodni. Queue worker padł po deploy'u i zaległe joby się piętrzą. Synchronizacja co godzinę po cichu gubi wiersze przez problem uprawnień. Dowiadujesz się dopiero, gdy coś downstream w końcu padnie - zwykle właśnie wtedy, gdy tej rzeczy najbardziej potrzebujesz. Data team chce export, support kolejkę maili, ops backup. Wtedy jest już za późno.

Standardowy monitoring uptime tego nie złapie, bo nie ma czego pingować. Cron nie wystawia endpointu HTTP, nie otwiera portu, nie uruchamia serwera. Odpala się, kończy, kończy. Jeśli przestanie działać - nie ma żadnego sygnału jego nieobecności, dopóki nie zaczniesz szukać.

Wzorzec odwrotny: monitoring heartbeat

Monitoring heartbeat (zwany też "dead man's switch" lub "monitoring cronów") odwraca kierunek. Zamiast my sprawdzać Twoją usługę, Twoja usługa melduje się u nas. Dodajesz jedną linię do crona - curl do unikalnego URL-a, który generujemy - a ten URL zapisuje znacznik czasu przy każdym uderzeniu. My pilnujemy nieobecności tych pingów. Jeśli URL nie zostanie trafiony w oczekiwanym interwale (plus margines), traktujemy to jako pominięty bieg i wysyłamy alert.

Model jest prosty, niezawodny i niezależny od języka. Wszystko co potrafi zrobić HTTP request - integruje się. Bash przez curl, Python przez requests, Node przez fetch, PHP przez curl_init, Task Scheduler na Windowsie przez Invoke-WebRequest, GitHub Actions, Kubernetes CronJobs, Lambda scheduled events - cokolwiek. Bez SDK, bez agenta, bez daemona do zainstalowania.

Jak skonfigurować

W DiagnoSEO Uptime Monitoring kliknij "Dodaj monitor", wybierz typ "Heartbeat / cron". Narzędzie generuje unikalny URL z tokenem - coś w stylu https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9. Ustaw oczekiwany interwał (jak często ma działać job, w minutach) i margines (o ile spóźnione bieg jest OK, zanim spanikujemy). Zapisz.

Teraz zmodyfikuj crona, aby pingował URL po każdym udanym biegu. Trzy style w zależności od środowiska:

# Bash cron - ping tylko po sukcesie
0 3 * * * /usr/bin/backup.sh && curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Lub gdy częściowy sukces jest OK
0 3 * * * /usr/bin/backup.sh; curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Python
import requests
def main():
    do_the_work()
    requests.get('https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9', timeout=5)

# GitHub Actions
- name: Notify heartbeat
  if: success()
  run: curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9

Od tego momentu każdy udany bieg pinguje nas, a my zapisujemy timestamp. Jeśli nie zobaczymy pinga w ciągu interwał + margines minut, otwierany jest incydent i lecą powiadomienia na wszystkie włączone kanały: Email, Telegram, Slack, Discord, SMS.

Wybór interwału i marginesu

Interwał powinien dokładnie pasować do harmonogramu jobu. Nocny backup o 3:00 - interwał 1440 minut (24h). Synchronizacja co godzinę - 60. Worker pollujący co 5 min - 5.

Margines pochłania naturalny jitter. Crony nie odpalają się dosłownie co do nanosekundy - są kolejkowane, czekają na zakończenie poprzedniego biegu, robią back-off przy chwilowych błędach. 24-godzinny job z marginesem 1h daje wygodny bufor bez opóźniania alertów. 5-minutowy worker pollujący z 2-minutowym marginesem łapie prawdziwe śmierci szybko, bez false positive'ów od 30-sekundowego mignięcia. Z grubsza: ustaw margines na 10-50% interwału w zależności od tego, jak job lubi się "miotać".

Wzorce, które polecamy

• Ping tylko po sukcesie. Używaj && w bash - bieg który padł nie pinguje. My wykryjemy brak pinga i zaalarmujemy.
• Ping po każdej iteracji pętli. Dla długo działających workerów pinguj wewnątrz pętli po każdej udanej jednostce pracy, nie na końcu. Dzięki temu zawieszony worker jest wykrywany w trakcie biegu.
• Jeden heartbeat na logiczny job, nie na skrypt. Jeśli trzy skrypty razem to jeden nocny pipeline, pinguj raz na końcu łańcucha. Daje to czysty sygnał "czy pipeline żyje".
• Łącz z logami. Heartbeat mówi że job się odpalił. Logi aplikacji mówią co zrobił. Razem to pełen obraz.

Co się dzieje gdy heartbeat zniknie

Incydent jest otwierany w momencie minięcia deadline'u. Dashboard pokazuje monitor na czerwono z błędem "Brak heartbeat od X minut". Powiadomienia lecą na wszystkie kanały, które masz włączone. Gdy świeży heartbeat dotrze, monitor automatycznie wraca do up - jest oznaczony jako up, incydent zamyka się, a (jeśli masz alerty recovery włączone) dostajesz powiadomienie "back online".

Wszystko to ma takie samo traktowanie jak inne monitory - heatmapa, procent uptime, historia, tagi, wyszukiwanie, eksport. Z perspektywy dashboardu monitor heartbeat to po prostu kolejny wiersz, sortowalny i filtrowalny obok HTTP, ping, port i API.

Lista kontrolna

Dodaj monitor → typ Heartbeat → skopiuj wygenerowany URL → dodaj do cron / worker / schedulera → ustaw interwał i margines → zapisz → gotowe. Teraz dowiesz się w sekundzie, gdy zaplanowane zadanie przestanie działać - co długoterminowo jest jedną z najbardziej kluczowych decyzji dotyczących monitoringu, jakie możesz podjąć.

Najczęściej zadawane pytania

• Czym jest monitoring heartbeat / cron-job?

  Odwrócony monitoring — Twoje zaplanowane zadanie pinguje nasz URL gdy uruchamia się pomyślnie. Jeśli nie usłyszymy od niego w oczekiwanym oknie, alertujemy. Rozwiązuje problem cichych awarii: popsuty cron job nie produkuje błędu i nie wyzwala tradycyjnego alertu uptime.

• Jak zintegrować URL heartbeat z moim cronem?

  Dodaj curl -fsS <heartbeat_url> na końcu komendy crona. Jeśli komenda przed nim zawiedzie, curl się nie wykona i heartbeat zostanie pominięty. Alternatywnie pinguj na początku I końcu różnymi ścieżkami — daje to osobno sygnały "started" i "completed".

• Jaki grace period powinienem ustawić?

  Około 2-3x typowego czasu wykonania zadania. Jeśli Twój dzienny backup zajmuje 30 minut, ustaw grace na 90 minut — uwzględnia spowolnienia bez false alertów. Dla zadań ze zmiennym czasem wykonania ustaw hojnie i użyj dashboarda do identyfikacji outlierów.

• Czy mogę monitorować cron joby uruchamiane co godzinę?

  Tak — ustaw interwał na odpowiadający (np. 60 minut oczekiwane z 15-minutowym grace). Monitor oczekuje pinga co najmniej co 75 minut. Jeśli Twoje zadanie jest częstsze (co 5 minut), URL heartbeat to też obsługuje — po prostu dopasuj ustawienie interwału.

• Czy heartbeat monitoring działa dla AWS Lambda / serverless?

  Tak. Dodaj wychodzące wywołanie HTTP do URL heartbeat na końcu funkcji Lambda. Monitor traktuje to identycznie jak cron heartbeat — to samo alertowanie, ten sam grace period. Przydatne dla zaplanowanych Lambd gdzie alarmy CloudWatch nie łapią cichych awarii wykonania.