Monitoring cron jobów i workerów w tle przez heartbeat

W skrócie: Klasyczny monitoring HTTP nie wykryje, że padł twój nocny cron wysyłający faktury lub synchronizujący dane. Wzorzec heartbeat odwraca kierunek komunikacji - cron melduje się monitoringowi, a jeśli w oczekiwanym czasie nie zadzwoni, dostajesz alert.

Problem: zadania w tle bez endpointu HTTP

Typowy backend ma ścieżki:

• Żądania webowe (HTTP/HTTPS do serwera) - monitorujesz przez uptime check.
• Cron joby (codzienny backup, miesięczna fakturacja, godzinna synchronizacja) - nie mają endpointu HTTP, monitoring zewnętrzny ich nie widzi.
• Workery (Celery, BullMQ, Sidekiq) konsumujące kolejkę - też bez HTTP.

Jeśli cron padnie (zmienisz crontab i zrobisz literówkę, serwer nie ma dysku, brakuje environment variable, upgrade dependency złamał import), nikt cię nie ostrzeże - dopóki w poniedziałek rano nie zauważysz, że faktury się nie wysłały przez weekend.

Wzorzec heartbeat: cron pinguje monitoring

Zasada jest odwrotna w stosunku do normalnego monitoringu:

1. W usłudze monitoringu tworzysz monitor heartbeat z oczekiwanym interwałem (np. "co 60 minut").
2. Dostajesz unikalny URL heartbeat: https://epulz.io/heartbeat/abc123xyz.
3. W swoim cron jobie na końcu udanego biegu wywołujesz ten URL (HTTP GET lub POST).
4. Jeśli ping nie przyjdzie w oczekiwanym czasie (+ okres grace), monitoring cię ostrzeże.

Praktyczny przykład: bash cron

# /etc/crontab
0 3 * * * www-data /usr/local/bin/backup.sh && curl -fsS -m 10 \
  https://epulz.io/heartbeat/abc123xyz > /dev/null

Kluczowe jest && - heartbeat się wysyła tylko jeśli backup.sh kończy z kodem 0. Jeśli skrypt zawiedzie, ping nie przyjdzie, a ty w ciągu godziny dostaniesz alert.

Wskazówka: Dla dokładniejszego pokrycia dodaj również "start" heartbeat:

curl -fsS -m 10 https://epulz.io/heartbeat/abc123xyz/start > /dev/null
/usr/local/bin/backup.sh
EXIT=$?
curl -fsS -m 10 "https://epulz.io/heartbeat/abc123xyz?exit=$EXIT" > /dev/null

Monitoring następnie rozróżnia "zaczął i nie dokończył" (skrypt zamarł) od "w ogóle nie zaczął" (cron job się nie uruchomił).

Python: requests + try/except

import os, requests
HEARTBEAT_URL = os.environ["HEARTBEAT_URL"]

def sync_data():
    # twoja logika
    pass

try:
    sync_data()
    requests.get(HEARTBEAT_URL, timeout=10)
except Exception as e:
    # Heartbeat się nie wysyła - monitoring cię ostrzeże
    raise

Node.js: async / await

const HEARTBEAT_URL = process.env.HEARTBEAT_URL;

async function nightlyJob() {
  await processInvoices();
  await fetch(HEARTBEAT_URL, { signal: AbortSignal.timeout(10000) });
}

nightlyJob().catch(err => {
  console.error(err);
  process.exit(1);
});

Grace period: ile czasu dać przed alertem

Monitor heartbeat potrzebuje tolerancji - cron czasami biegnie dłużej niż zwykle, sieć ma latencję, synchronizacja NTP może być lekko przesunięta. Grace period to czas po oczekiwanym interwale, w którym monitoring jeszcze czeka.

Wartości praktyczne:

• Hourly cron: interwał 60 min + grace 10 min
• Daily backup (średnio 20 min): interwał 1440 min + grace 60 min
• Weekly report: interwał 10080 min + grace 360 min (6 h)

Zbyt ciasny grace = alerty false-positive. Zbyt luźny = opóźnione ostrzeżenie, gdy naprawdę padnie.

Gdzie wzorzec heartbeat najbardziej pomaga

• Nocne backupy DB
• Synchronizacja z zewnętrznymi API (CRM, accounting, payment)
• Kalkulacja raportów
• Zadania cleanup (kasowanie starych sesji, logów, plików tymczasowych)
• Cykl healthcheck długo działających workerów
• Planowane emaile, newslettery, fakturacja

Wnioski

Zadania w tle są często bardziej krytyczne niż sama strona, ale pozostają ślepą plamą monitoringu. Wzorzec heartbeat wymaga 5 minut implementacji (dodanie curl na końcu linii cron) i daje ten sam spokój co monitoring uptime dla frontendu.

Zacznij monitorować cron joby

ePulz.io obsługuje checki heartbeat z konfigurowalnym grace period. 7 dni za darmo.

Uruchom monitoring →