こんにちは！横断BizOps本部AIOps部のこたろうです！今回は、Azure Logic Appsの活用例としてAzure Monitorアラートを起点にSlack通知する方法について紹介したいと思います！
Azure Logic Appsとは？
Azure Logic Apps（以下、Logic Apps）は、ノーコード／ローコードでワークフローを組み立て、Azureの各種リソースや外部サービス（Slack、Salesforceなど）と連携して処理を自動化できるサービスです。
数百のコネクタが用意されており、これらをパズルのように組み合わせるだけで業務フローを自動化できます。また、ワークフローはGUI上で管理できるため、Gitを前提としたコード管理を必須とせず運用できます。そのため、ケースによってはエンジニアでない方でも作成・運用できます。
今回は、このLogic Appsの柔軟性を活かした、運用の監視と柔軟なSlack通知の事例をご紹介します。一部、実運用とは異なるサンプルのコード／結果に差し替えています。
活用例：Azure Monitorアラートを起点にログを分析しSlack通知
通常、Monitorのアラートはメールや通知を飛ばすことができます。さらにLogic Appsをハブにすることで、アラート検知時の情報を、用途に合わせてカスタマイズしてSlack通知するといった柔軟な運用が可能になります。
全体のワークフロー
- HTTPトリガー : Monitorのアラートからリクエストを受信
- KQL（Kusto Query Language）によるログ取得 : Application Insightsへ詳細ログを問い合わせ
- アクション : ログ結果を整形しSlack通知
各コネクタを詳細に解説するのは割愛しますが、このように組み合わせることで目的のワークフローを作成できます。
ワークフローの全体図
HTTPトリガー: Monitorのアラートからリクエストを受信
Azure Monitorアラート側の設定
Monitorのアラートでエラーが起きた際にLogic Appsがトリガーされるようにルールを設定します。このようにMonitor側のクエリで特定項目を指定して（ここでは success==false など）、条件に一致した場合だけトリガーされるようにします。Logic Apps側では以下のようにHTTPトリガーとBodyを受け付けることができます。
リクエストを受け取る
KQLによるログ取得 : Application Insightsへ詳細ログを問い合わせ
KQLを指定・実行する
Logic Appsでは、KQLの指定と実行により柔軟にエラーの詳細や条件の指定を実施できます。これにより、Monitorのアラートを起点に、Logic Appsで詳細な分析や通知内容のカスタマイズを実施できます。
アクション: ログ結果を整形しSlack通知
KQLの実行結果は、変数にまとめて整理できます。
結果を変数に保存する
ここでは複数のエラーを一度に通知できるよう、KQLの実行結果をループで取得し、その内容を変数へ集約しています。
Slack通知先やBodyの指定
そしてその変数と必要なテキストをBodyにまとめることで、その内容をSlack通知できます。
実際にSlackで確認できる通知内容（添付しているメッセージ、タイムスタンプ、IDは全て実運用されていないサンプルの値です）
ワークフローのテストや運用
対象ワークフローのホーム画面
作成中にテストをしたい場合は、左上の Run や指定のPayload付きで実行できる Run with payload を利用できます。そしてワークフローの概要画面では実行した結果とその成功／失敗も合わせて確認できます。
失敗した場合、対象のレコードにアクセスすると、どのコネクタでどんなエラーが出ているか確認できます。
失敗しているコネクタとエラー
Logic Appsを選ぶメリット
1. ワークフロー作成が容易で運用コストが低い
- KQLとその結果に応じた条件分岐、通知メッセージ設定などをGUI上のワークフローとして組み立てられます
- ワークフローが可視化されているため、「何が起きているか」を把握しやすく、通知先や条件の追加も数クリックで対応できます
- 概要画面で実行の成功／失敗を確認でき、運用しながら改善しやすい点も利点です
2. 異なるサービス間の連携が容易
- Application Insightsのログ取得からSlack通知まで、コネクタ設定中心で連携を組めます
- 本来なら認証処理やAPI実装が必要な処理も、実装負荷を抑えて実現できます
Logic Appsの利用における制限
Logic Appsは便利な一方で万能ではありません。採用前に、次の点を把握しておくと安心です。
1. ワークフローが複雑になると可読性・保守性が下がる
- GUIで全体像は把握できる一方で、条件分岐やループが増えるほど追いかけにくくなります
- ドメインロジックや例外処理が厚くなるほど、GUI上での実装・変更が重くなり、コードで実装した方が保守しやすいケースが増えます
- 対策としては、Scope（スコープ）で処理をまとまりにする、命名規則を統一する、Logic Appsに寄せる範囲とコードで持つ範囲を切り分けるなどが有効です
2. Git中心のバージョン管理やレビューと相性が良くない
- ワークフロー定義はJSONとしてエクスポートできますが、日々の変更はポータル上での編集が中心になりやすく、PRベースのレビュー体験を作りにくいです
- 運用ルールを決める、長期運用を見据えて一部をコードベースに寄せるなど、体制に合わせた運用設計が必要になります
まとめ
Logic Appsは、単なる連携ツールに留まらず、運用のあり方を自分たちの使いやすい形にカスタマイズできる非常に強力なサービスです。
「標準機能ではあと一歩足りない」と感じたとき、Logic Appsを利用するだけで、その課題は一気に解消されるかもしれません。ぜひ、自分たちのワークフローに合わせた自動化に挑戦してみてください。
