【AWSハンズオン実践】監視編サーバーのモニタリングの基本を学ぼう

Last updated at 2025-09-08Posted at 2025-09-07

1. ハンズオン内容

ハンズオンでは各リソースを段階的に作成していきます

※Cloud9はVSCodeとPowerShellで代用
※画像はAWS公式ページより引用

CloudFormationによる自動化はこちら
Terraformによる自動化は準備中

前提条件＆注意事項

一部課金が発生します（数十円程度）。終了後は必ず削除しましょう。このハンズオンはec2が多いので注意です
親ページ見てない人は見てね
CodeCommitが登場する場合はGitHubを代用しますので、AWSから接続できるようご用意ください。
ブログ内でバケット、ドメインを扱っている場合、同一名称は使わないでください。
UIの操作はルートアカウントを使っています。

2. （Step1）環境作成

CloudFormation テンプレートの DBInstance は 1つ。
MultiAZ: true にすると、AWS が自動的に別の AZ にスタンバイ（レプリカ）インスタンスを用意します。
図では便宜的に RDS (Master) と RDS (Slave) と書かれていますが、実際に利用者が接続するのは 1つのエンドポイントだけ。
※画像はハンズオンより引用

2.1 （Step1）CFnによる作成

ハンズオンでテンプレートが用意されてます。でも古くて動かないので修正しています。DBがあるせいか15分ほどかかります。

CloudFormation > スタック > スタックの作成

スタックの作成

大項目	中項目	選択肢	備考
前提条件 - テンプレートの準備	テンプレートの準備	既存のテンプレートを選択
テンプレートの指定	テンプレートソース	テンプレートファイルのアップロード
	テンプレートファイルのアップロード	step1-monitoring-1.yml
スタック名を提供	スタック名	step1-monitoring-1
アクセス許可 - オプション	IAM ロール	（なし）	ユーザ権限で作成
上記以外		全てデフォルト

wordpressにログインしなくてもハンズオンできると思われます。wordpressの画面が表示されればOK。

CloudWatchエージェントの設定ファイルが導入されます

https://raw.githubusercontent.com/nikuyoshi/aws-monitoring-hands-on-1/master/amazon-cloudwatch-agent.json

この設定は、EC2上のWordPressサーバで /var/log/httpd/access_log と /var/log/httpd/error_log をCloudWatch Logsに送信しつつ、CPU・メモリ・ディスク・I/O・ネットワーク・スワップといった各種リソースメトリクスを60秒間隔で収集してCloudWatchに送信するためのCloudWatch Agent構成です。監視するときはamazon-cloudwatch-agent.jsonを作ることが重要

3. （Step2）メトリクスを見る方法

ハンズオンで見ていた画面は以下です。（手順化するのは厳しい）

CloudWatch > Metrics > 参照 > EC2 > インスタンス別メトリクス
CloudWatch > Metrics > 参照 > RDS > DBInstanceIdentifier
CloudWatch > Metrics > 参照 > ApplicationELB > AppELB 別、AZ 別、TG 別メトリクス
CloudWatch > Metrics > すべて > CWAgent > ImageId,InstanceId,InstanceType,device,fstype,path

メトリクス名が画面右側にあるので見ずらいと思った。
あとはメトリクスの表示期間を変える話をしていた。5分→1分

4. （Step3）EC2インスタンスのルートパスのDISK使用率が80%になったらアラートを出す

disk使用率の監視はCloudWatchエージェントが必要です

4.1 （Step3）SNSトピックの作成

アラートの通知でSNSトピックが必要になるのでまず作ります

Amazon SNS > トピック > トピックの作成

トピックの作成

大項目	中項目	選択肢	備考
詳細	🔴タイプ	⬜FIFO (先入れ先出し、先出し) ✅スタンダード
	🔴名前	monitoring-1-topic
	表示名 - オプション
暗号化 - オプション		⬜暗号化
アクセスポリシー - オプション	メソッドの選択	✅ベーシック ⬜アドバンスト
	パブリッシャー	✅トピックの所有者のみ ⬜全員 ⬜指定された AWS アカウントのみ
	サブスクライバー	✅トピックの所有者のみ ⬜全員 ⬜指定された AWS アカウントのみ ⬜特定のエンドポイントを持つリクエスタのみ
データ保護ポリシー - オプション			項目が多すぎるので省略
配信ポリシー (HTTP/S) - オプション			項目が多すぎるので省略
配信ステータスのログ記録 - オプション			項目が多すぎるので省略
タグ - オプション			項目が多すぎるので省略
アクティブトレース - オプション			項目が多すぎるので省略

4.2 （Step3）SNSサブスクリプションの作成

Amazon SNS > トピック > monitoring-1-topic > サブスクリプションの作成

画面名：サブスクリプションの作成

大項目	中項目	選択肢	備考
詳細	🔴トピック ARN	✅arn:aws:sns:ap-northeast-1:XXXXXXXXXXXX:monitoring-1-topic
	🔴プロトコル	⬜Amazon Kinesis Data Firehose ⬜Amazon SQS ⬜AWS Lambda ✅E メール ⬜HTTP ⬜HTTPS ⬜JSON 形式のメール ⬜SMS ⬜プラットフォームアプリケーションのエンドポイント
	🔴エンドポイント	XXXXX@gmail.com	任意の自分のメアド
サブスクリプションフィルターポリシー - オプション		⬜サブスクリプションフィルターポリシー	試験でみたことあるな
Redrive ポリシー (デッドレターキュー) - オプション		⬜Redrive ポリシー (デッドレターキュー)	試験でみたことあるな

この後メールがくるので、Confirm subscriptionクリックしておくこと。

You have chosen to subscribe to the topic:
arn:aws:sns:ap-northeast-1:XXXXXXXXXXXX:monitoring-1-topic

To confirm this subscription, click or visit the link below (If this was in error no action is necessary):
Confirm subscription # ここ

4.3 （Step3）CloudWatchアラームの作成

CloudWatch > アラーム > アラームの作成 > メトリクスの選択 > CWAgent > ImageId,InstanceId,InstanceType,device,fstype,path > step1-monitoring-1-WebServer01のdisk_used_percent > メトリクスの選択

画面名：メトリクスと条件の指定

大項目	中項目	選択肢	備考
メトリクス	名前空間	CWAgent
	メトリクス名	disk_used_percent
	path	/
	InstanceId	i-05d9aeb56c35f79e8	人によって違います
	ImageId	ami-07faa35bbd2230d90	人によって違う可能性あり
	InstanceType	t3.micro
	device	nvme0n1p1
	fstype	xfs
	インスタンス名	step1-monitoring-1-WebServer01
	統計	✅平均値 ⬜合計 ⬜最大 ⬜最小 ...
	期間	⬜10 秒 ⬜20 秒 ⬜30 秒 ⬜1 分 ✅5 分
条件	しきい値の種類	✅静的 ⬜異常検出
	🔴disk_used_percent が次の時...	⬜より大きい ✅以上 ⬜以下 ⬜より低い
	🔴異常検出のしきい値	80
その他の設定	アラームを実行するデータポイント	1/1	なんだろうこれ
	欠落データの処理	✅欠落データを見つかりませんとして処理 ⬜欠落データを適正（しきい値を超えていない）として処理 ⬜欠落データを無視（アラーム状態を維持する）として処理 ⬜欠落データを不正（しきい値を超えている）として処理

画面名：アクションの設定

大項目	中項目	選択肢	備考
通知	アラーム状態トリガー	✅アラーム状態 ⬜OK ⬜データ不足
	次の SNS トピックに通知を送信	✅既存の SNS トピックを選択 ⬜新しいトピックの作成 ⬜トピック ARN を使用して他のアカウントに通知
	🔴通知の送信先:	✅monitoring-1-topic
Lambda アクション			項目が多すぎるので省略。閾値を超えたらラムダでアクションができるという意味です
Auto Scaling アクション			項目が多すぎるので省略。閾値を超えたらAuto Scalingでアクションができるという意味です
EC2 アクション			項目が多すぎるので省略。閾値を超えたらEC2でアクションができるという意味です
Systems Manager アクション			項目が多すぎるので省略。閾値を超えたらSystems Managerでアクションができるという意味です
調査アクション - 新規			項目が多すぎるので省略。これは何ができるのかわかりません

画面名：アラームの詳細の追加

大項目	中項目	選択肢	備考
名前と説明	🔴アラーム名	monitoring-1-alarm
	タグ - オプション

画面を大きくしてないと見ずらい。右スクロールしないと見えないこともある
なんでCWAgentなのかはわからない
ImageId,InstanceId,InstanceType,device,fstype,pathはfstypeがあるからだと思う

4.4 （Step3）動作確認

インスタンスコネクトで接続できたので、容量を上げてみる。4GBのファイルを作る
DISK使用率を80%超えればメールがくる。

# WebServer01	
# /配下に4GBのファイルを作る。不足したらcountを増やせばOK
sudo dd if=/dev/zero of=/testfile bs=1M count=4096 oflag=direct

# こうなればメールが来るはずである
[ec2-user@ip-10-0-0-5 /]$ df -h
Filesystem        Size  Used Avail Use% Mounted on
devtmpfs          4.0M     0  4.0M   0% /dev
tmpfs             453M     0  453M   0% /dev/shm
tmpfs             181M  444K  181M   1% /run
/dev/nvme0n1p1    8.0G  6.9G  1.1G  87% / # ここ.80%over
tmpfs             453M  124M  330M  28% /tmp
/dev/nvme0n1p128   10M  1.3M  8.7M  13% /boot/efi
tmpfs              91M     0   91M   0% /run/user/1000

成功するとALARM: "monitoring-1-alerm" in Asia Pacific (Tokyo)といったタイトルのメールが来ます

5.（Step4）CloudWatchInsight（ログ分析）

CloudWatch > ログのインサイト

ロググループを選択（選択基準）：wordpress_access_log

まず知っておくこと
クエリは @message（ログの生本文）をベースにパースして、新しいフィールドを作る処理である。クエリには@messageの表示は省略されている。@messageはCloudWatchから送っているデータ全部だと思う

デフォルトのクエリ（@messageに時間とかを追加して出している）

fields @timestamp, @message, @logStream, @log
| sort @timestamp desc
| limit 10000

@timestamp, @message, @logStream, @logはCloudWatchで定義されている。エージェントがログを CloudWatch Logs に送信するときに、イベントの発生時刻 → @timestampといった形にしている。
https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData-discoverable-fields.html で書いてあるらしい

次のクエリ、行毎にパースするクエリ

parse '* - * [*] "* * *" * * * *' as host, identity, dateTimeString, httpVerb, url, protocol, statusCode, bytes, referrer, userAgent
 | filter statusCode like /(4\d\d)/

@messageは省略されているが、@messageをスペース区切りでparseをしている。そしてそれらをhost, identity, dateTimeString, httpVerb, url, protocol, statusCode, bytes, referrer, userAgentとして名前を付けている。ステータスコードを400番台に出力を限定している。これは利用者（クライアント）のエラーログだけを確認したいという意図だと思う。本来なら500番台も監視すべき。
@messageをみたいときはデフォルトクエリの実行や、ロググループに見に行けばよい

6. （Step5）CloudWatchダッシュボード作成

ダッシュボードの作成方法はハンズオン動画の通りなので、省略します。（手順化するのは厳しい）
コードでも作れると思います

ダッシュボードは自分で作ることもできる
- CloudWatch > Dashboards > カスタムダッシュボード > ダッシュボードの作成
ダッシュボードはAWSで自動で作ってくれる機能もある。EC2とかを選べば監視項目毎のグラフが表示される
- CloudWatch > Dashboards > 自動ダッシュボード

7. （Step6）EventBridge作成

7.1. （Step6）EventBridge作成

CloudWatchルールの後継機能

Amazon EventBridge > ルール > ルールを作成

画面名：ルールの詳細を定義

大項目	中項目	選択肢
ルールの詳細	🔴名前	monitoring-1-event-rule
	説明 - オプション
	イベントバス	✅default
		⬜選択したイベントバスでルールを有効にする
	ルールタイプ	✅イベントパターンを持つルール ⬜スケジュール

画面名：イベントパターンを構築

大項目	中項目	選択肢	備考
イベント	イベントソース	✅AWS イベントまたは EventBridge パートナーイベント ⬜その他 ⬜すべてのイベント
	サンプルイベント - オプション		省略。用途がわからない。イベントパターンのサンプルを作ってくれる？
イベントパターン	🔴作成のメソッド	⬜スキーマを使用する ✅パターンフォームを使用する ⬜カスタムパターン (JSON エディタ)
	イベントソース	✅AWS のサービス ⬜EventBrideでパートナー
	🔴AWS のサービス	✅EC2 ...
	🔴イベントタイプ	EC2 Instance State-change Notification
	🔴イベントタイプの仕様 1	⬜任意の状態 ✅特定の状態	stopping
	イベントタイプの仕様 2	✅任意のインスタンス ⬜個別のインスタンス ID	どのインスタンスが止まっても動作する、という意味だと思う

画面名：ターゲットを選択

大項目	中項目	選択肢	備考
ターゲット 1	ターゲットタイプ	⬜EventBridge イベントバス ⬜EventBridge API の宛先 ✅AWS のサービス
	🔴ターゲットを選択	✅SNSトピック ...
	ターゲットの場所	✅このアカウントのターゲット ⬜別の AWS アカウントのターゲット
	🔴トピック	✅monitoring-1-topic ...
		✅実行ロールを使用 (推奨)
	🔴実行ロール	✅この特定のリソースについて新しいロールを作成 ⬜既存のロールを使用
追加設定	ターゲット入力を設定		省略
	イベントの最大有効期間 - オプション		省略
	再試行回数 - オプション		省略
	デッドレターキュー		省略
タグ

7.2. （Step6）動作確認

インスタンスを停止（stop）し、メール通知があればOK

削除

monitoring-1スタック削除
ダッシュボード削除
CloudWatchアラーム削除
ロググループ(wordpress)削除
Amazon EventBridgeルール削除
SNSトピック削除

さいごに

感想です

自動化するとしたらアラーム作成し、メール通知まで確認すればOK
自動化するとしたらeventBridgeルールを作成し、メール通知まで確認すればOK
CloudWatchルールはもうない。eventBridgeルールが後継

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

【AWSハンズオン実践】監視編 サーバーのモニタリングの基本を学ぼう