「grepで調べたいけど、量が多すぎてどこに何が書いてあるのか全然見当がつかない」
Linuxサーバーのトラブル対応で、まず手をつけるべき作業はログの調査です。しかし、/var/log/ 配下のファイルの種類や、効率的な検索方法を体系的に把握していないと、時間だけが過ぎていきます。
この記事では、Linuxログの調査に必要な知識を一通り解説します。主要ログファイルの役割と読み方、grep や journalctl を使った効率的な検索テクニック、日時範囲での絞り込み方法、そして「ログが出ない」「ファイルが肥大化している」といった現場でよく遭遇するトラブルの対処まで、具体的なコマンド例を交えて説明します。
この記事のポイント
・/var/log/ 配下の主要ログファイルの役割と使い分けを解説
・grep -i や zgrep でログを効率的に検索するテクニック
・journalctl --since/--until で日時範囲を絞り込む方法
・「ログが出ない」「肥大化」等のトラブルシュート手順
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
Linuxのログファイルはどこにあるのか?
Linuxのシステムログは、原則として/var/log/ ディレクトリ配下に保存されています。サーバーで何か問題が起きたとき、まず確認すべき場所です。ログファイルの各行は、基本的に以下の4つの要素で構成されています。
・日時:ログが記録された日付と時刻
・ホスト名:ログを出力したサーバーの名前
・メッセージ出力元:ログを出力したプログラム名やプロセスID
・メッセージ:実際のログ内容
実際のサーバーで
/var/log/messages を確認すると、以下のように出力されます。Jun 29 17:38:11 Tiger shutdown[30243]: shutting down for system halt
ログを読み解くのが難しく感じる方でも、この「日時・ホスト名・出力元・メッセージ」の4要素を意識するだけで、格段に読みやすくなります。
主要ログファイル一覧
/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サーバー)のログ | アクセス解析・エラー調査 |
※ディストリビューションによって名前が異なる場合があります。例えば、Ubuntu/Debianでは
/var/log/messages の代わりに /var/log/syslog が使われます。grepでログを検索する基本テクニック
ログファイルの調査で最も頻繁に使うのがgrep コマンドです。大量のログの中から、目的のメッセージだけを抽出できます。1. 特定のキーワードでログを検索する
最も基本的な使い方は、キーワードを指定してログファイルを検索することです。実際のサーバーで
/var/log/messages から「shutdown」を含む行を抽出した例です。# grep shutdown /var/log/messages Jun 28 23:36:33 Tiger shutdown[3341]: shutting down for system halt Jun 29 03:10:39 Tiger shutdown[10217]: shutting down for system reboot Jun 29 03:29:37 Tiger shutdown[3142]: shutting down for system halt Jun 29 16:00:55 Tiger shutdown[2492]: shutting down for system reboot Jun 29 16:08:08 Tiger shutdown[2615]: shutting down for system halt
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 をリアルタイム監視する [root@Tiger log]# 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接続の失敗ログを確認した例です。
[root@Tiger log]# tail /var/log/secure Jul 15 15:00:53 Tiger sshd[10051]: Failed password for pakira from 192.168.1.97 port 51449 ssh2
外部から不審なログイン試行が繰り返されている場合は、以下のように件数を確認します。
# SSH接続失敗の件数を確認する # grep -c "Failed password" /var/log/secure
lastlog でユーザーの最終ログイン日時を確認する
lastlog コマンドは、システム上の全ユーザーの最終ログイン日時を一覧表示します。どのユーザーがいつログインしたかを把握でき、セキュリティ確認や不審なアカウントの発見に役立ちます。[root@Tiger log]# lastlog ユーザ名 ポート 場所 最近のログイン root tty1 水 6月 30 14:06:21 +0900 2010 bin **一度もログインはありません** daemon **一度もログインはありません** adm **一度もログインはありません** lp **一度もログインはありません** (中略) pakira pts/0 192.168.1.97 木 7月 15 13:35:23 +0900 2010 postgres **一度もログインはありません** mysql **一度もログインはありません** [root@Tiger log]#
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 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 run-parts(/etc/cron.hourly)[3715]: starting 0anacron Nov 14 12:01:03 Tiger anacron[3731]: Will run job `cron.daily' in 15 min.
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. cronログをjournalctlで確認する(Ubuntu系)
Ubuntu 24.04 LTSではデフォルトで/var/log/cron ファイルが存在しません。cronのログを確認するには journalctl が主要な確認手段になります。RHEL系とはサービス名(unit名)が異なる点に注意してください。# RHEL系(crond) # journalctl -u crond # Ubuntu系(cron) # journalctl -u cron # 今日のcronログだけを表示する # journalctl -u crond --since today Apr 05 03:00:01 server01 CROND[1789]: (root) CMD (/usr/local/bin/backup.sh) # リアルタイム監視する # journalctl -u crond -f
journalctlコマンドでsystemdジャーナルを調査する
RHEL 7 / CentOS 7 以降のsystemd環境では、多くのサービスのログがテキストファイルではなく、systemdのジャーナル(バイナリ形式)に記録されます。このジャーナルを検索するのがjournalctl コマンドです。1. 基本的な使い方
# システム全体のジャーナルを表示する # journalctl # 末尾からリアルタイム監視する(tail -f と同等) # journalctl -f # 特定のサービスのログだけを表示する # journalctl -u httpd # エラー以上の優先度のログだけを表示する # journalctl -p err
2. 日時範囲を指定して絞り込む(--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
テキストログの日時範囲を絞り込む方法
/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
【注意】ログファイルの閲覧には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のrsyslog設定を確認する(cronログが出ない場合) # grep cron /etc/rsyslog.conf cron.* /var/log/cron
cron.* の行がコメントアウトされていると、/var/log/cron にログが出力されません。コメントを外して rsyslog を再起動してください(systemctl restart rsyslog)。なお Ubuntu はデフォルトで /var/log/cron を作成しないため、/etc/rsyslog.d/50-default.conf に cron.* /var/log/cron.log を追加して rsyslog を再起動します。・cronデーモンが停止している:cronデーモン(crond)が動作していなければ、ジョブもログも出力されません。
systemctl status crond(Ubuntuは cron)で稼働状況を確認してください・systemd ジャーナルに出力されている:systemd管理のサービスは、テキストファイルではなくジャーナルにログを記録します。
journalctl -u サービス名 で確認してください・ログの出力先が別のファイルに設定されている:Apacheなどのアプリケーションは、独自の設定ファイルでログ出力先を指定しています。サービスの設定を確認してください
「ログが肥大化している」場合
ログファイルが数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.
本記事のまとめ
| やりたいこと | コマンド |
|---|---|
| システムログを確認する | 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 |
| 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 |
ログの読み方を体系的に学びたいと思いませんか?
ログの調査は、Linuxサーバー管理の中でも特に実務に直結するスキルです。
ネットの断片的な情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
journalctlで時間範囲・サービス別にログを絞り込む方法
journalctl(systemdの統合ログ閲覧コマンド)を使うと、systemd配下で動くサービスのログを一元的に確認できます。/var/log/messagesを目視で追うよりも、時間範囲やサービス単位で素早く絞り込めるのが大きな利点です。まずは基本となるオプションを覚えてください。-uでサービス名(unit)を指定し、--since・--untilで期間を指定するのが定番の組み合わせです。
下記の例では、sshdサービスのログを直近1時間分だけ抽出しています。トラブル発生時刻が分かっている場合は、--sinceに日付と時刻を直接渡しましょう。
# sshdサービスの直近1時間のログを表示 journalctl -u sshd --since "1 hour ago" # 日時を指定して範囲抽出 (24時間表記) journalctl -u nginx --since "2026-05-27 09:00:00" --until "2026-05-27 10:30:00"
・-f を付けるとtail -fのようにリアルタイム追跡できます
・-p err でエラー以上の重要度(priority)だけに絞り込めます
・-b は直近の起動以降のログのみを対象にします
これらを組み合わせれば、膨大なログから必要な情報だけを短時間で抜き出せます。
/var/log/messagesと/var/log/secureの使い分け
RHEL系(Red Hat Enterprise Linux系)のディストリビューションでは、/var/log/messagesと/var/log/secureが代表的なテキストログです。役割が明確に分かれているので、調査内容に応じて見るファイルを切り替えてください。
・/var/log/messages:システム全体の一般的なログ。カーネル、cron、各種デーモンの動作状況や警告が記録されます
・/var/log/secure:認証関連(authentication)のログ専用。sshログイン成功・失敗、sudo実行、suの利用履歴などが残ります
不正アクセスの形跡を追う場合は/var/log/secure、サービスの起動失敗や原因不明の異常を追う場合は/var/log/messagesから確認しましょう。
# sshのログイン失敗を抽出 grep "Failed password" /var/log/secure # 直近のカーネル関連の警告を確認 grep -i "kernel" /var/log/messages | tail -n 20
なおDebian/Ubuntu系では/var/log/syslogと/var/log/auth.logが同等の役割を持ちます。ディストリビューションによってファイル名が違うことを意識しておいてください。
dmesgでカーネルログを確認する実例
dmesgはカーネルリングバッファ(kernel ring buffer:カーネルが内部に保持する一時的なログ領域)の内容を表示するコマンドです。デバイスの認識状況、ディスクのI/Oエラー、OOM Killer(メモリ不足時にプロセスを強制終了する仕組み)の発動など、ハードウェアやカーネルレベルの事象を調べたいときに使ってください。
そのまま実行すると大量に出力されるので、オプションで絞り込むのが実用的です。-Tで人間が読める時刻表記に変換し、grepで関連キーワードを抽出するのが定番です。
# USB接続やディスク認識を時刻付きで確認 dmesg -T | grep -iE "usb|sda|sdb" # メモリ不足によるプロセス強制終了の痕跡を探す dmesg -T | grep -i "out of memory"
・-w を付けるとjournalctl -fと同様にリアルタイム追跡が可能です
・-l err でエラーレベルだけを抽出できます
・systemd採用環境では journalctl -k でも同じ内容を確認できます
サーバーが急に不安定になった、外付けデバイスが認識されないといった場面では、まずdmesgを実行する習慣を付けておきましょう。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒/合わなければ解除3秒 / 詳細はこちら
- 次のページへ:digコマンドでDNSを調査する方法|AレコードからDNSSECまで実務で使う引き方
- 前のページへ:e2fsck|ext2/ext3ファイルシステム検査コマンドの使い方とオプション一覧
- この記事の属するカテゴリ:Linuxコマンドへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます