دستور grep خط‌های متنیِ مطابق یک عبارت را پیدا می‌کند. برای جست‌وجوی یک پیام مشخص، -F انتخاب ساده‌تری از عبارت منظم است؛ با -n شمارهٔ خط را هم می‌بینید. نتیجهٔ جست‌وجو سرنخ است، نه تشخیص قطعی علت خطای سایت.
۱. یک فایل و یک عبارت مشخص
grep -nF -- 'ERROR' logs/app.log
این فرمان در فایل آموزشی app.log، عبارت بزرگ ERROR را به‌صورت متن ثابت جست‌وجو می‌کند. خروجی واقعی نمونه دو خط بود:
2:ERROR database timeout
4:ERROR upload failed
عدد قبل از دونقطه شمارهٔ خط است. این نمونه لاگ واقعی مشتری نیست؛ فقط فایل آزمایشی است. برای دادهٔ واقعی، ساعت، شناسهٔ درخواست و خط‌های اطراف را هم بررسی کنید تا پیام مربوط به حادثهٔ دیگری را به مشکل فعلی ربط ندهید.
۲. متن ثابت یا عبارت منظم؟
| گزینه | کاربرد |
|---|---|
-F |
نشانه‌ها را متن عادی در نظر می‌گیرد |
-E |
الگوی عبارت منظم گسترده |
-i |
نادیده‌گرفتن بزرگی و کوچکی حروف |
-n |
نمایش شمارهٔ خط |
-C 2 |
دو خط زمینه قبل و بعد از تطبیق |
بدون -F، علامت‌هایی مانند نقطه و کروشه ممکن است معنای الگو داشته باشند. برای جست‌وجوی literalِ آدرس یا پیام کپی‌شده، این تفاوت مهم است. کوتیشن جلوی تفسیر بخشی از نویسه‌ها توسط شِل را می‌گیرد، اما خودِ آن grep را از حالت regex به متن ثابت تبدیل نمی‌کند.
grep -nF -C 2 -- 'database timeout' logs/app.log
grep -nE -- 'ERROR|WARN' logs/app.log
۳. کد خروج را با خطای اجرا اشتباه نگیرید
کد در GNU grep |
معنی معمول |
|---|---|
0 |
حداقل یک خط انتخاب شد |
1 |
هیچ خطی انتخاب نشد |
2 |
اشکال اجرا، مانند فایل ناموجود |
در آزمون ما، جست‌وجوی FATAL در فایل موجود کد۱ داد؛ این نتیجه خطای ابزار نبود. در اسکریپت، توقف روی هر مقدار غیرصفر می‌تواند «پیدا نشدن عبارت» را با خرابی اجرا قاطی کند. حالت -q هم جزئیات خاص خودش را دارد؛ برای عیب‌یابی اولیه خروجی را بی‌دلیل ساکت نکنید.
۴. جست‌وجو را متناسب با قالب محدود کنید
از یک فایل یا پوشهٔ کوچک شروع کنید؛ جست‌وجوی بازگشتی در کل سرور می‌تواند کند باشد، خطای دسترسی بدهد و دادهٔ خصوصی زیادی نمایش دهد. لاگ فشرده، فایل باینری و متن چندخطی نیز با فرض «هر خط یک رخداد» همیشه قابل‌تحلیل نیستند.
نکته: گزینهٔ -c تعداد خط‌های انتخاب‌شده را می‌شمارد، نه تعداد دفعات ظاهرشدن عبارت. یک خط دارای دو ERROR همچنان یک خط محسوب می‌شود. برای JSON یا رخداد چندخطی، ابزار تحلیل همان قالب مناسب‌تر است.
پیش از ارسال نتیجه برای پشتیبانی، توکن، کوکی، ایمیل، IP خصوصی و مسیر حساس را پاک‌سازی کنید. تمام لاگ را به سرویس عمومی یا چت‌بات نفرستید.
۵. از سرنخ تا نتیجهٔ قابل‌اعتماد
- زمان حادثه و منطقهٔ زمانی را ثبت کنید.
- فایل درست و بازهٔ مربوط را انتخاب کنید.
- پیام را با شمارهٔ خط و زمینه بخوانید.
- آن را با وضعیت سرویس و درخواست کاربر تطبیق دهید؛ صرف وجود ERROR کافی نیست.
اگر هیچ نتیجه‌ای پیدا نشد، ممکن است لاگ چرخیده، پیام با حروف دیگر نوشته شده، مسیر لاگ متفاوت یا اصلاً ثبت آن رخداد فعال نباشد. «grep چیزی نداد» به معنی «سرویس سالم است» نیست. راهنماهای لاگ سی‌پنل در ادامه کمک می‌کنند منبع درست را پیدا کنید.
۶. مسیر مطالعهٔ مرتبط
- Raw Access و Visitors در سی‌پنل؛ خواندن لاگ دسترسی و پیدا کردن ربات مزاحم
- خطاهای سایت در سی‌پنل؛ بررسی لاگ و رفع خطای ۵۰۰ و ۴۰۳
۷. منابع و روش بررسی
منابع رسمی در ۲۴ اکتبر ۲۰۲۶ بررسی شدند. نمونه‌های فرمان با دادهٔ آموزشی در GNU/MSYS روی ویندوز بررسی شده‌اند؛ این محیط، سرور لینوکس بومی نیست. رفتار مالکیت و دسترسی فایل‌سیستم باید روی سیستم مقصد جدا بررسی شود.
