Linuxトラブルシューティング基礎 - 問題切り分けの考え方

1
2
3
4
5
6
7
8

# 問題定義のためのチェックリスト
# - いつから発生しているか？
# - 何が動かない/遅いのか？（具体的なサービス、機能）
# - どの環境で発生しているか？（本番、ステージング、特定サーバー）
# - 誰が影響を受けているか？（全ユーザー、特定ユーザー）
# - どのような操作をしたときに発生するか？
# - エラーメッセージは出ているか？
# - 最近システムに変更を加えたか？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# パッケージの更新履歴を確認（Debian/Ubuntu系）
cat /var/log/apt/history.log | tail -50

# パッケージの更新履歴を確認（RHEL/AlmaLinux系）
sudo dnf history
sudo dnf history info <transaction-id>

# 最近変更されたファイルを確認
find /etc -type f -mtime -1 -ls 2>/dev/null

# 最近のシステム起動を確認
who -b
uptime

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# システム全体の最新ログを確認
journalctl -xe

# 特定サービスのログを確認
journalctl -u nginx.service --since "1 hour ago"

# エラーレベル以上のログのみ表示
journalctl -p err --since today

# リアルタイムでログを監視
journalctl -f

# 特定の時間範囲のログを確認
journalctl --since "2026-01-08 10:00:00" --until "2026-01-08 12:00:00"

# ブート関連のログを確認
journalctl -b -1  # 前回起動時のログ

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# システムログの確認（Debian/Ubuntu系）
sudo tail -100 /var/log/syslog

# システムログの確認（RHEL/AlmaLinux系）
sudo tail -100 /var/log/messages

# 認証ログの確認
sudo tail -50 /var/log/auth.log    # Debian/Ubuntu
sudo tail -50 /var/log/secure       # RHEL/AlmaLinux

# アプリケーション固有のログ
sudo tail -100 /var/log/nginx/error.log
sudo tail -100 /var/log/mysql/error.log

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 特定のキーワードでフィルタリング
journalctl | grep -i "error\|fail\|warn"

# 特定時刻以降のエラーを抽出
journalctl -p err --since "2026-01-08 09:00:00" --no-pager

# ログをJSON形式で出力（スクリプト処理用）
journalctl -o json-pretty -n 10

# 複数条件でのフィルタリング
journalctl _SYSTEMD_UNIT=sshd.service + _SYSTEMD_UNIT=nginx.service

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 典型的なエラーメッセージの例
# Jan 08 10:30:45 webserver nginx[1234]: 2026/01/08 10:30:45 [error] 1234#0: 
#   *5678 open() "/var/www/html/missing.html" failed (2: No such file or directory)

# 分解すると:
# - タイムスタンプ: Jan 08 10:30:45
# - ホスト名: webserver
# - サービス名[PID]: nginx[1234]
# - 重要度: [error]
# - 詳細: ファイルが見つからない

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# CPU・メモリの概要を確認
top -bn1 | head -20

# メモリ使用状況の詳細
free -h
cat /proc/meminfo | head -10

# ディスク使用状況
df -h
df -i  # inode使用状況

# ディスクI/O状況
iostat -x 1 3

# 負荷状況の確認
uptime
cat /proc/loadavg

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 実行中のプロセス一覧
ps aux --sort=-%mem | head -20  # メモリ使用量順
ps aux --sort=-%cpu | head -20  # CPU使用量順

# 特定サービスのプロセス確認
pgrep -a nginx
pgrep -a mysql

# プロセスツリーの表示
pstree -p

# ゾンビプロセスの確認
ps aux | awk '$8 ~ /Z/'

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# ネットワークインターフェースの状態
ip addr show
ip link show

# ルーティングテーブル
ip route show

# 接続状況の確認
ss -tuln  # リッスンポート一覧
ss -tunp  # 確立済み接続

# 特定ポートの使用状況
ss -tulnp | grep :80

# DNS解決の確認
dig example.com
nslookup example.com

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# サービスの状態確認
systemctl status nginx

# 全サービスの状態一覧
systemctl list-units --type=service --state=failed

# サービスの依存関係確認
systemctl list-dependencies nginx

# サービス起動の詳細ログ
journalctl -u nginx --no-pager -n 50

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# エラー例
$ cat /var/log/secure
cat: /var/log/secure: Permission denied

# 対処法1: 権限を確認
ls -la /var/log/secure

# 対処法2: 適切な権限で実行
sudo cat /var/log/secure

# 対処法3: ファイルの所有者・権限を修正（必要な場合）
sudo chown appropriate_user:appropriate_group /path/to/file
sudo chmod 644 /path/to/file

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Nginxがファイルにアクセスできない場合
# エラーログ: open() "/var/www/html/index.html" failed (13: Permission denied)

# ファイルの権限確認
ls -la /var/www/html/

# Nginxの実行ユーザー確認
ps aux | grep nginx

# 権限の修正
sudo chown -R www-data:www-data /var/www/html/
sudo chmod -R 755 /var/www/html/

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# エラー例
$ touch /var/log/test.log
touch: cannot touch '/var/log/test.log': No space left on device

# ディスク使用状況の確認
df -h

# 大きなファイルの特定
sudo du -sh /* 2>/dev/null | sort -hr | head -20
sudo du -sh /var/* 2>/dev/null | sort -hr | head -10

# 削除済みだがプロセスが掴んでいるファイルを確認
sudo lsof +L1

# 古いログファイルの圧縮・削除
sudo journalctl --vacuum-size=500M
sudo find /var/log -name "*.gz" -mtime +30 -delete

# inode枯渇の確認（小さなファイルが大量にある場合）
df -i

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# エラー例
$ curl http://localhost:80
curl: (7) Failed to connect to localhost port 80: Connection refused

# 対処法1: サービスの状態確認
systemctl status nginx

# 対処法2: ポートのリッスン状態確認
ss -tulnp | grep :80

# 対処法3: サービスの起動
sudo systemctl start nginx

# 対処法4: ファイアウォールの確認
sudo iptables -L -n
sudo firewall-cmd --list-all  # firewalldの場合
sudo ufw status               # ufwの場合

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# エラー例
$ ping example.com
ping: example.com: Name or service not known

# 対処法1: DNS設定の確認
cat /etc/resolv.conf

# 対処法2: DNS解決のテスト
dig example.com
nslookup example.com

# 対処法3: /etc/hostsの確認
cat /etc/hosts

# 対処法4: 特定のDNSサーバーを指定してテスト
dig @8.8.8.8 example.com

# 対処法5: nsswitch.confの確認
cat /etc/nsswitch.conf | grep hosts

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# OOMキラーの発動を確認
dmesg | grep -i "out of memory"
journalctl -k | grep -i "oom"

# メモリ使用状況の確認
free -h
cat /proc/meminfo

# メモリを大量消費しているプロセスの特定
ps aux --sort=-%mem | head -10

# スワップ使用状況
swapon --show

# OOMスコアの確認（値が大きいほど終了されやすい）
cat /proc/$(pgrep nginx)/oom_score

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# エラー例
$ sudo systemctl start nginx
Job for nginx.service failed because the control process exited with error code.

# 対処法1: 詳細なステータス確認
systemctl status nginx -l

# 対処法2: ジャーナルログの確認
journalctl -xe -u nginx

# 対処法3: 設定ファイルの文法チェック
sudo nginx -t

# 対処法4: 依存サービスの確認
systemctl list-dependencies nginx

# 対処法5: ポート競合の確認
ss -tulnp | grep :80

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 再現手順を文書化する例
# 1. 環境情報
cat /etc/os-release
uname -a

# 2. 事前状態の記録
systemctl status myservice
ss -tulnp | grep :8080

# 3. 再現操作
curl -v http://localhost:8080/api/endpoint

# 4. 結果の記録
echo $?  # 終了コード

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# 仮説1: ディスク容量不足
df -h
# 結果: 容量に余裕あり → 仮説棄却

# 仮説2: メモリ不足
free -h
# 結果: メモリ使用率95% → 仮説採用、詳細調査

# 仮説2の詳細調査
ps aux --sort=-%mem | head -10
# 結果: 特定プロセスがメモリを大量消費

# 対処と検証
sudo systemctl restart problematic-service
free -h
# 結果: メモリ使用率が50%に低下、問題解決

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# 設定ファイルを最小構成にして起動テスト
sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup
sudo cat > /etc/nginx/nginx.conf.minimal << 'EOF'
events {
    worker_connections 1024;
}

http {
    server {
        listen 80;
        root /var/www/html;
    }
}
EOF

# 最小構成でテスト
sudo nginx -t -c /etc/nginx/nginx.conf.minimal
sudo nginx -c /etc/nginx/nginx.conf.minimal

# テスト後、元に戻す
sudo mv /etc/nginx/nginx.conf.backup /etc/nginx/nginx.conf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

#!/bin/bash
# system-info-collector.sh
# 障害調査用の情報収集スクリプト

OUTPUT_DIR="/tmp/system-info-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$OUTPUT_DIR"

echo "システム情報を収集しています..."

# 基本情報
{
    echo "=== System Info ==="
    date
    hostname
    uname -a
    cat /etc/os-release
} > "$OUTPUT_DIR/system-info.txt"

# リソース情報
{
    echo "=== Memory ==="
    free -h
    echo ""
    echo "=== Disk ==="
    df -h
    echo ""
    echo "=== Load ==="
    uptime
    cat /proc/loadavg
} > "$OUTPUT_DIR/resources.txt"

# プロセス情報
{
    echo "=== Top Processes (CPU) ==="
    ps aux --sort=-%cpu | head -20
    echo ""
    echo "=== Top Processes (Memory) ==="
    ps aux --sort=-%mem | head -20
} > "$OUTPUT_DIR/processes.txt"

# ネットワーク情報
{
    echo "=== Network Interfaces ==="
    ip addr
    echo ""
    echo "=== Listening Ports ==="
    ss -tulnp
    echo ""
    echo "=== Routing Table ==="
    ip route
} > "$OUTPUT_DIR/network.txt"

# サービス状態
{
    echo "=== Failed Services ==="
    systemctl list-units --type=service --state=failed
    echo ""
    echo "=== All Services ==="
    systemctl list-units --type=service
} > "$OUTPUT_DIR/services.txt"

# 最新のログ
journalctl --since "1 hour ago" --no-pager > "$OUTPUT_DIR/journal-1h.txt"
journalctl -p err --since "24 hours ago" --no-pager > "$OUTPUT_DIR/errors-24h.txt"

# アーカイブ作成
tar czf "$OUTPUT_DIR.tar.gz" -C /tmp "$(basename $OUTPUT_DIR)"

echo "情報収集完了: $OUTPUT_DIR.tar.gz"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

## 障害報告書

### 概要
- 発生日時: 2026-01-08 10:30 JST
- 復旧日時: 2026-01-08 11:15 JST
- 影響範囲: Webサービス全体
- 影響ユーザー数: 約1,000名

### 症状
- Webサイトへのアクセスで504エラーが発生
- APIレスポンスタイムが通常の10倍に増加

### 原因
- データベースサーバーのディスク容量が100%に達し、
  トランザクションログの書き込みが失敗

### 対処
1. 不要なログファイルを削除（20GB確保）
2. データベースサービスを再起動
3. アプリケーションサーバーを再起動

### 再発防止策
1. ディスク使用率80%でアラート設定
2. ログローテーション設定の見直し
3. ディスク容量の週次レポート作成