🍽️ レストラン厨房で例えると超わかりやすい！
Procstat = 厨房スタッフの監視システム
レストランの厨房には、シェフ、調理助手、皿洗い担当など、様々なスタッフ（プロセス）が働いています。
Procstat
は、各スタッフが
何をしているか、疲れていないか、ちゃんと仕事をしているか
を監視する管理システムです。
「メインシェフ（Nginxプロセス）の疲労度は？」
「調理助手（Javaアプリ）は何個の鍋（メモリ）を使ってる？」
「皿洗い担当（データベース）は何枚の皿（ファイル）を扱ってる？」
こんな情報を
リアルタイムで可視化
して、問題を早期発見できます！✨
🎯 Procstatの3つの基本概念
1. プロセス特定
厨房のどのスタッフを監視するか決める
名札（プロセス名）で探す？
制服（実行ファイル）で探す？
担当ポジション（systemd）で探す？
複数の方法で特定可能！
名札（プロセス名）で探す？
制服（実行ファイル）で探す？
担当ポジション（systemd）で探す？
複数の方法で特定可能！
2. メトリクス収集
スタッフの状態を数値化
疲労度（CPU使用率）
使用中の道具数（メモリ）
担当している皿数（ファイル数）
作業時間（稼働時間）
あらゆる情報を記録！
疲労度（CPU使用率）
使用中の道具数（メモリ）
担当している皿数（ファイル数）
作業時間（稼働時間）
あらゆる情報を記録！
3. CloudWatch連携
収集した情報を本部に送信
リアルタイムでダッシュボード表示
異常値を検知したらアラート
過去のデータで傾向分析
経営判断に活用！
リアルタイムでダッシュボード表示
異常値を検知したらアラート
過去のデータで傾向分析
経営判断に活用！
🔍 プロセス特定の4つの方法
厨房スタッフをどうやって識別するか？状況に応じて使い分けよう！
1. pid_file
pid_file
🍽️ レストランの例え：
スタッフが出勤時に「出勤カード」を機械に通す方式。カードにスタッフ番号（PID）が記録されている。
📝 説明：
プロセスIDが記録されたファイルを指定。Nginx、Apache、PostgreSQLなど、多くのサービスがPIDファイルを作成する。
スタッフが出勤時に「出勤カード」を機械に通す方式。カードにスタッフ番号（PID）が記録されている。
📝 説明：
プロセスIDが記録されたファイルを指定。Nginx、Apache、PostgreSQLなど、多くのサービスがPIDファイルを作成する。
💡 使用例
"pid_file": "/var/run/nginx.pid"
→ Nginxのメインプロセスを監視
2. exe
exe
🍽️ レストランの例え：
特定の制服を着ている人を探す方式。「白い帽子とエプロンの人＝パティシエ」のように識別。
📝 説明：
実行ファイルの正確なパスで指定。確実に特定のプログラムだけを監視できる。
特定の制服を着ている人を探す方式。「白い帽子とエプロンの人＝パティシエ」のように識別。
📝 説明：
実行ファイルの正確なパスで指定。確実に特定のプログラムだけを監視できる。
💡 使用例
"exe": "/usr/bin/java"
→ Javaプロセス全てを監視
3. pattern
pattern
🍽️ レストランの例え：
名札の一部で探す方式。「〇〇シェフ」という名前の人を全員見つける。同じ役職の複数スタッフを一度に監視。
📝 説明：
プロセス名の正規表現パターンで指定。複数の類似プロセスを一括監視できる。
名札の一部で探す方式。「〇〇シェフ」という名前の人を全員見つける。同じ役職の複数スタッフを一度に監視。
📝 説明：
プロセス名の正規表現パターンで指定。複数の類似プロセスを一括監視できる。
💡 使用例
"pattern": "nginx.*worker"
→ Nginxワーカープロセス全てを監視
4. systemd_unit
systemd_unit
🍽️ レストランの例え：
担当ポジションで探す方式。「デザート部門」「メイン料理部門」のように、チーム単位で監視。
📝 説明：
systemdサービス名で指定。Linuxの標準的なサービス管理と連携できる最もモダンな方法。
担当ポジションで探す方式。「デザート部門」「メイン料理部門」のように、チーム単位で監視。
📝 説明：
systemdサービス名で指定。Linuxの標準的なサービス管理と連携できる最もモダンな方法。
💡 使用例
"systemd_unit": "nginx.service"
→ Nginxサービス全体を監視（推奨）
📊 収集できる主要メトリクス
スタッフの状態を数値化！各メトリクスが示す意味を理解しよう
CPU使用率
メトリクス名：
cpu_usage, cpu_time
プロセスがどれだけCPUを使っているか。0-100%で表示。
プロセスがどれだけCPUを使っているか。0-100%で表示。
🍽️ レストランで言うと
シェフの疲労度・集中度。100%に近いと「全力で料理中」、低いと「待機中」。
例： 80%以上が続く → スタッフ増員を検討
メモリ使用量
メトリクス名：
memory_rss, memory_vms, memory_swap
プロセスが使用しているメモリ容量（バイト単位）。
プロセスが使用しているメモリ容量（バイト単位）。
🍽️ レストランで言うと
シェフが使っている鍋・フライパン・ボウルの数。たくさん使うほど作業効率は上がるが、使いすぎると厨房が狭くなる。
例： メモリリーク検知に有効
ファイル数
メトリクス名：
num_fds
プロセスが開いているファイルディスクリプタの数。
プロセスが開いているファイルディスクリプタの数。
🍽️ レストランで言うと
シェフが同時に扱っている皿・レシピ本・注文票の枚数。多すぎると「手に負えない状態」になる。
例： データベース接続数の監視に最適
スレッド数
メトリクス名：
num_threads
プロセスが生成しているスレッドの数。
プロセスが生成しているスレッドの数。
🍽️ レストランで言うと
メインシェフが指示を出している助手の人数。適切な人数で効率的に、多すぎるとコミュニケーションコストが増加。
例： スレッドプールの監視
稼働時間
メトリクス名：
pid_count
プロセスが起動してからの経過時間。
プロセスが起動してからの経過時間。
🍽️ レストランで言うと
スタッフの連続勤務時間。長時間働き続けているか、頻繁に休憩（再起動）しているかを確認。
例： 頻繁な再起動の検知
I/O統計
メトリクス名：
read_bytes, write_bytes, read_count, write_count
ディスク読み書きの回数とバイト数。
ディスク読み書きの回数とバイト数。
🍽️ レストランで言うと
シェフが食材庫（ストレージ）に行く回数と、持ってくる食材の量。頻繁に往復するとボトルネックに。
例： ディスクI/Oの問題特定
🔧 Procstat設定の5ステップ
1
CloudWatch Agentインストール
🍽️ レストランで言うと：
監視カメラシステムの設置
EC2インスタンスにCloudWatch Agentをインストール。
または
EC2インスタンスにCloudWatch Agentをインストール。
sudo yum install amazon-cloudwatch-agent
または
sudo apt-get install amazon-cloudwatch-agent
2
設定ファイル作成
🍽️ レストランで言うと：
「誰を」「どう」監視するか決める
/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json を作成。
監視対象プロセスとメトリクスを指定する。
/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json を作成。
監視対象プロセスとメトリクスを指定する。
3
IAM権限設定
🍽️ レストランで言うと：
監視データを本部に送る許可を取得
EC2インスタンスに CloudWatchAgentServerPolicy をアタッチ。
これでCloudWatchにメトリクスを送信できるようになる。
EC2インスタンスに CloudWatchAgentServerPolicy をアタッチ。
これでCloudWatchにメトリクスを送信できるようになる。
4
Agentの起動
🍽️ レストランで言うと：
監視システムの稼働開始
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json
5
CloudWatchで確認
🍽️ レストランで言うと：
本部のダッシュボードで確認
AWSコンソール → CloudWatch → メトリクス → CWAgent
procstat_* から始まるメトリクスが表示される。
ダッシュボードやアラームを設定して活用！
AWSコンソール → CloudWatch → メトリクス → CWAgent
procstat_* から始まるメトリクスが表示される。
ダッシュボードやアラームを設定して活用！
📝 完全な設定ファイル例（Nginx監視）
{
"agent": {
"metrics_collection_interval": 60,
"run_as_user": "root"
},
"metrics": {
"namespace": "MyApp",
"metrics_collected": {
// 🎯 Procstat設定開始
"procstat": [
{
// 方法1: systemdで特定（推奨）
"systemd_unit": "nginx.service",
"measurement": [
{
"name": "cpu_usage",
"rename": "nginx_cpu",
"unit": "Percent"
},
{
"name": "memory_rss",
"rename": "nginx_memory",
"unit": "Bytes"
},
"num_fds",
"num_threads"
]
},
{
// 方法2: PIDファイルで特定
"pid_file": "/var/run/myapp.pid",
"measurement": [
"cpu_usage",
"memory_rss",
"read_bytes",
"write_bytes"
]
},
{
// 方法3: パターンで特定（複数プロセス）
"pattern": "java.*myapp",
"measurement": [
"cpu_usage",
"memory_rss",
"num_fds"
]
}
]
}
}
}
📊 プロセス特定方法の比較
| 方法 | 使用場面 | メリット | デメリット | 推奨度 |
|---|---|---|---|---|
| systemd_unit | systemdで管理されているサービス |
✅ 最もシンプル
✅ 自動的に全プロセス監視 ✅ サービス再起動に対応 |
⚠️ systemd必須 | ⭐⭐⭐⭐⭐ |
| pid_file | PIDファイルを作成するサービス |
✅ 正確に特定できる
✅ 設定が簡単 |
⚠️ PIDファイルが必要
⚠️ 再起動時は新PID |
⭐⭐⭐⭐ |
| exe | 特定の実行ファイルを監視 |
✅ 確実に特定できる
✅ バージョン違いも区別可能 |
⚠️ フルパス必須
⚠️ 複数バージョンは別設定 |
⭐⭐⭐⭐ |
| pattern | 複数の類似プロセスを一括監視 |
✅ 柔軟な指定
✅ 複数プロセス対応 ✅ ワイルドカード使用可 |
⚠️ 予期しないプロセスも対象に
⚠️ 正規表現の知識が必要 |
⭐⭐⭐ |
💼 実践的なユースケース
Webサーバー監視
監視対象：
Nginx / Apache
重要メトリクス：
• CPU使用率（処理負荷）
• メモリ使用量（キャッシュ）
• num_fds（接続数）
• num_threads（ワーカー数）
アラート例：
CPU > 80% が5分継続 → スケールアウト検討
重要メトリクス：
• CPU使用率（処理負荷）
• メモリ使用量（キャッシュ）
• num_fds（接続数）
• num_threads（ワーカー数）
アラート例：
CPU > 80% が5分継続 → スケールアウト検討
Javaアプリ監視
監視対象：
Spring Boot / Tomcat
重要メトリクス：
• memory_rss（ヒープ使用量）
• num_threads（スレッドプール）
• num_fds（DB接続数）
• cpu_time（処理時間）
アラート例：
メモリ使用量が増加傾向 → メモリリーク調査
重要メトリクス：
• memory_rss（ヒープ使用量）
• num_threads（スレッドプール）
• num_fds（DB接続数）
• cpu_time（処理時間）
アラート例：
メモリ使用量が増加傾向 → メモリリーク調査
データベース監視
監視対象：
MySQL / PostgreSQL
重要メトリクス：
• num_fds（接続数上限確認）
• read_bytes / write_bytes（I/O）
• cpu_usage（クエリ処理負荷）
• memory_rss（バッファプール）
アラート例：
接続数が上限の80% → 接続プール見直し
重要メトリクス：
• num_fds（接続数上限確認）
• read_bytes / write_bytes（I/O）
• cpu_usage（クエリ処理負荷）
• memory_rss（バッファプール）
アラート例：
接続数が上限の80% → 接続プール見直し
バッチ処理監視
監視対象：
Python / Shell スクリプト
重要メトリクス：
• pid_count（実行状態確認）
• cpu_time（処理時間計測）
• read_bytes / write_bytes（進捗確認）
• memory_rss（メモリリーク検知）
アラート例：
バッチが30分以上実行 → 処理の遅延検知
重要メトリクス：
• pid_count（実行状態確認）
• cpu_time（処理時間計測）
• read_bytes / write_bytes（進捗確認）
• memory_rss（メモリリーク検知）
アラート例：
バッチが30分以上実行 → 処理の遅延検知
💡
Procstat活用のベストプラクティス
1. systemd_unitを優先的に使おう：
systemdで管理されているサービスは、systemd_unitで指定するのが最もシンプルで確実。サービス再起動にも自動対応。
2. 必要なメトリクスだけ収集しよう：
全メトリクスを収集すると費用がかさむ。重要なメトリクスに絞って、コストと可視性のバランスを取る。
3. measurement配列でメトリクスを厳選：
デフォルトでは多くのメトリクスが収集される。measurementで必要なものだけ指定すると効率的。
4. renameで分かりやすい名前に：
procstat_cpu_usage より nginx_cpu の方が直感的。ダッシュボードが見やすくなる。
5. アラームは段階的に設定：
• Warning: CPU 70% (通知のみ)
• Critical: CPU 90% (即対応)
• Emergency: プロセス停止（自動復旧）
6. 定期的に設定を見直そう：
アプリケーションの成長に合わせて、監視すべきプロセスやメトリクスも変化する。四半期ごとにレビュー。
7. タグを活用して分類：
環境（prod/staging）、役割（web/api）などのタグを付けると、集計やフィルタリングが楽に。
systemdで管理されているサービスは、systemd_unitで指定するのが最もシンプルで確実。サービス再起動にも自動対応。
2. 必要なメトリクスだけ収集しよう：
全メトリクスを収集すると費用がかさむ。重要なメトリクスに絞って、コストと可視性のバランスを取る。
3. measurement配列でメトリクスを厳選：
デフォルトでは多くのメトリクスが収集される。measurementで必要なものだけ指定すると効率的。
4. renameで分かりやすい名前に：
procstat_cpu_usage より nginx_cpu の方が直感的。ダッシュボードが見やすくなる。
5. アラームは段階的に設定：
• Warning: CPU 70% (通知のみ)
• Critical: CPU 90% (即対応)
• Emergency: プロセス停止（自動復旧）
6. 定期的に設定を見直そう：
アプリケーションの成長に合わせて、監視すべきプロセスやメトリクスも変化する。四半期ごとにレビュー。
7. タグを活用して分類：
環境（prod/staging）、役割（web/api）などのタグを付けると、集計やフィルタリングが楽に。
⚠️
よくある落とし穴と対策
1. プロセスが見つからない：
• systemd_unitの綴りが間違っている →
• PIDファイルのパスが間違っている → 実際のパスを確認
• パターンが広すぎる/狭すぎる →
2. メトリクスがCloudWatchに表示されない：
• IAM権限が不足 → CloudWatchAgentServerPolicyをアタッチ
• Agent設定のJSON構文エラー →
• 収集間隔が長すぎる → metrics_collection_intervalを60秒に設定
3. 費用が予想以上に高い：
• 全メトリクスを収集している → measurementで必要なものだけ指定
• 収集間隔が短すぎる → 60秒以上を推奨（デフォルトは60秒）
• 不要なプロセスを監視 → 本当に必要なプロセスだけに絞る
4. パターンで予期しないプロセスも対象に：
• 正規表現が広すぎる → より具体的なパターンに変更
• 例: "java" → "java.*myapp" のように限定する
5. プロセス再起動でメトリクスが途切れる：
• PIDが変わると追跡できない → systemd_unitやpatternを使う
• pid_fileは再起動に弱い → 可能な限りsystemd_unitを使う
• systemd_unitの綴りが間違っている →
systemctl list-units
で確認
• PIDファイルのパスが間違っている → 実際のパスを確認
• パターンが広すぎる/狭すぎる →
ps aux | grep pattern
でテスト
2. メトリクスがCloudWatchに表示されない：
• IAM権限が不足 → CloudWatchAgentServerPolicyをアタッチ
• Agent設定のJSON構文エラー →
amazon-cloudwatch-agent-ctl -a query-status
で確認
• 収集間隔が長すぎる → metrics_collection_intervalを60秒に設定
3. 費用が予想以上に高い：
• 全メトリクスを収集している → measurementで必要なものだけ指定
• 収集間隔が短すぎる → 60秒以上を推奨（デフォルトは60秒）
• 不要なプロセスを監視 → 本当に必要なプロセスだけに絞る
4. パターンで予期しないプロセスも対象に：
• 正規表現が広すぎる → より具体的なパターンに変更
• 例: "java" → "java.*myapp" のように限定する
5. プロセス再起動でメトリクスが途切れる：
• PIDが変わると追跡できない → systemd_unitやpatternを使う
• pid_fileは再起動に弱い → 可能な限りsystemd_unitを使う
🎓 まとめ
👨🍳 Procstat = 厨房スタッフ監視システム
CloudWatch Agent Procstatを使えば、
サーバー上で動くプロセス（厨房スタッフ）の状態を
リアルタイムで可視化・監視できます
🔍
プロセス特定
systemd_unit,
pid_file, exe,
patternの4方式
📊
豊富なメトリクス
CPU、メモリ、
ファイル数、I/Oなど
あらゆる情報を収集
🔔
アラート連携
CloudWatchで
ダッシュボード作成
異常値を即検知
🎯 推奨アプローチ：
1️⃣ まずは
systemd_unit
で主要サービスを監視
2️⃣ 必要なメトリクスだけ
measurement
で指定
3️⃣ ダッシュボードで可視化して
アラーム
設定
4️⃣ 運用しながら段階的に
最適化
Procstatでプロセスの
「今」
を把握して、
問題が大きくなる前に対処しよう！
厨房のスタッフが全員元気に働いているか、
常に見守ることが安定運用の秘訣です！🎉