स्क्रिप्ट में journalctl से journald को क्वेरी करना
स्वचालित घटना-प्राथमिकता निर्धारण के लिए systemd जर्नल प्रविष्टियों को यूनिट, प्राथमिकता और समय के आधार पर फ़िल्टर करें।
स्क्रिप्ट में journalctl से journald को क्वेरी करना, CoddyKit पर DevOps बूटकैंप का एक निःशुल्क पाठ है। यह 4 में से 3वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह DevOps बूटकैंप सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। DevOps बूटकैंप पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
घटना की प्रारंभिक जाँच के लिए journald क्यों?
systemd चलाने वाली आधुनिक Linux प्रणालियाँ सभी लॉग आउटपुट को जर्नल में केंद्रीकृत करती हैं — यह systemd-journald द्वारा प्रबंधित संरचित, बाइनरी लॉग भंडार है। /var/log की साधारण टेक्स्ट फ़ाइलों के विपरीत, हर जर्नल प्रविष्टि में समृद्ध मेटाडेटा होता है: यूनिट का नाम, प्राथमिकता स्तर, PID, UID, टाइमस्टैम्प और अन्य जानकारी।
स्वचालित घटना-जाँच स्क्रिप्ट में यह मेटाडेटा आपको सक्षम बनाता है:
grepकी शृंखलाओं के बिना लॉग को एक ही सेवा तक फ़िल्टर करना- पूछताछ को सटीक समय-सीमाओं तक सीमित करना (पिछले 15 मिनट, परिनियोजन के बाद से)
- शोर को अनदेखा करके केवल गंभीर/त्रुटि संदेश निकालना
- संरचित आउटपुट को सीधे चेतावनी पाइपलाइनों में भेजना
इन सभी सुविधाओं को उपलब्ध कराने वाला टूल journalctl है। यह पाठ आपको Bash स्क्रिप्ट के भीतर इसे प्रोग्राम के रूप में चलाना सिखाता है।
journalctl का मूल आह्वान
journalctl का सबसे सरल रूप पूरा जर्नल निकाल देता है। स्क्रिप्ट में आप लगभग कभी ऐसा नहीं चाहेंगे — हमेशा कम-से-कम एक फ़िल्टर जोड़ें। यहाँ वे सामान्य फ़्लैग हैं जिन्हें आप एक साथ इस्तेमाल करेंगे:
-u <unit>— systemd यूनिट के आधार पर फ़िल्टर करें (जैसेnginx.service)-p <priority>— syslog प्राथमिकता के आधार पर फ़िल्टर करें (0=emerg … 7=debug)--since/--until— समय-सीमा-n <N>— अंतिम N पंक्तियाँ--no-pager— इंटरैक्टिव पेजिंग बंद करें (स्क्रिप्ट में आवश्यक)-o <format>— आउटपुट प्रारूप (short,json,catआदि)
गैर-इंटरैक्टिव स्क्रिप्ट में हमेशा --no-pager दें, ताकि journalctl less चलाने का प्रयास करके अटक न जाए।
#!/usr/bin/env bash
# Print the last 20 lines of the nginx service journal
journalctl --no-pager -u nginx.service -n 20Systemd यूनिट के आधार पर फ़िल्टर करना
-u फ़्लैग किसी भी मान्य यूनिट नाम को स्वीकार करता है। यूनिटों को मिलाने के लिए आप इसे कई बार दे सकते हैं, जो तब उपयोगी है जब कोई एक अनुप्रयोग कई सेवाओं में फैला हो (जैसे API और उसका डेटाबेस साइडकार)।
यूनिट नाम <name>.service, <name>.socket, <name>.timer आदि के पैटर्न का पालन करते हैं। ग्लॉबिंग समर्थित है: -u 'myapp*', myapp-api.service, myapp-worker.service आदि से मेल खाता है।
किसी घटना-जाँच स्क्रिप्ट में आपको सामान्यतः यूनिट नाम एक आर्ग्युमेंट के रूप में मिलता है, जिससे फ़िल्टर गतिशील बन जाता है।
#!/usr/bin/env bash
# Usage: ./unit_logs.sh nginx.service
UNIT="${1:?Usage: $0 <unit>}"
echo "=== Journal for ${UNIT} (last 50 lines) ==="
journalctl --no-pager -u "${UNIT}" -n 50
# Combine two related units
echo "=== Combined: api + worker ==="
journalctl --no-pager -u myapp-api.service -u myapp-worker.service -n 30प्राथमिकता स्तर और -p फ़्लैग
-p फ़्लैग मानक syslog प्राथमिकता स्तरों से मैप होता है:
0— emerg1— alert2— crit3— err4— warning5— notice6— info7— debug
आप केवल वही स्तर देखने के लिए एकल स्तर (-p err) निर्दिष्ट कर सकते हैं, या आपातकाल से लेकर त्रुटियों तक सब कुछ कैप्चर करने के लिए एक सीमा (-p emerg..err) निर्दिष्ट कर सकते हैं — स्वचालित अलर्टिंग के लिए यह सबसे सामान्य विकल्प है।
नामित उपनाम (err, warning, crit) संख्यात्मक मानों के साथ स्वीकार किए जाते हैं।
#!/usr/bin/env bash
# Extract only error-level and above entries for sshd
journalctl --no-pager \
-u sshd.service \
-p emerg..err \
--since "1 hour ago"
# Exit non-zero if any errors were found (useful in CI health checks)
ERROR_COUNT=$(journalctl --no-pager -u sshd.service -p emerg..err \
--since "1 hour ago" --output=cat | wc -l)
if [[ "${ERROR_COUNT}" -gt 0 ]]; then
echo "[ALERT] ${ERROR_COUNT} error(s) detected in sshd" >&2
exit 1
fi--since और --until से समय-सीमा फ़िल्टर करना
समय फ़िल्टर, घटना-समय-सीमा से संबंधित क्वेरी का आधार होते हैं। journalctl मनुष्यों के लिए पढ़ने योग्य लचीले टाइमस्टैम्प स्वीकार करता है:
- सापेक्ष:
"10 minutes ago","2 hours ago","yesterday" - निरपेक्ष:
"2026-06-11 14:00:00" - विशेष कीवर्ड:
today,yesterday,-1h(संक्षिप्त रूप)
डिप्लॉय स्क्रिप्ट में सामान्य तरीका यह है कि डिप्लॉय से ठीक पहले का टाइमस्टैम्प कैप्चर किया जाए, फिर उसी बिंदु से जर्नल में क्वेरी करके रिलीज़ से उत्पन्न रिग्रेशन का पता लगाया जाए।
#!/usr/bin/env bash
# Record deploy start time, then check logs afterwards
DEPLOY_START=$(date +"%Y-%m-%d %H:%M:%S")
echo "Deploying at ${DEPLOY_START}..."
# ... your deploy steps here ...
sleep 2 # simulate deploy
echo "=== Journal since deploy start ==="
journalctl --no-pager \
-u myapp.service \
--since "${DEPLOY_START}" \
-p emerg..warningJSON फ़ॉर्मैट में संरचित आउटपुट
मशीन द्वारा पढ़ी जा सकने वाली पाइपलाइन के लिए -o json (हर पंक्ति में एक JSON ऑब्जेक्ट, NDJSON) या -o json-pretty (फ़ॉर्मैट किया हुआ) पास करें। प्रत्येक ऑब्जेक्ट में जर्नल के सभी फ़ील्ड होते हैं:
MESSAGE— लॉग का पाठPRIORITY— संख्यात्मक प्राथमिकता (0–7)_SYSTEMD_UNIT— मूल यूनिट__REALTIME_TIMESTAMP— epoch से बीते माइक्रोसेकंड_PID,_UID,_HOSTNAME— प्रक्रिया का मेटाडेटा
आप इस NDJSON स्ट्रीम को jq में पाइप करके फ़ील्ड निकाल, फ़िल्टर या फिर से फ़ॉर्मैट कर सकते हैं, ताकि इसे PagerDuty, Slack वेबहुक या SIEM इनजेस्टर जैसी डाउनस्ट्रीम अलर्टिंग प्रणालियों के लिए तैयार किया जा सके।
#!/usr/bin/env bash
# Extract error messages as a clean list for a Slack notification
MESSAGES=$(journalctl --no-pager \
-u nginx.service \
-p emerg..err \
--since "30 minutes ago" \
-o json \
| jq -r '.MESSAGE' \
| sort -u)
if [[ -n "${MESSAGES}" ]]; then
echo "Errors detected:"
echo "${MESSAGES}"
fiजर्नल को रीयल टाइम में देखना
-f फ़्लैग journalctl को जर्नल का लाइव अंतिम भाग दिखाने देता है — यह लॉग फ़ाइल पर tail -f के समान है। यूनिट और प्राथमिकता फ़िल्टर के साथ मिलकर यह एक लक्षित रीयल-टाइम मॉनिटर बन जाता है।
स्क्रिप्टेड पाइपलाइन में अधिक उपयोगी तरीका कर्सर-आधारित पोलिंग है: वर्तमान जर्नल कर्सर सहेजें, फिर हर पोल में --after-cursor=<cursor> पास करके पिछली जाँच के बाद की केवल नई प्रविष्टियाँ पढ़ें। इससे पुरानी पंक्तियों को दोबारा संसाधित करने से बचा जाता है।
--show-cursor -n 0 से नवीनतम कर्सर प्राप्त करें और आउटपुट में मौजूद -- cursor: पंक्ति को पार्स करें।
#!/usr/bin/env bash
# Cursor-based polling: read only new journal entries each run
CURSOR_FILE="/tmp/triage_cursor"
if [[ -f "${CURSOR_FILE}" ]]; then
CURSOR=$(cat "${CURSOR_FILE}")
NEW_ENTRIES=$(journalctl --no-pager \
-u myapp.service \
-p emerg..err \
--after-cursor="${CURSOR}" \
-o json)
else
# First run: look back 5 minutes
NEW_ENTRIES=$(journalctl --no-pager \
-u myapp.service \
-p emerg..err \
--since "5 minutes ago" \
-o json)
fi
# Save updated cursor for next poll
journalctl --no-pager -n 0 --show-cursor 2>&1 \
| grep '^-- cursor:' \
| sed 's/-- cursor: //' \
> "${CURSOR_FILE}"
echo "${NEW_ENTRIES}" | jq -r '.MESSAGE // empty'-b से बूट-सीमित क्वेरी
-b फ़्लैग किसी क्वेरी को किसी विशिष्ट बूट सत्र तक सीमित करता है। क्रैश या अनपेक्षित रीबूट के बाद वर्तमान बूट के बजाय पिछले बूट के लॉग प्राप्त करने के लिए यह आवश्यक है।
-b 0— वर्तमान बूट (डिफ़ॉल्ट)-b -1— पिछला बूट-b -2— उससे दो बूट पहले--list-boots— टाइमस्टैम्प सहित सभी रिकॉर्ड किए गए बूट सत्र दिखाएँ
मरणोपरांत विश्लेषण की स्क्रिप्टें अक्सर पिछले बूट (-b -1) के महत्वपूर्ण लॉग डंप करती हैं, ताकि यह पता लगाया जा सके कि सिस्टम क्रैश क्यों हुआ या सेवा स्टार्टअप पर क्यों विफल हुई।
#!/usr/bin/env bash
# Post-mortem: collect critical logs from the previous boot
echo "=== Previous boot sessions ==="
journalctl --list-boots
echo ""
echo "=== Critical entries from previous boot ==="
journalctl --no-pager \
-b -1 \
-p emerg..crit \
-o short-isojournalctl में grep करना बनाम नेटिव मिलान
आप सभी फ़्लैग के बाद कच्चा grep पैटर्न दे सकते हैं, लेकिन journalctl FIELD=value सिंटैक्स का उपयोग करके नेटिव फ़ील्ड मिलान भी समर्थित करता है। नेटिव मिलानों का मूल्यांकन संरचित मेटाडेटा के आधार पर होता है — grep से पाठ को बाद में संसाधित करने की तुलना में यह बहुत तेज़ है।
कुछ सामान्य उपयोगी मिलान:
_PID=1234— किसी विशिष्ट प्रक्रिया के लॉग_COMM=python3—python3नाम वाली किसी भी प्रक्रिया के लॉगSYSLOG_IDENTIFIER=myapp— कस्टम पहचानकर्ता से टैग किए गए लॉग
कई FIELD=value तर्कों को AND से जोड़ा जाता है; उनके बीच + रखने से OR बनता है। जब संरचित मेटाडेटा पर्याप्त न हो, तब पूर्ण-पाठ grep के लिए -g <regex> का उपयोग करें।
#!/usr/bin/env bash
# Native field match: errors from the postgres process only
journalctl --no-pager \
_COMM=postgres \
-p emerg..err \
--since "1 hour ago"
# Full-text grep for a specific error string
journalctl --no-pager \
-u postgresql.service \
--since "1 hour ago" \
-g "FATAL|PANIC" \
--output=catपुन: उपयोग योग्य triage फ़ंक्शन बनाना
एकल फ़्लैग में महारत हासिल करने के बाद, उन्हें पुन: उपयोग योग्य Bash फ़ंक्शन में संयोजित करने से आपकी triage स्क्रिप्टें साफ़-सुथरी और सुसंगत रहती हैं। अच्छी तरह डिज़ाइन किए गए फ़ंक्शन को चाहिए कि वह:
- यूनिट, प्राथमिकता सीमा और समय-सीमा को पैरामीटर के रूप में स्वीकार करे
- तर्क न दिए जाने पर सुरक्षित और कम-शोर वाले मानों का डिफ़ॉल्ट उपयोग करे
- त्रुटियाँ मिलने पर शून्य से अलग निकास कोड लौटाए (CI पाइपलाइन के साथ एकीकृत होता है)
- ऑडिट रिकॉर्ड के लिए निष्कर्षों को stdout और टाइमस्टैम्प वाली लॉग फ़ाइल, दोनों में लिखे
#!/usr/bin/env bash
# triage.sh — reusable journal triage function
triage_unit() {
local unit="${1:?unit required}"
local priority="${2:-emerg..err}"
local since="${3:-1 hour ago}"
local logfile="/tmp/triage_${unit//[^a-zA-Z0-9]/_}_$(date +%s).log"
echo "[$(date -Iseconds)] Triaging ${unit} | prio=${priority} | since='${since}'" | tee "${logfile}"
journalctl --no-pager \
-u "${unit}" \
-p "${priority}" \
--since "${since}" \
-o short-iso \
| tee -a "${logfile}"
local count
count=$(wc -l < "${logfile}")
# Subtract 1 for the header line
(( count-- ))
if [[ "${count}" -gt 0 ]]; then
echo "[ALERT] ${count} line(s) logged to ${logfile}" >&2
return 1
fi
return 0
}
# Example: triage nginx errors in the last 30 minutes
triage_unit nginx.service "emerg..err" "30 minutes ago"स्वचालित घटना triage स्क्रिप्ट
नीचे दी गई पूरी स्क्रिप्ट सभी अवधारणाओं को एक व्यावहारिक स्वचालित triage टूल में जोड़ती है। यह महत्वपूर्ण सेवाओं की सूची पढ़ती है, कॉन्फ़िगर की जा सकने वाली पिछली अवधि में प्रत्येक के लिए जर्नल से क्वेरी करती है, निष्कर्षों को एकत्र करती है और कोई त्रुटि मिलने पर विफलता कोड के साथ बाहर निकलती है — इसलिए यह cron जॉब या CI स्वास्थ्य-जाँच चरण के रूप में उपयुक्त है।
#!/usr/bin/env bash
# incident_triage.sh — automated multi-service journal triage
set -euo pipefail
LOOKBACK="${1:-15 minutes ago}"
PRIORITY="emerg..err"
SERVICES=(nginx.service postgresql.service myapp-api.service myapp-worker.service)
REPORT="/tmp/incident_report_$(date +%Y%m%d_%H%M%S).txt"
FAILED=0
{
echo "Incident Triage Report"
echo "Generated : $(date -Iseconds)"
echo "Lookback : ${LOOKBACK}"
echo "Priority : ${PRIORITY}"
echo "-----------------------------------"
} > "${REPORT}"
for svc in "${SERVICES[@]}"; do
ENTRIES=$(journalctl --no-pager \
-u "${svc}" \
-p "${PRIORITY}" \
--since "${LOOKBACK}" \
--output=cat 2>/dev/null || true)
COUNT=$(echo "${ENTRIES}" | grep -c . || true)
if [[ "${COUNT}" -gt 0 ]]; then
echo "[FAIL] ${svc}: ${COUNT} error(s)" | tee -a "${REPORT}"
echo "${ENTRIES}" >> "${REPORT}"
echo "-----------------------------------" >> "${REPORT}"
FAILED=1
else
echo "[OK] ${svc}"
fi
done
echo ""
echo "Full report: ${REPORT}"
exit "${FAILED}"ज्ञान-जाँच: प्राथमिकता सीमा फ़िल्टर करना
आप ऐसी स्क्रिप्ट लिख रहे हैं जो ऑन-कॉल इंजीनियरों को केवल तब अलर्ट करे, जब कोई सेवा त्रुटि-गंभीरता या उससे अधिक गंभीर संदेश लॉग करे (अर्थात् error, critical, alert या emergency)। कौन-सा journalctl फ़्लैग संयोजन ठीक इसी सीमा को कैप्चर करता है?
पाठ का पुनरावलोकन: स्क्रिप्ट में journalctl
इस पाठ में आपने स्वचालित घटना triage के लिए systemd जर्नल से प्रोग्राम के माध्यम से क्वेरी करना सीखा:
- स्क्रिप्ट में हमेशा
--no-pagerपास करें, ताकि इंटरैक्टिव रुकावट न हो। - यूनिट फ़िल्टरिंग (
-u) क्वेरी को एक या अधिक सेवाओं तक सीमित करती है; ग्लोबिंग और कई-uफ़्लैग समर्थित हैं। - प्राथमिकता फ़िल्टरिंग (
-p emerg..err) केवल आपकी ज़रूरत वाले गंभीरता स्तर कैप्चर करती है — याद रखें कि छोटी संख्याएँ अधिक गंभीरता दर्शाती हैं। - समय-सीमाएँ (
--since/--until) मनुष्यों के लिए पढ़ने योग्य टाइमस्टैम्प का उपयोग करके लॉग आउटपुट को डिप्लॉयमेंट अवधि या पिछली अवधि तक सीमित करती हैं। - बूट-सीमांकन (
-b -1) मरणोपरांत विश्लेषण की स्क्रिप्टों को पिछले क्रैश सत्र के लॉग पढ़ने देता है। - JSON आउटपुट (
-o json) औरjqअलर्टिंग या SIEM प्रणालियों को डेटा भेजने वाली संरचित पाइपलाइन सक्षम करते हैं। - कर्सर-आधारित पोलिंग में
--after-cursorका उपयोग दोहराए गए रन में पुरानी प्रविष्टियों को दोबारा संसाधित करने से बचाता है। - नेटिव फ़ील्ड मिलान (
_COMM=,SYSLOG_IDENTIFIER=)grepमें पाइप करने से तेज़ होते हैं।
इन फ़्लैग को पुन: उपयोग योग्य Bash फ़ंक्शन में संयोजित करने से आपको उत्पादन-स्तर का triage टूल मिलता है, जो cron, CI पाइपलाइन और ऑन-कॉल अलर्टिंग कार्यप्रवाहों के साथ आसानी से एकीकृत होता है।
एआई शिक्षक के साथ DevOps बूटकैंप सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 142
- पाठ
- 568
अक्सर पूछे जाने वाले प्रश्न
क्या “स्क्रिप्ट में journalctl से journald को क्वेरी करना” पाठ निःशुल्क है?
हाँ — DevOps बूटकैंप अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “स्क्रिप्ट में journalctl से journald को क्वेरी करना” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। DevOps बूटकैंप पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“स्क्रिप्ट में journalctl से journald को क्वेरी करना” में मैं क्या सीखूँगा?
स्वचालित घटना-प्राथमिकता निर्धारण के लिए systemd जर्नल प्रविष्टियों को यूनिट, प्राथमिकता और समय के आधार पर फ़िल्टर करें। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ DevOps बूटकैंप का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या DevOps बूटकैंप शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर DevOps बूटकैंप शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 3वाँ पाठ है।
“स्क्रिप्ट में journalctl से journald को क्वेरी करना” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस DevOps बूटकैंप पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर DevOps बूटकैंप पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- बड़े पैमाने पर वेब और एप्लिकेशन लॉग पार्स करना
- रीयल-टाइम लॉग फ़ॉलो करना और स्ट्रीमिंग चेतावनियाँ
- स्क्रिप्ट में journalctl से journald को क्वेरी करना
- लॉग धाराओं से मेट्रिक और हिस्टोग्राम निकालना