24時間365日フルマネージドホスティングサービスのデイーネット

クラウド導入支援・運用支援 ディーネット 導入事例

CloudWatchでテストのためにアラームを発報させる3つの方法

こんにちは。構築担当の下地です。

私は会社でも自宅でも親指トラックボール派です。

でも最近親指を酷使しすぎたのか、付け根が痛くて腱鞘炎気味なので、泣く泣くマウスに乗り換えました。

早く治るといいのですが・・

さて、今日はCloudWatchのアラームについてお話します。

よろしくお願いします。

CloudWatchのアラーム

CloudWatchは説明不要なほどAWSでよく利用するサービスですが、もっと詳しく知りたいと思い少しずつ触っています。

色々検証でアラームを設定すると次はそのアラームをチェックしたくなるのですが、手動でテストのためにアラームを発報させる方法ってどうするんだっけ?と気になったので調べてみました。

まずアラーム設定

簡単なアラームをセットして試してみます。

テスト用にEC2(MyTestServer01)を1台作成し、アラームをセットしました。

アラーム1.jpg

アラーム内容は以下の通りです。

・通知の送信先:自分のアドレス

・アクションを実行:インスタンス再起動

・発生条件:ステータスチェック(インスタンス)に失敗

・最低期間:1分間以内に1回発生

・アラーム名:MyTestEC2Alarm

アラーム2.jpg

これでアラームのセットができました。

CloudWatchのマネジメントコンソール画面(以下マネコン)からもアラームが作成されていることを確認します。

アラーム3.jpg

テストでアラーム発報①:本当にアラーム発生条件に該当する状態にする

まず1つ目の方法としては、当たり前ですが「EC2をアラーム発生条件に当てはまる状態に設定する」です。

今回のアラーム発生条件はインスタンスのステータスチェック失敗ですので、試しにNICをダウンさせてみます。

これによりわざとステータスチェックが失敗する状態にします。

SSHでテスト用サーバにログインして、eth0をダウンさせます。

[root@webtestserver ~]# ifdown eth0

これでOKです。

実行すると直後にSSHが切断されます。

この状態でマネコンを見てると、しばらくしてインスタンスのチェック失敗が表示されました。

wazato1.jpg

CloudWatch側でもアラーム状態に遷移しています。

wazato1-2.jpg

これでアラーム発生時のアクションを再起動にしているため、自動でサーバ再起動が実施されます。

再起動後はNICが正常に戻るはずです。

またしばらく待っていると、EC2のインスタンスヘルスチェックが正常に戻りました。

wazato1-3.jpg

CloudWatch側も再び「OK」のステータスに遷移しています。

wazato1-4.jpg

これがまず1つ目の方法となります。

テストでアラーム発報②:アラーム発生条件の閾値を手動で調整する

二つ目の方法は、アラーム発生条件の閾値を手動で変更して、通常時なのにアラーム発生条件に含まれるようにします。

例えば今回のアラームは、閾値が初期状態だと以下の通りになっています。

wazato2-1.jpg

判定に使われるのは「StatusCheckFailed_Instance」で、この値が「1以上」になるとアラームを発報します。

このステータスは通常時が0で、インスタンスチェック失敗時に1になります。

そこで、この閾値を0以上に変更します。

すると通常の状態でも常にアラーム発報状態となります。

wazato2-2.jpg

こんな感じで変更。

すると以下の通りマネコンに反映されます。

wazato2-3.jpg

またこの変更を反映すると直後にSSHが切断されました。

すぐに再起動がかかったようです。

CloudWatchでもアラーム状態となっています。

wazato2-4.jpg

数十秒後に再びSSH接続できました。

wazato2-5.jpg

ただ、この手法ですとアラーム発報でリブートがかかっても依然アラーム状態が継続します(閾値が0以上なので当然ですが・・)。

EC2のマネコンでもアラーム状態のままとなっています。

wazato2-6.jpg

またアラーム状態は継続しますが、再起動がかかかるのは1回のみでした。

これが2つ目の方法です。

テストでアラーム発報③:set-alarm-state コマンドを使用してアラーム状態の変更する

3つ目の方法は、aws cliを使って設定したアラームの状態を変更します。

参考:https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/US_AlarmAtThresholdEC2.html

今回は該当のEC2にSSH接続して、そこでCLIを実行してみます。

このEC2には事前にIAMロールを割り当ててCLIが実行できる権限を渡しています。

コマンドは以下の感じ。

[root@webtestserver ~]# aws cloudwatch set-alarm-state --alarm-name "MyTestEC2Alarm" --state-value ALARM --state-reason "alarmtest"

これでOKです。

この方法ですと、実行後にマネコン側では変化を確認できませんでした。

ただ、

・実行直後にSSHが切断されたこと

・通知先メールアドレスにアラーム通知メールが届いていること

wazato3-1.jpg

・サーバ側でリブート履歴が残っていること

wazato3-2.jpg

から、アラームが発報して再起動がかかっていることがわかりました。

これが3つ目の方法です。

まとめ

今回は3つ方法を紹介しましたが、もしかしたら他にも何か方法があるかもしれません。

また今後はEC2だけでなく他のサービスでも色々CloudWatchの検証しようと思います。

お読み頂きありがとうございました。

おまけ

アラームを色々設定した後にアラーム名を変更しようとしたら、マネコンのどこを触っても変更箇所が出てきませんでした。

おかしいなと思ってマニュアル見ると、

おまけ.jpg

既存アラームの名前変更不可とのこと。。

まじですかー

参考:https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/Edit-CloudWatch-Alarm.html

  • このページの先頭へ

  • 東京本社
    〒105-0001東京都港区虎ノ門2-3-22 第一秋山ビル5F
    TEL:03-3591-8887 FAX:03-3591-8886
  • 大阪本社
    〒541-0041 大阪市中央区北浜2-6-11北浜エクセルビル5F
    TEL:06-6231-8887 FAX:06-6231-8897

  • 認証範囲はこちらをご覧ください。

Denet logo

クラウドサービス・データセンタ・高機能専有サーバ・共有サーバホスティングサービス 株式会社ディーネット
dot_bar