Linuxのログファイルの種類と確認方法|/var/log配下の一覧とjournalctlの使い方


この記事の監修:宮崎智広(Linux教育歴15年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)【Linux入門】初心者のための基礎知識・講座 > Linuxのログファイルの種類と確認方法|/var/log配下の一覧とjournalctlの使い方
「/var/logを見ればサーバーの状態がわかる」とは聞くけど、ファイルが多すぎてどこを見ればいいかわからない。
journalctl は使えと言われたが、オプションが多くて途方に暮れている。

ログの読み方を知らないまま運用していると、障害が起きたときに原因を追えず、上司や顧客への報告が遅れます。

この記事では、/var/log配下の主要ログファイルの一覧と役割、syslog から rsyslog・journald への進化、journalctl の基本操作、そしてログローテーションの仕組みまで体系的に解説します。
RHEL 9 / Rocky Linux 9 / Ubuntu 24.04 LTS で動作確認済みです。

この記事のポイント

・/var/log配下の主要ファイルの役割を一覧で把握できる
・journalctl -xe / -b でリアルタイムの障害ログを確認できる
・syslog→rsyslog→journald の歴史的な変遷を理解できる
・logrotate.conf でログローテーションを制御する方法がわかる


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

Linuxのログとは何か?なぜ重要なのか

ログとは、Linuxシステムが自分の動作状況を記録し続けているファイルのことです。
サーバーが正常に動いているときは意識することはほぼありませんが、
障害・セキュリティインシデント・アプリケーションのバグが起きたとき、
ログなしでは原因を追うことが事実上不可能になります。

現場で「ログを見ろ」と言われても、どのファイルを、どうやって読めばよいか迷うのは当然です。
まずはログの全体像を把握するところから始めましょう。

1. ログが記録される2つの経路

Linuxのログには、記録される経路が2つあります。

アプリケーション独自のログ:Apacheの access_log、MySQLの slow.log など、ソフトウェア自身が書き込む
syslog / journald 経由のログ:カーネルやデーモンがシステムログとしてまとめて記録する

どちらも /var/log 配下に格納されるケースが多いですが、
systemd 環境(RHEL 8以降、Ubuntu 16.04以降)では journald がバイナリ形式で記録し、
journalctl コマンドで読み出す仕組みに移行しています。

/var/log配下の主要ログファイル一覧

以下は RHEL 9 / Rocky Linux 9 の標準ログファイルです。
ディストリビューションによってファイル名が若干異なる場合があります。
ファイルパス 主な記録内容 確認コマンド
/var/log/messages システム全般のメッセージ(RHEL/CentOS) tail -f /var/log/messages
/var/log/syslog システム全般のメッセージ(Ubuntu/Debian) tail -f /var/log/syslog
/var/log/secure 認証・SSH・sudo ログ(RHEL/CentOS) grep "Failed" /var/log/secure
/var/log/auth.log 認証・SSH・sudo ログ(Ubuntu/Debian) grep "Failed" /var/log/auth.log
/var/log/cron cron ジョブの実行ログ tail /var/log/cron
/var/log/boot.log 起動時のサービス起動ログ cat /var/log/boot.log
/var/log/dmesg カーネルリングバッファ(ハードウェア検出など) dmesg | tail
/var/log/httpd/access_log Apache のアクセスログ tail -f /var/log/httpd/access_log
/var/log/httpd/error_log Apache のエラーログ tail -f /var/log/httpd/error_log
/var/log/maillog メール送受信ログ tail /var/log/maillog
/var/log/audit/audit.log SELinux 監査ログ ausearch -m avc
実務ポイント: 最初に見るべきは /var/log/messages(RHEL系)または /var/log/syslog(Ubuntu系)です。
システム全般のログが集約されているため、「何かおかしい」と感じたときの最初の確認先になります。

syslog から rsyslog・journald への進化

Linuxのシステムログの仕組みは、長い年月をかけて進化してきました。
この歴史を理解すると、設定ファイルの場所や動作が腑に落ちます。

1. syslog(旧世代・現在は非推奨)

もともと Unix の時代から使われてきたログデーモンです。
設定ファイルは /etc/syslog.conf で、
ファシリティ(what)とレベル(severity)の組み合わせで記録先を振り分けていました。

現在の RHEL 8 以降では syslogd は標準インストールされておらず、
rsyslog または journald に置き換わっています。

2. rsyslog(現在の標準・テキスト形式)

syslog の後継として、2004年頃から登場した高機能版ログデーモンです。
設定ファイルは /etc/rsyslog.conf および /etc/rsyslog.d/*.conf です。

RHEL 8 / Rocky Linux 9 でも rsyslog がインストールされており、
/var/log/messages を生成しているのはこのデーモンです。

# rsyslog の設定確認 cat /etc/rsyslog.conf | grep -v "^#" | grep -v "^$" # rsyslog のサービス状態確認 systemctl status rsyslog

rsyslog.conf の主な設定書式は以下の形式です。

facility.level action(従来形式)
:msg, contains, "error" /var/log/error.log(フィルタ形式)

ファシリティの種類(代表的なもの):
kern:カーネルからのメッセージ
auth:認証関連
authpriv:プライベートな認証情報
cron:cron デーモン
daemon:各種デーモン
mail:メール関連
user:ユーザープロセス
*:全てのファシリティ

ログレベル(重要度の高い順):
emerg:緊急度の高い問題(システム停止レベル)
alert:早急に対処が必要
crit:致命的なエラー
err:通常のエラー
warning:警告
notice:注意喚起
info:情報
debug:デバッグ情報

3. journald(systemd 環境の現代的ログ)

systemd の登場(RHEL 7 / Ubuntu 16.04 以降)とともに、
systemd-journald がシステムログ管理の中心になりました。

journald の特徴:
バイナリ形式で記録:テキストではないため、直接 cat はできない
構造化データ:ユニット名・PID・優先度などのメタデータを持つ
過去ログへのアクセス:journalctl -b -1 で前回起動時のログを取得できる
揮発性デフォルト:再起動するとデフォルトでは消えるが、設定で永続化可能

journald のログを永続化するには、以下の設定が必要です。

# /var/log/journal/ ディレクトリを作成する(永続化) sudo mkdir -p /var/log/journal sudo systemd-tmpfiles --create --prefix /var/log/journal # または journald.conf で設定 sudo vi /etc/systemd/journald.conf # Storage=persistent を設定

journalctlコマンドの基本操作

journald のログは journalctl コマンドで読み出します。
最もよく使うオプションをまとめました。

1. 基本的なログ表示

# 全ログをページャーで表示(最新は末尾) journalctl # リアルタイムで新しいログを追いかける(tail -f 相当) journalctl -f # 最新50行を表示 journalctl -n 50 # エラー以上のログだけ表示 journalctl -p err # 今回の起動時のログ journalctl -b # 前回の起動時のログ(再起動直前のエラーを調べるときに便利) journalctl -b -1

2. 特定サービスのログを絞り込む

# sshd のログだけ表示 journalctl -u sshd # httpd のリアルタイムログ journalctl -u httpd -f # cron のログ(過去1時間) journalctl -u crond --since "1 hour ago"

3. 時間で絞り込む

# 今日の0:00以降のログ journalctl --since today # 特定の時間帯のログ journalctl --since "2026-04-07 10:00:00" --until "2026-04-07 11:00:00" # 昨日のログ journalctl --since yesterday --until today

4. 出力形式の変更

# JSON形式で出力(ログ解析ツールへの連携に使う) journalctl -o json-pretty -n 5 # 詳細なシステム情報とともにエラーを表示(障害調査の第一歩) journalctl -xe

実際のサーバーで journalctl -xe を実行すると、以下のような出力が得られます(IPはマスク):

Apr 07 10:23:14 web01.example.com sshd[3842]: Failed password for invalid user admin from 203.0.113.xx port 54321 ssh2 Apr 07 10:23:15 web01.example.com sshd[3843]: Failed password for invalid user admin from 203.0.113.xx port 54322 ssh2 Apr 07 10:23:16 web01.example.com sshd[3844]: Failed password for root from 203.0.113.xx port 54323 ssh2

このように SSH への不正ログイン試行を発見できます。
「Failed password」が短時間に大量発生している場合は、ブルートフォース攻撃の可能性があります。

ログローテーションの仕組み(logrotate)

ログを放置すると /var/log がディスクを食いつぶします。
これを防ぐのが logrotate です。RHEL 系では cron 経由で毎日自動実行されます。

1. logrotate の設定ファイル

/etc/logrotate.conf:グローバルなデフォルト設定
/etc/logrotate.d/:各パッケージが置く個別設定(Apache、rsyslog など)

# /etc/logrotate.conf の例(主要部分) weekly # 週次でローテーション rotate 4 # 4世代分保持 compress # 古いログを gzip 圧縮 dateext # 日付をファイル名に付ける(2026-04-07.gz 形式) missingok # ファイルがなくてもエラーにしない notifempty # 空ファイルはローテーションしない

2. ローテーション設定の実例(/var/log/httpd)

# /etc/logrotate.d/httpd /var/log/httpd/*log { weekly rotate 4 missingok notifempty sharedscripts delaycompress postrotate /bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true endscript }

3. 手動でローテーションを実行するには

# 設定のデバッグ(実際にはローテーションしない) sudo logrotate -d /etc/logrotate.conf # 強制的にローテーション実行(テスト用) sudo logrotate -f /etc/logrotate.conf # 特定のログだけ強制実行 sudo logrotate -f /etc/logrotate.d/httpd

ログ管理のトラブルシュートと実務Tips

1. ディスクが/var/logでいっぱいになった場合

# /var/log のディスク使用量を確認 du -sh /var/log/* # journald のディスク使用量を確認 journalctl --disk-usage # journald のログを手動削除(古いログを2週間分だけ残す) sudo journalctl --vacuum-time=2weeks # または容量ベースで削除(500MBまで) sudo journalctl --vacuum-size=500M

2. 「Permission denied」でログが読めない

/var/log/secure や /var/log/audit/audit.log は root 権限が必要です。

一般ユーザーで読むには:sudo less /var/log/secure
adm グループ:RHEL 系では adm グループに追加すると /var/log/messages は読める
journalctl の場合:sudo なしで読めるユーザーは systemd-journal グループに追加する

# 一般ユーザーを systemd-journal グループに追加(再ログイン後に有効) sudo usermod -aG systemd-journal username

3. ログが更新されない(rsyslog が停止している)

# rsyslog の状態確認 systemctl status rsyslog # 再起動 sudo systemctl restart rsyslog # 自動起動を有効に sudo systemctl enable rsyslog

4. SELinux の audit ログを読む

SELinux 関連の問題は /var/log/audit/audit.log に記録されます。
直接読むよりも ausearch / audit2why を使うほうが原因が分かりやすいです。

# AVC(アクセス拒否)ログのみ表示 ausearch -m avc -ts today # 拒否の理由を分かりやすく表示 ausearch -m avc -ts today | audit2why # ポリシーモジュールの自動生成(上級者向け) ausearch -m avc -ts today | audit2allow -M mymodule

ログ監視の実践:定期確認すべき項目

サーバーを運用していると、毎日確認すべきログの優先度が見えてきます。
以下は現場で実際に行っている日次・週次の確認内容です。

1. SSH 不正ログイン試行の監視

インターネットに公開しているサーバーには、毎日数十~数百件の不正アクセス試行が届きます。
放置すると気づかないうちに侵入されるリスクがあります。

# RHEL 系:SSH 不正試行を IP アドレスごとにカウント grep "Failed password" /var/log/secure | awk '{print $11}' | sort | uniq -c | sort -rn | head -20 # Ubuntu 系 grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn | head -20 # journalctl で絞り込む場合 journalctl -u sshd --since "24 hours ago" | grep "Failed password"

同一 IP から 10回以上試行があれば、fail2ban や firewalld での遮断を検討してください。

2. cron の実行結果を確認する

cron が期待通りに動いているかどうかは /var/log/cron で確認できます。

# 直近のcron実行を確認 tail -50 /var/log/cron # または journalctl で journalctl -u crond --since today # 特定スクリプトのログを絞り込む grep "backup.sh" /var/log/cron

「CMD」が記録されていれば正常に起動しています。
ただし、スクリプト内部のエラーは別途ログファイルに出力するか、
メール通知設定(MAILTO)を使う必要があります。

3. カーネルメッセージの確認

ハードウェア障害(ディスクエラーなど)はカーネルが最初にログに残します。

# dmesg でカーネルメッセージを確認(直近のもの) dmesg | tail -30 # エラー・警告だけ抽出 dmesg -l err,warn # タイムスタンプ付きで表示(カーネル起動時刻からの経過秒) dmesg -T | grep -i "error\|fail\|warn" | tail -20

「I/O error」や「SCSI error」が頻繁に出ていればディスク障害の前兆です。
早急に smartctl でディスクの健全性を確認してください。

4. logger コマンドで独自ログを書き込む

シェルスクリプトの実行結果をシステムログに統合したいときは logger コマンドが便利です。

# syslog に書き込む(ファシリティ:user、レベル:info) logger "バックアップ完了: $(date)" # ファシリティとレベルを指定 logger -p local0.info "デプロイ開始: v2.1.0" # スクリプト内での使い方例 if ./backup.sh; then logger -p local0.info "backup.sh 成功" else logger -p local0.err "backup.sh 失敗: exitcode=$?" fi

logger で書き込んだメッセージは journalctl や /var/log/messages に記録されます。
複数サーバーのログを一元管理するときにも応用できます。

本記事のまとめ

やりたいこと コマンド
リアルタイムでシステムログを確認 journalctl -f
エラー以上のログだけ表示 journalctl -p err
今回の起動時のログを確認 journalctl -b
特定サービスのログを確認 journalctl -u sshd -f
SSH 不正ログインを確認(RHEL系) grep "Failed" /var/log/secure
SSH 不正ログインを確認(Ubuntu系) grep "Failed" /var/log/auth.log
journald のディスク使用量を確認 journalctl --disk-usage
古いジャーナルを削除 journalctl --vacuum-time=2weeks
logrotate を手動実行 sudo logrotate -f /etc/logrotate.conf
SELinux の拒否ログを確認 ausearch -m avc -ts today
ログは「障害が起きてから必死に読むもの」ではなく、「日常的に眺めて異常の芽を摘むもの」です。
まずは journalctl -f を実行して、サーバーが今何を記録しているか確認してみてください。

ログの読み方は、最初のうちは「何が書いてあるかわからない」と感じるものです。
ですが、毎日少しずつ眺めているうちに、正常時のパターンが頭に入り、
異常が発生したときに「いつもと違う」と気づける感覚が育ってきます。

サーバー管理のプロが口をそろえて「ログを読め」と言うのは、
コマンドの暗記ではなく、この「パターン認識」を身につけてほしいからです。

まずは本番サーバーで journalctl -f を実行し、30分眺めてみてください。
そこから始まる発見が、あなたのLinuxスキルを確実に底上げします。

システムの起動プロセスについてさらに詳しく知りたい方は、Linuxのsystemdによる起動プロセスを理解するもあわせてご覧ください。
ディスク管理・ファイルシステムの操作については、Linuxでファイルシステムを作成する方法で詳しく解説しています。

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録

宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。