كيفية مراقبة جاهزية الخادم (Uptime) وإعداد التنبيهات

ما المقصود فعلياً بـ«مراقبة الجاهزية» (Uptime)

تجيب مراقبة الجاهزية عن سؤالين مختلفين، وتحتاج إلى كليهما لتشغيل خدمة موثوقة:

• هل خادمي قابل للوصول من الخارج؟ (المراقبة الخارجية / الصندوق الأسود) — هل يحصل عميل حقيقي عبر الإنترنت على استجابة سليمة؟
• هل خادمي سليم من الداخل؟ (المراقبة الداخلية / الصندوق الأبيض) — المعالج والذاكرة والقرص والخدمات الفردية مثل Nginx وMySQL أو عملية تطبيقك.

تكشف الفحوصات الخارجية الأعطال التي يراها المستخدمون. أما الفحوصات الداخلية فتكشف الأسباب — امتلاء القرص، أو عملية خارجة عن السيطرة، أو إرهاق ذاكرة الـ swap — غالباً قبل أن تتحول إلى انقطاع. يضبط هذا الدليل النوعين على خادم Linux افتراضي، بالإضافة إلى تنبيهات تصلك خلال ثوانٍ. تفترض الأوامر استخدام Ubuntu 22.04/24.04 أو Debian على خادم Skyline Cloud؛ عدّل أسماء الحزم لأنظمة AlmaLinux/RHEL.

الخطوة 1 — الفحوصات الخارجية للجاهزية

أبسط فحص خارجي هو طلب HTTP من جهاز غير خادمك. شغّل هذا من مضيف ثانٍ (أو من حاسوبك) للتأكد من أن الموقع يستجيب:

curl -sS -o /dev/null -w "HTTP %{http_code} in %{time_total}s\n" \
  https://example.com/

تبدو النتيجة السليمة هكذا: HTTP 200 in 0.184s. وللمراقبة المستمرة دون كتابة شيفرة، استخدم أداة مستضافة مثل UptimeRobot أو أداة ذاتية الاستضافة مثل Uptime Kuma. تبقي الاستضافة الذاتية بيانات مراقبتك داخل المملكة — وهو أمر مفيد للتوافق مع PDPL وضوابط الهيئة الوطنية للأمن السيبراني.

شغّل Uptime Kuma على خادم افتراضي منفصل وصغير (وليس أبداً على الخادم الذي يراقبه) باستخدام Docker:

docker run -d --restart=always \
  -p 3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma louislam/uptime-kuma:1

افتح http://<monitor-ip>:3001، وأنشئ حساب المدير، ثم Add New Monitor (إضافة مراقِب جديد):

• نوع المراقِب: HTTP(s)
• الرابط: https://example.com/health (استخدم نقطة فحص صحة خفيفة، لا الصفحة الرئيسية)
• فاصل نبضات القلب: 60 ثانية
• إعادة المحاولات: 2 (يتجنّب التنبيه عند خلل لحظي واحد)
• رموز الحالة المقبولة: 200-299

راقب دائماً نقطة /health مخصّصة تؤكد أن تطبيقك وقاعدة بياناته يعملان، لا مجرد أن خادم الويب يعيد صفحة.

الخطوة 2 — الصحة الداخلية عبر node_exporter وسكربت فحص

لخادم واحد لست بحاجة إلى منظومة Prometheus كاملة. يكفي سكربت قصير يشغّله cron أو مؤقّت systemd لتغطية الأساسيات. أنشئ ملف /usr/local/bin/health-check.sh:

#!/usr/bin/env bash
set -euo pipefail

THRESH_DISK=90      # نسبة مئوية
THRESH_MEM=90       # نسبة مئوية
WEBHOOK="https://hooks.example.com/your-webhook"

alert() {
  curl -fsS -X POST -H 'Content-Type: application/json' \
    -d "{\"text\":\"[$(hostname)] $1\"}" "$WEBHOOK" || true
}

# استخدام القرص على /
disk=$(df --output=pcent / | tail -1 | tr -dc '0-9')
[ "$disk" -ge "$THRESH_DISK" ] && alert "Disk at ${disk}% on /"

# استخدام الذاكرة
mem=$(free | awk '/Mem:/ {printf "%d", $3/$2*100}')
[ "$mem" -ge "$THRESH_MEM" ] && alert "Memory at ${mem}%"

# يجب أن تكون الخدمة الحرجة نشطة
for svc in nginx mysql; do
  systemctl is-active --quiet "$svc" || alert "Service $svc is DOWN"
done

اجعله قابلاً للتنفيذ واختبره:

sudo chmod +x /usr/local/bin/health-check.sh
sudo /usr/local/bin/health-check.sh

جدوِله عبر مؤقّت systemd، فهو أكثر موثوقية من cron من حيث التسجيل ومعالجة التشغيلات الفائتة. أنشئ /etc/systemd/system/health-check.service:

[Unit]
Description=Server health check

[Service]
Type=oneshot
ExecStart=/usr/local/bin/health-check.sh

وأنشئ /etc/systemd/system/health-check.timer:

[Unit]
Description=Run health check every 2 minutes

[Timer]

[Install]
WantedBy=timers.target

فعّله:

sudo systemctl daemon-reload
sudo systemctl enable --now health-check.timer
systemctl list-timers health-check.timer

وللحصول على مقاييس أغنى وسجل تاريخي، ثبّت Prometheus node_exporter الذي يعرض المعالج والذاكرة والقرص والشبكة كمقاييس على المنفذ 9100:

sudo apt update && sudo apt install -y prometheus-node-exporter
sudo systemctl enable --now prometheus-node-exporter
curl -s http://localhost:9100/metrics | head

اربطه بـ localhost أو قيّد المنفذ 9100 في جدارك الناري حتى لا تكون المقاييس متاحة للعموم:

sudo ufw allow from <monitor-ip> to any port 9100 proto tcp

الخطوة 3 — تنبيهات تصلك فعلاً

لا قيمة للتنبيه إلا إذا وصل بسرعة وعبر أكثر من قناة واحدة. اضبط قناتين على الأقل حتى لا يُسكتك تعطّل مزوّد واحد.

أرسِل بريد التنبيه عبر مُرحِّل SMTP مناسب — ولا تعتمد أبداً على بريد الخادم المراقَب نفسه، لأنه إن تعطّل لن يستطيع تحذيرك. استخدم استضافة البريد التجاري أو أي مزوّد SMTP. إليك تنبيهاً بريدياً بسيطاً عبر msmtp:

sudo apt install -y msmtp msmtp-mta
printf 'Subject: ALERT %s\n\n%s\n' "$(hostname)" "Disk high" \
  | msmtp -a default you@example.com

في Uptime Kuma، أضف الإشعارات من Settings → Notifications (بريد/SMTP، أو Slack، أو Telegram، أو webhook عام) واربطها بكل مراقِب.

الخطوة 4 — اضبط العتبات وتجنّب إرهاق التنبيهات

التنبيه السيّئ أسوأ من غيابه — إذ يتعلّم الناس تجاهله. اتّبع هذه القواعد:

• اشترط فشل فحصين أو أكثر قبل التنبيه (إعداد Retries) لتجاهل الأخطاء العابرة.
• نبّه على الأعراض التي يشعر بها المستخدم، مثل أخطاء HTTP 5xx أو ارتفاع زمن الاستجابة، لا على كل مقياس داخلي.
• اضبط عتبات منطقية: قرص 90٪، ذاكرة 90٪ بشكل مستمر، وزمن استجابة يفوق p95 الطبيعي لديك.
• أرسِل إشعار تعافٍ لتعرف متى انتهت المشكلة.
• راجِع التنبيهات شهرياً واحذف أو اضبط أي تنبيه «أطلق إنذاراً كاذباً».

تحقّق من المنظومة كاملة

اختبر مسار التنبيه من البداية إلى النهاية قبل أن تعتمد عليه. اخفض عتبة مؤقتاً أو أوقف خدمة غير حرجة:

sudo systemctl stop nginx        # يُطلق تنبيه توقّف الخدمة
# تأكد من وصول التنبيه، ثم:
sudo systemctl start nginx

إذا وصلك التنبيه إلى بريدك ومحادثتك خلال دقيقتين، فمراقبتك حقيقية. مسار التنبيه غير المُختبَر يساوي غياب المراقبة تماماً.

الخلاصة

لديك الآن فحوصات جاهزية خارجية، ومراقبة صحة داخلية عبر مؤقّت systemd وnode_exporter، وتنبيهات متعددة القنوات تحقّقت منها فعلاً. أبقِ مضيف المراقبة منفصلاً عن الخوادم التي يراقبها، واحتفظ بالبيانات داخل المملكة للتوافق مع PDPL وضوابط الأمن السيبراني، وأعد النظر في العتبات كلما نما حجم الزيارات.

هل تحتاج إلى خادم افتراضي موثوق وداخل المملكة لاستضافة تطبيقاتك ومنظومة مراقبتك — بدعم عربي محلي وتسعير شفّاف؟ أنشئ حساب Skyline Cloud وانشر خلال دقائق.