پایش وظایف زمان‌بندی‌شده کرون

مشکل با وظایف زمان‌بندی‌شده

ویژگی دردناک کران‌ها این است که وقتی خراب می‌شوند، هیچ چیزی به شما اطلاع نمی‌دهد. اپلیکیشن وب همچنان درخواست‌ها را پاسخ می‌دهد، صفحه اصلی عادی به نظر می‌رسد، مانیتورینگ سبز است – اما در جایی روی سرور، بکاپ شبانه دو هفته است اجرا نشده. ورکِر صف بعد از دیپلوی کرش کرده و کارهای معلق در حال جمع شدن‌اند. همگام‌سازی ساعتی بی‌سر و صدا به دلیل مشکل دسترسی، سطرهایی را از دست می‌دهد. شما فقط زمانی متوجه می‌شوید که چیزی در بخش پایین‌تر سیستم بالاخره کرش می‌کند – معمولاً دقیقاً وقتی که بیشترین نیاز را به آن دارید. تیم داده‌ها اکسپورت می‌خواهد، پشتیبانی صف ایمیل را، اپس بکاپ را. آن زمان دیگر خیلی دیر شده.

مانیتورینگ استاندارد آپ‌تایم این مورد را متوجه نمی‌شود، چون چیزی برای پینگ کردن وجود ندارد. کران هیچ اندپوینت HTTP نمی‌دهد، پورتی را باز نمی‌کند، سِروری راه نمی‌اندازد. اجرا می‌شود، تمام می‌شود، تمام. اگر از کار بیفتد – هیچ سیگنالی از نبودن آن نخواهید داشت، تا زمانی که دنبال آن نگردید.

الگوی معکوس: مانیتورینگ هارت‌ بیت

مانیتورینگ هارت‌ بیت (که به آن "کلید مرده" یا "مانیتورینگ کران‌ها" هم می‌گویند) جهت را عوض می‌کند. به جای اینکه ما سرویس شما را بررسی کنیم، این سرویس شما است که خود را به ما معرفی می‌کند. فقط یک خط به کران اضافه می‌کنید – یک curl به یک URL یکتا که ما تولید می‌کنیم – و این URL با هر ضربه، زمان را ثبت می‌کند. ما مراقب غیاب این پینگ‌ها هستیم. اگر URL در بازه مورد انتظار (به همراه مارجین) فراخوانی نشود، آن را یک اجرای از دست رفته حساب می‌کنیم و هشدار می‌فرستیم.

این مدل ساده، قابل اعتماد و مستقل از زبان است. هرچیزی که بتواند درخواست HTTP بفرستد – یکپارچه می‌شود. مثلا Bash با curl، پایتون با requests، Node با fetch، PHP با curl_init، Scheduler ویندوز با Invoke-WebRequest، GitHub Actions، Kubernetes CronJobs، رویدادهای زمان‌بندی‌شده Lambda – هر چیزی. بدون SDK، بدون ایجنت، بدون دیمون برای نصب.

چگونه پیکربندی کنیم

در DiagnoSEO Uptime Monitoring روی "افزودن مانیتور" کلیک کنید، نوع "Heartbeat / cron" را انتخاب کنید. ابزار یک URL یکتای دارای توکن تولید می‌کند – چیزی شبیه https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9. بازه مورد انتظار (هر چند دقیقه یک‌بار باید اجرا شود) و مارجین (چقدر تأخیر مجاز است پیش از هشدار) را تنظیم کنید. ذخیره کنید.

حالا کران را طوری تغییر دهید که پس از هر اجرای موفق، به این 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

از این لحظه، هر اجرای موفق کران برای ما پینگ می‌فرستد و ما زمان آن را ثبت می‌کنیم. اگر طی بازه + مارجین دقیقه پینگی نبینیم، یک حادثه ثبت و روی همه کانال‌های فعال اطلاع‌رسانی ارسال می‌شود: ایمیل، تلگرام، اسلک، دیسکورد، پیامک.

انتخاب بازه و مارجین

بازه باید کاملاً مطابق زمان‌بندی کار در کران باشد. بکاپ شبانه ۳ صبح – بازه ۱۴۴۰ دقیقه (۲۴ ساعت). همگام‌سازی ساعتی – ۶۰. ورکِر که هر ۵ دقیقه یک‌بار اجرا می‌شود – ۵.

مارجین برای جذب تاخیرهای طبیعی است. کران‌ها دقیقاً سر نانوثانیه اجرا نمی‌شوند – صف‌بندی می‌شوند، منتظر اتمام اجرای قبلی می‌مانند، در خطاهای موقت back-off می‌زنند. یک کار ۲۴ ساعته با مارجین ۱ ساعته یک بافر راحت می‌دهد بدون اینکه هشدارها دیر برسد. ورکِر ۵ دقیقه‌ای با مارجین ۲ دقیقه‌ای، مرگ واقعی را به‌سرعت می‌گیرد بدون هشدار کاذب از پرش‌های ۳۰ ثانیه‌ای. به طور حدودی: مارجین را ۱۰ تا ۵۰ درصد بازه قرار دهید بسته به اینکه کار شما چقدر "نوسان" دارد.

الگوهای پیشنهادی ما

• فقط پس از موفقیت پینگ کن. از && در bash استفاده کن – اجرای ناموفق پینگ نمی‌زند. ما غیبت پینگ را شناسایی می‌کنیم و هشدار می‌دهیم.
• پینگ بعد از هر چرخه حلقه. برای ورکِرهای طولانی‌مدت، بعد از هر واحد موفق کار، درون حلقه پینگ کن، نه آخر کار. اینگونه ورکِر گیرکرده در زمان اجرا قابل شناسایی خواهد بود.
• یک هارت‌ بیت برای هر وظیفه منطقی، نه هر اسکریپت. اگر سه اسکریپت روی هم یک پایپ‌لاین شبانه هستند، فقط یک‌بار در انتهای زنجیره پینگ کن. این یک سیگنال واضح «آیا پایپ‌لاین زنده است» می‌دهد.
• با لاگ‌ها ترکیب کن. هارت‌ بیت نشان می‌دهد که کار اجرا شده است. لاگ‌های اپلیکیشن نشان می‌دهد چه کار انجام شده. با هم، یک تصویر کامل داری.

اگر هارت‌ بیت قطع شود چه می‌شود

در لحظه عبور از پایان مهلت، حادثه ثبت می‌شود. داشبورد مانیتور را با رنگ قرمز و پیام خطا «مدت X دقیقه هارت‌ بیت نداریم» نشان می‌دهد. اطلاع‌رسانی روی همه کانال‌های فعال شما ارسال می‌شود. وقتی هارت‌ بیت جدید برسد، مانیتور اتوماتیک به حالت up بازمی‌گردد – با وضعیت up علامت‌گذاری می‌شود، حادثه بسته می‌شود و (اگر هشدار بهبود روشن باشد) پیام «سیستم دوباره آنلاین شد» دریافت می‌کنید.

همه این‌ها مثل سایر مانیتورها رفتار می‌شوند – نقشه حرارتی، درصد آپ‌تایم، تاریخچه، تگ‌ها، جستجو، خروجی گزارش. از دید داشبورد، مانیتور هارت‌ بیت فقط یک ردیف دیگر است که کنار HTTP، پینگ، پورت و API قابل مرتب‌سازی و فیلتر است.

چک‌لیست

مانیتور اضافه کن → نوع Heartbeat → URL تولیدشده را کپی کن → به کران / ورکِر / زمان‌بندی اضافه کن → بازه و مارجین تعیین کن → ذخیره کن → آماده. حالا در لحظه‌ای که وظیفه زمان‌بندی‌شده کرش کند مطلع خواهی شد – چیزی که در بلندمدت از مهم‌ترین تصمیمات مانیتورینگ است که می‌توانی بگیری.

سوالات متداول

• مانیتورینگ هارت‌ بیت / کران‌جاب چیست؟

  مانیتورینگ معکوس — وظیفه زمان‌بندی‌شده شما هنگام اجرای موفق، به URL ما پینگ می‌کند. اگر در بازه انتظار ندیده باشیم، هشدار می‌دهیم. مشکل خرابی‌های بی‌صدا را حل می‌کند: کران آسیب‌دیده خطا نمی‌دهد و منجر به هشدار استاندارد آپ‌تایم نمی‌شود.

• چطور URL هارت‌ بیت را با کران خود یکپارچه کنم؟

  در انتهای فرمان کران، curl -fsS <heartbeat_url> اضافه کنید. اگر دستور قبلی ناموفق باشد، curl اجرا نخواهد شد و هارت‌ بیت رد می‌شود. یا می‌توانید ابتدای کار و پایان کار با مسیرهای متفاوت پینگ کنید — این‌گونه سیگنال «شروع» و «پایان» مجزا دریافت می‌شود.

• چه مدت دوره مهلتی باید تنظیم کنم؟

  حدود ۲ تا ۳ برابر زمان معمول اجرای وظیفه. اگر بکاپ روزانه شما ۳۰ دقیقه طول می‌کشد، مهلت را روی ۹۰ دقیقه بگذارید — به کندی‌ها بدون هشدار کاذب میدان می‌دهد. برای کارهایی با زمان اجرای متغیر، مهلت بیشتری بگذارید و از داشبورد برای شناسایی کارهای غیرمعمول استفاده کنید.

• آیا می‌توانم کران‌جاب‌های ساعتی را مانیتور کنم؟

  بله — بازه را مطابق قرار دهید (مثلاً ۶۰ دقیقه مورد انتظار و ۱۵ دقیقه مهلت). مانیتور انتظار دارد حداقل هر ۷۵ دقیقه یک پینگ بگیرد. اگر کار شما پرتکرارتر است (هر ۵ دقیقه)، URL هارت‌ بیت هم پشتیبانی می‌کند — فقط تنظیم بازه را مطابق کنید.

• آیا مانیتورینگ هارت‌ بیت برای AWS Lambda یا سرورلس جواب می‌دهد؟

  بله. در پایان تابع لمبدا، یک فراخوانی خروجی HTTP به URL هارت‌ بیت اضافه کنید. مانیتور کاملاً معادل هارت‌ بیت کران رفتار می‌کند — همان هشدار، همان دوره مهلت. برای لمبداهای زمان‌بندی‌شده که آلارم CloudWatch خرابی‌های بی‌صدا را شناسایی نمی‌کند سودمند است.