1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@hidekko(hideaki koga)

【みんな大好き】AWSのCloudWatchでログインの必要なサイトの正常性を監視する02【CloudWatch】

1
Posted at

前回の記事の続きです。
やっと本体の監視基盤の構築です。

構成図

diagram01.png
全体の構成図はこの通り変わりありませんが、今回は以下の赤枠内のAWS側を設定します。
image.png

監視基盤構築

では早速AWSの監視基盤を構築します。

CloudWatch構築

AWSコンソールにログイン

AWSコンソールにログインし[検索]窓に[CloudWatch]と入力します。
image.png
CloudWatchが出てくるのでクリックします。
image.png

CloudWatch Synthetics Canaries構築

CloudWatchのサービスの中でも今回はSynthetics Canariesを使いますので、[Application Signals]から[Synthetics Canaries]を選択します。
image.png
カナリアサイトのカナリアですね。
語源としては炭鉱内での工事の際、ガス漏れをいち早く検知するために連れていくカナリアですね。
人がガス中毒で倒れる前に、人よりも有毒なガスにより敏感なカナリアさんにその代わりを務めてもらう、ということですね。
カナリアさん、ごめんなさい。
でもITの世界では誰も犠牲になりません。
良い世の中になりましたね。
Syntheticsの画面から[Canaryを作成]をクリックします。
image.png
[設計図を使用する]から[GUIワークフロービルダー]を選択します。
image.png

Canaryビルダーで名前を設定します。
image.png

[アプリケーションまたはエンドポイントURL]で今回https://カスタムドメイン/login.phpと入力します。
ワークフロービルダーでID、パスワード、を入力し前の記事で設定しているセレクターと共に指定します。
image.png

HTTPリクエストは無視して、次のスクリプトエディタではsyn-nodejs-puppeteer-15.1を選択します。
スクリプト内の情報を削除します。
image.png

削除したスクリプトに、以下のコマンドを貼り付けます。

monitor.js
const synthetics = require('Synthetics');
const log = require('SyntheticsLogger');

const pageLoadBlueprint = async function () {

    const page = await synthetics.getPage();

    await synthetics.executeStep('Open Login Page', async function () {

        await page.goto(
            'https://[カスタムドメイン]/login.php',
            {
                waitUntil: 'networkidle0',
                timeout: 30000
            }
        );
    });

    await synthetics.executeStep('Input Username', async function () {

        await page.type(
            'input[name="username"]',
            'admin'
        );
    });

    await synthetics.executeStep('Input Password', async function () {

        await page.type(
            'input[name="password"]',
            'P@ssw0rd0123'
        );
    });

    await synthetics.executeStep('Click Login Button', async function () {

        await Promise.all([
            page.waitForNavigation({
                waitUntil: 'networkidle0',
                timeout: 30000
            }),
            page.click('button[type="submit"]')
        ]);
    });

    await synthetics.executeStep('Verify Login Success', async function () {

        await page.waitForSelector(
            '#login-success',
            {
                timeout: 10000
            }
        );
    });
};

exports.handler = async () => {
    return await pageLoadBlueprint();
};

スケジュールは、今回手動実行したいので[1回実行]を選択します。
image.png

後はデフォルト設定値のままです。
デフォルト設定値の中でS3を構築していますので後から説明します。

最後に[Canaryを作成]をクリックします。
image.png

以下のようにカナリアが構築されます。
image.png

構築はこれにて完了です。

CloudWatch Synthetics Canaries動作確認

正常系

まずは正常系です。
構築したカナリアにアクセスします。
image.png

アクセスすると実行されて、Last Runの部分に成功と出てきます。
image.png

詳細を見てみると2回実行されています。
それぞれブラウザが違い、FIREFOXとCHROMEとみてくれているみたいですね。
素晴らしいですね。
更に面白いのが[スクリーンショット]をクリックします。
image.png

画面が少し小さくて見にくいですが、各ステップの設定が確認できます。
image.png

2つ目のステップを見てみるとこの通りログインユーザー名にちゃんと指定したIDを入力してくれています。
素晴らしいですね。
image.png

このスクリーンショットの保存先が、先ほどカナリア作成の際に説明をスキップしたデフォルトパラメータで作成したS3になります。

異常系

次に異常系です。
Azure App Serviceでログイン後のdashboard.phpをリネームしてみましょう。

rename.sh
mv site/wwwroot/dashboard.php site/wwwroot/dashboard.php_org

実際に実行してみるとこのようになります。
image.png

実際にアクセスしてみてNot foundになりましたね。
image.png

AWSコンソールのCloudWatchのSynthetics Canariesから構築したカナリアを選択し、[アクション]から[開始]を実行します。
image.png

ちゃんと失敗になりましたね。
上にある緑の帯の成功！というのは、Canaryの起動(実行)に成功したのであって、起動したCanaryの結果が成功、ではないです。
誤認しやすくて少しややこしいですね。
中身を詳細に確認するために先ほどと同じようにスクリーンショットを見てみます。
image.png

思っている通りの場所でコケてくれていますね。
image.png

メール送信

ここまでできればあと一息です。
このCanaryで検知した失敗をトリガーにメールを送信すれば構築は完了です。

CloudWatch Synthentics Canariesで先ほど作成したカナリアをクリックし、[アクション]から[編集]をクリックします。
image.png

下の方にちゃんとパラメーターが用意されているCloudWatch アラーム - オプションをクリックします。
このようにちゃんとUIにパラメーターが用意されているので最初からアラームを作りこむこともできたのですが、構築中に色々詰め込んでしまうと切り分け、確認が面倒かなと思うので今回は分けました。
image.png

[アラームのSNSトピックを編集する]をクリックします。
image.png

[アラームの作成]
image.png

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

メトリックス選択画面が出てくるのでカスタム名前空間から[CloudWatch Synthentics]をクリックします。
image.png

[Canary]をクリックします。
image.png

[test-canary01]の[Failed]を選択(チェックボックスのチェックを入れる)し、[メトリックスの選択]
image.png

[統計]の部分はデフォルトだと平均になっているようですが、[合計]に変更します。
平均でも良いと思うのですが、「1回でも失敗したらアラートをあげる」ということを目的に据えるとするならば[合計で一回でも失敗したら発報]とするポリシーの方がわかりやすいと思います。
青枠で囲んでいる[期間]ですが、このカナリアを何分間に1回実行するかを設定するので、この実行から実行までの期間をアラートを集計する期間として設定します。
先ほど統計を平均から合計に変えましたが、「どの期間からどの期間までの平均/合計なの？」という疑問が出てくると思いますが、この期間を表しています。
image.png

[閾値]は今回静的とし、異常検出といういわゆる動的な閾値にはしないでおきます。
[Failedが次の時]も[より大きい＞]という値にしておきます。
[...よりも]は[1]とし、これで「監視対象のWebサービスで1回でもサービス停止が検出されれば発報」という条件になります。
image.png

[アラーム状態トリガー]は[アラーム状態]を選びます。
設定した閾値を超えた状態＝アラームとして処理＝アラーム状態、ということですね。
わかりにくいですね。
[SNSトピックに通知を送信]、ですが、これは[新しいトピックの作成]をクリックし、トピック名を適当に決めます。
[通知を受け取るEメールエンドポイント]にメールを受信したいメールアドレスを入力します。
最後に[トピックの作成]をクリックします。
image.png

トピックが正しく設定されたことで以下のように表示が変わり、[新規作成]だったSNSトピックが[既存のSNSトピックを選択]に変化します。
image.png

後は設定変更しないので最後まで進み[次へ]をクリックします。
image.png

[アラーム名]に任意の名前を入力し、[次へ]をクリックします。
image.png

最後にこれまでのパラメーターの確認画面が出てくるので[アラームの作成]をクリックします。
image.png

無事アラームが作成されました。
image.png

以上でメール発報のAWS側の設定は完了です。

受信メールアドレス側設定

今回の発報メールを受け取るよ、と設定したメールアドレス宛に以下のようなメールが届きます。
メールの中に[Confirm subscription]というボタンがあるのでクリックします。
これをクリックすることで、SNSにこのメールを登録する、という行為が成立します。
image.png

[Confirm subscription]を押すとブラウザが立ち上がり、以下の画面が出てきます。
image.png

無事、SNSトピックにこのメールアドレスが送信用のメールアドレスとして登録されました。
私も検証中、このConfirmの処理を終えずに何度も検証しているのに全然メールが飛んでこずに時間を無駄に使ってしまったため、皆様お気を付けください。

アラートメール発報確認

ではちゃんとメールが飛ぶか確認作業です。
カナリアを呼び出して[開始]を実行します。
image.png

無事以下のようなメールが届きました。
image.png

はい。
完璧ですね。

本日はここまで。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?