محتوای آموزشی وبلاگ نت‌آرام
تا دیشب گزارش درخواست‌های وب‌سرور ثبت می‌شد، اما امروز فایل جدید خالی است یا خطای دسترسی دیده می‌شود. گاهی هم درخواست‌های تازه هنوز به فایل قدیمی با پسوند چرخش نوشته می‌شوند. این دو مشکل یکسان نیستند: اولی می‌تواند از ساخت فایل با مالک یا مجوز نامناسب باشد و دومی از بازنشدن دوباره فایل پس از تغییر نام آن.
فرمان‌های این راهنما برای مدیر لینوکس هستند. چرخش اجباری گزارش فعال، حذف فایل لاگ یا بازنشانی کل تنظیمات می‌تواند شواهد را از بین ببرد. ابتدا فقط بخوانید و نمونه جداگانه بسازید.
۱. معلوم کنید کدام فایل نوشته می‌شود
در مثال زیر مسیرها فرضی‌اند؛ آن‌ها را با مسیر واقعی access log همان وب‌سایت جایگزین کنید:
کد / دستورsudo ls -l /var/log/nginx/access.log*
sudo stat /var/log/nginx/access.log
sudo journalctl -u nginx -n 50 --no-pager
دستور اول نام، اندازه، مالک و مجوز فایل فعلی و نسخه‌های نزدیک را نمایش می‌دهد.
stat جزئیات فایل کنونی را می‌دهد و journalctl پیام‌های اخیر سرویس را نشان می‌دهد. نام سرویس یا محل گزارش ممکن است در توزیع شما متفاوت باشد. نشانی‌ها و اطلاعات شخصی موجود در لاگ را عمومی منتشر نکنید.یک درخواست کوچک و بی‌خطر به صفحه آزمایشی خود بفرستید و زمان و رشد فایل فعلی و فایل چرخیده را مقایسه کنید. اگر فایل قدیمی رشد می‌کند، مشکل احتمالاً در بازشدن مجدد خروجی است. اگر هیچ‌کدام رشد نمی‌کند، وضعیت پیکربندی لاگ، خطاهای سرویس، مسیر، دسترسی و فضای دیسک را بررسی کنید. نبود درخواست به تنهایی دلیل خرابی نیست.
۲. تنظیم واقعی logrotate را بخوانید
ابتدا فایل اصلی و قاعده مربوط به سرویس را بدون ویرایش ببینید. این دستور حالت تشخیصی را اجرا می‌کند و خودش فایل‌های گزارش را نمی‌چرخاند:
کد / دستورsudo logrotate -d /etc/logrotate.conf
خروجی ممکن است طولانی باشد؛ مسیر همان فایل و خطاهای قاعده مربوط را پیدا کنید. گزینه
-d اجرای واقعی نیست و ثابت نمی‌کند همه فرمان‌های بعدی در محیط عملیاتی موفق می‌شوند. محل فایل قاعده اغلب زیر /etc/logrotate.d/ است، ولی ساختار هر توزیع می‌تواند متفاوت باشد. از فایل تنظیم مربوط پیش از تغییر، نسخه پشتیبان بگیرید.گزینه
create می‌تواند پس از چرخش فایل تازه‌ای با حالت، مالک و گروه مشخص بسازد. مقدار درست به کاربری که واقعاً فایل را باز می‌کند و پیکربندی همان سرویس بستگی دارد. برای Nginx ممکن است فرایند اصلی و workerها نقش‌های متفاوتی در بازکردن لاگ داشته باشند؛ نام کاربری یک راهنمای دیگر را کورکورانه برای سرور خود کپی نکنید.۳. مالکیت و امکان عبور از مسیر را بررسی کنید
namei -l /var/log/nginx/access.log مجوز اجزای مسیر را نشان می‌دهد. systemctl cat nginx تنظیم سرویس systemd را نمایش می‌دهد، اما لزوماً تمام اطلاعات کاربران فرایند را مشخص نمی‌کند. مدیر باید کاربر و گروه واقعی فرایند، مالک فایل و پیام خطا را کنار هم بگذارد. در سیستم دارای SELinux برچسب و گزارش رد دسترسی نیز مهم است.اگر فایل تازه ساخته شده ولی مجوزش با نیاز واقعی سرویس ناسازگار است، مقدار
create را در قاعده همان گزارش با مالک و گروه تأییدشده اصلاح کنید. برای نمونه، شکل کلی create 0640 owner group است؛ owner و group در این جمله جای‌نگهدارند و دستور آماده کپی نیستند. در نظر بگیرید چه کسی باید لاگ را بخواند؛ بازکردن مجوز نوشتن برای همه یا chmod 777 راه‌حل مناسب نیست. ACLهای قبلی نیز ممکن است با ساخت فایل تازه حفظ نشوند.۴. بازشدن مجدد فایل را جدا بررسی کنید
پس از تغییر نام لاگ قدیمی، برنامه باید مطابق روش خودش فایل جدید را باز کند. Nginx از درخواست بازکردن مجدد لاگ پشتیبانی می‌کند و بسیاری از بسته‌ها در
postrotate روش مخصوص توزیع را قرار می‌دهند. همان دستور بسته نصب‌شده و نتیجه آن را بخوانید؛ نام سرویس، مسیر PID و مجوزها ممکن است فرق کند. کپی یک دستور سیگنال از سایت دیگر بدون بررسی PID می‌تواند به فرایند اشتباه برسد.اگر از
copytruncate استفاده می‌کنید، رفتار آن با روش تغییر نام و بازکردن مجدد متفاوت است و در فاصله کپی و کوتاه‌کردن ممکن است بخشی از داده ثبت‌شده از دست برود. بدون درک نیاز برنامه بین این روش‌ها جابه‌جا نشوید. نتیجه موفق فرمان نیز باید با یک درخواست واقعی و مشاهده رشد فایل تازه تأیید شود.۵. چرخش را روی فایل آزمایشی تمرین کنید
در ترمینال حساب خود، خارج از مسیر لاگ واقعی، این نمونه یک پوشه تصادفی و قاعده مستقل می‌سازد:
کد / دستورdemo=$(mktemp -d)
printf 'test line\n' > "$demo/demo.log"
cat > "$demo/logrotate.conf" <<EOF
$demo/demo.log {
size 1
rotate 2
create 0600
}
EOF
logrotate -v -s "$demo/status" "$demo/logrotate.conf"
ls -l "$demo"
mktemp پوشه تازه می‌سازد، قاعده فقط فایل داخل همان پوشه را هدف می‌گیرد و -s وضعیت جداگانه نگه می‌دارد. پس از اجرا، فایل تازه و نسخه چرخیده را مقایسه کنید؛ مقدار دقیق نام می‌تواند به تنظیمات وابسته باشد. این آزمون به Nginx سیگنال نمی‌دهد و جای تست واقعی مسیر بازشدن لاگ را نمی‌گیرد. پس از شناسایی دقیق پوشه آزمایشی می‌توانید آن را طبق سیاست خود پاک کنید.۶. بررسی پس از اصلاح
در زمان مناسب، پس از بازبینی تنظیمات و روش بازگشت، با روش عملیاتی خود چرخش بعدی را زیر نظر بگیرید. یک درخواست آزمایشی بدهید و ببینید فایل تازه رشد می‌کند، خطای سرویس تکرار نمی‌شود و فایل قدیمی بی‌دلیل تغییر نمی‌کند. اگر باز هم خالی است، وضعیت ارسال لاگ به journald یا سامانه متمرکز را نیز بررسی کنید؛ همه سرویس‌ها الزاماً در فایل محلی نمی‌نویسند.
برای کنترل حجم گزارش‌های systemd، راهنمای نگهداری امن journald و برای خدمات مدیریت سرور نت‌آرام را ببینید. جزئیات گزینه‌ها در راهنمای logrotate و راهنمای بازکردن مجدد لاگ Nginx آمده است.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام