مشروع مصغر: نظام مراقبة متكامل يكتشف توقف السيرفر ويبلغك عبر الإيميل فوراً

في أي بيئة تشغيل حديثة، لا تكفي عملية نشر التطبيق بنجاح ثم تركه يعمل وحده. القيمة الحقيقية في عالم DevOps تبدأ عندما تبني آلية تلاحظ الأعطال تلقائياً وتبلغك فور حدوثها. لهذا السبب يعد هذا المشروع امتداداً عملياً لما شرحناه في مقال لماذا المراقبة حتمية في الـ DevOps؟ مقدمة في Prometheus و Grafana.

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

فكرة البنية المعمارية للمشروع

سنبني النظام على شكل طبقتين واضحتين. الطبقة الأولى هي سكربت فحص يقوم بطلب عنوان الخدمة عبر HTTP باستخدام curl. الطبقة الثانية هي مجدول تشغيل دوري، ويمكنك تنفيذه محلياً عبر Cron أو سحابياً عبر GitHub Actions.

اختيار GitHub Actions هنا ذكي لأنه يحررك من الاعتماد على نفس السيرفر الذي تراقبه. فإذا تعطل السيرفر بالكامل، ستظل منصة الجدولة الخارجية تعمل وتكتشف الانقطاع. وهذه نقطة معمارية مهمة جداً، لأن أداة المراقبة إذا عاشت داخل الخادم نفسه فقد تتوقف معه في نفس اللحظة.

لا تضع آلية المراقبة الحرجة على نفس السيرفر الذي تراقبه فقط. أفضل ممارسة هي وجود مراقب خارجي مستقل، لأن توقف النظام قد يشمل خدمة الجدولة نفسها أو الشبكة المحلية أو حتى النظام التشغيلي كاملاً.

المكونات التي سنستخدمها

• مستودع GitHub لحفظ السكربت.
• مهمة مجدولة عبر Workflow كل خمس دقائق.
• سكربت Bash يفحص الحالة ويرجع نتيجة واضحة.
• إرسال بريد عبر خدمة SMTP أو أكشن جاهز للبريد.
• أسرار مخزنة داخل GitHub Secrets لحماية بيانات البريد، كما ناقشنا في إدارة الأسرار (GitHub Secrets) لحماية كلمات المرور ومفاتيح الـ API في الأتمتة.

سكريبت الفحص الأساسي

جوهر المشروع هو فحص عنوان الخدمة وقراءة status code. إذا عاد الرد ضمن المجال 200-399 نعتبر الخدمة متاحة. أما في حالات الانقطاع، الفشل، أو تجاوز الزمن، فيجب إنهاء المهمة بحالة خطأ حتى تلتقطها منصة التشغيل وتنفذ خطوة الإرسال.

#!/usr/bin/env bash

URL="${CHECK_URL:-https://example.com/health}"
TIMEOUT="${TIMEOUT:-10}"

HTTP_CODE=$(curl -L -s -o /dev/null -w "%{http_code}" --max-time "$TIMEOUT" "$URL")
CURL_EXIT_CODE=$?

if [ "$CURL_EXIT_CODE" -ne 0 ]; then
  echo "ERROR: Request failed for $URL"
  exit 1
fi

if [ "$HTTP_CODE" -ge 200 ] && [ "$HTTP_CODE" -lt 400 ]; then
  echo "OK: $URL returned HTTP $HTTP_CODE"
  exit 0
else
  echo "DOWN: $URL returned HTTP $HTTP_CODE"
  exit 1
fi

من الأفضل أن تراقب مساراً صحياً مثل /health بدلاً من الصفحة الرئيسية فقط. هذا المسار يجب أن يختبر التطبيق وقاعدة البيانات أو التبعيات الحيوية إذا لزم الأمر، لأن نجاح الصفحة الرئيسية لا يعني دائماً أن التطبيق يعمل بكفاءة حقيقية.

بناء مهمة المراقبة في GitHub Actions

إذا كنت جديداً على هذا المفهوم فأنصحك بمراجعة مقدمة في GitHub Actions: كتابة أول مسار عمل (Workflow) ثم الجدولة (Cron Jobs) في GitHub Actions لتشغيل المهام الاحتياطية ليلاً. في مشروعنا سنستخدم جدولة قصيرة نسبياً لموازنة السرعة مع عدد مرات التنفيذ.

name: Server Uptime Monitor

on:
  schedule:
    - cron: "*/5 * * * *"
  workflow_dispatch:

jobs:
  monitor:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Run uptime check
        env:
          CHECK_URL: ${{ secrets.CHECK_URL }}
          TIMEOUT: 10
        run: |
          chmod +x monitor.sh
          ./monitor.sh

      - name: Send email on failure
        if: failure()
        uses: dawidd6/action-send-mail@v3
        with:
          server_address: ${{ secrets.SMTP_HOST }}
          server_port: ${{ secrets.SMTP_PORT }}
          username: ${{ secrets.SMTP_USERNAME }}
          password: ${{ secrets.SMTP_PASSWORD }}
          subject: "ALERT: Server appears down"
          to: ${{ secrets.ALERT_EMAIL_TO }}
          from: ${{ secrets.ALERT_EMAIL_FROM }}
          body: |
            Monitoring job detected a failure.
            Checked URL: ${{ secrets.CHECK_URL }}
            Repository: ${{ github.repository }}
            Workflow: ${{ github.workflow }}
            Run URL: https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}

المنطق هنا مباشر: إذا فشل السكربت، ستتحول المهمة إلى حالة فشل، ثم تعمل خطوة البريد باستخدام الشرط if: failure(). هذه من أبسط صور الاستجابة للحوادث المصغرة داخل Pipeline مراقبة مستقل.

كيف تخزن الأسرار بشكل آمن

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

• CHECK_URL
• SMTP_HOST
• SMTP_PORT
• SMTP_USERNAME
• SMTP_PASSWORD
• ALERT_EMAIL_TO
• ALERT_EMAIL_FROM

استخدم حساب بريد مخصص للتنبيهات فقط، وفعّل كلمات مرور التطبيقات أو رموز الوصول المخصصة إن كانت الخدمة تدعم ذلك. لا تعتمد على البريد الشخصي الرئيسي في مهام الأتمتة، لأن أي تسريب قد يتحول إلى حادث أمني واسع.

تحسينات هندسية تجعل النظام أكثر احترافية

1) تقليل الإنذارات الكاذبة

أحياناً يفشل الطلب مرة واحدة بسبب مشكلة شبكة عابرة. لذلك يمكنك تعديل السكربت لعمل ثلاث محاولات قبل إعلان الانقطاع. هذا يقلل false positives ويحسّن موثوقية التنبيه.

2) مراقبة أكثر من خدمة

بدلاً من عنوان واحد، يمكنك قراءة قائمة عناوين من ملف نصي أو YAML وتشغيل حلقة فحص. هذا مفيد إذا كان لديك frontend وbackend ولوحة إدارة منفصلة.

3) دمج المراقبة مع النشر المستمر

بعد تنفيذ deployment يمكنك تشغيل فحص صحة تلقائي كمرحلة تالية. هذا يربط المشروع بما تعلمته في ما هو الـ CI/CD؟ ولماذا نؤتمت عمليات اختبار ونشر الأكواد؟ والنشر المستمر (Continuous Deployment): رفع الكود الجديد إلى سيرفر Linux تلقائياً. إذا فشل الفحص بعد النشر، تعرف فوراً أن النسخة الجديدة سببت مشكلة.

4) الحاويات للمراقب نفسه

إذا أردت تشغيل النظام داخل بيئة خاصة بك، يمكنك حزم السكربت داخل Docker. وهذا منطقي خصوصاً إذا كنت تطبق ما ورد في مشكلة “الكود يعمل على جهازي فقط” وكيف يحلها Docker نهائياً؟ لأنك ستحصل على سلوك موحّد في كل بيئة تشغيل.

متى تحتاج للانتقال إلى أدوات أكبر؟

هذا المشروع ممتاز كبداية عملية، لكنه ليس بديلاً كاملاً عن المنصات المتقدمة. عندما يكبر عدد الخوادم أو تحتاج رسومًا بيانية وتنبيهات ذكية وتاريخاً زمنياً للمقاييس، يصبح من المنطقي الانتقال إلى Prometheus وGrafana أو إلى خدمات Uptime Monitoring متخصصة.

يمكنك اعتبار هذا النظام طبقة استجابة سريعة، بينما أدوات القياس الأوسع تضيف لك الرؤية التاريخية والتحليل العميق للأداء. وللتوسع لاحقاً، راجع تثبيت Prometheus لجمع مقاييس السيرفر ثم إعداد تنبيهات (Alerts) لإرسال رسالة إذا ارتفع استهلاك المعالج عن 90%.

الخلاصة

بضعة أسطر من Bash مع مهمة مجدولة في GitHub Actions تكفي لبناء نظام مراقبة مصغر لكنه فعال جداً. الفكرة الأساسية ليست مجرد إرسال بريد، بل بناء عقلية تشغيلية ترى الانقطاع كحدث يجب اكتشافه فوراً، لا كشكوى تأتي من المستخدم بعد فوات الأوان.

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