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 でログローテーションを制御する方法がわかる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
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 |
システム全般のログが集約されているため、「何かおかしい」と感じたときの最初の確認先になります。
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
・
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
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
「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"
2. cron の実行結果を確認する
cron が期待通りに動いているかどうかは /var/log/cron で確認できます。# 直近のcron実行を確認 tail -50 /var/log/cron # または journalctl で journalctl -u crond --since today # 特定スクリプトのログを絞り込む grep "backup.sh" /var/log/cron
ただし、スクリプト内部のエラーは別途ログファイルに出力するか、
メール通知設定(MAILTO)を使う必要があります。
3. カーネルメッセージの確認
ハードウェア障害(ディスクエラーなど)はカーネルが最初にログに残します。# dmesg でカーネルメッセージを確認(直近のもの) dmesg | tail -30 # エラー・警告だけ抽出 dmesg -l err,warn # タイムスタンプ付きで表示(カーネル起動時刻からの経過秒) dmesg -T | grep -i "error\|fail\|warn" | tail -20
早急に 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
複数サーバーのログを一元管理するときにも応用できます。
本記事のまとめ
| やりたいこと | コマンド |
|---|---|
| リアルタイムでシステムログを確認 | 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でファイルシステムを作成する方法で詳しく解説しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒/合わなければ解除3秒 / 詳細はこちら
