今回はAWSの記事です。
- 記事を作ろうと思った経緯
- お題：CloudWatchアラームの「状態」がよくわからない
- 回答：人間同士のやり取りに例えると理解しやすいですよ！
- 補足：欠落データの扱い
- 追加のお題と回答：欠落データは結局どう扱うべきなのか
- 最後に
【AWS】CloudWatchアラームのステータス(状態)を説明してみた
記事を作ろうと思った経緯
AWSでインフラ担当をやっている皆さまにはおなじみの
CloudWatchアラームという機能があります。
EC2が意図せずダウンしたり、
ALBのヘルスチェックが切れて
サービス提供不能になったら通知してくれる便利なヤツ！です。
ところでこの、CloudWatchアラームについて最近質問されました。
お題：CloudWatchアラームの「状態」がよくわからない
CloudWatchアラームをEC2に対して設定したがサーバーダウンを意図したように検知してくれない。
まず【OK】【アラーム状態】【データ不足】の
状態表示(ステータス)があるようだがどういう状態を指すのか？
回答：人間同士のやり取りに例えると理解しやすいですよ！
とある職場のマネージャーMさんは朝礼でメンバーの体調をヒアリングする業務を行っています。
今日もMさんはメンバーそれぞれに対して体調をヒアリングしました。Aさん：バッチリです！
＞これがステータス【OK】そのまんまの意味です。応答があり、かつ正常な状態という意味になります。
EC2に例えると普通に稼働していて、SSHとかでログインできる状態ですね。
Bさん：おなか痛いです。。。
＞これがステータス【アラーム状態】
応答があったけど、異常を訴えているという意味になります。これはEC2のStatusCheckFailed_instance の場合だと、
『EC2は稼働できているけどNICのパラメータが狂っていて疎通不能』
などの時に見られる状況ですね。
Cさん：（不在につき応答なし）
＞これがステータス【データ不足】
応答がなく、状態の識別不能という意味になります。
システム的には1でも0でもなくNullが返ってきた、みたいなイメージですかね。意味不明に感じるかもしれませんが、
人間だったら欠勤しているような状態です。
EC2が停止しているときや削除してしまった後などがこの状態になります。
そう、欠勤＜EC2停止＞や退職＜EC2削除＞しているから
体調不良【アラーム状態】というわけではない、ってことですね！
そういうわけで、欠勤＜EC2停止＞を検知したい場合は
【データ不足】になったことを通知トリガーに設定すると吉、ということになります。
補足：欠落データの扱い
上記【データ不足】の判定は『欠落データの処理』というパラメータで
コントロールすることができます。
デフォルト値は「欠落データが見つかりません」です。
すなわち前述の理屈はこのデフォルト値である時について語っていることになります。
ここを変えるとどうなるのか？
わかりやすくまとめてくれている先達がいたのでリンクを貼っておきます。
【AWS】CloudWatchアラームの「欠落データの処理」について理解する
「欠落データを適正（しきい値を超えていない）として処理」
EC2を停止しても【データ不足】にならない、ということを意味しています。
例えば
夜間は停止しているEC2でかつ、単なる踏み台サーバなど直接業務影響がないものに対して
「NICの障害が発生したら自動的に再起動させたい」場合に有効かもしれません。
「欠落データを不正（しきい値を超えている）として処理」
これを設定すると【データ不足】という状態になることがなくなります。
例えば
ALBのヘルスチェックは【データ不足】というステータス自体が
ターゲット登録なし 状態でしか発生しえないので、
状態管理を一本化したい場合はこの設定をおこなうことに一定の価値を感じますね。
「欠落データを無視（アラーム状態を維持する）として処理」
欠落データを検知する前の状態を維持します。
他の設定値と比べるとヒューマンライクな動作になります。
【OK】だった場合
そのまま【OK】状態を維持します。
つまりEC2を停止しても他の状態へ遷移しません。
【アラーム状態】だった場合
そのまま【アラーム状態】を維持します。
欠落データ＝アラーム判定 ということになるので
EC2を停止しても【データ不足】へ遷移しません。
EC2を起動するなりして欠落データにならず
障害解消した場合は【OK】状態へ遷移するということです。
【データ不足】だった場合
そのまま【データ不足】を維持します。
EC2を起動するなりして欠落データにならなくなった場合
【OK】状態へ遷移するということです。
EC2を起動したとき最初からアラーム判定がなされた場合に限り
【アラーム状態】へ遷移することが考えられます。
上記(欠落データを無視)の状態遷移を表にする
以下のように、【データ不足】に状態遷移することはないと考えてよいでしょう。
| 元の状態 | EC2停止 したあとの状態変化 | EC2起動(正常起動) したあとの状態変化 | EC2起動(起動時異常) したあとの状態変化 |
| 【OK】 | 【OK】 | 【OK】 | 【アラーム状態】 |
| 【アラーム状態】 | 【アラーム状態】 | 【OK】 | 【アラーム状態】 |
| 【データ不足】 | 【データ不足】 ※もともと停止状態 と思われる | 【OK】 | 【アラーム状態】 |
追加のお題と回答：欠落データは結局どう扱うべきなのか
上記の補足内容も含めて自信満々に語ってみたところ、
欠落データは結局どう扱えばいいの？難しいのでわかりやすく説明してほしい。
というPJT(プロジェクト)あるあるな追加質問を頂戴しました。
そういうわけで、また人間同士のやり取りに例えて説明します。
とある職場のマネージャーMさんは欠勤しているメンバーについて、
これまでの管理では、次回出社してきた際に朝礼で体調ヒアリングするまで
ずっと管理簿につけないようにしていましたが、
他のALBチームなどでは管理の仕方が異なっていたりして業務報告時に齟齬があるため
自チーム(EC2)の管理の仕方を改めて検討することにしました。検討１：「欠落データを適正（しきい値を超えていない）として処理」
＞つまり欠勤状態を一律元気と判断するEC2チームはまず出社していることが業務前提なので、この管理方法はふさわしくなさそうです。
検討２：「欠落データを不正（しきい値を超えている）として処理」
＞つまり欠勤状態を一律体調不良と判断する EC2チームは貼りつき業務のため、出社していても体調不良で休憩しているようでは戦力外です。
そういう意味ではこの管理方法に改めてもよいと考えているようです。
ALBチームとも管理方法の足並みがそろっていて、その点でもメリットがあるようです。
ただし、サブマネージャーのSさんは
『欠勤しているメンバーを管理簿へ記載しないのが標準的であり、
ALBチームは特殊な管理をしているので、無理に合わせるのはイマイチだ。
全社的に共通の管理をする、ということになるまでは賛同しかねる』 と反論しているようです。
※要約すると、このAWSアカウントだけヘルスチェックの見方が変わっちゃいますよね？
誤認の原因になることを懸念してます。
ただしすべてのAWSアカウントで標準化していく前提なら異論なし。
と言っている
検討３：「欠落データを無視（アラーム状態を維持する）として処理」
＞つまり欠勤前の状態を引き継ぐ EC2チームはまず出社していることが業務前提なので、この管理方法はふさわしくなさそうです。
欠勤しているメンバーにレジ係を任せたりできないので、かえって煩雑と結論付けたようです。
検討４：「欠落データが見つかりません」
＞つまり欠勤状態を管理簿に付けない ※元の設定結論：
マネージャーのMさんはデフォルト値の検討４：「欠落データが見つかりません」
が適正な管理と考えているようです。
ただし検討２に関しては一考の価値があり、今後業務前提の動き次第で
変更していくことも視野に入れる、と結論付けました。結論、「当AWSにおいてはデフォルト値で問題ない」と回答しました。
最後に
いかがでしたでしょうか。
いざ説明を求められると、専門用語が多くて普通に説明するのは
大変ですが何か別のものに例えると、すんなり納得してもらえたりします。
なお本記事は以下公式URLを自分なりに咀嚼した内容になります。
コメント