Monitoring crona w 60 sekund

Nie musisz zmieniać tego, co robi Twoje zadanie. Owijasz je dwoma pingami: jednym przy starcie, jednym na końcu. To cała integracja.

Krok 1: utwórz monitor

W panelu Cronitorex utwórz monitor typu ping i nadaj mu nazwę, na przykład nightly-backup. Ustaw oczekiwany interwał na to, jak często zadanie powinno się wykonywać (co 5 minut, co godzinę, raz dziennie) oraz okres tolerancji na wypadek, gdy czas wykonania trochę się waha. To jedyny krok, który wykonujesz w panelu; reszta zostaje w Twoim crontabie.

Krok 2: owiń polecenie

Oto typowa linia crontaba dla nocnego backupu bazy danych, owinięta trzema pingami: jednym dla run, jednym dla complete przy sukcesie, jednym dla fail przy niezerowym kodzie wyjścia.

# /etc/cron.d/nightly-backup
0 2 * * * root curl -fsS "https://api.cronitorex.com/ping/nightly-backup?status=run"; \
  pg_dump mojabaza | gzip > /backups/db-$(date +\%F).sql.gz \
  && curl -fsS "https://api.cronitorex.com/ping/nightly-backup?status=complete" \
  || curl -fsS "https://api.cronitorex.com/ping/nightly-backup?status=fail&exit_code=$?"

Średnik po pingu run jest celowy: jeśli API Cronitorex jest chwilowo niedostępne, Twój backup i tak się wykona. Monitoring nigdy nie powinien być powodem, dla którego zadanie się nie uruchomi.

Jeśli nie chcesz pisać wrappera ręcznie, klient cronitorex.sh zrobi to za Ciebie:

cronitorex run nightly-backup -- pg_dump mojabaza | gzip > /backups/db-$(date +%F).sql.gz

Wysyła ping run, uruchamia polecenie, automatycznie przechwytuje kod wyjścia i stderr, a na końcu sam wysyła complete albo fail.

Krok 3: niech pominięte uruchomienie alarmuje samo

Tego zwykły curl na końcu skryptu nie załatwi: jeśli zadanie w ogóle nie wystartuje (źle skonfigurowany crontab, serwer się zrestartował i demon cron nie wrócił, deploy po cichu usunął wpis), żaden ping nigdy nie dotrze, w żadną stronę. Cronitorex mierzy odstęp od ostatniego udanego complete względem oczekiwanego interwału i okresu tolerancji, i zgłasza alert missed, gdy to okno się zamknie bez sygnału. Tej logiki nie musisz pisać sam.

Krok 4: wybierz, gdzie ma trafić alert

Skonfiguruj co najmniej jeden kanał powiadomień, zanim zaczniesz na tym polegać produkcyjnie. Email sprawdza się w projekcie jednoosobowym; wspólny kanał na Telegramie albo Discordzie lepiej sprawdza się w zespole, bo wszyscy widzą ten sam alert w tym samym momencie zamiast przeszukiwać skrzynkę. Wszystkie te kanały są dostępne w każdym planie, także Free.

Co z tego wynika

Wpis w dashboardzie pokazujący ostatnie 30 uruchomień na pierwszy rzut oka, kod wyjścia i stderr przechwycone przy awarii, więc nie musisz logować się po SSH, żeby odtworzyć, co się stało, oraz alert, który dociera do Ciebie w ciągu około minuty od awarii albo od uruchomienia, które powinno się zdarzyć, a się nie zdarzyło. Ta ostatnia sytuacja, pominięte uruchomienie, to właśnie ta, którą większość domowych rozwiązań do monitoringu pomija całkowicie, bo wymaga pilnowania braku czegoś, a nie obecności błędu.