【Azure Monitor】アラートから Logic Apps をトリガーしアラート種別に応じて処理を分岐する【前編】

Azure Monitor アラートから Logic Apps をトリガーし、アラート種別に応じて Logic Apps のワークフローをカスタマイズする方法をまとめました。

本記事では前編として、 Azure Monitor のアラートから Logic Apps をトリガーしてアクションをカスタマイズするために必須の知識である「共通アラートスキーマ」について記載します。

Azure Monitor アラートの基本知識
アラートから Logic Apps のワークフローをトリガーする
共通アラートスキーマとは
共通アラートスキーマの構造
おわりに

Azure Monitor アラートの基本知識

Azure Monitor *1 を使用すると、Azure リソース等のパフォーマンス、正常性、アクティビティなどを監視することができます。また、アラートルールを設定することで、条件に応じてアラートを発報することも可能です。

Azure Monitor でアラートが発報された際にトリガーするアクションは、アクショングループ *2 を使用して定義することができます。トリガーできるアクションには Logic Apps *3 のワークフローも含まれています。Logic Apps のワークフローをトリガーすることで、アラート通知のカスタマイズや、他の監視サービスへのアラートの連携などが実現できます。

アラートから Logic Apps のワークフローをトリガーする

共通アラートスキーマについて記載する前に、事前知識として Azure Monitor アラートから Logic Apps のワークフローをトリガーする手順を記載します。詳細な手順は下記のドキュメントをご覧ください。

learn.microsoft.com

なお、本記事では Logic Apps の［消費］プランを使用した手順を記載しています。

Logic Apps を作成します
Logic Apps デザイナーからトリガーとして［HTTP 要求の受信時］を選択します
［要求本文の JSON スキーマ］にアラートペイロードのスキーマを入力します
（スキーマについては後述します）
後続のステップに任意のアクションを追加します。
Azure Monitor のアクショングループを作成します
［アクション］タブの［アクションタイプ］には［ロジックアプリ］を選択します。
アラートルールを作成します
［アクション］タブでは、手順5 で作成したアクショングループを選択します。

以上で、アラートが発報時に Logic Apps がトリガーされるようになります。

共通アラートスキーマとは

共通アラートスキーマとは、Azure Monitor アラートのペイロードの JSON スキーマを標準化したものです。詳細は下記のドキュメントをご覧ください。

learn.microsoft.com

過去にはアクティビティログ、メトリック、ログのアラートごとに異なるスキーマが使用されていたようです。

アラートから Logic Apps をトリガーすることを考える場合、アラート種別ごとにペイロードのスキーマが異なると、不都合が起こり得ます。

前章「アラートから Logic Apps のワークフローをトリガーする」の手順 3 に記載した通り、［HTTP 要求の受信時］>［要求本文の JSON スキーマ］にアラートペイロードのスキーマを入力することで、後続のステップでペイロードに含まれるデータを使用することができます。

言い換えると、アラートペイロードのスキーマに含まれるデータのうち、［要求本文の JSON スキーマ］に含まれないものはワークフローに取り込むことができません。

したがって、アラート種別ごとにペイロードのスキーマが異なる場合、アラート種別ごとにトリガーを用意する必要があり、つまりはアラート種別ごとにワークフローを用意しなければならなくなります。

この不都合を解決するために、共通アラートスキーマが役立ちます。

アラートペイロードに共通アラートスキーマを使用することで、アラート種別が異なる場合も同じワークフローをトリガーしてペイロードに含まれるデータを取り込むことが可能になります。

共通アラートスキーマを使用するには、アクショングループ作成時の設定が必要です。［アクション］タブで［アクションタイプ］を選択する際に、［共通アラートスキーマを有効にします。］に［はい］を選択します。

共通アラートスキーマの構造

共通アラートスキーマには以下3つのフィールドがあります。*4

essentials
- 共通アラートスキーマの "共通な" 部分です。
- アラートID、アラートルール名、発報日時、重大度、アラート種別（監視サービスやシグナルタイプ）、影響を受けるリソースなどが含まれます。
alertContext
- 共通アラートスキーマの "共通ではない" 部分です。
- アラートルールに関連するデータが含まれており、アラート種別によって含まれるフィールドが異なります。
  - 例えば、メトリックアラートの alertContext には、メトリック名、閾値、発報の条件などが含まれています。
- こちら *5 のドキュメントに記載されているサンプルから、各監視サービスごとに含まれるフィールドを確認できます。
customProperties
- 任意の情報を含めることができる部分です。

前章では、共通アラートスキーマを使用したアラートペイロードから Logic Apps をトリガーすることで、複数のアラート種別に対してもペイロードに含まれるデータを後続のステップで使用できると説明しました。

確かに、 essentials フィールドはアラート種別が違っても共通のため、1つのトリガーに1つの JSON スキーマを定義するだけでデータを取り込むことができます。

しかし、alertContext フィールドはアラート種別により異なるため、データを取り込むためには工夫が必要になります。選択肢としては以下のようなものがあります。

アラート種別ごとにワークフローを用意する
- 手数は増えますが、複数のワークフローを用意し、各ワークフローのトリガーにアラート種別ごとの JSON スキーマを定義します。
すべてのアラート種別の alertContext に含まれるフィールドを1つのトリガーの JSON スキーマに含める
- トリガーの JSON スキーマに含めるフィールドは、実際のアラートペイロードのフィールドより多くなっても問題ありません。そのため、想定されるすべてのアラート種別の alertContext フィールドをトリガーの JSON スキーマに含めてしまえば、すべてのデータを取り込むことが可能です。
- ただし、トリガーの JSON スキーマを作り込む必要があり、やや手数が増えます。
essentials フィールドに含まれるデータを基に、後続のステップで alertContext フィールドに含まれるデータを取得する
- この方法が実現できれば、ワークフローが1つで済み、修正の負担も軽くなるため、最も合理的です（後編でこちらの方法を紹介します）。