सिस्टमडी लॉग्स में महारत हासिल करना:लिनक्स पर जर्नलसीटीएल का उपयोग करने के लिए एक संपूर्ण गाइड

सिस्टमडी जर्नल और जर्नलसीटीएल लॉगिंग का परिचय

<पी> systemd के कुछ सबसे आकर्षक फायदे वे प्रक्रिया और सिस्टम लॉगिंग से जुड़े हैं। अन्य उपकरणों का उपयोग करते समय, लॉग आमतौर पर पूरे सिस्टम में फैले होते हैं, विभिन्न डेमॉन और प्रक्रियाओं द्वारा नियंत्रित होते हैं, और जब वे कई अनुप्रयोगों में फैले होते हैं तो उनकी व्याख्या करना काफी मुश्किल हो सकता है। systemd सभी कर्नेल और उपयोगकर्तालैंड प्रक्रियाओं को लॉग करने के लिए एक केंद्रीकृत प्रबंधन समाधान प्रदान करके इन मुद्दों का समाधान करने का प्रयास किया गया है। वह सिस्टम जो इन लॉग्स को एकत्रित और प्रबंधित करता है उसे जर्नल के रूप में जाना जाता है .

<पी> जर्नल journald के साथ कार्यान्वित किया गया है डेमॉन, जो कर्नेल, initrd, सेवाओं आदि द्वारा उत्पादित सभी संदेशों को संभालता है। इस गाइड में, हम चर्चा करेंगे कि journalctl का उपयोग कैसे करें उपयोगिता, जिसका उपयोग जर्नल के भीतर रखे गए डेटा तक पहुंचने और हेरफेर करने के लिए किया जा सकता है।

<पी> इस लेख में, आप सीखेंगे कि journalctl का उपयोग कैसे करें सिस्टमड जर्नल से लॉग डेटा तक पहुंचने और फ़िल्टर करने के लिए कमांड-लाइन टूल। हम विशिष्ट बूट या समय सीमा से लॉग देखने, सिस्टम इकाइयों, उपयोगकर्ताओं या प्राथमिकता स्तरों द्वारा फ़िल्टर करने और अन्य उपकरणों के साथ एकीकरण के लिए JSON जैसे प्रारूपों में आउटपुट लॉग को देखने का तरीका कवर करेंगे। आप यह भी सीखेंगे कि वास्तविक समय की घटनाओं की निगरानी कैसे करें, डिस्क उपयोग को कैसे प्रबंधित करें, लगातार लॉगिंग को कॉन्फ़िगर करें और गुम लॉग या अनुमति त्रुटियों जैसे सामान्य मुद्दों को कैसे हल करें। चाहे आप किसी विफल सेवा को डिबग कर रहे हों या केंद्रीकृत लॉग संग्रह स्थापित कर रहे हों, जर्नलक्टल आपके वर्कफ़्लो को सुव्यवस्थित करने के लिए लचीलापन और सटीकता प्रदान करता है।

मुख्य बातें

द 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 बूट और इकाइयों में लॉग एकत्र करके सेवा डिबगिंग को सरल बनाता है, जिससे विफलताओं की पहचान करना, एसएसएच पहुंच को ट्रैक करना और विस्तृत संदर्भ के साथ मुद्दों की जांच करना आसान हो जाता है।

सिस्टमडी जर्नल कैसे काम करता है और यह क्यों मायने रखता है

<पी> systemd के पीछे एक प्रेरणा जर्नल का उद्देश्य लॉग के प्रबंधन को केंद्रीकृत करना है, चाहे संदेश कहीं से भी उत्पन्न हो रहे हों। चूँकि अधिकांश बूट प्रक्रिया और सेवा प्रबंधन systemd द्वारा नियंत्रित किया जाता है प्रक्रिया, लॉग एकत्र करने और उन तक पहुंचने के तरीके को मानकीकृत करना समझ में आता है। journald डेमॉन सभी उपलब्ध स्रोतों से डेटा एकत्र करता है और इसे आसान और गतिशील हेरफेर के लिए बाइनरी प्रारूप में संग्रहीत करता है।

<पी> इससे हमें कई महत्वपूर्ण लाभ मिलते हैं। एकल उपयोगिता का उपयोग करके डेटा के साथ इंटरैक्ट करके, प्रशासक अपनी आवश्यकताओं के अनुसार लॉग डेटा को गतिशील रूप से प्रदर्शित करने में सक्षम होते हैं। यह तीन बूट पहले के बूट डेटा को देखने, या संचार समस्या को डीबग करने के लिए दो संबंधित सेवाओं से क्रमिक रूप से लॉग प्रविष्टियों को संयोजित करने जितना सरल हो सकता है।

<पी> लॉग डेटा को बाइनरी प्रारूप में संग्रहीत करने का अर्थ यह भी है कि डेटा को इस समय आपकी आवश्यकता के आधार पर मनमाने आउटपुट स्वरूपों में प्रदर्शित किया जा सकता है। उदाहरण के लिए, दैनिक लॉग प्रबंधन के लिए आप मानक syslog में लॉग देखने के आदी हो सकते हैं। प्रारूपित करें, लेकिन यदि आप बाद में सेवा रुकावटों को ग्राफ़ करने का निर्णय लेते हैं, तो आप प्रत्येक प्रविष्टि को JSON ऑब्जेक्ट के रूप में आउटपुट कर सकते हैं ताकि इसे आपकी ग्राफ़िंग सेवा में उपभोग्य बनाया जा सके। चूंकि डेटा सादे पाठ में डिस्क पर नहीं लिखा जाता है, इसलिए जब आपको एक अलग ऑन-डिमांड प्रारूप की आवश्यकता होती है तो किसी रूपांतरण की आवश्यकता नहीं होती है।

<पी> systemd जर्नल का उपयोग या तो मौजूदा syslog के साथ किया जा सकता है कार्यान्वयन, या यह syslog को प्रतिस्थापित कर सकता है कार्यक्षमता, आपकी आवश्यकताओं पर निर्भर करती है। जबकि systemd जर्नल अधिकांश व्यवस्थापक की लॉगिंग आवश्यकताओं को कवर करेगा, यह मौजूदा लॉगिंग तंत्र को भी पूरक कर सकता है। उदाहरण के लिए, आपके पास एक केंद्रीकृत syslog हो सकता है वह सर्वर जिसका उपयोग आप कई सर्वरों से डेटा संकलित करने के लिए करते हैं, लेकिन आप systemd के साथ एक ही सिस्टम पर कई सेवाओं के लॉग को इंटरलीव करना भी चाह सकते हैं। पत्रिका. आप इन तकनीकों को मिलाकर ये दोनों काम कर सकते हैं।

`timedatectl` के साथ सही सिस्टम समय कैसे सेट करें

<पी> लॉगिंग के लिए बाइनरी जर्नल का उपयोग करने के लाभों में से एक यूटीसी या इच्छानुसार स्थानीय समय में लॉग रिकॉर्ड देखने की क्षमता है। डिफ़ॉल्ट रूप से, 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 का उपयोग करें आदेश.

<पी> जब अकेले उपयोग किया जाता है, तो सिस्टम में मौजूद प्रत्येक जर्नल प्रविष्टि एक पेजर के भीतर प्रदर्शित की जाएगी (आमतौर पर 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 की तुलना में अधिक स्रोतों से डेटा एकत्र करता है क्रियान्वयन करने में सक्षम हैं। इसमें प्रारंभिक बूट प्रक्रिया, कर्नेल, इनिटर्ड और एप्लिकेशन मानक त्रुटि और आउट से लॉग शामिल हैं। ये सभी जर्नल में उपलब्ध हैं।

<पी> आप देख सकते हैं कि प्रदर्शित किए जा रहे सभी टाइमस्टैम्प स्थानीय समय हैं। यह अब प्रत्येक लॉग प्रविष्टि के लिए उपलब्ध है क्योंकि हमारे सिस्टम पर स्थानीय समय सही ढंग से सेट है। सभी लॉग इस नई जानकारी का उपयोग करके प्रदर्शित किए जाते हैं।

<पी> यदि आप यूटीसी में टाइमस्टैम्प प्रदर्शित करना चाहते हैं, तो आप --utc का उपयोग कर सकते हैं झंडा:

journalctl --utc

`journalctl` के साथ समय के अनुसार सिस्टम लॉग को कैसे फ़िल्टर करें

<पी> हालांकि डेटा के इतने बड़े संग्रह तक पहुंच निश्चित रूप से उपयोगी है, लेकिन इतनी बड़ी मात्रा में जानकारी का मैन्युअल रूप से निरीक्षण और प्रसंस्करण करना मुश्किल या असंभव हो सकता है। इस वजह से, यह journalctl की सबसे महत्वपूर्ण विशेषताओं में से एक है इसके फ़िल्टरिंग विकल्प हैं।

वर्तमान बूट सत्र से `journalctl` के साथ लॉग दिखाएं

<पी> इनमें से सबसे बुनियादी जो आप दैनिक उपयोग कर सकते हैं, वह -b है झंडा. यह आपको वे सभी जर्नल प्रविष्टियाँ दिखाएगा जो नवीनतम रीबूट के बाद से एकत्र की गई हैं।

journalctl -b

<पी> इससे आपको उस जानकारी को पहचानने और प्रबंधित करने में मदद मिलेगी जो आपके वर्तमान परिवेश के लिए प्रासंगिक है।

<पी> ऐसे मामलों में जहां आप इस सुविधा का उपयोग नहीं कर रहे हैं और एक से अधिक दिन के बूट प्रदर्शित कर रहे हैं, आप देखेंगे कि journalctl एक लाइन डाली है जो सिस्टम के डाउन होने पर इस तरह दिखती है:

. . .
-- Reboot --
. . .

<पी> इसका उपयोग बूट सत्रों में जानकारी को तार्किक रूप से अलग करने में आपकी सहायता के लिए किया जा सकता है।

`journalctl` का उपयोग करके पिछले बूट से लॉग तक कैसे पहुंचें

<पी> हालाँकि आप आमतौर पर वर्तमान बूट से जानकारी प्रदर्शित करना चाहेंगे, लेकिन निश्चित रूप से ऐसे समय भी होंगे जब पिछले बूट भी सहायक होंगे। जर्नल पिछले कई बूटों से जानकारी सहेज सकता है, इसलिए journalctl जानकारी को आसानी से प्रदर्शित करने के लिए बनाया जा सकता है।

<पी> कुछ वितरण पिछली बूट जानकारी को डिफ़ॉल्ट रूप से सहेजने में सक्षम करते हैं, जबकि अन्य इस सुविधा को अक्षम करते हैं। लगातार बूट जानकारी को सक्षम करने के लिए, आप या तो टाइप करके जर्नल को संग्रहीत करने के लिए निर्देशिका बना सकते हैं:

sudo mkdir -p /var/log/journal

<पी> या आप जर्नल कॉन्फ़िगरेशन फ़ाइल को संपादित कर सकते हैं:

sudo nano /etc/systemd/journald.conf

<पी> [Journal] के अंतर्गत अनुभाग, Storage= सेट करें लगातार लॉगिंग सक्षम करने के लिए "लगातार" का विकल्प:

<पी> /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

कस्टम दिनांक और समय सीमा के अनुसार जर्नल लॉग फ़िल्टर करें

<पी> हालाँकि बूट द्वारा लॉग प्रविष्टियाँ देखना अविश्वसनीय रूप से उपयोगी है, अक्सर आप समय की उन विंडो का अनुरोध करना चाह सकते हैं जो सिस्टम बूट के साथ अच्छी तरह से संरेखित नहीं होती हैं। महत्वपूर्ण अपटाइम के साथ लंबे समय तक चलने वाले सर्वर से निपटने के दौरान यह विशेष रूप से सच हो सकता है।

<पी> आप --since का उपयोग करके मनमानी समय सीमा के अनुसार फ़िल्टर कर सकते हैं और --until विकल्प, जो क्रमशः दिए गए समय के बाद या उससे पहले प्रदर्शित प्रविष्टियों को प्रतिबंधित करते हैं।

<पी> समय मान विभिन्न स्वरूपों में आ सकते हैं। निरपेक्ष समय मानों के लिए, आपको निम्नलिखित प्रारूप का उपयोग करना चाहिए:

YYYY-MM-DD HH:MM:SS

<पी> उदाहरण के लिए, हम 10 जनवरी 2015 से शाम 5:15 बजे तक की सभी प्रविष्टियाँ टाइप करके देख सकते हैं:

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

<पी> यदि उपरोक्त प्रारूप के घटकों को छोड़ दिया जाता है, तो कुछ डिफ़ॉल्ट लागू हो जाएंगे। उदाहरण के लिए, यदि तारीख छोड़ दी गई है, तो वर्तमान तारीख मान ली जाएगी। यदि समय घटक गायब है, तो "00:00:00" (मध्यरात्रि) को प्रतिस्थापित किया जाएगा। सेकंड फ़ील्ड को डिफ़ॉल्ट रूप से "00" पर छोड़ा जा सकता है:

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

<पी> पत्रिका कुछ सापेक्ष मूल्यों और नामित शॉर्टकटों को भी समझती है। उदाहरण के लिए, आप "कल", "आज", "कल", या "अभी" शब्दों का उपयोग कर सकते हैं। आप क्रमांकित मान में "-" या "+" जोड़कर या वाक्य निर्माण में "पहले" जैसे शब्दों का उपयोग करके सापेक्ष समय कर सकते हैं।

<पी> कल का डेटा प्राप्त करने के लिए, आप टाइप कर सकते हैं:

journalctl --since yesterday

<पी> यदि आपको सेवा में सुबह 9:00 बजे से रुकावट और एक घंटे पहले तक जारी रहने की रिपोर्ट प्राप्त होती है, तो आप टाइप कर सकते हैं:

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

<पी> जैसा कि आप देख सकते हैं, जिन प्रविष्टियों को आप देखना चाहते हैं उन्हें फ़िल्टर करने के लिए समय की लचीली विंडो को परिभाषित करना अपेक्षाकृत सरल है।

सेवा, पीआईडी, या उपयोगकर्ता द्वारा सिस्टमडी जर्नल लॉग को कैसे फ़िल्टर करें

<पी> ऊपर, हमने कुछ तरीके सीखे हैं जिनसे आप समय की कमी का उपयोग करके जर्नल डेटा को फ़िल्टर कर सकते हैं। इस अनुभाग में हम चर्चा करेंगे कि आप किस सेवा या घटक में रुचि रखते हैं, उसके आधार पर फ़िल्टर कैसे करें। 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

<पी> इससे अलग-अलग प्रक्रियाओं के बजाय विभिन्न प्रोग्रामों और डिबग सिस्टम के बीच इंटरैक्शन को पहचानना बहुत आसान हो सकता है।

PID, UID, या GID के आधार पर सिस्टम लॉग को फ़िल्टर करें

<पी> कुछ सेवाएँ कार्य करने के लिए विभिन्न प्रकार की चाइल्ड प्रक्रियाओं को जन्म देती हैं। यदि आपने अपनी रुचि की प्रक्रिया की सटीक पीआईडी खोज ली है, तो आप उसके आधार पर भी फ़िल्टर कर सकते हैं।

<पी> ऐसा करने के लिए हम _PID निर्दिष्ट करके फ़िल्टर कर सकते हैं फ़ील्ड. उदाहरण के लिए, यदि जिस पीआईडी में हमारी रुचि है वह 8088 है, तो हम टाइप कर सकते हैं:

journalctl _PID=8088

<पी> अन्य समय में, आप किसी विशिष्ट उपयोगकर्ता या समूह से लॉग की गई सभी प्रविष्टियाँ दिखाना चाह सकते हैं। यह _UID के साथ किया जा सकता है या _GID फिल्टर. उदाहरण के लिए, यदि आपका वेब सर्वर www-data के अंतर्गत चलता है उपयोगकर्ता, आप टाइप करके उपयोगकर्ता आईडी पा सकते हैं:

id -u www-data

<पी> बाद में, आप जर्नल परिणामों को फ़िल्टर करने के लिए लौटाई गई आईडी का उपयोग कर सकते हैं:

journalctl _UID=33 --since today

<पी> systemd जर्नल में कई फ़ील्ड हैं जिनका उपयोग फ़िल्टरिंग के लिए किया जा सकता है। उनमें से कुछ को लॉग किए जाने की प्रक्रिया से पारित किया जाता है और कुछ को journald द्वारा लागू किया जाता है यह लॉग के समय सिस्टम से एकत्रित की गई जानकारी का उपयोग करता है।

<पी> अग्रणी अंडरस्कोर इंगित करता है कि _PID फ़ील्ड बाद वाले प्रकार का है. जर्नल स्वचालित रूप से उस प्रक्रिया की पीआईडी को रिकॉर्ड और अनुक्रमित करता है जो बाद में फ़िल्टरिंग के लिए लॉगिंग कर रही है। आप टाइप करके सभी उपलब्ध जर्नल फ़ील्ड के बारे में पता लगा सकते हैं:

man systemd.journal-fields

<पी> हम इस गाइड में इनमें से कुछ पर चर्चा करेंगे। हालाँकि, अभी हम इन क्षेत्रों द्वारा फ़िल्टर करने से संबंधित एक और उपयोगी विकल्प पर चर्चा करेंगे। -F किसी दिए गए जर्नल फ़ील्ड के लिए सभी उपलब्ध मान दिखाने के लिए विकल्प का उपयोग किया जा सकता है।

<पी> उदाहरण के लिए, यह देखने के लिए कि systemd किस समूह की आईडी है जर्नल में प्रविष्टियाँ हैं, आप टाइप कर सकते हैं:

journalctl -F _GID

<पी> यह आपको वे सभी मान दिखाएगा जो जर्नल ने समूह आईडी फ़ील्ड के लिए संग्रहीत किए हैं। इससे आपको अपना फ़िल्टर बनाने में मदद मिल सकती है।

निष्पादन योग्य पथ द्वारा लॉग देखें

<पी> हम पथ स्थान प्रदान करके भी फ़िल्टर कर सकते हैं।

<पी> यदि पथ किसी निष्पादन योग्य की ओर जाता है, तो 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

<पी> यह आपको त्रुटि, गंभीर, चेतावनी या आपातकालीन के रूप में चिह्नित सभी संदेश दिखाएगा। जर्नल मानक syslog लागू करता है संदेश स्तर. आप या तो प्राथमिकता नाम या उसके संगत संख्यात्मक मान का उपयोग कर सकते हैं। उच्चतम से निम्नतम प्राथमिकता के क्रम में, ये हैं:

0 :उभरना
1 :चेतावनी
2 :आलोचक
3 :ग़लती
4 :चेतावनी
5 :सूचना
6 :जानकारी
7 :डिबग

<पी> उपरोक्त संख्याओं या नामों को -p के साथ परस्पर उपयोग किया जा सकता है विकल्प. प्राथमिकता का चयन करने से निर्दिष्ट स्तर पर और उसके ऊपर चिह्नित संदेश प्रदर्शित होंगे।

`journalctl` को अनुकूलित करें लॉग आउटपुट डिस्प्ले

<पी> ऊपर, हमने फ़िल्टरिंग के माध्यम से प्रवेश चयन का प्रदर्शन किया। हालाँकि, ऐसे अन्य तरीके भी हैं जिनसे हम आउटपुट को संशोधित कर सकते हैं। हम journalctl को समायोजित कर सकते हैं विभिन्न आवश्यकताओं को पूरा करने के लिए प्रदर्शन।

`journalctl` में आउटपुट लंबाई और फ़ॉर्मेटिंग को कैसे नियंत्रित करें

<पी> हम journalctl को कैसे समायोजित कर सकते हैं डेटा को आउटपुट को सिकोड़ने या विस्तारित करने के लिए कहकर प्रदर्शित करता है।

<पी> डिफ़ॉल्ट रूप से, journalctl पेजर में संपूर्ण प्रविष्टि दिखाएगा, जिससे प्रविष्टियाँ स्क्रीन के दाईं ओर जा सकेंगी। इस जानकारी तक दायाँ तीर कुंजी दबाकर पहुँचा जा सकता है।

<पी> यदि आप आउटपुट को छोटा करना चाहते हैं, जहां जानकारी हटा दी गई है, वहां एक इलिप्सिस डालना, आप --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` में पेजर को कैसे अक्षम करें आउटपुट

<पी> डिफ़ॉल्ट रूप से, journalctl आसान उपभोग के लिए आउटपुट को पेजर में प्रदर्शित करता है। हालाँकि, यदि आप टेक्स्ट मैनिपुलेशन टूल के साथ डेटा को संसाधित करने की योजना बना रहे हैं, तो आप शायद मानक आउटपुट पर आउटपुट करने में सक्षम होना चाहते हैं।

<पी> आप इसे --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"
}
. . .

<पी> प्रदर्शन के लिए निम्नलिखित प्रारूपों का उपयोग किया जा सकता है:

बिल्ली :केवल संदेश फ़ील्ड ही प्रदर्शित करता है।
निर्यात :स्थानांतरित करने या बैकअप लेने के लिए उपयुक्त एक बाइनरी प्रारूप।
json :प्रति पंक्ति एक प्रविष्टि के साथ मानक JSON।
json-सुंदर :बेहतर मानव-पठनीयता के लिए JSON स्वरूपित
json-sse :ऐड सर्वर-भेजे गए ईवेंट को संगत बनाने के लिए JSON स्वरूपित आउटपुट लपेटा गया
संक्षिप्त :डिफ़ॉल्ट syslog स्टाइल आउटपुट
शॉर्ट-आइसो :आईएसओ 8601 वॉलक्लॉक टाइमस्टैम्प दिखाने के लिए डिफ़ॉल्ट प्रारूप को संवर्धित किया गया।
लघु-मोनोटोनिक :मोनोटोनिक टाइमस्टैम्प के साथ डिफ़ॉल्ट प्रारूप।
संक्षिप्त-सटीक :माइक्रोसेकंड परिशुद्धता के साथ डिफ़ॉल्ट प्रारूप
क्रियात्मक :प्रविष्टि के लिए उपलब्ध प्रत्येक जर्नल फ़ील्ड दिखाता है, जिसमें आमतौर पर आंतरिक रूप से छिपा हुआ फ़ील्ड भी शामिल है।

<पी> ये विकल्प आपको जर्नल प्रविष्टियों को आपकी वर्तमान आवश्यकताओं के अनुरूप किसी भी प्रारूप में प्रदर्शित करने की अनुमति देते हैं।

`journalctl` के साथ लाइव सिस्टम लॉग की निगरानी करें

<पी> journalctl कमांड यह अनुकरण करता है कि कितने प्रशासक tail का उपयोग करते हैं सक्रिय या हाल की गतिविधि की निगरानी के लिए। यह कार्यक्षमता journalctl में निर्मित है , आपको किसी अन्य टूल पर पाइप किए बिना इन सुविधाओं तक पहुंचने की अनुमति देता है।

`journalctl -n` के साथ हाल की लॉग प्रविष्टियाँ दिखाएँ

<पी> रिकॉर्ड की एक निर्धारित मात्रा प्रदर्शित करने के लिए, आप -n का उपयोग कर सकते हैं विकल्प, जो बिल्कुल tail -n की तरह काम करता है .

<पी> डिफ़ॉल्ट रूप से, यह नवीनतम 10 प्रविष्टियाँ प्रदर्शित करेगा:

journalctl -n

<पी> आप -n के बाद एक संख्या के साथ उन प्रविष्टियों की संख्या निर्दिष्ट कर सकते हैं जिन्हें आप देखना चाहते हैं :

journalctl -n 20

`journalctl -f` के साथ रीयल-टाइम लॉग का पालन करें

<पी> जैसे ही लॉग लिखे जा रहे हैं उनका सक्रिय रूप से अनुसरण करने के लिए, आप -f का उपयोग कर सकते हैं झंडा. फिर, यदि आपके पास tail -f का उपयोग करने का अनुभव है तो यह आपकी अपेक्षा के अनुरूप काम करता है :

journalctl -f

<पी> इस कमांड से बाहर निकलने के लिए, CTRL+C टाइप करें .

सिस्टमडी जर्नल लॉग्स को कैसे प्रबंधित और साफ करें

<पी> आप अब तक हमारे द्वारा देखे गए सभी डेटा को संग्रहीत करने की लागत के बारे में सोच रहे होंगे। इसके अलावा, आप कुछ पुराने लॉग्स को साफ करने और जगह खाली करने में रुचि ले सकते हैं।

`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 के साथ उपलब्ध) संस्करण 218 और बाद का)।

<पी> यदि आप --vacuum-size का उपयोग करते हैं विकल्प, आप आकार का संकेत देकर अपनी पत्रिका को छोटा कर सकते हैं। यह पुरानी प्रविष्टियों को तब तक हटा देगा जब तक कि डिस्क पर लिया गया कुल जर्नल स्थान अनुरोधित आकार पर न हो जाए:

sudo journalctl --vacuum-size=1G

<पी> एक और तरीका जिससे आप जर्नल को छोटा कर सकते हैं वह है --vacuum-time के साथ कटऑफ समय प्रदान करना विकल्प. उस समय के बाद की कोई भी प्रविष्टि हटा दी जाती है। यह आपको एक विशिष्ट समय के बाद बनाई गई प्रविष्टियों को रखने की अनुमति देता है।

<पी> उदाहरण के लिए, पिछले वर्ष की प्रविष्टियाँ रखने के लिए, आप टाइप कर सकते हैं:

sudo journalctl --vacuum-time=1years

जर्नल लॉग के लिए डिस्क स्थान सीमा कॉन्फ़िगर करें

<पी> आप अपने सर्वर को इस बात के लिए कॉन्फ़िगर कर सकते हैं कि जर्नल कितनी जगह ले सकता है। यह /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. एक विफल सिस्टमडी सेवा को डिबग करना

<पी> When a systemd-managed service fails to start or crashes unexpectedly, journalctl becomes an essential tool for identifying the root cause. 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 group. 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:

Create the persistent journal directory:
```
sudo mkdir -p /var/log/journal
```

Set permissions if needed:

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

Restart the journal daemon:

sudo systemctl restart systemd-journald

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.

Feature dmesg journalctl ScopeKernel ring buffer onlyKernel + system + userland logsPersistenceCleared on reboot or buffer fullPersistent (if enabled)MetadataNo structured metadataRich metadata (unit, PID, UID, etc.)FilteringLimitedExtensive filtering capabilitiesOutput formatsRaw, simpleJSON, export, short, verbose, etc.PermissionsRequires sudo for full outputRequires root or group membership

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 अंतर्राष्ट्रीय लाइसेंस।