Linuxでサーバを運用していると、「あの時のログ、どこにいった?」と焦る場面に必ず遭遇します。
とくにsystemdが導入されてからは、従来の /var/log/messages に頼るだけでは不十分。そんなときに威力を発揮するのが journalctl です。
本記事では、journalctl の基本操作から、実務で役立つ活用例までを初心者向けにわかりやすく解説します。
よく使うjournalctlコマンド一覧
journalctlは使いこなすことで日々の運用監視やトラブルシュートを大幅に効率化できます。
しかし、オプションが豊富で最初は覚えきれないことも多いため、現場でよく使うjournalctlコマンドを整理して覚えておくことが重要です。
ここでは運用現場で即使えるjournalctlの代表的なコマンドと用途をわかりやすくまとめます。
コマンド | 用途 |
---|---|
journalctl | すべてのログを時系列で表示する |
journalctl -k | カーネル関連ログのみを表示する |
journalctl -f | リアルタイムでログを監視する |
journalctl -u sshd | 特定サービス(sshd)のログを表示する |
journalctl -b | 現在のブート時のログを表示する |
journalctl -b -1 | 前回ブート時のログを表示する |
journalctl --since "2025-07-01 00:00:00" | 指定日時以降のログを表示する |
journalctl -p err | エラーレベルのログのみを表示する |
これらのコマンドを使いこなすことで、特定サービスの障害解析やシステム全体のトラブル調査がスムーズになります。運用の中で繰り返し使いながら覚えていくことが大切です。
journalctlの概要と役
Linuxの運用管理においてログの確認と管理は非常に重要な作業の一つです。
サーバーの状態把握、トラブルシュート、パフォーマンス管理、セキュリティ管理など、あらゆる場面でログを適切に確認することが求められます。
systemd環境では、ログ管理のためのツールとしてjournalctlが標準搭載されており、従来のテキストログ管理よりも効率的にログを収集・検索できる仕組みを持っています。
journalctlはLinux初心者から実務レベルの運用者まで幅広く活用されているツールであり、基本操作を理解することは運用スキル向上に直結します。
ここではjournalctlの概要と役割について初心者でも理解できるようわかりやすく解説します。
journalctlでできること
journalctlはsystemdのジャーナルサービスによって記録されたログ情報を確認するためのツールです。
テキストエディタでファイルを直接開かなくても、コマンド操作のみでログを効率的に確認できることが大きな特徴です。
日々の運用でサービスが正常に起動しているか、トラブル発生時にどのようなエラーが出ているのかなどを即座に確認できるため、トラブル対応速度を飛躍的に高めることが可能です。
また、特定のサービスに関連するログだけを抽出したり、エラーレベルごとにログを絞り込んで確認したり、リアルタイムで新規発生するログを監視することも可能です。
これにより、不要な情報を取り除き必要な情報だけにフォーカスできる点が運用管理者にとって非常に有益です。
dmesgやログファイルとの違い
Linuxでログを確認する方法としてdmesgコマンドや/var/logディレクトリ内のログファイルを直接確認する方法がありますが、journalctlはこれらとは異なる特性を持っています。
dmesgはカーネルリングバッファ内に記録されているカーネルメッセージを表示するコマンドであり、主にカーネル関連のログ確認を行う際に利用されます。
しかし、dmesgは過去のログの長期保存には適しておらず、バッファが古いログで上書きされるため履歴確認用途には不向きです。
一方、/var/logディレクトリ内のログファイルはテキスト形式で管理されており、lessやgrepコマンドを使って中身を確認したり絞り込んだりする運用が一般的ですが、複数ファイルをまたぐ場合はgrepのパターンやファイル指定に慣れていないと効率が落ちることがあります。
journalctlはsystemdによって管理されるログをバイナリ形式で保管し、高速かつ柔軟に検索・絞り込みができることが最大の特徴です。
カーネルログだけでなく、サービス起動ログ、システムログ、ユーザーログなどをまとめて管理し、時系列順、サービス別、エラーレベル別など多様な切り口でログを閲覧できるため、トラブルシュートの効率が格段に向上します。
また、リアルタイムでログを監視しながらサービスの状態を確認することも可能であり、運用現場で非常に役立つツールです。
項目 | journalctl | dmesg | /var/log配下のログ |
---|---|---|---|
ログの対象 | システム全体+ユーザーサービスのログ | カーネルが出力したメッセージ | 個別サービスの専用ログ |
主な用途 | トラブル調査全般に最も使う | 起動直後のハードウェア状況やドライバ確認 | アプリやWeb、DBなどの専用ログ確認 |
ログの出力元 | systemd-journaldが集約 | カーネルリングバッファ | 各アプリが独自出力 |
永続性 | 設定による(/var/log/journal/ があれば永続) | 再起動で消える | ログローテーションされる |
使いやすさ | 時系列で統一表示・フィルタも可能 | 短くて扱いにくいが早く読める | 内容によるがgrepやtailで対応 |
ざっくり言うと
- journalctl = なんでも屋。まずこれで調べれば全体像がつかめる
- dmesg = 起動・ハードウェア系の速報。カーネルドライバ問題に使う
- /var/log/ = 専門職。nginxやpostgresのログなどはここで直接確認
journalctlの基本操作方法
journalctlはLinuxのsystemd環境で動作するログ管理ツールであり、トラブルシュート時や運用監視時に活用することで作業効率を大幅に向上できます。
journalctlの基本操作を理解することで、ログの取得、フィルタリング、リアルタイム監視などが容易となり、障害発生時の原因特定や平時の動作確認を迅速に進められるようになります。
ここではjournalctlの基本的な操作方法についてわかりやすく解説します。
ログの基本的な表示方法
journalctlを使うことで、システム全体のログを簡単に時系列で表示することが可能です。
ファイルを開いてスクロールする必要がなく、コマンドだけで効率よくログ内容を確認できます。
すべてのログを時系列で表示する方法
システム全体のすべてのログを時系列で確認する場合は以下のコマンドを使用します。
このコマンドは最新のログが下部に表示され、スペースキーでページ送り、qキーで終了することが可能です。
journalctl
システムの動作状況を把握する際や、何が起きているのかを広く確認したいときに活用できます。
カーネル関連ログだけを表示する方法
カーネル関連のログだけを確認したい場合は以下のコマンドを使用します。
カーネルの起動時メッセージやドライバの読み込み状況、ハードウェア認識状況を把握する際に便利です。
journalctl -k
dmesgと似ていますが、journalctlを使うことでカーネルログの履歴も含めて確認可能です。
リアルタイムでログを監視する方法
サービス起動時やトラブル対応時に、ログをリアルタイムで監視したい場合は以下のコマンドを使用します。
このコマンドはtail -fと同じように動作し、新規に発生するログをその場で確認できます。
journalctl -f
サービスの起動状況を追跡する際やエラー発生の瞬間を捉えたいときに活用できます。
日時や優先度でログを絞り込む方法
journalctlでは大量のログの中から必要な情報だけを効率よく抽出できます。
ここでは日時や優先度で絞り込む方法について説明します。
日時を指定して表示する方法
特定の日時以降のログだけを確認したい場合は以下のコマンドを使用します。
トラブルが発生した時間帯に絞り込むことで、不要なログを省きつつ迅速に状況把握が可能です。
journalctl --since "2025-07-01 00:00:00"
「--until」を使うことで終了時間を設定することも可能です。
journalctl --since "2025-07-01 00:00:00" --until "2025-07-01 12:00:00"
エラーレベルで表示を絞り込む方法
エラーレベルに絞り込んでログを確認したい場合は以下のコマンドを使用します。
journalctl -p err
「-p」の後に指定することで優先度を絞り込めます。errはエラーのみ表示する指定であり、warning、crit、alertなどを指定することも可能です。
特定のブート時のログを確認する方法
サーバーが再起動した際に、特定のブート時のログだけを確認したい場合は以下のコマンドを使用します。
journalctl -b -1
「-b」はブートを意味し、「-1」で前回の起動時のログを表示します。さらに「-2」とすることで二つ前の起動ログを確認することが可能です。
これにより、再起動前後で発生したエラーやサービスの挙動の違いを調査することができます。
トラブルシュートでのjournalctlの活用例
Linuxサーバーの運用においてトラブルシュートを行う際、原因調査のスピードと精度を高めるためにはログ確認が欠かせません。
journalctlを活用することで、サービスの起動失敗時の原因調査やシステム全体のエラー状況の把握を効率的に行うことが可能となります。
ここではjournalctlを使った実践的なトラブルシュート例を紹介し、実務で即活用できる知識を身につけることを目的とします。
サービス起動失敗時のログ確認方法
サービスが起動しない場合、原因特定の第一歩としてサービス単位でログを確認することが重要です。
systemd管理下でサービスが起動失敗する場合、journalctlを使うことで関連するログを効率的に抽出できます。
サービス単位でログを確認するには以下のコマンドを使用します。
journalctl -u サービス名
例えばSSHサービスが起動しない場合には以下のように実行します。
journalctl -u sshd
このコマンドによりsshdサービスに関連するすべてのログが時系列で表示されます。
サービス起動に失敗している場合、赤字でFailedなどのエラーが記録されている箇所が見つかることが多く、原因の切り分けに役立ちます。
また、ログの中で該当エラーが発生したタイミングを起点に周辺ログを確認することで、環境設定ミスや依存サービスの起動失敗など連鎖的な原因の把握も可能です。
さらに直近のログだけを確認したい場合には以下のように表示件数を制限することも可能です。
journalctl -u sshd -n 50
このコマンドはsshdサービスの直近50件のログのみを表示します。
障害発生直後の調査において最新のログだけを素早く確認したい場合に便利です。
サービスの起動失敗が確認できた場合は、ログに記載されたエラーメッセージや不足しているファイル、設定ミスの内容をもとに設定ファイルの修正や権限設定の見直し、依存サービスの起動確認を進めます。
システム全体のエラー調査の進め方
特定のサービスだけでなく、システム全体で発生しているエラーをまとめて把握することも重要です。
全体的なエラー状況を確認することで、ハードウェア障害やカーネル関連エラー、その他サービス間の依存エラーなどを把握できます。
システム全体のエラーログを確認する場合には以下のコマンドを使用します。
journalctl -p err -b
このコマンドは現在のブート時に発生したエラーレベル(err)のログのみを表示します。
さらに重大度の高いログだけを確認したい場合は以下のようにcriticalレベルで絞り込むことも可能です。
journalctl -p crit -b
エラー調査時には特定の日時を指定して調査する場合もあります。トラブルが発生した時間帯がわかっている場合には以下のコマンドを使います。
journalctl --since "2025-07-01 09:00:00" --until "2025-07-01 11:00:00" -p err
このコマンドにより指定時間内に発生したエラーログのみを抽出できます。
障害対応時にエラーが発生したタイミングをピンポイントで確認することができ、問題の特定や修正のスピードが向上します。
また、全体エラー調査の際には以下の点を意識してログを確認します。
ログ確認ポイント
- 繰り返し発生しているエラーの有無
- エラー発生前後のサービス停止や再起動履歴
- カーネル関連の警告やエラーが含まれていないか
- ストレージのエラーやマウント失敗の有無
これらを踏まえてログを読み取ることで、システム全体の安定運用に必要な改善ポイントを洗い出すことが可能となります。
まとめ
journalctlはLinuxのsystemd環境におけるログ管理ツールとして、運用監視とトラブルシュートを支える強力なツールです。
本記事ではjournalctlの概要から基本操作、トラブル対応での実践例まで解説しました。日常的にjournalctlを活用することで、障害の迅速な原因特定が可能になり、復旧時間の短縮や再発防止策の策定に繋がります。
日々の学習としては、以下の流れで使い慣れていくことをおすすめします。
- 普段からjournalctlでサービスの起動ログやシステムログを確認する習慣を持つ
- トラブル対応時にはjournalctlで対象サービスのログを即確認する
- 時系列確認、優先度指定、日時指定など複数のフィルタリングを活用する
ログの可視化と正確な情報収集はトラブルシュートにおいて重要なスキルのひとつです。
journalctlを積極的に活用し、日々の業務に役立ててください。Linux運用管理のスキルアップを図るためには、実際に使って覚えることが一番の近道です。
今後のトラブル対応だけでなく、セキュリティ監査やパフォーマンス改善、障害予防の一環としてもjournalctlの活用を進めていきましょう。