الدليل الكامل لقراءة سجلات السيرفر (Server Logs): تشخيص أعطال NGINX وPM2 وsystemd باستخدام journalctl في 2026

مقدمة

تُعدّ قراءة سجلات السيرفر (Server Logs) أهم مهارة يمتلكها مدير الخوادم لتشخيص الأعطال بسرعة. فعند توقف موقعك أو ظهور خطأ مثل 502، لا يكون التخمين حلًّا، بل الإجابة الحقيقية موجودة دائمًا في السجلات.

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

ما هي سجلات السيرفر (Server Logs)؟

سجلات السيرفر هي ملفات وسجلات يكتب فيها النظام والخدمات كل ما يحدث: بدء الخدمات وإيقافها، الأخطاء، الطلبات، ومحاولات الدخول. إنها بمثابة الصندوق الأسود لخادمك، وقراءتها الصحيحة تكشف سبب أي عطل بدقة.

أنواع السجلات في Linux

• سجل النظام (journald): يجمعه systemd ويُقرأ بـ journalctl.
• سجلات الخدمات: مثل NGINX وMySQL.
• سجلات المصادقة: لمحاولات الدخول عبر SSH.
• سجل النواة (Kernel): لأحداث العتاد والنظام.

ما هو journalctl؟

journalctl هو الأداة الرسمية لقراءة سجلات النظام التي يجمعها journald ضمن systemd. يتيح لك تصفية سجلات السيرفر حسب الخدمة والوقت والأولوية، ما يجعله نقطة البداية المثالية لأي تشخيص.

ويمكنك الاطّلاع على التوثيق الرسمي من دليل journalctl الرسمي.

أساسيات قراءة سجلات السيرفر بـ journalctl

ابدأ بعرض أحدث السجلات ثم انتقل إلى نهايتها مباشرةً:

journalctl
journalctl -e
journalctl -b
journalctl -r

قراءة سجل خدمة معيّنة (-u)

لعزل مشكلة خدمة محددة، استخدم الخيار -u باسم الوحدة:

journalctl -u nginx
journalctl -u mariadb -e
journalctl -u ssh

متابعة السجلات لحظيًا (-f)

لمشاهدة السجلات وهي تُكتب مباشرةً أثناء إعادة إنتاج المشكلة:

journalctl -f
journalctl -u nginx -f

التصفية حسب الوقت

ركّز على الفترة الزمنية التي حدث فيها العطل لتقليل الضجيج:

journalctl --since today
journalctl --since 09:00 --until 12:00

التصفية حسب الأولوية (-p)

لعرض الأخطاء فقط وتجاهل الرسائل العادية، صفِّ حسب مستوى الأولوية:

journalctl -p err -b
journalctl -p warning

تشخيص أعطال NGINX من السجلات

عند مشكلة في NGINX، ابدأ بسجل الخدمة ثم فحص صحة الإعدادات:

journalctl -u nginx -e
nginx -t

ولفهم إعداد NGINX كوسيط عكسي، راجع: شرح NGINX Reverse Proxy: كيف يربط الدومين بتطبيقك الداخلي باستخدام proxy_pass؟ الدليل الكامل 2026.

سجلات NGINX: access و error

• access: يسجّل كل طلب وارد (IP، المسار، رمز الحالة).
• error: يسجّل الأخطاء مثل upstream timed out وconnect failed.
• ابحث في سجل الأخطاء عن السطر المقترن بوقت ظهور العطل.

تشخيص أعطال PM2 وتطبيقات Node.js

لتطبيقات Node.js التي تعمل عبر PM2، اجمع بين سجلات PM2 وjournald:

pm2 logs
pm2 logs my-api
journalctl -u pm2-root -e

تشخيص أعطال systemd والخدمات الفاشلة

لمعرفة الخدمات التي فشلت وسبب فشلها:

systemctl --failed
systemctl status myapp
journalctl -u myapp -p err -b

ولفهم إدارة الخدمات، راجع: شرح systemd في Linux: كيفية إنشاء Service تعمل تلقائيًا عند إقلاع السيرفر باستخدام systemctl (Enable وDisable) – الدليل الكامل 2026.

من خطأ 502 إلى السبب الجذري

خطأ 502 يعني أن NGINX لم يتلقَّ ردًا صالحًا من الخدمة الخلفية. تتبّع السبب عبر السجلات بالترتيب: سجل NGINX، ثم سجل التطبيق الخلفي، ثم حالة الخدمة.

وللحل التفصيلي لخطأ 502 بعد إعادة التشغيل، راجع: حل مشكلة 502 Bad Gateway بعد إعادة تشغيل السيرفر (NGINX وPHP-FPM وNode.js): الدليل الكامل للتشخيص والإصلاح في 2026.

أوامر journalctl متقدمة

journalctl -k
journalctl -u nginx -o json
journalctl --disk-usage

إدارة حجم سجلات السيرفر

مع الوقت تكبر سجلات السيرفر وتستهلك مساحة القرص. راقب حجمها ونظّفها بأمان بالاحتفاظ بآخر فترة فقط.

تصدير السجلات ومشاركتها

يمكنك حفظ جزء من السجل في ملف لمشاركته مع الدعم الفني دون كشف بيانات حساسة، مع تحديد الخدمة والفترة الزمنية.

أشهر رسائل الخطأ ومعناها

Permission denied

تعني أن الخدمة لا تمتلك صلاحية للوصول إلى ملف أو مجلد.

No such file or directory

تشير إلى أن الملف أو المسار غير موجود.

Address already in use

تعني أن منفذ الخدمة مستخدم من قبل خدمة أخرى.

يمكن التأكد من ذلك باستخدام:

ss -tlnp

Connection refused

تعني أن التطبيق الخلفي لا يعمل أو لا يستمع على المنفذ الصحيح، وهي من أكثر أسباب ظهور خطأ 502 Bad Gateway.

Failed to start

تشير إلى أن الخدمة لم تتمكن من البدء بسبب خطأ في الإعدادات أو التطبيق.

تفعيل السجلات الدائمة (Persistent Logs)

افتراضيًا قد تُحفظ سجلات السيرفر في الذاكرة فقط وتُفقد بعد إعادة التشغيل — وهذا يعني ضياع الدليل وقت الحاجة إليه بالضبط. فعّل الاحتفاظ الدائم لتبقى السجلات بعد كل إقلاع:

mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald

بعدها يمكنك مراجعة سجلات الإقلاعات السابقة بسهولة عبر الخيار -b -1 للإقلاع السابق.

تحليل سجل access وأكواد الحالة

لا يقتصر تشخيص الأعطال على سجل الأخطاء؛ فسجل الوصول (access) يكشف الكثير عن سلوك موقعك. ابدأ بمعرفة توزيع أكواد الحالة، فارتفاع مفاجئ في 404 أو 502 يدلّ على مشكلة حقيقية:

awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

ولمعرفة أكثر المسارات التي تُنتج أخطاء، صفِّ السطور حسب الكود ثم اجمعها حسب المسار — عندها تعرف تحديدًا أي صفحة تسبّب المشكلة.

سجلات قواعد البيانات (MySQL / MariaDB)

كثير من أعطال المواقع مصدرها قاعدة البيانات لا الخادم نفسه. راجع سجل الخدمة لتكتشف الاستعلامات البطيئة أو فشل الاتصال:

journalctl -u mariadb -e
journalctl -u mysql -p err -b

ابحث عن رسائل مثل Too many connections أو Aborted connection — فهي تشير إلى ضغط أو إعدادات تحتاج ضبطًا.

سجلات SSH ومحاولات الدخول المشبوهة

تكشف سجلات السيرفر أيضًا محاولات الاختراق. راقب محاولات الدخول الفاشلة لتكتشف هجمات القوة الغاشمة مبكرًا:

journalctl -u ssh -p warning -b
journalctl -u sshd | grep -i "failed password"

إن رأيت عشرات المحاولات من عنوان واحد، فهذا مؤشر واضح على هجوم — عندها فعّل الحظر التلقائي وقيّد المنفذ.

سيناريو عملي: الموقع متوقف — ماذا تفعل؟

طبّق هذا التسلسل كما هو، فهو يغطي 90% من الحالات ويوصلك إلى السبب في دقائق:

# 1) هل هناك خدمة فاشلة؟
systemctl --failed

# 2) ماذا يقول الوسيط (NGINX)؟
journalctl -u nginx -e

# 3) ماذا يقول التطبيق الخلفي؟
journalctl -u myapp -b -p err

# 4) هل المنفذ يعمل؟
ss -tlnp

# 5) هل القرص ممتلئ؟
df -h

في معظم الحالات ستجد الإجابة في الخطوتين الأولى والثانية؛ فقراءة سجلات السيرفر بترتيب منطقي أسرع بكثير من التخمين العشوائي.

أتمتة التنبيه عند الأخطاء

لا تنتظر شكوى العميل لتكتشف العطل. اجعل الخادم يخبرك بنفسه عبر فحص دوري للأخطاء الحرجة وإرسال تنبيه:

• فحص دوري بـ journalctl -p err --since "10 min ago" عبر Cron.
• ربط النتيجة بتنبيه بريد أو ويب هوك.
• استخدام أدوات جاهزة مثل lnav أو Grafana Loki للبنى الأكبر.
• مراقبة التوقّف عبر أداة Uptime خارجية.

أفضل الممارسات لقراءة سجلات السيرفر

• ابدأ دائمًا بتحديد الوقت والخدمة لتقليل الضجيج.
• استخدم الأولوية err للتركيز على الأخطاء أولًا.
• اقرأ من الأحدث للأقدم قرب وقت العطل.
• فعّل الاحتفاظ بالسجلات بشكل دائم.
• راقب حجم السجلات ونظّفها دوريًا.

واجعل قراءة السجلات جزءًا من فحص صحة الخادم، راجع: الدليل الكامل لفحص صحة السيرفر (Server Health Check): أهم أوامر Linux لتشخيص الأعطال ومراقبة الأداء في 2026.

أخطاء شائعة عند قراءة السجلات

• قراءة السجل كاملًا دون تصفية بالوقت أو الأولوية.
• تجاهل سجل الخدمة الخلفية والاكتفاء بسجل NGINX.
• عدم تفعيل السجلات الدائمة ففقدانها بعد الإقلاع.
• إهمال حجم السجلات حتى يمتلئ القرص.

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

إلى جانب journalctl، تساعد أدوات مثل lnav وGrafana Loki وELK Stack على تجميع سجلات السيرفر من عدة خوادم وتحليلها بصريًا، وهي مفيدة للبنى الكبيرة والمتعددة الخوادم.

لماذا مرام هوست لإدارة خوادمك؟

توفّر مرام هوست خوادم VPS وDedicated بصلاحيات Root كاملة تتيح لك الوصول إلى سجلات السيرفر وتحليلها بحرية، مع دعم فني عربي يساعدك في تشخيص الأعطال عند الحاجة.

الخلاصة

باختصار، إتقان قراءة سجلات السيرفر عبر journalctl يحوّل تشخيص الأعطال من تخمين إلى منهج دقيق: حدّد الخدمة والوقت والأولوية، واقرأ السجل، وستجد السبب. اجعل قراءة سجلات السيرفر عادةً، وستحل مشاكل NGINX وPM2 وsystemd في دقائق.