সিস্টেমড লগ মাস্টারিং:লিনাক্সে জার্নালসিটিএল ব্যবহার করার জন্য একটি সম্পূর্ণ গাইড

সিস্টমড জার্নাল এবং জার্নালসিটিএল লগিংয়ের ভূমিকা

systemd এর সবচেয়ে আকর্ষণীয় কিছু সুবিধা প্রক্রিয়া এবং সিস্টেম লগিং সঙ্গে জড়িত যারা. অন্যান্য সরঞ্জাম ব্যবহার করার সময়, লগগুলি সাধারণত সিস্টেম জুড়ে ছড়িয়ে পড়ে, বিভিন্ন ডেমন এবং প্রক্রিয়া দ্বারা পরিচালিত হয় এবং একাধিক অ্যাপ্লিকেশন স্প্যান করার সময় ব্যাখ্যা করা মোটামুটি কঠিন হতে পারে। systemd সমস্ত কার্নেল এবং ইউজারল্যান্ড প্রসেস লগিং করার জন্য একটি কেন্দ্রীভূত ব্যবস্থাপনা সমাধান প্রদান করে এই সমস্যাগুলি সমাধান করার চেষ্টা করে। যে সিস্টেম এই লগগুলি সংগ্রহ করে এবং পরিচালনা করে তা জার্নাল নামে পরিচিত .

জার্নালটি journald দিয়ে প্রয়োগ করা হয় ডেমন, যা কার্নেল, initrd, পরিষেবা ইত্যাদি দ্বারা উত্পাদিত সমস্ত বার্তা পরিচালনা করে। এই নির্দেশিকায়, আমরা journalctl কীভাবে ব্যবহার করতে হয় তা নিয়ে আলোচনা করব। ইউটিলিটি, যা জার্নালের মধ্যে থাকা ডেটা অ্যাক্সেস এবং ম্যানিপুলেট করতে ব্যবহার করা যেতে পারে।

এই নিবন্ধে, আপনি কীভাবে journalctl ব্যবহার করবেন তা শিখবেন সিস্টেমড জার্নাল থেকে লগ ডেটা অ্যাক্সেস এবং ফিল্টার করার জন্য কমান্ড-লাইন টুল। আমরা নির্দিষ্ট বুট বা সময় সীমা থেকে লগ দেখতে, সিস্টেম ইউনিট, ব্যবহারকারী, বা অগ্রাধিকার স্তর দ্বারা ফিল্টার এবং অন্যান্য সরঞ্জামগুলির সাথে একীকরণের জন্য JSON-এর মতো ফর্ম্যাটে আউটপুট লগগুলিকে কভার করব৷ আপনি কীভাবে রিয়েল-টাইম ইভেন্টগুলি নিরীক্ষণ করবেন, ডিস্কের ব্যবহার পরিচালনা করবেন, ক্রমাগত লগিং কনফিগার করবেন এবং অনুপস্থিত লগ বা অনুমতি ত্রুটির মতো সাধারণ সমস্যাগুলি সমাধান করবেন তাও শিখবেন। আপনি একটি ব্যর্থ পরিষেবা ডিবাগ করছেন বা কেন্দ্রীভূত লগ সংগ্রহ সেট আপ করছেন না কেন, journalctl আপনার কর্মপ্রবাহকে স্ট্রিমলাইন করার জন্য নমনীয়তা এবং নির্ভুলতা প্রদান করে৷

প্রধান টেকওয়ে

• systemd জার্নাল একটি ইউনিফাইড লগিং সিস্টেম সরবরাহ করে যা কার্নেল, পরিষেবা এবং ব্যবহারকারীর অ্যাপ্লিকেশনগুলি থেকে বার্তাগুলিকে একটি কেন্দ্রীভূত, সূচীযুক্ত লগে ক্যাপচার করে৷
• journalctl কমান্ড আপনাকে বুট সেশন, টাইম রেঞ্জ, সিস্টেমড ইউনিট, প্রসেস আইডি, ইউজার আইডি, গ্রুপ আইডি এবং আরও অনেক কিছুর মাধ্যমে লগ ফিল্টার করতে দেয়, যার ফলে প্রাসঙ্গিক ইভেন্টগুলি চিহ্নিত করা সহজ হয়৷
• আপনি --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 দ্বারা পরিচালিত হয় প্রক্রিয়া, লগ সংগ্রহ করা এবং অ্যাক্সেস করার পদ্ধতিকে প্রমিত করা বোধগম্য। journald ডেমন সমস্ত উপলব্ধ উত্স থেকে ডেটা সংগ্রহ করে এবং সহজ এবং গতিশীল ম্যানিপুলেশনের জন্য একটি বাইনারি বিন্যাসে সংরক্ষণ করে৷

এটি আমাদের বেশ কয়েকটি উল্লেখযোগ্য সুবিধা দেয়। একটি একক ইউটিলিটি ব্যবহার করে ডেটার সাথে ইন্টারঅ্যাক্ট করে, অ্যাডমিনিস্ট্রেটররা তাদের প্রয়োজন অনুযায়ী গতিশীলভাবে লগ ডেটা প্রদর্শন করতে সক্ষম হয়। এটি তিনটি বুট আগের বুট ডেটা দেখার মতো সহজ হতে পারে, অথবা যোগাযোগের সমস্যা ডিবাগ করতে দুটি সম্পর্কিত পরিষেবা থেকে ক্রমিকভাবে লগ এন্ট্রিগুলিকে একত্রিত করে৷

একটি বাইনারি বিন্যাসে লগ ডেটা সঞ্চয় করার মানে হল যে এই মুহূর্তে আপনার যা প্রয়োজন তার উপর নির্ভর করে ডেটা নির্বিচারে আউটপুট ফর্ম্যাটে প্রদর্শিত হতে পারে। উদাহরণস্বরূপ, দৈনিক লগ পরিচালনার জন্য আপনি স্ট্যান্ডার্ড syslog লগগুলি দেখতে অভ্যস্ত হতে পারেন বিন্যাস, কিন্তু আপনি যদি পরে গ্রাফ পরিষেবা বাধার সিদ্ধান্ত নেন, তাহলে আপনি প্রতিটি এন্ট্রিকে একটি JSON অবজেক্ট হিসাবে আউটপুট করতে পারেন যাতে এটি আপনার গ্রাফিং পরিষেবাতে ব্যবহারযোগ্য হয়। যেহেতু ডেটা প্লেইন টেক্সটে ডিস্কে লেখা হয় না, তাই যখন আপনার আলাদা অন-ডিমান্ড ফর্ম্যাটের প্রয়োজন হয় তখন কোনো রূপান্তরের প্রয়োজন হয় না।

systemd জার্নাল হয় একটি বিদ্যমান syslog এর সাথে ব্যবহার করা যেতে পারে বাস্তবায়ন, অথবা এটি syslog প্রতিস্থাপন করতে পারে কার্যকারিতা, আপনার প্রয়োজনের উপর নির্ভর করে। যখন systemd জার্নাল বেশিরভাগ প্রশাসকের লগিং প্রয়োজনীয়তাগুলি কভার করবে, এটি বিদ্যমান লগিং প্রক্রিয়াগুলিকেও পরিপূরক করতে পারে। উদাহরণস্বরূপ, আপনার একটি কেন্দ্রীভূত syslog থাকতে পারে যে সার্ভারটি আপনি একাধিক সার্ভার থেকে ডেটা কম্পাইল করার জন্য ব্যবহার করেন, তবে আপনি systemd এর সাথে একটি একক সিস্টেমে একাধিক পরিষেবার লগগুলিকে ইন্টারলিভ করতে চাইতে পারেন জার্নাল আপনি এই প্রযুক্তিগুলিকে একত্রিত করে এই দুটিই করতে পারেন৷

timedatectl দিয়ে কীভাবে সঠিক সিস্টেম সময় সেট করবেন

লগিংয়ের জন্য একটি বাইনারি জার্নাল ব্যবহার করার সুবিধাগুলির মধ্যে একটি হল ইউটিসি বা স্থানীয় সময় ইচ্ছামত লগ রেকর্ড দেখার ক্ষমতা। ডিফল্টরূপে, systemd স্থানীয় সময়ে ফলাফল প্রদর্শন করবে৷

এই কারণে, আমরা জার্নাল শুরু করার আগে, আমরা নিশ্চিত করব যে টাইমজোনটি সঠিকভাবে সেট আপ করা হয়েছে। systemd স্যুট আসলে timedatectl নামে একটি টুলের সাথে আসে যে এটিতে সাহায্য করতে পারে৷

প্রথমে দেখুন list-timezones এর সাথে কোন টাইমজোন পাওয়া যায় বিকল্প:

এটি আপনার সিস্টেমে উপলব্ধ টাইমজোনগুলির তালিকা করবে। যখন আপনি আপনার সার্ভারের অবস্থানের সাথে মেলে এমন একটি খুঁজে পান, আপনি set-timezone ব্যবহার করে এটি সেট করতে পারেন বিকল্প:

আপনার মেশিন এখন সঠিক সময় ব্যবহার করছে তা নিশ্চিত করতে, 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 ব্যবহার করুন আদেশ৷

যখন একা ব্যবহার করা হয়, সিস্টেমে থাকা প্রতিটি জার্নাল এন্ট্রি একটি পেজারের মধ্যে প্রদর্শিত হবে (সাধারণত less ) আপনার ব্রাউজ করার জন্য। প্রাচীনতম এন্ট্রিগুলি উপরে থাকবে:

-- 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 দিয়ে সময় অনুসারে সিস্টেমড লগ ফিল্টার করবেন

যদিও এত বড় তথ্য সংগ্রহে অ্যাক্সেস থাকা অবশ্যই দরকারী, এত বড় পরিমাণ তথ্য ম্যানুয়ালি পরিদর্শন এবং প্রক্রিয়া করা কঠিন বা অসম্ভব হতে পারে। এই কারণে, journalctl এর অন্যতম গুরুত্বপূর্ণ বৈশিষ্ট্য এটির ফিল্টারিং বিকল্প।

বর্তমান বুট সেশন থেকে journalctl দিয়ে লগ দেখান

এর মধ্যে সবচেয়ে মৌলিক যা আপনি প্রতিদিন ব্যবহার করতে পারেন তা হল -b পতাকা এটি আপনাকে সব জার্নাল এন্ট্রি দেখাবে যা সাম্প্রতিক রিবুট থেকে সংগ্রহ করা হয়েছে৷

এটি আপনাকে আপনার বর্তমান পরিবেশের সাথে প্রাসঙ্গিক তথ্য সনাক্ত করতে এবং পরিচালনা করতে সহায়তা করবে৷

যে ক্ষেত্রে আপনি এই বৈশিষ্ট্যটি ব্যবহার করছেন না এবং এক দিনের বেশি বুট প্রদর্শন করছেন, আপনি দেখতে পাবেন যে journalctl একটি লাইন সন্নিবেশ করা হয়েছে যা এইরকম দেখায় যখনই সিস্টেমটি ডাউন হয়:

. . .
-- Reboot --
. . .

এটি আপনাকে যুক্তিযুক্তভাবে বুট সেশনে তথ্য আলাদা করতে সাহায্য করতে ব্যবহার করা যেতে পারে।

journalctl ব্যবহার করে আগের বুটগুলি থেকে লগগুলি কীভাবে অ্যাক্সেস করবেন

যদিও আপনি সাধারণত বর্তমান বুট থেকে তথ্য প্রদর্শন করতে চান, এমন কিছু সময় আছে যখন অতীতের বুটগুলিও সহায়ক হবে। জার্নাল অনেক আগের বুট থেকে তথ্য সংরক্ষণ করতে পারে, তাই journalctl সহজে তথ্য প্রদর্শন করার জন্য তৈরি করা যেতে পারে।

কিছু ডিস্ট্রিবিউশন ডিফল্টরূপে পূর্ববর্তী বুট তথ্য সংরক্ষণ করতে সক্ষম করে, অন্যরা এই বৈশিষ্ট্যটি নিষ্ক্রিয় করে। অবিরাম বুট তথ্য সক্ষম করতে, আপনি টাইপ করে জার্নাল সংরক্ষণ করার জন্য ডিরেক্টরি তৈরি করতে পারেন:

অথবা আপনি জার্নাল কনফিগারেশন ফাইল সম্পাদনা করতে পারেন:

[Journal] এর অধীনে বিভাগে, Storage= সেট করুন ক্রমাগত লগিং সক্ষম করার জন্য "স্থির" বিকল্প:

/etc/systemd/journald.conf

. . .
[Journal]
Storage=persistent

আপনার সার্ভারে পূর্ববর্তী বুটগুলি সংরক্ষণ করার সময়, journalctl বিভাজনের একক হিসাবে বুট দিয়ে কাজ করতে সাহায্য করার জন্য কিছু কমান্ড প্রদান করে। বুট দেখতে যে journald সম্পর্কে জানেন, --list-boots ব্যবহার করুন journalctl সহ বিকল্প :

-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 এর সাথে আপেক্ষিক পয়েন্টার পতাকা:

আপনি বুট থেকে ডেটা কল ব্যাক করতে বুট আইডি ব্যবহার করতে পারেন:

কাস্টম তারিখ এবং সময় সীমা অনুসারে জার্নালসিটিএল লগ ফিল্টার করুন

যদিও বুট দ্বারা লগ এন্ট্রি দেখা অবিশ্বাস্যভাবে দরকারী, আপনি প্রায়ই এমন সময়ের উইন্ডোগুলির অনুরোধ করতে চাইতে পারেন যা সিস্টেম বুটের সাথে ভালভাবে সারিবদ্ধ নয়। উল্লেখযোগ্য আপটাইম সহ দীর্ঘ-চলমান সার্ভারগুলির সাথে ডিল করার সময় এটি বিশেষত সত্য হতে পারে৷

আপনি --since ব্যবহার করে নির্বিচারে সময় সীমা দ্বারা ফিল্টার করতে পারেন এবং --until বিকল্পগুলি, যা যথাক্রমে প্রদত্ত সময়ের পরে বা আগে প্রদর্শিত এন্ট্রিগুলিকে সীমাবদ্ধ করে৷

সময়ের মান বিভিন্ন ফরম্যাটে আসতে পারে। পরম সময়ের মানগুলির জন্য, আপনার নিম্নলিখিত বিন্যাসটি ব্যবহার করা উচিত:

উদাহরণস্বরূপ, আমরা 10শে জানুয়ারী, 2015 বিকাল 5:15 এ টাইপ করে সমস্ত এন্ট্রি দেখতে পারি:

যদি উপরের বিন্যাসের উপাদানগুলি ছেড়ে দেওয়া হয় তবে কিছু ডিফল্ট প্রয়োগ করা হবে। উদাহরণস্বরূপ, যদি তারিখটি বাদ দেওয়া হয়, তাহলে বর্তমান তারিখটি ধরে নেওয়া হবে। যদি সময়ের উপাদানটি অনুপস্থিত থাকে, "00:00:00" (মধ্যরাত) প্রতিস্থাপিত হবে। সেকেন্ডের ক্ষেত্রটিকে "00" এ ডিফল্ট হিসাবেও ছেড়ে দেওয়া যেতে পারে:

জার্নাল কিছু আপেক্ষিক মান এবং নামযুক্ত শর্টকাটও বোঝে। উদাহরণস্বরূপ, আপনি "গতকাল", "আজ", "আগামীকাল", বা "এখন" শব্দগুলি ব্যবহার করতে পারেন। আপনি একটি সংখ্যাযুক্ত মানের সাথে "-" বা "+" আগে থেকে বা বাক্য গঠনে "আগে" এর মতো শব্দ ব্যবহার করে আপেক্ষিক সময় করতে পারেন।

গতকাল থেকে ডেটা পেতে, আপনি টাইপ করতে পারেন:

আপনি যদি সকাল 9:00 AM থেকে শুরু করে এবং এক ঘন্টা আগে পর্যন্ত চলতে থাকা পরিষেবার বিঘ্নের রিপোর্ট পান তবে আপনি টাইপ করতে পারেন:

আপনি দেখতে পাচ্ছেন, আপনি যে এন্ট্রিগুলি দেখতে চান সেগুলি ফিল্টার করার জন্য সময়ের নমনীয় উইন্ডোগুলি সংজ্ঞায়িত করা তুলনামূলকভাবে সহজ৷

পরিষেবা, পিআইডি, বা ব্যবহারকারী দ্বারা সিস্টেমড জার্নাল লগগুলি কীভাবে ফিল্টার করবেন

উপরে, আমরা কিছু উপায় শিখেছি যে আপনি সময় সীমাবদ্ধতা ব্যবহার করে জার্নাল ডেটা ফিল্টার করতে পারেন। এই বিভাগে আমরা আলোচনা করব যে আপনি কোন পরিষেবা বা উপাদানে আগ্রহী তার উপর ভিত্তি করে কীভাবে ফিল্টার করবেন৷ systemd জার্নাল এটি করার বিভিন্ন উপায় প্রদান করে।

সিস্টেমড সার্ভিস ইউনিট দ্বারা লগ দেখুন

সম্ভবত ফিল্টার করার সবচেয়ে কার্যকর উপায় হল আপনি যে ইউনিটে আগ্রহী। আমরা -u ব্যবহার করতে পারি। এইভাবে ফিল্টার করার বিকল্প।

উদাহরণস্বরূপ, আমাদের সিস্টেমে একটি Nginx ইউনিট থেকে সমস্ত লগ দেখতে, আমরা টাইপ করতে পারি:

সাধারণত, আপনার আগ্রহের লাইনগুলি প্রদর্শন করার জন্য আপনি সম্ভবত সময়ের সাথে সাথে ফিল্টার করতে চান৷ উদাহরণস্বরূপ, পরিষেবাটি আজ কীভাবে চলছে তা পরীক্ষা করতে, আপনি টাইপ করতে পারেন:

এই ধরনের ফোকাস অত্যন্ত সহায়ক হয়ে ওঠে যখন আপনি জার্নালের বিভিন্ন ইউনিট থেকে রেকর্ড ইন্টারলিভ করার ক্ষমতার সুবিধা গ্রহণ করেন। উদাহরণস্বরূপ, যদি আপনার Nginx প্রক্রিয়াটি গতিশীল বিষয়বস্তু প্রক্রিয়া করার জন্য একটি PHP-FPM ইউনিটের সাথে সংযুক্ত থাকে, তাহলে আপনি উভয় ইউনিট নির্দিষ্ট করে কালানুক্রমিক ক্রমে উভয়ের এন্ট্রিগুলিকে একত্রিত করতে পারেন:

এটি পৃথক প্রক্রিয়ার পরিবর্তে বিভিন্ন প্রোগ্রাম এবং ডিবাগ সিস্টেমের মধ্যে মিথস্ক্রিয়া সনাক্ত করা আরও সহজ করে তুলতে পারে।

পিআইডি, ইউআইডি, বা জিআইডি দ্বারা সিস্টেমড লগ ফিল্টার করুন

কিছু পরিষেবা কাজ করার জন্য বিভিন্ন শিশু প্রক্রিয়ার জন্ম দেয়। আপনি যদি আগ্রহী সেই প্রক্রিয়াটির সঠিক পিআইডি খুঁজে বের করে থাকেন, তাহলে আপনি সেটি দ্বারাও ফিল্টার করতে পারেন।

এটি করার জন্য আমরা _PID নির্দিষ্ট করে ফিল্টার করতে পারি ক্ষেত্র উদাহরণস্বরূপ, যদি আমরা আগ্রহী PID 8088 হয়, আমরা টাইপ করতে পারি:

অন্য সময়ে, আপনি একটি নির্দিষ্ট ব্যবহারকারী বা গ্রুপ থেকে লগ করা সমস্ত এন্ট্রি দেখাতে চাইতে পারেন। এটি _UID দিয়ে করা যেতে পারে অথবা _GID ফিল্টার উদাহরণস্বরূপ, যদি আপনার ওয়েব সার্ভার www-data এর অধীনে চলে ব্যবহারকারী, আপনি টাইপ করে ব্যবহারকারী আইডি খুঁজে পেতে পারেন:

33

পরে, আপনি জার্নাল ফলাফল ফিল্টার করার জন্য ফেরত দেওয়া আইডি ব্যবহার করতে পারেন:

systemd জার্নালের অনেকগুলি ক্ষেত্র রয়েছে যা ফিল্টারিংয়ের জন্য ব্যবহার করা যেতে পারে। এর মধ্যে কিছু লগ করা প্রক্রিয়া থেকে পাস করা হয় এবং কিছু journald দ্বারা প্রয়োগ করা হয় লগের সময় সিস্টেম থেকে সংগ্রহ করা তথ্য ব্যবহার করে।

অগ্রণী আন্ডারস্কোর নির্দেশ করে যে _PID ক্ষেত্রটি পরবর্তী প্রকারের। জার্নাল স্বয়ংক্রিয়ভাবে রেকর্ড করে এবং পরবর্তী ফিল্টারিংয়ের জন্য লগিং করা প্রক্রিয়াটির PID সূচী করে। আপনি টাইপ করে সমস্ত উপলব্ধ জার্নাল ক্ষেত্র সম্পর্কে জানতে পারেন:

আমরা এই গাইডে এর মধ্যে কয়েকটি নিয়ে আলোচনা করব। যদিও আপাতত, আমরা এই ক্ষেত্রগুলি দ্বারা ফিল্টার করার সাথে আরও একটি দরকারী বিকল্পের উপরে যাব। -F একটি প্রদত্ত জার্নাল ক্ষেত্রের জন্য উপলব্ধ সমস্ত মান প্রদর্শন করতে বিকল্পটি ব্যবহার করা যেতে পারে৷

উদাহরণস্বরূপ, কোন গ্রুপ আইডি systemd দেখতে জার্নালে এন্ট্রি আছে, আপনি টাইপ করতে পারেন:

32
99
102
133
81
84
100
0
124
87

এটি আপনাকে জার্নাল গ্রুপ আইডি ক্ষেত্রের জন্য সংরক্ষণ করা সমস্ত মান দেখাবে। এটি আপনাকে আপনার ফিল্টার তৈরি করতে সাহায্য করতে পারে৷

এক্সিকিউটেবল পাথ দ্বারা লগ দেখুন

আমরা একটি পথ অবস্থান প্রদান করে ফিল্টার করতে পারি।

যদি পথটি এক্সিকিউটেবলের দিকে নিয়ে যায়, journalctl প্রশ্নে এক্সিকিউটেবল জড়িত সমস্ত এন্ট্রি প্রদর্শন করবে। উদাহরণস্বরূপ, bash জড়িত সেই এন্ট্রিগুলি খুঁজে বের করতে৷ এক্সিকিউটেবল, আপনি টাইপ করতে পারেন:

সাধারণত, যদি এক্সিকিউটেবলের জন্য একটি ইউনিট উপলব্ধ থাকে, তবে সেই পদ্ধতিটি পরিষ্কার এবং আরও ভাল তথ্য প্রদান করে (সংশ্লিষ্ট শিশু প্রক্রিয়াগুলি থেকে এন্ট্রি ইত্যাদি)। কখনও কখনও, তবে, এটি সম্ভব হয় না৷

কিভাবে journalctl -k ব্যবহার করে কার্নেল লগ দেখতে হয়

কার্নেল বার্তা, যেগুলি সাধারণত dmesg এ পাওয়া যায় আউটপুট, জার্নাল থেকেও পুনরুদ্ধার করা যেতে পারে।

শুধুমাত্র এই বার্তাগুলি প্রদর্শন করতে, আমরা -k যোগ করতে পারি অথবা --dmesg আমাদের কমান্ডের পতাকা:

ডিফল্টরূপে, এটি বর্তমান বুট থেকে কার্নেল বার্তা প্রদর্শন করবে। আপনি পূর্বে আলোচনা করা সাধারণ বুট নির্বাচন পতাকা ব্যবহার করে একটি বিকল্প বুট নির্দিষ্ট করতে পারেন। উদাহরণস্বরূপ, পাঁচটি বুট আগে থেকে বার্তা পেতে, আপনি টাইপ করতে পারেন:

journalctl -p দিয়ে সিভিরিটি লেভেল অনুযায়ী লগ ফিল্টার করুন

একটি ফিল্টার যা সিস্টেম অ্যাডমিনিস্ট্রেটররা প্রায়শই আগ্রহী থাকে তা হল বার্তা অগ্রাধিকার। যদিও এটি প্রায়শই একটি খুব ভার্বোস স্তরে তথ্য লগ করার জন্য দরকারী, যখন প্রকৃতপক্ষে উপলব্ধ তথ্য হজম করা হয়, কম অগ্রাধিকার লগগুলি বিভ্রান্তিকর এবং বিভ্রান্তিকর হতে পারে৷

আপনি journalctl ব্যবহার করতে পারেন -p ব্যবহার করে শুধুমাত্র একটি নির্দিষ্ট অগ্রাধিকার বা তার উপরে বার্তা প্রদর্শন করতে বিকল্প এটি আপনাকে নিম্ন অগ্রাধিকার বার্তাগুলিকে ফিল্টার করতে দেয়৷

উদাহরণস্বরূপ, ত্রুটি স্তরে বা উপরে লগ করা এন্ট্রিগুলি দেখানোর জন্য, আপনি টাইপ করতে পারেন:

এটি আপনাকে ত্রুটি, সমালোচনামূলক, সতর্কতা বা জরুরি হিসাবে চিহ্নিত সমস্ত বার্তা দেখাবে। জার্নাল স্ট্যান্ডার্ড syslog প্রয়োগ করে বার্তা স্তর। আপনি হয় অগ্রাধিকার নাম বা এর সংশ্লিষ্ট সংখ্যাসূচক মান ব্যবহার করতে পারেন। সর্বোচ্চ থেকে সর্বনিম্ন অগ্রাধিকারের ক্রমে, এগুলি হল:

• 0 :emerg
• 1 :সতর্কতা
• 2 :সমালোচনা
• 3 :ভুল
• 4 :সতর্কতা
• 5 :বিজ্ঞপ্তি
• 6 :তথ্য
• 7 :ডিবাগ

উপরের সংখ্যা বা নামগুলিকে -p এর সাথে বিনিময়যোগ্যভাবে ব্যবহার করা যেতে পারে বিকল্প একটি অগ্রাধিকার নির্বাচন করা নির্দিষ্ট স্তরে চিহ্নিত বার্তাগুলি এবং এটির উপরে বার্তাগুলি প্রদর্শন করবে৷

কাস্টমাইজ করুন journalctl লগ আউটপুট প্রদর্শন

উপরে, আমরা ফিল্টারিংয়ের মাধ্যমে এন্ট্রি নির্বাচন প্রদর্শন করেছি। যদিও আমরা আউটপুট পরিবর্তন করতে পারি অন্য উপায় আছে. আমরা journalctl সামঞ্জস্য করতে পারি বিভিন্ন প্রয়োজনের সাথে মানানসই প্রদর্শন।

কিভাবে journalctl এ আউটপুট দৈর্ঘ্য এবং বিন্যাস নিয়ন্ত্রণ করতে হয়

আমরা কিভাবে journalctl সমন্বয় করতে পারি আউটপুট সঙ্কুচিত বা প্রসারিত করতে বলে ডেটা প্রদর্শন করে।

ডিফল্টরূপে, 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 এ পেজার নিষ্ক্রিয় করবেন আউটপুট

ডিফল্টরূপে, journalctl সহজ খরচের জন্য একটি পেজারে আউটপুট প্রদর্শন করে। আপনি যদি টেক্সট ম্যানিপুলেশন টুলস দিয়ে ডেটা প্রসেস করার পরিকল্পনা করছেন, তবে, আপনি সম্ভবত স্ট্যান্ডার্ড আউটপুটে আউটপুট করতে সক্ষম হতে চান।

আপনি --no-pager দিয়ে এটি করতে পারেন বিকল্প:

এটি অবিলম্বে একটি প্রক্রিয়াকরণ ইউটিলিটিতে পাইপ করা যেতে পারে বা আপনার প্রয়োজনের উপর নির্ভর করে ডিস্কের একটি ফাইলে পুনঃনির্দেশিত করা যেতে পারে৷

journalctl-এ বিভিন্ন আউটপুট ফরম্যাট

আপনি যদি জার্নাল এন্ট্রিগুলি প্রক্রিয়াকরণ করেন, যেমন উপরে উল্লিখিত হয়েছে, আপনার কাছে সম্ভবত ডেটা পার্স করা আরও সহজ হবে যদি এটি আরও বেশি ব্যবহারযোগ্য বিন্যাসে হয়। সৌভাগ্যবশত, প্রয়োজন অনুযায়ী জার্নালটি বিভিন্ন ফরম্যাটে প্রদর্শিত হতে পারে। আপনি -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 ভোক্তার কাছে পাঠানোর আগে ডেটা স্ট্রাকচারের উপর একটি ভাল হ্যান্ডেল পেতে ফর্ম্যাট করুন:

{
 "__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 :প্রতি লাইনে একটি এন্ট্রি সহ স্ট্যান্ডার্ড JSON।
• json-pretty :ভালো মানুষের-পাঠযোগ্যতার জন্য JSON ফর্ম্যাট করা হয়েছে
• json-sse :JSON ফর্ম্যাট করা আউটপুট অ্যাড সার্ভার-প্রেরিত ইভেন্টকে সামঞ্জস্যপূর্ণ করতে মোড়ানো হয়
• ছোট :ডিফল্ট syslog শৈলী আউটপুট
• short-iso :ISO 8601 ওয়ালক্লক টাইমস্ট্যাম্প দেখানোর জন্য ডিফল্ট বিন্যাস পরিবর্ধিত।
• শর্ট-একঘেয়ে :একঘেয়ে টাইমস্ট্যাম্প সহ ডিফল্ট বিন্যাস।
• সংক্ষিপ্ত-সুনির্দিষ্ট :মাইক্রোসেকেন্ড নির্ভুলতা সহ ডিফল্ট বিন্যাস
• ভার্বোস :প্রবেশের জন্য উপলব্ধ প্রতিটি জার্নাল ক্ষেত্র দেখায়, যা সাধারণত অভ্যন্তরীণভাবে লুকানো থাকে।

এই বিকল্পগুলি আপনাকে জার্নাল এন্ট্রিগুলি আপনার বর্তমান প্রয়োজনের জন্য সবচেয়ে উপযুক্ত যে বিন্যাসে প্রদর্শন করতে দেয়৷

journalctl দিয়ে লাইভ সিস্টেমড লগ মনিটর করুন

journalctl কমান্ড অনুকরণ করে কতজন প্রশাসক tail ব্যবহার করেন সক্রিয় বা সাম্প্রতিক কার্যকলাপ নিরীক্ষণের জন্য। এই কার্যকারিতা journalctl-এ তৈরি করা হয়েছে , অন্য টুলে পাইপ না করেই আপনাকে এই বৈশিষ্ট্যগুলি অ্যাক্সেস করার অনুমতি দেয়৷

journalctl -n সহ সাম্প্রতিক লগ এন্ট্রিগুলি দেখান৷

রেকর্ডের একটি নির্দিষ্ট পরিমাণ প্রদর্শন করতে, আপনি -n ব্যবহার করতে পারেন বিকল্প, যা ঠিক tail -n হিসাবে কাজ করে .

ডিফল্টরূপে, এটি সাম্প্রতিকতম 10টি এন্ট্রি প্রদর্শন করবে:

আপনি -n-এর পরে একটি নম্বর সহ আপনি কতগুলি এন্ট্রি দেখতে চান তা নির্দিষ্ট করতে পারেন :

journalctl -f দিয়ে রিয়েল-টাইম লগগুলি অনুসরণ করুন

লগগুলিকে সক্রিয়ভাবে অনুসরণ করতে যেমন সেগুলি লেখা হচ্ছে, আপনি -f ব্যবহার করতে পারেন পতাকা আবার, আপনার যদি tail -f ব্যবহার করার অভিজ্ঞতা থাকে তবে এটি আপনার প্রত্যাশা অনুযায়ী কাজ করে :

এই কমান্ড থেকে প্রস্থান করতে, CTRL+C টাইপ করুন .

কিভাবে সিস্টেমড জার্নাল লগগুলি পরিচালনা এবং পরিষ্কার করবেন

আপনি হয়তো ভাবছেন যে আমরা এখন পর্যন্ত যতগুলি ডেটা দেখেছি তার সমস্ত সংরক্ষণের খরচ। উপরন্তু, আপনি কিছু পুরানো লগ পরিষ্কার করতে এবং স্থান খালি করতে আগ্রহী হতে পারেন৷

journalctl --disk-usage দিয়ে সিস্টেমড লগের ডিস্ক ব্যবহার পরীক্ষা করুন

আপনি --disk-usage ব্যবহার করে জার্নালটি বর্তমানে ডিস্কে যে পরিমাণ স্থান দখল করছে তা খুঁজে বের করতে পারেন পতাকা:

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

journalctl --vacuum-size দিয়ে পুরানো লগ মুছুন এবং --vacuum-time

আপনি যদি আপনার জার্নাল সঙ্কুচিত করতে চান তবে আপনি এটি দুটি ভিন্ন উপায়ে করতে পারেন (systemd এর সাথে উপলব্ধ সংস্করণ 218 এবং পরবর্তী)।

আপনি যদি --vacuum-size ব্যবহার করেন বিকল্প, আপনি একটি আকার নির্দেশ করে আপনার জার্নাল সঙ্কুচিত করতে পারেন। ডিস্কে নেওয়া মোট জার্নাল স্পেস অনুরোধকৃত আকারে না হওয়া পর্যন্ত এটি পুরানো এন্ট্রিগুলিকে সরিয়ে দেবে:

জার্নালটি সঙ্কুচিত করার আরেকটি উপায় হল --vacuum-time এর সাথে একটি কাটঅফ সময় প্রদান করা বিকল্প যে সময়ের বাইরে কোনো এন্ট্রি মুছে ফেলা হয়. এটি আপনাকে একটি নির্দিষ্ট সময়ের পরে তৈরি করা এন্ট্রিগুলিকে রাখতে দেয়৷

উদাহরণস্বরূপ, গত বছরের এন্ট্রি রাখতে, আপনি টাইপ করতে পারেন:

জার্নাল্ড লগের জন্য ডিস্ক স্পেস সীমা কনফিগার করুন

জার্নাল কতটা জায়গা নিতে পারে তার সীমাবদ্ধতা রাখতে আপনি আপনার সার্ভার কনফিগার করতে পারেন। এটি /etc/systemd/journald.conf সম্পাদনা করে করা যেতে পারে ফাইল।

জার্নাল বৃদ্ধি সীমিত করতে নিম্নলিখিত আইটেমগুলি ব্যবহার করা যেতে পারে:

• SystemMaxUse= :জার্নাল দ্বারা স্থায়ী সঞ্চয়স্থানে ব্যবহার করা যেতে পারে এমন সর্বোচ্চ ডিস্ক স্থান নির্দিষ্ট করে৷
• SystemKeepFree= :স্থায়ী সঞ্চয়স্থানে জার্নাল এন্ট্রি যুক্ত করার সময় জার্নালটি যে পরিমাণ স্থান খালি ছেড়ে দেবে তা নির্দিষ্ট করে৷
• SystemMaxFileSize= :ঘোরানোর আগে স্থির সঞ্চয়স্থানে কত বড় পৃথক জার্নাল ফাইলগুলি বাড়তে পারে তা নিয়ন্ত্রণ করে৷
• RuntimeMaxUse= :ডিস্কের সর্বাধিক স্থান নির্দিষ্ট করে যা উদ্বায়ী সঞ্চয়স্থানে ব্যবহার করা যেতে পারে (/run এর মধ্যে ফাইল সিস্টেম)।
• RuntimeKeepFree= :উদ্বায়ী সঞ্চয়স্থানে ডেটা লেখার সময় অন্যান্য ব্যবহারের জন্য আলাদা করে রাখা স্থানের পরিমাণ নির্দিষ্ট করে (/run এর মধ্যে ফাইল সিস্টেম)।
• RuntimeMaxFileSize= :একটি পৃথক জার্নাল ফাইল উদ্বায়ী সঞ্চয়স্থানে (/run-এর মধ্যে) স্থানের পরিমাণ নির্দিষ্ট করে ফাইল সিস্টেম) ঘোরানোর আগে।

এই মানগুলি সেট করে, আপনি কিভাবে journald নিয়ন্ত্রণ করতে পারেন আপনার সার্ভারে স্থান গ্রহণ করে এবং সংরক্ষণ করে। মনে রাখবেন যে SystemMaxFileSize এবং RuntimeMaxFileSize উল্লেখিত সীমাতে পৌঁছানোর জন্য সংরক্ষণাগারভুক্ত ফাইলগুলিকে লক্ষ্য করবে৷ ভ্যাকুয়ামিং অপারেশনের পরে ফাইল গণনা ব্যাখ্যা করার সময় এটি মনে রাখা গুরুত্বপূর্ণ।

সাধারণ সমস্যা সমাধান করা journalctl এবং সিস্টেমড জার্নাল ইস্যুস

1. কেন journalctl লগ দেখাচ্ছে না?

কিছু ক্ষেত্রে, আপনি journalctl চালাতে পারেন কমান্ড লগ আউটপুট দেখার আশা করছে, শুধুমাত্র একটি ফাঁকা স্ক্রীন বা কোন অর্থপূর্ণ ফলাফলের সাথে দেখা হবে। এই পরিস্থিতি বিভ্রান্তিকর হতে পারে, বিশেষ করে যদি আপনি একটি সমস্যা সমাধান করছেন বা সাম্প্রতিক সিস্টেম কার্যকলাপ খুঁজছেন। সৌভাগ্যবশত, বেশ কিছু সাধারণ ব্যাখ্যা রয়েছে যা journalctl কেন তা রহস্যময় করতে সাহায্য করে লগ দেখাচ্ছে না।

জার্নাল ডেটাবেস খালি বা অনুপস্থিত

কোন আউটপুট দেখার জন্য সবচেয়ে সহজবোধ্য কারণ হল জার্নালটি খালি। এটি নতুন ইনস্টল করা সিস্টেম, ন্যূনতম ধারক পরিবেশ বা সার্ভারগুলিতে ঘটতে পারে যেখানে সিস্টেম লগিং এখনও কোনও এন্ট্রি তৈরি করেনি। এটিও সম্ভব যে আপনার সিস্টেমটি শুধুমাত্র মেমরিতে লগ সংরক্ষণ করার জন্য কনফিগার করা হয়েছে (অস্থির সঞ্চয়স্থান), যার অর্থ রিবুট করার সময় সমস্ত লগ মুছে ফেলা হয়েছে। ক্রমাগত লগিং সক্ষম কিনা তা পরীক্ষা করতে, আপনি journal এর উপস্থিতি দেখতে পারেন ডিরেক্টরি:

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 দ্বারা ভ্যাকুয়াম করা হয় , তারা আর অ্যাক্সেসযোগ্য হবে না. জার্নালটি বর্তমানে কতটা স্থান ব্যবহার করছে তা আপনি পরিদর্শন করতে পারেন:

journalctl --disk-usage

আপনি যদি আপনার সিস্টেমকে জার্নালের আকার আক্রমনাত্মকভাবে সীমিত করার জন্য কনফিগার করে থাকেন, অথবা আপনি যদি সম্প্রতি ম্যানুয়ালি একটি ভ্যাকুয়াম কমান্ড চালান, তাহলে ডাটাবেস থেকে লগগুলি পরিস্কার করা হতে পারে৷

2. journalctl ব্যবহার করার সময় অনুমতি অস্বীকার করা হয়েছে

আপনি journalctl চালানোর চেষ্টা করলে একজন নিয়মিত ব্যবহারকারী হিসাবে এবং একটি "অনুমতি অস্বীকার" বার্তা পান, আপনি একা নন। ডিফল্টরূপে, সিস্টেম লগগুলিতে অ্যাক্সেস root-এ সীমাবদ্ধ systemd-journal ব্যবহারকারী এবং সদস্যরা দল এই নিষেধাজ্ঞাটি সম্ভাব্য সংবেদনশীল লগ ডেটা রক্ষা করার জন্য ডিজাইন করা হয়েছে, যাতে ব্যবহারকারীর কার্যকলাপ, সিস্টেম প্রক্রিয়া এবং পরিষেবা ব্যর্থতা সম্পর্কে তথ্য থাকতে পারে৷

চলছে journalctl উন্নত বিশেষাধিকার সহ

সবচেয়ে সহজ এবং সবচেয়ে সাধারণ সমাধান হল sudo দিয়ে কমান্ড চালানো . এটি কমান্ডের সময়কালের জন্য আপনার বিশেষাধিকারগুলিকে উন্নত করে এবং আপনাকে সমস্ত সিস্টেম লগ দেখতে দেয়:

sudo journalctl

আপনি যদি স্ক্রিপ্ট করছেন বা ঘন ঘন লগগুলি পরিদর্শন করছেন, sudo টাইপ করুন প্রতিবার ক্লান্তিকর হয়ে উঠতে পারে। এই ধরনের ক্ষেত্রে, আপনার ব্যবহারকারীকে জার্নালে স্থায়ীভাবে অ্যাক্সেস দেওয়া আরও বাস্তবসম্মত হতে পারে।

গ্রুপ মেম্বারশিপের মাধ্যমে আপনার ব্যবহারকারীকে অ্যাক্সেস দেওয়া

sudo প্রয়োজন এড়াতে , আপনি আপনার ব্যবহারকারীকে systemd-journal-এ যোগ করতে পারেন দল এই গ্রুপটি বিশেষভাবে অ-রুট ব্যবহারকারীদের জার্নাল লগ পড়ার অনুমতি দেওয়ার জন্য ডিজাইন করা হয়েছে। আপনি নিম্নলিখিত কমান্ডের মাধ্যমে আপনার ব্যবহারকারীকে গ্রুপে যুক্ত করতে পারেন:

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

এই অনুমতিগুলির সাথে এবং সঠিক গোষ্ঠী সদস্যতার সাথে, নন-রুট ব্যবহারকারীরা নিরাপদে লগগুলি অ্যাক্সেস করতে পারে৷

3. লগগুলি রিবুট করার পরে স্থায়ী হয় না

আপনি যদি লক্ষ্য করেন যে প্রতিবার আপনার সার্ভার রিবুট করার সময় লগগুলি অদৃশ্য হয়ে যায়, আপনার সিস্টেম সম্ভবত শুধুমাত্র উদ্বায়ী মেমরিতে লগ সংরক্ষণ করার জন্য কনফিগার করা হয়েছে , যা মেশিন বন্ধ হয়ে গেলে হারিয়ে যায়। এটি অনেক লিনাক্স ডিস্ট্রিবিউশন এবং কন্টেইনার পরিবেশে একটি সাধারণ ডিফল্ট, বিশেষ করে যেগুলি কম ডিস্ক ব্যবহারের জন্য অপ্টিমাইজ করা হয়েছে৷

অস্থায়ী লগিং সক্ষম করা হচ্ছে

রিবুট জুড়ে লগগুলি ধরে রাখতে, আপনাকে স্থায়ী স্টোরেজ ব্যবহার করতে জার্নাল্ড কনফিগার করতে হবে। এর জন্য উপযুক্ত ডিরেক্টরি তৈরি করা প্রয়োজন যেখানে জার্নালটি ডিস্কে লগ লিখতে পারে। পথ /var/log/journal এই উদ্দেশ্যে ব্যবহার করা হয়। যদি এটি বিদ্যমান না থাকে, এটি তৈরি করুন এবং লগিং ডেমন পুনরায় চালু করুন:

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

এটি সম্পন্ন হওয়ার পরে, সমস্ত ভবিষ্যতের লগগুলি ডিস্কে লেখা হবে এবং সিস্টেম রিবুট বেঁচে থাকবে৷

জার্নাল্ড কনফিগারেশন যাচাই করা হচ্ছে

যদি ডিরেক্টরিটি বিদ্যমান থাকে কিন্তু লগগুলি এখনও টিকে না থাকে, তাহলে journald পরিদর্শন করা মূল্যবান কনফিগারেশন ফাইল:

sudo nano /etc/systemd/journald.conf

এই ফাইলে, Storage= খুঁজুন [Journal]-এর অধীনে নির্দেশিকা বিভাগ যদি এটি volatile সেট করা থাকে , এটিকে persistent এ পরিবর্তন করুন :

[Journal]
Storage=persistent

ফাইলটি সংরক্ষণ করুন এবং পরিবর্তনগুলি প্রয়োগ করতে পরিষেবাটি পুনরায় চালু করুন। এটি নিশ্চিত করে যে সিস্টেম এখন থেকে RAM এর পরিবর্তে ডিস্কে লগ লিখবে৷

4. একটি ব্যর্থ সিস্টেমড পরিষেবা ডিবাগ করা

যখন একটি সিস্টেম-পরিচালিত পরিষেবা শুরু হতে ব্যর্থ হয় বা অপ্রত্যাশিতভাবে ক্র্যাশ হয়, journalctl মূল কারণ চিহ্নিত করার জন্য একটি অপরিহার্য হাতিয়ার হয়ে ওঠে। Instead of searching through multiple log files, the journal collects all messages related to a service in one place, complete with metadata, timestamps, and priority levels.

Reviewing the Service Status

The first step when troubleshooting is to examine the service status. The systemctl status command provides a snapshot of the service’s current state, including the most recent log entries. যেমন:

systemctl status nginx.service

This output often reveals immediate issues such as misconfigured paths, permission problems, or exit codes. The exit code and signal information, if present, can be especially helpful for determining whether the service failed on its own or was killed by the system.

Viewing the Full Log History

To see all logs related to the failed service, use journalctl with the -u flag:

journalctl -u nginx.service

This provides a chronological view of messages generated by the service. If you’re trying to diagnose a failure that happened during the last system boot, it’s helpful to limit the output to just that session:

journalctl -u nginx.service -b

Investigating Failure Context

You can often get to the heart of the issue by reading the log entries from a few minutes before and after the failure. Use time-based filters to narrow your focus:

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

This can help identify whether the problem was isolated or part of a larger system issue.

For deeper analysis, you can enable verbose output or view extended error messages using:

journalctl -xe

This command highlights priority messages and recent failures, which can be useful when a service doesn’t leave obvious clues in the standard output.

5. Monitoring SSH Login Attempts

SSH is a primary access method for most Linux servers, which also makes it a common vector for brute-force attacks, unauthorized access attempts, or general auditing. Fortunately, journalctl allows you to monitor all SSH-related activity with ease.

Viewing SSH Logs

Systemd tracks SSH activity under the sshd or ssh unit, depending on your distribution. To see all entries related to SSH:

journalctl -u ssh.service

or, on some systems:

journalctl -u sshd.service

These logs include login attempts, authentication failures, session closures, and key negotiation messages. It’s an excellent first step when verifying who accessed the server and when.

Following SSH Activity in Real Time

For real-time monitoring, you can use journalctl in follow mode. This is especially useful if you suspect an intrusion or want to keep an eye on active login attempts:

journalctl -f -u ssh.service

Each new login event will be printed live as it happens, making it easier to spot failed logins or rapid connection attempts that may indicate malicious behavior.

Filtering by Login Events

If you’re looking for specific login messages, such as failed passwords or accepted connections, you can filter the journal output using keyword matches:

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

These messages indicate whether a login was successful and which user attempted it. You can combine these with time filters to narrow the search to a specific window:

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

This can be extremely helpful during security audits or forensic investigations.

Frequently Asked Questions (FAQs)

1. Why does journalctl require root access?

By default, journalctl requires root access because it can expose sensitive information collected from system services, kernel messages, user sessions, and background daemons. These logs may include usernames, environment variables, error traces, authentication attempts, and other details that could pose a security risk if accessed by unauthorized users.

To safeguard this data, systemd restricts access to the system journal. However, you don’t always need to use sudo . Non-root users can read logs if they are part of the systemd-journal দল You can add your user to this group with:

sudo usermod -aG systemd-journal yourusername

After logging out and back in, you should be able to access logs without elevated privileges, as long as file permissions on the journal directories are properly configured.

2. How do I make logs persistent across reboots?

To preserve logs after a reboot, you need to configure systemd-journald to use persistent storage rather than volatile memory. By default, some distributions store logs in /run/log/journal , a temporary directory cleared at shutdown. To enable persistent logging:

1. Create the persistent journal directory:

   sudo mkdir -p /var/log/journal
   

2. Set permissions if needed:

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

3. Restart the journal daemon:

   sudo systemctl restart systemd-journald
   

4. Optional:Verify or edit configuration:

   Open /etc/systemd/journald.conf and ensure the following line is set:

   Storage=persistent
   

This configuration ensures your system retains log data across reboots, making it easier to audit and debug historical issues.

3. Can I clear journalctl logs?

Yes, journalctl allows you to clear logs using the --vacuum-* options provided by systemd-journald . These commands help reduce disk usage by deleting old or excess log data.

Here are common methods to clear or shrink journal logs:

• Remove logs older than a specific time:

  sudo journalctl --vacuum-time=2weeks
  

• Limit total disk usage for all logs:

  sudo journalctl --vacuum-size=500M
  

• Restrict the number of journal files kept:

  sudo journalctl --vacuum-files=10
  

These commands do not erase current or recent logs unless they exceed the defined threshold. To fully remove all logs, you can manually delete the journal files from /var/log/journal , but this is rarely necessary and not generally recommended for production systems.

4. How do I access systemd logs?

You can access systemd logs using the journalctl command, which interfaces directly with the systemd journal. All logs related to services managed by systemd, such as boot messages, unit failures, and runtime errors, are stored in the journal.

For general access:

journalctl

To see logs for a specific systemd service, such as nginx , use:

journalctl -u nginx.service

You can also filter by boot session, priority level, time range, or combine multiple services to gain deeper insight. Unlike traditional log files, journalctl provides a unified, indexed view of log messages from multiple sources.

5. Which command is used to view systemd logs?

The primary command used to view systemd logs is:

journalctl

This tool is included with systemd and provides access to all logs collected by the systemd-journald service, including kernel messages, early boot logs, system services, and user sessions.

You can tailor the command with various options:

• View logs for a specific service:

  journalctl -u ssh.service
  

• Filter logs by priority:

  journalctl -p err
  

• Display logs in real time:

  journalctl -f
  

This makes journalctl the most versatile and comprehensive utility for viewing systemd-related logs.

6. How to see kernel logs through journalctl ?

Kernel messages, such as those traditionally viewed using dmesg , are also available through the systemd journal. To display only kernel messages using journalctl , use the -k flag:

journalctl -k

This command filters the output to include only messages originating from the kernel. It is especially useful for diagnosing hardware issues, kernel module problems, or boot-time errors. You can also use the -b option to show messages from the current or previous boot:

journalctl -k -b -1

This gives you consistent access to kernel logs, integrated with logs from other services for better contextual understanding.

7. What is the difference between dmesg and journalctl ?

While both dmesg and journalctl can show kernel logs, they serve different purposes and operate under different mechanisms.

In short, dmesg is limited to low-level kernel logs in real time, while journalctl offers a more complete, structured, and persistent logging interface that encompasses the entire system.

উপসংহার

As you can see, the systemd journal is incredibly useful for collecting and managing your system and application data. Most of the flexibility comes from the extensive metadata automatically recorded and the centralized nature of the log.

In this guide, we covered basic log viewing, time-based and field-based filtering, monitoring kernel and service logs, output formatting, and real-time log tracking. We also discussed journal maintenance, storage limits, and troubleshooting common issues like missing logs or permission errors.

The journalctl command makes it easy to take advantage of the advanced features of the journal and to do extensive analysis and relational debugging of different application components. By mastering journalctl, you gain a versatile, unified logging interface for debugging, monitoring, and auditing across your entire system.

For more detailed insight into logging and troubleshooting on Linux systems, explore the following related tutorials:

• How To Troubleshoot Common Apache Errors
• How To Centralize Logs With Journald on Debian 10
• How To Centralize Logs With Journald on Ubuntu 20.04

এই ক্রিয়েটিভ লাইসেন্সের অধীনে কাজ করে" অ্যাট্রিবিউশন-অবাণিজ্যিক- শেয়ারঅ্যালাইক 4.0 আন্তর্জাতিক লাইসেন্স।