محتوای آموزشی وبلاگ نت‌آرام
هنگام بررسی گزارش‌های سرور مجازی ایران به پیامی مانند
Suppressed 500 messages from myapp.service می‌رسید. این یعنی سیستم ثبت گزارش در یک بازه تعداد زیادی پیام از آن سرویس دریافت کرده و بخشی از پیام‌های اضافی را ذخیره نکرده است. در نتیجه ممکن است دقیقاً همان لاگی که برای فهم خطا نیاز دارید وجود نداشته باشد.محدودیت نرخ برای جلوگیری از سیل گزارش و فشار بر سرور مفید است. بالا بردن بی‌حساب آن می‌تواند فضای دیسک و توان ذخیره‌سازی را مصرف کند، و از طرف دیگر پیام‌های حذف‌شده را برنمی‌گرداند. ابتدا مشخص می‌کنیم کدام سرویس چه چیزی را بیش از حد تکرار می‌کند و سپس، اگر لازم بود، محدودیت همان سرویس را متناسب با ظرفیت تغییر می‌دهیم.
۱. پیام و سرویس ایجادکننده را پیدا کنید
در ترمینال لینوکس، با حساب دارای مجوز خواندن journal اجرا کنید:
کد / دستورsudo journalctl -b --no-pager | grep -i 'suppressed'
sudo journalctl -u systemd-journald --since '24 hours ago' --no-pager
systemd --version
دستور اول پیام‌های دارای کلمه نمونه را در بوت فعلی فیلتر می‌کند؛ دومی گزارش خود journald را در بازه انتخاب‌شده می‌خواند و سومی نسخه را نشان می‌دهد. زمان پیام، تعداد و نام واحد یا گروه درج‌شده در آن را یادداشت کنید. نمایش و متن دقیق در توزیع‌ها فرق دارد و نبود این کلمه به‌تنهایی ثابت نمی‌کند هیچ پیامی از دست نرفته است.
اگر بعد از ریبوت دنبال مشکل قدیمی هستید، فقط در صورت نگه‌داری journal قبلی از
sudo journalctl -b -1 --no-pager استفاده کنید. اگر هیچ گزارش سرویس را نمی‌بینید، ابتدا نام واحد، دسترسی و محل ذخیره را با راهنمای دیده‌نشدن لاگ در journalctl بررسی کنید؛ موضوع این مقاله پیام مشخص محدودشدن نرخ است.۲. ببینید سرویس چه چیزی را تکرار می‌کند
نام نمونه را با واحد واقعی جایگزین کنید:
کد / دستورsudo journalctl -u myapp.service --since '30 minutes ago' --no-pager
systemctl status myapp.service --no-pager -l
systemctl cat myapp.service
به پیام‌های قبل و بعد از زمان Suppressed نگاه کنید. اگر برنامه هر ثانیه به یک پایگاه داده در دسترس‌نبودنی وصل می‌شود و خطا می‌نویسد، ابتدا اتصال و فاصله تلاش دوباره را طبق تنظیم برنامه درست کنید. اگر سطح debug در محیط عملیاتی روشن مانده، بعد از هماهنگی آن را به سطح مناسب برگردانید. خاموش‌کردن همه خطاها یا پنهان‌کردن یک خطای امنیتی راه‌حل نیست.
ممکن است سرویس عمداً در لحظه راه‌اندازی انبوهی پیام ارزشمند تولید کند. تعداد تقریبی پیام در دوره اوج و اهمیت آن‌ها را با تیم برنامه روشن کنید. سرویس‌هایی که مستقیم در فایل می‌نویسند لزوماً از محدودیت journald پیروی نمی‌کنند؛ مقصد گزارش را از تنظیم برنامه و واحد بخوانید. محدودیت یک ابزار دریافت‌کننده دیگر مثل rsyslog نیز باید جداگانه بررسی شود.
۳. ظرفیت و تنظیم فعلی را بررسی کنید
کد / دستورjournalctl --disk-usage
df -h /var/log /run
systemctl show myapp.service -p LogRateLimitIntervalUSec -p LogRateLimitBurst
خروجی اول حجم journalهای موجود را نشان می‌دهد و
df فضای فایل‌سیستم مسیرهای نمونه را نمایش می‌دهد. بسته به حالت ذخیره‌سازی، journal ممکن است در مسیر موقت یا پایدار باشد. نام property نمایش‌داده‌شده و پشتیبانی از آن به نسخه systemd بستگی دارد؛ اگر ناشناخته بود، از مستند همان نسخه استفاده کنید. تنظیم سراسری را در فایل‌های پیکربندی journald و drop-inها بررسی کنید، اما عدد کامنت‌شده لزوماً تنظیم فعال نیست.طبق مستند journald، محدودیت معمولاً برای هر سرویس جدا اعمال می‌شود و مقدار مؤثر می‌تواند به فضای آزاد journal وابسته باشد. بنابراین عدد تنظیم‌شده را به‌عنوان تعداد تضمین‌شده پیام در هر شرایطی در نظر نگیرید. بزرگ‌تر کردن نرخ بدون سیاست نگه‌داری، نظارت بر فضا و تخمین حجم گزارش می‌تواند مشکل دیگری بسازد.
۴. اول علت سیل پیام را برطرف کنید
اگر لاگ‌ها از تلاش تکراری ناشی می‌شوند، علت همان خطا را رفع و فاصله تلاش را در تنظیم خود برنامه بیشتر کنید. مثلاً وقتی نام میزبان پایگاه داده اشتباه است، اصلاح نام و بررسی اتصال از سرور می‌تواند هزاران پیام تکراری را متوقف کند. بعد از تغییر، همان درخواست را دوباره انجام دهید و تعداد خطاها و سلامت برنامه را در یک بازه مشابه بسنجید.
اگر خطا ناشی از ورودی نامعتبر کاربران است، افزون بر رفع خطای برنامه، نرخ درخواست‌ها و سیاست امنیتی سرویس را بررسی کنید. حذف موقت منبع پیام بدون حل علت، ممکن است پس از شروع مجدد دوباره سیل را ایجاد کند. اگر به همه رخدادها برای حسابرسی نیاز دارید، معماری ثبت امن و ظرفیت لازم را جداگانه با مسئول آن طراحی کنید.
۵. فقط در صورت نیاز محدودیت همان سرویس را تنظیم کنید
در systemd نسخه ۲۴۰ و جدیدتر، گزینه‌های per-unit زیر در نسخه‌های پشتیبان در دسترس‌اند. ابتدا دستور
کد / دستورsystemd --version و مستند systemd.exec همان نسخه را تطبیق دهید. در پنجره نگه‌داری و پس از ثبت تنظیم قبلی، برای سرویس نمونه اجرا کنید:sudo systemctl edit myapp.service
برای مثال می‌توانید در فایل تکمیلی مقدار مشخصی ثبت کنید:
کد / دستور[Service]
LogRateLimitIntervalSec=30s
LogRateLimitBurst=20000
این اعداد فقط مثال‌اند، نه مقدار پیشنهادی برای همه سرورها. محدودیت واحد می‌تواند تنظیم سراسری journald را برای پیام‌های همان سرویس جایگزین کند. مقدار مناسب را از حجم پیام واقعی، مدت اوج، فضای آزاد و نیاز نگه‌داری انتخاب کنید. صفرکردن محدودیت برای همیشه می‌تواند در زمان خرابی حجم زیادی گزارش تولید کند؛ تغییر را محدود و قابل بازگشت نگه دارید.
پس از ذخیره، در زمان مناسب اعمال کنید:
کد / دستورsudo systemctl daemon-reload
systemctl cat myapp.service
sudo systemctl restart myapp.service
systemctl status myapp.service --no-pager -l
راه‌اندازی مجدد می‌تواند سرویس را موقتاً قطع کند؛ پیش از آن هماهنگی و روش بازگشت داشته باشید. اگر دستور
systemctl edit از قبل drop-in دیگری باز می‌کند، تنظیم‌های قبلی همان فایل را حفظ کنید. گزینه‌های ناشناخته یا اخطارهای نسخه را در journal بخوانید؛ وجود متن در فایل به‌تنهایی به معنی اعمال‌شدن آن نیست.۶. نتیجه و راه بازگشت
در بازه‌ای مشابه بار قبلی، پیام‌های جدید سرویس، رخدادهای Suppressed، حجم journal و فضای آزاد را پایش کنید. نبود یک پیام Suppressed به‌تنهایی اثبات ثبت همه پیام‌ها نیست؛ برای سنجش دقیق، یک رویداد آزمایشی مشخص یا شمارنده برنامه را با پیام‌های ثبت‌شده مقایسه کنید. پیام‌های قبلاً حذف‌شده از راه افزایش سقف بازیابی نمی‌شوند.
اگر تغییر باعث رشد غیرعادی لاگ شد یا اثری نداشت، با
sudo systemctl edit myapp.service فقط همان دو تنظیم را به مقدار قبلی برگردانید، daemon را reload و سرویس را در زمان مجاز بازراه‌اندازی کنید. سپس مقصد ثبت، فیلتر سطح لاگ و محدودیت ابزار جمع‌آوری بعدی را جداگانه بررسی کنید. برای مدیریت فایل‌های چرخشی معمول لینوکس، راهنمای قفل logrotate به مشکلی متفاوت می‌پردازد.اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام