こんにちは、フルスタックエンジニアのryuです。
Linuxサーバーで障害が発生したとき、何から確認すれば良いのか分からなくなることはありませんか？
思いついたコマンドを片っ端から実行しても、原因を見つけるのは難しいです。
Linuxのトラブルシューティングでは、まず影響範囲を確認し、一つずつ切り分けることが大切です。
Linuxのトラブルシューティングは何から始める？¶
トラブルが起きたときに、いきなりサーバーを再起動するのはおすすめしません。
再起動によって一時的に直ることはありますが、原因を調査するために必要だった状態が分からなくなることもあります。
まずは、次の流れで考えてみましょう。
| 手順 | 確認すること |
|---|---|
| 1. 状況確認 | 何が使えないのか、いつから発生したのか |
| 2. 影響範囲確認 | 一部の機能だけか、システム全体か |
| 3. 原因の切り分け | プロセス、ログ、リソース、ネットワークなど |
| 4. 復旧 | サービス再起動、切り戻しなど |
| 5. 原因調査 | なぜ障害が発生したのか |
| 6. 再発防止 | 監視、設定、手順などを改善する |
会社によって手順は異なりますが、復旧と原因調査を分けて考えることが大切です。
まず障害の状況と影響範囲を確認する¶
障害が発生したら、最初に何が起きているのか整理します。
Webサイトへアクセスできない場合でも、原因はWebサーバーとは限りません。
まず次のような情報を確認します。
| 確認項目 | 具体例 |
|---|---|
| 発生時刻 | 10:25頃からアクセスできない |
| 対象 | Webサイト全体、特定画面だけ |
| 利用者 | 全ユーザー、一部ユーザー |
| 直前の変更 | デプロイ、設定変更、OS更新 |
| エラー内容 | 502、503、Connection refusedなど |
| 再現性 | 常に発生するか、断続的か |
発生時刻と直前の変更が分かると、ログや原因候補を絞りやすくなります。
Linuxサーバー自体が動いているか確認する¶
サーバーへSSH接続できる場合は、まずLinux自体の状態を確認します。
現在時刻や稼働時間を簡単に確認するなら、次のコマンドが使えます。
date
uptime
uptimeでは、サーバーがどれくらい連続稼働しているか、ロードアベレージがどの程度かを確認できます。
12:30:10 up 25 days, 3 users, load average: 0.15, 0.10, 0.08
障害直前に意図しない再起動が発生していないかを見る材料にもなります。
サービスやプロセスが動いているか確認する¶
Webサイトへアクセスできない場合は、NginxやApacheなど対象サービスが起動しているか確認します。
systemdを利用しているLinuxでは、次のように確認できます。
systemctl status nginx
Apacheであれば、環境に応じて次のようになります。
systemctl status apache2
サービスが停止している場合は、画面にエラーが表示されることがあります。
プロセス全体を確認したい場合はpsも使えます。
ps aux
特定のプロセスだけ確認するなら、次のように絞れます。
ps aux | grep nginx
サービスが起動しているか、異常終了していないかを最初に確認しましょう。
【関連記事】プロセスの確認方法は、psコマンドの使い方解説！Linuxのプロセスを確認する方法でも詳しく解説しています。
Linuxのログを確認する¶
ログには障害原因のヒントが残っている¶
トラブルシューティングで特に重要なのがログです。
エラーが発生した時刻の前後に何が起きていたのかを確認すると、原因を絞り込みやすくなります。
systemdで管理されているサービスであれば、journalctlを利用できます。
journalctl -u nginx
直近のログだけ見たい場合は、次のように確認できます。
journalctl -u nginx -n 50
発生時刻が分かっている場合は、時間を指定すると調査しやすくなります。
journalctl -u nginx --since "2026-08-26 10:00"
アプリケーションやWebサーバーが独自のログファイルを出力している場合は、tailやlessを使います。
tail -n 100 /var/log/nginx/error.log
リアルタイムでログを確認する場合は、次のように実行します。
tail -f /var/log/nginx/error.log
【関連記事】ログを確認するコマンドは、Linuxでログ監視するコマンドtailとlessの使い方解説も参考にしてください。
CPUやメモリ不足が起きていないか確認する¶
サービスが動いていても、CPUやメモリを大量に使用していると処理が遅くなったり、アプリケーションが正常に動かなかったりします。
リアルタイムの状態はtopで確認できます。
top
メモリ使用量を見たい場合は、freeも便利です。
free -h
出力例は次のようになります。
total used free shared buff/cache available
Mem: 7.7Gi 2.1Gi 3.8Gi 120Mi 1.8Gi 5.2Gi
availableも確認し、CPU使用率が高い場合はtopやpsで原因プロセスを調べます。
【関連記事】メモリの見方は、Linuxのメモリ使用率を確認する方法は？top・free・psコマンドの使い方解説で解説しています。
ディスク容量不足を確認する¶
Linuxサーバーでよくある障害原因の一つが、ディスク容量不足です。
ログが大量に出力され続けたり、バックアップファイルが残り続けたりすると、ディスクがいっぱいになることがあります。
まずdfでファイルシステムの使用量を確認します。
df -h
たとえば、Use%が100%に近いファイルシステムがないか確認します。
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 30G 29G 1.0G 97% /
容量に余裕があるのにファイルを作成できない場合は、inode不足も確認します。
df -i
ディスクがいっぱいになっていることが分かっても、いきなりファイルを削除するのではなく、どのディレクトリが容量を使っているのか確認してから対応しましょう。
ネットワークの問題を切り分ける¶
サービスやリソースに問題がなければ、ネットワークも確認します。
まず自分のIPアドレスを確認します。
ip addr
ルーティング情報は次のコマンドです。
ip route
通信相手へ到達できるか確認する場合はpingを利用できます。
ping -c 4 192.168.1.10
ただし、ファイアウォールなどでICMPを拒否している環境では、サービスが正常でもpingへ応答しない場合があります。
Webサーバーがローカルでは応答するか確認したい場合は、curlも便利です。
curl -I http://localhost
ローカルでは応答するのに外部から接続できない場合は、ファイアウォールやクラウド側の設定も確認します。
ポートが待ち受けているかはssで確認できます。
ss -lntp
このように、アプリケーション → Linux → ネットワークと範囲を分けて確認すると原因を絞り込みやすくなります。
カーネルやハードウェア関連のログを確認する¶
OSやデバイスに近い問題では、dmesgが役立つ場合があります。
dmesg
直近のメッセージだけ確認するなら、次のように使えます。
dmesg -T | tail -n 50
メモリ不足によってプロセスが終了された場合や、ディスク・ネットワークデバイスに関するメッセージが記録されることがあります。
ただし、環境によっては一般ユーザーからすべてのカーネルログを参照できない場合があります。その場合は適切な権限で確認してください。
とりあえず再起動する前に確認したいこと¶
障害対応では、再起動で復旧するケースもあります。
ただし、何も確認せずにサーバーやサービスを再起動すると、なぜ障害が発生したのか分からなくなることがあります。
再起動前には最低限、次の情報を残しておくと調査しやすいです。
date
uptime
free -h
df -h
ps aux
systemctl status nginx
必要に応じてログも保存します。
業務影響が大きい場合は、運用手順に沿ってサービス再起動や切り戻しを行います。
復旧したあとに原因と再発防止を考える¶
システムが復旧しても、障害対応は終わりではありません。
なぜ障害が起きたのかを整理し、同じ問題が起きないように対策します。
たとえばディスク容量不足が原因だった場合、不要ファイルを削除するだけでは再発する可能性があります。
ログローテーションを設定する、ディスク使用率を監視する、一定値を超えたらアラートを通知するといった対策まで考えます。
人的ミスなら、レビューや自動化などでミスが起きにくい仕組みを作ります。
Linuxのトラブルシューティングは練習しておく¶
普段からLinuxを操作し、プロセス、ログ、メモリ、ネットワークを確認する練習をしておくことが大切です。
InfraAcademyでは、Linuxのコマンドをブラウザ上で実行しながら学習できます。
Linuxを基礎から学習したい方は、Linux入門講座をご覧ください。
ネットワーク障害の切り分けに必要なIPアドレスやルーティングは、ネットワーク講座で学習できます。
AWS上のLinuxやクラウド環境も学びたい方は、AWS講座も用意しています。
関連:Linuxのコマンド練習におすすめのInfraAcademy【Linuxのコマンドをブラウザで練習しよう】
Linuxのトラブルシューティングまとめ¶
今回の記事では、Linuxで障害が発生した際のトラブルシューティング手順について解説しました。
大切なのは、最初から原因を決めつけず、状況を確認しながら一つずつ切り分けることです。
Webサイトへアクセスできないのであれば、サービスが動いているか、ログにエラーがないか、CPUやメモリは足りているか、ディスクはいっぱいになっていないか、ネットワークは正常かという順番で確認できます。
よく使うコマンドをまとめると、次のようになります。
| 確認内容 | コマンド例 |
|---|---|
| 稼働時間 | uptime |
| プロセス | ps aux、top |
| サービス | systemctl status |
| ログ | journalctl、tail |
| メモリ | free -h |
| ディスク | df -h、df -i |
| IP・経路 | ip addr、ip route |
| 通信 | ping、curl |
| ポート | ss -lntp |
| カーネルログ | dmesg |
コマンドを暗記するだけではなく、どの問題を確認するためにそのコマンドを使うのかまで理解しておきましょう。
日頃から実際にLinuxを操作しておくと、障害が発生したときにも落ち着いて原因を切り分けられるようになります。
