learn

فایل error_log چیست؟ خواندن خطا و کنترل حجم بدون قطع ثبت

راهنمای تشخیص خطا از روی زمان و مسیر، با تفکیک نمایش خطا از ثبت آن و حفظ محرمانگی اطلاعات لاگ.

فایل error_log می‌تواند محل ثبت پیام‌های خطای PHP یا یک برنامه باشد، اما نام و مسیر آن در همهٔ هاست‌ها یکسان نیست. همهٔ خطاهای سایت الزاماً در یک فایل جمع نمی‌شوند. وب‌سرور، PHP، برنامه و سرویس‌های دیگر ممکن است لاگ جدا داشته باشند.

ثبت خطا با نمایش خطا فرق دارد

در PHP، تنظیم display_errors نمایش پیام روی صفحه را کنترل می‌کند و log_errors به ثبت پیام مربوط است. خاموش بودن نمایش عمومی به معنی خاموش بودن لاگ نیست. برای سایت فعال، نمایش جزئیات خطا به بازدیدکننده مناسب نیست؛ مسیر فایل‌ها یا دادهٔ خصوصی ممکن است آشکار شود.

فایل error_log را چطور پیدا کنیم؟

ابتدا بخش لاگ دامنه در پنل و تنظیمات مجاز PHP را بررسی کنید. محل ثبت ممکن است کنار برنامه، در پوشهٔ غیرعمومی یا در لاگ سرویس باشد. اگر فایل را نمی‌بینید، یک فایل خالی هم‌نام نسازید و فرض نکنید ثبت فعال شده است؛ مسیر و مجوز نوشتن باید با پیکربندی هماهنگ باشند.

خواندن خطا بدون حدس عجولانه

  1. زمان رخداد و منطقهٔ زمانی سرور را با زمان آزمون تطبیق دهید.
  2. نوع پیام، متن خطا، مسیر فایل و شمارهٔ خط را بخوانید.
  3. پیام‌های قبل و بعد را برای زنجیرهٔ خطا بررسی کنید.
  4. تغییر اخیر قالب، افزونه یا نسخهٔ PHP را با شواهد مقایسه کنید.
  5. پس از اصلاح، همان درخواست را دوباره آزمایش و لاگ تازه را کنترل کنید.

هشدار Deprecated لزوماً علت توقف صفحه نیست؛ Fatal error اهمیت متفاوتی دارد. شمارهٔ خط محل گزارش را نشان می‌دهد و همیشه منشأ اصلی مشکل نیست.

بخش Errors در سی‌پنل

در Metrics، ابزار Errors تا ۳۰۰ ورودی اخیر لاگ خطای وب‌سرور را نشان می‌دهد، نه تضمیناً تمام خطاهای PHP یا برنامه. برای رخداد قدیمی یا سرویس دیگر، لاگ مربوط را جدا بررسی کنید. دامنهٔ این ابزار در مستند رسمی Errors آمده است.

ابزار Errors سی‌پنل برای مشاهدهٔ ورودی‌های اخیر خطا
نمونهٔ رابط قدیمی؛ نام و جای دکمه‌ها در نسخهٔ فعلی ممکن است متفاوت باشد. راهنمای بازبینی‌شدهٔ متن را مبنا قرار دهید.

حجم زیاد را با قطع دسترسی درمان نکنید

مجوز 000 یا قطع ثبت، علت خطا را حل نمی‌کند و شواهد تشخیصی را از بین می‌برد. ابتدا نمونهٔ لازم را خصوصی نگه دارید، علت تکرار را رفع کنید و گردش و نگهداری لاگ را با میزبان تنظیم کنید. حذف بی‌برنامهٔ فایل باز هم ممکن است فضا را فوراً آزاد نکند؛ وضعیت سرویس و فایل باید مشخص باشد.

لاگ وردپرس و محرمانگی

وردپرس با WP_DEBUG_LOG می‌تواند در محیط عیب‌یابی، فایل debug.log یا مسیر مشخص دیگری بنویسد؛ این قابلیت به WP_DEBUG وابسته است. نمایش عمومی را فعال نگذارید و فایل لاگ را قابل‌دانلود عمومی نکنید. پیش از ارسال نمونه برای پشتیبانی، رمز، توکن و دادهٔ شخصی را حذف کنید.

تنظیمات رسمی PHP و راهنمای عیب‌یابی وردپرس مرجع تفکیک ثبت و نمایش‌اند. پس از تشخیص، حالت عیب‌یابی موقت را به تنظیم عملیاتی مناسب برگردانید.

مطالعهٔ مرتبط

بازبینی فنی: ۲۷ مهر ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.

مطالب مرتبط

ارسال نظر

فهرست مطالب