Skip to content
VDS · المراقبة والأداء

تنبيهات توقف الموقع

كيف تعرف بعدم توفر الخدمة قبل المستخدمين: فحوصات خارجية، ومراقب بسيط على الخادم نفسه، وإعادة تشغيل الخدمة تلقائيًا.

آخر تحديث 23 أغسطس 2026

تعرض الرسوم البيانية في لوحة التحكم حالة الجهاز، لكنها لا تجيب عن سؤال «هل الموقع يعمل؟». قد يتعطل التطبيق بينما تظل وحدة المعالجة المركزية خاملة، ومن دون فحص خارجي لن تعرف بذلك إلا من عملائك.

الفحوصات الخارجية

القاعدة الأساسية: لا تفحص من الجهاز الذي تراقبه. استخدم أي خدمة مراقبة جهوزية خارجية — فهناك العديد منها، بما في ذلك خطط مجانية لعدة عناوين بفاصل زمني دقيقة واحدة. الإعدادات المهمة فعلاً:

  • عنوان الفحص. ليس الصفحة الرئيسية، بل مسار منفصل مثل /healthz يفحص قاعدة البيانات وقائمة الانتظار معاً. وإلا فسيُقدَّم لك نسخة مخزّنة مؤقتاً من الصفحة الرئيسية حتى عندما تكون الواجهة الخلفية معطلة.
  • الاستجابة المتوقعة. رمز 200 مع سلسلة نصية في المحتوى. كثير من التطبيقات تعيد 200 مع رسالة خطأ عند تعطلها.
  • الحد الأدنى. محاولتان أو ثلاث محاولات فاشلة متتالية، وإلا أي تعثر في الشبكة سوق يوقظك.
  • القناة. Telegram أو البريد الإلكتروني. تأكد من وصول التنبيه فعلاً: عطّل الخدمة لدقيقة وانتظر الرسالة.

لا تنسَ فحصاً منفصلاً لانتهاء صلاحية الشهادة — فشهادة TLS منتهية الصلاحية تبدو كعطل وتحدث بانتظام.

Watchdog على الجهاز نفسه

ستخبرك المراقبة الخارجية بأن الموقع متوقف. ولتعود الخدمة إلى العمل من تلقاء نفسها، اضبط systemd. في وحدة الخدمة:

[Service]
Restart=always
RestartSec=5
StartLimitBurst=5
StartLimitIntervalSec=120

بهذه الطريقة تنجو الخدمة من تعطل عارض، لكنها لن تدخل في حلقة لا نهائية إذا كان الإعداد معطوباً. بعد التعديل: systemctl daemon-reload && systemctl restart myapp.

أما التطبيقات التي لا تتعطل بل تتجمد، فأضف إليها فحص HTTP. زوج من الوحدات — مؤقت وخدمة:

cat >/etc/systemd/system/healthcheck.service <<'EOF'
[Service]
Type=oneshot
ExecStart=/usr/local/bin/healthcheck.sh
EOF

cat >/etc/systemd/system/healthcheck.timer <<'EOF'
[Timer]
OnUnitActiveSec=60
[Install]
WantedBy=timers.target
EOF

systemctl enable --now healthcheck.timer

السكربت نفسه:

#!/bin/sh
curl -fsS --max-time 10 http://127.0.0.1:8080/healthz >/dev/null || systemctl restart myapp

تنبيهات صحة الجهاز

من المفيد أيضاً أن تعرف بنفاد مساحة القرص والذاكرة قبل حدوث عطل. أبسط خيار هو مهمة cron ترسل رسالة عبر Telegram عند تجاوز حد معين:

0 * * * * root [ "$(df --output=pcent / | tr -dc 0-9)" -gt 85 ] && curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" -d chat_id=$CHAT -d text="VDS disk usage is over 85%"

يوفر Netdata خياراً أكثر تقدماً بحدود جاهزة.

الأخطاء الشائعة

  • المراقبة على الجهاز نفسه. إذا تعطل الجهاز، يموت كل من الـ watchdog والتنبيهات.
  • حد أدنى حساس للغاية. سيل من الإنذارات الكاذبة يعني أنك ستتجاهل الإنذار الحقيقي.
  • Restart=always بدلاً من التحقيق في السبب. إعادة التشغيل تخفي تسرب الذاكرة: تتعطل الخدمة كل نصف ساعة وأنت لا ترى ذلك. تحقق من systemctl show myapp -p NRestarts وjournal.
  • الفحص عبر ping فقط. يستجيب الجهاز لـ ICMP حتى مع خادم ويب ميت تماماً.

أول ما تفحصه عند إطلاق تنبيه هو «Overview» في لوحة التحكم /hosting/vds/m/<id>. انقطاع في الرسوم البيانية يعني مشكلة في الجهاز؛ ورسوم بيانية مسطحة عند تعذر الوصول إلى الموقع تعني مشكلة في التطبيق.