محتوای آموزشی وبلاگ نت‌آرام
برنامه روی سرور خطا می‌دهد، اما وقتی
journalctl را باز می‌کنید چیزی نمی‌بینید. خالی‌بودن خروجی الزاماً به معنی نداشتن خطا نیست. ممکن است نام سرویس را اشتباه نوشته باشید، بازه زمانی درست انتخاب نشده باشد، حساب شما به گزارش دسترسی نداشته باشد یا برنامه اصلاً گزارش خود را در فایل دیگری بنویسد.در این آموزش از خواندن وضعیت سرویس شروع می‌کنیم و سپس محل ثبت گزارش و باقی‌ماندن آن پس از ریبوت را بررسی می‌کنیم. دستورها برای مدیر مجاز سرور لینوکسی دارای systemd هستند. نام
example.service در این مطلب فقط نمونه است؛ در هر دستور نام واقعی سرویس خود را جایگزین کنید.پیش از شروع، این اطلاعات را یادداشت کنید
نام برنامه و زمانی را که خطا اتفاق افتاده بنویسید. اگر بعد از ریبوت دنبال خطای قبل هستید، مشخص کنید خطا مربوط به بوت فعلی بوده یا بوت قبلی. همچنین بدانید برنامه روی خود سرور اجرا می‌شود یا داخل کانتینر؛ گزارش یک کانتینر لزوماً با نام سرویس میزبان در journal دیده نمی‌شود.
لاگ می‌تواند نشانی مشتری، شناسه نشست، رمز یا اطلاعات خصوصی داشته باشد. خروجی کامل را در سایت عمومی قرار ندهید و پیش از ارسال برای پشتیبانی اطلاعات حساس را حذف کنید. دستورهای خواندن گزارش را با دستور حذف لاگ یا پاک‌سازی فضای دیسک اشتباه نگیرید.
مرحله اول: نام دقیق واحد systemd را پیدا کنید
اگر تصور می‌کنید نام سرویس
کد / دستورexample است، در ترمینال همان سرور اجرا کنید:systemctl status example.service --no-pager -l
نام نمونه را با نام واقعی جایگزین کنید. این فرمان وضعیت واحد و بخشی از اطلاعات اخیر را نشان می‌دهد؛ چیزی را تغییر نمی‌دهد. اگر پیام
Unit ... could not be found دیدید، آن نام در این سیستم پیدا نشده است. ممکن است سرویس نام دیگری داشته باشد، در سطح کاربر اجرا شود یا اصلاً توسط systemd مدیریت نشود.برای دیدن فهرست واحدهای سرویس بارگذاری‌شده می‌توانید از دستور زیر استفاده کنید:
کد / دستورsystemctl list-units --type=service --all --no-pager
نام کامل و وضعیت واحد موردنظر را در خروجی پیدا کنید. برای نمونه، Apache در برخی توزیع‌ها
apache2.service و در برخی دیگر httpd.service نام دارد. واحدهای نمونه‌دار نیز ممکن است نامی مثل program@instance.service داشته باشند؛ نام واقعی را از وضعیت سیستم بخوانید، نه از مثال اینترنت.اگر برنامه به‌صورت سرویس کاربری اجرا می‌شود، نشست همان کاربر ممکن است به فرمان
systemctl --user نیاز داشته باشد. سرویس سیستم و سرویس کاربری دو زمینه متفاوت‌اند. درباره کانتینر نیز نام برنامه و روش ثبت گزارش را از ابزار مدیریت همان کانتینر بگیرید.مرحله دوم: بدون محدودیت اضافی و با دسترسی مناسب بخوانید
با نام واقعی سرویس، ابتدا آخرین پیام‌های قابل دسترس را ببینید:
کد / دستورsudo journalctl -u example.service -n 100 --no-pager
-u گزارش‌های مرتبط با واحد، -n 100 حداکثر صد پیام اخیر و --no-pager نمایش در همان خروجی را درخواست می‌کند. در حساب root پیشوند sudo لازم نیست. اگر بدون sudo گزارش خالی است ولی با حساب مدیریتی پیام دیده می‌شود، مشکل می‌تواند سطح دسترسی به journal باشد؛ فایل‌های لاگ را برای همه کاربران دنیا قابل خواندن نکنید، چون ممکن است اطلاعات حساس داشته باشند.اگر پیام‌هایی می‌بینید، ساعت و متن خطای مرتبط را با زمان رخداد مقایسه کنید. اگر فقط پیام‌های قدیمی می‌بینید، به این معنی نیست که برنامه جدید حتماً لاگ را به journal می‌فرستد. اگر خروجی شامل عبارتی مانند
No entries است، به مراحل زمان و مقصد گزارش بروید.مرحله سوم: بازه زمانی و بوت درست را انتخاب کنید
برای مثال، اگر خطا در سی دقیقه گذشته رخ داده، نام سرویس واقعی را در فرمان زیر بگذارید:
کد / دستورsudo journalctl -u example.service --since "30 minutes ago" --no-pager
اگر بازه خیلی کوتاه باشد یا ساعت سرور با چیزی که یادداشت کرده‌اید فرق کند، پیام موردنظر خارج از جست‌وجو می‌ماند. برای دیدن ساعت و منطقه زمانی سرور می‌توانید
timedatectl را اجرا کنید. خروجی را با زمان اعلام‌شده مقایسه کنید؛ صرف تغییر ساعت بدون بررسی اثر بر سرویس‌ها راه‌حل جست‌وجوی لاگ نیست.برای مشاهده شناسه بوت‌هایی که journal در اختیار دارد، از این دستور استفاده کنید:
کد / دستورsudo journalctl --list-boots
اگر بوت قبلی در فهرست موجود است، معمولاً می‌توان گزارش سرویس همان بوت را با نمونه زیر خواند:
کد / دستورsudo journalctl -b -1 -u example.service --no-pager
-b -1 یعنی بوت قبلیِ موجود نسبت به بوت فعلی. اگر پیام نبود بوت قبلی گرفتید، ممکن است گزارش آن نگهداری نشده یا پاک شده باشد. در این حالت نوشتن دوباره همان دستور گزارش ازدست‌رفته را بازنمی‌گرداند. نسخه systemd و سیاست نگهداری سرور را در نظر بگیرید.مرحله چهارم: برنامه واقعاً لاگ را به journal می‌فرستد؟
بعضی برنامه‌ها پیام را به خروجی استاندارد فرآیند می‌نویسند و systemd آن را به journal می‌فرستد؛ بعضی دیگر فایل جداگانه، syslog، سرویس ثبت متمرکز یا مکانیزم داخلی دارند. خالی‌بودن
journalctl -u در حالت دوم لزوماً ایراد سرویس ثبت گزارش نیست.برای دیدن تعریف واحد و تنظیمات جایگزین‌شده آن اجرا کنید:
کد / دستورsystemctl cat example.service
دنبال مسیر اجرای برنامه و گزینه‌هایی مانند
StandardOutput، StandardError یا نام فضای گزارش بگردید. اگر خروجی به فایل مشخصی هدایت شده، مدیر باید مجوز و محتوای همان فایل را مطابق راهنمای برنامه بررسی کند. فایل واحد ممکن است اطلاعات داخلی داشته باشد؛ خروجی کامل آن را بدون حذف اطلاعات حساس منتشر نکنید.برای نمونه، وب‌سرور ممکن است خطاهای درخواست را در فایل گزارش جداگانه بنویسد، در حالی که journal فقط پیام شروع یا توقف سرویس را نشان می‌دهد. محل واقعی را از تنظیمات همان سایت و راهنمای نصب پیدا کنید. خطاهای داخل کانتینر را نیز با ابزار و تنظیمات ثبت گزارش همان کانتینر ببینید؛ لاگ مهمان را با لاگ میزبان یکی فرض نکنید.
مرحله پنجم: لاگ زنده را با یک اتفاق امن آزمایش کنید
اگر سرویس باید در journal پیام بدهد، مدیر می‌تواند در یک پنجره ترمینال این دستور را اجرا کند:
کد / دستورsudo journalctl -u example.service -f
-f پیام‌های جدید را دنبال می‌کند؛ برای خروج از نمایش، Ctrl+C را بزنید. در پنجره یا مرورگر دیگر، یک درخواست بی‌خطر و مجاز که طبق تنظیم برنامه باید لاگ تولید کند انجام دهید. نیازی به قطع سرویس، واردکردن رمز اشتباه مکرر یا ایجاد سفارش واقعی نیست.اگر پیام تازه ظاهر شد، ثبت فعلی کار می‌کند و مشکل ممکن است بازه زمانی، دسترسی یا نوع پیام قبلی باشد. اگر چیزی ظاهر نشد، ابتدا مطمئن شوید آن عمل واقعاً باید در همین واحد لاگ تولید کند و تنظیم سطح گزارش آن را حذف نکرده است. تنظیم خروجی سرویس یا سطح لاگ را فقط با شناخت برنامه و اثر امنیتی تغییر دهید؛ ثبت جزئیات بیش از حد ممکن است داده حساس را وارد فایل کند.
چرا لاگ بعد از ریبوت ناپدید شده است؟
journal می‌تواند فقط در حافظه موقت یا روی دیسک نگهداری شود. در حالت موقت، بخشی از گزارش‌ها پس از ریبوت باقی نمی‌ماند. رفتار پیش‌فرض به نسخه systemd و تنظیم توزیع بستگی دارد؛ نباید برای همه سرورها یک مقدار ثابت فرض کرد.
وجود پوشه
/var/log/journal، تنظیم Storage و فضای دیسک فقط بخشی از بررسی‌اند. تنظیمات ممکن است در فایل اصلی یا فایل‌های تکمیلی اعمال شده باشند. برای دیدن تنظیم موجود، مدیر می‌تواند مستندات همان نسخه و فایل‌های پیکربندی را بخواند و ابتدا از تنظیمات نسخه بردارد. اگر Storage=volatile یا Storage=none عمداً انتخاب شده، تغییر آن بدون هماهنگی می‌تواند سیاست نگهداری و حریم خصوصی سازمان را نقض کند.در یک سیستم که مدیر تأیید کرده تنظیم پیش‌فرض auto استفاده می‌شود و نگهداری دائمی لازم و مجاز است، مستندات systemd ساخت پوشه journal و اعمال مالکیت و حالت مناسب را توضیح می‌دهند:
کد / دستورsudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo journalctl --flush
این دستورها تنظیم عملیاتی سرور را تغییر می‌دهند.
mkdir پوشه را ایجاد می‌کند، systemd-tmpfiles قواعد مربوط را اعمال می‌کند و journalctl --flush در صورت فعال بودن ذخیره پایدار، داده موقت را به محل دائمی منتقل می‌کند. این روش برای هر نسخه یا پیکربندی، از جمله Storage=volatile یا فضای نام جداگانه، تضمین‌شده نیست؛ ابتدا تنظیم واقعی و راهنمای توزیع را بخوانید. پیش از اجرا از فضای دیسک، سیاست نگهداری، مجوز مدیر و محل ذخیره مطمئن شوید.بعد از تغییر، یک پیام آزمایشی مجاز تولید کنید، آن را در journal ببینید و در زمان نگهداری برنامه‌ریزی‌شده پس از ریبوت با
--list-boots و -b -1 بررسی کنید آیا پیام بوت قبلی مانده است. لاگ‌هایی که پیش از فعال‌شدن نگهداری دائم از بین رفته‌اند با این کار بازنمی‌گردند. برای محدودکردن رشد لاگ، سیاست حجم و زمان نگهداری را طبق مستندات همان سرور تنظیم کنید؛ کل پوشه لاگ را برای آزادکردن فضا بی‌برنامه حذف نکنید.اگر هنوز چیزی دیده نمی‌شود
نام دقیق واحد، زمان آزمایش، نتیجه دستور وضعیت، دسترسی حساب و مقصد گزارش را در یک فهرست جمع کنید. اگر برنامه برای رویداد موردنظر اصلاً لاگ تولید نمی‌کند، باید سطح و مقصد ثبت گزارش آن را طبق مستندات خودش تنظیم کرد. اگر سرویس ثبت گزارش خطا دارد یا دیسک فقط‌خواندنی است، ابتدا همان خطای مشخص را بررسی کنید.
بعد از اصلاح، یک رویداد بی‌خطر را تکرار و مطمئن شوید پیام درست در محل مورد انتظار و با سطح دسترسی مناسب دیده می‌شود. برای بررسی منابع و امکانات مدیریتی، صفحه سرور مجازی ایران نت‌آرام را ببینید؛ لاگ‌نویسی برنامه و سیاست نگهداری سرور همچنان باید درست تنظیم شوند.
منابع فنی
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام