AWS CloudWatchで高度な監視を実現！ディスク・プロセス・ポート監視の全手法

AWS CloudWatch監視の全体像と効率的な設定ロードマップ

なぜCloudWatchによる詳細監視が必要なのか

近年の企業活動において、クラウドサービスの利用はもはや不可欠なインフラとなっています。総務省の調査（2024年時点）によると、国内企業の80.6％がクラウドサービスを利用しており、さらに日本の国が利用する情報システムのうち、約85％がAWS上で稼働しているとされています（デジタル庁資料、2026年3月31日時点）。このような状況下で、システムを安定稼働させ、運用を効率化するためには、AWS CloudWatchによる統合的な監視体制が欠かせません。しかし、CloudWatchはCPU使用率やネットワークトラフィックといった標準メトリクスを自動収集する一方で、OS内部の詳細な状態（ディスク使用率、実行中のプロセス、ポートの応答状況など）については、追加設定なしでは監視できません。これらの詳細な情報を把握することで、システム障害の予兆を早期に検知し、サービスの安定提供に繋げることが可能になります。

標準監視と高度な監視の違いを理解する

AWS CloudWatchには、大きく分けて「標準監視」と「高度な監視」の2種類があります。標準監視は、EC2インスタンスのCPU使用率、ネットワークI/O、ディスクI/Oといった基本的なリソース情報をAWS側が自動で収集する機能です。これらのメトリクスは、デフォルトで5分間隔で取得され、追加設定なしに利用できます。一方、高度な監視は、OSのメモリ使用率、ディスクの論理的な空き容量、特定のプロセスの稼働状況、ポートの応答性など、より詳細な情報を対象とします。これらのデータは、監視対象のEC2インスタンスに「CloudWatchエージェント」をインストールし、設定ファイルを適用することで収集されます。エージェントが収集したデータは「カスタムメトリクス」としてCloudWatchに送信され、標準メトリクスと同様にダッシュボードでの可視化やアラーム設定が可能になります。

CloudWatchエージェント導入からカスタムメトリクス設定までのロードマップ

CloudWatchエージェントを導入し、カスタムメトリクスを設定するまでの一般的なロードマップは以下の通りです。まず、監視対象となるEC2インスタンス（LinuxまたはWindows）にCloudWatchエージェントをインストールします。エージェントはAWS Systems Managerや手動でのインストールが可能です。次に、エージェントが収集するメトリクスを定義する設定ファイルを作成します。この設定ファイルはJSON形式で、ディスク使用率、メモリ使用率、プロセス、ポートなど、監視したい項目とその収集間隔、名前空間などを記述します。設定ファイルをインスタンスに配置し、CloudWatchエージェントを起動または再起動することで、指定したメトリクスがCloudWatchに送信され始めます。最後に、CloudWatchコンソールで新しいカスタムメトリクスが正しく表示されているかを確認し、ダッシュボードへの追加やアラーム設定の準備を進めます。このステップを踏むことで、高度な監視体制の基盤を確立できます。

出典：総務省「令和7年版 情報通信白書」、ITmedia「政府クラウド、AWSが8割超を独占 デジタル庁が答えた「特定企業推奨」の可能性」、Amazon Web Services、iDATEN「AWS 第37回『押さえておきたいCloudWatchの基本機能』」

カスタムメトリクスとアラーム設定のステップバイステップガイド

CloudWatchエージェント設定ファイル作成の基本

CloudWatchエージェントによるカスタムメトリクス収集の鍵は、JSON形式で記述される設定ファイルにあります。このファイルには、監視対象のリソース（CPU、メモリ、ディスク、プロセス、ポートなど）や、収集するメトリクス、名前空間、ディメンション、収集間隔などを詳細に定義します。例えば、ディスク使用率を監視するには、"disk_path": "/" のように対象パスを指定し、"measurement": [ "%used", "used", "free" ] のように収集するデータポイントを記述します。設定の際は、名前空間を適切に設定することが重要です。例えば、「MyCustomNamespace」のような独自の名前空間を使用することで、標準メトリクスとの混同を避け、メトリクスを整理しやすくなります。収集間隔はデフォルトで60秒（1分）ですが、重要度やコストに応じて10秒または300秒（5分）に変更することも可能です。カスタムメトリクスはデータ量に応じて費用が発生するため、不要なメトリクスや過剰な頻度での収集は避けるよう、コスト設計を考慮して設定しましょう。

カスタムメトリクスをCloudWatchに送信する手順

CloudWatchエージェントの設定ファイルが完成したら、次の手順でカスタムメトリクスをCloudWatchに送信します。まず、作成した設定ファイルを監視対象のEC2インスタンス内に配置します。Linuxの場合、通常は/opt/aws/amazon-cloudwatch-agent/bin/config.json や /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json など、エージェントのインストールパスに応じた場所に配置します。設定ファイルを配置したら、CloudWatchエージェントサービスを起動または再起動して、新しい設定を反映させます。エージェントが正常に動作しているかを確認するためには、エージェントのログファイル（Linuxの場合は/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log）を確認し、エラーメッセージがないかチェックします。その後、AWS CloudWatchコンソールにログインし、「メトリクス」セクションで設定ファイルに定義した名前空間を選択すると、送信されたカスタムメトリクスが表示されるはずです。これにより、エージェントが正しくデータを収集・送信していることが確認できます。

効果的なアラーム設定と通知アクションの設計

カスタムメトリクスがCloudWatchに送信されるようになったら、システム異常を検知するためのアラームを設定します。アラームは、特定のメトリクスが定義した閾値を超えた場合に発動するように設定します。例えば、ディスク使用率が90%以上になった場合や、特定のプロセスが停止した場合などです。アラーム設定では、メトリクスの「統計関数」（平均、最大、最小など）、「期間」（メトリクスを評価する時間枠）、「評価期間」（閾値を超えた状態が何回続いたらアラームを発動するか）を指定します。誤検知を減らすためには、「評価期間」を複数回に設定するなど、システムの特性に応じた調整が重要です。アラームが発動した際のアクションとしては、Amazon SNS（Simple Notification Service）を使用して、メール、SMS、またはChatOpsツール（Slack、Microsoft Teamsなど）への通知を設定するのが一般的です。さらに高度な自動化として、AWS Lambda関数をトリガーして、自動的な復旧処理や関連ログの収集を行うことも検討できます。

出典：Amazon Web Services、iDATEN「AWS 第37回『押さえておきたいCloudWatchの基本機能』」

ディスク・プロセス・ポート監視の具体的な設定例とテンプレート

ディスク使用率監視の実践的な設定例

サーバーの安定稼働において、ディスク使用率の監視は最も基本的ながら重要な項目の一つです。CloudWatchエージェントを使用してディスク使用率を監視する場合、設定ファイル（JSON）の"metrics"セクション内に、以下のようなブロックを追加します。例えば、Linuxサーバーのルートディレクトリ（`/`）を監視し、使用率（`%used`）と空き容量（`free`）を収集するには、"path": "/" と "metrics_collection_interval": 60 （1分間隔）を指定します。これにより、`/`のディスク使用状況が1分ごとにカスタムメトリクスとしてCloudWatchに送信されます。アラーム設定では、例えば「`Disk_Used_Percent`が5分間の平均で80%を超えたら警告、90%を超えたら緊急」といった閾値を設定し、SNSを通じて担当者に通知するよう構成します。ファイルシステムの種類（ext4, xfsなど）や対象ドライブを正確に指定することで、より精度の高い監視が可能です。

特定のプロセス動作監視テンプレート

特定のアプリケーションプロセスが停止していないか、あるいは過剰なリソースを消費していないかを監視することは、サービス停止の予防に直結します。CloudWatchエージェントでは、プロセス名を指定してその稼働状況を監視できます。設定ファイルでは、"processes" セクションに監視したいプロセス名（例: `httpd`、`mysqld`）を追加します。これにより、プロセスのPID（プロセスID）、CPU使用率、メモリ使用率、プロセス数などのメトリクスが収集されます。例えば、Webサーバーの`httpd`プロセスが停止した場合、`ProcessCount`メトリクスが0になるため、これを閾値としてアラームを設定することで、サービス停止を即座に検知し、通知できます。さらに、特定のプロセスが異常に高いCPUやメモリを使用している場合も検知できるよう、それぞれのメトリクスに対して閾値を設けることが可能です。これにより、リソース枯渇によるパフォーマンス低下の予兆を捉えることができます。

ポート応答監視の構成と注意点

アプリケーションが正常に動作しているかを確認する上で、特定のポート（例: HTTP/80, HTTPS/443, MySQL/3306など）が応答しているかどうかの監視は重要です。CloudWatchエージェントは、TCPポートの接続可否をメトリクスとして収集する機能を提供します。設定ファイルで"port_numbers"セクションに監視したいポート番号（例: `[80, 443]`）を指定すると、エージェントは指定されたポートへの接続を試み、その成否をメトリクスとして送信します。これにより、アプリケーションが起動しているにもかかわらず、特定のサービスポートが外部からアクセスできない状態になっているといったケースを検知できます。ただし、CloudWatchエージェントによるポート監視は、エージェントが稼働しているインスタンス内部からの接続確認に限定されます。外部からのURLやAPIのエンドポイントが正常に応答しているかを確認するには、CloudWatch Syntheticsの「カナリア」機能を利用するなど、目的に応じた適切な監視ツールを組み合わせる必要があります。

出典：Amazon Web Services、iDATEN「AWS 第37回『押さえておきたいCloudWatchの基本機能』」

監視設計で陥りやすい落とし穴と評価期間設定の注意点

過剰なカスタムメトリクスによるコスト増大の回避策

CloudWatchカスタムメトリクスは非常に柔軟性が高い一方で、設定次第では予期せぬコスト増大を招く可能性があります。これは、カスタムメトリクスがデータポイントの数や保存期間に基づいて課金されるためです。陥りやすい落とし穴としては、すべての可能なメトリクスを収集しようとすることや、不要なリソース（例：テスト環境の一時的なインスタンス）まで監視対象に含めてしまうケースが挙げられます。これを回避するためには、まず「何を監視することでビジネス影響を最小化できるか」という観点から、本当に必要なメトリクスを厳選することが重要です。次に、収集頻度と精度のバランスを考慮し、重要度の低いメトリクスは5分間隔にする、あるいは特定のアラート時にのみ詳細なメトリクスを収集する設定を検討するのも有効です。CloudWatchの料金体系を事前に理解し、導入前に簡易的なコストシミュレーションを行うことで、予算超過のリスクを低減できます。

オートスケーリング環境下でのログ情報不足を防ぐ設計

AWSのオートスケーリンググループを利用している環境では、インスタンスが自動的にスケールアウト・インするため、一時的なインスタンスが削除される際にそのインスタンス内のローカルログが消失してしまうという問題が発生しがちです。これにより、障害発生時の原因究明に必要な情報が不足し、解決に時間を要する可能性があります。この落とし穴を回避するためには、重要なログデータをCloudWatch Logsへリアルタイムで転送・保持する設計が不可欠です。CloudWatchエージェントは、カスタムメトリクスだけでなく、ログファイルのデータをCloudWatch Logsに転送する機能も持っています。エージェントの設定ファイルにログファイルのパスとロググループ、ログストリームの情報を追記することで、インスタンスが削除される前にログデータを永続的に保存できます。ロググループの命名規則を統一し、各アプリケーションやサービスごとにログを適切に整理することで、障害発生時のログ分析を効率化できるでしょう。

アラームの誤検知と見逃しを防ぐ評価期間の最適化

CloudWatchアラームの評価期間の設定は、誤検知による運用負荷の増加や、逆に重要な障害の見逃しを防ぐために非常に重要です。短すぎる評価期間（例：1分間のメトリクスが1回閾値を超えたらアラーム）は、一時的なネットワークスパイクや瞬間的な負荷上昇によって誤検知を引き起こし、運用担当者の疲弊に繋がります。一方、長すぎる評価期間は、実際にシステムに問題が発生していてもアラーム発動が遅れ、サービス停止時間が増大するリスクがあります。システムの特性（トラフィックの変動パターン、復旧に必要な時間など）を理解した上で、適切な「期間」と「評価期間」を設定することが求められます。例えば、「5分間隔のメトリクスが3回中2回以上閾値を超えた場合にアラーム」といった設定は、一時的な変動を無視しつつ、持続的な問題を検知するのに有効です。また、「データポイント不足時の処理」として「無視」、「不良」、「OK」を選択できるため、監視対象の特性に応じて最適なオプションを選定しましょう。

出典：Amazon Web Services

【ケース】監視データ不足による誤検知を解決した最適化事例

架空のケース：既存監視の問題点と初期分析

ある中規模のWebサービス運用チームでは、既存のCloudWatch監視設定において、ディスク容量不足のアラームが月に数回誤検知されるという課題に直面していました。（これは架空のケースです。）アラームは「ディスク使用率が85%を超えたら発報」というシンプルなものでしたが、実際にはディスクが本当に枯渇しているわけではなく、深夜のバックアップ処理やログローテーションなど、瞬間的に大量のデータが生成・削除されるタイミングで一時的に使用率が上昇し、アラームが発動していました。これにより、運用担当者はアラームが上がるたびにシステムを確認する手間が発生し、疲弊していました。詳細なログを確認しても、特定のエラーや異常なプロセスは発見されず、一過性の現象であることが判明。この状況では、本来監視すべき深刻な問題を見逃すリスクも高まっていました。

問題解決に向けたCloudWatchエージェント設定の見直し

この誤検知問題を解決するため、チームはCloudWatchエージェントの設定とアラームの評価期間を見直しました。まず、ディスク使用率のメトリクス収集頻度を、従来の1分間隔から5分間隔に変更しました。これにより、瞬間的な使用率のスパイクが直接アラームに繋がる可能性を低減しました。次に、CloudWatchアラームの評価期間をより慎重に設定しました。具体的には、「5分間隔で収集されるメトリクスが、過去3データポイントのうち2データポイント以上で閾値（85%）を超えた場合にアラームを発動する」という条件に変更しました。この設定により、一過性のスパイクではアラームが上がらず、実際に5分間で複数回にわたってディスク使用率が高い状態が続いた場合にのみアラームが発動するようになりました。さらに、特定のバックアッププロセスが使用するディスクI/Oやメモリ使用量を別途カスタムメトリクスとして収集し、相関関係を分析できるようにしました。

最適化後の効果と継続的な改善策

上記の見直しを実施した結果、ディスク容量不足に関する誤検知アラームは劇的に減少し、運用担当者の確認作業が大幅に削減されました。これにより、本当に注意すべきアラームに集中できるようになり、運用効率が向上しました。この事例から学べるのは、監視は単にメトリクスを収集し閾値を設定するだけでなく、システムの特性や運用状況を深く理解し、それに基づいてメトリクスの収集頻度、評価期間、データポイント不足時の処理などを継続的に最適化していくことの重要性です。今後もシステムの構成変更やアプリケーションの更新が行われる際には、それに合わせて監視設定も常に最新の状態に保つよう見直しを行うことで、より堅牢で効率的な監視体制を維持できるでしょう。