Hogyan monitorozz cron feladatokat: 5 minta heartbeattel

A cron kiváló abban, hogy ütemezetten elindítson dolgokat, és katasztrofális abban, hogy szóljon neked, amikor nem teszi meg. Egy biztonsági mentés, amely abbahagyja a futást, ritkán dob olyan hibát, amit látsz. Egyszerűen csendben nem csinál semmit, és hetekkel később jössz rá, amikor szükséged lenne a mentésre, és nincs ott. Ez a csendes hiba problémája, és pont ezért minden fontos ütemezett feladatnak heartbeat ellenőrzésre van szüksége.

A heartbeat (vagy "dead man's switch") megfordítja a logikát. Ahelyett, hogy akkor riasztana, amikor valami baj van, a feladatod pingel egy monitorozási végpontot, amikor minden rendben van. Ha a várt ping nem érkezik időben, a monitor riaszt. Nincs ping, nincs üzenet, nagy baj.

Alább öt minta, a legegyszerűbbtől a legrobusztusabbig. Mind feltételezi, hogy van egy heartbeat URL-ed a monitorozó eszközödtől.

1. minta: Klasszikus dead man's switch

A lehető legegyszerűbb beállítás. A feladatod befejezés után meghív egy URL-t. Ha a monitor a várt ablakban nem kap üzenetet, riaszt.

# Napi mentés 02:30-kor, ping befejezés után
30 2 * * * /usr/local/bin/backup.sh && curl -fsS https://a-monitorod/ping/abc123

A &&-en múlik: a curl csak akkor fut le, ha a backup.sh 0 kóddal (siker) ér véget. Ha a mentés hibázik, nem megy ping, és a monitor elkapja. A -fsS kapcsolók miatt a curl HTTP-hibáknál csendben elbukik, de a valódi problémákat mégis megmutatja.

Gyengeség: csak azt erősíti meg, hogy a szkript futott és nullával ért véget. Ha a szkript elnyeli a saját hibáit, és mégis nullával végződik, hamis "minden rendben"-t kapsz.

2. minta: Ping csak valódi sikernél

Tedd explicitté a sikerjelet, ahelyett, hogy a shell exit-kód láncolására támaszkodnál. Több lépéses szkriptekben ez egyértelműbb.

#!/bin/bash
set -euo pipefail   # bármilyen hibánál ess el hangosan
run_the_backup
verify_the_backup    # tényleg ellenőrizd, hogy a kimenet létezik és van értelme
curl -fsS https://a-monitorod/ping/abc123   # csak akkor érhető el, ha minden fentebbi átment

A set -euo pipefail azt jelenti, hogy bármely sikertelen parancs megszakítja a szkriptet még a ping előtt. Egy valódi ellenőrző lépés hozzáadása (létezik-e a mentésfájl, nagyobb-e nulla bájtnál) bezárja az 1. minta "nullával végződött, de semmit sem csinált" lyukát.

3. minta: Exit-kód burkoló

Amikor magát a feladatot nem tudod módosítani (harmadik féltől származó bináris, beszállítói szkript), burkold be. A burkoló jelzi az indulást, lefuttatja a feladatot, és jelenti az exit-kódot.

#!/bin/bash
URL=https://a-monitorod/ping/abc123
curl -fsS "$URL/start"                  # "elindultam" jelzés
/opt/vendor/report-generator            # a feladat, amit nem irányítasz
EXIT=$?
curl -fsS "$URL/$EXIT"                   # jelentsd az exit-kódot

Az indulás jelzése lehetővé teszi, hogy a monitor a futás hosszát is mérje, és felfedezzen egy olyan feladatot, amely elindult, de soha nem ért véget (beragadt). Az exit-kód jelentése lehetővé teszi, hogy megkülönböztesse a "rendben lefutott"-at a "lefutott és hibázott"-tól.

4. minta: Feltételes ping (csak akkor pingelj, ha a munkának volt értelme)

Néhány feladat ütemezetten fut, de a valódi munkát csak néha végzi (egy sorfeldolgozó, amely gyakran üresen találja a sort). Nem akarsz "hiányzó heartbeat" riasztást, amikor a feladat jogosan nem csinált semmit. Csak akkor pingelj, amikor valódi munka történt, és ehhez igazítsd az ütemezést.

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

A monitor várt periódusát a valódi futások közötti leghosszabb reális szünetre állítsd. Az ára az érzékenység: a hosszabb ablak lassabb észlelést jelent, így csak akkor használd, ha a szabálytalan munka valóban várható.

5. minta: Jitter és grace ablakok

A valódi ütemezések driftelnek. A 02:00-ra állított feladat 02:00:04-kor is elindulhat a terhelés miatt, és egy napi feladat futásideje ingadozik. Ha a monitor pontosan az intervallumban várja a pinget, a normál jitter feleslegesen felver.

A megoldás a grace periódus: mondd meg a monitornak, hogy a várt idő után várjon még egy bizonyos ráhagyást, mielőtt riaszt. Egy napi mentés, amely általában 8 percig tart, használhat 20 perces grace ablakot. Szeretnél némi jittert is magában az ütemezésben, amikor sok feladatod van, hogy ne terheljék ugyanazt az erőforrást ugyanabban a másodpercben:

# Adj egy kis véletlen késleltetést (0-59 mp), hogy a 02:00-s feladatok szétterüljenek
0 2 * * * sleep $((RANDOM % 60)) && /usr/local/bin/backup.sh && curl -fsS https://a-monitorod/ping/abc123

A grace ablakok jelentik a különbséget egy monitor között, amelyben megbízol, és egy között, amelyet a harmadik téves riasztás után lenémítasz. A grace-t úgy állítsd be, hogy kényelmesen meghaladja a feladat legrosszabb reális futásidejét, ne az átlagát.

Gyors áttekintés

Hogyan ültesd át a gyakorlatba

Kezdd az 1. mintával a legfontosabb feladatodon még ma (mentés, számlázási futás, adatszinkronizálás). Adj hozzá ellenőrzést (2. minta) és grace ablakot (5. minta), mire elkezdesz támaszkodni rá. A heartbeat konfigurálásának részletesebb útmutatóját megtalálod a cron feladatok monitorozása heartbeattel útmutatónkban.

Ha a feladatod egy szolgáltatással kommunikál egy adott porton, az elérhetőséget először az ingyenes portellenőrzővel ellenőrizheted. És amikor készen állsz az ütemezett feladatok monitorozására a webekkel és API-kkal együtt egy helyen, nézd meg, hogyan működik az ePulz.io uptime monitorozása - a 7 napos próbaidőszak ingyenes, bankkártya nélkül.