راهنمای کامل خواندن لاگ خطا و پیدا کردن علت واقعی مشکلات سرور

آموزش گام‌به‌گام خواندن لاگ خطا در سرورهای لینوکسی: از پیدا کردن فایل‌های لاگ تا ترجمه پیام‌های خطا به علت اصلی. مناسب برای مدیران وب‌سایت و توسعه‌دهندگان.

۶ دقیقه به‌روزرسانی ۱۴ مرداد ۱۴۰۵

وقتی وب‌سایت شما از کار می‌افتد یا خطای ۵۰۰ نشان می‌دهد، اولین جایی که باید به آن مراجعه کنید لاگ خطا است. اما مشکل اینجاست: بسیاری از مدیران وب‌سایت نمی‌دانند دقیقاً کجا باید لاگ‌ها را پیدا کنند یا چطور یک پیام خطای مبهم مثل Connection refused را به علت واقعی ترجمه کنند. در این مقاله، یاد می‌گیرید که چطور لاگ خطا را در سرورهای لینوکسی پیدا کنید، ساختار آن را بخوانید و رایج‌ترین خطاها را به راه‌حل تبدیل کنید.

۱. لاگ خطا کجاست؟ مسیرهای استاندارد در سرور لینوکس

بسته به نوع سرویس، لاگ خطا در مسیرهای متفاوتی ذخیره می‌شود. رایج‌ترین مکان‌ها عبارتند از:

  • لاگ‌های سیستمی: /var/log/syslog یا /var/log/messages (بسته به توزیع لینوکس)
  • لاگ وب‌سرور Apache: /var/log/apache2/error.log (در اوبونتو/دبیان) یا /var/log/httpd/error_log (در CentOS/RHEL)
  • لاگ وب‌سرور Nginx: /var/log/nginx/error.log
  • لاگ MySQL/MariaDB: /var/log/mysql/error.log
  • لاگ PHP-FPM: /var/log/php-fpm/error.log یا /var/log/php7.4-fpm.log

برای دسترسی به این فایل‌ها معمولاً نیاز به دسترسی root یا sudo دارید. با دستور زیر می‌توانید آخرین ۵۰ خط از لاگ خطا را ببینید:

sudo tail -n 50 /var/log/apache2/error.log

۱.۱. چطور لاگ‌های خاص یک سرویس را پیدا کنیم؟

اگر سرویس خاصی مثل Postfix یا Dovecot دارید، مسیر لاگ ممکن است متفاوت باشد. بهترین راه استفاده از دستور journalctl در سیستم‌های systemd است:

sudo journalctl -u nginx.service --since "1 hour ago"

این دستور لاگ‌های سرویس Nginx را در یک ساعت گذشته نشان می‌دهد. برای لاگ خطاهای MySQL هم می‌توانید از mysqladmin استفاده کنید:

sudo mysqladmin -u root -p variables | grep log_error

۲. ساختار یک پیام لاگ خطا: چه اطلاعاتی در آن نهفته است؟

یک خط معمولی از لاگ خطا در Apache به این شکل است:

[Mon Oct 21 14:23:45.123456 2025] [php:notice] [pid 12345] [client 192.168.1.1:54321] PHP Notice:  Undefined variable: foo in /var/www/html/index.php on line 15

این پیام شامل بخش‌های زیر است:

  • تاریخ و زمان: دقیقاً مشخص می‌کند خطا چه زمانی رخ داده است.
  • سطح خطا: مثل notice، warning، error، critical. سطح critical جدی‌تر است.
  • شناسه فرآیند (PID): برای ردیابی درخواست‌های هم‌زمان مفید است.
  • آدرس IP کلاینت: نشان می‌دهد کدام کاربر خطا را تجربه کرده است.
  • متن خطا: توضیح دقیق مشکل.

۲.۱. سطوح خطا را بشناسید

در لاگ‌های سیستمی و وب‌سرور، سطوح خطا از کم‌اهمیت به پراهمیت به این ترتیب هستند:

  1. debug: اطلاعات برای اشکال‌زدایی، معمولاً نادیده گرفته می‌شود.
  2. info: رویدادهای عادی مثل شروع سرویس.
  3. notice: رویدادهای مهم اما غیر بحرانی.
  4. warning: هشدار، ممکن است به مشکل تبدیل شود.
  5. error: خطا، سرویس هنوز کار می‌کند اما بخشی از آن مختل شده است.
  6. critical: بحرانی، سرویس ممکن است از کار بیفتد.
  7. alert: نیاز به اقدام فوری.
  8. emergency: سیستم در شرف فروپاشی.

برای عیب‌یابی معمولاً روی سطوح error و بالاتر تمرکز کنید.

۳. ترجمه پیام‌های خطا به علت واقعی

بسیاری از پیام‌های لاگ خطا مبهم هستند. در اینجا رایج‌ترین خطاها و علت واقعی آنها را بررسی می‌کنیم.

۳.۱. خطای "Connection refused" در MySQL

پیام: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)

علت واقعی: سرویس MySQL اجرا نمی‌شود یا سوکت خراب است. ابتدا با دستور زیر وضعیت سرویس را بررسی کنید:

sudo systemctl status mysql

اگر سرویس فعال نبود، آن را راه‌اندازی کنید:

sudo systemctl start mysql

اگر سرویس فعال بود اما خطا ادامه داشت، احتمالاً فایل سوکت حذف شده است. با دستور زیر مسیر سوکت را پیدا کنید:

mysql -u root -p -h 127.0.0.1

اگر این کار کرد، مشکل از سوکت است. فایل سوکت را دوباره ایجاد کنید یا در تنظیمات MySQL مسیر درست را مشخص کنید.

۳.۲. خطای "Permission denied" در لاگ وب‌سرور

پیام: AH00558: apache2: Could not reliably determine the server's fully qualified domain name

علت واقعی: این یک هشدار است، نه خطای بحرانی. معمولاً به دلیل عدم تنظیم ServerName در فایل کانفیگ Apache رخ می‌دهد. برای رفع آن، خط زیر را به /etc/apache2/apache2.conf اضافه کنید:

ServerName localhost

سپس Apache را ری‌استارت کنید:

sudo systemctl restart apache2

۳.۳. خطای "PHP Fatal error: Allowed memory size exhausted"

پیام: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/wp-admin/includes/media.php on line 123

علت واقعی: حافظه اختصاص داده شده به PHP (معمولاً ۱۲۸ مگابایت) برای اجرای اسکریپت کافی نیست. این خطا در وردپرس هنگام آپلود فایل‌های حجیم رایج است. برای رفع آن، مقدار memory_limit را در فایل php.ini افزایش دهید:

memory_limit = 256M

سپس سرویس PHP-FPM را ری‌استارت کنید:

sudo systemctl restart php7.4-fpm

۳.۴. خطای "SSL: error:0A000086:SSL routines::certificate verify failed"

پیام: SSL: error:0A000086:SSL routines::certificate verify failed

علت واقعی: گواهی SSL سرور شما منقضی شده، نامعتبر است یا زنجیره گواهی کامل نیست. با دستور زیر تاریخ انقضای گواهی را بررسی کنید:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

اگر گواهی منقضی شده است، آن را تمدید کنید. اگر مشکل از زنجیره گواهی است، مطمئن شوید فایل‌های fullchain.pem و privkey.pem به درستی در کانفیگ وب‌سرور قرار گرفته‌اند.

۴. اشتباهات رایج در خواندن لاگ خطا

بسیاری از مدیران تازه‌کار مرتکب اشتباهات زیر می‌شوند:

  • نگاه کردن به لاگ‌های اشتباه: مثلاً به جای لاگ خطای Apache، به لاگ دسترسی (access log) نگاه می‌کنند. لاگ دسترسی فقط درخواست‌ها را ثبت می‌کند، نه خطاها را.
  • نادیده گرفتن زمان وقوع خطا: خطاهای قدیمی ممکن است دیگر مرتبط نباشند. همیشه لاگ‌های مربوط به زمان بروز مشکل را بررسی کنید.
  • تفسیر نادرست سطوح خطا: یک warning را بحرانی فرض کردن و وقت تلف کردن روی آن.
  • عدم استفاده از ابزارهای فیلتر: با دستور grep می‌توانید لاگ را بر اساس کلمه کلیدی فیلتر کنید. مثلاً:
sudo grep "PHP Fatal error" /var/log/apache2/error.log

۵. ابزارهای پیشرفته برای تحلیل لاگ خطا

برای پروژه‌های بزرگ، خواندن دستی لاگ‌ها غیرممکن است. از ابزارهای زیر استفاده کنید:

  • Logwatch: یک ابزار خط فرمان که خلاصه‌ای از لاگ‌ها را به صورت روزانه ایمیل می‌کند. نصب و تنظیم آن ساده است:
sudo apt install logwatch
sudo logwatch --detail High --mailto admin@example.com --service all --range today
  • GoAccess: یک تحلیل‌گر لاگ وب‌سرور با رابط کاربری ترمینال. می‌توانید لاگ‌های دسترسی و خطا را به صورت تعاملی ببینید.
  • Fail2ban: برای شناسایی حملات brute-force از روی لاگ خطا و مسدود کردن خودکار IPهای متخلف.

۶. نکته نهایی: لاگ‌ها را به صورت خودکار پایش کنید

منتظر نمانید تا کاربران از مشکل گزارش دهند. با ابزارهایی مثل Prometheus و Grafana یا حتی یک اسکریپت ساده bash، لاگ‌ها را به صورت خودکار پایش کنید. مثلاً اسکریپت زیر هر ۵ دقیقه لاگ خطا را بررسی می‌کند و در صورت مشاهده خطای بحرانی، ایمیل می‌فرستد:

#!/bin/bash
if sudo tail -n 10 /var/log/apache2/error.log | grep -q "PHP Fatal error"; then
    echo "خطای بحرانی در سرور!" | mail -s "Alert: PHP Fatal Error" admin@example.com
fi

این اسکریپت را با cron هر ۵ دقیقه اجرا کنید.

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

آیا این مطلب برایتان مفید بود؟