DevOps Bootcamp · บทเรียน

การสอบถาม journald ด้วย journalctl ในสคริปต์

กรองรายการบันทึกของ systemd ตามยูนิต ระดับความสำคัญ และเวลา เพื่อคัดแยกเหตุการณ์โดยอัตโนมัติ

การสอบถาม journald ด้วย journalctl ในสคริปต์ เป็นบทเรียน DevOps Bootcamp ฟรีบน CoddyKit นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน DevOps Bootcamp และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส DevOps Bootcamp มีบทเรียนทั้งหมด 4 บทเรียน

เหตุใดจึงใช้ journald เพื่อคัดแยกเหตุขัดข้อง

ระบบ Linux รุ่นใหม่ที่ใช้ systemd จะรวมผลลัพธ์บันทึกทั้งหมดไว้ในjournal — ที่เก็บบันทึกแบบไบนารีและมีโครงสร้าง ซึ่งจัดการโดย systemd-journald ต่างจากไฟล์ข้อความทั่วไปใน /var/log รายการ journal ทุก条จะมีข้อมูลเมทาดาทาที่ครบถ้วน เช่น ชื่อหน่วย ระดับความสำคัญ PID, UID การประทับเวลา และอื่น ๆ

ในสคริปต์คัดแยกเหตุขัดข้องอัตโนมัติ เมทาดาทานี้ช่วยให้คุณ:

กรองบันทึกให้เหลือบริการเดียวโดยไม่ต้องต่อคำสั่ง grep หลายชุด
จำกัดขอบเขตคำค้นให้อยู่ในช่วงเวลาที่แน่นอน (15 นาทีล่าสุด นับตั้งแต่การนำไปใช้งาน)
ส่งออกเฉพาะข้อความวิกฤตหรือข้อผิดพลาด โดยไม่รวมสัญญาณรบกวน
ส่งผลลัพธ์แบบมีโครงสร้างเข้าสู่สายงานแจ้งเตือนได้โดยตรง

เครื่องมือที่เปิดให้ใช้งานทั้งหมดนี้คือ journalctl บทเรียนนี้จะสอนให้คุณควบคุมเครื่องมือนี้ด้วยโปรแกรมภายในสคริปต์ Bash

การเรียกใช้ journalctl เบื้องต้น

รูปแบบที่ง่ายที่สุดของ journalctl คือการถ่ายข้อมูล journal ทั้งหมดออกมา ในสคริปต์แทบไม่ควรทำเช่นนั้น — ให้เพิ่มตัวกรองอย่างน้อยหนึ่งตัวเสมอ ต่อไปนี้คือตัวเลือกที่พบบ่อยที่สุดซึ่งคุณจะใช้ต่อกัน:

-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 20

การกรองตามหน่วย Systemd

ตัวเลือก -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 — emerg
1 — alert
2 — crit
3 — err
4 — warning
5 — notice
6 — info
7 — 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..warning

เอาต์พุตแบบมีโครงสร้างด้วยรูปแบบ JSON

สำหรับกระบวนการประมวลผลที่เครื่องอ่านได้ ให้ส่ง -o json (ออบเจ็กต์ JSON หนึ่งรายการต่อหนึ่งบรรทัด, NDJSON) หรือ -o json-pretty (จัดรูปแบบให้อ่านง่าย) แต่ละออบเจ็กต์จะมีฟิลด์ทั้งหมดของบันทึก:

MESSAGE — ข้อความบันทึก
PRIORITY — ระดับความสำคัญเป็นตัวเลข (0–7)
_SYSTEMD_UNIT — หน่วยต้นทาง
__REALTIME_TIMESTAMP — จำนวนไมโครวินาทีตั้งแต่ยุคอ้างอิง
_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-iso

การใช้ grep ภายใน journalctl เทียบกับการจับคู่แบบเนทีฟ

คุณสามารถส่งรูปแบบ grep ดิบต่อท้ายแฟล็กทั้งหมดได้ แต่ journalctl ยังรองรับ การจับคู่ฟิลด์แบบเนทีฟ โดยใช้ไวยากรณ์ FIELD=value การจับคู่แบบเนทีฟจะตรวจสอบกับข้อมูลเมตาที่มีโครงสร้าง จึงเร็วกว่าให้ grep ประมวลผลข้อความภายหลังมาก

ตัวอย่างการจับคู่ที่มีประโยชน์:

_PID=1234 — บันทึกจากกระบวนการที่ระบุ
_COMM=python3 — บันทึกจากกระบวนการใด ๆ ที่ชื่อ python3
SYSLOG_IDENTIFIER=myapp — บันทึกที่ติดแท็กด้วยตัวระบุแบบกำหนดเอง

อาร์กิวเมนต์ FIELD=value หลายรายการจะเชื่อมด้วย AND ส่วนเครื่องหมาย + ระหว่างรายการจะสร้างเงื่อนไข OR ใช้ -g <regex> สำหรับการค้นหา grep แบบเต็มข้อความเมื่อข้อมูลเมตาที่มีโครงสร้างไม่เพียงพอ

#!/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

การสร้างฟังก์ชันวิเคราะห์เหตุที่นำกลับมาใช้ซ้ำได้

เมื่อคุณเชี่ยวชาญการใช้แฟล็กแต่ละรายการแล้ว การประกอบแฟล็กเหล่านั้นเป็นฟังก์ชัน Bash ที่นำกลับมาใช้ซ้ำได้จะช่วยให้สคริปต์วิเคราะห์เหตุเป็นระเบียบและสอดคล้องกัน ฟังก์ชันที่ออกแบบมาอย่างดีควร:

รับหน่วย ช่วงระดับความสำคัญ และช่วงเวลาเป็นพารามิเตอร์
ใช้ค่าเริ่มต้นที่ปลอดภัยและมีเสียงรบกวนน้อยเมื่อไม่ได้ระบุอาร์กิวเมนต์
คืนรหัสออกที่ไม่ใช่ศูนย์เมื่อพบข้อผิดพลาด (เชื่อมต่อกับกระบวนการประมวลผล 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"

สคริปต์วิเคราะห์เหตุอัตโนมัติ

สคริปต์ฉบับสมบูรณ์ต่อไปนี้รวบรวมแนวคิดทั้งหมดเข้าด้วยกันเป็นเครื่องมือวิเคราะห์เหตุอัตโนมัติที่ใช้งานได้จริง สคริปต์จะอ่านรายการบริการสำคัญ ค้นหาบันทึกของแต่ละบริการในช่วงย้อนหลังที่กำหนดค่าได้ รวบรวมผลการตรวจพบ และจบการทำงานด้วยรหัสล้มเหลวหากตรวจพบข้อผิดพลาดใด ๆ จึงเหมาะสำหรับใช้เป็นงาน 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 ในสคริปต์

ในบทเรียนนี้ คุณได้เรียนรู้วิธีค้นหาบันทึกของ systemd ด้วยโปรแกรม เพื่อวิเคราะห์เหตุอัตโนมัติ:

ส่ง --no-pager เสมอในสคริปต์ เพื่อป้องกันการหยุดรอการโต้ตอบ
การกรองตามหน่วย (-u) จำกัดการค้นหาให้กับบริการหนึ่งรายการขึ้นไป รองรับการใช้รูปแบบโกลบและแฟล็ก -u หลายรายการ
การกรองตามระดับความสำคัญ (-p emerg..err) เก็บเฉพาะระดับความรุนแรงที่ต้องการ โปรดจำไว้ว่าตัวเลขที่น้อยกว่าจะมีความรุนแรงมากกว่า
ช่วงเวลา (--since / --until) จำกัดเอาต์พุตบันทึกให้อยู่ในช่วงการนำระบบขึ้นใช้งานหรือช่วงย้อนหลัง โดยใช้การประทับเวลาที่อ่านเข้าใจได้ง่าย
การจำกัดตามการบูต (-b -1) ช่วยให้สคริปต์วิเคราะห์หลังเกิดเหตุอ่านบันทึกจากเซสชันที่ระบบขัดข้องก่อนหน้าได้
เอาต์พุต JSON (-o json) และ jq ช่วยสร้างกระบวนการประมวลผลที่มีโครงสร้างเพื่อส่งต่อไปยังระบบแจ้งเตือนหรือระบบ SIEM
การดึงข้อมูลเป็นระยะโดยอาศัยเคอร์เซอร์ร่วมกับ --after-cursor ช่วยหลีกเลี่ยงการประมวลผลรายการเก่าซ้ำเมื่อเรียกใช้หลายครั้ง
การจับคู่ฟิลด์แบบเนทีฟ (_COMM=, SYSLOG_IDENTIFIER=) เร็วกว่าการส่งข้อมูลไปยัง grep

การรวมแฟล็กเหล่านี้ไว้ในฟังก์ชัน Bash ที่นำกลับมาใช้ซ้ำได้ จะทำให้คุณมีเครื่องมือวิเคราะห์เหตุระดับพร้อมใช้งานจริง ซึ่งเชื่อมต่อกับ cron, กระบวนการประมวลผล CI และกระบวนการแจ้งเตือนผู้เข้าเวรได้อย่างราบรื่น

คำถามที่พบบ่อย

บทเรียน “การสอบถาม journald ด้วย journalctl ในสคริปต์” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การสอบถาม journald ด้วย journalctl ในสคริปต์” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส DevOps Bootcamp ให้อัปเกรดเป็น CoddyKit PRO คอร์ส DevOps Bootcamp มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การสอบถาม journald ด้วย journalctl ในสคริปต์”

กรองรายการบันทึกของ systemd ตามยูนิต ระดับความสำคัญ และเวลา เพื่อคัดแยกเหตุการณ์โดยอัตโนมัติ คุณปฏิบัติ DevOps Bootcamp ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน DevOps Bootcamp หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน DevOps Bootcamp บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน

บทเรียน “การสอบถาม journald ด้วย journalctl ในสคริปต์” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน DevOps Bootcamp นี้ได้ไหม

ได้ บทเรียน DevOps Bootcamp ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

การแยกวิเคราะห์บันทึกเว็บและแอปพลิเคชันในระดับใหญ่
การติดตามบันทึกแบบเรียลไทม์และการแจ้งเตือนแบบสตรีม
การสอบถาม journald ด้วย journalctl ในสคริปต์
การคำนวณตัวชี้วัดและฮิสโตแกรมจากกระแสบันทึก

← กลับไปที่ DevOps Bootcamp