لماذا لا تُعدّ مراقبة الخوادم بتنبيهات تلقائية أمرًا اختياريًا
موقع تجارة إلكترونية يتعطّل عند الساعة الثانية ظهرًا يوم ثلاثاء، يعني خسائر تتراوح بين 500€ و5000€ لمؤسسة صغيرة ومتوسطة. واجهة API خلفية تصل إلى حدّ التشبّع بصمت لمدة 3 ساعات تعني بيانات تالفة وعملاء محبطين. مراقبة الخوادم بتنبيهات تلقائية ليست رفاهية خاصة بفرق DevOps — بل هي تأمين حقيقي لأعمالك.
المشكلة؟ معظم المؤسسات الصغيرة والمتوسطة تُعدّ تنبيهاتها مرة واحدة، ثم تتلقّى كمًّا كبيرًا من الإنذارات الكاذبة، فتُعطّل الإشعارات، وتجد نفسها عمياء تمامًا في اليوم الذي يهمّ فعلًا.
هذا الدليل يوضّح لك كيفية بناء نظام تنبيهات موثوق ومُصنَّف حسب الأولوية وقابل للتنفيذ — وليس مجرد لوحة تحكم أخرى لا ينظر إليها أحد.
المقاييس الأربعة الحرجة التي يجب مراقبتها أولًا
قبل الحديث عن الأدوات، لنتحدث عن الاستراتيجية. مراقبة كل شيء تعني عدم مراقبة أي شيء. ركّز على هذه الركائز الأربع:
- التوفّر (Uptime): هل يستجيب خادمك؟ فحص HTTP كل 60 ثانية كحدّ أدنى
- استهلاك المعالج والذاكرة (CPU/RAM): عتبة تنبيه عند 80%، وعتبة حرجة عند 95%
- مساحة القرص: القاتل الصامت — أطلق تنبيهًا عند بلوغ 85% من الاستخدام
- زمن الاستجابة: إذا استغرقت واجهة API أكثر من ثانيتين، فسيغادر المستخدمون
# مثال سريع: فحص القرص مع تنبيه
DISK_USAGE=$(df -h / | awk 'NR==2 {print $5}' | sed 's/%//')
if [ "$DISK_USAGE" -gt 85 ]; then
curl -X POST https://votre-webhook.com/alerte \
-d '{"severity": "warning", "message": "Disque à '$DISK_USAGE'%"}'
fi
البنية المُوصى بها: حزمة المراقبة الخاصة بنا
في Otomy، إليك البنية التي ننشرها لعملائنا من المؤسسات الصغيرة والمتوسطة:
طبقة جمع البيانات: Netdata + Prometheus
يُثبَّت Netdata بأمر واحد ويوفّر مراقبة فورية دقيقة:
bash <(curl -Ss https://my-netdata.io/kickstart.sh)
بالنسبة للبنى التحتية الأكثر تعقيدًا (خوادم متعددة، Kubernetes)، يبقى Prometheus مع node_exporter المرجع الأساسي:
# prometheus.yml - الإعداد الأساسي
scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['serveur-prod:9100', 'serveur-staging:9100']
scrape_interval: 30s
طبقة التنبيهات: Alertmanager + n8n
هنا يحدث السحر الحقيقي. يتولّى Alertmanager الخاص بـ Prometheus إزالة التكرارات والتوجيه، لكننا نضيف n8n كمنسّق ذكي للتنبيهات:
- يُرسل Alertmanager حدث webhook إلى n8n
- يتحقّق n8n من درجة الخطورة والتوقيت (لا رسائل SMS في الثالثة صباحًا لمجرد تحذير)
- يوجّه n8n التنبيه إلى القناة المناسبة: Slack للتحذيرات، SMS/مكالمة هاتفية للحالات الحرجة
- يسجّل n8n التنبيه في Supabase لأغراض الأرشفة والتحليل
طبقة الإشعارات: التصنيف لتجنّب الإرهاق
إليك مصفوفة الإشعارات الخاصة بنا:
| درجة الخطورة | القناة | المهلة قبل التصعيد |
|---|---|---|
| معلومات | لوحة تحكم Grafana فقط | لا يوجد |
| تحذير | Slack #ops + بريد إلكتروني | 30 دقيقة ← SMS |
| حرج | SMS + Slack + مكالمة PagerDuty | 5 دقائق ← تصعيد إلى المسؤول |
| كارثي | مكالمة فورية + تسجيل حادثة في Supabase | فوري |
إعداد n8n: سير عمل التنبيهات الذكي
إليك سير عمل n8n الذي نستخدمه في بيئة الإنتاج:
العقدة 1 — Webhook Trigger: تستقبل حمولة البيانات من Alertmanager
العقدة 2 — Switch: توجّه حسب حقل severity
العقدة 3 — IF (الجدول الزمني): بين الساعة 22:00 والساعة 07:00، التنبيهات الحرجة والكارثية فقط هي التي تُرسَل عبر SMS
العقدة 4 — Claude AI (اختياري لكنه فعّال جدًا): نرسل سياق التنبيه إلى Claude AI عبر API للحصول على اقتراح تشخيص بلغة واضحة
{
"prompt": "Serveur prod-01, CPU à 97% depuis 10 min, RAM à 82%, 3 processus Node.js actifs. Quel est le diagnostic probable et l'action recommandée ?"
}
العقدة 5 — الإشعار: رسالة مُثراة تُرسَل إلى Slack مع تشخيص الذكاء الاصطناعي
العقدة 6 — Supabase Insert: تسجيل كامل لأغراض تحليل ما بعد الحادثة
الأخطاء القاتلة الخمسة التي يجب تجنّبها
1. عدم وجود عتبات تدريجية
لا تضع تنبيهًا واحدًا عند 90% من استخدام المعالج. بل أعدّ: 70% (معلومات)، 80% (تحذير)، 95% (حرج). السياق يغيّر كل شيء.
2. تنبيهات بدون سياق
رسالة "استخدام المعالج مرتفع" لا تفيد بشيء. يجب أن تتضمّن: أي خادم، أي قيمة، منذ متى، وما العمليات التي تستهلك الموارد.
3. عدم وجود فترات صمت (كبح)
أثناء عملية نشر مخطّطة، يجب أن تصمت تنبيهاتك. أعدّ نوافذ الصيانة في Alertmanager:
inhibit_rules:
- source_match:
alertname: 'DeploymentInProgress'
target_match_re:
severity: 'warning|info'
4. قناة إشعارات واحدة
إذا مرّ كل شيء عبر البريد الإلكتروني، فلا شيء يبدو عاجلًا. وإذا مرّ كل شيء عبر SMS، فسيُتجاهَل الجميع. صنّف حسب الأولوية.
5. عدم إجراء اختبارات أبدًا
كل شهر، أطلق تنبيهًا حرجًا وهميًا. إذا لم يستجب أحد خلال 5 دقائق، فنظامك معطّل.
المراقبة لمشاريع Vercel والحوسبة بدون خوادم (Serverless)
بالنسبة للتطبيقات المنشورة على Vercel، لا تنطبق المراقبة التقليدية. إليك منهجيتنا:
- Vercel Analytics لقياس زمن استجابة الدوال بدون خادم (Serverless Functions)
- Checkly أو UptimeRobot للمراقبة التركيبية (فحوصات HTTP خارجية)
- n8n يستعلم عن API الخاص بـ Vercel كل 5 دقائق لاكتشاف عمليات النشر الفاشلة
- تنبيهات Slack إذا تجاوز زمن الاستجابة عند الشريحة المئوية 95 (P95) حاجز 3 ثوانٍ
قائمة التحقّق قبل النشر
قبل اعتبار نظام المراقبة جاهزًا للعمل، تحقّق من كل نقطة:
- تثبيت Netdata أو Prometheus على كل خادم
- إعداد Alertmanager بثلاثة مستويات خطورة على الأقل
- اختبار سير عمل n8n من البداية إلى النهاية
- إعداد إشعارات Slack + SMS والتحقّق منها
- تخزين سجلات التنبيهات في Supabase
- إجراء اختبار تنبيه حرج مع الفريق
- توثيق دليل إجراءات (Runbook): لكل تنبيه إجراء محدّد
- جدولة مراجعة شهرية للتنبيهات
كلمة أخيرة
مراقبة الخوادم بتنبيهات تلقائية ليست مشروعًا يُنجَز مرة واحدة. إنها نظام حيّ يجب أن يتطوّر مع بنيتك التحتية. ابدأ ببساطة — Netdata + n8n + Slack — ثم أضف Prometheus وGrafana والتحليل بالذكاء الاصطناعي عندما تتوسّع بنيتك التحتية.
في Otomy، نُعدّ هذا النوع من الحزم التقنية للمؤسسات الصغيرة والمتوسطة في فرنسا والجزائر. نظام مراقبة مدروس جيدًا هو الفرق بين "تعرّضنا لعطل استمرّ 3 ساعات" و"حللنا المشكلة قبل أن يلاحظها أي شخص".