أغلب الوقت الضائع في عطلٍ يُنفَق في قراءة السجلّ الخطأ. فكلٌّ منها يجيب سؤالًا مختلفًا، واختيار الملفّ الصحيح أوّلًا يجعل الباقي سريعًا عادةً.
- /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 يعني أنه لم يصل إطلاقًا.