「messagesやsecureの中身をgrepで探しても、量が多すぎて目的の情報にたどり着けない」
Linuxサーバーのトラブル対応で最初にやるべきことは、ログの調査です。しかし、ログファイルの種類や調査手法を体系的に理解していないと、無駄に時間を消費してしまいます。
この記事では、Linuxログの調査に必要な知識を網羅的に解説します。主要ログファイルの役割と読み方、
grep や journalctl を使った効率的な検索テクニック、日時範囲での絞り込み、さらに「ログが出力されない」「ログが肥大化している」「cronジョブが動いているか確認できない」といった現場で頻出するトラブルの対処法までをカバーしています。RHEL 9 / CentOS 7 / Rocky Linux 9 / Ubuntu 24.04 LTSで動作確認しています。
【この記事でわかること】
・/var/log/ 配下の主要ログファイルの役割と使い分けを解説
・grep -i / -C / zgrep でログを効率的に検索するテクニック
・journalctl --since/--until で日時範囲を絞り込む方法
・/var/log/cron でcronジョブの実行確認・REPLACE履歴の調べ方
・「ログが出ない」「肥大化」等のトラブルシュート手順
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
Linuxのログファイルはどこにあるのか？
Linuxのシステムログは、原則として/var/log/ ディレクトリ配下に保存されています。サーバーで何か問題が起きたとき、まず確認するのがこのディレクトリです。ログファイルの形式は、基本的に以下の4つの要素で構成されています。
・日時：ログが記録された日付と時刻
・ホスト名：ログを出力したサーバーの名前
・メッセージ出力元：ログを出力したプログラム名やプロセスID
・メッセージ：実際のログ内容
実際のサーバーで
/var/log/messages を確認すると、以下のように出力されます。Jun 29 17:38:11 Tiger shutdown[30243]: shutting down for system halt
主要ログファイル一覧
/var/log/ 配下には用途別に複数のログファイルが存在します。トラブルの種類に応じて、どのファイルを見ればいいかを把握しておくことが調査の第一歩です。| ログファイル | 記録内容 | 調査する場面 |
|---|---|---|
/var/log/messages |
システム全般のログ | サービス異常・カーネルメッセージ |
/var/log/secure |
認証関連のログ | SSH接続失敗・不正アクセス調査 |
/var/log/maillog |
メール送受信のログ | メール配信エラー・送信遅延 |
/var/log/cron |
cronジョブの実行ログ | 定期処理の実行確認・失敗調査 |
/var/log/boot.log |
OS起動時のログ | 起動時のサービス障害 |
/var/log/dmesg |
カーネルのリングバッファ | ハードウェア認識・ドライバ問題 |
/var/log/httpd/ |
Apache（Webサーバー）のログ | アクセス解析・エラー調査 |
/var/log/nginx/ |
nginx（Webサーバー）のログ | アクセス解析・エラー調査 |
/var/log/messages の代わりに /var/log/syslog が使われます。grepでログを検索する基本テクニック
ログファイルの調査で最も頻繁に使うのがgrep コマンドです。大量のログの中から、目的のメッセージだけを抽出できます。1. 特定のキーワードでログを検索する
最も基本的な使い方は、キーワードを指定してログファイルを検索することです。実際のサーバーで
/var/log/messages から「shutdown」を含む行を抽出した例を見てみましょう。# grep shutdown /var/log/messages Jun 29 17:38:11 Tiger shutdown[30243]: shutting down for system halt Jun 30 15:47:49 Tiger shutdown[3498]: shutting down for system reboot Jul 1 18:12:48 Tiger shutdown[3521]: shutting down for system halt Jul 2 10:52:09 Tiger shutdown[3618]: shutting down for system reboot Jul 2 14:26:12 Tiger shutdown[3727]: shutting down for system reboot
2. 大文字・小文字を区別せずに検索する（grep -i）
ログメッセージは大文字・小文字が混在していることが多いため、-i オプションで区別なく検索するのが安全です。# error/Error/ERROR を全て検索する # grep -i "error" /var/log/messages
3. マッチした行の前後を表示する（grep -A/-B/-C）
エラーの原因を調べるには、エラー行だけでなく前後の文脈も重要です。# エラー行の前後3行を表示する # grep -C 3 "error" /var/log/messages # エラー行の後5行を表示する（After） # grep -A 5 "error" /var/log/messages # エラー行の前5行を表示する（Before） # grep -B 5 "error" /var/log/messages
-C（前後両方）を使うのが最も実用的です。エラーの直前に何が起きていたかが分かるため、原因特定のスピードが上がります。4. マッチした件数だけを表示する（grep -c）
「エラーが何回発生しているか」を把握したい場合は-c オプションが便利です。# エラーの発生回数を数える # grep -c -i "error" /var/log/messages 42
5. 圧縮されたログファイルを検索する（zgrep）
logrotate によってローテーションされた古いログは .gz で圧縮されています。通常の grep では検索できませんが、zgrep を使えば圧縮ファイルのまま検索できます。# 圧縮されたログから検索する # zgrep "error" /var/log/messages-20260329.gz # 現在のログと圧縮ログを一括検索する # zgrep "error" /var/log/messages*
tail -f でログをリアルタイム監視する
ログファイルの調査には、過去のログを検索する方法と、リアルタイムで新しいログを監視する方法の2つがあります。リアルタイム監視には
tail -f コマンドを使います。# /var/log/messages をリアルタイム監視する # tail -f /var/log/messages
Ctrl + C を押してください。grep と組み合わせれば、特定のキーワードだけをリアルタイムに抽出することもできます。# ERROR を含む行だけをリアルタイム監視する # tail -f /var/log/messages | grep --line-buffered "ERROR"
--line-buffered を付けないと、grepのバッファリングにより表示が遅れることがあります。tail -f の詳しい使い方（-F オプションによるログローテーション対応、複数ファイルの同時監視、トラブルシュートなど）は、以下の記事で詳しく解説しています。→ tailコマンドでログ監視する方法｜tail -fの使い方やgrep連携も
/var/log/secure で認証ログを調査する
/var/log/secure には、SSH接続やsudo実行など、認証に関するログが記録されます。不正アクセスの調査やセキュリティ監査で必ず確認するファイルです。実際のサーバーでSSH接続の失敗ログを確認した例です。
# grep "Failed password" /var/log/secure Jul 13 07:04:30 pakira sshd[19854]: Failed password for root from 192.168.1.97 port 1060 ssh2
外部から不審なログイン試行が繰り返されている場合は、以下のように件数を確認します。
# SSH接続失敗の件数を確認する # grep -c "Failed password" /var/log/secure
lastlog でユーザーの最終ログイン日時を確認する
lastlog コマンドは、システム上の全ユーザーの最終ログイン日時を一覧表示します。# lastlog Username Port From Latest root pts/0 192.168.11.9 Mon Jul 13 07:35:54 +0900 2010 bin **Never logged in** daemon **Never logged in** adm **Never logged in** lp **Never logged in** ...（省略）... pakira pts/0 192.168.11.9 Mon Jul 12 18:40:03 +0900 2010
lastlog や last コマンドの詳しい使い方（特定ユーザーの絞り込み、lastb による失敗履歴の確認など）は、以下の記事で解説しています。→ lastコマンドでログイン履歴を確認する方法｜lastb・lastlogの使い分けも
/var/log/cron でcronジョブを調査する
「cronで設定したジョブが動いていない」という状況は、実務でもよく遭遇するトラブルです。cronはバックグラウンドで動作するため、ジョブの実行結果がターミナルに表示されることはありません。ジョブが実行されたかどうかを確認する手段はログのみです。RHEL系（CentOS、Rocky Linux、AlmaLinux）では、cronのログは
/var/log/cron に出力されます。1. cronログのフォーマットを理解する
cronログの各行は、以下の形式で記録されます。Nov 14 12:00:01 Tiger CROND[3692]: (root) CMD (/usr/lib64/sa/sa1 1 1)
・Nov 14 12:00:01：実行日時（月 日 時:分:秒）
・Tiger：ホスト名
・CROND[3692]：cronデーモンのプロセスID（PID）
・(root)：ジョブを実行したユーザー名
・CMD (...)：実際に実行されたコマンド
【注意】cronログには「コマンドが起動された」という記録だけが残ります。コマンドの実行結果（成功・失敗）やエラーメッセージはcronログには記録されません。ジョブの標準出力・標準エラー出力を確認するには、crontabの設定でリダイレクト先を指定しておく必要があります。
# crontab設定でログをリダイレクトする例 0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
2. cronログを確認する基本操作
まずは末尾の数行を確認するのが基本です。# tail /var/log/cron Nov 14 11:58:01 Tiger CROND[3132]: (pcp) CMD ( /usr/libexec/pcp/bin/pmie_check -C) Nov 14 12:00:01 Tiger CROND[3692]: (root) CMD (/usr/lib64/sa/sa1 1 1) Nov 14 12:00:01 Tiger CROND[3693]: (root) CMD (/usr/share/clamav/freshclam-sleep) Nov 14 12:01:02 Tiger CROND[3715]: (root) CMD (run-parts /etc/cron.hourly) Nov 14 12:01:02 Tiger CROND[3717]: (root) CMD (/var/www/system/snortsnarf.sh) Nov 14 12:01:02 Tiger run-parts(/etc/cron.hourly)[3715]: starting 0anacron Nov 14 12:01:03 Tiger anacron[3731]: Anacron started on 2017-11-14 Nov 14 12:01:03 Tiger anacron[3731]: Will run job `cron.daily' in 15 min. Nov 14 12:01:03 Tiger anacron[3731]: Will run job `cron.weekly' in 35 min. Nov 14 12:01:03 Tiger anacron[3731]: Will run job `cron.monthly' in 55 min. Nov 14 12:01:03 Tiger anacron[3731]: Jobs will be executed sequentially
tail -f /var/log/cron を使います。3. grepでcronログを絞り込む
cronログには大量のエントリが記録されるため、目的の情報を素早く見つけるにはgrep による絞り込みが欠かせません。# 特定のジョブで絞り込む # grep "backup.sh" /var/log/cron Apr 5 03:00:01 server01 CROND[12345]: (root) CMD (/usr/local/bin/backup.sh) # 特定のユーザーで絞り込む # grep "(webapp)" /var/log/cron Apr 5 01:00:01 server01 CROND[9876]: (webapp) CMD (/home/webapp/cleanup.sh) # 特定の時間帯で絞り込む # grep "Apr 5 03:" /var/log/cron Apr 5 03:00:01 server01 CROND[12345]: (root) CMD (/usr/local/bin/backup.sh)
4. crontabの編集履歴を確認する（REPLACE）
誰かがcrontabを編集した場合、ログに「REPLACE」というエントリが記録されます。本番環境でジョブが突然動かなくなった場合、まずREPLACEの履歴を確認するのが実務上の鉄則です。# grep "REPLACE" /var/log/cron Apr 4 15:32:10 server01 crontab[5678]: (admin) REPLACE (admin)
5. logrotateとcronログの世代管理
/var/log/cron は logrotate によって定期的にローテーションされます。過去のログを確認したい場合は、ローテーションされたファイルを参照する必要があります。# ls -la /var/log/cron* -rw-------. 1 root root 84523 Apr 5 12:01 /var/log/cron -rw-------. 1 root root 156234 Apr 4 03:22 /var/log/cron-20260404 -rw-------. 1 root root 148901 Mar 28 03:22 /var/log/cron-20260328 -rw-------. 1 root root 142567 Mar 21 03:22 /var/log/cron-20260321 # ワイルドカードで過去のログを一括検索する # grep "backup.sh" /var/log/cron* /var/log/cron:Apr 5 03:00:01 server01 CROND[12345]: (root) CMD (/usr/local/bin/backup.sh) /var/log/cron-20260404:Apr 4 03:00:01 server01 CROND[11234]: (root) CMD (/usr/local/bin/backup.sh)
/etc/logrotate.d/syslog で確認できます。journalctlコマンドでsystemdジャーナルを調査する
RHEL 7 / CentOS 7 以降のsystemd環境では、多くのサービスのログがテキストファイルではなく、systemdのジャーナル（バイナリ形式）に記録されます。このジャーナルを検索するのがjournalctl コマンドです。1. 基本的な使い方
# システム全体のジャーナルを表示する # journalctl # 末尾からリアルタイム監視する（tail -f と同等） # journalctl -f # 特定のサービスのログだけを表示する # journalctl -u httpd # エラー以上の優先度のログだけを表示する # journalctl -p err
2. cronデーモンのログをjournalctlで確認する
Ubuntu 24.04ではデフォルトで/var/log/cron ファイルが存在しません。cronのログを確認するには journalctl が主要な確認手段です。# RHEL系（crond） # journalctl -u crond # Ubuntu系（cron） # journalctl -u cron # 今日のcronログだけを表示する # journalctl -u crond --since today Apr 05 00:00:01 server01 CROND[1234]: (root) CMD (/usr/lib64/sa/sa1 1 1) Apr 05 01:00:01 server01 CROND[1456]: (root) CMD (run-parts /etc/cron.hourly) Apr 05 03:00:01 server01 CROND[1789]: (root) CMD (/usr/local/bin/backup.sh) # リアルタイム監視する # journalctl -u crond -f
3. 日時範囲を指定して絞り込む（--since / --until）
journalctl の強力な機能が、日時範囲の指定です。テキストファイルのログを awk や sed で日時抽出するのは手間がかかりますが、journalctl なら簡単に絞り込めます。# 今日のログだけを表示する # journalctl --since today # 特定の日時範囲を指定する # journalctl --since "2026-04-01 09:00" --until "2026-04-01 18:00" # 1時間前からのログを表示する # journalctl --since "1 hour ago" # 特定のサービスの今日のエラーだけを表示する # journalctl -u httpd -p err --since today
journalctl の詳しい使い方（出力フォーマットの変更、ディスク使用量の管理、永続化設定など）は、以下の記事で解説しています。→ journalctlコマンドの使い方
テキストログの日時範囲を絞り込む方法
/var/log/messages や /var/log/secure のようなテキスト形式のログファイルでは、journalctl の --since / --until は使えません。代わりに awk や sed を使って日時範囲を絞り込みます。1. awk で特定の日時のログを抽出する
# 4月1日のログだけを抽出する # awk '/^Apr 1/' /var/log/messages # 4月1日の10時台のログだけを抽出する # awk '/^Apr 1 10:/' /var/log/messages
2. sed で日時範囲を切り出す
# 4月1日 09:00 から 4月1日 18:00 までのログを切り出す # sed -n '/^Apr 1 09:00/,/^Apr 1 18:00/p' /var/log/messages
sed の範囲指定は「開始パターンにマッチした行～終了パターンにマッチした行」を出力します。該当する時刻のログが存在しないとマッチしないため、実際の出力状況に合わせてパターンを調整してください。【注意】ログファイルの閲覧にはroot権限が必要
/var/log/messages や /var/log/secure は、一般ユーザーでは読み取り権限がありません。ログの調査は sudo を付けるか、root ユーザーで実行してください。# 一般ユーザーで実行するとPermission deniedになる $ grep "error" /var/log/messages grep: /var/log/messages: Permission denied # sudo を付けて実行する $ sudo grep "error" /var/log/messages
ログ調査のトラブルシュート
「ログが出力されない」場合
以下の原因を順番に確認してください。・rsyslogが停止している：
/var/log/messages などのテキストログは rsyslog デーモンが書き込んでいます。停止していればログは出力されません# rsyslog の稼働状況を確認する # systemctl status rsyslog
/etc/rsyslog.conf の設定で、特定のファシリティ（ログの分類）が無効化されている可能性があります。例えば、cronログが出ない場合は以下を確認します# cronのrsyslog設定を確認する # grep cron /etc/rsyslog.conf cron.* /var/log/cron
/var/log/cron にログが出力されません。コメントを外して rsyslog を再起動してください。# systemctl restart rsyslog
# cronデーモンの稼働状況を確認する # systemctl status crond * crond.service - Command Scheduler Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled) Active: active (running) since Sat 2026-04-05 00:00:01 JST # 停止していた場合は起動する # systemctl start crond # systemctl enable crond
journalctl -u サービス名 で確認してください・ログの出力先が別のファイルに設定されている：Apacheなどのアプリケーションは、独自の設定ファイルでログ出力先を指定しています。サービスの設定を確認してください
なお、Ubuntuではデフォルトで
/var/log/cron ファイルが作成されません。cronのログを出力したい場合は以下のように rsyslog の設定を追加します。# /etc/rsyslog.d/50-default.conf に以下を追加 cron.* /var/log/cron.log # rsyslogを再起動 # systemctl restart rsyslog
「ログが肥大化している」場合
ログファイルが数GB以上に膨らんでディスクを圧迫している場合は、以下を確認します。・logrotate が正常に動作しているか確認する：
# logrotate の最終実行状態を確認する # cat /var/lib/logrotate/logrotate.status # logrotate をテスト実行する（実際にはローテーションしない） # logrotate -d /etc/logrotate.conf
# どのプログラムが最も多くログを出力しているか調べる # awk '{print $5}' /var/log/messages | sort | uniq -c | sort -rn | head -10
# ジャーナルのディスク使用量を表示する # journalctl --disk-usage Archived and active journals take up 1.2G in the file system.
→ logrotateでLinuxのログを自動ローテーションする方法
本記事のまとめ
| やりたいこと | コマンド |
|---|---|
| システムログを確認する | cat /var/log/messages |
| 認証ログを確認する | cat /var/log/secure |
| ログから特定キーワードを検索する | grep "キーワード" /var/log/messages |
| 大文字・小文字を区別せず検索する | grep -i "キーワード" /var/log/messages |
| マッチ行の前後を表示する | grep -C 3 "キーワード" /var/log/messages |
| 圧縮ログを検索する | zgrep "キーワード" /var/log/messages*.gz |
| ログをリアルタイム監視する | tail -f /var/log/messages |
| 最終ログイン日時を確認する | lastlog |
| cronジョブの実行を確認する | tail /var/log/cron |
| crontab編集履歴を確認する | grep "REPLACE" /var/log/cron |
| 過去のcronログを一括検索する | grep "スクリプト名" /var/log/cron* |
| systemdジャーナルを検索する | journalctl -u サービス名 |
| 日時範囲でジャーナルを絞り込む | journalctl --since "2026-04-01 09:00" --until "2026-04-01 18:00" |
| テキストログを日付で絞り込む | awk '/^Apr 1/' /var/log/messages |
| logrotateの状態を確認する | cat /var/lib/logrotate/logrotate.status |
「cronが動かない」「ログが出ない」と夜中に焦った経験はありませんか？
ログの読み方を知らなければ、原因の特定すらできません。しかし、ログの見方はLinuxサーバー管理の基本中の基本です。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。