لماذا تراقب ما يجب أن يُنفَّذ، لا ما يستجيب فقط
تتحقق مراقبة التوفّر من أن الخدمة تستجيب. لكنها لا ترى ما يحدث بين طلبين: نسخة الساعة الثالثة فجراً، وإرسال الفواتير، وتجديد شهادة، والتصدير إلى المحاسب. تفشل هذه المهام في صمت — قرص ممتلئ أو كلمة مرور منتهية أو خادم أُعيد تشغيله دون مؤقّته — ولا تنتبه إلا يوم تحتاج إليها.
لا يفيد متغير MAILTO في cron كثيراً: لا يرسل رسالة إلا إذا نُفّذت المهمة وكتبت في مخرجاتها، ولا يقول شيئاً حين لا تبدأ المهمة أصلاً. ينطلق Healthchecks من الغياب: لكل مهمة جدولة متوقعة، والصمت بعد مهلة السماح يطلق التنبيه.
ما يقدّمه Healthchecks
- مراقبة بالـ ping — كل مهمة تستدعي رابطاً فريداً، وغياب الإشارة يطلق التنبيه.
- جدولة cron أو بالمدة — تعبير cron مع المنطقة الزمنية أو فاصل بسيط، مع مهلة سماح.
- مدة التنفيذ — إشارتا
/startو/failتقيسان المدة وتبلّغان عن الفشل الصريح. - رموز الخروج والسجلات — رمز الخروج وآخر مخرجات الأمر، تُعرض في لوحة التحكم.
- أكثر من عشرين تكاملاً — البريد وwebhook وSlack وDiscord وMatrix وntfy وTelegram وGotify وPagerDuty وOpsgenie…
- الفريق وواجهة API — مشاريع منفصلة وأعضاء مدعوّون وشارات حالة وواجهة REST لإنشاء المراقبات من سكربتاتك.
Healthchecks مقارنةً بالطرق الشائعة
مرّر الجدول أفقيًا
| Healthchecks | MAILTO في cron | مراقبة التوفّر | |
|---|---|---|---|
| تنبيه إذا لم تبدأ المهمة | نعم | لا | لا |
| تنبيه إذا فشلت المهمة | نعم، برمز الخروج أو /fail | فقط إن كتبت في مخرجاتها | لا |
| مدة التنفيذ | تُقاس | لا | لا |
| أجهزة دون منفذ مفتوح | نعم، باستدعاء HTTPS صادر | نعم | لا، يجب الوصول إلى الهدف |
| قنوات التنبيه | أكثر من عشرين تكاملاً | بريد محلي | حسب الأداة |
| سجل مركزي | نعم، لكل مراقبة | لا | نعم، للخدمات |
المتطلبات
يكفي خادم Ubuntu 24.04 بذاكرة 1 غيغابايت: يعمل Healthchecks في حاوية واحدة ويخزّن بياناته في قاعدة SQLite. تحتاج إلى Docker مع إضافة Compose، وإلى اسم نطاق يشير إلى الخادم، مع nginx وشهادة HTTPS: تُبنى روابط ping وروابط التنبيهات على هذا العنوان، ويرفض التطبيق الطلبات الموجّهة إلى اسم آخر.
يفضّل تثبيت Healthchecks على جهاز منفصل عن الخوادم التي يراقبها: إن توقّف معها فلن ينبّهك أحد.
تثبيت Healthchecks باستخدام Docker Compose
تحضير ملف .env
أنشئ مجلد التطبيق وملف
.envيحمل المفتاح السري والعنوان العام. استبدلhc.example.comبنطاقك.mkdir -p /opt/healthchecks && cd /opt/healthchecks cat > .env <<EOF SECRET_KEY=$(openssl rand -hex 24) SITE_ROOT=https://hc.example.com EOFإنشاء ملف Compose
ضع ملف
docker-compose.ymlهذا في المجلد نفسه. يُنشر المنفذ على واجهة الحلقة المحلية فقط، والتسجيل العام مغلق، وقاعدة SQLite في وحدة تخزين.services: healthchecks: image: healthchecks/healthchecks:v5.0.1 restart: unless-stopped ports: - "127.0.0.1:8102:8000" env_file: .env environment: DEBUG: "False" DB_NAME: /data/hc.sqlite REGISTRATION_OPEN: "False" GUNICORN_WORKERS: "2" volumes: - healthchecks-data:/data volumes: healthchecks-data: {}التشغيل وإنشاء حساب المسؤول
عند التشغيل تطبّق الحاوية الترحيلات ثم تشغّل خادم الويب وعمليات إرسال التنبيهات. أنشئ بعد ذلك حسابك: يطلب الأمر بريداً إلكترونياً وكلمة مرور.
docker compose up -d docker compose exec healthchecks ./manage.py createsuperuserالنشر عبر HTTPS خلف nginx
أضف كتلة
serverلنطاقك مع شهادة Let's Encrypt، ومرّر ترويسات المصدر: دونX-Forwarded-Protoيفشل تسجيل الدخول بخطأ CSRF.location / { proxy_pass http://127.0.0.1:8102; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }
أبقِ التسجيل مغلقاً
يقبل Healthchecks افتراضياً التسجيل العام. الإعداد REGISTRATION_OPEN: "False" يغلقه: لا يدخل إلا الحسابات التي تنشئها أو تدعوها إلى مشروع. على خادم مكشوف للإنترنت، اضبط هذا منذ أول تشغيل.
ربط مهام cron
في لوحة التحكم أنشئ مراقبة، وحدّد الجدولة — تعبير cron للمهمة ومنطقتها الزمنية — ثم مهلة سماح تغطي مدتها المعتادة. انسخ رابط ping وأضفه إلى المهمة.
# crontab: backup at 3 a.m., ping only on success
0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 5 -o /dev/null https://hc.example.com/ping/<uuid>
# variant: signal the start, then send the exit code
URL=https://hc.example.com/ping/<uuid>
curl -fsS -m 10 --retry 5 -o /dev/null "$URL/start"
/usr/local/bin/backup.sh > /tmp/backup.log 2>&1
curl -fsS -m 10 --retry 5 -o /dev/null --data-binary @/tmp/backup.log "$URL/$?"الصيغة الأولى لا ترسل الإشارة إلا عند النجاح: يظهر الفشل كإشارة غائبة، ومن ثم تنبيه بعد مهلة السماح. الثانية أوضح: /start يقيس المدة، ورمز الخروج المرسل بدل الإشارة يبلّغ عن الفشل فوراً، والمخرجات المرسلة في جسم الطلب تظهر في سجل المراقبة. الخياران -m 10 --retry 5 يمنعان شبكة متقلبة من تعطيل المهمة أو إيهامك بعطل.
استقبال التنبيهات
من Integrations أضف قناة واحدة على الأقل تقرؤها فعلاً، ثم اربطها بمراقباتك. تعمل webhook وSlack (webhook وارد) وMattermost وntfy وGotify دون أي إعداد على الخادم. تحتاج تكاملات أخرى إلى بيانات اعتماد في .env: رمز بوت لـ Telegram، وحساب ورمز لـ Matrix، وتطبيق OAuth لـ Discord.
تمرّ تنبيهات البريد عبر خادم SMTP: أضف EMAIL_HOST وEMAIL_PORT وEMAIL_HOST_USER وEMAIL_HOST_PASSWORD وDEFAULT_FROM_EMAIL إلى .env ثم أعد التشغيل بـ docker compose up -d. الإعدادات نفسها تخدم دعوات الفريق والتقارير الدورية.
استكشاف الأعطال
تُرجع الصفحة خطأ 400. لا يصل الطلب باسم المضيف الصحيح: تحقّق من أن SITE_ROOT يطابق تماماً النطاق الذي يخدمه nginx، وأن كتلة location تمرّر ترويسة Host.
يفشل تسجيل الدخول بخطأ CSRF. لا يمرّر nginx الترويسة X-Forwarded-Proto: يظن التطبيق أنه يستقبل HTTP بينما يتحدث المتصفح HTTPS. أضف الترويسة وأعد تحميل nginx.
تنتقل مراقبة إلى حالة تنبيه رغم تنفيذ المهمة. لم تُرسل الإشارة: جرّب أمر curl يدوياً من الجهاز المعني، وتحقّق من الوصول الصادر عبر HTTPS، ومدّد مهلة السماح إن كانت المهمة أطول من المتوقع.
لا يصل أي بريد. دون EMAIL_HOST لا يرسل Healthchecks شيئاً ويذكر ذلك في سجلاته عند التشغيل: راجع docker compose logs healthchecks.
التثبيت بنقرة من متجر ServOrbit
يثبّت متجر ServOrbit تطبيق Healthchecks على خادمك دون سطر أوامر: ينشر الحاوية مع إغلاق التسجيل، وينشئ حساب المسؤول بكلمة مرور مولّدة، وينشر التطبيق عبر HTTPS على نطاق فرعي لنطاقك أو على النطاق الفرعي المجاني للخادم. يظهر المعرّف وكلمة المرور في مساحة العميل؛ ولا يبقى إلا إنشاء مراقباتك.
