برای دیدن بخش کوچکی از فایل لاگ، از head برای ابتدا و tail برای انتها استفاده کنید. نمایش چند خط محدود، سریع‌تر و خواناتر از ریختن کل فایل بزرگ در ترمینال است. با این حال، آخر فایل همیشه «آخرین رخداد کل سامانه» نیست؛ چرخش لاگ، چند پردازه و منطقهٔ زمانی باید بررسی شوند.
۱. دیدن دو سر فایل بدون تغییر آن
head -n 2 -- logs/app.log
tail -n 2 -- logs/app.log
در نمونهٔ آموزشی پنج‌خطی، head دو خط اول و tail دو خط آخر را نشان داد. خروجی tail چنین بود:
ERROR upload failed
INFO done
این فرمان‌ها فقط می‌خوانند؛ فایل اصلی کوتاه یا پاک نمی‌شود. گزینهٔ -n تعداد خط را تعیین می‌کند و مقدار پیش‌فرض هر دو ابزار معمولاً ۱۰ خط است. برای پیدا کردن قالب فایل، head و برای دیدن انتهای آن، tail را انتخاب کنید.
۲. چه زمانی کدام ابزار؟
| نیاز | انتخاب |
|---|---|
| تشخیص سربرگ و شکل داده | head با تعداد خط کم |
| دیدن پیام‌های انتهای فایل | tail با تعداد خط محدود |
| پیدا کردن یک پیام در سراسر فایل | grep |
| مشاهدهٔ رویدادهای جدید هنگام اضافه‌شدن | tail با حالت follow |
اگر دنبال حادثه‌ای در ساعت مشخص دیروز هستید، tail به‌تنهایی انتخاب دقیقی نیست. ابتدا فایل مربوط به آن بازه را پیدا کنید، بعد زمان را با ابزار جست‌وجو فیلتر کنید. دریافت فایل جدید یا تغییر زمان آن هم الزاماً ترتیب رخدادهای داخلش را عوض نمی‌کند.
۳. دنبال‌کردن فایل و چرخش لاگ
tail -n 20 -f -- logs/app.log
tail -n 20 -F -- logs/app.log
در GNU tail، -f به‌طور پیش‌فرض فایل بازشده را دنبال می‌کند؛ اگر لاگ rename و فایل تازه‌ای با همان نام ساخته شود، ممکن است به نسخهٔ قدیمی وابسته بماند. -F معادل دنبال‌کردن نام همراه تلاش مجدد است و برای چرخشِ همراه جایگزینی نام کاربرد دارد. رفتار به روش rotation هم وابسته است.
نکته: فرمان‌های follow تا متوقف‌شدن ادامه دارند؛ برای خروج Ctrl+C بزنید. در بررسی این مقاله، نمونه‌های محدود head/tail اجرا شدند؛ پایش زنده و چرخش لاگ روی سرور آزمایش نشده است. این دو فرمان follow را فقط در محیط مجاز خودتان اجرا کنید.
۴. فایل را با برنامهٔ پردازش اشتباه نگیرید
لاگ می‌تواند قبل از نوشتن نهایی در بافر بماند؛ تأخیر دیدن پیام الزاماً خرابی tail نیست. برخی برنامه‌ها هم خروجی را به stdout، سرویس journal یا مسیر دیگری می‌فرستند. اگر فایل جدید نمی‌شود، ابتدا منبع واقعی ثبت پیام را بررسی کنید.
- فایل فشرده را مثل متن عادی به tail ندهید.
- فایل خالی به معنی سالم‌بودن برنامه نیست.
- پیام چندخطی را با بریدن دو خط از وسط، ناقص تفسیر نکنید.
- نام فایل و بازهٔ زمانی را کنار خروجی یادداشت کنید.
۵. ارسال خروجی برای عیب‌یابی
برای پشتیبانی، چند خط مرتبط قبل و بعد از رخداد همراه ساعت و شناسهٔ پیگیری کافی‌تر از هزاران خط بدون زمینه است. رمز، session، آدرس خصوصی و محتوای مشتری را پیش از ارسال محو یا حذف کنید. در عکس هم blur باید واقعاً ناخوانا باشد، نه فقط خط‌کشیدن روی بخش کوچکی از مقدار.
اگر دسترسی SSH ندارید، ابزار Errors یا Raw Access سی‌پنل می‌تواند بخشی از اطلاعات را در اختیار شما بگذارد. آن ابزارها الزاماً همهٔ لاگ برنامهٔ Node.js یا همهٔ رخدادهای WAF را نمایش نمی‌دهند؛ محل ثبت را از مستند برنامه و پشتیبانی بپرسید.
پیش از اجرای head و tail روی یک فایل، مطمئن شوید به مسیر درست اشاره می‌کنید؛ راهنمای مسیر مطلق و نسبی در لینوکس برای رفع این ابهام مفید است.
۶. مسیر مطالعهٔ مرتبط
- Raw Access و Visitors در سی‌پنل؛ خواندن لاگ دسترسی و پیدا کردن ربات مزاحم
- خطاهای سایت در سی‌پنل؛ بررسی لاگ و رفع خطای ۵۰۰ و ۴۰۳
۷. منابع و روش بررسی
منابع رسمی در ۲۴ اکتبر ۲۰۲۶ بررسی شدند. نمونه‌های فرمان با دادهٔ آموزشی در GNU/MSYS روی ویندوز بررسی شده‌اند؛ این محیط، سرور لینوکس بومی نیست. رفتار مالکیت و دسترسی فایل‌سیستم باید روی سیستم مقصد جدا بررسی شود.
