مراقبة سيرفر VPS: الأدوات والمقاييس المهمة

لماذا المراقبة ليست رفاهية بل خطّ دفاعك الأول؟

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

المراقبة الجيدة تقلب المعادلة: بدل أن يخبرك الزائر أن الموقع بطيء أو ساقط، يخبرك نظامك أنت أولًا — وغالبًا قبل أن تتحوّل المشكلة إلى عطل فعلي. القرص الذي وصل إلى 85% ينبّهك اليوم لتنظّفه، بدل أن يصل إلى 100% غدًا ويُسقط كل شيء. الذاكرة التي بدأت تتسرّب تظهر في منحنى صاعد بطيء قبل أسبوع من أن يقتل النظام عمليّتك المهمّة.

الفرق بين الاستضافة المشتركة والـVPS جوهري هنا أيضًا. في المشتركة، المزوّد يراقب الخادم نيابةً عنك. أمّا في الـVPS غير المُدار فأنت العين الوحيدة على صحّة الخادم. المراقبة هي الخطوة المنطقية التالية بعد أن جهّزت خادمك من الصفر (راجع إعداد أول سيرفر VPS من الصفر) وحصّنته؛ فبلا عين تراقب، يضيع كل ذلك الإعداد عند أول عطل صامت. لا أحد سيخبرك أن المعالج عند 100% منذ ساعتين، أو أن خدمة nginx سقطت، أو أن أحدهم يستهلك كل النطاق الشبكي. هذه المسؤولية هي ثمن الحرية التي يمنحها الـVPS، والمراقبة هي الأداة التي تجعل تلك المسؤولية محتملة.

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

الطبقات الثلاث للمراقبة

المراقبة الناضجة ليست أداة واحدة، بل ثلاث طبقات متكاملة، لكلٍّ منها دور لا تؤدّيه الأخرى:

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

المقاييس الأساسية: ماذا تراقب ولماذا؟

قبل اختيار الأدوات، يجب أن تفهم ماذا تقيس. ستّة مقاييس تشكّل العمود الفقري لصحّة أي خادم. كلٌّ منها يحكي قصّة مختلفة، وتفسيرها الصحيح هو ما يفرّق المراقبة المفيدة عن مجرّد أرقام على شاشة.

المخطّط أعلاه يلخّص المقاييس الستّة ومصدر كلٍّ منها داخل الخادم. الآن لنشرح كلًّا بعمق مع العتبات المقترحة للتنبيه. ابدأ بهذه الجدول المرجعي الذي سنفصّله بعده:

1) استخدام المعالج (CPU)

استخدام المعالج هو النسبة المئوية من قدرة المعالجة المشغولة فعليًا. لكن الرقم الإجمالي وحده مضلّل؛ المهمّ تفكيكه إلى مكوّناته. حين تشاهد top سترى توزيعًا مثل: us (وقت المستخدم — تطبيقاتك)، sy (وقت النظام — النواة)، wa (انتظار القرض/الإدخال والإخراج)، id (خامل). ارتفاع us يعني أن تطبيقاتك تعمل بكثافة (PHP، Node، قاعدة بيانات). ارتفاع wa (iowait) إشارة خطيرة: المعالج يجلس منتظرًا القرص، أي أن مشكلتك الحقيقية في القرص لا المعالج.

نقطة مهمّة في الـVPS: قد تكون أنويتك "مشتركة" مع جيران على نفس المضيف الفيزيائي (خصوصًا في الباقات الرخيصة). إذا رأيت st (steal time) مرتفعًا في top، فهذا يعني أن المُضيف يسرق وقت معالجك لصالح أجهزة افتراضية أخرى — مؤشّر على ازدحام المضيف، وحلّه غالبًا الترقية أو تغيير المزوّد.

2) الذاكرة (RAM) وSwap

أكثر مقياس يُساء فهمه. كثيرون يفزعون حين يرون الذاكرة "ممتلئة"، لكن لينكس يستخدم الذاكرة الحرّة عمدًا للتخزين المؤقت (buffers/cache) لتسريع النظام، ويحرّرها فورًا عند الحاجة. لذلك لا تنظر إلى "المستخدَم" بل إلى عمود available في free -h — وهو يمثّل ما يمكن للتطبيقات أخذه فعلًا. الخطر الحقيقي ليس امتلاء الذاكرة، بل أن يبدأ النظام باستخدام Swap بكثافة.

Swap هو مساحة على القرص يستخدمها النظام كذاكرة احتياطية حين تنفد الـRAM. المشكلة أن القرص أبطأ من الذاكرة بآلاف المرّات، فحين يبدأ Swap بالعمل بنشاط (swapping) يصبح الخادم بطيئًا جدًا. القاعدة: Swap موجود لا بأس، لكن Swap نشط باستمرار علامة على أنك تحتاج المزيد من الـRAM. والأسوأ من ذلك هو الـOOM Killer: حين تنفد الذاكرة والـSwap معًا، تقتل النواة أكبر عملية لتنقذ النظام — وقد تكون قاعدة بياناتك. راقب dmesg بحثًا عن Out of memory لاكتشاف هذا.

3) مساحة القرص وI/O

هنا مقياسان منفصلان يخلط بينهما المبتدئون:

• المساحة (Capacity): كم امتلأ القرص؟ يُقاس بـdf -h. القرص الممتلئ كارثة صامتة: قواعد البيانات تتوقّف عن الكتابة، السجلّات تفشل، والموقع قد ينهار دون رسالة خطأ واضحة. انتبه أيضًا إلى inodes (df -i)؛ قد تمتلك مساحة فارغة لكن تنفد منك الـinodes بسبب ملايين الملفّات الصغيرة، فيرفض النظام إنشاء ملفّات جديدة رغم وجود مساحة.
• الأداء/الإدخال والإخراج (I/O): كم القرص مشغول بالقراءة/الكتابة؟ يُقاس بـiostat. حتى لو كانت المساحة كافية، قد يكون القرص عنق الزجاجة إذا كان %util قريبًا من 100% أو await (زمن انتظار الطلب) مرتفعًا. هذا شائع مع أقراص HDD أو الباقات ذات حدود IOPS منخفضة.

4) الشبكة (الإدخال/الإخراج)

تراقب حركة المرور الداخلة (RX) والخارجة (TX). يهمّك هنا ثلاثة أمور: استهلاك النطاق (هل تقترب من حدّ باقتك الشهري؟)، عرض الحزمة اللحظي (هل وصلتك مشبَّعة فتبطئ كل شيء؟)، وعدد الاتصالات النشطة (ss -s). ارتفاع مفاجئ غير مبرّر في الترافيك قد يعني هجوم DDoS، أو زحف بوتات مكثّف، أو خادمك صار جزءًا من botnet بعد اختراقه. مراقبة الشبكة المنتظمة تكشف الشذوذ مبكرًا.

5) متوسّط الحِمل (Load Average) وتفسيره الصحيح

أكثر مقياس يُفسَّر خطأً على الإطلاق. متوسّط الحِمل ثلاثة أرقام (مثل 0.52, 0.48, 0.40) تمثّل عدد العمليات التي تعمل أو تنتظر على المعالج خلال آخر 1 و5 و15 دقيقة. الخطأ الشائع: ظنّ أن الرقم نسبة مئوية. ليس كذلك.

القاعدة الذهبية: قارن الحِمل بعدد أنوية المعالج. خادم بنواة واحدة، حِمله المثالي حول 1.0 (مشغول تمامًا دون طوابير). نفس الرقم 1.0 على خادم بـ4 أنوية يعني أنه مشغول 25% فقط — صحّة ممتازة. إليك الجدول المرجعي:

لمعرفة عدد أنويتك: nproc. القاعدة العملية: إذا تجاوز الحِمل لمدّة طويلة عدد الأنوية، فهناك طابور انتظار وبطء؛ راقب الأرقام الثلاثة معًا — إن كان رقم الدقيقة الواحدة أعلى بكثير من رقم الـ15 دقيقة فالحِمل يتصاعد الآن.

6) زمن التشغيل والتوفّر (Uptime)

هذا المقياس مختلف جوهريًا: لا يُقاس من داخل الخادم بل من خارجه. التوفّر يجيب عن السؤال البسيط الذي يهمّ عميلك: "هل الموقع يعمل الآن؟". تُقاس عادةً بنسبة مئوية (مثل 99.9%)، وتترجم إلى دقائق توقّف مسموح بها شهريًا. فهم هذه النسب ضروري لتقدير جودة استضافتك وأهدافك:

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

تحتاج موارد مخصّصة وتحكّمًا كاملًا؟

خطط VPS من wpressly بموارد مضمونة وصلاحية root، مُدارة وغير مُدارة، مع دعم عربي للإعداد والتأمين من اليوم الأول.

استعرض خطط VPS

الطبقة الأولى: المراقبة المحلية الفورية بالأوامر

هذه أدوات تُشغّلها يدويًا عبر SSH لتشخيص لحظي. لا تتطلّب تثبيتًا معقّدًا (معظمها مثبّت أو بتثبيت بسيط)، وهي خطّ دفاعك الأول عند حدوث مشكلة حيّة. إن لم تكن متمكّنًا من الاتصال عبر SSH بعد، فابدأ من أساسيات SSH ثم عُد.

top وhtop: من يستهلك المعالج والذاكرة؟

الأداة top مثبّتة افتراضيًا في كل توزيعة، وhtop نسخة محسّنة بألوان وتفاعل بالفأرة:

# أداة المراقبة الأساسية المثبّتة افتراضيًا
top

# داخل top: اضغط M للترتيب حسب الذاكرة، P للترتيب حسب المعالج، q للخروج

# تثبيت htop (أوضح وأسهل) على أنظمة Debian/Ubuntu
sudo apt update && sudo apt install -y htop

# على أنظمة AlmaLinux/Rocky/CentOS
sudo dnf install -y htop

# تشغيل htop
htop

داخل htop: الأشرطة العلوية تعرض كل نواة على حدة والذاكرة والـSwap، ويمكنك الضغط على F6 للترتيب، وF9 لإنهاء عملية متعطّلة (kill)، وF5 لعرض شجرة العمليات. هذه أسرع طريقة لاكتشاف العملية الجشعة.

free: حالة الذاكرة الحقيقية

# عرض الذاكرة بصيغة قابلة للقراءة (h = human-readable)
free -h

# المثال الناتج:
#               total        used        free      shared  buff/cache   available
# Mem:           3.8Gi       1.2Gi       180Mi        45Mi       2.4Gi       2.3Gi
# Swap:          2.0Gi       128Mi       1.9Gi

# تحديث مستمر كل ثانيتين لمراقبة التغيّر
free -h -s 2

كما ذكرنا: انظر إلى عمود available (2.3Gi هنا = صحّة جيّدة)، لا إلى used. ملاحظة الـbuff/cache المرتفع طبيعية تمامًا وليست مشكلة. أمّا ارتفاع used في Swap مع نشاط مستمر فعلامة على ضغط الذاكرة.

df وdu: مساحة القرص وأين ذهبت

# عرض المساحة المستخدمة لكل قسم بصيغة مقروءة
df -h

# فحص الـinodes (مهمّ مع ملايين الملفّات الصغيرة)
df -i

# تحديد أكبر المجلّدات داخل مسار (الترتيب التنازلي لأكبر 15)
sudo du -h --max-depth=1 / 2>/dev/null | sort -rh | head -n 15

# مثال شائع: العثور على أكبر ملفّات السجلّات المتضخّمة
sudo du -ah /var/log | sort -rh | head -n 10

تسلسل التشخيص النموذجي: df -h يكشف أيّ قسم ممتلئ، ثم du يحفر داخله ليجد المجلّد/الملف المسؤول. غالبًا سيكون /var/log (سجلّات متضخّمة) أو نسخ احتياطية منسيّة أو ملفّات مؤقّتة.

iostat وvmstat: أداء القرص والذاكرة

# تثبيت حزمة أدوات الأداء (تتضمّن iostat و mpstat)
sudo apt install -y sysstat      # على Debian/Ubuntu
# أو
sudo dnf install -y sysstat      # على AlmaLinux/Rocky

# iostat كل ثانيتين، مع نسب الاستخدام الموسّعة (-x)
iostat -x 2

# انظر في الناتج إلى:
#   %util   : نسبة انشغال القرص (قريب من 100% = عنق زجاجة)
#   await   : متوسّط زمن انتظار طلب القرص بالميلي ثانية
#   r/s, w/s: عمليات القراءة/الكتابة بالثانية (IOPS)

# vmstat كل ثانيتين: نظرة شاملة على الذاكرة والمعالج والقرص
vmstat 2

# في ناتج vmstat راقب:
#   si/so : دخول/خروج Swap (يجب أن يبقيا قرب الصفر)
#   wa    : نسبة انتظار المعالج للقرص (iowait)
#   r/b   : عمليات تنتظر التشغيل / محجوبة

ss وiftop: الشبكة والاتصالات

# ملخّص إحصائيات الاتصالات (TCP/UDP)
ss -s

# عرض كل اتصالات TCP المستمعة مع المنفذ والعملية
sudo ss -tulnp

# عدّ الاتصالات النشطة لكل عنوان IP (مفيد لكشف هجوم/زحف)
sudo ss -tn state established | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

# مراقبة عرض الحزمة اللحظي لكل اتصال (تثبيت iftop)
sudo apt install -y iftop
sudo iftop -i eth0

# إحصائيات استهلاك النطاق التاريخية (تثبيت vnstat)
sudo apt install -y vnstat
vnstat -d        # تقرير يومي
vnstat -m        # تقرير شهري (مهمّ لتتبّع حدّ الباقة)

uptime: الحِمل وزمن التشغيل بنظرة واحدة

# سطر واحد يلخّص: زمن التشغيل، عدد المستخدمين، ومتوسّط الحِمل
uptime
#  14:32:01 up 27 days,  3:14,  2 users,  load average: 0.52, 0.48, 0.40

# لمعرفة عدد الأنوية لمقارنته بالحِمل
nproc
#  4    => الحِمل 0.52 على 4 أنوية يعني استغلال ~13% (ممتاز)

جدول مرجعي: أوامر الفحص السريع

احفظ هذا الجدول؛ هو "صندوق الإسعافات الأوّلية" لأي مشكلة:

الطبقة الثانية: لوحات المراقبة المستمرة

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

netdata: لوحة لحظية فورية بتثبيت دقيقة

netdata هي أسهل طريقة للحصول على لوحة مراقبة احترافية. تعرض مئات المقاييس بدقّة الثانية الواحدة عبر واجهة ويب جميلة، بلا إعداد تقريبًا:

# التثبيت بأمر واحد عبر السكربت الرسمي (الطريقة الأبسط)
wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sh /tmp/netdata-kickstart.sh

# بعد التثبيت تعمل اللوحة على المنفذ 19999
# افتح: http://YOUR_SERVER_IP:19999
# (احمِ المنفذ بجدار حماية أو خلف reverse proxy — لا تتركه مكشوفًا)

# التحقّق من أن الخدمة تعمل
sudo systemctl status netdata

نقطة أمان مهمّة: لوحة netdata تعرض تفاصيل حسّاسة عن خادمك، فلا تترك المنفذ 19999 مفتوحًا للعالم. قيّده بـUFW على IP إدارتك، أو ضعه خلف reverse proxy مع مصادقة، أو استخدم Netdata Cloud. لتفاصيل تأمين المنافذ راجع تأمين وتحصين سيرفر VPS.

Glances: نظرة شاملة في الطرفية والمتصفّح

Glances أداة بايثون تجمع كل شيء (CPU، RAM، قرص، شبكة، عمليات، حاويات Docker) في شاشة واحدة، ويمكن تشغيلها في الطرفية أو كخادم ويب:

# التثبيت
sudo apt install -y glances        # Debian/Ubuntu
# أو عبر pip لأحدث إصدار
pip install glances

# تشغيل في الطرفية (يلوّن القيم: أخضر/برتقالي/أحمر حسب الخطورة)
glances

# تشغيل كخادم ويب للوصول من المتصفّح
glances -w
# افتح: http://YOUR_SERVER_IP:61208

Prometheus + Grafana: التأريخ والاحترافية

حين تحتاج بيانات تاريخية حقيقية، ولوحات قابلة للتخصيص، وتنبيهات متقدّمة، فإن ثنائي Prometheus + Grafana هو المعيار الصناعي. الفكرة: Prometheus قاعدة بيانات زمنية تجمع المقاييس وتخزّنها (يجمعها من node_exporter المثبّت على الخادم)، وGrafana أداة العرض التي ترسم لوحات تفاعلية جميلة من تلك البيانات. مقابل قوّتها، إعدادها أكثر تعقيدًا من netdata، وتناسب من يدير عدّة خوادم أو يريد احتفاظًا طويلًا بالبيانات.

Zabbix: المراقبة المؤسّسية الشاملة

Zabbix منصّة مراقبة متكاملة موجّهة للمؤسّسات وأساطيل الخوادم. تتميّز بنظام تنبيهات وقوالب وكشف تلقائي قويّ، لكنها الأثقل إعدادًا والأنسب لعشرات/مئات الخوادم لا لخادم واحد.

جدول المقارنة الحاسم بين الأدوات

كيف تختار؟

لا توجد أداة "أفضل" مطلقًا، بل أفضل لحالتك:

• خادم واحد، تريد البساطة: netdata (للوحة) + htop (للتشخيص) + UptimeRobot (للتوفّر). هذا المزيج يغطّي 90% من الاحتياجات بأقل جهد.
• عدّة خوادم، تريد التأريخ والتخصيص: Prometheus + Grafana + node_exporter + Alertmanager، مع UptimeRobot للتوفّر الخارجي.
• أسطول مؤسّسي: Zabbix أو Prometheus على نطاق واسع.

الطبقة الثالثة: المراقبة الخارجية للتوفّر

أعِد التأكيد على النقطة الجوهرية: أدوات الخادم الداخلية لا تستطيع تنبيهك حين يموت الخادم. لو سقط netdata مع الخادم، من سيرسل لك التنبيه؟ لا أحد. لهذا تحتاج عينًا خارجية مستقلّة تمامًا.

المراقبة الخارجية خدمة تعمل من خوادم في مواقع متعدّدة حول العالم، تطلب موقعك كل دقيقة (أو نصف دقيقة) وتتحقّق: هل يستجيب؟ هل رمز الحالة 200؟ كم استغرق؟ هل شهادة SSL سليمة؟ إن فشل الطلب من عدّة مواقع، تراسلك فورًا. وهي تحاكي تجربة الزائر الحقيقي، فترى ما يراه عميلك بالضبط — بما في ذلك أعطال الشبكة وDNS التي لا يراها الخادم نفسه.

نصيحة عملية: راقب أكثر من مجرّد "هل الصفحة تفتح". اضبط فحصًا على كلمة محتوى متوقّعة في الصفحة (keyword monitoring)، فقد يردّ الخادم برمز 200 لكن يعرض صفحة خطأ فارغة أو رسالة "تحت الصيانة". راقب أيضًا انتهاء شهادة SSL وانتهاء صلاحية الدومين — أعطال شائعة ومحرجة يسهل تفاديها.

تحتاج موارد مخصّصة وتحكّمًا كاملًا؟

خطط VPS من wpressly بموارد مضمونة وصلاحية root، مُدارة وغير مُدارة، مع دعم عربي للإعداد والتأمين من اليوم الأول.

استعرض خطط VPS

مراقبة السجلّات والخدمات

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

journalctl: السجلّ الموحّد لأنظمة systemd

# عرض كامل سجلّ النظام (مع الترقيم والتمرير)
journalctl

# سجلّ خدمة محدّدة فقط (مثلًا nginx)
journalctl -u nginx

# المتابعة الحيّة (مثل tail -f) — مفيد أثناء استكشاف مشكلة
journalctl -u nginx -f

# آخر ساعة فقط، ومستوى الخطأ فأعلى
journalctl --since "1 hour ago" -p err

# سجلّ منذ آخر إقلاع (مفيد لتشخيص مشكلة بعد إعادة تشغيل)
journalctl -b

# حجم السجلّ على القرص (وقد يكون سبب امتلائه!)
journalctl --disk-usage

# تنظيف السجلّات الأقدم من 7 أيّام لتحرير مساحة
sudo journalctl --vacuum-time=7d

ملفّات /var/log التقليدية

كثير من الخدمات تكتب في /var/log. هذه أهمّ الملفّات وما تجده فيها:

# متابعة حيّة لأخطاء nginx أثناء إعادة إنتاج المشكلة
sudo tail -f /var/log/nginx/error.log

# آخر 100 سطر من سجلّ المصادقة لرصد محاولات الدخول الفاشلة
sudo tail -n 100 /var/log/auth.log

# عدّ المحاولات الفاشلة لكل IP (كشف هجوم تخمين)
sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

تذكّر تفعيل logrotate (مفعّل افتراضيًا غالبًا) ليضغط السجلّات القديمة ويحذفها دوريًا — وإلّا ستملأ السجلّات قرصك بصمت، وهي من أكثر أسباب امتلاء القرص شيوعًا. ولوحة مثل CyberPanel تسهّل تصفّح سجلّات الويب من واجهة رسومية؛ راجع دليل CyberPanel.

مراقبة الخدمات وإعادة التشغيل التلقائي

ليس كافيًا أن تعرف أن خدمة سقطت؛ تريد أن تنهض تلقائيًا. أداة systemctl هي مفتاحك:

# حالة خدمة محدّدة (running / failed) مع آخر أسطر سجلّها
sudo systemctl status nginx

# قائمة بكل الخدمات الفاشلة حاليًا
systemctl --failed

# تفعيل بدء الخدمة تلقائيًا عند الإقلاع
sudo systemctl enable nginx

# إعادة تشغيل خدمة
sudo systemctl restart nginx

لإعادة التشغيل التلقائي عند التعطّل، أضف توجيهًا في وحدة systemd. أنشئ ملف override:

# إنشاء/تحرير override لخدمة (مثلًا nginx)
sudo systemctl edit nginx

# أضف هذه الأسطر داخل المحرّر ثم احفظ:
# [Service]
# Restart=always
# RestartSec=5

# أعد تحميل التهيئة لتفعيل التغيير
sudo systemctl daemon-reload
sudo systemctl restart nginx

بهذا، إن تعطّلت الخدمة لأي سبب، سيعيد systemd تشغيلها تلقائيًا بعد 5 ثوانٍ — حلٌّ بسيط يرفع توفّرك دون تدخّل بشري.

ضبط العتبات والتنبيهات: الفنّ لا العلم فقط

أداة المراقبة بلا تنبيهات مثل جهاز إنذار مطفأ. لكن التنبيهات سلاح ذو حدّين: قليلة جدًا فتفوتك المشاكل، وكثيرة جدًا فتصاب بـإرهاق التنبيهات (alert fatigue) — تبدأ بتجاهلها جميعًا، فتفوتك المهمّ بينها. الهدف: تنبيهات قليلة، دقيقة، قابلة للتنفيذ.

قنوات التنبيه

مبادئ ضبط العتبات بذكاء

1. ميّز التحذير عن الحرج: القرص عند 80% = تحذير (نظّفه في وقتك)، عند 90% = حرج (تصرّف الآن). افصل القناتين: التحذير على البريد، الحرج على تيليجرام/SMS.
2. اشترط المدّة لا اللحظة: لا تنبّه على ارتفاع CPU لثانية واحدة (طبيعي تمامًا). نبّه فقط إن تجاوز 80% لمدّة 5 دقائق متواصلة. هذا يلغي 90% من الإنذارات الكاذبة.
3. نبّه على ما تستطيع التصرّف حياله: كل تنبيه يجب أن يقابله إجراء واضح. إن لم تعرف ماذا تفعل عند وصوله، فلا تنبّه عليه.
4. استخدم التصعيد: إن لم يُحَلّ التحذير خلال ساعة، صعّده إلى حرج. وإن سقط الموقع، أرسل عبر القناة الأعلى صخبًا فورًا.

أنواع التنبيهات المقترحة

مثال cron لفحص بسيط يُنبّهك

لا تحتاج دائمًا لأداة ثقيلة. سكربت بسيط مع cron قد يكفي لفحص حرج كامتلاء القرص:

# أنشئ سكربت فحص المساحة: /usr/local/bin/disk-check.sh

#!/bin/bash
THRESHOLD=90
USAGE=$(df / | awk 'NR==2 {gsub("%",""); print $5}')
if [ "$USAGE" -ge "$THRESHOLD" ]; then
  MSG="تحذير: مساحة القرص على $(hostname) وصلت ${USAGE}%"
  # إرسال عبر بوت تيليجرام (استبدل TOKEN و CHAT_ID)
  curl -s -X POST "https://api.telegram.org/bot<TOKEN>/sendMessage" \
       -d chat_id="<CHAT_ID>" -d text="$MSG" >/dev/null
fi

# اجعله قابلًا للتنفيذ
sudo chmod +x /usr/local/bin/disk-check.sh

# أضفه إلى cron ليعمل كل 15 دقيقة
crontab -e

# أضف هذا السطر:
*/15 * * * * /usr/local/bin/disk-check.sh

هذا النمط (سكربت بسيط + cron + بوت تيليجرام) قابل للتكييف لأي فحص: حالة خدمة، الحِمل، عدد الاتصالات، أو أي مقياس تستطيع قراءته بأمر.

الاستجابة للحوادث: ماذا تفعل حين يرنّ الإنذار؟

التنبيه وصل. لا تهلع. اتبع تسلسلًا منهجيًا بدل القفز إلى حلول عشوائية:

1. أكّد المشكلة: هل هي حقيقية أم إنذار كاذب؟ تحقّق من قناتين (مثلًا المراقبة الخارجية + اتصال SSH يدوي).
2. حدّد النطاق: هل الخادم كلّه ساقط أم خدمة واحدة؟ هل المشكلة من الخادم أم من الشبكة/DNS؟ المراقبة الخارجية تساعد هنا.
3. اجمع الأدلّة قبل التغيير: التقط لقطة من htop، df -h, آخر أسطر السجلّ ذي الصلة. ستحتاجها للتحليل اللاحق.
4. طبّق الإصلاح الأقل تدخّلًا أولًا: أعد تشغيل الخدمة المتعطّلة قبل إعادة تشغيل الخادم كاملًا.
5. وثّق ما حدث: بعد الحلّ، اكتب: ماذا حدث، ما السبب، كيف حُلّ، وكيف تمنع تكراره. هذه "مراجعة ما بعد الحادث" تمنع الحادث القادم.

جدول troubleshooting: العَرَض ← السبب ← الحل

أخطاء شائعة في المراقبة (وكيف تتجنّبها)

• المراقبة بلا تنبيهات: لوحة جميلة لا ينظر إليها أحد عديمة الفائدة. التنبيه التلقائي هو الجوهر.
• الاعتماد على المراقبة الداخلية وحدها: كما كرّرنا، حين يموت الخادم تموت معه أدواته. المراقبة الخارجية ليست خيارًا.
• عتبات صارمة جدًا فتُغرقك بالإنذارات: فتعتاد تجاهلها، فتفوتك المشكلة الحقيقية. اضبط بحكمة.
• تجاهل الاتجاهات: المشكلة نادرًا ما تظهر فجأة؛ غالبًا تتصاعد. المنحنى الصاعد البطيء للذاكرة أو القرص تحذير مبكّر ثمين.
• عدم مراقبة inodes: قرص "فيه مساحة" قد يرفض إنشاء ملفّات لأن الـinodes نفدت. افحص df -i أيضًا.
• ترك لوحات المراقبة مكشوفة للعالم: netdata/Grafana مكشوفة على IP عام = تسريب معلومات للمهاجمين. أمّنها دائمًا.
• سوء فهم متوسّط الحِمل: قراءته كنسبة مئوية دون مقارنته بعدد الأنوية خطأ كلاسيكي يقود لقرارات خاطئة.
• عدم اختبار التنبيهات: اضبط تنبيهًا ثم تأكّد أنه يصلك فعلًا. تنبيه مكسور تكتشفه وقت الكارثة هو أسوأ توقيت.

نصائح خبير لمراقبة احترافية

• أنشئ خطّ أساس (baseline): اعرف كيف يبدو خادمك "في حالته الطبيعية" في أوقات الذروة والهدوء. الشذوذ يُكتشف فقط مقارنةً بالطبيعي.
• راقب من منظور المستخدم: زمن استجابة الصفحة الفعلي أهمّ من أرقام CPU المجرّدة. الزائر لا يهمّه حِملك، يهمّه السرعة.
• اجمع المقاييس في لوحة واحدة: لوحة Grafana تجمع CPU والذاكرة والقرص والشبكة وزمن الاستجابة في شاشة واحدة تختصر التشخيص لثوانٍ.
• احتفظ بالبيانات التاريخية: لا تستطيع تحليل اتجاه لا تملك بياناته. احتفظ بشهور من المقاييس لتقرّر متى تترقّى.
• اربط المراقبة بالنسخ الاحتياطي: المراقبة تكشف الكارثة، والنسخة الاحتياطية تنقذك منها. الاثنان معًا أو لا شيء.
• أتمت ما تستطيع: إعادة التشغيل التلقائي للخدمات، تنظيف السجلّات الدوري، والتنبيهات — كلّها تقلّل التدخّل اليدوي ليلًا.

الأسئلة الشائعة

ما الفرق بين المراقبة المحلية والخارجية ولماذا أحتاج الاثنين معًا؟ المراقبة المحلية (htop، netdata) تعمل داخل الخادم وتعطيك تفاصيل دقيقة عن موارده الداخلية، لكنها تموت معه إن سقط. المراقبة الخارجية (UptimeRobot) تعمل من خارجه وتكتشف سقوطه التامّ وأعطال الشبكة وDNS، لكنها لا ترى تفاصيله الداخلية. كلٌّ منهما يغطّي عمى الآخر، فتحتاج الاثنين معًا.

كيف أفسّر متوسّط الحِمل (load average) بشكل صحيح؟ قارنه دائمًا بعدد أنويتك (nproc). حِمل 1.0 على نواة واحدة = إشباع تامّ، لكن نفس الرقم على 4 أنوية = استغلال 25% فقط. القاعدة: إن تجاوز الحِمل عدد الأنوية لمدّة مستمرّة، فهناك طابور انتظار وبطء. وراقب الأرقام الثلاثة (1/5/15 دقيقة) لتعرف إن كان الحِمل يتصاعد أم يتراجع.

هل ارتفاع استخدام الذاكرة في لينكس مشكلة؟ ليس بالضرورة. لينكس يستخدم الذاكرة الحرّة عمدًا للتخزين المؤقت (cache) ويحرّرها عند الحاجة، لذا "الذاكرة المستخدمة" المرتفعة طبيعية. انظر بدلًا منها إلى عمود available في free -h. المشكلة الحقيقية تبدأ حين ينفد available ويبدأ Swap بالعمل بنشاط مستمرّ.

ما أفضل أداة مراقبة لمبتدئ على خادم واحد؟ المزيج الأبسط والأكثر فاعلية: netdata للوحة لحظية بتثبيت من دقيقة، htop للتشخيص اليدوي السريع، وUptimeRobot المجانية لمراقبة التوفّر من الخارج. هذا الثلاثي يغطّي معظم احتياجاتك دون تعقيد Prometheus/Grafana.

متى أحتاج Prometheus + Grafana بدل netdata؟ حين تدير أكثر من خادم، أو تريد الاحتفاظ بالبيانات التاريخية لشهور لتحليل الاتجاهات، أو تحتاج لوحات وتنبيهات مخصّصة ومتقدّمة. لخادم واحد يريد البساطة، netdata أكفأ بكثير. Prometheus + Grafana استثمار في التعقيد يُسدَّد عند النطاق الأكبر.

كيف أمنع امتلاء القرص بسبب السجلّات؟ فعّل logrotate (مفعّل افتراضيًا غالبًا) ليضغط السجلّات القديمة ويحذفها دوريًا، وحدّ حجم journald عبر SystemMaxUse في /etc/systemd/journald.conf أو نظّف يدويًا بـjournalctl --vacuum-time=7d. أضف فحص مساحة دوريًا عبر cron يُنبّهك عند 80% قبل أن تصل لـ100%.

ما معنى iowait المرتفع وكيف أعالجه؟ iowait (في top يظهر كـwa) يعني أن المعالج يجلس منتظرًا القرص بدل أن يعمل. ارتفاعه المستمرّ يعني أن القرص هو عنق الزجاجة لا المعالج. شخّصه بـiostat -x (راقب %util وawait)، وعالجه بترقية القرص (SSD/NVMe)، تقليل عمليات القرص الكثيفة، أو إضافة ذاكرة لتقليل الاعتماد على Swap.

كيف أضبط تنبيهات دون أن أغرق في الإنذارات الكاذبة؟ اشترط المدّة لا اللحظة (مثلًا CPU > 80% لخمس دقائق متواصلة)، وافصل التحذير عن الحرج بقناتين مختلفتين، ونبّه فقط على ما تستطيع التصرّف حياله. اختبر كل تنبيه بعد ضبطه للتأكّد من وصوله، وراجع تنبيهاتك دوريًا لإلغاء ما لم يعد مفيدًا.

هل أحتاج مراقبة إن كانت استضافتي مُدارة؟ إن كانت استضافة مُدارة بالكامل، فالمزوّد يراقب البنية التحتية. لكن يظلّ من الحكمة مراقبة التوفّر الخارجي لموقعك (UptimeRobot) ومراقبة أداء تطبيقك ذاته، فالمزوّد يراقب الخادم لا بالضرورة تطبيقك. أمّا في الـVPS غير المُدار فالمراقبة مسؤوليتك بالكامل.

كيف أراقب عدّة خوادم من مكان واحد؟ استخدم نظامًا مركزيًا: ثبّت node_exporter على كل خادم، واجمع Prometheus بياناتها كلّها في مكان واحد، واعرضها في لوحات Grafana موحّدة مع Alertmanager للتنبيهات. بديل أبسط: Netdata Cloud يجمع عدّة عقد netdata في لوحة واحدة. ولمراقبة التوفّر، أضف كل خادم/موقع كمراقب مستقلّ في UptimeRobot.

الخلاصة

المراقبة ليست مهمّة تُنجَز مرّة وتُنسى، بل عادة مستمرّة وثقافة تشغيل. ابدأ بالأساس: ثبّت netdata للوحة لحظية، أتقن أوامر htop وfree وdf وiostat للتشخيص اليدوي، وأضف UptimeRobot المجانية لمراقبة التوفّر من الخارج. افهم المقاييس الستّة وما يعنيه كلٌّ منها — خصوصًا متوسّط الحِمل مقارنةً بالأنوية، والفرق بين مساحة القرص وأدائه. اضبط تنبيهات قليلة ودقيقة وقابلة للتنفيذ، راقب سجلّاتك وخدماتك، وجهّز خطّة استجابة واضحة قبل أن تحتاجها. حين تفعل ذلك، تنقلب المعادلة لصالحك: تكتشف المشكلة وأنت مرتاح، لا وأنت تحت ضغط شكاوى العملاء.

والخطوة المنطقية التالية بعد المراقبة هي بناء خادم مهيّأ للمراقبة منذ البداية — وهنا يأتي دور استضافة VPS قويّة وموثوقة.

تحتاج موارد مخصّصة وتحكّمًا كاملًا؟

خطط VPS من wpressly بموارد مضمونة وصلاحية root، مُدارة وغير مُدارة، مع دعم عربي للإعداد والتأمين من اليوم الأول.

استعرض خطط VPS