ניטור משימות קרון

בעיה במשימות מתוזמנות

המגרעת האכזרית של cron היא שכשהן נופלות, אף אחד לא יגיד לך על זה. אפליקציית הווב עדיין מגישה בקשות, הדף הראשי נראה תקין, המוניטור מראה ירוק – אבל איפשהו על השרת הגיבוי הלילי לא רץ כבר שבועיים. ה-queue worker התרסק אחרי deploy והעבודות נערמות. הסנכרון בכל שעה מאבד בשקט שורות עקב בעיית הרשאות. אתה מגלה רק כשהמשהו בתהליך למטה קורס – בדרך כלל בדיוק כשאתה צריך את זה הכי הרבה. צוות הנתונים מבקש export, התמיכה מבקשת טור מיילים, צוות התפעול מבקש גיבוי. בשלב הזה כבר מאוחר מדי.

מוניטור uptime סטנדרטי לא יזהה את זה, כי אין מה "לפינג". cron לא פותח endpoint של HTTP, לא פותח פורט, לא מריץ שרת. הוא מתחיל, מסיים, נגמר. אם הוא מפסיק לפעול – אין שום איתות להיעדרות שלו, עד שתתחיל לחפש.

דפוס הפוך: ניטור heartbeat

ניטור heartbeat (נקרא גם "dead man's switch" או "ניטור cron") הופך את הכיוון. במקום שאנחנו נבדוק את השירות שלך, השירות שלך מדווח אלינו. אתה מוסיף שורה אחת ל-cron – curl ל-URL ייחודי שנוצר עבורך – וה-URL הזה שומר חותמת זמן בכל פעם שהוא מקבל פינג. אנחנו שומרים על חוסר הפינגים האלו. אם ה-URL לא נדרש בפרק הזמן שציפינו (פלוס שוליים), אנחנו מתייחסים לזה כריצה שהתפספסה ושולחים התראה.

המודל פשוט, אמין ולא תלוי שפה. כל מה שיכול לשלוח בקשת HTTP – משתלב. Bash עם curl, Python עם requests, Node עם fetch, PHP עם curl_init, Task Scheduler ב-Windows עם Invoke-WebRequest, GitHub Actions, Kubernetes CronJobs, Lambda scheduled events – מה שתרצה. בלי SDK, בלי agent, בלי daemon להתקנה.

איך מגדירים

ב- Uptime Monitoring של DiagnoSEO לחץ על "הוסף מוניטור", בחר סוג "Heartbeat / cron". הכלי יוצר עבורך URL ייחודי עם token – משהו כמו https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9. קבע את האינטרוול המצופה (כל כמה דקות שה-job אמור לפעול) ואת השוליים (כמה איחור עדיין בסדר לפני שנלחצים). שמור.

עכשיו שנה את ה-cron כך שיפינג את ה-URL אחרי כל ריצה מוצלחת. שלוש דוגמאות לפי הסביבה:

# Bash cron - פינג רק אחרי הצלחה
0 3 * * * /usr/bin/backup.sh && curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# או כאשר הצלחה חלקית מספיקה
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

מרגע זה, כל ריצה מוצלחת תשלח אלינו פינג ואנחנו מתעדים את החותמת זמן. אם לא נראה פינג בתוך אינטרוול + שוליים דקות, נפתח אירוע ונשלחות התראות לכל הערוצים הפעילים: אימייל, טלגרם, Slack, דיסקורד, SMS.

בחירת אינטרוול ושוליים

האינטרוול צריך להתאים בדיוק ללוח הזמנים של ה-job. גיבוי לילי ב-3:00 – אינטרוול 1440 דקות (24 שעות). סנכרון כל שעה – 60. worker שמושך כל 5 דקות – 5.

השוליים בולעים את ה-jitter הטבעי. cron לא רץ בדייקנות של ננושנייה – יש תורים, מחכה לסיום הרצה קודמת, עושה back-off על שגיאות רגעיות. job יומי עם שעת שוליים נותן מרווח ביטחון בלי לעכב התראות. worker של 5 דקות עם שוליים של 2 דקות מגלה הפסקות אמיתיות מהר, בלי false positive על נפילה קצרה של 30 שניות. כלל אצבע: קבע שוליים של 10-50% מהאינטרוול לפי כמה ה-job שלך "מתנדנד".

דפוסים מומלצים

• פינג רק אחרי הצלחה. השתמש ב-&& ב-bash – ריצה שנכשלה לא תפינג. אנחנו נזהה היעדר פינג ונתריע.
• פינג אחרי כל איטרציה בלולאה. עבור workers שרצים לאורך זמן, פינג בלולאה אחרי כל יחידת עבודה מוצלחת, לא רק בסוף. כך worker שנתקע יתגלה תוך כדי הריצה.
• Heartbeat אחד ל-job לוגי, לא לסקריפט. אם שלושה סקריפטים מרכיבים יחד pipeline לילי, תפינג רק בסוף השרשרת. כך מקבלים איתות נקי "האם ה-pipeline חי".
• שלב עם לוגים.heartbeat מסמן שה-job רץ. לוגים של האפליקציה מספרים מה נעשה. ביחד זו תמונת מצב מלאה.

מה קורה כשה-heartbeat נעלם

אירוע נפתח ברגע שעובר ה-deadline. לוח הבקרה מסמן את המוניטור באדום עם השגיאה "לא התקבל heartbeat כבר X דקות". התראות נשלחות לכל הערוצים המופעלים. ברגע שמתקבל heartbeat חדש, המוניטור חוזר אוטומטית ל-up – מסומן כפעיל, האירוע נסגר, ואם הפעלת התראות החלמה, תקבל הודעה על חזרה לאונליין.

הכל מטופל באותו אופן כמו כל מוניטור אחר: heatmap, uptime באחוזים, היסטוריה, תגיות, חיפוש, ייצוא. מבחינת הדשבורד מוניטור heartbeat הוא סתם עוד שורה – ניתן לסינון ומיון כמו HTTP, פינג, פורט ו-API.

רשימת בדיקה

הוסף מוניטור → סוג Heartbeat → העתק את ה-URL שנוצר → הוסף ל-cron / worker / scheduler → קבע אינטרוול ושוליים → שמור → מוכן. מעתה תדע תוך שנייה כשהמשימה המתוזמנת שלך לא עובדת – החלטה קריטית ארוכת טווח לאיכות הניטור שלך.

שאלות נפוצות

• מה זה ניטור heartbeat / cron-job?

  ניטור הפוך — המשימה המתוזמנת שלך שולחת פינג ל-URL שלנו כשהיא מופעלת בהצלחה. אם לא נשמע ממנה בפרק הזמן שנקבע, אנו מתריעים. פותר את הבעיה של כשלים שקטים: cron job תקול לא מייצר שגיאה ולא יפעיל התראת uptime רגילה.

• איך אני משלב את URL ה-heartbeat עם ה-cron שלי?

  הוסף curl -fsS <heartbeat_url> לסוף הפקודה של ה-cron. אם הפקודה שלפניו נכשלה, curl לא ירוץ וה-heartbeat יתפספס. ניתן גם לפינג בתחילה ובסוף עם שני נתיבים שונים – זה מספק איתותים נפרדים של "התחל" ו-"הושלם".

• איזה grace period כדאי להגדיר?

  בערך פי 2-3 לזמן הריצה האופייני של המשימה. אם הגיבוי היומי שלך לוקח 30 דקות, הגדר grace ל-90 דקות – לוקח בחשבון עיכובים בלי התראות שווא. למשימות עם זמן ריצה משתנה, הגדר בנדיבות והשתמש בלוח הבקרה כדי לזהות חריגים.

• האם אני יכול לנטר cron jobs שרצים כל שעה?

  כן – קבע אינטרוול מתאים (למשל 60 דקות צפוי, עם 15 דקות grace). המוניטור מצפה לפינג לפחות כל 75 דקות. אם המשימה שלך תדירה יותר (כל 5 דקות), גם ל-URL heartbeat אין בעיה – פשוט התאם את ההגדרה.

• האם ניטור heartbeat עובד ב-AWS Lambda / serverless?

  כן. הוסף קריאה יוצאת של HTTP ל-URL של heartbeat בסוף פונקציית ה-Lambda. המוניטור מתייחס לזה כמו cron heartbeat – אותה התראה, אותו grace period. זה עוזר ל-Lambdas מתוזמנות שבהן CloudWatch לא מזהה כשלים שקטים.