أغلب الوقت الضائع في عطلٍ يُنفَق في قراءة السجلّ الخطأ. فكلٌّ منها يجيب سؤالًا مختلفًا، واختيار الملفّ الصحيح أوّلًا يجعل الباقي سريعًا عادةً.

  • /var/log/nginx/error.log — خادم الويب لم يستطع أداء عمله: رفضٌ من الأعلى، أو منعُ إذن، أو ملفّ غير موجود.
  • /var/log/nginx/access.log — ما طُلب وما رُدّ به. وهنا تجد «متى».
  • /var/log/php8.3-fpm.log — عمّالٌ يموتون، ومشكلات التجمّعات.
  • سجلّ التطبيق — شفرتك أنت. وأثر التنفيذ يعيش هنا ولا مكان له غيره.

راقبه وأنت تُعيد إنتاج العطل

tail -f /var/log/nginx/error.log

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

وجِد شكل المشكلة

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

الأوّل يُظهر مزيج رموز الحالة. والثاني يسمّي العناوين التي تفشل مرتّبةً بالتكرار — وعنوانٌ واحد هو غالبًا أغلبها.

وضيّق بالوقت

sed -n '/04\/Sep\/2026:14:0/,/04\/Sep\/2026:14:2/p' access.log | grep ' 50'

وأوّل حدوثٍ هو المهمّ

اقرأ أوّل خطأ في الدفقة لا آخره. فالمتأخّرات نتائج عادةً — طابورٌ يتراكم، أو تجمّع اتّصالات ينفد — وإصلاح النتيجة لا يغيّر شيئًا.
وإن كان السجلّ فارغًا وقد فشل شيءٌ بوضوح، فالطلب لم يبلغ تلك الطبقة أصلًا. انتقل طبقةً إلى الخارج: غيابُ خطأ PHP يعني أن Nginx رفضه؛ وغيابُ قيدٍ في Nginx يعني أنه لم يصل إطلاقًا.