Linux サーバーの運用において、リアルタイムな状態変化を正確に捉えることは、障害対応の成否を分ける鍵となります。単発のコマンド実行では見逃されがちな瞬間的な負荷 spikes やリソース枯渇の兆候を、watch コマンドの差分ハイライト機能（-d）を活用して可視化することで、人間の目による検出精度を飛躍的に向上させられます。

watch -d の本質的価値：静的ビューで動的変化を読み取る

watch -n 1 -d "command" を用いることで、画面が固定されたまま更新され、変化した数値のみが反転表示されます。これは単なる自動更新ではなく、「変化そのもの」を視覚的に抽出する分析手法です。平均値や累積値ではなく、瞬時値の推移に焦点を当てた診断が可能になります。

ケーススタディ①：全体的なレスポンス低下 — メモリ・CPU・I/O の総合評価

vmstat を用いたシステム全体の健康診断：

watch -n 1 -d "vmstat -w -Sm 1 1"

• r（実行待ちプロセス数）：論理CPU数を超えて継続的に増加 → CPU スケジューリングボトルネック
• swpd：Swap 使用量が増加傾向 → 物理メモリ不足のサイン（OOM 発生リスク）
• cs（コンテキストスイッチ）：1秒あたり10万回以上 → 過度なスレッド生成／ロック競合（例：Go の goroutine leak）
• wa（I/O wait）：20%超 → 磁気ディスクや低速ストレージへの依存が疑われる

ケーススタディ②：全体CPU利用率が低いにもかかわらず遅延 — 単一コアの過負荷検出

mpstat を用いて各CPUコアの負荷分布を確認：

watch -n 1 -d "mpstat -P ALL 1 1"

• %usr が特定コア（例：CPU 0）で100%に達し、他のコアはほぼアイドル → シングルスレッドアプリ（Redis, Nginx worker）やIRQ処理の偏りが原因
• %soft（ソフト割り込み）が突出 → NICのRSS設定不備または irqbalance の無効化により、ネットワークパケット処理が単一コアに集中

ケーススタディ③：DB応答遅延やログ書き込み停滞 — ストレージレイヤーの深層解析

iostat でデバイス単位のI/O特性を精査：

watch -n 1 -d "iostat -dxzm -y 1 1"

• %util：100%に近い値は物理I/O能力の限界を示すが、SSDでは補助指標が必要
• aqu-sz（平均I/Oキュー長）：>1 → キュー待ち開始、>10 → 深刻なボトルネック（アプリケーションレイテンシ急増）
• await（平均応答時間）：SSDで1–3msを超える → ディスク障害、キャッシュ枯渇、クラウドストレージのQoS制限など

ケーススタディ④：ネットワーク帯域飽和 — 流量源の即時特定

iftop を非対話モードで活用：

watch -n 2 "iftop -t -s 1 -n -N -P | head -n 20"

• 上位数行に表示される Local Host:Port ⇄ Remote Host:Port のTX/RX値から、異常通信元を即座に特定
• 外部IPへの大量TX → マルウェア感染やC2通信の可能性
• 内部ノード間の高帯域通信 → バックアップジョブ、データ再分散（Kafka rebalanceなど）の実行中を示唆

ケーススタディ⑤：一瞬だけ現れる高負荷プロセス — 瞬間的なリソース消費の捕捉

top のバッチモードと watch を組み合わせて、消えゆくプロセスを定格記録：

# 上位15件のCPU使用率順プロセス（コマンドライン引数含む）
watch -n 1 -d "top -b -n 1 -c -o +%CPU | head -n 22"

# Javaプロセスに絞った監視（OOM直前挙動の観察）
watch -n 1 -d "top -b -n 1 -c | grep 'java\|jvm'"

• -c により起動引数まで表示 → メモリ設定（-Xmx）やJVMバージョンの確認が可能
• S 列に D（Uninterruptible Sleep）が頻出 → ファイルI/OやNFSマウントの固着を疑う

実践上の注意点

• コマンドのクォート必須：パイプ（|）、オプション引数を含む場合は、必ずダブルクォートで囲む（例：watch -d "top -b -n 1 | head -20"）
• 自動終了トリガー：条件付き終了が必要な場合、-g（exit on change）フラグを併用すると、変化検知後に後続スクリプトを起動可能