Alerty o błędach zadań cron: telefon, gdy zaplanowane zadanie padnie

Spis treści

• Wzorzec 1: alert przy błędzie na podstawie kodu wyjścia
• Wzorzec 2: czuwak (dead man's switch) na pominięte uruchomienia
• Wzorzec 3: kontrole w oknie czasowym dla zadań raportujących dane
• Jak sprawić, by alertu nie dało się przeoczyć
• Który wzorzec wybrać?

Najgroźniejsze w nieudanym zadaniu cron jest to, że nic się nie dzieje. Żadnej strony błędu, żadnej awarii, żadnych wściekłych użytkowników — tylko kopia zapasowa, która po cichu przestała powstawać trzy tygodnie temu, raport, który nigdy nie został wysłany, albo skrypt czyszczący, który pozwolił zapełnić dysk, aż produkcja się położyła.

Sam cron nie ma wbudowanego alertowania. Jeśli zadanie zakończy się błędem, cron rozłoży ręce. Jeśli o zaplanowanej godzinie cały serwer jest wyłączony, zadanie po prostu się nie uruchomi i nie zostawi po sobie żadnego śladu, który by o tym powiedział. To właśnie ten drugi przypadek umyka większości konfiguracji monitoringu.

Ten przewodnik opisuje trzy wzorce wychwytujące oba rodzaje awarii oraz sposób, by alertu nie dało się przeoczyć — dzięki eskalacji do prawdziwego połączenia telefonicznego z Echobell.

Wzorzec 1: alert przy błędzie na podstawie kodu wyjścia

Najprostsze podejście: wywołaj webhook zawsze, gdy zadanie zakończy się kodem innym niż zero.

Najpierw utwórz kanał w Echobell i skopiuj adres URL jego webhooka. Następnie opakuj polecenie cron:

0 3 * * * /opt/scripts/backup.sh || curl -s "https://hook.echobell.one/t/<channel-token>?title=Backup+failed&host=$(hostname)"

Jeśli backup.sh zadziała poprawnie, nic się nie stanie. Jeśli zawiedzie, Echobell w kilka sekund dostarczy alert na Twój telefon. Parametry zapytania stają się zmiennymi szablonu, więc powiadomienie może dokładnie wskazać, który host i które zadanie zawiodło.

Przy dłuższych skryptach pułapka trap da Ci bogatszy kontekst:

#!/usr/bin/env bash
set -euo pipefail

notify_failure() {
  curl -s -X POST "https://hook.echobell.one/t/<channel-token>" \
    -H "Content-Type: application/json" \
    -d "{\"job\":\"nightly-backup\",\"host\":\"$(hostname)\",\"line\":\"$1\"}"
}
trap 'notify_failure $LINENO' ERR

# ... logika Twojego zadania ...

Ograniczenie: to działa tylko wtedy, gdy skrypt faktycznie się uruchomi i zawiedzie. Jeśli serwer jest wyłączony, cron jest źle skonfigurowany albo ktoś zakomentował daną linię podczas debugowania, żaden alert nie poleci. Właśnie dlatego przyda się też wzorzec 2.

Wzorzec 2: czuwak (dead man's switch) na pominięte uruchomienia

Czuwak odwraca logikę: zadanie pinguje monitor po sukcesie, a monitor alarmuje, gdy ping nie dotrze o czasie. To wychwytuje każdy rodzaj awarii — błędy, zawieszenia, martwe serwery i usunięte wpisy w crontabie.

Dwa popularne rozwiązania do samodzielnego hostowania dobrze współpracują z Echobell:

• Healthchecks.io powstał dokładnie do tego. Utwórz kontrolę z harmonogramem swojego crona i okresem karencji, a następnie dopisz && curl -s https://hc-ping.com/YOUR_UUID na końcu linii w crontabie. Gdy ping się spóźni, Healthchecks wyśle webhook — skieruj go na swój kanał Echobell, aby pominięta kopia zapasowa zamieniła się w dzwoniący telefon.
• Uptime Kuma ma monitor typu „Push", który działa tak samo: Twoje zadanie wywołuje adres push, a Uptime Kuma alarmuje przez swoje integracje powiadomień, gdy sygnał życia przestaje przychodzić.

W obu przypadkach przepływ wygląda tak: zadanie cron → ping o sukcesie → monitor zauważa ciszę → webhook do Echobell → powiadomienie push lub połączenie telefoniczne.

Wzorzec 3: kontrole w oknie czasowym dla zadań raportujących dane

Niektóre zadania lepiej weryfikować po ich wynikach niż po kodzie wyjścia. Jeśli nocny proces ETL powinien wstawić rekordy do godziny 4 rano, niewielkie zadanie weryfikujące może sprawdzić liczbę wierszy i wywołać webhook Echobell, gdy liczby wyglądają podejrzanie.

Pomagają tu warunki w Echobell: możesz wysyłać webhook ze statusem po każdym uruchomieniu i pozwolić kanałowi zdecydować, kiedy powiadomić. Warunek w rodzaju status != "ok" sprawia, że udane uruchomienia pozostają ciche, a wbudowane zmienne czasu UTC pozwalają ograniczyć alerty do okna, w którym zadanie powinno się zakończyć.

Jak sprawić, by alertu nie dało się przeoczyć

Wykrycie problemu to dopiero połowa sprawy. Alert o nieudanej kopii zapasowej, który o 3 w nocy ląduje jako cichy baner, jest praktycznie tym samym co brak alertu.

W Echobell każdy kanał ma własny poziom pilności:

• Normal — standardowe powiadomienie push, w sam raz dla zadań informacyjnych
• Time-sensitive — przebija się przez tryb Skupienia w iOS, odpowiedni dla zadań, na które ktoś powinien wkrótce spojrzeć
• Calling — telefon dzwoni jak przy zwykłej rozmowie, dopóki nie zareagujesz

W przypadku zadań, w których cicha awaria kosztuje realne pieniądze — kopie zapasowe baz danych, naliczanie płatności, odnawianie certyfikatów — ustaw kanał na Calling. Różnica między „zobaczyłem o 3 w nocy" a „zobaczyłem o 9 rano" to dokładnie ta różnica, którą robi alert telefoniczny.

Jeśli za zadanie odpowiada kilka osób, udostępnij zespołowi link subskrypcji kanału; każda subskrybująca osoba dostanie ten sam alert w tej samej chwili.

Który wzorzec wybrać?

• Reakcja na kod wyjścia: pięć minut konfiguracji, wychwytuje jawne błędy. Zacznij od tego.
• Czuwak: łapie też pominięte i zawieszone uruchomienia. Dodaj go do każdego zadania, którego brak naprawdę byłby problemem.
• Kontrole danych w oknie czasowym: dla procesów, w których realnie grozi „zakończyło się sukcesem, ale wyprodukowało śmieci".

Dobrze się uzupełniają: reakcja na kod wyjścia mówi, że zadanie zawiodło i dlaczego, a czuwak gwarantuje, że dowiesz się o awariach, które nigdy nie miały szansy zgłosić się same.

Pierwszy alert o zadaniu cron ustawisz w kilka minut: pobierz Echobell, utwórz kanał i dopisz jedno wywołanie curl w crontabie. Następnym razem, gdy zaplanowane zadanie padnie o 3 w nocy, Twój telefon zadzwoni — a kopia zapasowa, którą odtworzysz w przyszłym kwartale, będzie istnieć.