ELBのヘルスチェック失敗をCloudWatchアラームで監視してメール通知してみた

こんにちは！コンサル部のinomaso(@inomasosan)です。

ELBのヘルスチェックで失敗した場合にメールを受け取れるように、以下のブログをベースに検証してみました。

今回はAWSマネジメントコンソールでCloudWatchアラーム周りを中心に設定方法まとめました。

ヘルスチェックって何？

ELBからターゲット(EC2等)に対して定期的にヘルスチェックを実行し、正常かどうかを判断することができます。
ヘルスチェックの失敗で、EC2内のWebサービス(ApacheやNGINX)やEC2自体の障害等が発生していることを検知することが可能です。

• (BlackBelt)Elastic Load Balancing (ELB)抜粋

前提

ALBやEC2等のリソースが作成済みで、平常時のヘルスチェックのステータスがhealthyであることを前提とします。

やってみた

CloudWatchアラームで異常なEC2の数を監視し、アラームが実行された場合はAmazon SNS経由でメール送信するよう設定していきます。

CloudWatchアラーム作成

アラーム作成開始

• AWSマネージメントコンソールから CloudWatch サービスを選択
• 左ペインからアラーム状態を選択し、アラームの作成をクリック

監視するメトリクスの選択

• メトリクスの選択をクリック

• 参照タブのApplicationELBをクリック

• AppELB 別、AZ 別、TG 別メトリクスをクリック

• 監視対象とするELBとターゲットグループのUnHealthyHostCountにチェックを入れ、メトリクスの選択をクリック
  • ターゲットグループはEC2等のターゲットの集合体
  • UnHealthyHostCountは異常なEC2等の数

メトリクスと条件設定

• 統計は最小を選択
• 期間は1分を選択
  • 1分毎にデータを収集

• しきい値の種類に静的を選択
• アラーム条件に以上を選択
• しきい値に1を入力
  • 異常なEC2が1台でもあればアラームを実行する

• アラームを実行するデータポイントに5/5と入力
  • 1分毎に収集したデータが5回連続で条件を満たした場合にアラームを実行する
• 欠落データの処理に欠落データを不正 (しきい値を超えている)として処理を選択
  • EC2自体が停止している場合はデータ自体が取得できないので、アラームを実行するには、しきい値を超えた扱いにする必要がある

通知設定

• アラーム状態トリガーにアラーム状態を選択
• 次の SNS トピックに通知を送信に新しいトピックの作成をチェック
• 新規トピック名に一意となる任意の名前を入力
• 通知を受け取る E メールエンドポイントにメール受け取り可能なメールアドレスを入力
• 上記が全て完了したらトピックの作成をクリック

• SNSトピックが作成されたことを確認
  • トピックの作成をクリック後に以下のような画面が表示されること

アラームの名前

• アラーム名に任意の名前を入力

プレビューと作成

• ここまで入力した内容が表示されるので、問題ないことを確認しアラームの作成をクリック

Amazon SNSサブスクリプション

Amazon SNS経由でCloudWatchアラームのメールを受信するためには、設定したメールアドレスに届いたメールから登録完了する必要があります。 ただし、メールのConfirm subscriptionリンクをクリックして有効化すると、日々の運用でAmazon SNS経由のメールに記載されている登録解除用のリンクによる登録解除の危険性があります。

以下のブログにリンクを押しても登録解除されないやり方が記載されていますので、そちらを参考に作業願います。

アラームテスト

UnHealthyHostCountを1以上にする

今回は手っ取り早くテストするために、ヘルスチェックのパスを存在しないパスに変更してテストしてみます。

しばらく待つとCloudWatchアラームの状態がアラーム状態となり、以下のようなメールが送信されてきます。

Reason for State Changeを見ると、5回連続でしきい値を超えたためにALARMになったことがわかりますね。

欠落データを発生させる

上述したとおり、EC2自体が停止した場合は、UnHealthyHostCountはデータ自体が取得できません。 なので、今回のテストではEC2自体を停止させて、アラームが実行されるか確認してみます。

しばらく待つと、UnHealthyHostCountを1以上にした時と同様の状態となります。

Reason for State Changeは先ほどと異なり、データ自体が存在しないことが原因とわかります。

まとめ

ELBのヘルスチェック結果の監視は簡単そうに見えて、欠落データを気にしないといけないなど気にしなきゃいけないポイントがあって勉強になりました。 今回はUnHealthyHostCountのみを監視対象としましたが、ターゲットグループ毎に複数台のEC2を運用する場合はHealthyHostCountも組み合わせてシステムの特性にあった監視を検討するのが良いかと思います。

この記事が、どなたかのお役に立てば幸いです。それでは！