بیشتر مزایای systemd آنهایی هستند که با فرآیند و ثبت تاریخچه سیستم مرتبط می‌شوند. امّا هنگامی که از ابزارهای دیگر استفاده می‌کنیم، تاریخچه‌ها معمولاً در کل سیستم پخش شده و توسط ابزارهای و فرآیندهای مختلف مدیریت می شوند. در نتیجه، تفسیر و بررسی آنها در اپلیکیشن‌های چندگانه دشوار می‌شود. system برای حل این شکل، یک راه‌حل ارائه داده و آن یک مرکز مدیریت برای ثبت تاریخچه تمام فرآیندهای هسته و عملکرد کاربران است. سیستمی که تمام این تاریخچه‌ها را جمعآوری و مدیریت می‌کند با نام journal شناخته می‌شود و بکارگیری آن از طریق ابزار journald است. journald تمام پیام‌های تولید شده توسط هسته، initrd، سرویس‌ها و … را مدیریت می‌کند. در این آموزش به نحوه استفاده از ابزار journalctl خواهیم پرداخت؛ ابزاری که می‌توند برای دسترسی و دست‌کاری داده‌ها درون journal مورد استفاده قرار گیرد.
ایده کلی
یکی از اهداف اصلی systemd journal، مرکزیت مدیریت ثبت تاریخچه‌ها فارغ از منبع آنها بوده است. از آنجایی که بیشتر پردازش بوت و مدیریت سرویس به عهده فرآیند systemd است، بسیار منطقی است که در نحوه جمعآوری و دسترسی به آنها یک استاندارد تعریف شود. ابزار journal داده‌ها را از تمام منابع در دسترس جمعآوری کرده و آنها را به یک فرمت باینری که می‌تواند به سهولت در آن تغییرات انجام داد، ذخیره می‌کند.
این موضوع، مزایای بسیاری در اختیار ما قرار می‌دهد. وقتی تنها یک ابزار بتواند با تمام داده‌ها سر و کار داشته باشد، مدیران سیستم می‌توانند به نسبت نیازشان، نمایشی پویا از تاریخچه عملکرد سیستم داشته باشند. این کار می‌تواند به سادگی بازدید از داده‌های بوت مربوط به سه دوره بوت قبل و یا ترکیب ورودی‌های دو سرویس مرتبط با یکدیگر باشد.
همچنین ذخیره داده‌های تاریخچه در یک فرمت باینری به این معناست که داده‌ها می‌تواند به شکل دلخواه و بر حسب نیاز در لحظه نمایش داده شوند. به عنوان نمونه، برای مدیریت تاریخچه عملکرد روزانه احتمالاً نیاز به مشاهده تاریخچه در فرمت استاندارد syslog باشد. امّا اگر بخواهید اختلالات سرویس را به صورت نمودار در آینده رسم کنید، می‌توانید از هر کدام از ورودی‌ها به صورت یک آبجکت JSON خروجی بگیرید. به دلیل اینکه داده به صورت متن plain text در دیسک ذخیره شده، برای تبدیل آنها به آن فرمت‌های مختلف نیاز به هیچ‌گونه اقدام اضافه‌ای نیست.
systemd journal می‌تواند یا با ابزار کنونی syslog استفاده شود و یا اینکه جایگزین کاربری syslog گردد. این موضوع، به نیازهای شما ارتباط پیدا می‌کند. با اینکه systemd journal می‌تواند اکثر نیازهای مدیر سیستم در ثبت تاریخچه را رفع کند، امّا در عین حال، می‌تواند به عنوان یک مکمّل در کنار ساز و کارهای کنونی ثبت تاریخچه عملکرد سیستم نیز مورد استفاده قرار گیرد. به عنوان مثال، درنظر بگیرید که یک سرور مرکزی syslog برای استخراج داده از سرورهای چندگانه داشته باشید. در همین حال، تمایل به جمعآوری تاریخچه‌ها از سرویس‌های مختلف در یک سیستم جداگانه با systemd journal داشته باشید. شما می‌توانید هر دوی اینها را با ترکیب تکنولوژی‌ها در اختیار داشته باشید.
تنظیم زمان سیستم
یکی از مزایای استفاده از journal باینری برای ثبت تاریخچه، قابلیت نمایش تاریخچه در UTC یا ساعت محلی است. systemd به صورت پیش‌فرض، نتایج را در ساعت محلی سیستم نمایش می‌دهد.
به همین دلیل است که قبل از شروع به کار با journal، ابتدا مطمئن می‌شویم که منطقه زمانی به‌درستی تنظیم شده است. بسته system معمولاً با ابزاری به نام timedatectl همراه است که می‌تواند به ما در این رابطه کمک کند.
ابتدا ببینیم که کدام مناطق زمانی در گزینه list-timezones در دسترس هستند.
timedatectl list-timezones
در نتیجه، لیست مناطق زمانی در دسترس برای سیستم شما نمایش داده می‌شوند. پس از پیدا کردن منطقه زمانی مناسب برای سرور، می‌توانید با گزینه set-timezone آن را تنظیم کنید.
sudo timedatectl set-timezone zone
برای اطمینان از صحیح‌بودن زمان سیستم، فرمان timedatectl را به تنهایی استفاده می‌کنیم. یا اینکه می‌توانیم گزینه status را به کار ببریم. خروجی هر دوی اینها یکسان خواهد بود.
timedatectl status
خروجی
Local time: Fri 2021-07-09 14:44:30 EDT Universal time: Fri 2021-07-09 18:44:30 UTC RTC time: Fri 2021-07-09 18:44:31 Time zone: America/New_York (EDT, -0400) System clock synchronized: yes NTP service: active RTC in local TZ: no
اولین خط می‌بایست زمان درست را برای شما نشان دهد.
نمایش گزارش پایه Basic Log
برای دیدن تاریخچه‌هایی که ابزار journald جمعآوری کرده، از فرمان journalctl استفاده می‌کنیم.
در صورتی که این ابزار به‌تنهایی استفاده شود، هر کدام از ورودی‌های journal در سیستم درون یک صفحه برایتان نمایش داده می‌شوند. قدیمی‌ترین ورودی‌ها در بالا قرار خواهند داشت.
journalctl
نمونه خروجی
-- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. -- Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49. Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49. Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd). Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_en Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules. Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules. Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/ Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 8 users, 102 roles, 4976 types, 294 bools, 1 sens, Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 83 classes, 104131 rules . . .
احتمالاً صفحات زیادی پیش روی شما قرار می‌گیرند که می‌توانید آنها را مرور کنید. در صورتی که مدتی است از systemd استفاده می‌کنید، این صفحات ممکن است شامل صدها و هزاران خط باشند. این موضوع بیانگر سطح میزان داده‌ای است که از طریق پایگاه داده journal در اختیار قرار می‌گیرد.
این فرمت برای آنهایی که عادت به استفاده از ثبت تاریخچه استاندارد syslog دارند، آشنا خواهد بود. با این وجود، این کار باعث جمعآوری داده‌ها از منابع بیشتری در مقایسه با ابزارهای سنتی syslog می‌شود؛ از جمله پردازش بوت، هسته، initrd و خطاهای استاندارد اپلیکیشن. همه اینها در journal در دسترس قرار می‌گیرند.
مشاهده می‌کنید که تمام بازه‌های زمانی نمایش داده‌شده به ساعت محلی هستند. این موضوع برای تمام هر تاریخچه‌ای که زمان محلی را به‌درستی برای آن تنظیم کرده‌ایم، صادق خواهد بود. تمام تاریخچه‌ها با استفاده از این اطلاعات جدید نشان داده می‌شوند.
در صورتی که بخواهید بازه‌های زمانی را در قالب UTC نمایش دهید، می‌توانید از گزینه –utc استفاده نمایید.
journalctl --utc
فیلترینگ Journal بر اساس زمان
دسترسی به حجم گسترده‌ای از داده‌های جمع‌آوری‌شده واقعاً مفید است. امّا این حجم بزرگ از اطلاعات می‌تواند در پردازش‌ها و جستجوهای دستی مشکل‌ساز باشد. به همین دلیل، یکی از مهم‌ترین ویژگی‌های ابزار journalctl، گزینه‌های فیلترینگ موجود در آن است.
نمایش تاریخچه عملکرد بعد از آخرین شروع به کار سیستم
یکی از پایه‌ای ترین آیتم‌ها در این رابطه که ممکن است روزانه از آن استفاده کنید، گزینه -b است. این گزینه باعث نمایش تمام ورودی‌های جمع‌آوری‌شده journal از زمان آخرین بوت (راه‌اندازی سیستم) خواهد شد.
journalctl -b
این به شما در تشخیص و مدیریت اطلاعات مرتبط با محیط کنونی کمک خواهد کرد.
در صورتی که از این ویژگی استفاده نمی‌کنیدو بیشتر از یک روز از بوت‌ها را نمایش می‌دهید، مشاهده می‌کنید که ابزار journalctl یک خط مشابه زیر در زمان خاموش‌شدن سیستم اضافه می‌کند.
. . . -- Reboot -- . . .
این خط می‌تواند برای جداسازی منطقی اطلاعات بین دوره‌های راه‌اندازی سیستم به کمک شما بیاید.
راه‌اندازی‌های سیستم در گذشته
در حالی که معمولاً اطلاعات از زمان راه‌اندازی کنونی سیستم، مورد نیاز هستند، امّا گاهی اوقات بوت‌های گذشته نیز مدّنظر قرار می‌گیرند. journal می‌تواند اطلاعات تعداد زیادی از بوت‌ها را در خود نگه دارد. بنابراین ابزار journalctl می‌تواند به راحتی این اطلاعات را به نمایش بگذارد.
در برخی توزیع‌ها و نسخه‌ها امکان ذخیره اطلاعات بوت قبلی به صورت پیش‌فرض وجود دارد. برای فعالسازی قابلیت حفظ اطلاعات بوت سیستم، می‌توانید با تایپ فرمان زیر، یک دایرکتوری برای ذخیره‌سازی journal ایجاد کنید.
sudo mkdir -p /var/log/journal
یا اینکه می‌توانید فایل تنظیمات journal را به صورت زیر ویرایش نمایید.
sudo nano /etc/systemd/journald.conf
در بخش [Journal]، مقدار گزینه Storage= را به “persistent” تغییر دهید. این کار باعث فعالسازی ثبت تاریخچه به صورت همیشگی می‌شود.
. . . [Journal] Storage=persistent
زمانی که ذخیره بوت‌های قبلی در سرور شما فعال باشد، ابزار journalctl برخی فرمان‌ها را برای کمک به کار با بوت‌ها در اختیارتان قرار می‌دهد. برای مشاهده بوت‌های مشخص و در دسترس برای journal از گزینه –list-boots همراه با journalctl استفاده کنید.
journalctl --list-boots
خروجی
-2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC -1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC 0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC
در نتیجه، برای هر بوت یک خط نمایش داده می‌شود. اولین ستون، عبارتی است که می‌تواند برای ارجاع‌دهی ساده بوت با journalctl مورد استفاده قرار گیرد. در صورتی که بخواهید یک مرجع دقیق ارائه بدهید، شناسه بوت در ستون دوم را به کار ببرید. همچنین بازه زمانی برای هر دوره راه‌اندازی سیستم در ستون آخر در دسترس قرار می‌گیرد.
برای نمایش اطلاعات مرتبط با این بوت‌ها می‌توانید از ستون اول یا دوم استفاده کنید. به عنوان مثال، اگر بخواهید journal مربوط به بوت قبلی را ببینید، نسبت -1 همراه با گزینه -b را به کار ببرید.
journalctl -b -1
همچنین می‌توانید با استفاده از شناسه بوت، داده‌های مربوط به یک بوت را فراخوانی کنید.
journalctl -b caf0524a1d394ce0bdbcff75b94444fe
بازه‌های زمانی
امکان مشاهده گزارش عملکرد سیستم مطابق با دوره‌های راه‌اندازی سیستم بسیار مفید است. امّا گاهی ممکن است نیاز به مشاهده تاریخچه در بازه‌هایی داشته باشید که ارتباطی با زمان‌های راه‌اندازی سیستم ندارند. این موضوع، به‌ویژه در مورد سرورهایی که مدت‌زمان بسیار زیادی از شروع به کار آنها می‌گذرد، صدق می‌کند.
برای این منظور می‌توانید محدودیت‌های زمانی دلخواه با استفاده از گزینه‌های –since و –until ایجاد کنید. در نتیجه، زمان ورودی‌ها با توجه به این گزینه‌ها تنظیم خواهد شد. مقادیر زمانی می‌توانند فرمت‌های مختلفی داشته باشند. برای وارد کردن مقادیر زمانی مشخص، می‌توانید از فرمت زیر استفاده کنید.
YYYY-MM-DD HH:MM:SS
به عنوان مثال، با تایپ فرمان زیر، تمام ورودی‌ها را از ساعت 5:15 بعدازظهر روز ۱۰ ژانویه ۲۰۱۵ مشاهده کنیم.
journalctl --since "2015-01-10 17:15:00"
در صورتی که هر کدام از اجزای فرمان بالا وارد نشوند، از برخی مقادیر پیش‌فرض استفاده خواهد شد. به عنوان نمونه، اگر از وارد کردن مقدار روز صرف‌نظر شود، تاریخ روز کنونی درنظر گرفته می‌شود. ساعت پیش‌فرض نیز در صورت وارد نکردن ساعت دقیق برابر نیمه‌شب “00:00:00” است. فیلد مربوط به ثانیه نیز می‌تواند به صورت پیش فرض صفر استفاده شود.
journalctl --since "2015-01-10" --until "2015-01-11 03:00"
journal همچنین قادر به تشخیص بخی مقادیر نسبی و مخفف‌هاست. از جمله اینکه می‌توانید از کلماتی مانند “yesterday”، “today”، “tomorrow” یا “now” استفاده کنید. همچنین می‌توانید از زمان‌های نسبی با اضافه‌کردن علامت‌های “-” یا “+” و یک عدد مشخص، و یا کلمه‌ای مانند “ago” در ساختار یک عبارت استفاده کنید.
برای دریافت اطلاعات روز قبل می‌توانید فرمان زیر را تایپ نمایید.
journalctl --since yesterday
در صورتی که گزارش‌هایی مبنی بر اختلال سرویس بعد از ساعت ۹ صبح تا یک ساعت قبل دریافت کرده‌اید، می‌توانید از فرمان زیر کمک بگیرید.
journalctl --since 09:00 --until "1 hour ago"
همان‌طور که مشاهده می‌کنید، امکان تعریف بازه‌های زمانی مشاهده ورودی‌ها به شکلی انعطاف‌پذیر برای شما وجود دارد.
فیلترینگ بر اساس پیغام‌های خاص
آنچه که در بالا مرور کردیم، شامل راه‌هایی برای فیلتر کردن داده‌های journal با استفاده از محدودیت‌های زمانی بود. در این بخش به نحوه فیلتر کردن بر اساس سرویس‌ها یا موارد خاص دیگر می‌پردازیم. systemd journal روش‌های متنوعی در این رابطه درنظر گرفته است.
بر اساس واحد
شاید یکی از مفیدترین راه‌های فیلترینگ، جداسازی بر اساس واحد موردنظر شماست. برای این منظور می‌توانیم از گزینه -u استفاده کنیم.
به عنوان مثال، برای مشاهده تمام تاریخچه‌های مرتبط با واحد Nginx سیستم، می‌توانیم فرمان زیر را تایپ کنیم.
journalctl -u nginx.service
البته معمولاً گزارش عملکرد در بین دو مقطع زمانی خاص مدّنظر قرار می‌گیرد. برای نمونه، به منظور مشاهد نحوه عملکرد سرویس در روز جاری، فرمان زیر را تایپ کنید.
journalctl -u nginx.service --since today
این سطح از دقت در خروجی‌‌ها می‌تواند در هنگام بهره‌گیری از ثبت رکوردهای ترکیبی واحدهای مختلف فواید بسیاری داشته باشد. مثلاً اگر فرآیند Nginx به یک واحد PHP-FPM برای پردازش محتوای دینامیک مرتبط باشد، می‌توان ورودی‌های هر دو را با ترتیب زمانی در اختیار داشت.
journalctl -u nginx.service -u php-fpm.service --since today
این کار موجب سهولت در تشخیص تعاملات برنامه‌های مختلف و عیب‌یابی سیستم‌ها می‌شود.
بر اساس فرآیند، کاربر یا گروه
برخی از سرویس‌ها به منظور انجام کار، از فرآیندهای زیرمجموع مختلفی بهره می‌گیرند. در صورتی که از شناسه دقیق این فرآیند استفاده کنید، می‌توانید تاریخچه کلی مرتبط با آن را مشاهده نمایید.
برای این منظور، می‌توانید با استفاده از فیلد _PID فیلترگذاری را انجام دهید. به عنوان نمونه، اگر شناسه یا PID موردنظر ما برابر 8088 باشد، می‌توانیم فرمان زیر را تایپ کنیم.
journalctl _PID=8088
همچنین گاهی ممکن است نمایش تاریخچه عملکرد یک کاربر یا گروه خاص مدّنظر باشد. چنین کاری می‌توانید با استفاده از فیلترهای _UID یا _GID انجام شود. مثلاً اگر وب‌سرور شما تحت کاربری www-data در حال اجرا باشد، می‌توانید شناسه کاربر را به روش زیر پیدا کنید.
id -u www-data
خروجی
33
سپس از این شناسه برای فیلتر کردن نتایج journal استفاده می‌شود.
journalctl _UID=33 --since today
systemd journal دارای فیلدهای زیادی است که می‌توانند برای فیلترینگ استفاده شوند. برخی از آنها از فرآیندهای ثبت‌شده استفاده می‌کنند و برخی دیگر نیز توسط journald از منابع مختلف سیستم جمعآوری می‌شوند. علامت (_) در ابتدای _PID نشان می‌دهد که این فیلد از نوع دوم است. journal به صورت خودکار، برای فرآیندهای سیستم شناسه تعریف و ثبت می‌کند تا بتواند بعداً از آنها برای فیلترینگ استفاده کند. با تایپ فرمان زیر می‌توانید اطلاعات کاملی در مورد تمام فیلدهای در دسترس journal دریافت کنید.
man systemd.journal-fields
در مورد برخی از این فیلدها در ادامه این مطلب صحبت خواهیم کرد. امّا در اینجا، به سراغ یکی دیگر از گزینه‌های مفید در رابطه با فیلترینگ می‌رویم. گزینه -F می‌تواند برای نمایش تمام مقادیر در دسترس برای یک فیلد خاص journal مورد استفاده قرار گیرد.
به عنوان مثال، برای مشاهده اینکه کدام شناسه گروه در systemd journal دارای ورودی است، داریم:
journalctl -F _GID
خروجی
32 99 102 133 81 84 100 0 124 87
در نتیجه، تمام مقادیری که journal برای فیلد شناسه گروه ذخیره کرده، نمایش داده می‌شوند. چنین چیزی می‌تواند در ساختن فیلترها به شما کمک کند.
بر اساس موقعیت
امکان فیلترینگ بر اساس یک مسیر یا موقعیت نیز وجود دارد.
اگر مسیر به یک فایل اجرایی ختم شود، ابزار journalctl تمام ورودی‌های مرتبط با این فایل اجرایی را نمایش خواهد داد. مثلاً اگر تمام ورودی‌های مرتبط با فایل اجرایی bash مدّنظر باشد، می‌توانید فرمان زیر را تایپ کنید.
journalctl /usr/bin/bash
معمولاً اگر یک واحد در دسترس فایل اجرایی باشد، متد به کار رفته صریح‌تر است و اطلاعات بهتری در اختیار قرار می‌دهد. امّا گاهی اوقات نیز چنین امکانی وجود نخواهد داشت.
نمایش پیغام‌های هسته
پیغام‌های هسته که معمولاً در خروجی dmesg مشاهده می‌شوند، می‌توانند از طریق journal نیز استخراج گردند.
برای اینکه صرفاً این پیغام ها را نمایش دهیم، می‌توانیم از گزینه‌های -k یا –dmesg در فرمان استفاده کنیم.
journalctl -k
این فرمان به صورت پیش‌فرض، پیغام‌های هسته را از زمان بوت کنونی نشان خواهد داد. با استفاده از گزینه‌های انتخاب بوت که در قبل گفته شد، می‌توانیم یک دوره راه‌اندازی دیگر از سیستم را انتخاب کنیم. به عنوان نمونه، برای دریافت پیغام‌های مربوط به پنج بوت قبل، داریم:
journalctl -k -b -5
بر اساس اولویت
یکی از فیلترهایی که مدیران سیستم معمولاً به آن علاقه‌مند هستند، اولویت پیغام‌هاست. اگرچه ثبت اطلاعات به صورت جزئی و طولانی بسیار مفید است، امّا در هنگام جستجوی انبوهی از اطلاعات، تاریخچه‌های با اولویت پایین‌تر می‌توانند بسیار گمراه‌کننده نیز باشند.
می‌توانید از ابزار journalctl برای نمایش پیغام‌هایی استفاده کنید که یک اولویت خاص یا بالاتر دارند. برای این منظور، از گزینه -p استفاده می‌شود. در نتیجه، پیغام‌های با اولویت‌های پایین‌تر از خروجی حذف می‌شوند.
به عنوان مثال، برای نشان‌دادن ورودی‌های ثبت‌شده در سطح «خطا» یا بالاتر، می‌توانید فرمان زیر را تایپ کنید.
journalctl -p err -b
در نتیجه، تمام پیغام‌هایی که دارای برچسب خطا، بحرانی، هشداردهنده یا اضطراری هستند، نمایش داده می‌شوند. journal برای این منظور سطوح استاندارد پیغام syslog را به کار می‌گیرد. امکان استفاده از عنوان اولویت یا مقدار عددی متناظر با آن وجود دارد. این اعداد به ترتیب بالاترین تا پایین‌ترین اولویت عبارتند از:
0: emerg 1: alert 2: crit 3: err 4: warning 5: notice 6: info 7: debug
اعداد یا عنوان‌های بالا را می‌توان به جای گزینه -p به کار برد. انتخاب یک اولویت باعث می‌شود که پیغام‌های سطح مربوطه و بالاتر نمایش داده شوند.
اصلاح نحوه نمایش Journal
تا به اینجا، نحوه انتخاب ورودی را از طریق فیلترینگ بررسی کردیم. امّا راه‌هایی برای اصلاح خروجی نیز وجود دارد. می‌توانیم خروجی ابزار journalctl بر حسب نیازهایمان تنظیم کنیم.
خلاصه‌کردن یا گسترش نتیجه خروجی
این امکان وجود دارد که با برخی گزینه‌ها، نمایش خروجی ابزار journalctl را به گونه‌ای مختصر یا طولانی تنظیم کنیم.
ابزار journalctl به صورت پیش‌فرض، تمام ورودی را در pager نمایش می‌دهد و خطوط تا سمت راست صفحه امتداد می‌یابند. این اطلاعات با فشردن کلید جهتی راست صفحه‌کلید، قابل دسترسی هستند.
امّا اگر بخواهید برخی موارد را از اطلاعات ورودی حذف کنید، می‌توانید گزینه –no-full را به کار ببرید.
journalctl --no-full
نمونه خروجی
. . . Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2 Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth] Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot
در همین حال، می‌توانید خلاف این موضوع عمل کنید و از ابزار journalctl بخواهید که تمام اطلاعات را فارغ از قابل چاب‌بودن یا نبودن کاراکترهای آنها، برایتان نمایش دهد. چنین کاری را می‌توان با گزینه -a انجام داد.
journalctl -a
خروجی استاندارد
ابزار journalctl به صورت پیش‌فرض خروجی را در یک pager نمایش می‌دهد تا تفسیر آن راحت‌تر انجام شود. در صورتی که قصد دارید پردازش داده‌ها را با ابزارهای ویرایش متن انجام دهید، احتمالاً به یک خروجی استاندارد احتیاج خواهید داشت.
چنین کاری را می‌توانید با استفاده از گزینه –no-pager انجام دهید.
journalctl --no-pager
این خروجی می‌تواند بلافاصله در یک ابزار پردازش یا یک فایل در دیسک انتقال یابد.
فرمت‌های خروجی
همراه با پردازش ورودی‌های journal به صورت بالا، نیاز به داشتن یک فرمت مناسب‌تر و «مصرفی‌تر» نیز وجود خواهد داشت. خوشبختانه در journal می‌توان خروجی را در فرمت‌های مختلف نمایش داد. این کار از طریق اضافه‌کردن گزینه -o همراه با مشخصه فرمت امکان‌پذیر خواهد بود.
به عنوان نمونه، برای داشتن خروجی به فرمت JSON داریم:
journalctl -b -u nginx -o json
خروجی
{ "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }
. . .
در نتیجه، پردازش با ابزارهای مختلف به سهولت انجام خواهد گرفت. می‌توانید با استفاده از فرمت json-pretty ، مدیریت بهتری بر روی ساختار داده داشته باشید.
journalctl -b -u nginx -o json-pretty
خروجی
{
"__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
"__REALTIME_TIMESTAMP" : "1422990364739502",
"__MONOTONIC_TIMESTAMP" : "27200938",
"_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
"PRIORITY" : "6",
"_UID" : "0",
"_GID" : "0",
"_CAP_EFFECTIVE" : "3fffffffff",
"_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
"_HOSTNAME" : "desktop",
"SYSLOG_FACILITY" : "3",
"CODE_FILE" : "src/core/unit.c",
"CODE_LINE" : "1402",
"CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
"SYSLOG_IDENTIFIER" : "systemd",
"MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
"_TRANSPORT" : "journal",
"_PID" : "1",
"_COMM" : "systemd",
"_EXE" : "/usr/lib/systemd/systemd",
"_CMDLINE" : "/usr/lib/systemd/systemd",
"_SYSTEMD_CGROUP" : "/",
"UNIT" : "nginx.service",
"MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
"_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
}
. . .
فرمت‌های زیر می‌توانند برای نمایش مورد استفاده قرار گیرند.
- cat: صرفاً نمایش فیلد پیغام
- export: یک فرمت باینری مناسب برای انتقال یا پشتیبان‌گیری
- json: فرمت استاندارد JSON به صورت یک ورودی در هر خط
- json-pretty: فرمت خواناتر JSON
- json-sse: فرمت بسته‌ای JSON برای انتقال بهتر در سرور
- short: طرح پیش‌فرض خروجی syslog
- short-iso: فرمت پیش‌فرض مطابق با بازه‌های زمانی ISO 8601 wallclock
- short-monotonic: فرمت پیش‌فرض با بازه‌های زمانی یکنواخت
- short-precise: فرمت پیش‌فرض با دقت میکروثانیه
- verbose: نمایش هر گونه اطلاعاتی که در مورد ورودی ثبت شده باشد، از جمله آنهایی به صورت داخلی و پنهان هستند.
این گزینه به شما امکان می‌دهند که نمایش خروجی journal را در هر فرمت دلخواه داشته باشید.
پایش هوشمند فرآیندها
فرمان journalctl موجب تداعی استفاده از tail برای پایش فعالیت‌های سیستم توسط مدیران سیستم می‌شود. این عملکرد در ابزار journalctl به شما اجازه می‌دهد که بدون رفتن به سراغ ابزاری دیگر، به این ویژگی‌ها دسترسی داشته باشید.
نمایش ثبت تاریخچه‌های اخیر
برای نمایش مجموعه‌ای از رکوردها می‌توانید از گزینه -n استفاده کنید که دقیقاً عملکردی مشابه tail -n خواهد داشت.
پیش‌فرض این گزینه، نمایش ۱۰ ورودی اخیر خواهد بود.
journalctl -n
در همین حال، می‌توانید تعداد ورودی‌ها را با افزودن یک عدد بعد از -n مشخص کنید.
journalctl -n 20
پیگیری تاریخچه‌ها
برای پیگیری هوشمند گزارش‌های عملکرد سیستم که در حال نوشته‌شدن هستند، می‌توانید از گزینه -f استفاده کنید. در اینجا نیز باید گفت که نتیجه‌ای مشابه tail -f در انتظار شما خواهد بود.
journalctl -f
برای خروجی از این فرمان، کلیدهای CTRL+C را بزنید.
نگهداری Journal
شاید با خود فکر می‌کنید که هزینه نگهداری و ذخیره این همه داده‌ای که تاکنون مشاهده کردیم، چقدر خواهد بود. به علاوه، شاید بخواهید تاریخچه‌های قدیمی‌تر را پاک کنید و فضای دیسک بیشتری در اختیار داشته باشید.
مشاهده میزان استفاده از فضای دیسک
با استفاده از گزینه –disk-usage می‌توانید به میزان فضای اشغال‌شده توسط journal دست پیدا کنید.
journalctl --disk-usage
خروجی
Archived and active journals take up 8.0M in the file system.
حذف تاریخچه‌های قدیمی
اگر بخواهیم از حجم journal کم کنیم، دو روش مختلف برای این منظور وجود دارد (در نسخه 218 و بالاتر systemd).
اگر از گزینه –vacuum-size استفاده کنید، می‌توانید با وارد کردن یک اندازه، حجم journal را کم کنید. در نتیجه، تمام تاریخچه‌های قدیمی حذف می‌شوند تا حجم کلی موردنظر به‌دست آید.
sudo journalctl --vacuum-size=1G
روش دیگری که می‌توانید برای کم کردن حجم journal استفاده کنید، گزینه –vacuum-time است. در این حالت، هر ورودی خارج از زمان تعریف‌شده، حذف خواهد شد و ورودی‌های بعد از این زمان، حفظ می‌شوند.
به عنوان مثال، برای حفظ ورودی‌ها از یک سال قبل، فرمان زیر را تایپ کنید.
sudo journalctl --vacuum-time=1years
محدود کردن حجم Journal
می‌توانید سرور را به گونه‌ای تنظیم کنید که فضای محدودی به journal اختصاص دهد. چنین کاری را می‌توان با ویرایش فایل /etc/systemd/journald.conf انجام داد.
آیتم‌های زیر می‌توانند باری محدود کردن حجم journal مورد استفاده قرار گیرند.
- SystemMaxUse=: حداکثر فضای دیسکی که می‌تواند توسط journal برای ذخیره‌سازی مورد استفاده قرار گیرد.
- SystemKeepFree=: میزان فضای دیسکی که journal می‌بایست در هنگام اضافه‌کردن ورودی‌ها به محل ذخیره، به صورت آ‌زاد نگه دارد.
- SystemMaxFileSize=: کنترل حداکثر حجم فایل‌های journal در زمان ذخیره‌سازی
- RuntimeMaxUse=: حداکثر فضای دیسکی که می‌تواند در هنگام ذخیره‌سازی‌های موقتی (درون /run filesystem) مورد استفاده قرار گیرد.
- RuntimeKeepFree=: حداکثر فضای دیسکی که در هنگام نوشتن داده‌های موقتی، کنار گذاشته می‌شود.
- RuntimeMaxFileSize=: مقدار فضایی که یک فایل مجزای journal می‌تواند در فضای ذخیره موقتی داشته باشد.
با مشخص کردن این مقادیر، می‌توانید نحوه مصرف و نگهداری داده‌ها در سرور تسوط journald را مدیریت کنید. به خاطر داشته باشید که SystemMaxFileSize و RuntimeMaxFileSize فایل‌های آرشیو شده را برای رسیدن به محدودیت‌ها، مورد توجه قرار می‌دهند. این موضوع در هنگام تفسیر تعداد فایل‌ها پس از عملیات پاکسازی اهمیت خواهد داشت.
جمع‌بندی
همان‌طور که مشاهده کردید، systemd journal واقعاً برای جمعآوری داده‌های سیستم و اپلیکیشن‌ها مفید خواهد بود. بیشتر این انعطاف‌پذیری از فراداده‌های گسترده‌ای ناشی می‌شود که به صورت اتوماتیک ثبت و در یک مرکز محوری جمعآوری می‌گردند. ابزار journalctl موجب سهولت در بهره‌گیری از مزایای journal به منظور آنالیزهای گسترده و عیب‌یابی منطقی قسمت‌های مختلف یک اپلیکیشن می‌شود.