✍️ この記事を書いたきっかけ

文系出身でIT業界に入り、最初に携わったのはシステムの保守フェーズでした。

入社してすぐ、Linuxコマンドは一通り勉強しました。
ls、grep、chmod……頭では知っている。でも、いざ現場で問題が起きると手が止まってしまっていました。
「エラーログって、どこを見ればいいの？」
「サーバーが重いって言われたけど、何を確認すれば……？」

そのとき痛感したのが、「知っている」と「使える」は全然違うということでした。
コマンドを覚えるだけでなく、「この症状のときに、何を、どの順番で確認するか」 という体験が圧倒的に足りていませんでした。

この記事では、インフラ現場でよく遭遇するログ調査とリソース監視に絞り、「症状 → 調査 → 対処」の流れをまるごと体験できる演習を作成してみました。
トラブルシューティングの第一歩として、お役に立てれば幸いです。🌱

🎮 基本コマンドの練習には「エンベーダー」がおすすめ

この記事はトラブルシューティングの実践演習にフォーカスしているため、以下のような基本操作は扱いません。

ファイル・ディレクトリ操作（ls / mkdir / cp / mv など）
テキスト処理（grep / awk / sed）
プロセス・権限管理（ps / kill / chmod）

これらは、 エンベーダー でも練習できるので、試してみてください。

エンベーダーはエンジニア予備軍のための ITインフラ学習ゲームで、ブラウザ上で1クリックするだけで自分専用のLinux環境が起動し、環境構築不要でハンズオン演習を始められます。Linux入門・基礎コースは無料で利用できます。

🎮 エンベーダーで補える内容

ファイル・ディレクトリ操作
テキスト処理（grep / awk / sed）
プロセス・権限管理
パイプ・リダイレクト

📖 この記事で扱う内容

✅ ログ調査・エラー体験
✅ リソース監視（CPU / メモリ / ディスク）

👀 この記事の対象読者

基本コマンドは一通り知っているが、現場で使いこなせていない方
「障害対応」「ログ調査」「リソース監視」の流れを体験してみたい方

🖥️ 前提環境

Windows 10 / 11 に WSL2 がインストール済み（Ubuntu 推奨）
起動方法：スタートメニューで Ubuntu を検索またはコマンドプロンプトで wsl を実行

WSL のインストール方法は Microsoft 公式ドキュメントを参照してください。

💪 余裕がある方へ：今回は手軽に始められる WSL を利用していますが、より本番に近い環境で挑戦したい場合は、VirtualBox + Ubuntu の仮想マシンを構築してみてください。systemd によるサービス管理やネットワーク設定なども体験できるため、インフラの理解がさらに深まります。

📚 演習の構成

レベル	テーマ	目安時間
🔴 Lv.1	ログ調査・エラー体験（総合演習）
🟣 Lv.2	リソース監視（CPU・メモリ・ディスク）

各問題は ヒント → 回答 の折りたたみ形式になっています。
まずは自分で考えてから開いてみましょう！

💡 コマンドのオプションは暗記しなくてOKです。
わからないオプションがあれば grep --help や df --help のように --help を付けて実行すると、使い方の一覧が確認できます。「なんとなく知っている」状態で手を動かしながら覚えていくのが一番の近道です。

🔴 Lv.1：ログ調査・エラー体験

💼 シナリオ：深夜にアラートが来ました。「Webサーバーが起動しない」という報告です。
WSL上でエラーを意図的に再現し、ログ調査から原因特定までの流れを体験しましょう。

🔧 事前準備：エラーシナリオを作成する

以下のコマンドをコピペで上から順に実行してください。
演習で使うディレクトリとログファイルを作成します。

① 演習用ディレクトリを作成する

# logs（ログ置き場）と config（設定ファイル置き場）ディレクトリを一括作成
# -p オプションで、存在しない中間ディレクトリも含めて一気に作れる
mkdir -p ~/training/app/logs ~/training/app/config

作成できたか確認してみましょう：

ls ~/training/app/
# → config  logs  と表示されればOK

② 演習用のシステムログを作成する

実際のサーバーで起動失敗が発生したときのログを模擬したファイルを作成します。
cat << 'EOF' > ファイル名 は、EOF と書くまでの間に入力した内容をそのままファイルに書き込むコマンドです。

# system.log という名前で、以下の内容のログファイルを作成する
cat << 'EOF' > ~/training/app/logs/system.log
Apr  1 09:00:01 myhost systemd[1]: Starting Web Application Server...
Apr  1 09:00:02 myhost app[1234]: Loading configuration from /etc/app/config.yml
Apr  1 09:00:02 myhost app[1234]: ERROR: Config file not found: /etc/app/config.yml
Apr  1 09:00:02 myhost app[1234]: Falling back to default configuration
Apr  1 09:00:03 myhost app[1234]: INFO: Binding to port 8080
Apr  1 09:00:03 myhost app[1234]: ERROR: Address already in use: port 8080
Apr  1 09:00:03 myhost systemd[1]: app.service: Main process exited, code=exited, status=1/FAILURE
Apr  1 09:00:03 myhost systemd[1]: Failed to start Web Application Server.
Apr  1 09:05:00 myhost systemd[1]: app.service: Scheduled restart job, restart counter is at 3
Apr  1 09:05:01 myhost app[1235]: ERROR: Max restart attempts reached. Giving up.
EOF

作成できたか確認してみましょう：

ls ~/training/app/logs/
# → system.log と表示されればOK

💡 ここまでの準備でできたもの

~/training/
└── app/
    ├── logs/
    │   └── system.log  ← 演習で調査するログファイル
    └── config/         ← 設定ファイル置き場（今回は空でOK）

📝 問題 1-1：何が起きているのかを把握しよう

まず system.log を見て、「このログには何が記録されているのか」を自分なりに把握してください。

ファイルの内容を行番号付きで表示し、全体を確認してください
エラーが何件・何行目に記録されているか確認してください
次の問いに自分の言葉で答えてみてください
- このログはどんな処理の記録だと思いますか？
- エラーはどのタイミングで発生していますか？

💡 コマンドの正解よりも、「ログを見て何が起きているか説明できる」ことがゴールです。
わからないオプションは cat --help や grep --help で確認しながら進めてください。

💡 ヒント

cat -n で行番号付き表示、grep -c で件数カウント、grep -n で行番号付き検索ができます。

✅ 回答・解説

# 行番号付きでファイル全体を表示
cat -n ~/training/app/logs/system.log

出力例：

     1  Apr  1 09:00:01 myhost systemd[1]: Starting Web Application Server...
     2  Apr  1 09:00:02 myhost app[1234]: Loading configuration from /etc/app/config.yml
     3  Apr  1 09:00:02 myhost app[1234]: ERROR: Config file not found: /etc/app/config.yml
     4  Apr  1 09:00:02 myhost app[1234]: Falling back to default configuration
     5  Apr  1 09:00:03 myhost app[1234]: INFO: Binding to port 8080
     6  Apr  1 09:00:03 myhost app[1234]: ERROR: Address already in use: port 8080
     7  Apr  1 09:00:03 myhost systemd[1]: app.service: Main process exited, code=exited, status=1/FAILURE
     8  Apr  1 09:00:03 myhost systemd[1]: Failed to start Web Application Server.
     9  Apr  1 09:05:00 myhost systemd[1]: app.service: Scheduled restart job, restart counter is at 3
    10  Apr  1 09:05:01 myhost app[1235]: ERROR: Max restart attempts reached. Giving up.

# エラーの件数と行番号を確認
grep -c "ERROR" ~/training/app/logs/system.log
grep -n "ERROR" ~/training/app/logs/system.log

出力例：

3
3:Apr  1 09:00:02 myhost app[1234]: ERROR: Config file not found: /etc/app/config.yml
6:Apr  1 09:00:03 myhost app[1234]: ERROR: Address already in use: port 8080
10:Apr  1 09:05:01 myhost app[1235]: ERROR: Max restart attempts reached. Giving up.

自分の言葉で説明できる状態のイメージ：

「Webアプリを起動しようとしたログで、起動処理中に3件のエラーが発生している。
エラーは3行目・6行目・10行目に記録されており、起動の最初のほうで発生している。」

行番号表示コマンドの使い分け：

コマンド	特徴	使う場面
`cat -n`	全行を行番号付きで表示	ファイル全体を確認したい
`grep -n`	検索結果の行だけ行番号付きで表示	特定の文字列が何行目にあるか調べたい
`grep -c`	マッチした行数だけ数値で表示	件数だけ素早く知りたい

📝 問題 1-2：最初のエラーを起点に前後の動作を読み取ろう

エラーが複数あるとき、「どれが最初に起きたか」を特定することが重要です。
最初のエラーを起点に、その前後でどんな動作・処理が走っていたかを読み取ってください。

最初のエラーだけを表示してください
そのエラーの前後3行も含めて表示してください
次の問いに自分の言葉で答えてみてください
- 最初のエラーが起きる直前、アプリは何をしようとしていましたか？
- エラーが起きた後、アプリはどんな動作をとりましたか？

💡 ヒント

grep ... | head -1 で最初の1件だけ取得できます。
grep -B3 -A3 でマッチした行の前後3行も一緒に表示できます。

✅ 回答・解説

# 最初のエラーだけ表示
grep "ERROR" ~/training/app/logs/system.log | head -1

出力：

Apr  1 09:00:02 myhost app[1234]: ERROR: Config file not found: /etc/app/config.yml

# 前後3行も含めて表示
grep -B3 -A3 "Config file not found" ~/training/app/logs/system.log

出力例：

Apr  1 09:00:01 myhost systemd[1]: Starting Web Application Server...   ← 起動開始
Apr  1 09:00:02 myhost app[1234]: Loading configuration from /etc/app/config.yml   ← 設定ファイルを読もうとした
Apr  1 09:00:02 myhost app[1234]: ERROR: Config file not found: /etc/app/config.yml   ← ★ 最初のエラー
Apr  1 09:00:02 myhost app[1234]: Falling back to default configuration   ← デフォルト設定に切り替えた
Apr  1 09:00:03 myhost app[1234]: INFO: Binding to port 8080   ← ポート 8080 で起動を試みた
Apr  1 09:00:03 myhost app[1234]: ERROR: Address already in use: port 8080   ← 次のエラーへ

自分の言葉で説明できる状態のイメージ：

「起動直後に設定ファイルを読みに行ったが見つからなかった（3行目・最初のエラー）。
4行目に Falling back to default configuration とあるので、デフォルト設定に切り替えて起動を続けようとしたとわかる。
その後ポート8080で起動を試みたが（5行目）、すでに使われていて次のエラーにつながっている（6行目）。」

ポイント：

前後を見ることで「1つのエラーが次のエラーを引き起こす連鎖」が見えてくる
-B3（before）・-A3（after）の数字は状況に応じて増やして確認するとよい

📝 問題 1-3：原因を特定して、次の対応を判断しよう

ここまでの調査で「設定ファイルが見つからない」「ポート 8080 が使用中」という2つのエラーが確認できました。
さらに掘り下げて、何が根本的な原因かを整理し、次にどんな対応をとるべきかを考えてください。

systemd が記録した行を抽出して、サービス全体としての結末を確認してください
ポート 8080 の使用状況を確認してください
次の問いに自分の言葉で答えてみてください
- このログから読み取れる根本的な原因は何だと思いますか？
- 次にどんな対応をとるべきだと思いますか？（プロセスのさらなる調査・設定修正・他への確認など）

💡 ヒント

grep "systemd" でsystemdの行を抽出できます。
ss -tlnp でポートの使用状況を確認できます。
ポート競合が確認できたら、そのプロセスを ps aux でさらに調べることもできます。

✅ 回答・解説

# systemd の記録を確認してサービスの結末を把握する
grep "systemd" ~/training/app/logs/system.log

出力例：

Apr  1 09:00:01 myhost systemd[1]: Starting Web Application Server...
Apr  1 09:00:03 myhost systemd[1]: app.service: Main process exited, code=exited, status=1/FAILURE
Apr  1 09:00:03 myhost systemd[1]: Failed to start Web Application Server.
Apr  1 09:05:00 myhost systemd[1]: app.service: Scheduled restart job, restart counter is at 3

起動失敗後も自動再起動を3回試み、最終的に「Max restart attempts reached. Giving up.」で諦めていることがわかります。

# ポート 8080 の使用状況を確認
ss -tlnp | grep 8080

# 何も表示されなければ全ポートを確認
ss -tlnp

⚠️ WSL 環境での注意：今回の演習ではポート 8080 を実際に使用するプロセスを起動していないため、ss の結果には何も表示されません。これはあくまで「ログからポート競合が疑われた場合に、このコマンドで実際の使用状況を確認する」という手順を体験するための演習です。実際の現場では、ここで別のプロセスが表示されることがあります。

ss -tlnp オプションの意味：

オプション	意味
`-t`	TCP のみ表示
`-l`	LISTEN 状態のみ表示
`-n`	ポート番号を数値で表示
`-p`	プロセス情報を表示

自分の言葉で説明できる状態のイメージ：

ログの各行が根拠になっています。どの行からどう読み取れるかを意識しながら確認してみてください。

（3行目）ERROR: Config file not found: /etc/app/config.yml
  → 設定ファイルが存在しない、またはパスが間違っていることがわかる（最初のエラー）

（4行目）Falling back to default configuration
  → 設定ファイルが見つからなかったため、デフォルト設定に切り替えたことがわかる

（6行目）ERROR: Address already in use: port 8080
  → デフォルト設定でポート8080を使おうとしたが、すでに使用中だったことがわかる

（9行目）Scheduled restart job, restart counter is at 3
  → 失敗後に自動再起動を試みたが、すでに3回目であることがわかる

（10行目）ERROR: Max restart attempts reached. Giving up.
  → 再起動の上限に達し、サービスが停止したことがわかる

「設定ファイルが見つからず（3行目）、4行目の Falling back to default configuration からデフォルト設定に切り替えたとわかる。ポート8080で起動を試みたが使用中で失敗（6行目）。自動再起動を繰り返したが上限に達し、サービスが停止した（10行目）。」

次の対応として考えられること：

確認・対応内容	理由
ポート8080を使っているプロセスを `ps aux` で詳細調査	意図しないプロセスが残っている可能性がある
設定ファイル `/etc/app/config.yml` の存在・パスを確認	本来あるべきファイルがない・パスが間違っている可能性がある
上記を確認・修正後にサービスを再起動	根本原因を解消してから再起動しないと同じ失敗を繰り返す
対応内容をチームに報告	同じ現象が別の場所でも起きていないか共有する

ポイント：

ログはあくまで「結果」を記録したもの。「なぜその状態になったか」を推測するのが調査の本質
複数のエラーがあるときは「どれが最初か」「どれが連鎖して起きているか」を意識する
修正前に必ず現状をチームに共有し、独断で本番環境を変更しないことが鉄則

🗺️ ログ調査の流れ（まとめ）

① 全体把握       → ログ全体を行番号付きで確認し、エラーの件数・場所を把握する
      ↓
② 起因の特定     → 最初のエラーはどこか、何がきっかけで発生したか
      ↓
③ 前後を読む     → エラーの前後でどんな動作・処理が走っていたかを確認する
      ↓
④ 原因を整理     → エラーの連鎖を整理し、根本的な原因がどこにあるかを考える
      ↓
⑤ 次の対応を判断 → プロセスのさらなる調査か、設定修正か、他サービスへの確認か
      ↓
⑥ 対処・記録     → 修正実施 → 再発防止策とともにチームに共有

🟣 Lv.2：リソース監視

🔍 症状から要因を絞り込む考え方

同じ「サーバーが遅い」という症状でも、原因はさまざまです。
まず症状から考えられる要因を洗い出し、優先度の高いものから順にコマンドで確認していきます。

【症状の例】
「アプリのレスポンスが遅い・返ってこない」
        ↓
【考えられる要因】
 ① CPU が高負荷（処理が詰まっている）
 ② メモリ不足（スワップが発生して遅くなっている）
 ③ ディスク枯渇（ログが書けずアプリが止まっている）
 ④ 不要なプロセスが残存してリソースを奪っている
        ↓
【絞り込みの手順】
 まず全体を把握 → 数値を見て原因を特定 → 対処

症状	まず疑うべき要因	最初に確認するコマンド
アプリが遅い・応答しない	CPU 過負荷 / メモリ不足	`top`
アプリが突然落ちる	メモリ不足（OOM）	`free -h`
ログファイルが書き込めない	ディスク枯渇	`df -h`
サービスが起動できない	ポート競合 / ディスク枯渇	`ss -tlnp` / `df -h`
特定の時間帯だけ重くなる	バッチ処理・定期ジョブの重複	`ps aux` / `top`

⚠️ 調査時の心構え：1つの原因にフォーカスしすぎない

リソース監視コマンドで確認できるのは、あくまでそのサーバー自身の状態です。
しかし実際の現場では、サーバー単体に問題がなくても遅延や障害が起きることがあります。

たとえば「アプリの応答が遅い」という症状でも、原因はこんな場所にあることもあります：

原因の場所	具体例
サーバー内部	CPU 高負荷・メモリ不足・ディスク枯渇
ネットワーク	スイッチ・ルーターの障害、帯域不足、パケットロス
外部サービス	連携している DB サーバーや API の応答遅延
ストレージ	共有ストレージや NAS の I/O 詰まり

最初から「CPU が原因に違いない」と決めつけてしまうと、本当の原因を見落とすリスクがあります。
まずはサーバー内部のリソースを数値で確認したうえで「サーバーは問題なさそう」と判断できたら、次はネットワークや周辺機器・外部サービスへと視野を広げていくのが現場でのセオリーです。

また、コマンドで調査を始める前に報告者へのヒアリングも欠かせません。
「いつから発生しているか」「どんな操作をしたときに起きるか」「特定のユーザーや時間帯だけか」といった発生条件を事前に把握しておくことで、調査の優先順位が大きく変わります。

ヒアリング項目	絞り込みに役立つ理由
いつから発生しているか	直前のリリースや変更作業との関連を確認できる
常時か・特定条件のみか	常時なら負荷系、特定条件なら設定・連携系を疑う
特定のユーザーだけか	権限・設定の問題に絞り込める
他のサービスも影響を受けているか	ネットワークや共有リソースの問題を疑う手がかりになる

💡 「サーバーのリソースは正常なのに遅い」というケースは意外と多いです。
ヒアリングで発生条件を絞り、コマンドで数値を確認しながら消去法で原因に近づく姿勢が大切です。

💼 シナリオ：「最近サーバーの動きが重い、アプリも不安定」という報告が来ました。
症状をもとに要因を1つずつ絞り込み、原因を特定して対処する流れを体験しましょう。

🔧 事前準備：高負荷・ディスク圧迫シナリオを作成する

以下のコマンドをコピペで上から順に実行してください。
CPU高負荷・メモリ高使用・ディスク圧迫が同時に起きている状況を意図的に作り出します。

① 演習用ディレクトリを作成する

# Lv.1 からの続きで ~/training/app/ がすでにある場合はスキップしてOK
mkdir -p ~/training/app/logs ~/training/app/config

② CPU に高負荷をかけるプロセスを起動する

# yes コマンドは「y」を無限に出力し続け、CPU を使い切る
# > /dev/null で出力を捨てることでターミナルが埋まらないようにしている
# 末尾の & はバックグラウンドで実行する指定（ターミナルを占有しない）
yes > /dev/null &
yes > /dev/null &

起動できたか確認してみましょう：

ps aux | grep yes | grep -v grep
# → yes が2行表示されればOK

③ メモリを大量消費するプロセスを起動する

# Python で 512MB のデータをメモリ上に実際に確保し続けるプロセスを起動する
# data[0] = 1 でメモリページを実際に使用済みにする（これがないと OS がページを確保しない）
python3 -c "
import time, sys
data = bytearray(512 * 1024 * 1024)
data[0] = 1
sys.stdout.write('ready\n')
sys.stdout.flush()
time.sleep(3600)
" &

起動できたか確認してみましょう：

free -h
# → used の値が 500MB 前後増えていればOK

⚠️ WSL のスワップについて：WSL 環境ではスワップが無効になっている場合があります（Swap: 0B 0B 0B）。その場合でも free -h の used が増加した状態でメモリ高使用の状態は確認できます。

④ ディスクを圧迫するダミーファイルを作成する

# dd コマンドでゼロ埋めのダミーファイルを作成する
# bs=1M：1回の書き込みサイズ（1MB）  count=50：50回繰り返す → 合計50MBのファイル
# 2>/dev/null は dd の進捗メッセージを非表示にしている
dd if=/dev/zero of=~/training/app/logs/large_log.bin bs=1M count=50 2>/dev/null

# 同様に 10MB、5MB のファイルも作成
dd if=/dev/zero of=~/training/app/logs/medium_log.bin bs=1M count=10 2>/dev/null
dd if=/dev/zero of=~/training/app/config/backup.bin bs=1M count=5 2>/dev/null

作成できたか確認してみましょう：

du -ah ~/training/app | sort -rh
# → 50M, 10M, 5M のファイルが表示されればOK

⚠️ 注意：yes プロセスと Python プロセスは演習後も動き続けます。末尾の「後片付け」を必ず実行してください。

📝 問題 2-1：3コマンドでサーバーの全体状態を把握しよう

【場面】 「サーバーが重い、アプリも不安定」という報告を受けました。
何が原因かはまだ分からない状況とします。
まず CPU・メモリ・ディスクの3つを確認して、今サーバーがどんな状態かを数値で把握してください。

CPU・メモリの使用状況をリアルタイムで確認してください
メモリの残量・スワップ発生の有無を確認してください
ディスクの使用率を確認してください

確認できたら、次の問いに自分の言葉で答えてみてください：

今のサーバーはどんな状態ですか？
問題がありそうな箇所はどこですか？

💡 ヒント

top・free -h・df -h の3コマンドが全体把握の基本セットです。

✅ 回答・解説

# 1. CPU・メモリをリアルタイムで確認（q で終了）
top

top 画面の読み方（上部の要約欄）：

%Cpu(s): 98.0 us,  1.0 sy,  0.0 ni,  0.0 id

項目	意味	要注意の目安
`us`（user）	ユーザープロセスの CPU 使用率	80% 超で要確認
`id`（idle）	CPU の空き率	10% 未満で高負荷状態

今回の演習では yes プロセスが CPU をほぼ使い切っているため、us が高い・id がほぼ 0 の状態が確認できます。

# 2. メモリ・スワップの残量を確認
free -h

演習時の出力イメージ：

              total        used        free      shared  buff/cache   available
Mem:           15Gi       13Gi       500Mi        50Mi       1.5Gi       1.2Gi
Swap:         4.0Gi       1.0Gi       3.0Gi

列	意味	要注意の目安
`available`	実際に使えるメモリ残量	total の 20% 未満で注意
`Swap used`	スワップ使用量	0 より大きければメモリ不足のサイン（本番環境で確認）

Python プロセスが 512MB を確保しているため、used が増加・available が減少している状態が確認できます。

⚠️ WSL2 ではスワップが無効な場合が多く、Swap: 0B 0B 0B と表示されることがあります。これは WSL の仕様によるもので、本番の Linux サーバーでは used が増えるとスワップが発生し始めます。

# 3. ディスク使用率を確認
df -h

出力例：

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb        251G  230G   21G  92% /

`Use%` の目安	状態
～70%	🟢 正常
70～85%	🟡 やや多め・監視が必要
85～95%	🟠 要対応
95%以上	🔴 危険・障害が起きやすい

ダミーファイルによりディスク使用量が増加した状態が確認できます。

自分の言葉で説明できる状態のイメージ：

「CPU 使用率が異常に高く（top）、メモリの空きが少なく（free -h）、さらにディスク使用率も高い（df -h）。3つとも要注意な状態で、それぞれ原因の調査が必要。」

ポイント：

まずこの3コマンドで全体を把握し、異常な箇所を確認してから問題2-2以降に進みましょう
複数の箇所が同時に異常なこともある。1つを直しても改善しない場合は他の要因も見ること

📝 問題 2-2：🔥【CPU使用率が高い】原因プロセスを特定して止めよう

【場面】 問題2-1の top で CPU 使用率が異常に高いことを確認しました。
次は「どのプロセスが原因か」を特定し、停止します。

💡 要因の絞り込み：CPU が高い → 何かのプロセスが処理を占有している → どのプロセスかを特定する

CPU 使用率の高いプロセス上位5件を表示してください
原因プロセス（yes）を停止してください
停止後、CPU 使用率が下がったことを確認してください

💡 ヒント

ps aux --sort=-%cpu で CPU 使用率の高い順に表示できます。

✅ 回答・解説

# 1. CPU 使用率の高いプロセス上位5件を確認
ps aux --sort=-%cpu | head -6

出力例（停止前）：

USER   PID  %CPU %MEM  COMMAND
user  2345  99.5  0.0  yes
user  2346  99.3  0.0  yes
user   123   0.1  0.5  bash

yes プロセスが CPU のほぼ全てを消費しているとわかりました。

# 2. プロセスを停止
pkill yes

# 個別に止める場合（PID を指定）
kill 2345

# 3. 停止後の確認
ps aux --sort=-%cpu | head -6
# → yes が消えて CPU が下がっていればOK

【今回の演習シナリオの場合】
原因：yes プロセスが2つバックグラウンドで動き続け、CPU を使い切っていた
対処：pkill yes で停止

【一般的な対応策】

状況	考えられる原因	対処
見覚えのないプロセスが高消費	不正プロセス・誤操作	`kill` で停止しログで経緯を確認
正規アプリが高消費	処理の無限ループ・バグ	再起動を検討・担当者に報告
複数プロセスが同時に高消費	バッチ処理の重複起動	スケジュール設定を確認

ポイント：

ps aux --sort=-%cpu の -%cpu の - は降順ソートを意味する
本番では kill の前に必ずプロセスの正体を確認してから止める

📝 問題 2-3：💾【メモリ使用率が高い】何がメモリを使っているか特定しよう

【場面】 問題2-1の free -h でメモリの used が増加していることを確認しました。
何がメモリを大量消費しているかを特定します。

💡 要因の絞り込み：メモリの used が多い → 何かのプロセスがメモリを大量消費している → どのプロセスかを特定する

メモリ消費量の多いプロセス上位5件を表示してください
原因プロセスを停止してください
停止後、メモリの空きが回復したことを確認してください

⚠️ WSL 環境での制約について
WSL2 では「スワップが発生するほどのメモリ不足」を再現することは難しい状況です。
この演習では「メモリを消費しているプロセスを特定して kill で解放する」という体験に集中します。

💡 ヒント

ps aux --sort=-%mem でメモリ使用率の高い順に表示できます。
free -h でメモリの回復を確認できます。

✅ 回答・解説

# 1. メモリを多く使っているプロセスを上位5件確認
ps aux --sort=-%mem | head -6

出力例：

USER   PID  %CPU %MEM  VSZ      RSS      COMMAND
user  4567   0.0  3.2  534000  524288   python3
user   123   0.0  0.5  640000   85000   bash

列	意味
`%MEM`	物理メモリの使用率
`RSS`	実際に使っているメモリ量（KB）

python3 プロセスが大量のメモリを確保していることが確認できます。

# 2. プロセスを停止（PID は環境によって異なる）
kill 4567

# プロセス名で止める場合
pkill -f "bytearray"

# 3. 停止後にメモリの回復を確認
free -h
# → used が減り、available が増えていればOK

【今回の演習シナリオの場合】
原因：Python プロセスが 512MB のメモリを確保し続けていた
対処：プロセスを kill で停止することでメモリが解放される

【スワップとは（概念として）】
メモリが足りなくなったとき、ディスクの一部をメモリの代わりに使う仕組みです。
ディスクはメモリより大幅に遅いため、スワップが増えるほどシステム全体が遅くなります。
free -h の Swap used が 0 より大きければメモリ不足のサインです。

Swap: 4.0Gi  1.5Gi  2.5Gi
              ^^^^
              0 より大きい = メモリ不足が発生している（本番環境で確認）

【一般的な対応策】

状況	考えられる原因	対処
特定のアプリがメモリを占有	メモリリーク・設定ミス	アプリ再起動・担当者に報告
スワップが大量発生している	全体的なメモリ不足	不要プロセスを停止・メモリ増設を検討
OOM でプロセスが落ちている	メモリ上限を超えた	ログで `Out of memory` を確認し原因アプリを特定

📝 問題 2-4：📂【ディスク使用率が高い】容量を食っているファイルを特定して整理しよう

【場面】 問題2-1の df -h でディスク使用率が高いことを確認しました。
このままではログが書き込めなくなりアプリが停止します。何が容量を使っているかを特定して対処します。

💡 要因の絞り込み：ディスクが高い → どのディレクトリ・ファイルが容量を食っているか → 削除・整理で対応

~/training 配下でサイズの大きいファイル上位5件を特定してください
~/training/app/logs/ の .bin ファイルを安全に削除してください
削除後にディスク使用量が減ったことを確認してください

💡 ヒント

du -ah | sort -rh でサイズの大きい順に一覧表示できます。
削除前に ls で対象を必ず確認しましょう。

✅ 回答・解説

# 1. サイズの大きいファイルを上位5件特定
du -ah ~/training | sort -rh | head -5

出力例：

65M  /home/user/training/app/logs
50M  /home/user/training/app/logs/large_log.bin
10M  /home/user/training/app/logs/medium_log.bin
 5M  /home/user/training/app/config/backup.bin

# 2. 削除前に対象ファイルを必ず目視確認してから削除
ls -lh ~/training/app/logs/*.bin
rm ~/training/app/logs/*.bin

# 3. 削除後のディスク使用量を確認
du -ah ~/training | sort -rh | head -5
df -h

【今回の演習シナリオの場合】
原因：dd コマンドで作成した大容量のダミーファイルがディスクを圧迫していた
対処：不要ファイルを確認・削除してディスク使用量を回復させる

【一般的な対応策】

要因	確認場所	対策
ログの肥大化	`/var/log/` や `app/logs/`	古いログを圧縮・削除
コアダンプファイル	`/var/crash/` や `/tmp/`	確認して削除
一時ファイルの蓄積	`/tmp/`	不要ファイルを定期削除
バックアップの世代管理なし	バックアップ先ディレクトリ	保持世代数を決めてローテーション

ポイント：

du でどのディレクトリが大きいかを上位から掘り下げ、犯人ファイルを特定する
削除前の ls 確認は必須。ワイルドカードは予想外のファイルに当たる場合がある

🧹 後片付け

# yes プロセスを停止
pkill yes 2>/dev/null

# Python メモリ確保プロセスを停止
pkill -f "bytearray" 2>/dev/null

# ダミーファイルを削除
rm -f ~/training/app/logs/*.bin
rm -f ~/training/app/config/backup.bin

# 後片付けの確認
echo "--- プロセス確認 ---"
ps aux | grep -E "yes|bytearray" | grep -v grep
echo "--- メモリ確認 ---"
free -h
echo "--- ディスク確認 ---"
du -ah ~/training

🗺️ 症状から原因を絞り込む調査フロー（まとめ）

【症状報告】「サーバーが重い・アプリが不安定・起動しない」
      ↓
① 全体把握（数値で現状を確認）
   top     → CPU 使用率・プロセス全体の状態
   free -h → メモリ残量・スワップ発生の有無
   df -h   → ディスク使用率
      ↓
② 症状ごとに要因を絞り込む
   CPU が高い    → ps aux --sort=-%cpu で重いプロセスを特定
                    └ kill / pkill で停止
   スワップが出る → ps aux --sort=-%mem でメモリを食うプロセスを特定
                    └ kill で停止 / 改善しなければ再起動・増設を検討
   ディスクが高い → du -ah | sort -rh で容量を食うファイルを特定
                    └ rm で削除（削除前に ls で確認）
      ↓
③ 再確認・報告
   top / free -h / df -h で改善されたか確認
   対応内容をチームに共有・記録

🎓 この演習で使ったコマンド一覧

コマンド	使い方のポイント	現場での活用場面
`cat -n`	行番号付きでファイルを表示	ログ全体を行番号つきで確認
`grep -c`	マッチした行数だけカウント	エラー件数の素早い把握
`grep -n`	検索結果に行番号を付与	該当行が何行目か即座に確認
`grep -B / -A`	マッチ行の前後N行も表示	エラーの前後の文脈を把握
`grep -E`	正規表現で複数条件検索	OR条件での絞り込み
`sort \| uniq -c`	値ごとに集計	ログ種別の件数まとめ
`ss -tlnp`	ポート使用状況を確認	ポート競合の調査
`top`	CPU・メモリをリアルタイム監視	高負荷プロセスの特定
`free -h`	メモリ使用状況を確認	スワップ発生・メモリ不足の調査
`df -h`	ディスク全体の使用状況を確認	ディスク枯渇の早期発見
`du -ah`	ディレクトリ・ファイルの容量を確認	容量を食っているファイルの特定

🔗 参考リンク