Ubuntu 26.04 障害時の切り分け – OS / ネットワーク / サービスを層で見る

Ubuntu 26.04 で障害を調べる時は、最初から特定の設定ファイルだけを疑わず、OS、ディスク、ネットワーク、名前解決、経路、サービス、ログの順に層を分けて確認します。層を分けると、原因がアプリケーションなのか、OS の状態なのか、通信経路なのかを切り分けやすくなります。

この記事では、サーバーへログインできる状態を前提に、基本情報、負荷、ディスク、ネットワーク、DNS、サービス状態、ログ、設定反映、再起動後の確認を順番に見ます。

最初に状況を固定する

作業前にホスト名、時刻、起動時刻、OS バージョンを確認します。複数台を扱う時は、対象ホストを間違えないことが重要です。

hostnamectl
date
uptime
lsb_release -a
uname -a

負荷とリソースを見る

応答が遅い、コマンドが返らない、サービスが不安定な場合は、CPU、メモリ、プロセス、ディスク使用量を確認します。

uptime
free -h
ps aux --sort=-%mem | head
ps aux --sort=-%cpu | head
df -h

ディスクと inode を確認する

ディスク容量だけでなく inode 枯渇も確認します。ログや一時ファイルが原因でサービスが書き込めないことがあります。

df -h
df -ih
sudo du -xh /var/log | sort -h | tail
journalctl --disk-usage

ネットワークインターフェイスを見る

通信できない場合は、まずインターフェイス、IP アドレス、リンク状態を確認します。

ip address
ip link
networkctl status --no-pager
resolvectl status

経路を確認する

宛先へ届かない場合は、デフォルトルートと宛先ごとの経路を確認します。複数 NIC や policy based routing がある環境では、想定したインターフェイスから出ているかを見ます。

ip route
ip rule
ip route get 8.8.8.8
ip route get 192.0.2.10

疎通を確認する

名前解決の前に IP アドレスで疎通を確認します。ICMP が許可されていない環境では、TCP ポートへの接続確認も行います。

ping -c 4 8.8.8.8
ping -c 4 192.0.2.10
nc -vz 192.0.2.10 443
curl -I https://www.example.com/

名前解決を確認する

IP アドレスでは疎通できるのにホスト名では失敗する場合は、DNS と resolver の状態を確認します。

resolvectl query www.example.com
resolvectl dns
resolvectl domain
getent hosts www.example.com

ポート待ち受けを確認する

サービスが起動していても、想定ポートで待ち受けていない場合があります。待ち受けアドレスが 127.0.0.1 だけなのか、外部から到達できるアドレスなのかも確認します。

sudo ss -lntup
sudo ss -lntup | grep ':22'
sudo ss -lnup

サービス状態を確認する

対象サービスが分かっている場合は、現在動いているか、起動時に有効か、失敗 unit が残っていないかを確認します。

systemctl status ssh.service --no-pager
systemctl is-active ssh.service
systemctl is-enabled ssh.service
systemctl --failed

ログを確認する

サービス状態だけでは原因が分からない場合は、今回起動中のエラー、対象サービスのログ、カーネルログを確認します。

journalctl -b -p err --no-pager
journalctl -u ssh.service -b --no-pager
journalctl -k -b --no-pager
sudo tail -n 100 /var/log/syslog

設定ファイルの構文を確認する

設定変更後に起動しない場合は、対象サービスが提供する構文チェックを使います。コマンド名はサービスごとに異なります。

sudo nginx -t
sudo apache2ctl configtest
sudo named-checkconf
sudo postfix check

設定反映の種類を確認する

設定変更後は、reload で反映できるのか、restart が必要なのか、unit 変更に daemon-reload が必要なのかを分けます。

sudo systemctl daemon-reload
sudo systemctl reload ssh.service
sudo systemctl restart ssh.service
systemctl status ssh.service --no-pager

権限と所有者を確認する

設定は正しく見えても、ファイル権限や所有者が原因で読めないことがあります。証明書、秘密鍵、ログ出力先、ソケットの権限を確認します。

ls -l /etc/ssh/sshd_config
sudo namei -l /etc/ssh/sshd_config
sudo journalctl -u ssh.service -b --no-pager

再起動後に確認する

一時的な修復で終わらせず、再起動後も設定が残るかを確認します。自動起動、マウント、ネットワーク、サービス状態を見ます。

systemctl --failed
systemctl is-enabled ssh.service
findmnt
ip address
ip route

切り分けの順番

• 対象ホスト、時刻、OS バージョンを確認する。
• CPU、メモリ、ディスク、inode を確認する。
• インターフェイス、IP アドレス、経路、DNS を確認する。
• ポート待ち受けと到達性を確認する。
• サービス状態とログを確認する。
• 設定構文、権限、反映方法を確認する。
• 再起動後も状態が維持されるか確認する。

確認項目

• どの層で失敗しているかを言える状態になっているか。
• IP 疎通と名前解決を分けて確認しているか。
• サービスの active と enabled を分けて見ているか。
• 今回起動中のログと前回起動のログを分けて確認しているか。
• 設定変更後の反映方法と再起動後の状態を確認しているか。

まとめ

Ubuntu 26.04 の障害切り分けでは、OS、リソース、ネットワーク、DNS、サービス、ログ、設定反映を順番に確認します。最初から原因を決め打ちせず、どの層で期待と違う状態になっているかを確認すると、復旧作業と恒久対応を分けやすくなります。

関連記事

Ubuntu 26.04 サービス状態確認の基本 – systemctl で active / enabled / failed を見る Ubuntu 26.04 設定反映の確認 – reload / restart / daemon-reload を切り分ける Ubuntu 26.04 再起動後確認 – 永続化された設定と起動状態を見る Ubuntu 26.04 journald の基本設定 – journalctl と永続ログを管理する Ubuntu 26.04 ログ確認の基本 – journalctl と /var/log を切り分ける Ubuntu 26.04 systemd の基本 – unit / target / timer とサービス管理を理解する Ubuntu 26.04 fstab によるリモートマウント – リモートストレージを固定マウントする Ubuntu 26.04 smartd の基本設定 – S.M.A.R.T. で物理ディスクを監視する