今回はAWSの仮想サーバEC2の監視方法について、最低限やっておきたい設定を解説しようと思います。
目次
1. EC2とは
そもそもEC2とはなにか。これはAWS上の基本となる仮想サーバを指します。
仮想サーバの構築方法については、以下ページをご参照ください。
この仮想サーバを利用して、WEBサーバやファイルサーバなどありとあらゆるサーバを構築することになります。ちなみに本件では以下のような構成を想定して仮想サーバに対する監視方法を解説します。
2. 設定しておきたい監視
今回はDBサーバと連携しているWebサーバを想定します。ユーザからの受け口はload balancerとなります。
・load blalancerからの監視
監視は基本的にload blalancerからの監視を考えます。そもそもload balancerの監視にて正常でなければ接続ができないので、ここの設定は強制的にやることになりますが。
一番単純な設定方法としては、トップページを指定して、200番が返るようにしておくことが基本と思います。もしくは、指定したフォルダへ画像ファイルなりを設置してアクセスさせ、200番が返るようにするのが簡単と思います。この場合、httpdサービスの障害に気づけなくなってしまいますが。。。
また、このような設定の場合DBサーバに障害もしくはアクセスできない状況が発生するとサーバを利用できなくなります。また、運用側でそれに気づくことができなくなります。
以下は、load blalancerの監視設定画面。基本は「instances」を選択して、Health checksの中で接続に使うプロトコル（通常はHTTPもしくはHTTPS）、アクセスするパスを指定します。
ではどのような監視としたらよいか。それはDBサーバを含めたアドレスにアクセスするようにするとよいと思います。たとえばテスト用アドレスを準備、アクセスするとDBを参照してテスト用データを返す単純なものでよいでしょう。
あとはそのアドレスをload blalancerのHealth check pathに指定するだけです。これでWebサーバ、DBサーバ双方を監視できることになります。ここはDB設計者との打ち合わせが必要になるかもしれません。
3. アラート通知を含める
さて、各サーバの監視設定は完了しましたがこのままだと単純にアクセスできなくなるだけです。なので、障害が発生したらアラートを運用側へ通知できる仕組みが必要です。
load blalancer（ターゲットグループ）では、以下メトリクスを監視しています。
なので、Cloudwatchのアラーム設定でこのメトリクス用のアラートを作成します。まずターゲットグループIDをメモしておきます。「Cloudwatch」→「アラート」→「アラートの作成」の順で接続し、「メトリクスの選択」を押下します。
ApplicationELBを選択、AppELB別、AZ別、TG別メトリクスを選択します。一覧の中に、「UnHealthyHostCount」が存在するので、「TargetGroup」が該当のものであることを確認して選択します。
次に条件を以下の通りに設定します。（UnHealthyの値が1以上になったら異常とみなすという意味ですね）
次に、異常だった時のアクションを設定します。今回はSNSに設定したメールアドレス宛へアラートを飛ばすよう以下の通り設定をします。（SNSは設定済みとします）
あとは分かり易い名前と、解説を記述して作成が完了です。
Cloud watchアラートの画面で、状態がOKとなれば設定は完了です。
4. まとめ
いかがだったでしょうか。EC2を扱う以上最低限の監視設定となります。次回はインスタンス事態に対するアラートの設定を解説できたらと思います。
最後まで読んでいただき、ありがとうございました。
