この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
Linuxサーバーのトラブル対応で、こうした場面に何度も立ち会ってきました。
ログを読める人と読めない人の差は、知識の差ではありません。習慣の差です。この記事では、20年以上Linuxサーバーを運用してきた経験から、ログを「読める」エンジニアが日常的にやっていることを解説します。
この記事のポイント
・ログを「眺める」と「読む」は全く異なる行為である
・平常時のログを把握していない人は異常に気づけない
・「何を探すか」を決めてからログを開く習慣が大切
・ログは問題発生後ではなく、日常的に見るものだ
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
「ログを見ました」と言うが、実は眺めているだけの人が多い
私のセミナーで受講生に「障害が起きたらまず何をしますか」と聞くと、多くの人が「ログを見ます」と答えます。それ自体は正しい。でも続けて「ログを見て、何が分かりましたか」と聞くと、急に答えが詰まるのです。「たくさん文字が出ていて、よくわからなかった」
「ERRORという文字を探して、見つかったけど意味がわからなかった」
「とにかくスクロールしてみたんですが……」
これは「ログを眺めた」であって、「ログを読んだ」ではありません。受講生のせいではなく、ログをどう読むかを体系的に教わる機会がないまま現場に出てしまうことが多いのです。3,100名以上を指導してきた中で、これは一貫して感じてきたことです。
ログを「読める」人と「眺めるだけ」の人の具体的な違い
1. 「正常なログ」を知っているかどうか
ログを読める人は、平常時のサーバーがどんなログを出しているかを知っています。何も問題がない状態の/var/log/messagesや/var/log/secureがどんな内容かを、意識的に確認したことがある。だからこそ、異常なログが混ざった瞬間に「あれ、いつもと違う」と気づけるのです。眺めるだけの人は、ログをトラブルが起きた時しか開きません。基準がないまま大量の行を見ても、どれが異常でどれが正常かの判断ができません。大量の文字の海に溺れるだけになってしまいます。
私が現場でよく見かけるのが、「ログは何かあった時に見るもの」という思い込みです。これが最初の誤解です。ログは「日常的に読むもの」です。
2. 「何を探すか」を決めてから開くかどうか
ログを読める人は、ファイルを開く前に必ず「今回の問題に関係するのはどのログか」「何時頃から症状が出ているか」「何のプロセスが関係しているか」を考えてから開きます。例えばWebサービスが応答しなくなったなら、/var/log/httpd/error_logを時刻つきで追いながら、症状が出始めた時間帯のエラーメッセージを探す。SSHでログインできなくなったなら/var/log/secureを開いて認証失敗の連続がないかを確認する、という具合です。
眺めるだけの人は「とにかく全部見よう」とします。数万行あるログを上から順に読むのは非効率なだけでなく、本質的な問題を見逃すリスクもあります。
3. grepを「コマンド」ではなく「思考ツール」として使うかどうか
ログを読める人は、grepを使って「この時間帯のこのプロセスの出力だけを絞り込む」という操作を自然にやっています。例えば：# Jun 17以降のエラーだけを抽出 grep "Jun 17" /var/log/messages | grep -i "error\|failed\|denied" # sshdの認証失敗だけを絞り込む grep "sshd" /var/log/secure | grep "Failed" # 特定IPからのアクセスだけを追う grep "192.168.1.101" /var/log/httpd/access_log | tail -20
平常時のログを把握するための実践的な習慣
1. 週に1回、何もない時にログを開く
私がSE時代の先輩から教わったことのひとつが、「問題がない時こそサーバーのログを見ろ」という言葉です。最初は意味がわかりませんでした。トラブルもないのにログを見て何の意味があるのか、と。でも実際にやってみると、気づくことがたくさんありました。「このエラーメッセージ、毎週水曜の深夜に出ているな」「cronのジョブが失敗しているのに誰も気づいていなかった」「ディスク使用量の警告が数週間前から出始めていた」といった具合です。
問題が起きてから初めてログを見るのではなく、問題が起きる前にログを読む習慣があるエンジニアは、障害の芽を事前に摘み取れます。
2. ログの「場所」と「役割」を体系的に把握する
Linuxサーバーには多くのログファイルがありますが、まず以下の主要ログの役割を押さえておくと読むスピードが上がります。・/var/log/messages（またはsyslog）：システム全体のメッセージ
・/var/log/secure（またはauth.log）：認証関連のログ
・/var/log/httpd/（またはnginx/）：Webサーバーのアクセス・エラーログ
・/var/log/maillog：メールサーバーのログ
・journalctl：systemd管理のサービスログ（現代的な確認方法）
20年以上サーバーを運用してきた経験から言うと、「どのログにどんな情報が出るか」を体に染み込ませているかどうかが、障害対応の速度を大きく左右します。
3. 「調べた記録」をログに残す習慣を持つ
これは意外と知られていませんが、ログを読める人はログを読んだ記録も残しています。何かを調べた時に「特定の日付、/var/log/messagesでこのエラーを確認。原因はディスクフルだった」というメモを残しておくことで、次に同じエラーが出た時に即対応できます。私自身、過去に対応したエラーのメモをテキストファイルに蓄積してきました。5年後に同じエラーが出た時、過去のメモを見ながら10分で解決できた経験が何度もあります。
ログが読めると現場でどう変わるか
ログを読む習慣がついたエンジニアと、そうでないエンジニアの現場での違いは、障害対応の「落ち着き」に出ます。ログを読める人は、問題が起きても慌てません。「まずどのログを見るか」「何時頃からの変化を追うか」「どのプロセスが絡んでいるか」という順序が頭の中にあるからです。スムーズに手が動きます。
一方、ログを眺めるだけの人は、問題が起きると焦ってターミナルを開き、何となくlesで/var/log/messagesを開いて上から下に読み始めます。何をどう探せばいいかわからないまま、時間だけが過ぎていきます。
私のセミナーでは「障害対応の90%はログを読む力で決まる」という話をよくします。これは大げさではありません。ログには、サーバーが何を経験したかが全部書いてあります。それを読み解ける人とそうでない人では、同じ問題でも対応にかかる時間が文字通り桁違いになることがあります。
まとめ
| 観点 | 眺めるだけ | 読める |
|---|---|---|
| ログを開くタイミング | 問題が起きてから | 日常的に＋問題が起きた時 |
| 正常状態の把握 | していない | 意識的に確認している |
| ファイルを開く前に | 何も考えずに開く | 何を探すかを決めてから開く |
| grepの使い方 | ERRORを探すだけ | 時刻・プロセス・キーワードで絞り込む |
| 調査結果 | 記録しない | メモとして蓄積する |
今日から始められることはシンプルです。週に1回、何もトラブルがない時にサーバーのログを開いてみてください。「正常ってこういう状態なんだ」という基準が少しずつ積み上がっていきます。その積み上げが、次の障害対応を確実に変えます。
ログの読み方を体系的に身につけたい方には、Linuxネットワーク設定の実践解説やポート確認コマンドの使い方も合わせて参考にしてください。
「ログが読める」力を、体系的なLinux学習で身につけませんか？
ログを読む力はコマンドの知識があってこそ磨かれます。個別のトラブル対応を断片的に覚えるのではなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxエンジニアが古いサーバーを引き継いで学んだこと｜技術的負債と向き合う現役講師の経験談
- 前のページへ：Linuxのプロンプトをカスタマイズした日から作業ミスが減った話｜現役講師が語るターミナル環境と集中力の関係
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます