Troubleshooting Methodology and Tools
Linuxトラブルシューティング方法論とツール 完全ガイド
目次
- はじめに
- 体系的トラブルシューティング方法論
- システム情報の収集
- ハードウェアトラブルシューティング
- プロセストラブルシューティング
- メモリトラブルシューティング
- ディスクトラブルシューティング
- ネットワークトラブルシューティング
- ブートトラブルシューティング
- ログ分析
- コアダンプ分析の基礎
- ランブックの作成
- トラブルシューティングツール比較表
- ベストプラクティス
- 参考資料
1. はじめに
Linuxシステムのトラブルシューティングは、体系的なアプローチと適切なツールの知識が不可欠である。問題の症状から根本原因を特定し、適切な対策を講じるためには、方法論に基づいた調査が重要である。
本ドキュメントでは、トラブルシューティングの方法論（USE、RED、TSA）、各分野のトラブルシューティングツール、そして実践的な調査手順を包括的に解説する。
2. 体系的トラブルシューティング方法論
2.1 USE メソッド
Brendan Gregg が提唱した方法論。各リソースについて Utilization（使用率）、Saturation（飽和度）、Errors（エラー）を確認する。
┌──────────────────────────────────────────────────────┐
│ USE メソッド │
│ │
│ U = Utilization (使用率) │
│ リソースがどれだけ使用されているか │
│ 例: CPU使用率 80% │
│ │
│ S = Saturation (飽和度) │
│ リソースがどれだけ過負荷状態か │
│ 例: CPU のランキュー長 │
│ │
│ E = Errors (エラー) │
│ エラーイベントの発生回数 │
│ 例: NIC のCRCエラー数 │
└──────────────────────────────────────────────────────┘
USEメソッドのチェックリスト:
| リソース | Utilization | Saturation | Errors |
|---|---|---|---|
| CPU | mpstat -P ALL 1, sar -u | vmstat 1 (r列), sar -q | dmesg, MCEログ |
| メモリ | free -m, vmstat 1 (si/so列) | vmstat 1 (si/so列), sar -B | dmesg (OOMメッセージ) |
| ストレージI/O | iostat -xz 1, sar -d | iostat -xz 1 (avgqu-sz) | smartctl -a, dmesg |
| ストレージ容量 | df -h, du -sh | df -i (inode) | dmesg, FS エラー |
| ネットワーク | sar -n DEV 1, ip -s link | ss -s, netstat -s | ip -s link (エラーカウンタ) |
# CPU の USE チェック
# U: CPU使用率
$ mpstat -P ALL 1 3
Linux 5.15.0-91-generic 01/15/2024
10:00:01 AM CPU %usr %nice %sys %iowait %irq %soft %steal %idle
10:00:02 AM all 45.25 0.00 12.50 2.25 0.50 1.00 0.00 38.50
10:00:02 AM 0 50.00 0.00 15.00 3.00 1.00 2.00 0.00 29.00
10:00:02 AM 1 40.50 0.00 10.00 1.50 0.00 0.00 0.00 48.00
# S: CPUの飽和度（ランキュー）
$ vmstat 1 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
5 0 0 1234567 89012 3456789 0 0 0 50 1234 567 45 12 38 2 0
# r列 > CPUコア数 → 飽和状態
# E: CPUエラー
$ dmesg | grep -i "mce\|machine check\|cpu error"
$ journalctl -k | grep -i "mce"
2.2 RED メソッド
Tom Wilkie が提唱した、マイクロサービス向けの方法論。各サービスについて Rate（リクエスト率）、Errors（エラー率）、Duration（応答時間）を確認する。
┌──────────────────────────────────────────────────────┐
│ RED メソッド │
│ │
│ R = Rate (リクエスト率) │
│ サービスが処理しているリクエスト数/秒 │
│ │
│ E = Errors (エラー率) │
│ 失敗したリクエストの割合 │
│ │
│ D = Duration (応答時間) │
│ リクエストの処理にかかる時間 │
└──────────────────────────────────────────────────────┘
# RED メソッドの実践例（Webサーバ）
# R: リクエスト率
$ awk '{print $4}' /var/log/nginx/access.log | cut -d: -f1-3 | uniq -c | tail -5
125 [15/Jan/2024:10:00
130 [15/Jan/2024:10:01
142 [15/Jan/2024:10:02
128 [15/Jan/2024:10:03
135 [15/Jan/2024:10:04
# E: エラー率
$ awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
45000 200
2000 304
500 404
100 500
50 502
20 503
# D: 応答時間（Nginxのログに$request_timeが含まれる場合）
$ awk '{print $NF}' /var/log/nginx/access.log | sort -n | tail -20
# curl でレスポンスタイムを測定
$ curl -o /dev/null -s -w "time_total: %{time_total}s\n" http://localhost/
time_total: 0.045s
2.3 TSA メソッド
Thread State Analysis（スレッド状態分析）。プロセスの各スレッドが何をしているかを分析する。
┌──────────────────────────────────────────────────────┐
│ TSA メソッド │
│ │
│ 1. スレッドの状態を特定 │
│ - On-CPU (実行中) │
│ - Off-CPU (待機中: I/O, ロック, スリープ) │
│ │
│ 2. 状態の分布を分析 │
│ - CPU使用が高い → プロファイリング │
│ - Off-CPU時間が長い → Off-CPUプロファイリング │
│ │
│ 3. 根本原因を特定 │
│ - スタックトレースの分析 │
│ - ホットスポットの特定 │
└──────────────────────────────────────────────────────┘
# スレッド状態の確認
$ ps -eLf | head -20
UID PID PPID LWP C NLWP STIME TTY TIME CMD
root 1 0 1 0 1 Jan15 ? 00:00:05 /usr/lib/systemd/systemd
# プロセスのスレッド一覧
$ ps -T -p $(pgrep -f httpd | head -1)
PID SPID TTY TIME CMD
12345 12345 ? 00:00:01 httpd
12345 12346 ? 00:00:00 httpd
12345 12347 ? 00:00:00 httpd
# strace でシステムコールを追跡
$ sudo strace -c -p 12345 -f -e trace=all
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.00 0.450000 5 90000 read
30.00 0.300000 4 75000 write
15.00 0.150000 10 15000 futex
5.00 0.050000 3 16667 epoll_wait
2.4 方法論の比較
| 方法論 | 対象 | 焦点 | 適用場面 |
|---|---|---|---|
| USE | ハードウェアリソース | リソースの枯渇状態 | インフラ/OS層の問題 |
| RED | サービス/アプリケーション | ユーザー体験 | マイクロサービスの問題 |
| TSA | プロセス/スレッド | 実行状態の分析 | アプリケーションの問題 |
3. システム情報の収集
# カーネルとOS情報
$ uname -a
Linux server1 5.15.0-91-generic #101-Ubuntu SMP x86_64 GNU/Linux
$ uname -r # カーネルバージョンのみ
5.15.0-91-generic
# ディストリビューション情報
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
ID=ubuntu
VERSION_ID="22.04"
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.3 LTS
Release: 22.04
Codename: jammy
# ホスト情報
$ hostnamectl
Static hostname: server1
Icon name: computer-vm
Chassis: vm
Machine ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Boot ID: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
Virtualization: kvm
Operating System: Ubuntu 22.04.3 LTS
Kernel: Linux 5.15.0-91-generic
Architecture: x86-64
# ハードウェア情報の詳細
$ sudo dmidecode -t system | head -20
System Information
Manufacturer: QEMU
Product Name: Standard PC
Serial Number: Not Specified
UUID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
$ sudo dmidecode -t memory | head -30
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Maximum Capacity: 64 GB
Number Of Devices: 4
# CPU情報
$ lscpu
Architecture: x86_64
CPU(s): 4
Model name: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
Thread(s) per core: 1
Core(s) per socket: 4
# 稼働時間と負荷
$ uptime
10:00:00 up 45 days, 12:30, 3 users, load average: 1.50, 1.20, 0.95
# システムリソースの概要
$ cat /proc/meminfo | head -10
MemTotal: 16384000 kB
MemFree: 2048000 kB
MemAvailable: 8192000 kB
Buffers: 512000 kB
Cached: 5632000 kB
4. ハードウェアトラブルシューティング
# PCI デバイスの一覧
$ lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI
00:03.0 Ethernet controller: Red Hat, Inc. Virtio network device
00:04.0 SCSI storage controller: Red Hat, Inc. Virtio block device
# 詳細なPCI情報
$ lspci -v -s 00:03.0
00:03.0 Ethernet controller: Red Hat, Inc. Virtio network device
Subsystem: Red Hat, Inc. Virtio network device
Flags: bus master, fast devsel, latency 0, IRQ 11
I/O ports at c000 [size=32]
Memory at feb90000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: virtio-pci
# USB デバイスの一覧
$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd Keyboard
# ブロックデバイスの一覧
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 100G 0 disk
├─sda1 8:1 0 1G 0 part /boot
├─sda2 8:2 0 50G 0 part /
└─sda3 8:3 0 49G 0 part /home
sr0 11:0 1 1024M 0 rom
# ディスクの健全性チェック（SMART）
$ sudo smartctl -a /dev/sda
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Blue
Device Model: WDC WD10EZEX-00RKKA0
Serial Number: WD-XXXXXXXXX
Firmware Version: 80.00A80
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART Attributes Data Structure revision number: 16
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always 0
3 Spin_Up_Time 0x0027 138 138 021 Pre-fail Always 4091
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always 0
9 Power_On_Hours 0x0032 095 095 000 Old_age Always 4123
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline 0
# SMART テストの実行
$ sudo smartctl -t short /dev/sda # 短時間テスト（約2分）
$ sudo smartctl -t long /dev/sda # 長時間テスト（数時間）
$ sudo smartctl -l selftest /dev/sda # テスト結果の確認
# メモリテスト
$ sudo memtester 1024M 1 # 1GBのメモリテスト、1回
memtester version 4.5.1 (64-bit)
Loop 1/1:
Stuck Address : ok
Random Value : ok
Compare XOR : ok
Compare SUB : ok
...
# ハードウェアエラーログ
$ sudo mcelog --client # Machine Check Exception ログ
$ sudo rasdaemon --record # RAS (Reliability, Availability, Serviceability) ログ
5. プロセストラブルシューティング
# プロセス一覧
$ ps aux | head -20
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 169588 12936 ? Ss Jan15 0:05 /usr/lib/systemd/systemd
root 2 0.0 0.0 0 0 ? S Jan15 0:00 [kthreadd]
...
# CPU使用率の高いプロセス
$ ps aux --sort=-%cpu | head -10
# メモリ使用量の多いプロセス
$ ps aux --sort=-%mem | head -10
# 特定プロセスの詳細情報
$ ps -fp $(pgrep -f httpd | head -1)
# top / htop - リアルタイムプロセスモニタ
$ top -bn1 | head -20
top - 10:00:00 up 45 days, 12:30, 3 users, load average: 1.50, 1.20, 0.95
Tasks: 256 total, 2 running, 254 sleeping, 0 stopped, 0 zombie
%Cpu(s): 45.0 us, 12.5 sy, 0.0 ni, 38.5 id, 2.0 wa, 0.5 hi, 1.0 si, 0.0 st
MiB Mem : 16000.0 total, 2000.0 free, 8000.0 used, 6000.0 buff/cache
MiB Swap: 4000.0 total, 3800.0 free, 200.0 used. 7000.0 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12345 www-data 20 0 600000 200000 50000 S 85.0 1.2 5:30.00 httpd
23456 mysql 20 0 2000000 800000 100000 S 25.0 5.0 10:15.00 mysqld
# プロセスの検索
$ pgrep -la httpd
12345 /usr/sbin/httpd -DFOREGROUND
12346 /usr/sbin/httpd -DFOREGROUND
# プロセスツリー
$ pstree -p 12345
httpd(12345)─┬─httpd(12346)
├─httpd(12347)
├─httpd(12348)
└─httpd(12349)
# シグナルの送信
$ kill -15 12345 # SIGTERM（正常終了）
$ kill -9 12345 # SIGKILL（強制終了）
$ kill -1 12345 # SIGHUP（設定再読み込み）
# strace - システムコールの追跡
$ sudo strace -p 12345 -f -e trace=network
[pid 12345] accept4(3, {sa_family=AF_INET, sin_port=htons(54321), ...
[pid 12345] read(5, "GET / HTTP/1.1\r\n", 8192) = 16
[pid 12345] write(5, "HTTP/1.1 200 OK\r\n", 17) = 17
# strace の統計出力
$ sudo strace -c -p 12345 -f
^C
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
35.00 0.350000 5 70000 read
25.00 0.250000 4 62500 write
20.00 0.200000 10 20000 accept4
10.00 0.100000 3 33333 epoll_wait
5.00 0.050000 8 6250 close
5.00 0.050000 15 3333 stat
# ltrace - ライブラリコールの追跡
$ sudo ltrace -p 12345 -e malloc+free
malloc(1024) = 0x55e8a1b00000
malloc(4096) = 0x55e8a1b00400
free(0x55e8a1b00000) = <void>
# /proc からプロセス情報を取得
$ cat /proc/12345/status | head -20
Name: httpd
State: S (sleeping)
Tgid: 12345
Pid: 12345
PPid: 1
Threads: 4
VmPeak: 600000 kB
VmRSS: 200000 kB
# ファイルディスクリプタの確認
$ ls -la /proc/12345/fd/ | head -20
$ cat /proc/12345/limits
6. メモリトラブルシューティング
# メモリ使用状況の確認
$ free -mh
total used free shared buff/cache available
Mem: 16Gi 8.0Gi 2.0Gi 256Mi 6.0Gi 7.0Gi
Swap: 4.0Gi 200Mi 3.8Gi
# vmstat - メモリと仮想メモリの統計
$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 204800 2048000 512000 5632000 0 0 5 20 1500 800 45 12 38 2 0
1 0 204800 2040000 512100 5632500 0 0 0 50 1450 780 40 10 45 2 0
# si: スワップイン（ディスク→メモリ）
# so: スワップアウト（メモリ→ディスク）
# si/so > 0 → メモリ不足の兆候
# /proc/meminfo の詳細
$ cat /proc/meminfo
MemTotal: 16384000 kB
MemFree: 2048000 kB
MemAvailable: 7168000 kB
Buffers: 512000 kB
Cached: 5632000 kB
SwapCached: 10000 kB
Active: 8000000 kB
Inactive: 5000000 kB
SwapTotal: 4096000 kB
SwapFree: 3891200 kB
Dirty: 12000 kB
Shmem: 256000 kB
Slab: 800000 kB
SReclaimable: 600000 kB
SUnreclaim: 200000 kB
# OOM (Out of Memory) の分析
$ dmesg | grep -i "oom\|out of memory\|killed process"
[12345.678901] Out of memory: Killed process 23456 (mysqld) total-vm:2048000kB, anon-rss:1500000kB
[12345.678902] oom_reaper: reaped process 23456 (mysqld), now anon-rss:0kB
# OOMスコアの確認
$ cat /proc/12345/oom_score
150
$ cat /proc/12345/oom_score_adj
0 # -1000 ~ 1000 (-1000 = OOMされない)
# OOMの防止設定
$ echo -1000 > /proc/12345/oom_score_adj # このプロセスをOOMから保護
# slab メモリの分析
$ sudo slabtop -o | head -20
Active / Total Objects (% used) : 2500000 / 3000000 (83.3%)
Active / Total Slabs (% used) : 80000 / 80000 (100.0%)
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
50000 48000 96% 0.19K 2500 20 10000K dentry
30000 28000 93% 0.57K 2143 14 17144K inode_cache
20000 19000 95% 0.12K 625 32 2500K kernfs_node_cache
# メモリリークの調査
$ sudo smem -t -k
PID User Command Swap USS PSS RSS
12345 mysql mysqld 100M 800M 820M 850M
23456 www-data httpd 0 150M 160M 200M
# ページキャッシュのドロップ（緊急時のみ）
$ sudo sync; echo 3 > /proc/sys/vm/drop_caches
# 1 = ページキャッシュ, 2 = dentryとinode, 3 = 全て
7. ディスクトラブルシューティング
# I/O統計の確認
$ iostat -xz 1 3
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s wrqm/s %wrqm w_await wareq-sz d/s dkB/s drqm/s %drqm d_await dareq-sz f/s f_await aqu-sz %util
sda 50.00 2000.00 5.00 10.00 2.50 40.00 30.00 1500.00 10.00 25.00 5.00 50.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.35 45.00
# 重要な指標:
# %util: ディスク使用率（100%に近いと飽和状態）
# await: I/O待ち時間（高いとパフォーマンス低下）
# aqu-sz: キューの平均長（高いと飽和）
# I/Oを発生させているプロセスの特定
$ sudo iotop -oP
Total DISK READ: 5.00 MB/s | Total DISK WRITE: 3.00 MB/s
Actual DISK READ: 5.00 MB/s | Actual DISK WRITE: 3.00 MB/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
12345 be/4 mysql 4.00 MB/s 2.50 MB/s 0.00 % 35.00 % mysqld
23456 be/4 root 1.00 MB/s 0.50 MB/s 0.00 % 10.00 % rsync
# ディスク容量の確認
$ df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda2 ext4 50G 35G 13G 73% /
/dev/sda3 xfs 49G 40G 9.0G 82% /home
/dev/sda1 ext4 976M 150M 760M 17% /boot
# inode使用率の確認
$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda2 3276800 1500000 1776800 46% /
/dev/sda3 3211264 2800000 411264 87% /home
# 大きなファイルの検索
$ sudo find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null | sort -k5 -hr | head -20
# ディレクトリごとの使用量
$ sudo du -sh /var/* | sort -hr | head -10
15G /var/lib
5.0G /var/log
2.0G /var/cache
500M /var/tmp
# ファイルシステムの整合性チェック
# ext4
$ sudo e2fsck -f /dev/sda2 # アンマウント状態で実行
# xfs
$ sudo xfs_repair /dev/sda3 # アンマウント状態で実行
# ディスクI/Oの詳細追跡（blktrace）
$ sudo blktrace -d /dev/sda -o - | blkparse -i -
8,0 0 1 0.000000000 12345 Q R 1234567 + 8 [mysqld]
8,0 0 2 0.000001000 12345 G R 1234567 + 8 [mysqld]
8,0 0 3 0.000002000 12345 D R 1234567 + 8 [mysqld]
8,0 0 4 0.002000000 12345 C R 1234567 + 8 [0]
8. ネットワークトラブルシューティング
# ソケットの確認
$ ss -tlnp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1234))
LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=2345))
LISTEN 0 128 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=2345))
# ss の主要オプション
# -t: TCP, -u: UDP, -l: リスニング, -n: 数値表示, -p: プロセス表示
# -s: 統計, -a: 全て, -4: IPv4のみ, -6: IPv6のみ
# 接続の統計
$ ss -s
Total: 350
TCP: 250 (estab 200, closed 10, orphaned 5, timewait 20)
Transport Total IP IPv6
RAW 1 0 1
UDP 15 10 5
TCP 240 200 40
INET 256 210 46
# TCP接続の状態分布
$ ss -tan | awk '{print $1}' | sort | uniq -c | sort -rn
200 ESTAB
20 TIME-WAIT
10 CLOSE-WAIT
5 FIN-WAIT-2
5 LISTEN
# パケットキャプチャ
$ sudo tcpdump -i eth0 -n port 80 -c 20
10:00:01.000000 IP 192.168.1.10.54321 > 192.168.1.100.80: Flags [S], seq 1234567
10:00:01.000100 IP 192.168.1.100.80 > 192.168.1.10.54321: Flags [S.], seq 2345678, ack 1234568
10:00:01.000200 IP 192.168.1.10.54321 > 192.168.1.100.80: Flags [.], ack 1
# ファイルに保存して後で分析
$ sudo tcpdump -i eth0 -w /tmp/capture.pcap -c 1000
$ tcpdump -r /tmp/capture.pcap -n | head -20
# ネットワーク到達性の確認
$ ping -c 4 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.534 ms
# traceroute / mtr
$ mtr -r -c 10 google.com
Start: 2024-01-15T10:00:00+0900
HOST: server1 Loss% Snt Last Avg Best Wrst StDev
1.|-- gateway 0.0% 10 0.5 0.6 0.4 1.0 0.2
2.|-- isp-router 0.0% 10 5.0 5.2 4.8 6.0 0.4
3.|-- google.com 0.0% 10 10.0 10.5 9.5 12.0 0.8
# ポートスキャン
$ nmap -sT -p 1-1000 192.168.1.100
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
3306/tcp open mysql
# 帯域幅テスト
$ iperf3 -s # サーバ側
$ iperf3 -c 192.168.1.100 -t 10 # クライアント側
[ 5] 0.00-10.00 sec 1.09 GBytes 935 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.09 GBytes 935 Mbits/sec receiver
# DNS の確認
$ dig google.com +short
142.250.80.46
$ dig @8.8.8.8 google.com
$ nslookup google.com
# ARP テーブル
$ ip neigh show
192.168.1.1 dev eth0 lladdr 00:11:22:33:44:55 REACHABLE
9. ブートトラブルシューティング
# ブートプロセスの分析
$ systemd-analyze
Startup finished in 3.500s (firmware) + 1.200s (loader) + 2.800s (kernel) + 15.500s (userspace) = 23.000s
graphical.target reached after 15.200s in userspace
$ systemd-analyze blame | head -10
10.500s NetworkManager-wait-online.service
3.200s plymouth-quit-wait.service
1.500s systemd-udev-settle.service
1.200s lvm2-monitor.service
0.800s firewalld.service
$ systemd-analyze critical-chain
graphical.target @15.200s
└─multi-user.target @15.200s
└─sshd.service @5.000s +0.100s
└─network.target @4.900s
# GRUB レスキュー
# GRUB メニューでの操作:
# 'e' キー: エントリの編集
# linux 行の末尾に追加:
# single → シングルユーザーモード
# rd.break → initramfs でシェルを取得
# systemd.unit=emergency.target → エマージェンシーモード
# systemd.unit=rescue.target → レスキューモード
# init=/bin/bash → bash で起動
# ルートパスワードのリセット
# 1. GRUB で 'e' を押して編集
# 2. linux 行の末尾に rd.break を追加
# 3. Ctrl+X でブート
# 4. initramfs シェルで:
switch_root:/# mount -o remount,rw /sysroot
switch_root:/# chroot /sysroot
sh-5.1# passwd root
sh-5.1# touch /.autorelabel # SELinux環境の場合
sh-5.1# exit
switch_root:/# reboot
# initramfs の再構築
$ sudo dracut --force # RHEL/CentOS
$ sudo update-initramfs -u # Ubuntu/Debian
# GRUB の再インストール
$ sudo grub2-install /dev/sda # RHEL (BIOS)
$ sudo grub2-install --target=x86_64-efi --efi-directory=/boot/efi # UEFI
$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
# Ubuntu
$ sudo grub-install /dev/sda
$ sudo update-grub
# ブートログの確認
$ journalctl -b # 現在のブート
$ journalctl -b -1 # 前回のブート
$ journalctl --list-boots
-2 xxxxxx Mon 2024-01-13 10:00:00 — Mon 2024-01-14 08:00:00
-1 yyyyyy Mon 2024-01-14 08:05:00 — Mon 2024-01-15 09:00:00
0 zzzzzz Mon 2024-01-15 09:05:00 — Mon 2024-01-15 10:00:00
# systemd のユニット失敗の確認
$ systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
nginx.service loaded failed failed nginx web server
postfix.service loaded failed failed Postfix Mail Transport Agent
$ systemctl status nginx.service
$ journalctl -u nginx.service --since "1 hour ago"
10. ログ分析
# journalctl - systemd ジャーナルの確認
# 基本的な使い方
$ journalctl # 全ログ
$ journalctl -f # リアルタイム追跡
$ journalctl -n 50 # 最新50行
$ journalctl --since "2024-01-15" # 日付指定
$ journalctl --since "1 hour ago" # 相対時間
$ journalctl -u sshd.service # 特定ユニット
$ journalctl -k # カーネルメッセージのみ
$ journalctl -p err # エラー以上の優先度
# 優先度レベル
# 0: emerg, 1: alert, 2: crit, 3: err, 4: warning, 5: notice, 6: info, 7: debug
# ログファイルの分析
$ tail -f /var/log/syslog # Ubuntu
$ tail -f /var/log/messages # RHEL
# 認証ログ
$ tail -f /var/log/auth.log # Ubuntu
$ tail -f /var/log/secure # RHEL
# 失敗したSSHログインの分析
$ grep "Failed password" /var/log/auth.log | \
awk '{print $11}' | sort | uniq -c | sort -rn | head -10
500 192.168.1.50
200 10.0.0.25
50 172.16.0.100
# ログの集計と分析
$ journalctl --since "1 hour ago" -p err --no-pager | \
awk '{for(i=6;i<=NF;i++) printf "%s ",$i; print ""}' | \
sort | uniq -c | sort -rn | head -10
# ログローテーションの確認
$ cat /etc/logrotate.d/syslog
/var/log/syslog
{
rotate 7
daily
missingok
notifempty
delaycompress
compress
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}
# ログの検索パターン
$ journalctl --since "2024-01-15 09:00" --until "2024-01-15 10:00" \
-u httpd -p warning..err --no-pager
11. コアダンプ分析の基礎
# コアダンプの設定確認
$ ulimit -c
0 # 0 = コアダンプ無効
# コアダンプの有効化
$ ulimit -c unlimited # 現在のシェルセッション
$ echo "* soft core unlimited" >> /etc/security/limits.conf # 永続化
# systemd でのコアダンプ設定
$ cat /etc/systemd/coredump.conf
[Coredump]
Storage=external
Compress=yes
ProcessSizeMax=2G
ExternalSizeMax=2G
# コアダンプの保存先
$ coredumpctl list
TIME PID UID GID SIG COREFILE EXE
Mon 2024-01-15 10:00:00 JST 12345 1000 1000 11 present /usr/bin/myapp
# コアダンプの情報表示
$ coredumpctl info 12345
PID: 12345
UID: 1000
GID: 1000
Signal: 11 (SEGV)
Timestamp: Mon 2024-01-15 10:00:00 JST
Command Line: /usr/bin/myapp --config /etc/myapp.conf
Executable: /usr/bin/myapp
# GDB でコアダンプを分析
$ coredumpctl gdb 12345
# または
$ gdb /usr/bin/myapp /var/lib/systemd/coredump/core.myapp.12345.xxx
(gdb) bt # バックトレース
#0 0x00007f1234567890 in strlen () from /lib64/libc.so.6
#1 0x0000555555555678 in process_request (req=0x0) at main.c:42
#2 0x0000555555555abc in main (argc=2, argv=0x7fffffffe000) at main.c:100
(gdb) bt full # 詳細なバックトレース（ローカル変数含む）
(gdb) info threads # スレッド情報
(gdb) thread apply all bt # 全スレッドのバックトレース
12. ランブックの作成
# ランブックテンプレート
## インシデント: [問題名]
### 概要
- 影響範囲: [サービス名、ユーザー数]
- 重要度: [Critical/High/Medium/Low]
- 最終更新: [日付]
### 症状
1. [症状1]
2. [症状2]
### 診断手順
1. サービスの状態確認
```bash
systemctl status [service]
- ログの確認
journalctl -u [service] --since "30 minutes ago" - リソースの確認
top -bn1 | head -20 free -mh df -h
復旧手順
- [手順1]
- [手順2]
- [手順3]
エスカレーション
- L1: [担当チーム/連絡先]
- L2: [担当チーム/連絡先]
- L3: [担当チーム/連絡先]
根本原因と予防策
- 根本原因: [説明]
- 予防策: [説明]
### 一般的なランブック例
```bash
# ランブック: ディスク容量不足
## 診断
$ df -h /
$ du -sh /var/* | sort -hr | head -10
$ find /var/log -name "*.log" -size +100M
## 即時対応
# 1. 古いログの削除
$ sudo journalctl --vacuum-size=500M
$ sudo find /var/log -name "*.gz" -mtime +30 -delete
# 2. パッケージキャッシュの削除
$ sudo dnf clean all # RHEL
$ sudo apt-get clean # Ubuntu
# 3. 一時ファイルの削除
$ sudo rm -rf /tmp/*
$ sudo rm -rf /var/tmp/*
## 恒久対策
# 1. ログローテーションの設定確認
# 2. ディスク使用量の監視設定
# 3. 必要に応じてディスクの拡張
13. トラブルシューティングツール比較表
| カテゴリ | ツール | 用途 | 推奨度 |
|---|---|---|---|
| システム情報 | uname, hostnamectl | OS/カーネル情報 | 高 |
| dmidecode | ハードウェア情報 | 高 | |
| lscpu | CPU情報 | 高 | |
| プロセス | ps, top, htop | プロセス監視 | 高 |
| strace | システムコール追跡 | 高 | |
| ltrace | ライブラリコール追跡 | 中 | |
| pgrep, pkill | プロセス検索/キル | 高 | |
| メモリ | free | メモリ使用状況 | 高 |
| vmstat | 仮想メモリ統計 | 高 | |
| smem | プロセス別メモリ使用量 | 中 | |
| slabtop | カーネルslabメモリ | 中 | |
| ディスク | iostat | I/O統計 | 高 |
| iotop | プロセス別I/O | 高 | |
| blktrace | ブロックI/O追跡 | 中 | |
| smartctl | ディスク健全性 | 高 | |
| ネットワーク | ss | ソケット情報 | 高 |
| tcpdump | パケットキャプチャ | 高 | |
| mtr | ネットワーク経路 | 高 | |
| nmap | ポートスキャン | 中 | |
| iperf3 | 帯域幅テスト | 中 | |
| ブート | systemd-analyze | ブート分析 | 高 |
| journalctl -b | ブートログ | 高 | |
| ログ | journalctl | systemdログ | 高 |
| /var/log/ | 従来のログファイル | 高 |
14. ベストプラクティス
トラブルシューティングの原則
-
仮説を立てて検証する: 闇雲にコマンドを実行せず、仮説に基づいて調査する。
-
変更を一つずつ行う: 複数の変更を同時に行うと、どの変更が効果があったか分からなくなる。
-
記録を残す: 調査手順、発見事項、実施した対策を記録する。
-
再現性を確認する: 問題が再現可能か確認し、根本原因の特定に役立てる。
-
最近の変更を確認する: 問題が発生する前に何が変更されたかを確認する。
-
エスカレーションのタイミングを見極める: 解決に時間がかかりすぎる場合は早めにエスカレーションする。
調査の優先順位
# 1. 影響範囲の把握
$ systemctl status <service>
$ pcs status # HAクラスタの場合
# 2. リソースの確認（USEメソッド）
$ uptime # ロードアベレージ
$ free -mh # メモリ
$ df -h # ディスク
$ iostat -xz 1 3 # ディスクI/O
# 3. エラーの確認
$ journalctl -p err --since "30 minutes ago"
$ dmesg | tail -20
# 4. 最近の変更の確認
$ last # ログイン履歴
$ rpm -qa --last | head -10 # パッケージの変更履歴
$ find /etc -mmin -60 -type f # 最近変更された設定ファイル
# 5. 詳細な調査
$ strace -p <PID>
$ tcpdump -i eth0 ...
15. 参考資料
書籍
- Brendan Gregg, "Systems Performance: Enterprise and the Cloud"
- Brendan Gregg, "BPF Performance Tools"
- Michael Kerrisk, "The Linux Programming Interface"
Webリソース
重要なディレクトリとファイル
| パス | 説明 |
|---|---|
/proc/ | プロセスとカーネル情報の仮想FS |
/sys/ | デバイスとドライバ情報の仮想FS |
/var/log/ | システムログディレクトリ |
/var/log/messages | 汎用システムログ (RHEL) |
/var/log/syslog | 汎用システムログ (Ubuntu) |
/var/log/auth.log | 認証ログ (Ubuntu) |
/var/log/secure | 認証ログ (RHEL) |
/var/log/kern.log | カーネルログ |
/var/log/dmesg | ブート時のカーネルメッセージ |
ドキュメント情報:
- 作成日: 2024年1月
- 対象: Linux トラブルシューティング方法論とツール
- バージョン: 1.0
- 著者: AI Generated Technical Documentation