こんにちは、インフラエンジニアのryuです。
サーバーが動かない。画面が真っ白になった。設定を変えたのに反映されない。
そんなとき、あなたは何を最初に見るでしょうか。
未経験のうちは、つい「もう一回やってみる」「再起動してみる」と、手を動かしたくなります。その気持ちはよく分かります。でも、経験を積んだインフラエンジニアがまず開くのは、たいていログです。
ログとは、サーバーやアプリが「今こんなことが起きています」と書き残していく日記のようなものです。この日記を読めるかどうかで、原因にたどり着く速さがまるで変わります。
今日は、そのログをどう読むのか。場所・レベル・時系列という3つの切り口で、基礎から順に解説していきます。
そもそもログって何？なぜ最初に見るの？¶
ログを、宅配便の追跡履歴にたとえてみましょう。
荷物が届かないとき、あなたは配送業者の追跡ページを開きますよね。「◯時に営業所を出発」「◯時に配達を試みたが不在」——こう書いてあれば、荷物が今どこで止まっているかが一目で分かります。
ログもこれと同じです。サーバーは、起動したとき・リクエストを受けたとき・エラーが起きたときに、その事実を1行ずつファイルに書き残しています。だから「いつ・何が・どこで」起きたのかを、あとから追跡できるのです。
推測で原因を当てにいくと、当たることもありますが、外れると時間だけが溶けていきます。しかも、思い込みで見当違いの場所を触ってしまうと、元の問題に別の問題が重なって、状況がさらに複雑になります。ログは推測ではなく事実です。まず事実を確認してから動く。これがトラブル対応の基本姿勢です。
新人のうちは「ログを読む」と聞くと、なんだか難しそうで身構えてしまうかもしれません。でも安心してください。最初から全部を理解する必要はないのです。荷物の追跡ページを、私たちは配送システムの仕組みを知らなくても読めますよね。それと同じで、ログも「どこを見ればいいか」というポイントさえ押さえれば、初心者でも十分に手がかりをつかめます。大事なのは、身構えずに、まず開いてみることです。
障害が起きたときの切り分けの考え方そのものは、障害の切り分けを独学で鍛える方法でも詳しく書いています。ログの読み方は、その切り分けを支える一番の道具だと思ってください。
ログには「種類」がある¶
ひとくちにログと言っても、大きく分けると役割が違います。代表的なものを整理しておきましょう。
| ログの種類 | 何が書かれるか | 例 |
|---|---|---|
| システムログ | OS全体の動き・サービスの起動失敗など | Linuxの syslog / journal |
| アクセスログ | 誰がいつ何にアクセスしたか | Webサーバーへのリクエスト履歴 |
| エラーログ | 処理中に起きた異常・警告 | アプリが例外を吐いたときの記録 |
| 監査ログ | 誰が何を操作したか（追跡用） | クラウドの操作履歴 |
トラブルの種類によって、見るべきログは変わります。「サービスが起動しない」ならシステムログ、「特定のページだけ500エラー」ならWebサーバーのエラーログ、といった具合です。どのログを開くかを最初に見極めることが、遠回りしないコツです。病院で、症状に合った科を選ぶのと似ています。頭が痛いのに整形外科へ行っても原因は見つかりません。まずは「今の症状はどの種類の問題か」を考え、それに対応するログへ向かいましょう。
ログはどこにある？場所を知るのが第一歩¶
読み方の前に、まず「どこにあるか」です。ログは自分から出てきてはくれません。置き場所を知っている人だけが読めます。
Linuxのシステムログの置き場所¶
Linuxでは、伝統的にログは /var/log/ というディレクトリの下にまとまっています。ここを開けば、システムやサービスが残したファイルがずらりと並んでいます。
ただし、ディストリビューションによってファイル名が違う点に注意してください。
# Ubuntu / Debian 系のシステムログ
sudo tail -n 50 /var/log/syslog
# Red Hat / CentOS / Rocky 系のシステムログ
sudo tail -n 50 /var/log/messages
tail は、ファイルの末尾（＝一番新しい行）だけを表示するコマンドです。ログは下に追記されていくので、最新の出来事はいつも末尾にあります。「まず末尾を見る」と覚えておきましょう。
さらに、いま多くのLinuxは systemd という仕組みで動いていて、journald が構造化された形でログをまとめて保管しています。こちらは専用のコマンドで読みます。
# 直近のシステムログを新しい順に
journalctl -e
# 特定のサービス（例: nginx）のログだけを見る
sudo journalctl -u nginx
# エラー以上の深刻なログだけに絞る
sudo journalctl -p err
journalctl は、テキストファイルを直接開くのではなく、systemdが持つ記録を検索して見せてくれるツールです。-u でサービスを指定できるので、「このサービスの調子が悪い」というときに絶大な効果を発揮します。
こうしたコマンドの意味が分からなかったら、Linuxコマンドの基本を先に押さえておくと、ログ読みがぐっと楽になります。
Webサーバーのアクセスログ・エラーログ¶
Webサーバーのログも、多くは /var/log/ の下にあります。例えばApacheなら、アクセスログとエラーログが別々のファイルに分かれているのが一般的です。
Webサーバーでは、リクエストの記録（アクセスログ）と、処理中の異常の記録（エラーログ）が分かれている。「ページが表示されない」ならまずエラーログ、「アクセスが来ているか確かめたい」ならアクセスログ、と使い分ける。
「どのファイルがどのログか分からない」というときは、まずファイル一覧を眺めて、名前から当たりをつけます。ファイルを探すこと自体に慣れていないなら、findコマンドでのファイル検索も一緒に覚えておくと役立ちます。
クラウドの場合はどう見る？¶
オンプレミスのサーバーとは違い、クラウドではログを専用のサービスが集約しています。AWSなら、多くのログはCloudWatch Logsに集まります。ファイルを直接開くのではなく、コンソールやクエリで検索して読むスタイルです。
具体的な検索のやり方は、CloudWatchのクエリの使い方で手を動かしながら学べます。置き場所が「ファイル」から「サービス」に変わるだけで、「時系列に沿って事実を追う」という読み方の本質は同じです。
クラウドならではの利点もあります。ファイルだと、サーバーが増えるたびにログの置き場所も増えて、一台ずつログインして確認する手間がかかります。一方、集約サービスなら複数のサーバーのログを一か所で横断して検索できます。台数が多い現場ほど、この「集めて検索する」考え方が効いてきます。将来クラウドを扱うなら、ログは集約するもの、と頭の片隅に置いておくとよいでしょう。
ログの「読み方」——3つの視点で追う¶
場所が分かったら、いよいよ中身です。ログをただ眺めても、初心者には呪文の羅列にしか見えません。でも、次の3つの視点を持つと、読める景色が変わります。
視点1：レベル（深刻度）を見る¶
多くのログには、その行がどれくらい深刻かを示す「レベル」が付いています。これは syslog の仕様（RFC 5424）で8段階に決められていて、数字が小さいほど深刻です。
| 数字 | レベル | 意味（ざっくり） |
|---|---|---|
| 0 | Emergency | システムが使えない最悪の状態 |
| 1 | Alert | すぐ対処が必要 |
| 2 | Critical | 重大な問題 |
| 3 | Error | エラー（処理が失敗した） |
| 4 | Warning | 警告（今は動くが要注意） |
| 5 | Notice | 通常だが記録しておきたいこと |
| 6 | Informational | ただの情報 |
| 7 | Debug | 開発・調査用の細かい記録 |
トラブル対応では、まず ERROR や WARNING の行を探します。膨大なログの中から、深刻な行だけを拾い読みすれば、原因の近くに一気に近づけるからです。信号機で言えば、青（Info）は流し読みで構わない。赤（Error）で足を止める、というイメージです。
WARNING（警告）を軽く見ないことも大切です。警告は「今はまだ動いているけれど、このままだと危ないですよ」というサインであることが多いからです。ディスクの空き容量が少なくなってきた、証明書の期限が近い——こうした警告を見逃すと、後日それが本物のエラーに育ってしまいます。エラーが出てからではなく、警告のうちに気づける人が、頼れるインフラエンジニアです。
視点2：時系列（タイムスタンプ）を追う¶
ログの各行には、たいてい日時が付いています。ここがとても大事です。
トラブルは「ある時点」で始まります。だから、問題が起きた時刻の前後を集中的に読むのが鉄則です。「エラーが最初に出たのは何時何分か」「その直前に何が起きていたか」。この2つを押さえると、引き金になった出来事が浮かび上がってきます。
例えば「16:03にサービスが落ちた」なら、16:00〜16:05あたりだけを切り出して読みます。何万行もあるログを全部読む必要はありません。
ここでよくある落とし穴が、時刻のズレです。サーバーの時計が世界標準時（UTC）で動いていて、あなたの手元は日本時間、というのはよくある話です。ログの時刻と、あなたが「落ちた」と感じた時刻が9時間ずれていたら、いくら探しても見つかりません。ログを読むときは、その時刻がどのタイムゾーンで書かれているかを、最初に確認しておきましょう。
視点3：キーワードで絞り込む¶
とはいえ、目でスクロールして探すのは大変です。そこで grep の出番です。grep は、指定した文字を含む行だけを抜き出してくれるコマンドです。
# error という文字を含む行だけを大文字小文字を無視して抽出
grep -i error /var/log/syslog
# 特定の時刻や単語で絞る（例: 16:03 の行）
grep "16:03" /var/log/syslog
# journalctl の出力から絞り込むこともできる
sudo journalctl -u nginx | grep -i "failed"
grep を使いこなせると、ログ読みの速度が何倍にもなります。使い方に不安があれば、grepで文字を検索する方法で基本を固めておきましょう。
エラーメッセージが英語で出て意味が分からない、というのもよくあります。そんなときは自己流で解釈せず、そのメッセージをそのまま検索したり、公式ドキュメントで確認したりするのが近道です。調べ方のコツは公式ドキュメントの読み方にまとめています。
やりがちな失敗と、避けるコツ¶
最後に、初心者がログを読むときにつまずきやすいポイントを挙げておきます。
一つ目は、いきなり全部を読もうとすることです。ログは何万行にもなります。全部読むのではなく、「新しい行から」「エラーだけを」「問題が起きた時刻の前後だけ」と、対象をどんどん狭めていくのが正しい進め方です。最初から一字一句読もうとすると、それだけで気力が尽きてしまいます。ログ読みは、精読ではなく、絞り込みだと考えてください。
二つ目は、最初のエラー行を見落とすことです。エラーは連鎖します。一つの失敗が次の失敗を呼び、大量のエラーが並ぶことがあります。ドミノ倒しを思い浮かべてください。最後に倒れた派手な一枚に目を奪われがちですが、探すべきは最初に倒れた一枚です。このとき本当の原因は、たいてい一番上（＝一番古い）のエラーにあります。あわてて末尾のエラーに飛びつかず、「最初に何が壊れたか」までさかのぼって探しましょう。
三つ目は、ログを読む練習を後回しにすることです。ログは、トラブルが起きてから慌てて読もうとしても頭に入りません。ふだんから正常なログにも目を通しておくと、「いつもと違う」という違和感に気づけるようになります。健康診断と同じで、平常時の数値を知っているからこそ、異常に気づけるのです。
正常なログを「素振り」で見ておく¶
では、どうやって練習すればいいのでしょうか。おすすめは、自分の練習用サーバーで、わざと操作をしてログの動きを眺めてみることです。
例えば、サービスを再起動してみて、そのときシステムログに何が書かれるか。存在しないページにアクセスして、Webサーバーのエラーログにどんな行が増えるか。こうして「自分の操作」と「ログの変化」を結びつけて見ておくと、本番でトラブルが起きたときにも、ログの意味がすっと入ってきます。
journalctl -f や tail -f を使うと、ログが書き込まれる様子をリアルタイムで流し見できます。片方の画面でこれを開きながら、もう片方でサーバーを操作する。この素振りを何度かやっておくだけで、ログへの苦手意識はずいぶん薄れるはずです。
こうしたスキルは、Linuxの基礎からクラウドまで一本の道でつながっています。InfraAcademyのLinux学習ロードマップでは、コマンドの基礎からログを扱う場面までを順番に手を動かして学べるので、「ログが読める人」への最短ルートとして活用してください。
まとめ¶
今日は、ログの読み方の入門をお話ししました。振り返っておきましょう。
ログは、サーバーが残す事実の記録です。トラブルのときは、推測より先にログを開く。これが基本姿勢でした。
読むときの手順は、まず場所を知ること。Linuxなら /var/log/ や journalctl、クラウドなら集約サービスを見ます。そして中身は、レベル・時系列・キーワードという3つの視点で絞り込んで追いかける。全部を読むのではなく、対象を狭めていくのがコツでした。
最初は暗号のように見えるログも、読み方の型を知れば、少しずつ意味のある文章に見えてきます。原因はだいたい、ちゃんとログに書いてあります。
明日サーバーが不機嫌になったら、まずログを開いてみてください。その一歩が、あなたを一段たしかなインフラエンジニアにしてくれるはずです。
