こんにちは、Reoです。
現在、フリーランスのインフラエンジニアとして現場で働きながら、インフラ特化の学習サービス「InfraDojo（インフラ道場）」を運営しています。
普段はLinux・AWS・ネットワーク・自動化などを中心に、未経験からインフラエンジニアを目指す方や、新人エンジニア向けに学習方法・キャリアについて発信しています。
今回は、Linux初心者の頃に知っておきたかった、
「サーバーにつながらないと言われたら、何から確認すればいいのか？」
について解説します。
Linuxコマンドを勉強していると、
ping
curl
grep
ss
systemctl
journalctl
df
free
など、たくさんのコマンドが出てきます。
でも現場で重要なのは、
コマンドを知っていることではなく「どの場面で、何を確認するために使うのか」が分かること
です。
そこで今回は、
疎通確認
↓
ポート確認
↓
HTTP確認
↓
サービス確認
↓
ログ確認
↓
リソース確認
という流れで、障害対応の基本的な考え方を紹介します。
※実際の確認手順はシステム構成や障害内容によって異なります。この記事では、Linux初心者向けにWebサーバーを例として基本的な切り分け方を紹介します。
そもそも「サーバーにつながらない」だけでは原因は分からない
例えば利用者から、
Webサーバーにつながりません。
と連絡が来たとします。
初心者の頃は、
「サーバーが落ちている？」
と考えてしまうかもしれません。
しかし実際には、
- ネットワークに到達できない
- TCPポートに接続できない
- Webサーバーが停止している
- アプリケーションに問題がある
- DNSに問題がある
- ディスク容量が不足している
- メモリが不足している
- FirewallやSecurity Groupで遮断されている
など、さまざまな原因が考えられます。
だから障害対応では、
いきなり原因を当てにいくのではなく、正常なところと異常なところを一つずつ分ける
ことが重要です。
これが「切り分け」です。
STEP1：まず疎通を確認する
最初の確認としてよく使われるのがpingです。
ping 192.168.1.10
pingでは、主にICMPを利用して対象ホストとの疎通を確認できます。
例えば、
PC
↓
ネットワーク
↓
サーバー
という経路があったとき、対象サーバーから応答が返ってくるか確認します。
ただし、ここで重要なのが、
pingが通る = Webサービスも正常
ではないことです。
pingが通っても安心してはいけない
初心者の頃にありがちなのが、
ping 192.168.1.10
↓
応答あり
↓
「ネットワークは問題ありません！」
と判断してしまうことです。
しかし、pingで分かることには限界があります。
例えばWebサーバーなら、
サーバー自体には到達できる
↓
でも443番ポートは閉じている
という可能性があります。
つまり、
pingが通ることと、目的のサービスへ接続できることは別
です。
また、環境によってはICMPを意図的に遮断していることもあります。
そのため、pingだけで正常・異常を決めないことが大切です。
STEP2：目的のポートへ接続できるか確認する
次に確認したいのがポートです。
例えばHTTPSなら通常443番ポートを使用します。
ncを使うなら、
nc -vz example.com 443
などでTCP接続を確認できます。
ここで接続できれば、
少なくとも
接続元
↓
ネットワーク
↓
対象ホストの443/TCP
まで到達できている可能性が高くなります。
逆に接続できないなら、
- Firewall
- Security Group
- ルーティング
- サービスのListen状態
- 接続先IP・ポートの誤り
などを確認していきます。
STEP3：ssでListenしているポートを確認する
サーバー側へログインできるならssも使います。
ss -tlnp
例えばWebサーバーが443番ポートで待ち受けているなら、その状態を確認できます。
ここで、
443番でListenしていない
のであれば、
ネットワーク以前に、Webサーバー側が正しく起動していない可能性があります。
逆に、
443番でListenしている
のであれば、Firewallやネットワークなど別の場所へ調査範囲を広げられます。
障害対応では、
分かったことを一つずつ増やして、原因候補を減らしていく
ことが重要です。
STEP4：curlでHTTP/HTTPSの応答を見る
ポートまで問題なさそうなら、次はアプリケーションレイヤーを確認します。
Webサーバーならcurlが便利です。
curl -I https://example.com
例えば、
HTTP/2 200
が返ってくれば、HTTPレベルで正常に応答していることを確認できます。
一方、
500 Internal Server Error
なら、
「サーバーへ接続できない」
というより、
接続自体はできているが、サーバー内部でエラーが発生している
と考えられます。
この違いはかなり重要です。
例えば、
ping OK
↓
443/TCP OK
↓
HTTP 500
なら、ネットワークを延々と調査するより、Webサーバーやアプリケーションのログを確認する方が次の行動として自然です。
STEP5：systemctlでサービスの状態を確認する
WebサーバーがLinux上でsystemdサービスとして動いているなら、systemctlで状態を確認します。
例えばNginxなら、
systemctl status nginx
Apache系なら環境によって、
systemctl status httpd
などです。
ここで、
active (running)
なのか、
failed
なのかを確認します。
もしfailedになっていたら、
「なぜ停止したのか？」
を調べます。
そこで次に使うのがログです。
STEP6：journalctlでログを確認する
systemdで管理されているサービスなら、journalctlでログを確認できます。
Nginxなら、
journalctl -u nginx
直近のログを確認したいなら、
journalctl -u nginx -n 100
なども使えます。
ログの中に、
error
failed
denied
timeout
などがないか確認します。
大量のログから探す場合はgrepと組み合わせることもあります。
journalctl -u nginx | grep -i error
ここで重要なのは、
エラーメッセージを見つけた瞬間に、それを原因だと決めつけないこと
です。
エラーが発生した時刻。
障害が発生した時刻。
その直前に何が起きているか。
設定変更はなかったか。
なども合わせて確認します。
STEP7：df・freeでリソースを確認する
サービスやログだけで原因が分からなければ、サーバーのリソースも確認します。
ディスク容量
df -h
例えば、
/dev/xvda1 100%
となっていたら、ディスク容量不足によってログを書き込めなかったり、アプリケーションが正常に動作できなくなったりする可能性があります。
メモリ
free -h
メモリの利用状況を確認できます。
必要に応じて、
top
や
ps
などを使い、どのプロセスがリソースを使用しているのか確認していきます。
障害対応では「コマンドを打つ順番」に意味がある
ここまでを整理すると、例えばWebサーバーへ接続できない場合は、
1. ping
↓
ホストへの疎通は？
2. nc
↓
目的のTCPポートまで到達できる？
3. ss
↓
サーバー側でポートをListenしている？
4. curl
↓
HTTP/HTTPSでは何が返ってくる？
5. systemctl
↓
サービスは起動している？
6. journalctl
↓
エラーは出ている？
7. df / free
↓
リソースに問題はない？
というように確認できます。
もちろん実際の現場で、必ずこの順番になるわけではありません。
監視アラートやログなどから原因の見当がついていれば、必要な確認から始めることもあります。
大切なのは、
「とりあえず知っているコマンドを全部打つ」のではなく、何を確認するためにそのコマンドを実行するのか考えること
です。
初心者の頃はコマンドを丸暗記していた
自分もLinuxを勉強し始めた頃は、
ping = 疎通確認
grep = 検索
df = ディスク確認
free = メモリ確認
のように、コマンドと意味をセットで覚えていました。
もちろん最初はそれでもOKです。
ただ、実際の現場では、
Webサイトにつながらないので調べてください。
のように依頼されます。
そのとき、
「何のコマンドを使えばいいですか？」
とは教えてもらえません。
自分で、
そもそもホストへ到達できる？
↓
ポートは？
↓
HTTPの応答は？
↓
サービスは？
↓
ログは？
と考える必要があります。
ここが、
「Linuxコマンドを知っている」から「Linuxを使って問題を調査できる」へ進むポイント
だと思っています。
Linux学習では「答えを見ずに考える練習」を入れる
これからLinuxを勉強する人におすすめしたいのが、
問題形式で練習すること
です。
例えば、
/var/log/app.logからERRORを含む行を検索してください。
と言われたら、
すぐ答えを見るのではなく、
「何を使えばいい？」
と考えてみます。
そして、
grep "ERROR" /var/log/app.log
を自分で入力する。
次は、
nginxが起動しているか確認してください。
と言われたら、
systemctl status nginx
を考える。
こういう練習を繰り返すと、
コマンドを見る
↓
意味が分かる
だけではなく、
問題を見る
↓
必要な確認を考える
↓
コマンドを選ぶ
↓
実行する
という、実務に近い考え方を練習できます。
Linuxを実際に触って練習できる環境も作っています
ここまで紹介した内容は、読むだけで覚えるのはなかなか難しいです。
例えば、
grep
systemctl
journalctl
ss
df
free
をこの記事で知っても、実際に使わなければ数日後には忘れてしまうかもしれません。
自分自身、未経験の頃に一番成長したと感じたのも、教材を読む時間を増やしたときではなく、
実際にLinuxを触る時間を増やしたとき
でした。
そこで現在、未経験者やLinux初心者向けに「InfraDojo（インフラ道場）」という学習サービスを運営しています。
InfraDojoではブラウザ上のターミナルを使って、
問題を読む
↓
自分で考える
↓
Linuxコマンドを入力する
↓
結果を確認する
という形で学習できます。
Linuxの基本操作から、検索・ログ解析、権限、サービス管理などへ順番に進められるようにしています。
「Linuxコマンドは勉強しているけど、実際に自分で操作するとなると手が止まる」
という方は、アウトプット用の環境として使ってみてください。
▼ Linuxを実際に触って学ぶ
まとめ｜Linuxは「コマンド」ではなく「切り分け方」を覚える
今回は「サーバーにつながらない」というケースを例に、Linuxでの基本的な障害切り分けについて紹介しました。
初心者のうちは、
ping
nc
ss
curl
systemctl
journalctl
df
free
とコマンドを覚えるところから始めて大丈夫です。
ただ、少し慣れてきたら、
「このコマンドは何を確認するために使うのか？」
まで考えてみてください。
例えば、
疎通は？
↓
ポートは？
↓
HTTP応答は？
↓
サービスは？
↓
ログは？
↓
リソースは？
と一つずつ確認する。
これができるようになると、Linuxコマンドの暗記から一歩進んで、実際の障害対応につながっていきます。
最初から難しい障害を解決できる必要はありません。
まずは、
「何かおかしいときに、次に何を確認すればいいか」
を一つずつ増やしていきましょう。