محتوای آموزشی وبلاگ نت‌آرام
فضای سرور لینوکسی کم شده و دستور
journalctl --disk-usage نشان می‌دهد گزارش‌های systemd حجم زیادی گرفته‌اند. گزارش‌ها برای پیدا کردن علت قطعی، خطاهای امنیتی و بازسازی اتفاقات سرور مفیدند؛ بنابراین پاک‌کردن همه آن‌ها اولین راه‌حل خوبی نیست. ابتدا مشخص می‌کنیم واقعاً چه مقدار فضا متعلق به journal است، بعد در صورت مجاز بودن نگهداری کوتاه‌تر، فقط گزارش‌های آرشیوی قدیمی را کم می‌کنیم و علت رشد را پیدا می‌کنیم.این راهنما برای سرور لینوکسی دارای systemd، مانند نسخه‌های رایج Ubuntu و AlmaLinux، و برای مدیری است که دسترسی SSH یا کنسول و مجوز
sudo دارد. روی هاست اشتراکی معمولاً چنین دسترسی‌ای ندارید. اگر سرور در حال اختلال است، پیش از هر تغییر زمان و نوع پیام‌های مهم را ثبت و با تیم مدیریت هماهنگ کنید. مدت نگهداری موردنیاز کسب‌وکار، قرارداد یا بررسی رخداد امنیتی بر هر عدد نمونه این مقاله مقدم است.۱. بررسی کنید واقعاً journal عامل کمبود فضاست
در ترمینال خود سرور، ابتدا ظرفیت فایل‌سیستم‌ها را ببینید:
کد / دستورdf -hT
df -i
فرمان اول حجم و نوع فایل‌سیستم و فرمان دوم وضعیت inode، یعنی ظرفیت نگهداری تعداد فایل‌ها، را نشان می‌دهد. به محل نصب هر فایل‌سیستم دقت کنید. پرشدن inode یا پارتیشن دیگری مثل محل بکاپ، با کم‌کردن journal لزوماً حل نمی‌شود. مسیرهای دقیق سرور شما ممکن است با مثال فرق داشته باشند.
حالا از خود systemd اندازه گزارش‌های journal را بخواهید:
کد / دستورsudo journalctl --disk-usage
sudo journalctl --list-boots
خروجی اول مجموع فایل‌های فعال و آرشیوی journal را نشان می‌دهد. دستور دوم بوت‌هایی را که گزارششان در دسترس است فهرست می‌کند. اگر journal فقط چندصد مگابایت است ولی ده‌ها گیگابایت فضا کم دارید، سراغ راهنمای پیدا کردن مصرف دیسک نیز بروید. فایل‌های متنی مثل لاگ وب‌سرور یا Docker و بکاپ‌ها الزاماً جزو این عدد نیستند.
محل نگهداری هم مهم است:
کد / دستورfindmnt -T /var/log
findmnt -T /run/log
sudo du -sh /var/log/journal /run/log/journal 2>/dev/null
اگر یکی از پوشه‌ها وجود ندارد، نبود خروجی برای آن طبیعی است. در بسیاری از نصب‌ها
/var/log/journal روی دیسک و /run/log/journal روی حافظه موقت است. نتیجه findmnt تعیین می‌کند هر مسیر واقعاً روی کدام فایل‌سیستم قرار دارد. پاک‌سازی لاگ در حافظه لزوماً فضای پارتیشن دیسک را آزاد نمی‌کند. در سرورهای دارای فضای نام journal یا تنظیم اختصاصی، مسیرها و سهم‌ها ممکن است متفاوت باشند.۲. قبل از حذف، گزارش مهم را حفظ کنید
اگر در حال بررسی رخداد امنیتی، شکایت مشتری یا علت قطعی هستید، اول گزارش لازم را خارج از همان سرور و در محل امن نگه دارید. نمونه زیر لاگ ۲۴ ساعت گذشته را در پوشه خانه کاربر فعلی ذخیره می‌کند:
کد / دستورsudo journalctl --since '24 hours ago' --no-pager > ~/journal-last-24h.txt
ls -lh ~/journal-last-24h.txt
دستور دوم وجود و اندازه فایل را نشان می‌دهد، اما جایگزین بازکردن و بررسی محتوا نیست. این فایل می‌تواند نام کاربر، آدرس شبکه یا اطلاعات حساس داشته باشد؛ در پوشه عمومی سایت قرارش ندهید و با روش امن منتقلش کنید. اگر دیسک واقعاً پر است، خروجی روی همان دیسک ممکن است شکست بخورد؛ ابتدا مقصد امنی با فضای کافی فراهم کنید. برای حفظ سوابق با قالب و جزئیات موردنیاز سازمان، روش پشتیبان‌گیری و نگهداری مورد تأیید همان سازمان را انتخاب کنید.
۳. عامل تولید حجم را پیدا کنید
پیش از کاهش حجم، پیام‌های اخیر را ببینید تا گزارش‌ها دوباره در چند ساعت پر نشوند:
کد / دستورsudo journalctl -p warning -b -n 100 --no-pager
sudo journalctl -b -n 100 --no-pager
دستور اول صد هشدار اخیر و شدیدتر را از بوت جاری نشان می‌دهد؛ دستور دوم صد پیام اخیر با هر سطحی را نمایش می‌دهد. اگر نام سرویسی بارها تکرار شده، وضعیت همان سرویس را ببینید. به‌جای نام نمونه، نام واقعی را قرار دهید:
کد / دستورsudo systemctl status example.service --no-pager
sudo journalctl -u example.service --since '1 hour ago' -n 100 --no-pager
مثلاً اگر سرویس هر چند ثانیه به علت نبودن رمز یا قطع اتصال دیتابیس خطا می‌دهد، باید همان تنظیم یا اتصال را اصلاح کنید. توقف یک سرویس ضروری فقط برای کم‌شدن لاگ می‌تواند قطعی ایجاد کند؛ اول اثر آن را بشناسید. همچنین عوض‌کردن سطح گزارش بدون رفع علت، ممکن است نشانه مشکل را پنهان کند.
۴. فقط در صورت مجاز بودن، آرشیو قدیمی را کم کنید
بعد از اطمینان از نگهداری لازم و تهیه نسخه موردنیاز، این نمونه گزارش‌های آرشیوی قدیمی‌تر از ۱۴ روز را برای پاک‌سازی انتخاب می‌کند:
کد / دستورsudo journalctl --vacuum-time=14d
sudo journalctl --disk-usage
عدد ۱۴ صرفاً مثال است، نه توصیه یکسان برای همه سرورها. راه جایگزین، تعیین سقف برای آرشیو است؛ نمونه زیر قدیمی‌ترین آرشیوها را تا رسیدن به سقف درخواستی کاهش می‌دهد:
کد / دستورsudo journalctl --vacuum-size=1G
sudo journalctl --disk-usage
این دو روش اختیاری و مستقل‌اند؛ لازم نیست هر دو را اجرا کنید. خروجی عملیات و اندازه بعدی را ببینید. فایل‌های فعال با vacuum حذف نمی‌شوند و اندازه گزارش‌شده می‌تواند پس از آن هم از عدد درخواستی بیشتر بماند. اگر فقط چند فایل فعال بزرگ وجود دارد، کاهش چشمگیر فوری تضمین نمی‌شود. بدون شناخت شرایط، فایل‌های داخل پوشه journal را دستی حذف نکنید و در زمان پر بودن کامل دیسک، عملیات پرحجم دیگری راه نیندازید.
۵. برای آینده محدودیت قابل بازگشت بگذارید
در systemd،
کد / دستورSystemMaxUse برای journal پایدار و RuntimeMaxUse برای journal موقت هستند. سقف را بر اساس ظرفیت سرور و مدت گزارش موردنیاز انتخاب کنید. برای نمونه، اگر journal شما پایدار است و یک گیگابایت با نیاز شما سازگار است، مدیر سرور می‌تواند یک فایل تنظیم جداگانه بسازد. ابتدا بررسی کنید فایل همنام وجود نداشته باشد:sudo ls -la /etc/systemd/journald.conf.d/
نبودن پوشه در بعضی نصب‌ها طبیعی است. در صورت نیاز آن را بسازید، سپس با ویرایشگر دلخواه فایل تازه‌ای مانند
کد / دستور/etc/systemd/journald.conf.d/90-retention-local.conf ایجاد کنید. اگر فایلی با همین نام دارید، به‌جای بازنویسی آن ابتدا محتوایش را بررسی و حفظ کنید:sudo mkdir -p /etc/systemd/journald.conf.d
sudo nano /etc/systemd/journald.conf.d/90-retention-local.conf
فرمان اول پوشه تنظیمات را در صورت نبودن می‌سازد و دومی ویرایشگر nano را باز می‌کند؛ اگر nano روی سرور نصب نیست، از ویرایشگر مورد اعتماد خود استفاده کنید. خطوط زیر را در فایل تازه قرار دهید و ذخیره کنید:
کد / دستور[Journal]
SystemMaxUse=1G
SystemKeepFree=2G
گزینه اول سقف موردنظر journal پایدار را تعیین می‌کند و گزینه دوم می‌خواهد مقداری فضای آزاد برای بقیه سیستم باقی بماند. این اعداد نمونه‌اند؛ روی دیسک کوچک یا زمانی که نگهداری طولانی لازم است باید متفاوت انتخاب شوند. systemd هر دو محدودیت را در نظر می‌گیرد، ولی به دلیل فعال‌بودن برخی فایل‌ها و شرایط شروع سرویس، این سقف مثل یک کلید آزادسازی فوری همه فضا عمل نمی‌کند. برای journal موقت باید تنظیم Runtime متناسب را جداگانه بررسی کرد.
پس از ذخیره، در زمان مناسب سرویس journal را راه‌اندازی مجدد و وضعیتش را بررسی کنید:
کد / دستورsudo systemctl restart systemd-journald
sudo systemctl is-active systemd-journald
sudo journalctl --disk-usage
df -hT
خروجی
active یعنی سرویس در آن لحظه فعال است؛ علاوه بر آن، بعد از چند دقیقه وجود گزارش تازه و وضعیت فضا را ببینید. اگر مشکل پیش آمد، فایل تازه را با بازگرداندن نسخه قبلی یا حذف همان تنظیم تازه ایجادشده برگردانید و سرویس را دوباره راه‌اندازی کنید. تنظیمات دیگر را دست نزنید. اگر در انتخاب سقف یا رفع علت تولید خطا نیاز به همراهی دارید، خدمات مدیریت سرور نت‌آرام را ببینید. جزئیات گزینه‌ها در مستند رسمی journald و راهنمای journalctl آمده است.اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام