Cron-tehtävien valvonta

Ongelma ajoitettujen tehtävien kanssa

Cronien julma puoli on se, että kun ne kaatuvat, et saa siitä mitään tietoa. Verkkosovellus palvelee edelleen pyyntöjä, etusivu näyttää normaalilta, monitorointi näyttää vihreää – mutta jossain palvelimella yövarmuuskopio ei ole pyörähtänyt käyntiin kahteen viikkoon. Queue worker kaatui julkaisun jälkeen ja vanhat jobit kasaantuvat. Synkronointi hukkaa rivejä hiljaa kerran tunnissa käyttöoikeusongelman takia. Saat tietää vasta, kun jokin downstream kaatuu – yleensä juuri silloin, kun tarvitset sitä eniten. Data-tiimi haluaa viennin, tuki jonon sähköposteja, ylläpito varmuuskopion. Silloin on jo liian myöhäistä.

Tavallinen uptime-valvonta ei havaitse tätä, koska mitään ei voi pingata. Cron ei tarjoa HTTP-endpointtia, ei avaa porttia, ei käynnistä palvelinta. Se käynnistyy, suorittaa, lopettaa. Jos se lakkaa toimimasta – ei tule mitään signaalia poissaolosta ennen kuin alat itse etsiä syytä.

Käänteinen malli: heartbeat-valvonta

Heartbeat-valvonta (tunnetaan myös nimellä "dead man's switch" tai "cronien valvonta") kääntää suunnan. Sen sijaan, että me tarkistaisimme sinun palvelusi, sinun palvelusi ilmoittaa meille. Lisäät yhden rivin croniin – curl yksilölliseen URL-osoitteeseen, jonka luomme – ja tämä URL tallentaa aikaleiman aina jokaisen käynnistyksen yhteydessä. Me vahdimme näiden pingien poissaoloa. Jos URL-osoitetta ei osuta odotetulla välillä (plus marginaali), käsittelemme sen ohitetuksi suoritukseksi ja lähetämme hälytyksen.

Malli on yksinkertainen, luotettava ja kieliriippumaton. Kaikki mikä osaa tehdä HTTP-pyynnön – integroituu. Bash curlilla, Python requestseilla, Node fetchillä, PHP curl_initillä, Windowsin Task Scheduler Invoke-WebRequestillä, GitHub Actions, Kubernetes CronJobs, Lambda scheduled events – mikä vain. Ei SDK:ta, ei agenttia, ei asennettavaa daemonia.

Kuinka konfiguroida

DiagnoSEO Uptime Monitoringissa klikkaa "Lisää monitori", valitse tyyppi "Heartbeat / cron". Työkalu luo yksilöllisen URL-osoitteen tokenilla – jotain tyyliin https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9. Aseta odotettu väli (kuinka usein jobi suoritetaan, minuuteissa) ja marginaali (kuinka paljon myöhästyminen hyväksytään ennen paniikkia). Tallenna.

Muokkaa nyt croniasi niin, että se pingaa URL-osoitetta jokaisen onnistuneen suorituksen jälkeen. Kolme tyyliä ympäristöstä riippuen:

# Bash cron – ping vain onnistumisen jälkeen
0 3 * * * /usr/bin/backup.sh && curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Tai jos osittainen onnistuminen kelpaa
0 3 * * * /usr/bin/backup.sh; curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Python
import requests
def main():
    do_the_work()
    requests.get('https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9', timeout=5)

# GitHub Actions
- name: Notify heartbeat
  if: success()
  run: curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9

Tästä hetkestä lähtien jokainen onnistunut ajo pingaa meille, ja me tallennamme aikaleiman. Jos emme näe pingia väli + marginaali minuutin sisällä, incident avautuu ja ilmoitukset lähtevät kaikille aktivoiduille kanaville: Sähköposti, Telegram, Slack, Discord, SMS.

Välin ja marginaalin valinta

Välin tulee vastata täsmälleen jobin aikataulua. Yövarmuuskopio klo 03:00 – väli 1440 minuuttia (24 h). Synkronointi tunneittain – 60. Worker, joka pollaa 5 min välein – 5.

Marginaali tasaa luonnollisen jitterin. Cronit eivät käynnisty nanosekunnilleen – ne jonottuvat, odottavat aikaisemman suorituksen loppua, tekevät back-offin hetkellisissä virheissä. 24-tuntinen job marginaalilla 1 h antaa mukavan puskurin ilman, että hälytykset viivästyvät. 5 minuutin välein pollannut worker, jossa 2 minuutin marginaali, nappaa oikeat kuolemat nopeasti ilman vääriä hälytyksiä lyhyistä katkoksista. Yleisesti: aseta marginaali noin 10–50 % välistä sen mukaan, kuinka paljon jobi "heilahtelee".

Suositellut käytännöt

• Ping vain onnistumisen jälkeen. Käytä && bashissa – epäonnistunut ajo ei pingaa. Me havaitsemme pingin puuttumisen ja hälytämme siitä.
• Ping jokaisen silmukan iteraation jälkeen. Pitkäkestoisilla workereilla pingataan silmukassa jokaisen onnistuneen työyksikön jälkeen, ei lopuksi. Näin jumittunut worker havaitaan suorituksen aikana.
• Yksi heartbeat loogista jobia kohti, ei skriptiä. Jos kolme skriptiä muodostavat yhden yöaikataulun pipeline:n, pingaa kerran ketjun lopussa. Näin saat puhtaan signaalin "pipeline on elossa".
• Yhdistä lokien kanssa. Heartbeat kertoo että jobi käynnistyi. Sovelluslogit kertovat mitä tehtiin. Yhdessä saat täyden kuvan.

Mitä tapahtuu kun heartbeat katoaa

Incident avautuu heti deadline:n ylityttyä. Hallintapaneeli näyttää monitorin punaisena virheellä "Heartbeat puuttuu X minuuttia". Ilmoitukset lähtevät kaikille kanaville, jotka olet aktivoinut. Kun tuore heartbeat saapuu, monitori palaa automaattisesti tilaan up – merkitty ylös, incident sulkeutuu, ja jos palautumisilmoitukset ovat käytössä, saat ilmoituksen "takaisin verkossa".

Tämä kaikki käsitellään aivan kuten muutkin monitorit – heatmap, uptime-prosentti, historia, tagit, haku, vienti. Hallintapaneelin näkökulmasta heartbeat-monitori on vain yksi rivi, lajiteltavissa ja suodatettavissa HTTP:n, pingin, portin ja API:n rinnalla.

Tarkistuslista

Lisää monitori → tyyppi Heartbeat → kopioi luotu URL → lisää cron / worker / ajastimeen → aseta väli ja marginaali → tallenna → valmis. Nyt saat tiedon sekunnissa, jos ajoitettu tehtävä lakkaa toimimasta – mikä pitkällä aikavälillä on yksi tärkeimmistä monitorointipäätöksistä.

Usein kysytyt kysymykset

• Mikä on heartbeat- / cron-job-valvonta?

  Käänteinen valvonta — ajoitettu tehtäväsi pingaa meidän URL:iamme, kun se onnistuu. Jos emme saa siitä viestiä odotetussa aikaikkunassa, hälytämme. Tämä ratkaisee hiljaisten vikojen ongelman: hajonnut cron-job ei tuota virheilmoitusta eikä laukaise perinteistä uptime-hälytystä.

• Miten integroida heartbeat-URL cron-tehtävän kanssa?

  Lisää curl -fsS <heartbeat_url> cron-komennon loppuun. Jos edeltävä komento epäonnistuu, curl ei käynnisty ja heartbeat jää lähettämättä. Vaihtoehtoisesti voit pingata alussa ja lopussa eri osoitteisiin – näin saat erilliset signaalit "aloitettu" ja "valmis".

• Minkä pituisen grace-ajanjakson minun tulisi asettaa?

  Noin 2–3x tehtävän tyypillinen suoritusaika. Jos päivittäinen varmuuskopio kestää 30 minuuttia, aseta grace 90 minuuttiin – kattaa hidastelut ilman vääriä hälytyksiä. Vaihtelevan keston tehtäville aseta reilusti ja käytä hallintapaneelia poikkeamien tunnistamiseen.

• Voinko monitoroida cron-job-tehtäviä, jotka ajetaan tunnin välein?

  Kyllä – aseta väli sopivaksi (esim. 60 minuuttia odotettu, 15 minuuttia grace). Monitori odottaa pingia vähintään 75 minuutin välein. Jos tehtäväsi suoritetaan useammin (vaikka 5 minuutin välein), heartbeat-URL tukee tätäkin – säädä vain väliasetusta sopivaksi.

• Toimiiko heartbeat-valvonta AWS Lambda / serverless -ratkaisujen kanssa?

  Kyllä. Lisää HTTP-pyyntö heartbeat-URL:iin Lambda-funktion lopuksi. Monitori käsittelee tämän aivan kuten cron heartbeatin — sama ilmoitus, sama grace-jakso. Hyödyllinen ajastetuille Lamdoille, joissa CloudWatchin hälytykset eivät tunnista hiljaisia suoritusten virheitä.