サーバーの異常をメールで知らせる仕組みを作る

手順に迷ったときや、用語の意味を確かめたいときに開きましょう。

※ リンク切れの場合は、ページタイトルで検索してください。

EC2 の状態は CloudWatch にメトリクスとして集まります。そこにアラームを仕掛け、条件を満たすと SNS トピックへ通知し、トピックから自分のメールへ届きます。

以下の要件を満たし、通知メールが実際に届くことを確認してください。

「監視対象を用意 → 通知先（SNS）を用意 → アラームでつなぐ → 実際に発報させて確認」の順に進みます。まず一度メールを受け取ってから、現実的な設定に整えるのがコツです。

1. リージョンを合わせ、監視対象の EC2 を 1 台起動する

   リージョンが東京であることを確認し、EC2 を 1 台起動します（Amazon Linux 2023・無料利用枠タイプ）。CPU 使用率を見張る対象にするだけなので、ユーザーデータや特別な設定は不要です。

   メトリクスは自動で集まる

   EC2 の CPU 使用率などの基本的なメトリクスは、何もしなくても CloudWatch に集まります（標準では 5 分間隔）。起動直後はまだデータが少ないので、数分待つとグラフに現れます。

2. SNS トピックを作り、自分のメールを登録する

   検索バーから SNS コンソールを開き、「トピックの作成」でタイプ「スタンダード」のトピックを作ります（名前は alarm-topic など）。続けて、そのトピックに「サブスクリプションの作成」で、プロトコル「Eメール」・エンドポイントに自分のメールアドレスを登録します。

   届いた確認メールを必ず Confirm

   登録すると、AWS から確認メールが届きます。その中の「Confirm subscription」リンクをクリックして、はじめて通知を受け取れる状態になります。これを忘れると、アラームが鳴ってもメールは届きません。

3. CloudWatch アラームを作り、対象メトリクスを選ぶ

   CloudWatch コンソールの「すべてのアラーム」→「アラームの作成」を開き、「メトリクスの選択」から EC2 →「インスタンス別メトリクス」→ 対象インスタンスの CPUUtilization を選びます。

   何を見張るかを決める

   メトリクスは「どのリソースの・どの指標を見るか」の指定です。今回は「このインスタンスの CPU 使用率」を選びました。1 つのアラームは 1 つのメトリクスを見張ります。

4. まずは「必ず発報する」しきい値で、通知を確認する

   条件の設定で、今の状態でも必ず条件を満たすしきい値を一時的に指定します（例：「CPUUtilization が 0 以上」のように、現在値が確実に超える向き）。通知アクションに、手順 2 のSNS トピックを指定してアラームを作成します。しばらくすると状態が「アラーム」になり、通知メールが届きます。

   なぜ最初に必ず鳴らすの？

   本来の「CPU が高くなったら」という条件は、わざと負荷をかけないと発報しません。学習では、まず通知の経路が正しくつながっているかを確かめるのが先決です。確実に鳴る条件で一度メールを受け取り、仕組み全体が動くことを確認します。

5. 状態の移り変わりを観察する

   アラームの画面で、状態が データ不足 → OK や アラーム と移り変わる様子と、履歴を確認します。状態が「アラーム」に変わったタイミングで通知が送られていることを、メールの受信時刻と照らし合わせてみましょう。

6. 現実的なしきい値に整える

   仕組みが確認できたら、アラームを編集して、実運用を想定した条件に直します（例：「CPU 使用率が 70% 以上の状態が 5 分続いたら」）。これで、ふだんは静かにしていて、本当に高負荷になったときだけ知らせてくれるアラームになります。

   しきい値と期間はセットで考える

   「いくつを超えたら（しきい値）」だけでなく、「どのくらいの時間続いたら（評価期間）」も大切です。一瞬の上昇で毎回鳴ると、通知が多すぎて逆に見なくなります。少し続いたら鳴る、くらいが扱いやすいバランスです。

初学者がよく引っかかる箇所を先回りでまとめました。答えそのものは載せていませんが、「どこを見直せばよいか」の手がかりとして使ってください。

要件の再確認ではなく、画面のどこを見れば達成を確認できるかをまとめました。CloudWatch・SNS コンソールとメールを確認しながら、次を順に確かめましょう。

• SNS のサブスクリプションの状態が 「確認済み（Confirmed）」になっている。
• CloudWatch アラームが、対象インスタンスの CPUUtilization を見張っている。
• アラームの通知アクションに、作成した SNS トピックが指定されている。
• アラームが「アラーム」状態に変わったとき、通知メールが届いた（受信を確認できた）。
• 最終的に、しきい値が現実的な条件（例：CPU 使用率が一定以上の状態が続いたら）に整えられている。

手を動かすことに加えて、次の問いに自分の言葉で答えられるようにしておくと、理解がより深まります。

1. アラームのしきい値や評価期間を、低く・短くしすぎると何が起きるでしょうか。逆に高く・長くしすぎるとどうでしょうか。ちょうどよい設定とは、どんな考え方で決めればよいでしょうか。
   ヒント

   低く・短くすると、些細な変動で何度も鳴り、通知が多すぎて見なくなります（オオカミ少年のように）。高く・長くすると、本当の異常を見逃しかねません。「鳴りすぎず、見逃さず」のバランスをどう取るか、という観点で考えてみましょう。
2. 通知を、アラームから直接メールに送らず、SNS トピックを間にはさみました。この「ひと手間」は、あとからどんな場面で役に立つでしょうか。
   ヒント

   トピックには、メールの宛先を複数足したり、メール以外の届け先（他のサービスなど）をつないだりできます。「知らせる側（アラーム）」を変えずに「届け先」だけ増やせる、という分離の利点から考えてみましょう。
3. アラームには「データ不足」という状態がありました。監視の観点では、これを「正常」と同じに扱ってよいでしょうか。データが来ないこと自体が問題のサインである場合を考えてみましょう。
   ヒント

   データが来ない原因が「単に起動直後」なら問題ありませんが、「サーバーが落ちて値を送れない」なら見逃せません。データ不足を OK とみなすか、警告とみなすかは選べます。「沈黙＝正常」とは限らない、という視点で考えてみましょう。

学習で作ったものを片づけます。アラームや SNS は少額または無料枠の範囲が多いですが、EC2 は起動中ずっと課金されるため、忘れず終了しましょう。

1. CloudWatch アラームを削除する：「すべてのアラーム」で作成したアラームを選んで削除します。
2. SNS のサブスクリプションとトピックを削除する：サブスクリプション（メール登録）を削除し、続けてトピックを削除します。
3. EC2 インスタンスを終了する：「インスタンス」で monitor-target を選び、「インスタンスを終了（Terminate）」します。