Lab 3

Lab3：モニタリング

概要

この Lab では Amazon CloudWatch および Amazon CloudWatch Logs を使用して、ブログサイトを構成するリソースのメトリクスやインスタンス内部のログをモニタリングします。 また、AWS Systems Manager を使用して、運用の自動化・半自動化を体験します。

目標

このラボを修了すると、次のことができるようになります。

  • Amazon CloudWatch を使用して基礎的なメトリクスをモニタリングする
  • Amazon CloudWatch Agent を使用して任意のメトリクスをモニタリングする
  • Amazon CloudWatch アラームを使用して、リソースの変化を把握する
  • Amazon CloudWatch Logs を使用して、Web サーバーのログを収集する
  • Systems Manager を利用して複数の EC2 インスタンスに対して一括でコマンド実行ができる

最終的には、次の図で示すようなアプリケーション環境を構築します。

前提条件

このラボの前提条件を次に示します。

  • Microsoft Windows、Mac OS(X以降）、または Linux（Ubuntu、SUSE、または Red Hat）が搭載されているノートパソコンで、Wi-Fi アクセスができること
  • Microsoft Windows ユーザーの場合は、コンピュータへの管理者アクセスができること
  • Chrome、Firefox、Internet Explorer 11（これより前のバージョンの Internet Explorer はサポートされていません）などのインターネットブラウザを利用できること

時間

このラボは、終了までに 40 分かかります。

各タスクへのリンク

Lab3-Task1: 標準メトリクスによるモニタリング

ラボのこのセクションでは、ブログサイトを構成する、各リソースの性能監視を行います。

  1. AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。

  2. 左側のナビゲーションペインで [インスタンス] をクリックします。

  3. [Web Server01] の左側にあるボックスをオンにします。

  4. 画面下部の [詳細] タブに表示されている [インスタンス ID] の値をコピーします。

    ヒント : この後の手順で使用するため、メモ帳などのテキストエディタへコピーしてください。

  5. AWS マネジメントコンソールで [サービス] から [CloudWatch] をクリックします。

  6. 左側のナビゲーションペインから [メトリクス] > [すべてのメトリクス] をクリックします。

  7. [メトリクス] タブの検索フォームに、先の手順でコピーしておいた Web Server01 のインスタンス ID をペーストし、Enter キーを押します。 CloudWarch が自動的に取得している Web Server01 の標準メトリクスの一覧が表示されます。

  8. [EC2 > インスタンス別メトリクス] をクリックします。

  9. メトリクス名 = CPU Utilization のメトリクスをクリックします。 画面上部のグラフエリアに CPU 使用率のモニタリング結果が表示されます。

    Lab1 で Web Server01 を作成した直後から、CloudWatch によって自動的にモニタリングされている様子が分かります。

    グラフ化したメトリクス タブで、メトリクス値の表示方法、表示する統計値、グラフを表示する時間範囲、アクション > 異常検出 などを切り替えて、さまざまな角度からメトリクス値を参照してみましょう。

Lab3-Task2: IAM ロール (WP-Role) へ IAM Policy を追加

この Task では、WordPress サーバー内の CloudWatch Agent が Amazon CloudWatch へカスタムメトリクスとログを送信するために、IAM ロール “WP-Role” に Amazon CloudWatch へアクセスするためのアクセス権限を追加します。

  1. AWS マネジメントコンソールで [サービス] から [IAM] をクリックします。

  2. ナビゲーションペインで [ロール] をクリックします。

  3. ロール名 WP-Role をクリックします。

  4. [アクセス権限] タブの [ポリシーをアタッチします] をクリックします。

  5. [ポリシーのフィルタ] の検索フォームに cloudwatchagent と入力します。

  6. CloudWatchAgentAdminPolicy にチェックを入れます。

  7. ポリシーのアタッチ をクリックします。

    ハンズオンでは CloudWatch Agent の設定を AWS Systems Manager の Parameter Store に保存するため、IAM Policy "CloudWatchAgentAdminPolicy" を付与しています。 CloudWatch Agent の設定を AWS Systems Manager の Parameter Store から読み込むだけであれば、IAM Policy "CloudWatchAgentServerPolicy" を付与する事を推奨します。Parameter Store への書き込み権限がないため、意図しない書き込みによる CloudWatch Agent 設定の変更を未然に防止します。

Lab3-Task3: CloudWatch Agentのインストール

この Task では、AWS Systems Manager を使用して WordPress サーバーに CloudWatch Agent をインストールします。

  1. AWS マネジメントコンソールで [サービス] から Systems Manager をクリックします。

  2. 画面左側のナビゲーションペインで [Run Command] をクリックします。

  3. [コマンドを実行する] をクリックします。

  4. コマンドドキュメントの検索フォームで AWS-ConfigureAWSPackage と入力します。

  5. AWS-ConfigureAWSPackage にチェックします。

  6. 次の値を入力します。
    ドキュメントのバージョン ランタイムの最新バージョン
    Action Install
    Installation Type Uninstall and reinstall
    Name AmazonCloudWatchAgent
    Version (入力不要です)
    Additional Arguments (入力不要です)
    ターゲット インスタンスを手動で選択する
    Web Server01、Web Server02 にチェックしてください(※)

    ターゲットに Web Server01、Web Server02 が表示されない場合、こちらをクリックして問題を修正します。

  7. [実行] をクリックします。
    10 秒ほどでインストールが完了します。リロードボタンを押して、Run Command の実行状況を確認して下さい。

    ヒント : インスタンス ID 左側のラジオボタンをチェックし出力の表示 をクリックすると、実行したコマンドの標準出力を参照できます。

    Systems Manager の Run Command を利用することで、SSH や Session Manager 等でサーバへメンテナンスアクセスせずに複数インスタンスに対して同時に定型作業を実施する事が可能です。

Lab3-Task4: CloudWatch Agent 設定のアップロード

この Task では、CloudWatch Agent の設定ファイルを Systems Manager Parameter Store にアップロードします。 Systems Manager Parameter Store を操作することができる IAM Policy さえ付与されていれば、同一の CloudWatch Agent の設定ファイルを複数の EC2 インスタンスから利用することが可能です。

なお、このハンズオンでは標準的な手順として予め作成された CloudWatch Agent の設定ファイルを利用します。

ヒント : このハンズオンでは予め作成済みの CloudWatch Agent の設定ファイルを使用しますが、ウィザード形式で CloudWatch Agent の設定ファイルを新規作成することも可能です

  1. 下記 URL を右クリックして “名前を付けてリンク先を保存” し、CloudWatch Agent の設定ファイルを PC にダウンロードします。

    CloudWatch Agent 設定ファイル

  2. ダウンロードした CloudWatch Agent の設定ファイルをテキストエディタで開きます。 CloudWatch Agent の設定の概要は以下の通りです。どの項目も、OS レイヤーで CloudWatch Agent が取得する カスタムメトリクス や ログ となっています。これらは、Task1 で確認した標準メトリクスとして取得することが出来ません。
    CPU usage_idle,usage_iowaite,usage_user,usage_system
    Disk usage_percent,inodes_free
    Disk IO io_time,write_bytes,read_bytes,writes,reads
    Memory mem_used_percent
    Swap swap_used_percent
    Network tcp_established,tcp_time_wait
    Process Apache httpd のプロセスをモニタリング
    “pid_file”: “/var/run/httpd/httpd.pid”
    cpu_time,cpu_usage,memory_locked,memory_rss,memory_vms,num_threads,pid,pid_count
    Log Apache httpd のログをストリーム送信
    “file_path”: “/var/log/httpd/access_log”
    “file_path”: “/var/log/httpd/error_log”

  3. AWS マネジメントコンソールで [サービス] から [Systems Manager] をクリックします。

  4. 画面左側のナビゲーションペインで [パラメータストア] をクリックします。

  5. [パラメータの作成] をクリックします。

  6. 以下の値を入力します。
    名前 AmazonCloudWatch-Agentconf-Lab3
    説明 AmazonCloudWatch-Agentconf
    利用枠 標準
    タイプ 文字列
    データ型 text
    値 ダウンロードした CloudWatch Agent 設定ファイルをテキストエディタで開き、コピー ＆ ペーストしてください

  7. [パラメータを作成] をクリックします。

    これで、CloudWatch Agent の設定ファイルが Parameter Store にアップロードされました。

Lab3-Task5: CloudWatch Agentの実行

この Task では、Web Server01 で CloudWatch Agent を実行し、カスタムメトリクスとログの送信を開始します。

  1. AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。

  2. 左側のナビゲーションペインで [インスタンス] をクリックします。

  3. Web Server01 左のチェックボックスをクリックします。 ​

  4. 画面上部の [接続] をクリックします。 ​

  5. 接続方法 [セッションマネージャー] を選択します。 ​

  6. [接続] をクリックします。

  7. 以下のコマンドを実行して、Collectd のデータファイルを作成します。

    sudo su ec2-user
cd ~
sudo mkdir -p /usr/share/collectd/
sudo touch /usr/share/collectd/types.db

  8. 以下のコマンドを実行して、Systems Manager parameter store から Task5 で作成したモニタリング設定ファイルを読み込みながら CloudWatch Agent を起動します。

    sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c ssm:AmazonCloudWatch-Agentconf-Lab3 -s

  9. 以下のコマンドを実行すると、CloudWatch Agent のステータスが参照できます。
    コマンドの実行結果が "status": "running" となっていれば正常です。

    sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status

    暫くすると、CloudWatch Agent から カスタムメトリクスの送信が開始されます。

  10. AWS マネジメントコンソールで[サービス] から[CloudWatch] をクリックします。

  11. 左側のナビゲーションペインから[メトリクス] をクリックします。

  12. [すべてのメトリクス] タブの検索フォームに、先の手順でコピーしておいた Web Server01 のインスタンス ID をペーストします。 Task1 では表示されなかった CWAgent が表示されるはずです。

    ヒント : CWAgent が表示されない場合は更新ボタンを押してください。それでも表示されない場合は 1-3 分ほど待って、更新ボタンを押してください。 ヒント : 数分待っても CWAgent が表示されない場合は CloudWatch Agent が想定通り動いていない可能性があります。以下のコマンドを実行して Agent の状態を確認してください。

    cat /var/log/amazon/amazon-cloudwatch-agent/amazon-cloudwatch-agent.log

  13. [CWAgent] > [ImageId,InstanceId,InstanceType,cpu] の順にクリックします。

    標準メトリクスでは取得できなかった、OS から見た CPU 使用率である iowait , user , system , idle がカスタムメトリクスとして取得できています。

  14. [CWAgent] > [ImageId,InstanceId,InstanceType,pid_finder,pidfile] や [ImageId,InstanceId,InstanceType,pidfile,process_name]　の順にクリックします。

    1-3 分ほど待つと標準メトリクスでは取得できなかった、httpd プロセスのプロセス数、CPU、メモリ使用量等がカスタムメトリクスとして取得できています。

Lab3-Task6: CloudWatch によるアラーム設定

この Task では、ブログサイトを構成する Web Server01 の CPU 使用率 (user) のカスタムメトリクスに対して、アラームを設定します。

  1. CloudWatch マネジメントコンソールで、ナビゲーションペインから [アラーム] > [すべてのアラーム] をクリックし、次に [アラームの作成] をクリックします。

  2. [アラームの作成] ウィザードが開きます。

  3. [メトリクスの選択] をクリックします。

  4. [CWAgent] > [ImageId,InstanceId,InstanceType,cpu] の順にクリックします。

  5. メトリクス名 cpu_usage_user にチェックし、[メトリクスの選択] をクリックします。

  6. [メトリクスと条件の指定] の[条件] フィールドで以下の値を指定します。
    しきい値の種類 静的
    cpu_usage_user が次の時… より大きい
    …よりも 70
    その他の設定 （デフォルトのまま）

    ※CPU使用率が 70% を超えた場合にアラームを発報する設定とします

  7. [次へ] をクリックします。

  8. [アクションの設定] の [通知] フィールドで以下の値を指定します。
    アラーム状態トリガー アラーム状態
    SNS トピックの選択 新しいトピックの作成
    新規トピックの作成中（トピック名） Lab3-Alarm
    通知を受け取る E メールエンドポイント … ご自分のメールアドレス
    ※ 実際のメールアドレスを登録したくない方は、ダミーとして johndoe@example.com　を入力してください。

    ヒント : ダミーのメールアドレスを利用しない場合は、この後、通知の受け取り受諾確認メールが送信されます。現在、メールを確認できるメールアドレスを指定してください。 登録したメールアドレスの受信設定として、@sns.amazonaws.com からの受信を許可してください。

  9. [トピックの作成] をクリックします。

  10. [次へ] をクリックします。

  11. AWS マネジメントコンソールに戻り、[説明の追加] の[名前と説明] で以下の値を指定します。
    アラーム名 CPU utilization(user) High
    アラームの説明 （記述無しのままにします）

  12. [次へ] をクリックします。

  13. [プレビューと作成]で設定を再確認し、[アラームの作成] をクリックします。

    ヒント : “一部サブスクリプションが確認待ちの状態です” とメッセージが表示されます。これは、先ほど指定したアラーム送信先のメールアドレスで、SNS からのアラート通知を受け取ることを承諾していないためです。

  14. メールアドレスとして指定したアカウントの受信ボックスを確認します。

    ヒント : ダミーのメールアドレスを登録した方は、この手順をスキップしてください

  15. 受信した確認メールを開き、[Confirm subscription]というリンクをクリックして開きます。
    Web ブラウザが開き、「Subscription confirmed!」というメッセージ」が表示されます。

    ヒント : ダミーのメールアドレスを登録した方は、この手順をスキップしてください

  16. CloudWatch マネジメントコンソールで、[アラーム] の[OK] 状態に作成したアラームが表示されていることを確認します。

    この時点では、インスタンスの CPU には負荷がかかっていないため、[OK] と表示されるはずです。 収集するデータポイントが少ないと、[不足] と表示されます。 インスタンスの CPU に負荷がかかっている場合は、[アラーム] と表示されます。

  17. 意図的に CPU に負荷をかけるコマンドを使用して、アラームを発報させることが可能です。 アラーム発報を試す方は こちらをクリック してください。 アラーム発報は試さず、次の Task に進んでいただくことも可能です。

　

Lab3-Task7: CloudWatch Logs の確認

この Task では、CloudWatch Logs で Web Server01 上で稼働している Apache httpd (Web Server) のアクセスログが取得されていることを確認します。

  1. 自身のブログサイト(WordPress) へアクセスすると、http サーバのアクセスログ・エラーログがストリーム送信されます。 ブログサイト (WordPress) へのアクセスは数回行ってください。存在しないファイルにアクセスすると、エラーログが生成されます。

    アクセス先 URL は、http://<ロードバランサー (WordPressLB)の DNS 名> と指定します。
    以下は URL の例です。 例）http://wordpresslb-123456789012.ap-northeast-1.elb.amazonaws.com

  2. AWS マネジメントコンソールで [サービス] から [CloudWatch] をクリックします。

  3. ナビゲーションペインで [ロググループ] をクリックします。

  4. Web Server01 から CloudWatch Agent によって CloudWatch Logs へログ送信されていれば、HttpAccessLog と HttpErrorLog という 2 つのグループが表示されます。

    HttpAccessLog と HttpErrorLog のどちらも表示されていない場合は、自身のブログサイト (WordPress) へアクセスしてください。http サーバのアクセスログが CloudWatch Logs へストリーム送信されます。

    ヒント : この時点では Web Server01 でのみ CloudWatch Agent でログ送信しているため、自身のブログサイト (WordPress) へのアクセスは数回行ってください。

  5. [HttpAccessLog] をクリックします。

    このビューは、ログストリームを表示します。複数のインスタンスがデータを報告していた場合（Auto Scaling ウェブサーバー群のインスタンスなど）、このページに複数のログストリームが一覧表示されます。

  6. 表示された [ログストリーム] で、i- から始まる Web Server01 から送信されたログをクリックします。

    Web Server01 への HTTP アクセスを Apache httpd が記録した アクセスログ が表示されます。

  7. ナビゲーションペインで [ログ] 配下の [Logs Insights] をクリックします。

  8. [ロググループを選択] で HttpAccessLog を選択します。

  9. クエリの実行　をクリックします。

    ログストリームで参照した Web Server01 の Apache httpd のアクセスログと同じ情報が参照できます。 この時点では Web Server01 からのみログが送信されていますが、サーバー台数が増えても CloudWatch Agent から同じロググループへログ送信していれば、複数サーバーが送信したログを横串で参照することが可能です。

  10. クエリフィールドが以下のような記述になっていることを確認します。

    fields @timestamp, @message
| sort @timestamp desc
| limit 20

  11. クエリフィールドを以下の内容に上書きします クエリをコピー ＆ ペーストで貼り付けてください

    parse '* - * [*] "* * *" * * * *' as host, identity, dateTimeString, httpVerb, url, protocol, statusCode, bytes,Referer,UserAgent
| stats count(*) as requestNum by url
| sort requestNum desc
| limit 10

  12. クエリの実行　をクリックします。

    CloudWatch Logs に集約された Apache httpd のログに対してクエリを実行して、リクエスト数が多い URL Top10 を表示しました このように、簡易なログ分析であれば CloudWatch Logs Insight だけで実現できます。

Lab3-Task8: Managed Service のモニタリング、およびダッシュボード

この Task では、ALB や RDS などの Managed Service に対するモニタリングの様子を確認します。また、CloudWatch のダッシュボード機能を利用して、WordPress のブログサイトへのアクセス量・ALB の負荷分散先ホスト数を可視化します。

  1. AWS マネジメントコンソールで [サービス] から [CloudWatch] をクリックします。

  2. 左側のナビゲーションペインから [メトリクス] > [すべてのメトリクス] をクリックします。

  3. [メトリクス] > AWS の名前空間 に ApplicationELB,RDS,EBS,NATGateway などの Managed Service が存在していることを確認します。 フィルタ条件が残っている場合は、表示内容が限定されています。フィルタ条件を削除してください。

    ヒント : Managed Service の多くは CloudWatch と統合されており、リソース生成後に自動的にモニタリングが開始されます

  4. [ApplicationELB] > [AppELB別、TG別メトリクス] をクリックします。

  5. メトリクス名 列を参照して、HealthyHostCount 、 RequestCountPerTarget の 2 つを選択します。 画面上部のグラフエリアに時系列でメトリクスのチャートが表示されます。

  6. グラフ化したメトリクス タブで以下のように設定します。
    ラベル 統計 期間 Y 軸
    HealthyHostCount 平均 1 分 <
    RequestCountPerTarget 合計 1 分 >

  7. アクション で ダッシュボードに追加 を選択します。

  8. 以下の値を入力します
    ダッシュボードの選択 新規作成 をクリックします
    WordPressDashboard と入力します
    作成 ボタンをクリックしてダッシュボードを新規作成します
    ウィジェットタイプの選択 線
    ウィジェットタイトルのカスタマイズ ALB Targets

  9. [ダッシュボードに追加] をクリックします。

    ウィジェットの右下をドラッグして、サイズを変更してください ウィンドウ右上の更新ボタン右の▼をクリックすると、自動更新の間隔が選択できます

  10. [ダッシュボードの保存] をクリックします。

Lab3-Task9: AMIの作成

この Task では、Lab4 以降で作成する EC2 インスタンスのベースイメージとなる AMI を作成します。
作成された AMI は Lab1～4 の設定が組み込まれているため、WordPress Plugin、CloudWatch Agent が設定済みの状態の AMI となります。

  1. AWS マネジメントコンソールで [サービス] から [EC2] をクリックします。

  2. 左側のナビゲーションペインから [インスタンス] をクリックします。

  3. ラボ 1 で作成した Web サーバーインスタンス (Web Server01) を右クリックし、[イメージとテンプレート] - [イメージを作成] の順に選択します。

  4. [イメージを作成] ダイアログボックスで以下の設定を指定します。
    イメージ名 myAMI-Lab3
    イメージの説明 lab3-wordpress-ami
    再起動しない チェックあり

  5. [イメージを作成]をクリックします。

  6. 左側のナビゲーションペインで [AMI] をクリックし、AMI の一覧を表示します。
    作成した AMI(myAMI-Lab3) の [状態] が [available] になるれば AMI の取得が完了です。数分かかる場合があります。

    ヒント : AMI 取得には数分かかりますので、次のタスクに進んでください。

Lab3-Task10: データベースのスナップショットの取得

このセクションでは Lab5 の事前準備作業として、RDS でデータベースのスナップショット機能を使用してバックアップを取得します。

  1. AWS マネジメントコンソールで [サービス] から [RDS] をクリックします。

  2. 左側のナビゲーションペインで [データベース] をクリックします。

  3. インスタンスの一覧から DB サーバー [chapter1] を選択して [アクション] から [スナップショットの取得] を選択します。 [アクション] メニューに [スナップショットの取得] が表示されない場合は、ナビゲーションペインで [スナップショット] を選択して [スナップショットの取得] ボタンからスナップショットを取得してください。操作方法は以下の手順と同様です。

  4. [DB スナップショットの取得] ページで以下のように指定します。
    DB インスタンス chapter1 (入力済み)
    スナップショット名 wpdbbackup-lab3

  5. [スナップショットの取得]をクリックします。

  6. スナップショットの一覧画面で、作成したスナップショットの [ステータス] が [available] になるとスナップショット取得が完了です。
    画面が変わらない場合は、右上の [サーバーからのデータの更新] ボタンをクリックして画面をリフレッシュしてください。
    ※ スナップショット取得には 5 分 〜 10 分程度かかりますので、次のタスクに進んでください。

Lab3-Challenge Task1: CloudWatch Agentの展開

この Task では、Systems Manager を利用して Web Server02 へ CloudWatch Agent を設定、実行します。 Task5 で Web Server01 に対してマニュアル操作でコマンド実行した内容を、Systems Manager Run Command のみで半自動化して実施する手順となっています。

ヒント : Challenge Task はハンズオンをより深く理解をするための Task です。次のモジュールやラボに進むための必須手順ではありません。

  • Task 実施時間目安：5 分

  1. AWS マネジメントコンソールで [サービス] から [Systems Manager] をクリックします。

  2. 画面左側のナビゲーションペインで [Run Command] をクリックします。

  3. [Run Command] をクリックします。

  4. コマンドドキュメントのペインにある検索フォームで AWS-RunShellScript と入力します。

    "AWS-RunShellScript" は EC2 インスタンス内で SSM Agent が皆さんに代わってシェルを実行します。 SSH や Session Manager でサーバにログインせずに、各種 OS 上の操作が可能です。

  5. AWS-RunShellScript の横のラジオボタンをクリックします。

  6. 次の値を入力します。
    ドキュメントのバージョン ランタイムの最新バージョン
    コマンドのパラメータ sudo mkdir -p /usr/share/collectd/; sudo touch /usr/share/collectd/types.db
    ターゲット インスタンスを手動で選択する
    Web Server02 にチェックしてください

    ターゲットに Web Server01、Web Server02 が表示されない場合、マネジメントコンソール右上のリージョンがラボのリージョンになっているか確認してください。指定されたリージョンで操作しているが表示されない場合、こちらをクリックして問題を修正します。

  7. [実行] をクリックします。
    5 秒ほどでコマンド実行が完了します。リロードボタンを押して、Run Command の実行状況を確認して下さい。

  8. 画面左側のナビゲーションペインで [Run Command] をクリックします。

  9. [Run Command] をクリックします。

  10. コマンドドキュメントのペインにある検索フォームで AmazonCloudWatch-ManageAgent と入力します。

    ヒント : “AmazonCloudWatch-ManageAgent” は SSH や Session Manager で EC2 インスタンスにアクセスすることなく、 CloudWatch Agent の設定、起動、再起動、停止等を行うことが出来ます。

  11. AmazonCloudWatch-ManageAgent 横のラジオボタンをクリックします。

  12. 次の値を入力します。
    ドキュメントのバージョン ランタイムの最新バージョン
    Action configure(デフォルトのまま)
    Mode ec2(デフォルトのまま)
    Optional Configuration Source ssm(デフォルトのまま)
    Optional Configuration Location AmazonCloudWatch-Agentconf-Lab3
    Optional Open Telemetry Collector Configuration Source ssm(デフォルトのまま)
    Optional Open Telemetry Collector Configuration Location null(デフォルトのまま)
    Optional Restart yes
    ターゲット インスタンスを手動で選択する
    Web Server02 にチェックしてください

  13. [実行] をクリックします。
    5 秒ほどで CloudWatch Agent の設定が完了します。リロードボタンを押して、Run Command の実行状況を確認して下さい。

これで、Web Server01 と Web Server02 は同じメトリクス、ログのモニタリングが可能になりました。WordPress のブログにアクセスして CloudWatch のメトリクス、ログを確認してみましょう。

終了

このラボでは、Amazon CloudWatch および Amazon CloudWatch Logs を使用して、ブログサイトを構成するリソースの性能監視やインスタンス内部のログを収集してシステム運用に必要なモニタリング環境を構築しました。

お疲れさまでした。これで Lab3 は終了です。 このラボで作成した環境は継続して利用するので、[ラボを終了] はクリックしないでください。

補足：インスタンスとSSM間の接続を回復する

EC2 インスタンスに ssm agent がインストールされていても、適切な IAM Role やネットワーク接続性がないと Managed Instance として利用できません。 以下の手順で EC2 インスタンスとAWS Systems Manager(SSM) 間の接続を回復させます。

  1. IAM Role “WP-Role” に Systems Manager へのアクセス権限 AmazonSSMManagedInstanceCore がアタッチされているか、確認して下さい

  2. IAM Role “WP-Role” に Systems Manager へのアクセス権限がアタッチされている場合、Systems Manager Agent と Systems Manager 間のヘルスチェックがまだ実施されていない可能性があります。以下の手順を実施して、強制的に Systems Manager Agent　と Systems Manager 間の通信開始を試みます。

    Web Server01 に Session Manager でログインする。 次のコマンドを実行して Systems Manager Agent をリスタートする。

    sudo systemctl restart amazon-ssm-agent

  3. Web Server02 でも同様のコマンドを実行します。

  4. こちらをクリック して、もとの Task に戻り、再度 Run Command のパラメータ設定から行います。

補足：負荷をかけて、CloudWatchによるアラーム発報を行う

意図的に CPU に負荷をかけるコマンドを使用して、アラームを発報させることが可能です。 コマンドの実行を誤ると意図しない高負荷状態になりますので、慎重に操作をしてください。

  1. Web Server01 に Session Manager で接続する。

  2. 次のコマンドで簡易負荷ツール stress をインストールする。

    sudo amazon-linux-extras install -y epel; sudo yum install -y stress

  3. 次のコマンドを実行して、Web Server01 に 600 秒間 CPU 負荷をかける。

    stress -c 1 -t 600

  4. こちらをクリック して、もとの Task に戻ます。