W projektach, które utrzymujemy dla naszych klientów, zadania cykliczne (cron, kolejki, scheduler) odpowiadają za jedne z najbardziej krytycznych, a zarazem najmniej widocznych procesów w systemie. Ekran logowania czy formularz zamówienia od razu pokaże błąd - użytkownik go zobaczy i zgłosi. Zadanie cron, które przestało działać tydzień temu, nie zgłosi się samo. Dowiadujemy się o nim zwykle wtedy, gdy klient pyta, dlaczego raport z ostatnich siedmiu dni jest pusty.
Dlaczego zadania w tle zawodzą po cichu
Standardowy monitoring infrastruktury (CPU, pamięć, dostępność endpointu) w ogóle nie widzi tego problemu. Serwer działa, aplikacja odpowiada na żądania, a mimo to konkretne zadanie zaplanowane na godzinę 3:00 w nocy mogło:
- nie uruchomić się w ogóle, bo padł deployment albo zmienił się serwer,
- uruchomić się i zawiesić w nieskończonej pętli lub oczekiwaniu na zewnętrzne API,
- zakończyć się błędem, który trafił tylko do logów, których nikt nie czyta na bieżąco,
- wykonać się poprawnie, ale znacznie wolniej niż zwykle, sygnalizując narastający problem.
Konsekwencje bywają kosztowne: niewysłane maile transakcyjne, nieudane kopie zapasowe, rozjazd danych między systemami po nieudanej synchronizacji. W projektach e-commerce i systemach B2B, które integrują wiele źródeł danych, to właśnie zadania cykliczne najczęściej odpowiadają za spójność całej platformy - a jednocześnie najrzadziej mają realny nadzór.
Jak zaprojektować monitoring zadań cyklicznych
Dobry monitoring cron jobów nie polega na przeglądaniu logów raz dziennie. Polega na tym, że system sam informuje, gdy coś odbiega od harmonogramu. W praktyce sprowadza się to do kilku elementów, które wdrażamy jako standard w projektach z istotną warstwą zadań w tle:
1. Sygnał (heartbeat) na start i koniec zadania
Każde zadanie cykliczne powinno wysyłać potwierdzenie startu i zakończenia (wraz ze statusem: sukces, błąd, pominięcie). Brak takiego sygnału w oczekiwanym oknie czasowym jest sam w sobie informacją - często ważniejszą niż treść samego błędu.
2. Alert przy braku sygnału, nie tylko przy błędzie
Zadanie, które się w ogóle nie uruchomiło, nie wygeneruje żadnego wyjątku do złapania. Dlatego monitoring musi działać na zasadzie „oczekiwałem sygnału o określonej porze i go nie dostałem", a nie tylko „złapałem wyjątek".
3. Rozróżnienie stanów zadania
Start, sukces, błąd i pominięcie to inne sytuacje i powinny inaczej eskalować alert. Zadanie pominięte świadomie (np. bo nie było danych do przetworzenia) to co innego niż zadanie, które padło w trakcie wykonania.
W praktyce nie budujemy takiego mechanizmu od zera przy każdym projekcie. Zamiast tego sięgamy po gotowe narzędzia klasy heartbeat/monitoring, takie jak Cronitorex, które przyjmują ping po każdym uruchomieniu zadania i same alarmują, gdy oczekiwany sygnał się nie pojawi w zaplanowanym oknie czasowym. To oszczędza czas, który inaczej poszedłby na pisanie i utrzymywanie własnej warstwy alertowania - a przy dziesiątkach zadań cyklicznych w jednym systemie robi się to szybko nieopłacalne.
Kiedy wdrożyć monitoring zadań cyklicznych
Najlepszy moment to start projektu, nie moment po pierwszej awarii. W praktyce oznacza to dodanie pingów heartbeat do zadań cron już na etapie ich implementacji, a nie jako „dorobienie" po fakcie, kiedy trzeba przejrzeć dziesiątki istniejących zadań wstecz. Jeśli Twój system ma już za sobą kilka lat rozwoju i nikt nie potrafi dziś powiedzieć, które zadania cykliczne działają poprawnie, to zwykle pierwszy sygnał, że warto zrobić audyt tej warstwy.
Podsumowanie
Zadania w tle rzadko są priorytetem podczas projektowania systemu, a to właśnie one najczęściej odpowiadają za dane, na których opiera się codzienna praca klienta. Monitoring cron jobów wart jest wdrożenia od pierwszego dnia projektu - nie dlatego, że to modny temat, tylko dlatego, że koszt jego braku ujawnia się zawsze w najgorszym możliwym momencie.
Porozmawiajmy o Twoim projekcie