0Pricing
Linux Command Line Mastery · レッスン

高度なログ分析とトラブルシューティング

システムログを調査し、`journalctl`を使って、複雑な問題を体系的に解決する方法を学びます。

「高度なログ分析とトラブルシューティング」はCoddyKit上の無料Linux Command Line Masteryレッスンです。 これはレッスン3/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これは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!

よくある質問

「高度なログ分析とトラブルシューティング」レッスンは無料ですか?

はい。「高度なログ分析とトラブルシューティング」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、Linux Command Line Masteryコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Linux Command Line Masteryコースには全4レッスンが含まれています。

「高度なログ分析とトラブルシューティング」で何を学びますか?

システムログを調査し、`journalctl`を使って、複雑な問題を体系的に解決する方法を学びます。 ブラウザで直接実行するハンズオンコードでLinux Command Line Masteryを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Linux Command Line Masteryを始めるのに経験は必要ですか?

事前経験は必要ありません。CoddyKitのLinux Command Line Masteryは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン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に戻る