عیب‌یابی لینوکس چیست؟ رفع مشکلات سرور با لاگ و دستورهای کاربردی

تصور کن اول صبح یکی از بچه‌های تیم پیام می‌ده: «پنل ثبت سرویس آسانسورها باز می‌شه، ولی ذخیره درخواست‌ها خیلی طول می‌کشه و بعضی وقت‌ها هم خطا می‌ده.» حالا تو جای مدیر سرور باشی، اولین واکنشت چیه؟ top رو باز می‌کنی، سرور رو ری‌استارت می‌کنی یا اول می‌پرسی دقیقاً کدوم کار از چه زمانی خراب شده؟ من می‌خوام توی این درس یاد بگیری قبل از اجرای هر دستور، مسئله رو درست صورت‌بندی کنی.

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

توی درس‌های قبلی LPIC-1 با بوت، systemd، بسته‌ها و دیسک آشنا شدی. اینجا قرار نیست همون مطالب رو از اول درس بدیم. قراره ببینی توی یک حادثه واقعی‌نما، آموزش عیب یابی لینوکس چطور همه این مهارت‌ها رو کنار هم می‌ذاره. سناریوی این مقاله ساختگیه، داده‌ها برای تمرین ساخته شدن و تا جای ممکن با فرمان‌های فقط‌خواندنی پیش می‌ریم؛ هیچ نیازی به خراب کردن یک سرور واقعی نداریم.

عیب‌یابی لینوکس چیست و چرا فقط بلد بودن دستور کافی نیست؟

عیب‌یابی لینوکس یا Linux Troubleshooting یعنی از روی علائم، علت یک اختلال رو مرحله‌به‌مرحله محدود کنیم. مثلاً وقتی کاربر می‌گه سایت باز نمی‌شه، شاید برنامه خطا داده، شاید سرویس متوقف شده، شاید DNS جواب متفاوتی برگردونده یا شاید فضای دیسک تمام شده. کاربر در همه این حالت‌ها یک مشکل می‌بینه، ولی راه‌حل‌ها یکی نیستن. برای همین رفع مشکلات لینوکس از تشخیص درست شروع می‌شه، نه از کپی کردن سریع‌ترین دستور اینترنت.

من همیشه می‌گم برای هر فرضیه، یک سؤال قابل اندازه‌گیری داشته باش. فکر می‌کنی رم کمه؟ اول خروجی free و نشونه‌های فشار حافظه رو ببین. حدس می‌زنی برنامه خاموشه؟ وضعیت Unit و پاسخ واقعی برنامه رو مقایسه کن. حتی اگه یک restart موقتاً جواب داد، هنوز نمی‌دونی علت چه بوده. رفع خطاهای لینوکس وقتی ارزش داره که بدونی چرا مشکل ایجاد شده و چطور دوباره سراغت نیاد.

یه تفاوت مهم رو از اول یادت بمونه: عیب یابی سرور لینوکس با «همین حالا یه چیزی رو تعمیر کن» یکی نیست. بعضی وقت‌ها باید برای کاهش قطعی سریع اقدام کنی، ولی حتی اون وقت هم بهتره زمان، نشونه‌ها و اطلاعات ضروری رو ثبت کنی. پاک کردن لاگ، تغییر چند تنظیم با هم یا خاموش کردن یک سرویس حساس، ممکنه شاهدهای اصلی رو از بین ببره. هدفمون اول حفظ اطلاعات و محدود کردن اختلاله، بعد پیدا کردن علت.

عیب یابی سرور لینوکس؛ قبل از هر دستور مشکل رو دقیق تعریف کن

به جای جمله مبهم «سرور خیلی کُنده»، این گزارش رو تصور کن: «از ساعت ۱۰:۱۲، ذخیره فرم سرویس آسانسور برای بعضی کاربران بیشتر از پنج ثانیه طول می‌کشه و گاهی خطای ۵۰۰ می‌ده؛ صفحه اصلی همچنان باز می‌شه.» حالا می‌دونیم چه عملیاتی خرابه، مشکل از چه زمانی شروع شده و چه چیزی هنوز سالمه. برای رفع مشکل سرور لینوکس همین دقیق گفتنِ علامت، خیلی وقت‌ها از اجرای ده فرمان بی‌هدف مفیدتره.

وقتی مسئول عیب یابی سرور لینوکس هستی، از کسی که اختلال رو دیده بپرس: آخرین بار چه زمانی درست کار می‌کرد؟ مشکل برای همه کاربرهاست یا فقط بعضی‌ها؟ درست قبل از اون چه چیزی عوض شده؟ شاید نسخه تازه منتشر شده، یک تسک زمان‌بندی‌شده شروع شده یا تنظیم DNS تغییر کرده. این اطلاعات برای بررسی کندی سرور لینوکس سرنخ می‌دن، اما حواست باشه هم‌زمان شدن دو اتفاق به‌تنهایی ثابت نمی‌کنه یکی علت اون یکیه.

یه دام دیگه هم داریم: چیزی که اسمش رو سرور می‌ذاریم ممکنه ماشین فیزیکی، VM، کانتینر یا یک سرویس ابری باشه. عدد CPU و حافظه‌ای که از داخل کانتینر می‌بینی، لزوماً همه محدودیت‌های میزبان یا cgroup رو نشون نمی‌ده. اگه سطح اندازه‌گیری رو ندونی، ممکنه فکر کنی منابع آزاد دارن، درحالی‌که خود برنامه محدود شده. پس توی عیب‌یابی لینوکس، قبل از نتیجه‌گیری محیط اجرای سرویس رو بشناس.

مدل پنج‌مرحله‌ای نابغه‌ها برای عیب‌یابی لینوکس

برای اینکه وسط لاگ‌ها و نمودارها گم نشیم، یه روش پنج‌مرحله‌ای داریم: علامت، زمان، شاهد، فرضیه و راستی‌آزمایی. این اسم رو به‌عنوان چارچوب آموزشی همین درس در نظر بگیر، نه یک استاندارد رسمی. توی عیب‌یابی لینوکس هر فرمان باید به یکی از این پنج قدم کمک کنه. اگر نمی‌دونی دستور بعدی چه سؤالی رو جواب می‌ده، احتمالاً هنوز زوده اجراش کنی.

گاهی وسط یک اختلال جدی، فرصت یک بررسی طولانی نداری و لازم می‌شه سریع اثر مشکل رو روی کاربران کم کنی. اشکالی نداره، اما دقیق ثبت کن چه تغییری دادی و چطور می‌تونی برش گردونی. بعدش هم برای ادامه عیب‌یابی لینوکس دوباره برگرد سراغ شواهد. جمله «ری‌استارت کردم درست شد» پایان یک گزارش فنی نیست؛ هنوز معلوم نیست مشکل چرا شروع شده و چه زمانی برمی‌گرده.

پرونده آموزشی : پنل سرویس آسانسورها چرا کُند شده؟

بریم سراغ پرونده اصلی. یه شرکت فرضی رو تصور کن که درخواست‌های سرویس آسانسور ساختمون‌ها رو توی یک پنل ثبت می‌کنه. تکنسین‌ها با گوشی گزارش می‌فرستن و مسئول دفتر آخر روز خروجی می‌گیره. امروز ثبت بعضی فرم‌ها کند شده؛ درحالی‌که سیستم‌عامل روشنه و systemd سرویس رو active نشون می‌ده. این مثال برای عیب یابی سرور لینوکس طراحی شده تا یاد بگیری «فعال بودن پردازش» لزوماً «سالم بودن خدمت» نیست.

از مانیتورینگ چند عدد داریم: CPU حدود ۱۸٪، حافظه در دسترس نزدیک ۱٫۲ گیگابایت و مصرف دیسک حدود ۶۳٪. شاید در نگاه اول بگی پس منابع مشکلی ندارن. ولی این فقط یک لحظه از وضعیت سیستمه؛ برای بررسی CPU در لینوکس و بررسی رم در لینوکس به روند مصرف هم نیاز داری. تازه در همین بازه، زمان پاسخ بیشتر شده، صف درخواست‌ها بالا رفته و انتظار I/O رشد کرده. برای پیدا کردن علت کند شدن سرور لینوکس باید همه این شواهد رو کنار هم بذاری.

نکته جدول رو ببین: CPU تقریباً ثابته، ولی تأخیر و طول صف دارن زیاد می‌شن. آیا نتیجه می‌گیریم هارد خرابه؟ نه! شاید برنامه منتظر دیتابیس یا فضای ذخیره‌سازی شبکه است. شاید هم یک Query جدید سرعت سرویس رو گرفته. فعلاً فقط می‌گیم فرضیه انتظار I/O ارزش بررسی داره. کندی سرور لینوکس رو با شواهد دنبال می‌کنیم، نه با پیدا کردن یک مقصر آماده.

بررسی CPU در لینوکس؛ قدم اول برای پیدا کردن علت کندی

اولین کاری که بعد از ورود به سیستم پیشنهاد می‌کنم، ثبت زمان و وضعیت کلیه. خروجی date -Is رو نگه دار تا بعداً بتونی ساعت شکایت کاربر رو با زمان لاگ تطبیق بدی. با uptime مدت روشن بودن و Load رو می‌بینی و با nproc تعداد واحدهای پردازشی در دسترس این محیط رو می‌گیری. توی عیب‌یابی لینوکس این فرمان‌ها از دستورات عیب یابی لینوکس هستن، ولی هر کدوم فقط یک قطعه از پازلن.

date -Is
hostname
uptime
nproc

حالا برسیم به Load Average. خروجی uptime میانگین بار در بازه‌های یک، پنج و پانزده دقیقه رو نشون می‌ده. این عدد درصد استفاده از CPU نیست؛ تعداد میانگین کارهایی رو منعکس می‌کنه که آماده اجرا بودن یا در وضعیت انتظار بدون وقفه قرار داشتن. پس توی آموزش Load Average لینوکس نباید Load برابر ۴ رو به معنی «۴٪ مصرف پردازنده» بگیری. تعداد CPUها و وضعیت پردازش‌ها رو هم باید ببینی.

فرض کن روی ماشینی با چهار CPU منطقی، Load عدد ۴ رو نشون بده. همین عدد روی ماشینی با فقط یک CPU وضعیت متفاوتی داره. تازه ممکنه بخشی از بار مربوط به انتظار I/O باشه، نه پردازش واقعی روی CPU. برای همین وقتی می‌خوای بررسی CPU در لینوکس انجام بدی، خروجی top، وضعیت پردازش‌ها و زمان وقوع کندی رو کنار Load بذار؛ هیچ‌کدوم به تنهایی علت قطعی نیست.

top -b -n 1 | head -n 16
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head -n 12

فرمان top یه تصویر لحظه‌ای از سیستم می‌ده. اگه مشکل هر ربع ساعت فقط چند ثانیه ظاهر بشه، ممکنه موقع اجرا هیچ چیز غیرعادی نبینی. وقتی پردازشی بالای فهرست بود، اول مشخص کن متعلق به چه برنامه‌ایه و آیا زمان مصرفش با زمان خطا یکیه. برای رفع مشکلات لینوکس باید بدونی مصرف بالای CPU ممکنه برای یک کار سنگین کاملاً طبیعی باشه. پس قبل از kill کردن، دلیل واقعی اختلال رو پیدا کن.

بررسی رم در لینوکس؛ قدم دوم و تله عدد used

حالا بریم سراغ بررسی رم در لینوکس. یه نفر free -h می‌زنه، ستون used رو می‌بینه و می‌گه «رم پره؛ همین باعث کندیه!» ولی لینوکس بخشی از RAM رو برای Cache استفاده می‌کنه و در شرایط مناسب می‌تونه اون رو آزاد کنه. مقدار available، وضعیت Swap و رفتار برنامه خیلی مهم‌تر از قضاوت روی یک ستون هستن. هدف اینه فشار حافظه رو تشخیص بدیم، نه اینکه فقط دنبال عدد بزرگ بگردیم.

free -h
cat /proc/meminfo | grep -E '^(MemTotal|MemAvailable|SwapTotal|SwapFree):'

اگه در بررسی رم در لینوکس دیدی MemAvailable افت کرده، برنامه‌ها کند شدن و هم‌زمان پیام‌های OOM می‌بینی، فرضیه کمبود حافظه جدی‌تر می‌شه. برای رفع مشکل حافظه لینوکس اول مشخص کن چه پردازشی چقدر مصرف داره، آیا محدودیت کانتینر فعاله و مشکل از رشد غیرعادی حافظه است یا بار معمول سیستم. پاک کردن بی‌هدف Cache یا ری‌استارت پی‌درپی، جای این بررسی‌ها رو نمی‌گیره.

journalctl -k -b --no-pager | grep -Ei 'out of memory|oom-killer|killed process' | tail -n 25

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

قدم سوم: بررسی دیسک پر در لینوکس و خطاهای ذخیره‌سازی

حالا فرض کن کاربر می‌گه فایل گزارش ذخیره نمی‌شه. برای بررسی دیسک پر در لینوکس نباید فقط فضای / رو ببینی و پرونده رو ببندی؛ باید دقیقاً مسیر نوشتن برنامه رو بررسی کنی. شاید /var روی فایل‌سیستم جدا باشه، شاید Mount شبکه قطع شده یا شاید اصلاً نوشتن به خاطر مجوزها شکست خورده. برای عیب‌یابی لینوکس، فرمان‌های این بخش وضعیت رو می‌خونن و هیچ پارتیشنی رو تغییر نمی‌دن.

df -h /var
df -i /var
findmnt -T /var

کمبود Block با کمبود inode یکی نیست. خطای No space left on device می‌تونه با پر شدن ظرفیت یا تمام شدن inodeها دیده بشه؛ دلایل دیگه‌ای مثل سهمیه هم ممکنه مطرح باشن. برای رفع خطای No space left on device خروجی df -h و df -i رو برای همون مسیر بررسی کن. اگه این دو طبیعی بودن، هنوز نوبت حذف فایل نیست؛ باید Mount، محدودیت‌ها و خطای واقعی برنامه رو بیشتر ببینی.

for resource in cpu memory io; do
  if [ -r "/proc/pressure/$resource" ]; then
    printf '
[%s]
' "$resource"
    cat "/proc/pressure/$resource"
  fi
done

فایل‌های /proc/pressure/ شاخصی به اسم PSI می‌دن که درباره زمانی حرف می‌زنه که کارها به خاطر رقابت برای منابع منتظر موندن. مثلاً some avg10 نشون می‌ده در پنجره تقریباً ده‌ثانیه‌ای، چه سهمی از زمان دست‌کم بعضی کارها در انتظار بودن. توی رفع مشکلات لینوکس این عدد رو با «درصد مصرف دیسک» یکی نگیر. ممکنه بسته به نسخه Kernel، کانتینر و تنظیمات سیستم، این فایل‌ها در دسترس نباشن.

در پرونده آسانسورها، رشد صف و فشار I/O با هم رخ داده. در کنار بررسی CPU در لینوکس، حالا باید بفهمیم انتظار از کجا میاد: دیسک محلی؟ فایل‌سیستم شبکه؟ دیتابیس؟ یا یک عملیات برنامه که زمان زیادی می‌بره؟ اینجا عیب‌یابی لینوکس شبیه حل معماست؛ هر شاهد چند احتمال رو کم می‌کنه، ولی تا وقتی رفتار واقعی سرویس رو نسنجیدی حق نداری علت رو قطعی اعلام کنی.

قدم چهارم: آموزش journalctl و بررسی وضعیت سرویس در لینوکس

یه موقعیت خیلی رایج اینه که systemctl status می‌گه سرویس active (running)، اما فرم ثبت درخواست هنوز خطای ۵۰۰ می‌ده. اینجا برای رفع مشکلات لینوکس نباید خودکار سراغ ری‌استارت بری. systemd وضعیت پردازش رو بر اساس Unit می‌شناسه، نه لزوماً نتیجه کار برنامه برای کاربر رو. پس وضعیت سرویس، پاسخ واقعی درخواست و لاگ برنامه رو کنار هم بذار.

systemctl status YOUR-SERVICE.service --no-pager
systemctl --failed --no-pager
journalctl -u YOUR-SERVICE.service --since "30 minutes ago" --no-pager

در دستورهای این بخش، YOUR-SERVICE.service اسم واقعی نیست؛ قبل از اجرا باید اون رو با نام Unit خودت عوض کنی. گزینه --since کمک می‌کنه بازه زمانی مشکل رو هدف بگیری. اگه سرویس کاربریه ممکنه به --user نیاز داشته باشی، و اگه سیستم systemd نداره این فرمان‌ها جواب یکسان نمی‌دن. آموزش journalctl دقیقاً از همین شروع می‌شه: بدونی لاگ کدوم سرویس، کدوم بازه و با چه دسترسی‌ای رو می‌خونی.

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

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

فرض کن برنامه نوشته database request timeout. از این پیام نمی‌شه نتیجه گرفت Kernel لینوکس مشکل پیدا کرده. فقط می‌دونیم درخواست دیتابیس در زمان مورد انتظار جواب نداده. حالا باید شبکه بین برنامه و دیتابیس، تعداد اتصال‌ها، زمان Query و وضعیت منابع رو بررسی کنی. عیب یابی سرور لینوکس یعنی اول مشخص کنی خرابی مربوط به سیستم‌عامله یا یکی از سرویس‌های وابسته، بعد اقدام کنی.

قدم پنجم: عیب‌یابی شبکه، DNS و پورت‌های لینوکس

حالا برسیم به شبکه. وقتی مرورگر خطای اتصال می‌ده، ممکنه DNS، Route، فایروال، Reverse Proxy یا خود Listener مشکل داشته باشه. ترتیب رو رعایت کن: ببین نام دامنه به چه IPای تبدیل می‌شه، ماشین چه مسیرهایی می‌شناسه و برنامه روی چه آدرس و پورتی گوش می‌ده. برای رفع مشکل سرور لینوکس بررسی مرحله‌ای خیلی بهتر از اینه که همون اول فایروال رو خاموش کنی.

ip -brief address
ip route
ss -ltn
getent hosts nabegheha.com

دستور getent hosts nabegheha.com ممکنه برای پیدا کردن آدرس، درخواست DNS انجام بده؛ اگر تمرینت باید کاملاً آفلاین باشه، اون خط رو اجرا نکن. خروجی ss -ltn هم Listenerهای TCP محلی رو نشون می‌ده. اگه برنامه فقط روی 127.0.0.1 گوش بده، دسترسی مستقیم از بیرون محدود می‌شه؛ البته Proxy یا Port Mapping ممکنه مسیر دیگه‌ای فراهم کنه. فقط از دیدن یک خط خروجی، حکم کلی صادر نکن.

برای تست شبکه، بهتره آدرس و سرویس متعلق به محیط آزمایشی خودت رو انتخاب کنی، نه اینکه تصادفی چند سایت عمومی رو تحت فشار بذاری. با curl می‌تونی یک مسیر سلامت برنامه رو بررسی کنی، اما حواست باشه مسیر /health شاید فقط جواب بده «برنامه روشنه». هنوز معلوم نیست فرم ثبت درخواست یا اتصال دیتابیس سالمه. توی عیب‌یابی لینوکس تست باید همون کاری رو بسنجه که کاربر در اون مشکل داره.

# Only if this test application is running on your own machine:
curl -i --max-time 3 http://127.0.0.1:8080/health

نمونه curl روی پورت ۸۰۸۰ فقط وقتی معنی داره که خودت در همون ماشین برنامه آزمایشی مربوط رو راه انداخته باشی. اگه چیزی اونجا گوش نده، دریافت Connection refused طبیعی و قابل انتظاره. این شکست لزوماً نشون نمی‌ده «شبکه سرور خرابه». توی عیب‌یابی لینوکس مهم اینه که فرق نبودن Listener، Timeout و خطای HTTP رو بفهمی و هرکدوم رو در لایه درست بررسی کنی.

خط زمانی بساز؛ چون شواهد بی‌زمان گاهی گمراه‌کننده‌ان

برگردیم به ساعت ۱۰:۱۲ که پنل کند شد. حالا یکی لاگ خطای دیروز رو نشون می‌ده و می‌گه علت رو پیدا کرده. من قبول نمی‌کنم تا زمان‌ها رو کنار هم نذاریم. روی یک خط زمانی، شروع شکایت، رشد تأخیر، زیاد شدن صف، تغییرات استقرار و پیام‌های Journal رو ثبت کن. بخش مهم آموزش عیب یابی لینوکس همینه که از روی هم‌زمانی و ترتیب رخدادها، احتمال‌ها رو بسنجی.

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

چه چیزی رو باید در گزارش Incident بنویسیم؟

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

آزمایش کاملاً آفلاین : از چند عدد متناقض چه نتیجه‌ای می‌گیری؟

حالا یه تمرین کاملاً آفلاین برای عیب یابی سرور لینوکس داریم. چهار Snapshot ساختگی از وضعیت پنل آسانسورها رو داخل فایل CSV می‌ریزیم و با Python بررسی می‌کنیم چه زمانی شواهد برای بررسی صف و I/O قوی‌تر شدن. این مثال به هیچ سروری وصل نمی‌شه، هیچ سرویسی رو ری‌استارت نمی‌کنه و صرفاً فایل‌هایی در پوشه آزمایشی خودت می‌سازه. هدفش یاد گرفتن تصمیم‌گیریه، نه ساختن یک مانیتورینگ واقعی.

قدم اول : ساخت فایل‌های داده در پوشه خودت

LAB="$HOME/nb-lpic1-triage"
mkdir -p "$LAB"
cat > "$LAB/snapshots.csv" <<'CSV'
time,p95_ms,errors_5xx,cpu_pct,io_some_pct,queue_depth
10:08,220,0,18,2,12
10:10,790,1,19,14,55
10:12,2400,7,17,37,210
10:14,3600,12,18,42,420
CSV
cat "$LAB/snapshots.csv"

در فایل CSV شش ستون داریم. ستون p95_ms صدک ۹۵ زمان پاسخ رو به میلی‌ثانیه نشون می‌ده؛ یعنی در نمونه مربوط به اون بازه، حدود ۹۵٪ پاسخ‌ها در این زمان یا سریع‌تر ثبت شدن. بدون تعداد درخواست‌ها و روش نمونه‌گیری، توی عیب‌یابی لینوکس این عدد رو هم باید با احتیاط تفسیر کرد. io_some_pct این تمرین از مفهوم PSI الهام گرفته، ولی اعدادش واقعی نیستن.

قدم دوم : یک تحلیلگر کوچک بنویس

cat > "$LAB/triage.py" <<'PY'
from csv import DictReader
from pathlib import Path

path = Path.home() / "nb-lpic1-triage" / "snapshots.csv"
with path.open(encoding="utf-8", newline="") as file:
    rows = list(DictReader(file))

previous_queue = None
for row in rows:
    latency = int(row["p95_ms"])
    errors = int(row["errors_5xx"])
    cpu = int(row["cpu_pct"])
    io = int(row["io_some_pct"])
    queue = int(row["queue_depth"])

    increasing_queue = previous_queue is not None and queue > previous_queue
    warning = latency >= 2000 and errors >= 5 and io >= 30 and increasing_queue
    status = "INVESTIGATE_IO_AND_QUEUE" if warning else "COLLECT_MORE_EVIDENCE"
    print(f'{row["time"]}: {status} | cpu={cpu}% queue={queue}')
    previous_queue = queue
PY
python3 "$LAB/triage.py"

10:08: COLLECT_MORE_EVIDENCE | cpu=18% queue=12
10:10: COLLECT_MORE_EVIDENCE | cpu=19% queue=55
10:12: INVESTIGATE_IO_AND_QUEUE | cpu=17% queue=210
10:14: INVESTIGATE_IO_AND_QUEUE | cpu=18% queue=420

بعد از اجرای برنامه، دو ردیف آخر با INVESTIGATE_IO_AND_QUEUE مشخص می‌شن. دقت کن معنی این برچسب «برو فشار I/O و صف رو بیشتر بررسی کن» هست، نه «دیسک قطعاً خراب شده». آستانه‌هایی مثل ۲۰۰۰ میلی‌ثانیه رو فقط برای این داده ساختگی انتخاب کردیم. توی محیط واقعی رفع کندی سرور لینوکس باید با Baseline و نیاز همون برنامه سنجیده بشه، نه یک عدد ثابت برای همه سرورها.

برای تمرین بیشتر، یه Snapshot اضافه کن که CPU بالا رفته ولی فشار I/O پایینه. بعد یک ردیف بذار که تأخیر زیاد شده اما صف بزرگ نشده. ببین برنامه چه برچسبی می‌ده و از خودت بپرس «با چه شاهد تازه‌ای می‌تونم فرضیه رو رد کنم؟» این سؤال از حفظ کردن خروجی Python مهم‌تره. حتی یک برنامه درست هم وقتی مدل تصمیم‌گیریش ساده‌ست، قرار نیست همه مشکلات واقعی رو تشخیص بده.

قدم سوم : آزمایش رو بدون آسیب جمع کن

ls -lh "$LAB"
# If you no longer need the exercise files, remove only the lab directory you created:
# rm -r -- "$LAB"

آخر تمرین فقط فهرست فایل‌های پوشه آزمایش رو ببین. فرمان حذف رو عمداً به‌صورت Comment گذاشتم تا ناخواسته چیزی پاک نشه. اگه خواستی پوشه رو جمع کنی، قبلش مقدار متغیر LAB رو بررسی کن و مطمئن شو فقط فایل‌های همین تمرین اونجاست. توی رفع مشکلات لینوکس، همون‌قدر که اجرای درست دستور مهمه، فهمیدن اثر دستور هم مهمه.

علت کند شدن سرور لینوکس؛ وقتی Load بالاست و CPU خلوت

فرض کن Load Average بالا رفته ولی CPU هنوز خلوت به نظر می‌رسه. یکی از احتمال‌ها اینه که کارها منتظر I/O هستن، اما از خود Load به تنهایی نمی‌شه ثابتش کرد. برای بررسی CPU در لینوکس باید تعداد پردازنده‌ها، وضعیت پردازش‌ها، شاخص PSI و زمان پاسخ برنامه رو کنار هم بذاری. همین مقایسه کمک می‌کنه فرق CPU Busy و انتظار برای دیسک یا سرویس دیگه رو بفهمی.

اگه لازم شد، vmstat و در صورت نصب بودن iostat هم سرنخ‌های مفیدی می‌دن. فقط یادت باشه این ابزارها ممکنه روی یک کانتینر یا VM تصویر ناقصی از میزبان نشون بدن. بعضی خروجی‌ها هم به نمونه‌گیری در چند لحظه نیاز دارن. هدف از بررسی CPU در لینوکس این نیست که ابزارهای بیشتر نصب کنی؛ هدف اینه برای بررسی علت کند شدن سرور لینوکس داده‌ای بگیری که واقعاً به فرضیه مربوط باشه.

vmstat 1 3
# If installed:
# iostat -xz 1 3

مثلاً ستون wa در بعضی خروجی‌ها به زمان انتظار CPU برای I/O مربوطه، ولی نباید اونو معادل «درصد خرابی هارد» بخونی. موقع بررسی CPU در لینوکس، یک Snapshot کوتاه نمی‌تونه علت قطعی کندی رو مشخص کنه؛ همین‌طور نمی‌تونه تصویر کاملی از عملکرد ذخیره‌سازی بده. برای عیب‌یابی لینوکس اعداد رو در طول زمان با رفتار برنامه و شاخص‌های ذخیره‌سازی مقایسه کن؛ گاهی مشکل سمت پایگاه داده یا شبکه‌ست، نه دیسک محلی.

دستورات عیب یابی لینوکس؛ هر فرمان باید یه سؤال رو جواب بده

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

یه اشتباه خطرناک اینه که به محض دیدن اولین خطا، هر فرمانی رو با sudo اجرا کنی. تغییر فایروال، پاک کردن لاگ، نصب پکیج یا ری‌استارت سرویس همگی می‌تونن اثر جانبی داشته باشن. وقتی داری عیب یابی سرور لینوکس رو انجام می‌دی، برای رفع خطاهای لینوکس اول مشخص کن دقیقاً کدوم علامت رو می‌خوای بررسی کنی؛ بعد با کمترین سطح دسترسی و کم‌خطرترین روش جلو برو.

چهار اشتباه در رفع مشکلات لینوکس که اوضاع رو بدتر می‌کنن

اشتباه اول : پاک کردن لاگ برای خالی شدن فضا

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

اشتباه دوم : یکی دانستن Active با Healthy

این اشتباه رو توی درس systemd هم دیدیم: active بودن یک Unit تضمین نمی‌کنه کاربر خروجی سالم بگیره. شاید صفحه اصلی باز بشه ولی ثبت سفارش خطا بده؛ یا سرویس بالا باشه اما دیتابیس جواب نده. برای عیب‌یابی لینوکس یک تست واقعی از کار اصلی برنامه لازمه، نه فقط نگاه کردن به چراغ سبز سرویس.

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

فرض کن used RAM زیاده؛ فوراً می‌گی مشکل حافظه داریم. یا Load بالاست؛ نتیجه می‌گیری CPU صددرصد مشغوله. هر دو می‌تونن برداشت اشتباه باشن. در بررسی رم در لینوکس باید available و نشانه‌های OOM رو ببینی و در بررسی CPU هم تعداد پردازنده‌ها، روند و انتظار I/O رو در نظر بگیری. هیچ نموداری بدون زمینه به‌تنهایی تشخیص نهایی نیست.

اشتباه چهارم : تغییر چند چیز با هم

اگه هم‌زمان سرویس رو ری‌استارت کنی، بسته‌ها رو آپدیت کنی و تنظیم DNS رو عوض کنی، بعد از بهتر شدن وضعیت نمی‌فهمی کدوم اقدام مؤثر بوده. توی عیب‌یابی لینوکس تا جایی که شرایط اجازه می‌ده، تغییرها رو یکی‌یکی و قابل بازگشت انجام بده. روی Production شاید اقدامات اضطراری لازم باشن، اما حتی اون‌جا هم باید محدوده تغییر و روش سنجش نتیجه روشن باشه.

تمرین نهایی : سه پرونده کوتاه، سه تصمیم متفاوت

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

پرونده اول : سرویس فعال است اما فرم خطا می‌دهد

اینجا systemctl status سرویس رو active نشون می‌ده ولی فرم خطای ۵۰۰ برمی‌گردونه. اول زمان اختلال، مسیر درخواست و لاگ مرتبط رو مشخص کن. بعد یک درخواست آزمایشی قابل تکرار بفرست و وضعیت سرویس‌های وابسته رو ببین. ری‌استارت کور ممکنه برای چند دقیقه نشونه رو پنهان کنه، اما به‌خودی‌خود علت رو معلوم نمی‌کنه.

پرونده دوم : Load زیاد و CPU پایین است

اینجا Load بالاست ولی CPU کم‌کار به نظر می‌رسه. وضعیت پردازش‌های منتظر، فشار I/O و خروجی vmstat رو با زمان کندی مقایسه کن. اگه ابزار PSI در دسترسه، می‌تونه سرنخ دیگه‌ای بده. توی رفع مشکلات لینوکس با یک عدد Load نه باید رم اضافه کنی، نه سرویس رو بکشی و نه دیسک رو مقصر قطعی بدونی.

پرونده سوم : فقط کاربران بیرونی به سایت نمی‌رسن

در این پرونده، درخواست از داخل ماشین جواب می‌ده ولی کاربران بیرونی نمی‌تونن متصل بشن. مسیر DNS، Route، Firewall، Reverse Proxy و آدرس Listener رو یکی‌یکی بررسی کن. اگر برنامه روی Loopback گوش می‌ده، از همون اول بدون دسترسی مستقیم بیرونی محدود می‌شه؛ البته Port Mapping و Proxy می‌تونن مسیر متفاوتی بسازن. تست محلی فقط بخشی از راه رو بررسی کرده.

چطور مطمئن بشیم عیب‌یابی لینوکس واقعاً نتیجه داده؟

فرض کن خطای لاگ بعد از تغییر تنظیمات ناپدید شد. خوبه، ولی هنوز پرونده بسته نشده. همون عملیات خراب رو از نگاه کاربر دوباره اجرا کن، زمان پاسخ و نرخ خطا رو با قبل مقایسه کن و اگر ممکنه رفتار سرویس رو در بازه پیک مصرف هم ببین. هدف عیب‌یابی لینوکس این نیست که فقط یک پیام خطا رو پاک کنیم؛ باید خدمت واقعاً سالم شده باشه.

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

آموزش LPIC-1؛ این درس عیب‌یابی کجای مسیر قرار می‌گیره؟

اگه برای آموزش LPIC-1 این درس رو می‌خونی، بدون که عیب‌یابی یک بخش مستقل با همین عنوان در تمام فهرست آزمون نیست؛ این صفحه چند مهارت جدا رو ترکیب می‌کنه. از لاگ و systemd گرفته تا حافظه، فایل‌سیستم و شبکه، باید بتونی مفهوم هر ابزار رو در جای درست به کار ببری. برای مقایسه با سرفصل‌های رسمی، صفحه رسمی LPIC-1 و اهداف نسخه ۵ رو ببین.

اگه موقع حل تمرین احساس کردی یکی از مباحث رو خوب یادت نیست، می‌تونی برگردی سراغ درس بوت لینوکس، مدیریت سرویس با systemd، مدیریت پکیج‌ها یا مدیریت دیسک و Mount. این درس‌ها جای هم رو نمی‌گیرن؛ اینجا از همون دانش برای عیب‌یابی لینوکس در یک مسئله ترکیبی استفاده می‌کنیم.

اگه می‌خوای مباحث مدیریت سیستم رو عمیق‌تر تمرین کنی و برای آزمون آماده بشی، می‌تونی سرفصل‌های پکیج کامل LPIC-1 نابغه‌ها رو ببینی. پیشنهاد من اینه قبل از انتخاب دوره، سطح فعلی و هدف خودت رو با سرفصل‌ها مقایسه کنی. این مقاله یه نقطه شروع برای مفهوم Linux Server Troubleshooting یا عیب‌یابی سرورهای لینوکسه، نه جایگزین تمرین‌های گسترده روی ماشین‌های آزمایشگاهی.

منابع معتبر و چند نکته برای مطالعه بیشتر

برای اینکه بتونی رفتار ابزارها رو خودت هم بررسی کنی، منابع رسمی رو گذاشتم: راهنمای uptime برای Load Average، مستندات Kernel درباره PSI و راهنمای journalctl. سناریوی آسانسورها، داده‌ها و چارچوب پنج‌مرحله‌ای مخصوص این آموزش ساخته شدن؛ نباید اون‌ها رو گزارش یک حادثه واقعی فرض کنی.

در آخر فقط این رو یادت بمونه: دستور خوب، دستوریه که به یک سؤال درست جواب بده. دفعه بعد کسی گفت «لینوکس مشکل داره»، اول علامت رو دقیق کن، زمان رو ثبت کن، شاهد جمع کن، فرضیه قابل آزمایش بساز و در پایان نتیجه واقعی رو بسنج. اگه همین پنج قدم رو توی عیب‌یابی لینوکس جدی بگیری، هم اشتباه‌های کم‌خطرتر انجام می‌دی، هم از دستورهای بیشتری واقعاً سر درمیاری.

سؤالات متداول درباره عیب‌یابی لینوکس