نحوه استفاده از journalctl برای مشاهده و مدیریت لاگ‌های systemd در لینوکس

مقدمه‌ای بر ژورنال systemd و لاگینگ journalctl

بعضی از جذاب‌ترین مزایای systemd، موارد مرتبط با لاگینگ پروسه و سیستم هستند. هنگام استفاده از ابزارهای دیگر، لاگ‌ها معمولاً در سراسر سیستم پراکنده‌اند، توسط دیمن‌ها و پروسه‌های مختلف مدیریت می‌شوند و وقتی چند اپلیکیشن را در بر می‌گیرند، تفسیرشان می‌تواند نسبتاً دشوار باشد. systemd با ارائه راهکار مدیریت متمرکز برای لاگ کردن همه پروسه‌های کرنل و Userland تلاش می‌کند این مشکلات را حل کند. سیستمی که این لاگ‌ها را جمع‌آوری و مدیریت می‌کند، ژورنال (Journal) نام دارد.

ژورنال با دیمن journald پیاده‌سازی شده؛ که همه پیام‌های تولیدشده توسط کرنل، initrd، سرویس‌ها و غیره را مدیریت می‌کند. در این راهنما، نحوه استفاده از ابزار journalctl را بحث می‌کنیم؛ که می‌تواند برای دسترسی و دستکاری داده‌های موجود در ژورنال استفاده شود.

در این مقاله یاد می‌گیرید چطور از ابزار خط فرمان journalctl برای دسترسی و فیلتر داده‌های لاگ از ژورنال systemd استفاده کنید. پوشش می‌دهیم چطور لاگ‌های بوت‌های خاص یا بازه‌های زمانی را ببینید، بر اساس یونیت‌های سیستم، کاربران یا سطوح اولویت فیلتر کنید و لاگ‌ها را در قالب‌هایی مثل JSON برای یکپارچه‌سازی با ابزارهای دیگر خروجی بگیرید. همچنین یاد می‌گیرید چطور رویدادهای بلادرنگ را مانیتور، مصرف دیسک را مدیریت، لاگینگ ماندگار را پیکربندی و مسائل رایجی مثل لاگ‌های مفقود یا خطاهای مجوز را رفع کنید. چه در حال دیباگ سرویسِ خرابی باشید چه راه‌اندازی جمع‌آوری متمرکز لاگ، journalctl انعطاف و دقت لازم برای ساده‌سازی روند کاری‌تان را فراهم می‌کند.

نکات کلیدی

• ژورنال systemd یک سیستم لاگینگ یکپارچه فراهم می‌کند که پیام‌های کرنل، سرویس‌ها و اپلیکیشن‌های کاربر را در یک لاگ متمرکز و ایندکس‌شده ثبت می‌کند.
• دستور journalctl به شما اجازه می‌دهد لاگ‌ها را بر اساس نشست‌های بوت، بازه‌های زمانی، یونیت‌های systemd، شناسه‌های پروسه، شناسه‌های کاربر، شناسه‌های گروه و موارد دیگر فیلتر کنید؛ که پیدا کردن رویدادهای مرتبط را ساده می‌کند.
• می‌توانید لاگ‌های پنجره‌های زمانی خاص را با گزینه‌هایی مثل --since، --until یا عبارات نسبی مثل «1 hour ago» یا «yesterday» بازیابی کنید.
• لاگ‌ها را می‌توان در قالب‌های مختلفی نمایش داد؛ مانند متن ساده، JSON و حالت تفصیلی؛ که یکپارچه‌سازی با ابزارهای خارجی یا پارس برای تحلیل را ساده‌تر می‌کند.
• با journalctl -f می‌توانید پیام‌های لاگ را هم‌زمان با نوشته شدن زنده دنبال کنید؛ شبیه tail -f؛ که برای مانیتورینگ فعالیت سیستم یا رفتار سرویس در زمان واقعی مفید است.
• به‌طور پیش‌فرض، لاگ‌ها ممکن است در حافظه ذخیره و با ریبوت از بین بروند. می‌توانید با ساخت /var/log/journal و پیکربندی متناسب journald.conf، لاگینگ ماندگار را فعال کنید.
• ردپای ذخیره‌سازی ژورنال را می‌توان با دستوراتی مثل --disk-usage، --vacuum-size و --vacuum-time و گزینه‌های پیکربندی برای کنترل حداکثر اندازه و نگهداری مدیریت کرد.
• journalctl دیباگ سرویس را با تجمیع لاگ‌ها بین بوت‌ها و یونیت‌ها ساده می‌کند؛ که شناسایی خرابی‌ها، ردیابی دسترسی SSH و بررسی مسائل با زمینه تفصیلی را آسان‌تر می‌کند.

ژورنال systemd چگونه کار می‌کند و چرا مهم است

یکی از انگیزه‌های پشت ژورنال systemd، متمرکز کردن مدیریت لاگ‌ها فارغ از اینکه پیام‌ها از کجا می‌آیند است. چون بیشتر فرایند بوت و مدیریت سرویس توسط پروسه systemd انجام می‌شود، منطقی است که نحوه جمع‌آوری و دسترسی به لاگ‌ها استاندارد شود. دیمن journald داده‌ها را از همه منابع موجود جمع‌آوری و برای دستکاری آسان و داینامیک، در قالب باینری ذخیره می‌کند.

این به ما مزایای قابل توجهی می‌دهد. با تعامل با داده‌ها از طریق یک ابزار واحد، مدیران قادرند داده‌های لاگ را بر اساس نیازشان داینامیک نمایش دهند. این می‌تواند به سادگی دیدن داده‌های بوتِ سه بوت قبل باشد، یا ترکیب ترتیبی ورودی‌های لاگ از دو سرویس مرتبط برای دیباگ مشکل ارتباطی.

ذخیره داده‌های لاگ در قالب باینری هم یعنی داده‌ها را می‌توان در قالب‌های خروجی دلخواهی نمایش داد؛ بسته به اینکه در لحظه چه چیزی لازم دارید. مثلاً برای مدیریت روزانه لاگ، ممکن است به دیدن لاگ‌ها در قالب استاندارد syslog عادت داشته باشید؛ اما اگر بعداً تصمیم بگیرید وقفه‌های سرویس را نمودار کنید، می‌توانید هر ورودی را به‌عنوان شیء JSON خروجی بدهید تا برای سرویس نمودارتان قابل مصرف باشد. چون داده‌ها به‌صورت متن ساده روی دیسک نوشته نمی‌شوند، وقتی قالب در-لحظه-متفاوتی نیاز دارید، هیچ تبدیلی لازم نیست.

ژورنال systemd را می‌توان یا همراه پیاده‌سازی syslog موجود استفاده کرد، یا بسته به نیازتان، قابلیت syslog را جایگزین کند. در حالی که ژورنال systemd بیشتر نیازهای لاگینگ مدیران را پوشش می‌دهد، می‌تواند مکمل سازوکارهای لاگینگ موجود هم باشد. مثلاً ممکن است سرور syslog متمرکزی داشته باشید که برای تجمیع داده از چند سرور استفاده می‌کنید؛ اما همچنین مایل باشید لاگ‌های چند سرویس روی یک سیستم را با ژورنال systemd درهم‌بافته کنید. با ترکیب این فناوری‌ها هر دو کار ممکن است.

نحوه تنظیم درست زمان سیستم با timedatectl

یکی از مزایای استفاده از ژورنال باینری برای لاگینگ، توانایی دیدن رکوردهای لاگ در UTC یا زمان محلی در هر لحظه است. به‌طور پیش‌فرض، systemd نتایج را در زمان محلی نمایش می‌دهد.

به همین دلیل، قبل از شروع کار با ژورنال، مطمئن می‌شویم که منطقه زمانی درست تنظیم شده. مجموعه systemd در واقع ابزاری به نام 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

خط اول باید زمان درست را نمایش دهد.

نحوه مشاهده لاگ‌ها با journalctl

برای دیدن لاگ‌هایی که دیمن journald جمع‌آوری کرده، از دستور journalctl استفاده کنید.

وقتی به‌تنهایی استفاده شود، هر ورودی ژورنالی که در سیستم باشد داخل یک Pager (معمولاً less) برای مرور نمایش داده می‌شود. قدیمی‌ترین ورودی‌ها بالا خواهند بود:

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 مدت طولانی روی سیستم‌تان بوده، می‌تواند ده‌ها یا صدها هزار خط طولانی باشد. این نشان می‌دهد چقدر داده در دیتابیس ژورنال موجود است.

قالب برای کسانی که به لاگینگ استاندارد syslog عادت دارند آشنا خواهد بود. اما این در واقع داده‌ها را از منابع بیشتری نسبت به آنچه پیاده‌سازی‌های سنتی syslog قادرند جمع‌آوری می‌کند. شامل لاگ‌های اوایل فرایند بوت، کرنل، initrd و خطا و خروجی استاندارد اپلیکیشن‌هاست. همه این‌ها در ژورنال موجودند.

ممکن است متوجه شوید همه تایم‌استمپ‌های نمایش‌داده‌شده زمان محلی‌اند. این برای هر ورودی لاگ الان که زمان محلی را درست روی سیستم‌مان تنظیم کرده‌ایم موجود است. همه لاگ‌ها با این اطلاعات جدید نمایش داده می‌شوند.

اگر می‌خواهید تایم‌استمپ‌ها را در UTC نمایش دهید، از فلگ --utc استفاده کنید:

journalctl --utc

نحوه فیلتر لاگ‌های systemd بر اساس زمان با journalctl

در حالی که دسترسی به چنین مجموعه بزرگی از داده‌ها قطعاً مفید است، چنین مقدار زیادی اطلاعات می‌تواند برای بازرسی و پردازش دستی دشوار یا غیرممکن باشد. به همین دلیل، یکی از مهم‌ترین قابلیت‌های journalctl گزینه‌های فیلترینگ آن است.

نمایش لاگ‌های نشست بوت فعلی با journalctl

ساده‌ترین این‌ها که ممکن است روزانه استفاده کنید، فلگ -b است. این همه ورودی‌های ژورنالی را که از آخرین ریبوت جمع‌آوری شده‌اند نشان می‌دهد:

journalctl -b

این به شناسایی و مدیریت اطلاعاتی که با محیط فعلی‌تان مرتبط است کمک می‌کند.

در مواردی که از این قابلیت استفاده نمی‌کنید و بیش از یک روز بوت را نمایش می‌دهید، خواهید دید که journalctl هر وقت سیستم پایین رفته، خطی شبیه این درج کرده:

. . .

-- Reboot --

. . .

از این می‌توان برای جدا کردن منطقی اطلاعات به نشست‌های بوت استفاده کرد.

نحوه دسترسی به لاگ‌های بوت‌های قبلی با journalctl

در حالی که معمولاً اطلاعات بوت فعلی را می‌خواهید نمایش دهید، قطعاً مواقعی هست که بوت‌های گذشته هم مفید باشند. ژورنال می‌تواند اطلاعات بسیاری از بوت‌های قبلی را ذخیره کند؛ پس می‌توان journalctl را برای نمایش آسان اطلاعات تنظیم کرد.

برخی توزیع‌ها ذخیره اطلاعات بوت قبلی را به‌طور پیش‌فرض فعال می‌کنند؛ برخی دیگر این قابلیت را غیرفعال می‌کنند. برای فعال کردن اطلاعات بوت ماندگار، می‌توانید یا با تایپ این، دایرکتوری ذخیره ژورنال را بسازید:

sudo mkdir -p /var/log/journal

یا فایل پیکربندی ژورنال را ویرایش کنید:

sudo nano /etc/systemd/journald.conf

زیر بخش [Journal]، گزینه Storage= را روی «persistent» تنظیم کنید تا لاگینگ ماندگار فعال شود:

/etc/systemd/journald.conf
. . .
[Journal]
Storage=persistent

وقتی ذخیره بوت‌های قبلی روی سرورتان فعال باشد، journalctl دستوراتی برای کار با بوت‌ها به‌عنوان واحد تقسیم ارائه می‌دهد. برای دیدن بوت‌هایی که journald می‌شناسد، از گزینه --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 استفاده کرد. اگر مرجع مطلق لازم دارید، شناسه بوت در ستون دوم است. زمانی که نشست بوت به آن اشاره دارد را می‌توانید با دو مشخصه زمانی فهرست‌شده به سمت انتها بفهمید.

برای نمایش اطلاعات از این بوت‌ها، می‌توانید از اطلاعات ستون اول یا دوم استفاده کنید.

مثلاً برای دیدن ژورنال بوت قبلی، از اشاره‌گر نسبی -1 با فلگ -b استفاده کنید:

journalctl -b -1

همچنین می‌توانید از شناسه بوت برای فراخوانی داده‌های یک بوت استفاده کنید:

journalctl -b caf0524a1d394ce0bdbcff75b94444fe

فیلتر لاگ‌های journalctl بر اساس بازه‌های تاریخ و زمان سفارشی

در حالی که دیدن ورودی‌های لاگ بر اساس بوت فوق‌العاده مفید است، اغلب ممکن است بخواهید پنجره‌های زمانی‌ای را درخواست کنید که با بوت‌های سیستم هم‌راستا نیستند. این به‌ویژه هنگام کار با سرورهای طولانی‌مدت با Uptime قابل توجه می‌تواند صادق باشد.

می‌توانید با گزینه‌های --since و --until بر اساس محدودیت‌های زمانی دلخواه فیلتر کنید؛ که ورودی‌های نمایش‌داده‌شده را به آن‌های بعد از یا قبل از زمان داده‌شده محدود می‌کنند.

مقادیر زمانی می‌توانند در قالب‌های متنوعی بیایند. برای مقادیر زمان مطلق، باید از این قالب استفاده کنید:

YYYY-MM-DD HH:MM:SS

مثلاً می‌توانیم همه ورودی‌های بعد از ۱۰ ژانویه ۲۰۱۵ ساعت ۵:۱۵ بعدازظهر را با تایپ این ببینیم:

journalctl --since "2015-01-10 17:15:00"

اگر بخش‌هایی از قالب بالا حذف شوند، برخی پیش‌فرض‌ها اعمال می‌شوند. مثلاً اگر تاریخ حذف شود، تاریخ فعلی فرض می‌شود. اگر بخش زمان مفقود باشد، «00:00:00» (نیمه‌شب) جایگزین می‌شود. فیلد ثانیه هم می‌تواند حذف شود تا به «00» پیش‌فرض شود:

journalctl --since "2015-01-10" --until "2015-01-11 03:00"

ژورنال برخی مقادیر نسبی و میان‌برهای نام‌گذاری‌شده را هم می‌فهمد. مثلاً می‌توانید از کلمات «yesterday»، «today»، «tomorrow» یا «now» استفاده کنید. زمان‌های نسبی را می‌توان با پیش‌گذاشتن «-» یا «+» به مقدار عددی یا استفاده از کلماتی مثل «ago» در ساختار جمله ساخت.

برای گرفتن داده‌های دیروز، می‌توانستید تایپ کنید:

journalctl --since yesterday

اگر گزارش‌هایی از وقفه سرویسِ شروع‌شده از ساعت ۹ صبح و ادامه‌دار تا یک ساعت پیش دریافت کرده بودید، می‌توانستید تایپ کنید:

journalctl --since 09:00 --until "1 hour ago"

همان‌طور که می‌بینید، تعریف پنجره‌های زمانی منعطف برای فیلتر ورودی‌هایی که می‌خواهید ببینید نسبتاً سرراست است.

نحوه فیلتر لاگ‌های ژورنال systemd بر اساس سرویس، PID یا کاربر

در بالا، چند روش برای فیلتر داده‌های ژورنال با محدودیت‌های زمانی آموختید. در این بخش بحث می‌کنیم چگونه بر اساس سرویس یا جزء موردعلاقه‌تان فیلتر کنید. ژورنال systemd روش‌های متنوعی برای این کار ارائه می‌دهد.

مشاهده لاگ‌ها بر اساس یونیت سرویس Systemd

شاید مفیدترین روش فیلترینگ، بر اساس یونیتی است که به آن علاقه‌مندید. می‌توانیم از گزینه -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

این می‌تواند دیدن تعاملات بین برنامه‌های مختلف و دیباگ سیستم‌ها (به‌جای پروسه‌های منفرد) را بسیار ساده‌تر کند.

فیلتر لاگ‌های systemd بر اساس PID، UID یا GID

برخی سرویس‌ها انواعی از پروسه‌های فرزند برای انجام کار تولید می‌کنند. اگر PID دقیق پروسه موردعلاقه‌تان را پیدا کرده باشید، می‌توانید بر اساس آن هم فیلتر کنید.

برای این کار می‌توانیم با مشخص کردن فیلد _PID فیلتر کنیم. مثلاً اگر PID موردعلاقه‌مان ۸۰۸۸ باشد، می‌توانستیم تایپ کنیم:

journalctl _PID=8088

در موارد دیگر، ممکن است بخواهید همه ورودی‌های لاگ‌شده از کاربر یا گروه خاصی را نشان دهید. این کار با فیلترهای _UID یا _GID قابل انجام است. مثلاً اگر وب‌سرور شما با کاربر www-data اجرا می‌شود، می‌توانید شناسه کاربر را با تایپ این پیدا کنید:

id -u www-data

33

بعد، می‌توانید از شناسه برگردانده‌شده برای فیلتر نتایج ژورنال استفاده کنید:

journalctl _UID=33 --since today

ژورنال systemd فیلدهای زیادی دارد که می‌توان برای فیلترینگ استفاده کرد. برخی از این‌ها از پروسهِ در حال لاگ شدن پاس داده می‌شوند و برخی توسط journald با اطلاعاتی که در زمان لاگ از سیستم جمع‌آوری می‌کند اعمال می‌شوند.

خط تیره ابتدایی نشان می‌دهد فیلد _PID از نوع دومی است. ژورنال به‌طور خودکار PID پروسهِ لاگ‌کننده را برای فیلترینگ بعدی ثبت و ایندکس می‌کند. می‌توانید درباره همه فیلدهای موجود ژورنال با تایپ این اطلاعات کسب کنید:

man systemd.journal-fields

در این راهنما برخی از این‌ها را بحث خواهیم کرد. فعلاً، روی یک گزینه مفید دیگر مرتبط با فیلترینگ بر اساس این فیلدها مرور می‌کنیم. گزینه -F می‌تواند برای نمایش همه مقادیر موجود یک فیلد ژورنال خاص استفاده شود.

مثلاً برای دیدن اینکه ژورنال systemd برای کدام شناسه‌های گروه ورودی دارد، می‌توانید تایپ کنید:

journalctl -F _GID

32
99
102
133
81
84
100
0
124
87

این همه مقادیری را که ژورنال برای فیلد شناسه گروه ذخیره کرده نشان می‌دهد. می‌تواند به ساخت فیلترهای‌تان کمک کند.

مشاهده لاگ‌ها بر اساس مسیر فایل اجرایی

می‌توانیم با ارائه یک مسیر مکان هم فیلتر کنیم.

اگر مسیر به یک فایل اجرایی منتهی شود، journalctl همه ورودی‌هایی را که آن فایل اجرایی در آن‌ها دخیل است نمایش می‌دهد. مثلاً برای پیدا کردن ورودی‌هایی که فایل اجرایی bash در آن‌ها دخیل است، می‌توانید تایپ کنید:

journalctl /usr/bin/bash

معمولاً، اگر یونیتی برای فایل اجرایی موجود باشد، آن روش تمیزتر است و اطلاعات بهتری می‌دهد (ورودی‌های پروسه‌های فرزند مرتبط و غیره). گاهی اما این ممکن نیست.

نحوه مشاهده لاگ‌های کرنل با journalctl -k

پیام‌های کرنل—که معمولاً در خروجی dmesg یافت می‌شوند—را می‌توان از ژورنال هم بازیابی کرد.

برای نمایش فقط این پیام‌ها، می‌توانیم فلگ‌های -k یا --dmesg را به دستورمان اضافه کنیم:

journalctl -k

به‌طور پیش‌فرض، این پیام‌های کرنلِ بوت فعلی را نمایش می‌دهد. می‌توانید با فلگ‌های معمول انتخاب بوت که قبلاً بحث شد، بوت جایگزینی مشخص کنید. مثلاً برای گرفتن پیام‌های پنج بوت قبل، می‌توانستید تایپ کنید:

journalctl -k -b -5

فیلتر لاگ‌ها بر اساس سطح شدت با journalctl -p

فیلتری که مدیران سیستم اغلب به آن علاقه‌مندند، اولویت پیام است. در حالی که ثبت اطلاعات در سطح بسیار پرحرف اغلب مفید است، هنگام هضم واقعی اطلاعات موجود، لاگ‌های کم‌اولویت می‌توانند حواس‌پرت‌کننده و گیج‌کننده باشند.

می‌توانید از journalctl برای نمایش فقط پیام‌های اولویت مشخص یا بالاتر با گزینه -p استفاده کنید. این به شما اجازه می‌دهد پیام‌های کم‌اولویت را فیلتر کنید.

مثلاً برای نمایش فقط ورودی‌های ثبت‌شده در سطح خطا یا بالاتر، می‌توانید تایپ کنید:

journalctl -p err -b

این همه پیام‌های علامت‌خورده به‌عنوان error، critical، alert یا emergency را نشان می‌دهد. ژورنال سطوح پیام استاندارد syslog را پیاده‌سازی می‌کند. می‌توانید از نام اولویت یا مقدار عددی متناظرش استفاده کنید. به ترتیب بالاترین تا پایین‌ترین اولویت، این‌ها عبارت‌اند از:

0: emerg
1: alert
2: crit
3: err
4: warning
5: notice
6: info
7: debug

اعداد یا نام‌های بالا را می‌توان به‌جای هم با گزینه -p استفاده کرد. انتخاب اولویتی، پیام‌های علامت‌خورده در سطح مشخص‌شده و بالاتر از آن را نمایش می‌دهد.

سفارشی‌سازی نمایش خروجی لاگ journalctl

در بالا، انتخاب ورودی را از طریق فیلترینگ نمایش دادیم. راه‌های دیگری هم هست که می‌توانیم خروجی را تغییر دهیم. می‌توانیم نمایش journalctl را برای برآوردن نیازهای مختلف تنظیم کنیم.

نحوه کنترل طول و قالب‌بندی خروجی در journalctl

می‌توانیم با گفتن به journalctl که خروجی را جمع یا باز کند، نحوه نمایش داده‌ها را تنظیم کنیم.

به‌طور پیش‌فرض، journalctl کل ورودی را در Pager نشان می‌دهد؛ و اجازه می‌دهد ورودی‌ها به سمت راست صفحه بیرون بزنند. این اطلاعات با فشار کلید فلش راست قابل دسترسی است.

اگر ترجیح می‌دهید خروجی بریده شود و جایی که اطلاعات حذف شده سه‌نقطه (Ellipsis) درج شود، از گزینه --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

نحوه غیرفعال کردن Pager در خروجی journalctl

به‌طور پیش‌فرض، journalctl خروجی را در یک Pager برای مصرف آسان‌تر نمایش می‌دهد. اگر قصد پردازش داده‌ها با ابزارهای دستکاری متن را دارید اما، احتمالاً می‌خواهید بتوانید به خروجی استاندارد خروجی بگیرید.

این کار را با گزینه --no-pager می‌توانید انجام دهید:

journalctl --no-pager

این را می‌توان بلافاصله به ابزار پردازشی پایپ یا بسته به نیاز، به فایلی روی دیسک ریدایرکت کرد.

قالب‌های خروجی مختلف در journalctl

اگر در حال پردازش ورودی‌های ژورنال هستید، همان‌طور که در بالا اشاره شد، به احتمال زیاد اگر داده‌ها در قالبی قابل‌مصرف‌تر باشند، پارس‌شان راحت‌تر خواهد بود. خوشبختانه ژورنال را می‌توان در قالب‌های متنوعی بسته به نیاز نمایش داد. این کار را با گزینه -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 برای درک بهتر ساختار داده قبل از پاس دادن به مصرف‌کننده JSON استفاده کنید:

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 قالب‌بندی‌شده و wrap شده برای سازگاری با Server-Sent Event.
• short: خروجی پیش‌فرض به سبک syslog.
• short-iso: قالب پیش‌فرض با تایم‌استمپ‌های دیواری ISO 8601.
• short-monotonic: قالب پیش‌فرض با تایم‌استمپ‌های Monotonic.
• short-precise: قالب پیش‌فرض با دقت میکروثانیه.
• verbose: همه فیلدهای ژورنال موجود برای ورودی را—even آن‌هایی که معمولاً به‌صورت داخلی پنهان‌اند—نشان می‌دهد.

این گزینه‌ها به شما اجازه می‌دهند ورودی‌های ژورنال را در هر قالبی که بهترین برآورد نیاز فعلی‌تان را دارد نمایش دهید.

مانیتور لاگ‌های زنده systemd با journalctl

دستور journalctl از نحوه استفاده بسیاری از مدیران از tail برای مانیتورینگ فعالیت فعال یا اخیر تقلید می‌کند. این قابلیت داخل journalctl ساخته شده؛ که به شما اجازه می‌دهد بدون نیاز به پایپ به ابزار دیگر به این قابلیت‌ها دسترسی پیدا کنید.

نمایش ورودی‌های لاگ اخیر با journalctl -n

برای نمایش تعداد مشخصی رکورد، می‌توانید از گزینه -n استفاده کنید؛ که دقیقاً مثل tail -n کار می‌کند.

به‌طور پیش‌فرض، ۱۰ ورودی اخیر را نمایش می‌دهد:

journalctl -n

می‌توانید تعداد ورودی‌هایی را که می‌خواهید ببینید با عددی بعد از -n مشخص کنید:

journalctl -n 20

دنبال کردن لاگ‌های بلادرنگ با journalctl -f

برای دنبال کردن فعالانه لاگ‌ها همان‌طور که نوشته می‌شوند، می‌توانید از فلگ -f استفاده کنید. باز هم، این همان‌طور که انتظار دارید کار می‌کند اگر تجربه استفاده از tail -f دارید:

journalctl -f

برای خروج از این دستور، CTRL+C را تایپ کنید.

نحوه مدیریت و پاک‌سازی لاگ‌های ژورنال systemd

شاید در مورد هزینه ذخیره همه داده‌هایی که تا حالا دیدیم تعجب کنید. علاوه بر این، شاید به پاک‌سازی برخی لاگ‌های قدیمی و آزاد کردن فضا علاقه‌مند باشید.

بررسی مصرف دیسک لاگ‌های systemd با journalctl –disk-usage

می‌توانید مقدار فضایی که ژورنال در حال حاضر روی دیسک اشغال کرده را با فلگ --disk-usage بفهمید:

journalctl --disk-usage

Archived and active journals take up 8.0M in the file system.

حذف لاگ‌های قدیمی با journalctl –vacuum-size و –vacuum-time

اگر مایل به کوچک کردن ژورنال‌تان هستید، می‌توانید این کار را به دو روش مختلف انجام دهید (موجود با systemd نسخه ۲۱۸ و بعدتر).

اگر از گزینه --vacuum-size استفاده کنید، می‌توانید با نشان دادن یک اندازه، ژورنال‌تان را کوچک کنید. این، ورودی‌های قدیمی را تا وقتی کل فضای ژورنالِ گرفته‌شده روی دیسک به اندازه درخواستی برسد حذف می‌کند:

sudo journalctl --vacuum-size=1G

راه دیگر برای کوچک کردن ژورنال، ارائه زمان برش با گزینه --vacuum-time است. هر ورودی فراتر از آن زمان حذف می‌شود. این اجازه می‌دهد ورودی‌هایی را که بعد از زمان خاصی ساخته شده‌اند نگه دارید.

مثلاً برای نگه‌داشتن ورودی‌های یک سال اخیر، می‌توانید تایپ کنید:

sudo journalctl --vacuum-time=1years

پیکربندی محدودیت‌های فضای دیسک برای لاگ‌های Journald

می‌توانید سرورتان را برای تعیین محدودیت‌هایی روی اینکه ژورنال چقدر فضا بگیرد پیکربندی کنید. این کار با ویرایش فایل /etc/systemd/journald.conf انجام می‌شود.

موارد زیر را می‌توان برای محدود کردن رشد ژورنال استفاده کرد:

• SystemMaxUse=: حداکثر فضای دیسکی که ژورنال در ذخیره‌سازی ماندگار می‌تواند استفاده کند را مشخص می‌کند.
• SystemKeepFree=: مقدار فضایی را که ژورنال باید هنگام افزودن ورودی‌های ژورنال به ذخیره‌سازی ماندگار آزاد بگذارد مشخص می‌کند.
• SystemMaxFileSize=: کنترل می‌کند فایل‌های منفرد ژورنال در ذخیره‌سازی ماندگار قبل از چرخیده شدن تا چه اندازه‌ای می‌توانند رشد کنند.
• RuntimeMaxUse=: حداکثر فضای دیسکی که در ذخیره‌سازی فرّار (داخل فایل‌سیستم /run) می‌تواند استفاده شود را مشخص می‌کند.
• RuntimeKeepFree=: مقدار فضایی را که هنگام نوشتن داده به ذخیره‌سازی فرّار (داخل فایل‌سیستم /run) باید برای مصارف دیگر کنار گذاشته شود مشخص می‌کند.
• RuntimeMaxFileSize=: فضایی را که یک فایل ژورنال منفرد در ذخیره‌سازی فرّار (داخل فایل‌سیستم /run) قبل از چرخیده شدن می‌تواند اشغال کند مشخص می‌کند.

با تنظیم این مقادیر می‌توانید کنترل کنید journald چگونه فضا را روی سرورتان مصرف و حفظ می‌کند. در نظر داشته باشید که SystemMaxFileSize و RuntimeMaxFileSize برای رسیدن به محدودیت‌های بیان‌شده، فایل‌های آرشیوشده را هدف می‌گیرند. این هنگام تفسیر تعداد فایل‌ها بعد از عملیات Vacuum مهم است که به یاد داشته باشید.

عیب‌یابی مسائل رایج journalctl و ژورنال systemd

۱. چرا journalctl لاگ‌ها را نشان نمی‌دهد؟

در برخی موارد، ممکن است دستور journalctl را اجرا کنید و انتظار دیدن خروجی لاگ را داشته باشید؛ اما با صفحه خالی یا نتیجه بی‌معنایی روبه‌رو شوید. این وضعیت می‌تواند گیج‌کننده باشد؛ به‌ویژه اگر در حال عیب‌یاب مشکلی هستید یا به دنبال فعالیت اخیر سیستم می‌گردید. خوشبختانه چند توضیح رایج وجود دارد که کمک می‌کند بفهمید چرا journalctl لاگ‌ها را نشان نمی‌دهد.

دیتابیس ژورنال خالی یا مفقود است

یکی از سرراست‌ترین دلایل دیدن خروجی نبودن، خالی بودن ژورنال است. این می‌تواند روی سیستم‌های تازه‌نصب‌شده، محیط‌های مینیمال کانتینر یا سرورهایی که لاگینگ سیستم هنوز هیچ ورودی‌ای تولید نکرده اتفاق بیفتد. همچنین ممکن است سیستم‌تان طوری پیکربندی شده باشد که لاگ‌ها را فقط در حافظه (ذخیره‌سازی فرّار) نگه دارد؛ یعنی همه لاگ‌ها با ریبوت پاک می‌شوند. برای چک کردن فعال بودن لاگینگ ماندگار، می‌توانید وجود دایرکتوری ژورنال را ببینید:

ls /var/log/journal

اگر این دایرکتوری وجود ندارد یا خالی است، یعنی لاگ‌های‌تان بین بوت‌ها ذخیره نمی‌شوند. می‌توانید با ساخت دایرکتوری و ری‌استارت سرویس journald این را حل کنید:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

بعد از فعال شدن لاگینگ ماندگار، لاگ‌های آینده روی دیسک نوشته و بین ریبوت‌ها نگه داشته می‌شوند.

سرویس لاگینگ ممکن است در حال اجرا نباشد

احتمال دیگر این است که خود سرویس لاگینگ با خطا روبه‌رو شده یا در شروع شکست خورده. سرویس systemd-journald مسئول جمع‌آوری و مدیریت داده‌های لاگ است. اگر در حال اجرا نباشد، ژورنال به‌طور طبیعی خالی خواهد بود. وضعیتش را می‌توانید با این چک کنید:

systemctl status systemd-journald

اگر سرویس غیرفعال یا شکست‌خورده است، ری‌استارتش باید قابلیت جمع‌آوری لاگ را برگرداند.

فیلترها ممکن است خیلی تنگ باشند

گاهی، مسئله از خود لاگ‌ها نیست؛ بلکه از نحوه دسترسی‌تان به آن‌هاست. استفاده از فیلترهای تنگ—مثل نام یونیت ناموجود یا بازه زمانی بیش‌ازحد خاص—حتی وقتی داده مرتبط وجود دارد، می‌تواند بدون نتیجه برگردد. اغلب مفید است journalctl را بدون هیچ فلگی اجرا کنید تا تأیید شود لاگ‌ها در حال جمع‌آوری‌اند؛ سپس به‌تدریج فیلترها را در صورت نیاز اعمال کنید.

لاگ‌ها ممکن است چرخیده یا حذف شده باشند

در نهایت، در نظر داشته باشید که لاگ‌های ژورنال مشمول سیاست‌های نگهداری مبتنی بر اندازه و زمان‌اند. اگر لاگ‌های قدیمی توسط systemd-journald خلأ (Vacuum) شده باشند، دیگر قابل دسترسی نخواهند بود. می‌توانید بررسی کنید ژورنال الان چقدر فضا استفاده می‌کند:

journalctl --disk-usage

اگر سیستم‌تان را برای محدود کردن تهاجمی اندازه ژورنال پیکربندی کرده‌اید یا اخیراً دستور Vacuum را دستی اجرا کرده‌اید، ممکن است لاگ‌ها از دیتابیس پاک شده باشند.

۲. Permission Denied هنگام استفاده از journalctl

اگر سعی کنید journalctl را به‌عنوان کاربر عادی اجرا کنید و پیام «permission denied» دریافت کنید، تنها نیستید. به‌طور پیش‌فرض، دسترسی به لاگ‌های سیستم برای کاربر root و اعضای گروه systemd-journal محدود است. این محدودیت برای محافظت از داده‌های لاگِ بالقوه حساس طراحی شده؛ که می‌تواند شامل اطلاعاتی درباره فعالیت کاربر، پروسه‌های سیستم و خرابی‌های سرویس باشد.

اجرای journalctl با دسترسی‌های ارتقایافته

ساده‌ترین و رایج‌ترین راه‌حل، اجرای دستور با sudo است. این دسترسی‌های شما را برای مدت دستور ارتقا می‌دهد و اجازه می‌دهد همه لاگ‌های سیستم را ببینید:

sudo journalctl

اگر در حال اسکریپت‌نویسی یا بازرسی مکرر لاگ‌ها هستید، تایپ sudo در هر بار می‌تواند خسته‌کننده شود. در چنین مواردی، ممکن است کاربردی‌تر باشد که دسترسی کاربرتان به ژورنال را دائمی بدهید.

دادن دسترسی کاربر از طریق عضویت در گروه

برای اجتناب از نیاز به sudo، می‌توانید کاربرتان را به گروه systemd-journal اضافه کنید. این گروه مخصوصاً برای اجازه خواندن لاگ‌های ژورنال توسط کاربران غیر root طراحی شده. می‌توانید کاربرتان را با دستور زیر به گروه اضافه کنید:

sudo usermod -aG systemd-journal yourusername

حتماً yourusername را با نام ورود واقعی‌تان جایگزین کنید. بعد از افزودن کاربر به گروه، باید از سیستم خارج و دوباره وارد شوید تا تغییر اثر بگذارد. بعد از آن، باید بتوانید journalctl را بدون نیاز به دسترسی ارتقایافته اجرا کنید.

تأیید مجوزهای ژورنال

اگر عضویت در گروه مسئله را حل نکرد، ممکن است مشکلی با مجوزهای فایل یا دایرکتوری وجود داشته باشد. دایرکتوری /var/log/journal باید متعلق به root و گروهش systemd-journal باشد. مجوزهای خواندن گروه باید درست تنظیم شده باشند؛ وگرنه حتی اگر در گروه درست هستید، دسترسی همچنان رد می‌شود. می‌توانید با این اصلاحش کنید:

sudo chown root:systemd-journal /var/log/journal
sudo chmod 2755 /var/log/journal

با این مجوزها و عضویت درست در گروه، کاربران غیر root می‌توانند به‌صورت امن به لاگ‌ها دسترسی پیدا کنند.

۳. لاگ‌ها بعد از ریبوت ماندگار نمی‌شوند

اگر متوجه شدید لاگ‌ها هر بار که سرورتان ریبوت می‌شود ناپدید می‌شوند، احتمالاً سیستم‌تان طوری پیکربندی شده که لاگ‌ها را فقط در حافظه فرّار ذخیره کند؛ که با خاموش شدن ماشین از بین می‌رود. این پیش‌فرض رایجی در بسیاری از توزیع‌های لینوکس و محیط‌های کانتینر است؛ به‌ویژه آن‌هایی که برای مصرف دیسک پایین بهینه شده‌اند.

فعال کردن لاگینگ ماندگار

برای نگه‌داشتن لاگ‌ها بین ریبوت‌ها، باید journald را برای استفاده از ذخیره‌سازی ماندگار پیکربندی کنید. این نیازمند ساخت دایرکتوری مناسب‌ای است که ژورنال بتواند لاگ‌ها را روی دیسک در آن بنویسد. مسیر /var/log/journal برای این هدف استفاده می‌شود. اگر وجود ندارد، بسازید و دیمن لاگینگ را ری‌استارت کنید:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

بعد از انجام این کار، همه لاگ‌های آینده روی دیسک نوشته و از ریبوت‌های سیستم جان سالم به در می‌برند.

تأیید پیکربندی journald

اگر دایرکتوری وجود دارد اما لاگ‌ها همچنان ماندگار نمی‌شوند، ارزشش را دارد فایل پیکربندی journald را بازرسی کنید:

sudo nano /etc/systemd/journald.conf

در این فایل، به دنبال دایرکتیو Storage= زیر بخش [Journal] بگردید. اگر روی volatile تنظیم شده، به persistent تغییرش دهید:

[Journal]
Storage=persistent

فایل را ذخیره و سرویس را برای اعمال تغییرات ری‌استارت کنید. این تضمین می‌کند سیستم از این پس لاگ‌ها را به‌جای RAM روی دیسک بنویسد.

۴. دیباگ سرویس شکست‌خورده systemd

وقتی سرویسِ مدیریت‌شده با systemd در شروع شکست می‌خورد یا غیرمنتظره کرش می‌کند، journalctl به ابزاری ضروری برای شناسایی علت ریشه‌ای تبدیل می‌شود. به‌جای جستجو در فایل‌های لاگ متعدد، ژورنال همه پیام‌های مرتبط با یک سرویس را—کامل با متادیتا، تایم‌استمپ و سطوح اولویت—یک‌جا جمع می‌کند.

بررسی وضعیت سرویس

اولین قدم هنگام عیب‌یابی، بررسی وضعیت سرویس است. دستور systemctl status تصویری لحظه‌ای از وضعیت فعلی سرویس—شامل جدیدترین ورودی‌های لاگ—فراهم می‌کند. مثلاً:

systemctl status nginx.service

این خروجی اغلب مسائل فوری‌ای مثل مسیرهای پیکربندی‌اشتباه، مشکلات مجوز یا کدهای خروج را آشکار می‌کند. کد خروج و اطلاعات سیگنال، در صورت وجود، می‌توانند به‌ویژه برای تعیین اینکه سرویس خودش شکست خورده یا توسط سیستم کشته شده مفید باشند.

مشاهده کل تاریخچه لاگ

برای دیدن همه لاگ‌های مرتبط با سرویس شکست‌خورده، از journalctl با فلگ -u استفاده کنید:

journalctl -u nginx.service

این نمای زمان‌مرتبی از پیام‌های تولیدشده توسط سرویس فراهم می‌کند. اگر در تلاش به تشخیص شکستی هستید که در آخرین بوت سیستم رخ داده، مفید است خروجی را فقط به آن نشست محدود کنید:

journalctl -u nginx.service -b

بررسی زمینه شکست

اغلب می‌توانید با خواندن ورودی‌های لاگِ چند دقیقه قبل و بعد از شکست به قلب مسئله برسید. از فیلترهای مبتنی بر زمان برای محدود کردن تمرکز استفاده کنید:

journalctl -u nginx.service --since "10 minutes ago"

این می‌تواند کمک کند تشخیص دهید مسئله ایزوله بوده یا بخشی از مشکل بزرگ‌تر سیستم.

برای تحلیل عمیق‌تر، می‌توانید خروجی تفصیلی را فعال یا پیام‌های خطای گسترده را با این ببینید:

journalctl -xe

این دستور پیام‌های اولویت‌دار و خرابی‌های اخیر را هایلایت می‌کند؛ که وقتی سرویسی در خروجی استاندارد سرنخ‌های بدیهی باقی نمی‌گذارد مفید است.

۵. مانیتور تلاش‌های ورود SSH

SSH روش دسترسی اولیه برای بیشتر سرورهای لینوکسی است؛ که آن را به بردار رایجی برای حملات brute-force، تلاش‌های دسترسی غیرمجاز یا ممیزی عمومی هم تبدیل می‌کند. خوشبختانه journalctl اجازه می‌دهد همه فعالیت‌های مرتبط با SSH را با سهولت مانیتور کنید.

مشاهده لاگ‌های SSH

systemd فعالیت SSH را—بسته به توزیع‌تان—زیر یونیت sshd یا ssh ردیابی می‌کند. برای دیدن همه ورودی‌های مرتبط با SSH:

journalctl -u ssh.service

یا روی برخی سیستم‌ها:

journalctl -u sshd.service

این لاگ‌ها شامل تلاش‌های ورود، خرابی‌های احراز هویت، بسته‌شدن نشست‌ها و پیام‌های مذاکره کلید هستند. قدم اول عالی‌ای هنگام تأیید اینکه چه کسی و کِی به سرور دسترسی داشته است.

دنبال کردن فعالیت SSH در زمان واقعی

برای مانیتورینگ بلادرنگ، می‌توانید journalctl را در حالت دنبال‌کردن استفاده کنید. این به‌ویژه مفید است اگر به نفوذ مشکوک هستید یا می‌خواهید به تلاش‌های ورود فعال چشم داشته باشید:

journalctl -f -u ssh.service

هر رویداد ورود جدید همان‌طور که اتفاق می‌افتد زنده چاپ می‌شود؛ که دیدن ورودهای ناموفق یا تلاش‌های اتصال سریعی که می‌توانند نشانه رفتار مخرب باشند را ساده‌تر می‌کند.

فیلتر بر اساس رویدادهای ورود

اگر به دنبال پیام‌های ورود خاصی—مثل رمزهای عبور ناموفق یا اتصالات پذیرفته‌شده—می‌گردید، می‌توانید خروجی ژورنال را با تطبیق کلیدواژه فیلتر کنید:

journalctl -u ssh.service | grep "Failed password"
journalctl -u ssh.service | grep "Accepted password"

این پیام‌ها نشان می‌دهند ورود موفق بوده یا نه و چه کاربری تلاش کرده. می‌توانید این‌ها را با فیلترهای زمانی ترکیب کنید تا جستجو را به پنجره خاصی محدود کنید:

journalctl -u ssh.service --since "1 hour ago"

این می‌تواند در ممیزی‌های امنیتی یا بررسی‌های فورنزیک فوق‌العاده مفید باشد.

سوالات متداول

۱. چرا journalctl به دسترسی root نیاز دارد؟

به‌طور پیش‌فرض، journalctl به دسترسی root نیاز دارد؛ چون می‌تواند اطلاعات حساسی که از سرویس‌های سیستم، پیام‌های کرنل، نشست‌های کاربر و دیمن‌های پس‌زمینه جمع‌آوری شده را افشا کند. این لاگ‌ها ممکن است شامل نام‌های کاربری، متغیرهای محیطی، ردهای خطا، تلاش‌های احراز هویت و جزئیات دیگر باشند که در صورت دسترسی کاربران غیرمجاز می‌توانند ریسک امنیتی ایجاد کنند.

برای محافظت از این داده‌ها، systemd دسترسی به ژورنال سیستم را محدود می‌کند. اما همیشه لازم نیست از sudo استفاده کنید. کاربران غیر root می‌توانند لاگ‌ها را بخوانند اگر عضو گروه systemd-journal باشند. می‌توانید کاربرتان را با این به گروه اضافه کنید:

sudo usermod -aG systemd-journal yourusername

بعد از خروج و ورود مجدد، باید بتوانید بدون دسترسی ارتقایافته به لاگ‌ها دسترسی پیدا کنید؛ تا وقتی مجوزهای فایل روی دایرکتوری‌های ژورنال درست پیکربندی شده باشند.

۲. چطور لاگ‌ها را بین ریبوت‌ها ماندگار کنم؟

برای حفظ لاگ‌ها بعد از ریبوت، باید systemd-journald را برای استفاده از ذخیره‌سازی ماندگار به‌جای حافظه فرّار پیکربندی کنید. به‌طور پیش‌فرض، برخی توزیع‌ها لاگ‌ها را در /run/log/journal—دایرکتوری موقتی که هنگام خاموشی پاک می‌شود—ذخیره می‌کنند. برای فعال کردن لاگینگ ماندگار:

۱. دایرکتوری ژورنال ماندگار را بسازید:

sudo mkdir -p /var/log/journal

۲. در صورت نیاز، مجوزها را تنظیم کنید:

sudo systemd-tmpfiles --create --prefix /var/log/journal

۳. دیمن ژورنال را ری‌استارت کنید:

sudo systemctl restart systemd-journald

۴. اختیاری: پیکربندی را تأیید یا ویرایش کنید:

/etc/systemd/journald.conf را باز و مطمئن شوید خط زیر تنظیم شده:

Storage=persistent

این پیکربندی تضمین می‌کند سیستم‌تان داده‌های لاگ را بین ریبوت‌ها نگه می‌دارد؛ که ممیزی و دیباگ مسائل تاریخی را ساده‌تر می‌کند.

۳. آیا می‌توانم لاگ‌های journalctl را پاک کنم؟

بله، journalctl اجازه پاک کردن لاگ‌ها را با گزینه‌های --vacuum-* ارائه‌شده توسط systemd-journald می‌دهد. این دستورات با حذف داده‌های لاگ قدیمی یا اضافی به کاهش مصرف دیسک کمک می‌کنند.

روش‌های رایج پاک کردن یا کوچک کردن لاگ‌های ژورنال:

حذف لاگ‌های قدیمی‌تر از زمان مشخص:

sudo journalctl --vacuum-time=2weeks

محدود کردن کل مصرف دیسک برای همه لاگ‌ها:

sudo journalctl --vacuum-size=500M

محدود کردن تعداد فایل‌های ژورنال نگه‌داشته‌شده:

sudo journalctl --vacuum-files=10

این دستورات لاگ‌های فعلی یا اخیر را—even—پاک نمی‌کنند مگر اینکه از آستانه تعریف‌شده عبور کنند. برای حذف کامل همه لاگ‌ها، می‌توانید فایل‌های ژورنال را دستی از /var/log/journal حذف کنید؛ اما این به‌ندرت لازم است و عموماً برای سیستم‌های پروداکشن توصیه نمی‌شود.

۴. چطور به لاگ‌های systemd دسترسی پیدا کنم؟

می‌توانید با دستور journalctl که مستقیماً با ژورنال systemd رابط دارد، به لاگ‌های systemd دسترسی پیدا کنید. همه لاگ‌های مرتبط با سرویس‌های مدیریت‌شده توسط systemd—مثل پیام‌های بوت، خرابی‌های یونیت و خطاهای زمان اجرا—در ژورنال ذخیره می‌شوند.

برای دسترسی عمومی:

journalctl

برای دیدن لاگ‌های سرویس systemd خاصی مثل nginx، استفاده کنید:

journalctl -u nginx.service

همچنین می‌توانید بر اساس نشست بوت، سطح اولویت، بازه زمانی فیلتر یا چند سرویس را برای بینش عمیق‌تر ترکیب کنید. برخلاف فایل‌های لاگ سنتی، journalctl نمای یکپارچه و ایندکس‌شده‌ای از پیام‌های لاگ از منابع متعدد فراهم می‌کند.

۵. کدام دستور برای دیدن لاگ‌های systemd استفاده می‌شود؟

دستور اصلی استفاده‌شده برای دیدن لاگ‌های systemd این است:

journalctl

این ابزار همراه systemd عرضه می‌شود و به همه لاگ‌هایی که توسط سرویس systemd-journald جمع‌آوری شده‌اند—شامل پیام‌های کرنل، لاگ‌های اوایل بوت، سرویس‌های سیستم و نشست‌های کاربر—دسترسی می‌دهد.

می‌توانید دستور را با گزینه‌های مختلف تنظیم کنید:

دیدن لاگ‌های سرویس خاص:

journalctl -u ssh.service

فیلتر لاگ‌ها بر اساس اولویت:

journalctl -p err

نمایش لاگ‌ها در زمان واقعی:

journalctl -f

این journalctl را به همه‌کاره‌ترین و جامع‌ترین ابزار برای دیدن لاگ‌های مرتبط با systemd تبدیل می‌کند.

۶. چطور لاگ‌های کرنل را از طریق journalctl ببینم؟

پیام‌های کرنل—مثل آن‌هایی که سنتی با dmesg دیده می‌شوند—از طریق ژورنال systemd هم موجودند. برای نمایش فقط پیام‌های کرنل با journalctl، از فلگ -k استفاده کنید:

journalctl -k

این دستور خروجی را طوری فیلتر می‌کند که فقط پیام‌های منشأگرفته از کرنل شامل شوند. به‌ویژه برای تشخیص مسائل سخت‌افزاری، مشکلات ماژول کرنل یا خطاهای زمان بوت مفید است. همچنین می‌توانید از گزینه -b برای نمایش پیام‌های بوت فعلی یا قبلی استفاده کنید:

journalctl -k -b -1

این دسترسی سازگاری به لاگ‌های کرنل می‌دهد؛ یکپارچه با لاگ‌های سرویس‌های دیگر برای درک زمینه‌ای بهتر.

۷. تفاوت dmesg و journalctl چیست؟

در حالی که هر دو dmesg و journalctl می‌توانند لاگ‌های کرنل را نشان دهند، اهداف متفاوتی دارند و تحت سازوکارهای متفاوتی کار می‌کنند.

ویژگی	dmesg	journalctl
محدوده	فقط بافر حلقه‌ای کرنل	لاگ‌های کرنل + سیستم + Userland
ماندگاری	با ریبوت یا پر شدن بافر پاک می‌شود	ماندگار (در صورت فعال بودن)
متادیتا	بدون متادیتای ساختاریافته	متادیتای غنی (یونیت، PID، UID و…)
فیلترینگ	محدود	قابلیت‌های فیلترینگ گسترده
قالب‌های خروجی	خام، ساده	JSON، export، short، verbose و…
مجوزها	برای خروجی کامل به sudo نیاز دارد	نیازمند root یا عضویت در گروه

خلاصه اینکه، dmesg به لاگ‌های سطح-پایین کرنل در زمان واقعی محدود است؛ در حالی که journalctl رابط لاگینگ کامل‌تر، ساختاریافته‌تر و ماندگارتری را ارائه می‌دهد که کل سیستم را در بر می‌گیرد.

نتیجه‌گیری

همان‌طور که می‌بینید، ژورنال systemd برای جمع‌آوری و مدیریت داده‌های سیستم و اپلیکیشن‌تان فوق‌العاده مفید است. بیشتر انعطاف از متادیتای گسترده‌ای که به‌طور خودکار ثبت می‌شود و ماهیت متمرکز لاگ می‌آید.

در این راهنما، مشاهده پایه لاگ، فیلترینگ مبتنی بر زمان و مبتنی بر فیلد، مانیتورینگ لاگ‌های کرنل و سرویس، قالب‌بندی خروجی و ردیابی بلادرنگ لاگ را پوشش دادیم. همچنین نگهداری ژورنال، محدودیت‌های ذخیره‌سازی و عیب‌یابی مسائل رایجی مثل لاگ‌های مفقود یا خطاهای مجوز را بحث کردیم.

دستور journalctl بهره‌گیری از قابلیت‌های پیشرفته ژورنال و انجام تحلیل گسترده و دیباگ رابطه‌ای اجزای مختلف اپلیکیشن را ساده می‌کند. با تسلط بر journalctl، رابط لاگینگ همه‌کاره و یکپارچه‌ای برای دیباگ، مانیتورینگ و ممیوزی در کل سیستم‌تان به دست می‌آورید.