آموزش grep برای جستجوی خطا در لاگ‌های لینوکس

یکی از سریع‌ترین روش‌ها برای پیدا کردن خطا در فایل‌های لاگ لینوکس، استفاده از دستور grep است.

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

error
failed
warning
critical
denied
timeout

هستند.

برای مثال:

grep -i "error" /var/log/syslog

تمام خطوطی را که شامل error هستند نمایش می‌دهد.

در این مقاله روش‌های کاربردی استفاده از grep برای جستجو در لاگ‌های لینوکس را بررسی می‌کنیم.

ساختار اصلی دستور grep

ساختار ساده دستور به شکل زیر است:

grep "PATTERN" FILE

برای مثال:

grep "error" /var/log/syslog

یا در AlmaLinux و Rocky Linux:

grep "error" /var/log/messages

اگر عبارت موردنظر پیدا شود، خط کامل نمایش داده می‌شود.

جستجوی بدون حساسیت به حروف بزرگ و کوچک

یکی از پرکاربردترین گزینه‌ها:

-i

است.

برای مثال:

grep -i "error" /var/log/syslog

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

error
Error
ERROR

برای بررسی لاگ‌ها معمولاً استفاده از -i مفید است، چون شکل نوشتن پیام‌ها در سرویس‌های مختلف یکسان نیست.

پیدا کردن چند نوع خطا به‌ صورت همزمان

در بسیاری از موارد نمی‌دانیم پیام دقیق خطا چه خواهد بود.

می‌توان چند عبارت را همزمان جستجو کرد:

grep -Ei "error|failed|critical|warning" /var/log/syslog

گزینه:

-E

استفاده از Extended Regular Expression را فعال می‌کند.

عبارات منظم یا Regular Expression که به آن‌ها Regex نیز گفته می‌شود عباراتی هستند که می‌توان آن‌ها را به تعداد بینهایت عبارت عادی تبدیل کرد.

به عنوان مثال معنی (ab)*a یعنی تمام عباراتی که در ابتدا هر تعدادی (حتی صفر) ab دارد و به ‌‌a ختم می‌شوند. به عنوان مثال a – aba – ababa و … . نکته مهم این است که سیستم نگارش regex می‌تواند قواعد متفاوتی داشته باشد. * در سیستم‌های لینوکسی به معنای همه یا wildcard است. ls *.log تمامی فایل‌هایی که در انتهای خود .log دارند را نمایش می‌دهد.

علامت:

|

به معنی «یا» است.

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

نمونه کاربردی برای بررسی خطاهای عمومی

در Ubuntu یا Debian:

sudo grep -Ei "error|failed|critical|warning" /var/log/syslog

در AlmaLinux، Rocky Linux یا RHEL:

sudo grep -Ei "error|failed|critical|warning" /var/log/messages

این دستور نقطه شروع خوبی برای بررسی خطاهای عمومی سیستم است.

نمایش شماره خط

برای اینکه مشخص شود خطا در کدام قسمت فایل قرار دارد، از:

-n

استفاده کنید.

مثلاً:

grep -in "error" /var/log/syslog

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

1542:Sep 07 09:15:32 server nginx: error connecting to upstream
1874:Sep 07 09:20:11 server systemd: Failed to start example.service

عدد ابتدای هر خط، شماره همان خط در فایل است.

یا در یک مثال عملی دیگر:

نمایش خطوط قبل و بعد از خطا

گاهی خود خط Error اطلاعات کافی ندارد و باید چند خط قبل یا بعد آن را ببینیم.

برای نمایش سه خط بعد:

grep -A 3 "error" /var/log/syslog

A مخفف:

After

است.

برای سه خط قبل:

grep -B 3 "error" /var/log/syslog

B یعنی:

Before

و برای سه خط قبل و بعد:

grep -C 3 "error" /var/log/syslog

C به معنی:

Context

است.

این گزینه در عیب‌یابی بسیار مفید است.

مطابق تصویر هر یک از مجموعه contextها یعنی خطا به همراه متن همراه با علامت -- از هم جدا شده‌اند. شماره خطوط نیز نشان دهنده این موضوع است.

مثال: بررسی Context یک خطای سرویس

فرض کنید در لاگ عبارت زیر وجود دارد:

Failed to start nginx.service

برای مشاهده چند خط اطراف آن:

grep -C 5 "Failed to start nginx" /var/log/syslog

ممکن است خطوط قبل، علت اصلی خطا را نشان دهند؛ مثلاً:

nginx: [emerg] unexpected "}" in /etc/nginx/nginx.conf:42
systemd[1]: nginx.service: Main process exited
systemd[1]: Failed to start nginx.service

در این حالت خطای واقعی مربوط به Syntax فایل تنظیمات Nginx است.

جستجو در لاگ‌های SSH

در Ubuntu و Debian معمولاً:

/var/log/auth.log

را بررسی می‌کنیم.

برای پیدا کردن Loginهای ناموفق:

sudo grep "Failed password" /var/log/auth.log

برای جستجوی همه پیام‌های مربوط به SSH:

sudo grep "sshd" /var/log/auth.log

برای مشاهده Loginهای موفق:

sudo grep "Accepted" /var/log/auth.log

در AlmaLinux، Rocky Linux و RHEL معمولاً همین اطلاعات در:

/var/log/secure

قرار دارند:

sudo grep "Failed password" /var/log/secure

پیدا کردن خطاهای مربوط به یک IP

اگر می‌خواهید تمام رویدادهای مربوط به یک IP را ببینید:

grep "203.0.113.20" /var/log/auth.log

یا:

grep "203.0.113.20" /var/log/secure

این روش برای بررسی مواردی مانند:

• تلاش‌های ناموفق SSH
• درخواست‌های مشکوک
• IP خاص یک کاربر
• ارتباط‌های مکرر

کاربرد دارد.

بررسی لاگ Apache و Nginx

برای Apache در Ubuntu:

grep -i "error" /var/log/apache2/error.log

در RHEL-family:

grep -i "error" /var/log/httpd/error_log

برای Nginx:

grep -i "error" /var/log/nginx/error.log

برای چند عبارت:

grep -Ei "error|failed|timeout|denied" /var/log/nginx/error.log

جستجو در Access Log

grep فقط برای Error Log نیست.

مثلاً برای پیدا کردن پاسخ‌های HTTP 500 در Apache:

grep ' 500 ' /var/log/apache2/access.log

یا برای Nginx:

grep ' 500 ' /var/log/nginx/access.log

برای بررسی درخواست‌های یک IP:

grep "198.51.100.15" /var/log/nginx/access.log

شمارش تعداد نتایج

برای شمارش تعداد خطوط Match شده از گزینه:

-c

استفاده کنید.

مثلاً:

grep -c "Failed password" /var/log/auth.log

اگر خروجی:

247

باشد یعنی 247 خط شامل این عبارت پیدا شده است.

برای شمارش Errorها:

grep -ic "error" /var/log/syslog

نمایش فقط عبارت پیدا شده

گزینه:

-o

فقط قسمت Match شده را نمایش می‌دهد.

برای مثال:

grep -o "Failed password" /var/log/auth.log

این گزینه برای تحلیل ساده یا Pipe کردن خروجی به ابزارهای دیگر مفید است.

نکته‌ای که می‌تواند این دستور را کاربردی‌تر کند استفاده همزمان آن با -n است. در این مورد یک خروجی بسیار ساده و خلوت از خطوط حاوی کلمه مورد نظر خواهید داشت که می‌توانید تحلیل بعدی را از آن ادامه دهید:

حذف خطوط خاص از نتیجه

گاهی می‌خواهیم خطوطی را که شامل یک عبارت مشخص هستند نمایش ندهیم. به این قابلیت invert matching گفته می‌شود.

از:

-v

استفاده می‌کنیم.

مثلاً:

grep -i "error" /var/log/syslog | grep -v "known harmless error"

در دستور اول تمامی خطوط حاوی هر نوع نگارش error پیدا شده و در دستور دوم خطوطی که حاوی err هستند حذف شده‌اند:

یا:

grep -v "healthcheck" /var/log/nginx/access.log

در مثال دوم، درخواست‌های healthcheck از خروجی حذف می‌شوند.

ترکیب grep با tail

برای بررسی جدیدترین بخش لاگ:

tail -n 500 /var/log/syslog | grep -i "error"

در این مثال فقط 500 خط آخر بررسی می‌شوند.

این روش روی فایل‌های بزرگ سریع‌تر و خواناتر است.

مثلاً:

tail -n 1000 /var/log/nginx/error.log | grep -Ei "timeout|upstream|failed"

ترکیب grep با tail -f

برای مشاهده زنده خطاها می‌توان:

tail -f /var/log/syslog | grep -i "error"

را اجرا کرد.

یا برای Nginx:

tail -f /var/log/nginx/error.log | grep -Ei "error|timeout|upstream"

سپس ایراد را دوباره ایجاد کنید.

برای مثال:

Terminal 1:
tail -f /var/log/nginx/error.log | grep -i "error"

Browser:
باز کردن صفحه‌ای که خطا می‌دهد

اگر خطای جدیدی ثبت شود، همان لحظه در Terminal دیده می‌شود.

برای خروج:

Ctrl + C

جستجو بر اساس تاریخ و زمان

اگر زمان تقریبی رخ دادن مشکل را می‌دانید، بهتر است جستجو را محدود کنید.

فرض کنید خطا در تاریخ:

Sep 07

رخ داده است:

grep "Sep 07" /var/log/syslog

و برای ساعت مشخص:

grep "Sep 07 09:" /var/log/syslog

برای ترکیب با Error:

grep "Sep 07 09:" /var/log/syslog | grep -i "error"

این روش حجم نتیجه را بسیار کمتر می‌کند.

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

جستجو بر اساس نام سرویس

اگر فقط لاگ‌های یک سرویس خاص مهم هستند، نام آن را جستجو کنید.

مثلاً:

grep "nginx" /var/log/syslog

یا:

grep "sshd" /var/log/auth.log

یا:

grep "cron" /var/log/syslog

در بسیاری از موارد بهتر است ابتدا سرویس را مشخص کنیم و بعد داخل نتایج دنبال Error بگردیم:

grep "nginx" /var/log/syslog | grep -Ei "error|failed"

استفاده از چند فایل با grep

می‌توان چند فایل را همزمان بررسی کرد:

grep -i "error" /var/log/syslog /var/log/auth.log

در این حالت grep نام فایل را نیز در خروجی نمایش می‌دهد.

مثلاً:

جستجو در چند فایل با Wildcard

برای بررسی مجموعه‌ای از فایل‌ها:

grep -i "error" /var/log/*.log

یا:

grep -Ei "failed|error" /var/log/*.log

معنای *.log این است که تمام فایل‌هایی که با پسوند .log ختم می‌شوند جستجو شوند.

اما در /var/log ممکن است فایل‌هایی وجود داشته باشند که Binary هستند.

بنابراین بهتر است همیشه بدون بررسی، تمام فایل‌های /var/log/* را وارد grep نکنید.

جستجوی Recursive

برای جستجو در یک Directory و Subdirectoryهای آن از:

-r

استفاده کنید:

grep -ri "error" /var/log/nginx/

برای نمایش شماره خط:

grep -rin "error" /var/log/nginx/

این روش برای Applicationهایی که چند Log File دارند بسیار مفید است.

در خروجی این دستورات مانند استفاده از دستور grep برای چند فایل، ابتدا نام فایل و سپس خط حاوی match نمایش داده می‌شود.

نمایش نام فایل‌های دارای نتیجه

اگر فقط می‌خواهید بدانید کدام File شامل عبارت موردنظر است:

grep -ril "error" /var/log/nginx/

گزینه:

-l

فقط نام Fileهایی را نشان می‌دهد که مطابقت دارند.

جستجوی یک عبارت دقیق با Fixed String

بعضی عبارت‌ها شامل Characterهایی هستند که در Regular Expression معنی خاص دارند.

در این موارد می‌توان از:

-F

استفاده کرد:

grep -F "[error]" /var/log/example.log

این دستور [error] را دقیقاً به‌عنوان متن عادی جستجو می‌کند. اگر -F نبود تفسیر Regex از [error] این بود که کلماتی را نشان بده که حاوی یکی از مقادیر e,r,r,o یا r هستند (تکرار اهمیتی ندارد صرفا هدف شکستن املای error بود).

استفاده از Regular Expression

grep می‌تواند Patternهای پیچیده‌تری را نیز بررسی کند.

برای مثال:

grep -E "HTTP/[0-9.]+\" 5[0-9]{2}" /var/log/nginx/access.log

این Pattern می‌تواند پاسخ‌های HTTP سری 5xx را پیدا کند.

• HTTP/ → عبارت ثابت HTTP/
• [0-9.]+ → نسخه HTTP مثل 1.1 یا 2.0
• \" → علامت "
• 5[0-9]{2} → یک کد سه‌رقمی که با 5 شروع می‌شود؛ مثل 500، 502، 503

مثلاً این بخش را Match می‌کند:

HTTP/1.1" 500
HTTP/2.0" 503

یعنی هدف اصلی آن پیدا کردن خطاهای HTTP سری 5xx است.

برای استفاده روزمره در عیب‌یابی معمولاً Regexهای ساده کافی هستند:

grep -Ei "error|fail|warning|critical"

پیدا کردن خطاهای 4xx و 5xx

اگر Log Format استاندارد باشد، برای خطاهای HTTP سری 4xx:

grep -E ' 4[0-9]{2} ' /var/log/nginx/access.log

برای 5xx:

grep -E ' 5[0-9]{2} ' /var/log/nginx/access.log

و برای هر دو:

grep -E ' (4|5)[0-9]{2} ' /var/log/nginx/access.log

بررسی فایل‌های Rotate شده

بعد از Log Rotation ممکن است فایل‌هایی مانند:

syslog.1
auth.log.1
messages-20260901

وجود داشته باشند.

برای Fileهای معمولی همچنان می‌توان از grep استفاده کرد:

grep -i "error" /var/log/syslog.1

جستجو در فایل‌های فشرده با zgrep

فایل‌های قدیمی اغلب با gzip فشرده می‌شوند:

syslog.2.gz
auth.log.3.gz

در این حالت به‌جای Extract کردن فایل می‌توان از:

zgrep

استفاده کرد.

مثلاً:

zgrep -i "error" /var/log/syslog.2.gz

یا:

zgrep -Ei "error|failed|critical" /var/log/syslog.*.gz

این قابلیت هنگام بررسی ایرادی که چند روز قبل رخ داده بسیار کاربردی است.

grep و logrotate چه ارتباطی دارند؟

اگر Error موردنظر در فایل فعلی پیدا نشد، ممکن است Log قبلاً Rotate شده باشد.

مثلاً:

auth.log
auth.log.1
auth.log.2.gz
auth.log.3.gz

در این شرایط باید هم فایل فعلی و هم نسخه‌های قدیمی‌تر را بررسی کنید.

برای Log Rotation مقاله جداگانه داریم:

آموزش مدیریت و چرخش لاگ‌ها در لینوکس با logrotate

grep روی systemd Journal

grep برای فایل‌های Text بسیار مناسب است، اما فایل‌های Journal را نباید مستقیماً با grep باز کرد.

برای مثال فایل‌های داخل:

/var/log/journal/

Binary هستند.

برای جستجو در Journal می‌توان خروجی journalctl را Pipe کرد:

journalctl | grep -i "error"

یا بهتر:

journalctl -u nginx | grep -Ei "error|failed"

با این حال خود journalctl ابزارهای Filter داخلی دارد و معمولاً برای Journal بهتر است از همان قابلیت‌ها استفاده شود.

برای مثال:

journalctl -p err

برای نمایش پیام‌های Error.

راه حل دیگری نیز وجود دارد. از آنجایی که دستور grep بسیار کاربردی است این دستور به عنوان یک آپشن در journalctl قرار داده شده است و با استفاده از:

journalctl --grep

می‌توان از آن استفاده کرد. به عنوان مثال:

برای آموزش کامل:

آموزش کامل journalctl در لینوکس

جستجوی خطاهای Boot

برای Boot فعلی:

journalctl -b

و برای فیلتر ساده با grep:

journalctl -b | grep -Ei "failed|error|critical"

اما برای بررسی دقیق Boot بهتر است از قابلیت‌های خود journalctl استفاده شود.

این موضوع در مقاله زیر جداگانه بررسی می‌شود:

آموزش بررسی خطاهای Boot در لینوکس با journalctl -b

Permission denied هنگام grep

ممکن است اجرای:

grep "Failed" /var/log/secure

با:

Permission denied

مواجه شود.

در این حالت:

sudo grep "Failed" /var/log/secure

استفاده کنید.

برای خواندن Logهای حساس، Permission فایل را تغییر ندهید.

Binary file matches یعنی چه؟

گاهی grep خروجی زیر را نشان می‌دهد:

Binary file ... matches

این یعنی File موردنظر Text Log عادی نیست یا شامل داده Binary است.

مثلاً فایل‌هایی مانند:

wtmp
btmp
lastlog

باید با ابزار مخصوص خودشان بررسی شوند.

برای مثال:

last

برای wtmp و:

sudo lastb

برای btmp.

مثال عملی: بررسی خطای Database

اگر MySQL Error Log در مسیر زیر باشد:

/var/log/mysql/error.log

می‌توان:

sudo grep -Ei "error|warning|crash|failed" /var/log/mysql/error.log

را اجرا کرد.

اگر این فایل وجود نداشت، ممکن است Log از طریق Journal در دسترس باشد:

journalctl -u mysql

یا:

journalctl -u mariadb

مثال عملی: پیدا کردن Out of Memory

برای جستجوی OOM در Log:

grep -Ei "out of memory|oom|killed process" /var/log/syslog

یا:

grep -Ei "out of memory|oom|killed process" /var/log/messages

و در Journal:

journalctl -k | grep -Ei "out of memory|oom|killed process"

این جستجو هنگام بررسی Processهایی که ناگهان Kill شده‌اند مفید است.

مثال عملی: بررسی Permission denied

برای یافتن خطاهای Permission:

grep -i "permission denied" /var/log/syslog

یا داخل Log یک Application:

grep -ri "permission denied" /var/log/nginx/

بهتر است اول چه عبارتی را جستجو کنیم؟

یک لیست عمومی مناسب:

error
failed
failure
critical
warning
denied
timeout
refused
unreachable
killed
segfault

مثلاً:

grep -Ei \
  "error|failed|failure|critical|denied|timeout|refused" \
  /var/log/syslog

اما نباید فقط به کلمه error وابسته باشید؛ بعضی سرویس‌ها خطا را با عبارت دیگری ثبت می‌کنند.

همیشه زمان خطا را در نظر بگیرید

فرض کنید سایت در ساعت:

09:30

دچار مشکل شده است.

به‌جای جستجوی کل فایل بهتر است ابتدا همان بازه زمانی را بررسی کنید:

grep "Sep 07 09:3" /var/log/syslog

سپس:

grep "Sep 07 09:3" /var/log/syslog \
  | grep -Ei "error|failed|warning"

این روش معمولاً سریع‌تر از بررسی هزاران خط نامرتبط است.

اشتباهات رایج

فقط کلمه error را جستجو می‌کنیم

ممکن است سرویس از عبارت‌هایی مثل:

failed
denied
timeout
refused

استفاده کند.

حروف بزرگ و کوچک را فراموش می‌کنیم

بهتر است در بسیاری از جستجوها از:

-i

استفاده شود.

کل فایل چندگیگابایتی را مستقیم جستجو می‌کنیم

اگر فقط خطاهای جدید مهم هستند:

tail -n 1000 FILE | grep ...

خواناتر است.

Logهای Rotate شده را بررسی نمی‌کنیم

ممکن است خطای موردنظر در:

syslog.1

یا:

syslog.2.gz

باشد.

Context خطا را نمی‌بینیم

از:

-A
-B
-C

برای دیدن خطوط اطراف Error استفاده کنید.

فایل Binary را با grep بررسی می‌کنیم

فایل‌هایی مانند wtmp و btmp ابزار مخصوص خود را دارند.

Journal را مانند فایل Text در نظر می‌گیریم

برای systemd Journal از:

journalctl

استفاده کنید.

Workflow پیشنهادی برای جستجوی خطا

یک روش عملی:

مشخص کردن زمان بروز ایراد
↓
مشخص کردن سرویس
↓
پیدا کردن فایل لاگ مناسب
↓
بررسی آخرین خطوط
↓
جستجوی error / failed / timeout
↓
مشاهده Context خطا
↓
بررسی Logهای Rotate شده
↓
تکرار مشکل و مشاهده Live Log

برای مثال:

tail -n 500 /var/log/nginx/error.log

سپس:

grep -Ei "error|failed|timeout" /var/log/nginx/error.log

و در نهایت:

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

دستورات کاربردی grep برای لاگ‌ها

مطالعه بیشتر

مقالات مرتبط در دانشنامه:

• آموزش بررسی فایل‌های لاگ در /var/log لینوکس
• آموزش کامل journalctl در لینوکس
• آموزش کامل systemctl
• آموزش بررسی خطاهای Boot در لینوکس با journalctl -b
• آموزش مدیریت و چرخش لاگ‌ها در لینوکس با logrotate
• اگر منابع سرور لینوکسی کامل درگیر شد چکار کنیم؟

صفحات رسمی ابزارها:

• journalctl
• wtmp man page
• btmp man page

جمع‌بندی

دستور:

grep

یکی از ساده‌ترین و کاربردی‌ترین ابزارها برای پیدا کردن خطا در فایل‌های لاگ Linux است.

برای یک بررسی سریع می‌توان از:

grep -Ei "error|failed|critical|warning" /var/log/syslog

یا در RHEL-family:

grep -Ei "error|failed|critical|warning" /var/log/messages

استفاده کرد.

برای دیدن خطوط اطراف خطا نیز:

grep -C 5 "error" FILE

بسیار مفید است.

اگر Log قدیمی فشرده شده باشد:

zgrep

را استفاده کنید و اگر Log متعلق به systemd-journald باشد، بهتر است از:

journalctl

کمک بگیرید.

در عیب‌یابی، مشخص کردن زمان بروز ایراد، سرویس مربوطه و فایل لاگ مناسب معمولاً مهم‌تر از جستجوی تصادفی کلمه error در تمام /var/log است.