Jak monitorować zadania cron: 5 wzorców z heartbeatem

Cron jest doskonały w uruchamianiu rzeczy według harmonogramu i katastrofalny w tym, by powiedzieć ci, gdy tego nie zrobi. Kopia zapasowa, która przestaje działać, rzadko wyrzuca błąd, który zobaczysz. Po prostu po cichu nic nie robi, a dowiadujesz się o tym tygodnie później, gdy kopia jest potrzebna, a jej nie ma. To problem cichej awarii i właśnie dlatego każde zaplanowane zadanie, na którym zależy, potrzebuje kontroli heartbeat.

Heartbeat (albo "dead man's switch") odwraca logikę do góry nogami. Zamiast alertu, gdy coś jest nie tak, twoje zadanie pinguje endpoint monitorujący, gdy wszystko jest w porządku. Jeśli oczekiwany ping nie nadejdzie na czas, monitor alarmuje. Brak pingu, brak wiadomości, duży problem.

Poniżej pięć wzorców, od najprostszego do najbardziej odpornego. Wszystkie zakładają, że masz URL heartbeat z narzędzia monitorującego.

Wzorzec 1: Klasyczny dead man's switch

Najprostsza możliwa konfiguracja. Twoje zadanie po zakończeniu wywołuje URL. Jeśli monitor nie otrzyma wiadomości w oczekiwanym oknie, alarmuje.

# Codzienna kopia o 02:30, ping po zakończeniu
30 2 * * * /usr/local/bin/backup.sh && curl -fsS https://twoj-monitor/ping/abc123

&& ma znaczenie: curl uruchomi się tylko wtedy, gdy backup.sh zakończy się kodem 0 (sukces). Jeśli kopia zawiedzie, żaden ping nie zostanie wysłany, a monitor to wychwyci. Przełączniki -fsS sprawiają, że curl przy błędach HTTP zawodzi po cichu, lecz realne problemy nadal pokazuje.

Słabość: potwierdza tylko, że skrypt działał i zakończył się zerem. Jeśli skrypt połknie własne błędy i mimo to zakończy się zerem, dostaniesz fałszywe "wszystko w porządku".

Wzorzec 2: Ping tylko przy prawdziwym sukcesie

Uczyń sygnał sukcesu jawnym, zamiast polegać na łączeniu kodów wyjścia w powłoce. W skryptach wielokrokowych jest to jaśniejsze.

#!/bin/bash
set -euo pipefail   # przy jakimkolwiek błędzie padnij głośno
run_the_backup
verify_the_backup    # naprawdę zweryfikuj, że wynik istnieje i ma sens
curl -fsS https://twoj-monitor/ping/abc123   # osiągnięte tylko, jeśli wszystko powyżej przeszło

set -euo pipefail oznacza, że jakakolwiek nieudana komenda przerwie skrypt jeszcze przed pingiem. Dodanie realnego kroku weryfikacji (plik kopii istnieje, jest większy niż zero bajtów) zamyka dziurę "zakończył się zerem, ale nic nie zrobił" z Wzorca 1.

Wzorzec 3: Opakowanie kodu wyjścia

Gdy nie możesz zmodyfikować samego zadania (binarka firmy trzeciej, skrypt dostawcy), opakuj je. Opakowanie sygnalizuje start, uruchamia zadanie i raportuje kod wyjścia.

#!/bin/bash
URL=https://twoj-monitor/ping/abc123
curl -fsS "$URL/start"                  # sygnał "uruchomiłem się"
/opt/vendor/report-generator            # zadanie, którego nie kontrolujesz
EXIT=$?
curl -fsS "$URL/$EXIT"                   # zgłoś kod wyjścia

Sygnalizowanie startu pozwala monitorowi także mierzyć długość działania i wykryć zadanie, które się uruchomiło, lecz nigdy nie zakończyło (zawiesiło się). Zgłoszenie kodu wyjścia pozwala mu odróżnić "przebiegło w porządku" od "przebiegło i zawiodło".

Wzorzec 4: Ping warunkowy (pinguj tylko, gdy praca miała sens)

Niektóre zadania działają według harmonogramu, ale rzeczywistą pracę wykonują tylko czasami (procesor kolejki, który często znajduje kolejkę pustą). Nie chcesz alertu o "brakującym heartbeacie", gdy zadanie zgodnie z regułami nic nie zrobiło. Pinguj tylko wtedy, gdy rzeczywista praca się wydarzyła, i odpowiednio rozszerz harmonogram.

#!/bin/bash
PROCESSED=$(process_queue)
if [ "$PROCESSED" -gt 0 ]; then
  curl -fsS "https://twoj-monitor/ping/abc123?count=$PROCESSED"
fi

Oczekiwany okres monitora ustaw na najdłuższą realną przerwę między rzeczywistymi uruchomieniami. Ceną jest czułość: dłuższe okno oznacza wolniejszą detekcję, więc używaj tego tylko wtedy, gdy nieregularna praca jest naprawdę oczekiwana.

Wzorzec 5: Jitter i okna grace

Realne harmonogramy dryfują. Zadanie ustawione na 02:00 może uruchomić się o 02:00:04 z powodu obciążenia, a długość działania codziennego zadania się waha. Jeśli monitor oczekuje pingu dokładnie w interwale, normalny jitter niepotrzebnie cię wyrwie ze snu.

Rozwiązaniem jest okres grace: powiedz monitorowi, by po oczekiwanym czasie poczekał jeszcze pewien zapas, zanim zaalarmuje. Codzienna kopia, która zwykle trwa 8 minut, może użyć 20-minutowego okna grace. Chcesz też pewnego jittera w samym harmonogramowaniu, gdy masz wiele zadań, by nie obciążały tego samego zasobu w tej samej sekundzie:

# Dodaj małe losowe opóźnienie (0-59s), by rozłożyć zadania o 02:00
0 2 * * * sleep $((RANDOM % 60)) && /usr/local/bin/backup.sh && curl -fsS https://twoj-monitor/ping/abc123

Okna grace to różnica między monitorem, któremu ufasz, a takim, który po trzecim fałszywym alarmie wyciszysz. Grace ustaw tak, by wygodnie przekraczało najgorszy realny czas działania zadania, nie jego średnią.

Szybki przegląd

Jak wdrożyć to w praktyce

Zacznij od Wzorca 1 na najważniejszym zadaniu jeszcze dziś (kopia zapasowa, przebieg fakturowania, synchronizacja danych). Dodaj weryfikację (Wzorzec 2) i okno grace (Wzorzec 5), zanim zaczniesz na nim polegać. Bardziej szczegółowy przewodnik po konfiguracji heartbeatu znajdziesz w naszym poradniku monitorowanie zadań cron przez heartbeat.

Jeśli twoje zadanie komunikuje się z usługą przez konkretny port, osiągalność sprawdzisz najpierw bezpłatnym kontrolerem portów. A gdy będziesz gotowy monitorować zaplanowane zadania razem ze stronami i API w jednym miejscu, zobacz jak działa monitoring dostępności ePulz.io - 7-dniowy okres próbny jest za darmo, bez karty.