はじめに
AWSでエラー検知をしてメールを飛ばすという仕組みを作るのは簡単ですが、最低限の設定だけでメールを送ると、なかなか解読が難しい文字列が送られてきます。
現場でも使う仕組みだったので、少しでも読みやすくする方法を調べてみました。
以下の2つの記事が大変参考になりました。
CloudWatch アラームの通知メールを少しでも読みやすくしたい
EventBridgeの入力トランスフォーマーでSNSのメール通知内容を整形してみた
エラー通知メール（通常のすがた）を確認
構成
今回は「testAPI」という名前のAPIを作成して、APIでエラーが発生した場合、メールで通知するようにします。
構成図は以下のとおりです。
ざっくりと説明すると、CloudWatchで監視を行い、CloudWatchがエラーを検知したらSNSでメールを送るという流れです。
testAPIを作成したという前提で、SNSトピックの作成とCloudWatch Alarmの設定を説明します。
SNSトピックの作成
トピックで、タイプを「スタンダード」、名前はAPI名と何を通知するかわかるように設定します。
サブスクリプションで、プロトコルを「Eメール」、エンドポイントを自分のメールアドレスに設定します。
これだけだとサブスクリプションが保留中になっています。
登録したメールアドレスに認証メールが届いているので、「Confirm subscription」を押すと、以下の画面が出てきてSNSトピックの設定は完了です。
CloudWatch Alarmの設定
メトリクスはtestAPIの「4XXError」を選択します。ここは実際に監視したい項目を選んでください。（「4XXError」の選出理由はエラーが出しやすいというだけなので…）
統計「合計」、期間「5分」にします。
条件は以下の画像のとおり、しきい値の種類「静的」、4XXErrorが次の時…「以上」、…よりも「1」で設定します。
これで「5分間で、4XXErrorが1回以上発生したとき」アラーム状態になります。
アクションの設定で、アラーム状態トリガーを「アラーム状態」、次のSNSトピックに通知を送信を「既存のトピックを選択」、通知の送信先を先ほど作ったSNSトピック名にします。
アラーム名を設定します。
エラー通知メールを確認
適当にエラーを発生させて（APIの4XXエラーは存在しないパスにアクセスすれば出ます）、エラー通知メールを待ちます。
来ました。
・・・・・・？？？？
これはあくまで一部の抜粋で、本文はこの2倍くらい文字がずら～～～～と並んでいます。
AWSを全く知らない人に見せたら「迷惑メール？」と言われました。たしかに、寝起きの頭だと迷惑メールとして処分してしまうかもしれません。私はまだまだひよこなので、しっかり目覚めていてエラー通知メールと認識できても、解読が大変です。
そこで、SNSから発行されるメールの加工方法がないか調べてみました。
エラー通知メールを読みやすくする
構成
先ほどから構成を少し変えます。EventBridgeというサービスを新たに追加します。
流れをざっくりと説明すると、CloudWatchで監視を行い、CloudWatchがエラーを検知したらEventBridgeにイベントソースを送り、EventBridgeはイベントソースをもとにメッセージを加工して、SNSでメールを送るという流れです。
エラー検知するAPIや、CloudWatch Alarm、SNSトピックは基本的にそのまま使いますが、CloudWatch AlarmとSNSトピックについては少し設定の変更をします。
CloudWatch Alarmの設定変更
先ほどは、CloudWatch Alarmがアラーム状態になったら(＝エラーを検知したら)、SNSトピックに通知を行うという設定にしていました。
しかし、今回はCloudWatch Alarmがアラーム状態になったら、EventBridgeにイベントソースを送るという構成にします。そのため、CloudWatch Alarmのアクションの設定から通知を削除します。
SNSトピックの設定変更
実は通知メールの件名は、SNSトピックの表示名と同じです。
SNSトピックの表示名は任意の項目ですが、画像のように入力して、よりエラーが来たことをわかりやすくしました。
CloudWatch AlarmとSNSトピックについて、設定変更が終わったので、新しく使うEventBridgeの設定を行っていきます！
EventBridgeの設定
ルールの詳細を定義で、名前をわかりやすいものに(画像ではCloudWatchアラームと同じ名前にしています)、イベントを「default」に、ルールタイプを「イベントパターンを持つルール」にします。
イベントパターンを構築で、イベントソースを「AWSイベントまたはEventBridgeパートナーイベント」を選択します。
さらに、イベントパターンで、イベントソースを「AWSのサービス」、AWSのサービスを「CloudWatch」、イベントタイプを「CloudWatch Alarm State Change」にします。イベントパターンは画像の通りにJSONコードを入力します。
ターゲットを選択で、ターゲットタイプを「AWSのサービス」、ターゲットを選択を「SNSトピック」、トピックを先ほど作ったトピックにします。
ターゲットを選択の追加設定をクリックします。
ターゲット入力を設定から、「入力トランスフォーマー」を選択して、「入力トランスフォーマーを設定」を選択します。
入力トランスフォーマーを設定します。
サンプルイベントを選択し、EventBridgeに渡されるイベントソースを確認して、
入力パスで、サンプルイベントから必要な項目を抽出して変数に代入して、
入力テンプレートで、入力パスで定義した変数を使いながらSNSトピックに渡すメッセージを作っていくという流れです。
イベントソースは使わずに、入力テンプレートに必要なメッセージを入力するというような使い方も可能です！ ただし、改行を含む入力テンプレートは各行をダブルクォーテーションで囲むのが必須のようです。（公式ドキュメント）
エラー通知メール（加工後のすがた）
だいぶ何言ってるかわかるようになったのではないでしょうか！
入力テンプレートは記号等を含めて自由に記載できたので、メール受信者の事情（AWSの習熟度や、さっと読みたい/じっくり詳しくエラーの原因を把握したいといったニーズ）に合わせて内容を変えていけるのが良いですね。
感想
AWSは基本英語のサービスだと理解はしていますが、やっぱり日本語の方がうれしい。
今回Eventbridgeを触ってみて、AWSサービスを呼び出すときはJSON形式でイベントソースを渡していることを改めて認識できました（そういえば、API GatewayからLambda関数を起動するときにJSON形式でイベントを渡していたなぁと思い出したり）。このあたりの理解をもっと深めたら、サービスどうしを組み合わせていろんなことができて楽しそうです。