DLMのスナップショット作成・削除失敗時にをCloudWatch Alarmで通知を実装してみた

TERAO

3年前

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。

お久しぶりです。株式会社協栄情報システム3部所属の寺尾です。

Amazon Data Lifecycle Manager(以下DLM)を利用していますでしょうか？
自動でスナップショットやAMIの取得ができるので定常作業の自動化が可能で大変便利な機能です。

参考：Amazon Data Lifecycle Manager

ただ、この機能でもしスナップショットやAMIの取得に失敗してもメールでの通知などは行われません。
以下はAWSサポートに問い合わせた際の返答になります。

せっかくスナップショットやAMIの取得を自動化したのに取得が成功しているかどうかをマネジメントコンソールから確認していたら意味がないですよね。

というわけで今回はCloudWatch Alarmを利用して、DLMのスナップショット作成失敗時とDLMのスナップショット削除失敗時にメール通知を実装していこうと思います。

参考：Amazon Data Lifecycle Manager が CloudWatch メトリクスをサポートするように

前提条件

以下の三点が作成されていることを前提条件とします。

EC2
EC2のスナップショットを作成するライフサイクルポリシーとスケジュール
自分のメールアドレスをサブスクリプションのエンドポイントとして登録したSNSトピック

CloudWatch Alarmの作成

以下の設定値に従ってCloudWatch Alarmを作成してみましょう

設定項目	設定値	理由
メトリクス名	SnapshotsCreateFailed SnapshotsDeleteFailed	作成/削除失敗時のメトリクス
DLMPolicyId	監視したいライフサイクルポリシーのDLMPolicyId
統計	最大	エラーが起きていれば1、そうでなければ0であるため期間の途中からエラーが起きても検知できるように最大とした
期間	15分	高い頻度は必要ないので15分とした
しきい値の種類	静的
アラーム条件	以上	1以上でエラー状態とするため
…よりも	1	1以上でエラー状態とするため
アラームを実行するデータポイント	1/1	一度のデータポイントであっても、通知が必要なため
欠落データの処理	欠落データを無視	アラーム後のデータ欠落時はエラーが持続していることが予想されるため

「SnapshotsCreateFailed」メトリクスと「SnapshotsDeleteFailed」メトリクスは以下のように「EBS」→「EBSデータライフサイクル管理メトリクス」配下に存在しています。
監視したいライフサイクルポリシーのDLMPolicyIdで検索すればすぐに見つかります。

また、「SnapshotsCreateFailed」メトリクスと「SnapshotsDeleteFailed」メトリクスの詳細については以下をご確認ください。

メトリクス説明

SnapshotsCreateFailed スナップショットポリシーにより作成できなかったスナップショットの数。これには、スケジュールされた時刻から 60 分以内に失敗した再試行が含まれます。

SnapshotsDeleteFailed スナップショットポリシーまたは EBS-backed AMI ポリシーにより削除できなかったスナップショットの数。このメトリクスは、ポリシーによって作成されたスナップショットにのみ適用されます。このポリシーは、ポリシーによって作成されたクロスリージョンスナップショットコピーには適用されません。
このメトリクスには、EBS-backed AMI ポリシーが AMI の登録を解除したときに削除されるスナップショットが含まれます。

メトリクス	説明
SnapshotsCreateFailed	スナップショットポリシーにより作成できなかったスナップショットの数。これには、スケジュールされた時刻から 60 分以内に失敗した再試行が含まれます。
SnapshotsDeleteFailed	スナップショットポリシーまたは EBS-backed AMI ポリシーにより削除できなかったスナップショットの数。このメトリクスは、ポリシーによって作成されたスナップショットにのみ適用されます。このポリシーは、ポリシーによって作成されたクロスリージョンスナップショットコピーには適用されません。このメトリクスには、EBS-backed AMI ポリシーが AMI の登録を解除したときに削除されるスナップショットが含まれます。

引用元：Amazon CloudWatch を使用したポリシーのモニタリング

欠落データを無視と見つかりませんの違いが分かりにくいですが、

無視は欠落データがある場合はアラート状態を維持します
見つかりませんは欠落データがあり、それによってアラーム状態を決めるのに十分なデータがなければInsufficient data状態になります。
という違いがあります。

設定項目	設定値	理由
アラーム状態トリガー	アラーム状態	アラーム状態時に通知を送信するため
SNSトピックの選択	既存のSNSトピックの選択
通知の送信先	自分宛のトピックを選択
名前	SnapshotsCreateFailed-monitor SnapshotsDeleteFailed-monitor	入力内容は任意
説明		入力は任意

以下のように二つのCloudWatch Alarmが作成出来ました。

確認してみると確かに監視できています。

これで完成です！
これでもし削除や作成の失敗があっても安心ですね。
ただ、実際にDLMが失敗したことを私は見たことがないですし、自分の手で失敗させるテストも実施できないのでこのアラームが問題なく作動するかの確認はできていません。
そちらはご了承ください。

おわりに

ここまで読んでいただきありがとうございました。
DLM失敗は大変低い可能性ではあると思いますが転ばぬ先の杖ですね。安全に越したことはないです。
間違いなどあればぜひご指摘ください。
この記事が誰かの助けとなれば幸いです。