Linux Command Line Mastery · บทเรียน

เทคนิคการบันทึกเหตุการณ์และแก้ไขปัญหาขั้นสูง

สำรวจบันทึกระบบ ใช้ `journalctl` และใช้แนวทางอย่างเป็นระบบเพื่อแก้ไขปัญหาที่ซับซ้อน

บทเรียน 3 จาก 411 ขั้นตอน

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

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

Why Logs Matter

When something goes wrong on a Linux system, logs are your best friend! They are like a digital diary that records events and activities.

System logs help you understand what happened, when it happened, and often, why it happened. This information is crucial for fixing problems and maintaining system health.

The `/var/log` Directory

Traditionally, most system logs are stored in the /var/log directory. You'll find many files here, each typically dedicated to a specific service or type of event.

  • auth.log: Records authentication attempts.
  • syslog: General system activity messages.
  • kern.log: Messages from the Linux kernel.

It's a treasure trove of information, but navigating it can be complex.

Viewing Classic Logs

For older log files or those not managed by systemd, you can use basic commands like cat, less, or tail to view their contents.

tail -f is especially useful for watching logs in real-time as new entries are added.

Try viewing the end of the syslog file (if available on your system):

tail /var/log/syslog

Modern Logging with `journalctl`

Modern Linux systems often use systemd, which includes its own logging system called the Journal. The command-line tool to interact with this journal is journalctl.

journalctl provides a centralized way to access logs from the kernel, services, and applications, making troubleshooting much more efficient than sifting through many files.

Your First `journalctl` Command

Running journalctl without any arguments will display all log messages collected by the systemd journal, starting from the oldest available entry.

It's a lot of information! You can scroll with arrow keys, Page Up/Down, or 'q' to quit. This is your comprehensive system log:

journalctl

Narrowing Down Log Entries

The real power of journalctl comes from its filtering capabilities. You can specify exactly what you want to see:

  • -u <unit>: Show logs for a specific systemd unit (e.g., a service like nginx or sshd).
  • -b: Show logs from the current boot.
  • --since "YYYY-MM-DD HH:MM:SS": Filter by a specific time or date.

Let's check logs specifically for the `ssh` service (sshd unit), if it's running:

journalctl -u sshd

Watching Logs in Real-time

Just like tail -f, journalctl can also display new log entries as they happen. This is incredibly useful when you're trying to debug an issue in real-time, for example, when starting a service.

Use the -f (follow) option to continuously monitor the journal for new messages:

journalctl -f

A Plan for Problem Solving

Effective troubleshooting isn't just about looking at logs; it's about having a systematic approach. Here's a common methodology:

  • Observe: What are the symptoms? What is failing or acting strangely?
  • Define: Clearly state the problem. What exactly is not working as expected?
  • Isolate: Determine where the problem might be (e.g., network, specific service, configuration, hardware).
  • Test: Propose a solution based on your findings and test it.
  • Document: Record what you did, what worked, and what didn't.

Where to Start Looking

When a problem arises, start with these basic checks:

  • Recent Changes: Did anything change recently? New software installed, configuration edits, system updates?
  • Service Status: Is the relevant service running? (Use systemctl status <service>).
  • Resource Usage: Are you out of disk space, memory, or CPU? (df -h, free -h, top).
  • Relevant Logs: Use journalctl -u <service> -b to check logs for the affected service since the last boot.

`journalctl` Filtering Challenge

You need to find log entries related to the nginx web server that occurred since yesterday. Which journalctl command(s) would be most appropriate?

Logs & Troubleshooting Recap

Great job! You've learned how critical system logs are for diagnosing issues on Linux.

We explored the traditional /var/log directory and, more importantly, mastered journalctl for viewing, filtering, and following modern systemd logs.

Remember to combine these powerful tools with a systematic troubleshooting approach to efficiently identify and resolve complex system problems!

เริ่มต้นได้ฟรี

เรียนรู้ Linux Command Line Mastery ด้วย AI tutor — ฟรี

เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป

คอร์ส
12
บทเรียน
48

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

บทเรียน “เทคนิคการบันทึกเหตุการณ์และแก้ไขปัญหาขั้นสูง” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “เทคนิคการบันทึกเหตุการณ์และแก้ไขปัญหาขั้นสูง” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Linux Command Line Mastery ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Linux Command Line Mastery มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “เทคนิคการบันทึกเหตุการณ์และแก้ไขปัญหาขั้นสูง”

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

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

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

บทเรียน “เทคนิคการบันทึกเหตุการณ์และแก้ไขปัญหาขั้นสูง” ใช้เวลานานแค่ไหน

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

ฉันเขียนและรันโค้ดในบทเรียน Linux Command Line Mastery นี้ได้ไหม

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

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

  1. การตรวจสอบดิสก์ I/O: `iostat`, `iotop`
  2. เครื่องมือประสิทธิภาพหน่วยความจำและ CPU
  3. เทคนิคการบันทึกเหตุการณ์และแก้ไขปัญหาขั้นสูง
  4. การติดตามการเรียกระบบด้วย strace และ ltrace
← กลับไปที่ Linux Command Line Mastery