ここまでのLinux中級講座では、 ユーザー・グループ管理、プロセス、サービス、ログ、 パッケージ、ディスク、ネットワーク、cronなど、 Linuxサーバを運用するためのさまざまな操作を学習してきました。
しかし実際の運用では、 コマンドを知っているだけではなく、 「障害が発生したときに、どこに問題があるのかを調べる」 力が必要になります。
CPU・Memory・Disk・Process・Service・Networkの どこに原因があるのか分かりません。
そこで重要になるのが、 障害の切り分けです。
この記事ではLinux中級講座の最終レッスンとして、 これまで学習したコマンドを組み合わせながら、 Linux障害発生時の基本的な切り分け方法 を学習します。
Linuxで障害が発生したときに、 思いついたコマンドを闇雲に実行するのではなく、 「症状から原因候補を考え、確認結果を使って 障害範囲を狭めていく」 基本的なトラブルシューティングの考え方を身につけます。
Linux障害では「切り分け」が重要
たとえば、 「Webサイトにつながらない」 という障害が発生したとします。
原因として考えられるものは1つではありません。
CPU・Memoryが逼迫している
ディスク容量が不足している
Webサービスが停止している
IPやRoutingに問題がある
設定やアプリケーションに問題がある
トラブルシューティングでは、 確認結果から「正常な範囲」と「異常な範囲」を分ける ことが重要です。
障害対応の基本的な流れ
障害の種類によって確認する内容は異なりますが、 基本的な考え方は共通しています。
STEP1：まず症状を正確に確認する
障害が発生したとき、 いきなりコマンドを実行する前に 何が起きているのかを整理します。
たとえば、
WebサービスやPortなどを疑いやすい
NetworkやOS全体まで調査範囲が広がる
同じ「つながらない」でも、 確認すべき場所は大きく異なります。
障害発生前後の「変更」を確認する
障害が突然発生した場合、 直前に何か変更されていないか を確認することも重要です。
このような場合、 直前の設定変更は重要な原因候補になります。
変更内容は有力な情報ですが、 実際の状態やログも確認して 仮説が正しいか判断します。
STEP2：CPU・メモリなどのリソースを確認する
「サーバ全体が遅い」 「処理が終わらない」 といった障害では、 CPUやメモリを確認します。
top
$ top
top - 14:21:03 up 25 days
%Cpu(s): 92.1 us, 3.2 sy, 4.7 id
MiB Mem :
7976.0 total
215.4 free
6842.2 used
918.4 buff/cacheCPU使用率が高いことが分かったら、 次は どのプロセスがCPUを使用しているのか を確認します。
ps aux --sort=-%cpu | head
$ ps aux --sort=-%cpu | head
USER PID %CPU %MEM COMMAND
app 2481 91.2 18.4 java
mysql 1320 8.2 24.1 mysqld
root 842 0.3 0.2 sshdCPUが高いことは現象です。 そこから どのプロセスが原因なのか まで調査を進めます。
ディスク容量を確認する
ファイルを書き込めない、 ログ出力に失敗するなどの場合は ディスク容量も確認します。
df -h
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 50G 49G 1.0G 99% /
/dev/sdb1 100G 42G 58G 42% /data
この例では、
ルートファイルシステム
/
が99%使用されています。
次に どのディレクトリが容量を使用しているのか を確認します。
sudo du -h --max-depth=1 / | sort -hr
$ sudo du -h --max-depth=1 / | sort -hr
49G /
31G /var
8.0G /usr
4.2G /home
1.1G /opt
/var
が大きいことが分かったので、
さらに範囲を絞ります。
sudo du -h --max-depth=1 /var | sort -hr
障害調査では、 広い範囲から徐々に狭い範囲へ 調べていくことが重要です。
STEP3：サービスの状態を確認する
Webサイトなど特定のサービスだけ利用できない場合は、 まずサービス状態を確認します。
systemctl status nginx
$ systemctl status nginx
● nginx.service - nginx web server
Loaded: loaded
Active: failed (Result: exit-code)これで nginxが正常に起動していない ことは分かりました。
ただし、 まだ停止した原因は分かっていません。
では、なぜ停止したのでしょうか？
次にログを確認します。
STEP4：ログから原因を調べる
systemdで管理されているサービスなら、
journalctl
を利用してログを確認できます。
journalctl -u nginx -n 50
$ journalctl -u nginx -n 50
nginx[1420]: bind() to 0.0.0.0:80 failed
nginx[1420]: address already in use
systemd[1]: nginx.service: Failed with result 'exit-code'address already in use
80番ポートがすでに使用されている
ログから、 80番ポートの競合が原因候補だと分かりました。
そこで次は、 80番ポートを使用しているプロセスを確認します。
sudo ss -lntp
$ sudo ss -lntp
State Local Address:Port Process
LISTEN 0.0.0.0:22 sshd
LISTEN 0.0.0.0:80 httpd
systemctl → journalctl → ss
のように、確認結果を根拠にして次の調査へ進めます。
STEP5：通信できない場合はネットワークを切り分ける
Linuxサーバから通信できない場合は、 ネットワーク状態を順番に確認します。
ip addr
ip route
ping
ss
getent / dig
IPアドレスを確認する
ip addr
想定したIPアドレスが ネットワークインターフェースへ設定されているか確認します。
ルーティングを確認する
ip route
$ ip route
default via 192.168.10.1 dev ens160
192.168.10.0/24 dev ens160 proto kernel scope linkデフォルトゲートウェイなど、 宛先へ通信するための経路を確認します。
pingで疎通を確認する
ping -c 4 192.168.10.1
ネットワークでは、 近い場所から確認すると障害範囲を絞りやすくなります。
pingはIPレベルの到達性を確認する材料です。 Webサービスなどを確認する場合は、 PortやService状態も確認します。
IPでは通信できるのにホスト名では失敗する場合
この場合、 IPレベルの通信そのものより 名前解決 を疑いやすくなります。
getent hosts server.example.com
DNSを詳しく確認したい場合は、
環境に応じて
dig
なども利用できます。
障害発生時の「とりあえず再起動」に注意
再起動によって一時的に復旧する場合はあります。
しかし、 すぐに再起動すると 障害発生時のプロセス状態や一時的な情報が失われる 可能性があります。
CPU・Memory状態
Process状態
Service状態
Log・Error
Network状態
緊急時には復旧を優先することもあります。 その場合でも可能な範囲で状態やログを記録してから対応すると、 後から原因を調査しやすくなります。
ここで実際に試してみよう：Linux障害切り分けシミュレーター
ここからは、 Linux中級で学習してきたコマンドを使って 障害原因を調査してみましょう。
Linux Troubleshooting Console
どこに問題がありそうですか？
1つの結果だけでなく、複数の確認結果を組み合わせて原因を考えます。
理解度チェック：次に何を確認する？
$ systemctl status nginx
● nginx.service
Active: failed (Result: exit-code)Webサイトへ接続できず、 nginxがfailedになっていました。 次の確認として最も適切なのはどれでしょうか？
「サービスが停止している」と分かったあとに、 何を知りたいか考えてみましょう。
Linux障害対応でよく使う確認コマンド
top
サーバ全体の負荷
ps
実行中プロセス
df -h
ファイルシステム使用率
du
容量を使用している場所
systemctl
サービス状態
journalctl
エラー・原因候補
ip addr
IP設定
ip route
ルーティング
ping
IP到達性
ss
待受ポート
getent / dig
名前解決
重要なのは「コマンド」より「確認する目的」
障害対応では、 コマンドをたくさん暗記することそのものが目的ではありません。
この考え方ができれば、 初めて遭遇する障害でも 次に何を確認すればよいか を考えられるようになります。
Linux障害切り分けで覚えておきたい3つの考え方
Server全体 → Service → Process → Logなど、 徐々に問題範囲を狭めます。
CPU使用率やping結果など、 1つの情報だけで原因を決めつけないことが重要です。
「ここまでは正常」と確認することで、 調査対象を少しずつ減らしていきます。
障害対応では調査結果を記録する
実際の運用では、 実行したコマンドや確認結果を記録しておくことも重要です。
Web接続不可
nginx failed
Port 80 conflict
httpdが使用
確認問題：Linux障害切り分けの基本を理解できたか確認しよう
Linuxサーバ全体の動作が非常に遅い場合、 最初の確認候補として適切なのはどれですか？
topではCPU・Memory・Processなど、 Server全体の負荷状況を確認できます。
systemctlでnginxがfailedになっていました。 次に行う確認として適切なのはどれですか？
systemctlで分かるのはServiceの状態です。 「なぜ停止したのか」を調べるためにログを確認します。
障害切り分けの考え方として最も適切なのはどれですか？
障害対応では、 確認結果を使って正常な範囲を確定し、 原因候補を少しずつ絞っていきます。
3問に挑戦してみましょう。
まとめ
Linux障害では 最初に症状と影響範囲を整理する
CPU・Memory・Disk・Service・Networkなど、 症状に合わせて確認対象を選ぶ
systemctlで状態を確認したら、
journalctlなどで
原因を調査する
Network障害では IP → Route → 疎通 → Port → DNS のように段階的に確認する
障害切り分けでは 正常な範囲を確定し、調査範囲を狭める ことが重要
コマンドを暗記するだけでなく 「何を確認したいのか」からコマンドを選ぶ
Linux中級講座はここまでです
ここまで、 ユーザー・グループ管理、所有者変更、プロセス、 Service、Log、Package、Disk、Network、cron、 障害切り分けまで学習してきました。
Linuxの基本コマンドを知る段階から、 「Serverで何が起きているのか」 「問題が起きたときにどこを確認すればよいのか」 を考えられるところまで Linuxの理解を広げてきました。
さらに実践的なLinuxスキルへ
ここから先は、 Shell Scriptによる自動化、 Linux Server構築、 Security、 より高度なTroubleshooting、 Container・Cloud環境など、 実践的なLinux学習へ進む段階です。
上級学習コンテンツについては、 現在より実践的に学習できる形を準備しています。
※ 上級コンテンツは現在準備中です。