【第7回】Linuxトラブルシューティングの要！journalctlによるシステムログ完全攻略

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
「Linuxエンジニアになるための基礎」連載、いよいよ第7回へ突入です。前回は、システム自動化の心臓部である systemd を用いたサービス管理（デーモン化）の極意を学びました。

今回は、サーバー運用における「探偵のルーペ」とも言える「システムログの確認とトラブルシューティング（journalctl）」について、圧倒的な情報密度で徹底解剖します。システム障害が発生した際、「なぜ落ちたのか」「いつから異常が起きていたのか」を正確に突き止める能力こそが、インフラエンジニアの真の価値を決定づけます。

---

第1章：ログ管理の進化（rsyslogからsystemd-journaldへ）

まずは、Linuxのログ管理の歴史とアーキテクチャの変遷を理解しましょう。

1-1. 従来のログ管理（rsyslog）の限界

過去数十年間、Linuxのログは rsyslog などのデーモンによって収集され、/var/log/messages や /var/log/secure といった「ただのテキストファイル」として保存されてきました。しかし、この方式には以下の課題がありました。

• 単なるテキストのため、メタデータ（プロセスのPID、UID、カーネルの起動IDなど）が欠落しがち。
• フォーマットが各アプリケーションによってバラバラで、パース（解析）が困難。
• 検索手段が grep に頼るしかなく、数GBのファイルになると検索に膨大な時間がかかる。

1-2. バイナリ・ジャーナル（systemd-journald）の革命

AlmaLinux（systemdベースのOS）では、ログの収集と管理を systemd-journald が担当します。
最大の特徴は、ログが単なるテキストではなく「インデックス化されたバイナリファイル」として保存される点です。これにより、データベースのように「特定の時間帯」「特定のサービス」などの条件を組み合わせて、一瞬でログを抽出することが可能になりました。
このバイナリ・データベースにアクセスするための専用クライアントツールが journalctl コマンドです。

---

第2章：journalctlの基本操作とリアルタイム監視（-f, -n, -r）

オプションなしで journalctl を実行すると、OSが起動してからの全てのログが表示されますが、これでは量が多すぎて実用性がありません。プロは必ずオプションを組み合わせて情報を絞り込みます。

2-1. 直近のログを表示する（-n, -r）

障害発生直後は、「今、まさに何が起きているか」を知る必要があります。

# 直近の50行のログだけを表示する（--lines=50 と同義）
journalctl -n 50

# ログを「最新のものから順番に（逆順で）」表示する（--reverse と同義）
journalctl -r

-r オプションは非常に強力です。通常ログは古いものから表示されるため、エラーログを探すために何百ページもスクロールダウンする必要がありますが、-r を付ければ、一番上に「1秒前の最新のログ」が表示されるため、圧倒的な時短になります。

2-2. リアルタイム監視（-f）

現在進行形でシステムの挙動を確認したい場合、tail -f と同じ役割を果たすのが -f (follow) オプションです。

# システム全体のログをリアルタイムで追従監視する
journalctl -f

設定ファイルを書き換えてサービスを再起動した直後など、別ウィンドウでこのコマンドを走らせておくのがインフラエンジニアの基本動作です。

---

第3章：時間と期間によるタイムトラベル検索（–since, –until）

障害の調査において、「昨日の午後3時ごろにサーバーが遅くなった」といった曖昧な報告を受けた場合、テキストファイルベースのログでは目視でその時間帯を探し出すのは困難です。しかし、journalctl なら「時間」をデータベースのクエリとして指定できます。

3-1. 日時指定による絞り込み

--since（この時間以降）と --until（この時間以前）を組み合わせます。日時のフォーマットは YYYY-MM-DD HH:MM:SS です。

# 2026年8月22日の 15:00:00 から 15:30:00 までのログを抽出する
journalctl --since "2026-08-22 15:00:00" --until "2026-08-22 15:30:00"

3-2. 人間に優しい相対時間の指定

日時を正確に打つのが面倒な場合、プロは相対時間（today, yesterday, 1 hour ago など）を多用します。

# 「今日の午前0時」以降のログだけを表示
journalctl --since today

# 「昨日の午前0時」から「今日の午前0時」までのログを表示
journalctl --since yesterday --until today

# 「10分前」から現在までのログを表示（障害直後の初動調査に最適）
journalctl --since "10 min ago"

---

第4章：サービス（Unit）と重要度（Priority）による絞り込み（-u, -p）

システム全体のログから「Nginxのログだけ」「エラーログだけ」を抽出できる機能こそが、journalctl 最大の強みです。

4-1. 特定のサービス（デーモン）のログだけを抽出（-u）

-u (unit) オプションを使えば、特定の systemd サービスが出力したログだけにフィルタリングできます。

# Nginx（Webサーバー）のログだけを表示する
journalctl -u nginx.service

# MariaDB（データベース）の直近のログをリアルタイム監視する
journalctl -u mariadb.service -f

これにより、コウ君が直面した「ログがごちゃ混ぜになって読めない」という問題は完全に解決します。

4-2. 重大度（プライオリティ）によるエラー抽出（-p）

ログには、情報(Info)や警告(Warning)、エラー(Error)といった「重大度（Priority）」が紐付けられています。-p (priority) オプションを使うと、指定した重大度「以上」のログだけを炙り出すことができます。

数値	重大度名	意味
0	emerg	システムが使用不可能（パニック）
3	err	一般的なエラー（サービス停止など）
4	warning	警告。今は動いているが将来問題になる可能性がある
6	info	通常の情報メッセージ（デフォルト）

# システム全体の中から「エラー（err / レベル3）」以上の致命的なログだけを抽出
journalctl -p err

# 組み合わせ技：Nginxのログのうち、警告（warning / レベル4）以上のものだけを、今日の分だけ抽出
journalctl -u nginx.service -p warning --since today

---

第5章：出力フォーマットの柔軟な変更（-o json-pretty, -o short-full）

systemd-journald はログをバイナリで保持しているため、出力する際のフォーマットを自由に変更できます。これは、ログ監視ツール（DatadogやSplunkなど）にログを転送する際に極めて有用です。

5-1. 詳細な日時の表示（short-full）

デフォルトでは「Aug 22 15:30:00」のように年が省略されて表示されますが、監査目的などではミリ秒や年まで正確に出力させる必要があります。

# 年やタイムゾーン、マイクロ秒まで含めた完全なタイムスタンプで出力
journalctl -o short-full

5-2. JSON形式での出力（json-pretty）

API連携や、システム管理者が内部のメタデータを詳細に解析したい場合、ログをJSONオブジェクトとして出力させることができます。

# ログの内部構造を、人間が読みやすいJSON形式で整形して出力
journalctl -n 1 -o json-pretty

これを実行すると、_PID や _UID、_SYSTEMD_UNIT といった、OSが裏で密かに記録していた詳細な属性情報がすべて明らかになります。プロのインフラエンジニアは、このメタデータを元にさらに精密なクエリを組み立てます。

---

第6章：揮発性ログから永続化ログへの変更（/var/log/journal/）

AlmaLinux 9などの初期設定において、非常に恐ろしい落とし穴があります。
それは、「デフォルト設定では、journalのログはメモリ上（/run/log/journal/）にしか保存されず、OSを再起動するとすべてのログが消滅してしまう」ケースがあるという点です。

6-1. ログの永続化設定（プロ必須の構築手順）

OSがカーネルパニック等でクラッシュした場合、再起動後にその原因を調査できなければ意味がありません。プロのエンジニアは、サーバー構築時に必ず「ログの永続化（ディスクへの保存）」を保証する設定を行います。

設定は至ってシンプルです。永続化用のディレクトリを作成し、systemd-journald を再起動するだけです。

# 永続化用のディレクトリを作成
sudo mkdir -p /var/log/journal

# ディレクトリの権限と所有者を正しく設定（systemd-journal グループ）
sudo chown root:systemd-journal /var/log/journal
sudo chmod 2775 /var/log/journal

# journald サービスを再起動して設定を適用
sudo systemctl restart systemd-journald

これにより、OSが再起動してもログはディスク上に残り続け、過去の起動セッション（--list-boots）を跨いだログ調査が可能になります。

# 過去のOS起動セッションの一覧を表示（永続化後から記録される）
journalctl --list-boots

# 1つ前のOS起動セッション（前回クラッシュする前）のログを抽出する
journalctl -b -1

---

第7章：ログの肥大化を防ぐローテーションと容量管理（–vacuum-size）

ログを永続化（ディスクへ保存）するということは、放っておけばいつかディスク容量（/var）を食い潰し、サーバーをダウンさせる（No space left on device）危険があるということです。
journalctl には、肥大化したバイナリログを安全に掃除（バキューム）する機能が備わっています。

7-1. 現在のディスク使用量の確認

# journalログが現在どれだけのディスク容量を消費しているか確認する
journalctl --disk-usage

7-2. 手動でのログ削除（バキューム）

ディスク逼迫アラートが鳴った際の緊急対応として、サイズや期間を指定して古いログを強制削除します。

# ログの合計サイズが 500MB になるまで、古いログから順に削除する
sudo journalctl --vacuum-size=500M

# または、過去30日間より古いログをすべて削除する
sudo journalctl --vacuum-time=30d

---

第8章：【実践】障害発生時のプロのログ調査フロー

これまでの知識を総動員して、コウ君が直面した「MariaDBが突然ダウンした」というインシデントに対する、プロのインフラエンジニアの流れるような調査手順を見てみましょう。

# 1. まずはサービスの現在のステータスと、直近の終了ログを確認
sudo systemctl status mariadb

# 2. MariaDBのログから「エラー（err）」以上の重大なものを、過去1時間分だけ抽出
sudo journalctl -u mariadb -p err --since "1 hour ago"

# 3. （エラーログに「OOM Killer」の痕跡があった場合）カーネル全体のログからメモリ枯渇の証拠を探す
sudo journalctl -k | grep -i "out of memory"

# 4. （OS自体が勝手に再起動していた場合）前回の起動セッションにおける、システム停止直前のログを確認する
sudo journalctl -b -1 -n 100 -r

このように、闇雲に grep をかけるのではなく、「時間」「サービス」「重大度」という3つの軸でクエリを絞り込むことで、最短ルートで原因（真実）に到達できるのです。

---

総まとめ：真実を導き出すクエリの力

第7回「システムログの確認とトラブルシューティング」、いかがだったでしょうか。
かつてのブラックボックスだったテキストログの海は、systemd-journald の登場により、美しく構造化されたデータベースへと進化しました。

• -u と -p： サービス名と重大度でログを抽出し、ノイズを極限まで減らす。
• --since と -r： タイムトラベル検索と逆順表示で、障害発生時刻のログを瞬時に炙り出す。
• /var/log/journal/： ログの永続化設定を行い、再起動による証拠隠滅を防ぐ。
• --vacuum-size： ログの肥大化による二次災害（ディスク枯渇）を防ぐ。

これらの journalctl のテクニックを身につければ、どんな難解なシステム障害であっても、必ず原因を示す「ログという名の証拠」を見つけ出し、論理的に解決に導くことができるでしょう。

次回、いよいよ連載の最終回である第8回は「アーカイブとバックアップ戦略（tar / gzip）」です。システムを修復不可能な状態に追い込まないための最後の命綱、データの安全な退避と圧縮技術について解説します。有終の美を飾りましょう。お楽しみに！リナックス先生でした！