Zenn
🍇

Azure Application InsightsでREST APIの外形監視を行う

2023/09/18に公開
Azure
監視
REST API
運用
monitoring
tech

外形監視とは

アプリケーションやサービスの可用性やパフォーマンスを監視するために、
対象のサービス（ここではREST API)が正常に動作しているかどうかを外部から実際にユーザーとして叩いて確認を行う監視方法です。

REST APIを定期的に実行して、実行に失敗したら（or 失敗が続いたら）アラートを上げる、といった感じです。SaaSサービスとしてはRanscopeなどが有名かもしれません。

AzureにおいてもApplication Insightsの可用性テスト機能を用いてAPIの外形監視を行うことができます。

シナリオ1: シンプルなテスト

前提

今回は以下のような内容でテストを実施すると仮定します。

  • 監視対象のAPI URL: yourapi.azurewebsites.net
  • 監視したいAPI: GET /students
  • 上記を1分に1回監視し、200であれば成功、それ以外であれば失敗と見なす
  • 失敗した場合にはメール、SMSなどで通知を行う

というテストを作成します。

手順

準備はCLIで行っていきますがポータルで実施しても構いません。

ログイン

CLIでAzureにログインします。CloudShellで実行している場合にはこの手順は不要です。

az login

リソースグループの作成

az group create --name <ResourceGroupName> --location <Location>

例えば

az group create --name rg-rest-api-lecture --location japaneast

などで作成します。

既にリソースグループがある場合には不要です。

以下にリソースグループ名を再利用できるように変数宣言しておきます。

RESOURCE_GROUP=<ResourceGroupName>

Application Insightsリソースの作成

Application Insights

APP_INSIGHTS_NAME=my-app-insights

az monitor app-insights component create --app $APP_INSIGHTS_NAME --location japaneast  --resource-group $RESOURCE_GROUP --kind web --application-type web --retention-time 30
  • kind: 監視対象をweb, otherから選択。
  • application-type: 監視対象に合わせてUIをカスタマイズ。web, ios, other, store, java, phoneなどから選択
  • retention-time: ログのリテンション期間（LogAnalyticsにログ連携している場合は無効）

作成完了後、IDを変数に取得しておく。

APP_INSIGHTS_ID=$(az monitor app-insights component show --app $APP_INSIHGHTS_NAME --resource-group $RESOURCE_GROUP --query 'id' -o tsv)

上手く取得できると以下のようなIDが変数に取得できます。

echo $APP_INSIGHTS_ID
/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-rest-api-lecture/providers/microsoft.insights/components/my-app-insights

テストの作成

(CLIで作成するつもりでしたが、tags=hidden-linkの指定方法が公式ドキュメントに記載されていないためGUIで作成します。判明次第追記します)

Application Insightsの「可用性テスト」＞「標準テストの追加」を押下します。

  • URL: APIのリクエスト先URLを入力します
  • 従属要求の解析: 対象がWebページの場合、画像やテキストなどを続けて取得します。（API試験の場合は不要なはずです）
  • テストの頻度: リクエストを試行する間隔を指定
  • テストの場所: リクエストを送信する拠点を複数選択します
    （これにより、テスト対象のすべての地域で一定時間内にレスポンスが得られていることを監視できます）
  • Standard test info: HTTPメソッド、ヘッダなどを指定します
  • 成功の条件: 成功と見なすためのステータスコード、時間、コンテンツ要素などを指定します。

入力の上「作成」を押下します。成功すると以下のようにテストが追加されます

アラートの設定

作成したテストのケバブメニューから「規則（アラート）ページを開く」を選択します。

作成したWebTestに対応するアラートルールが作成されています。ルールを選択します。

この時点ではアラートを行うルールは定められていますが、具体的にアラートとして何を行うのかは定められていません。ここから、このアラートルールにアクションを追加していきます。

編集を選択。

「アクション グループの管理」 ＞ 「アクショングループの作成」を押します。

アクションの名前を決めます。

通知タブでは通知方法を設定します。電話、メール、SMSなどを指定できます。

アクションタブではAzure FunctionsやWebhookの起動などを指定し通知以外に行うアクション（例えばサーバを再起動するなど）を既定できます。

「確認と作成」 > 「作成」を押します。
アクショングループの作成完了後、作成したアクショングループをアラートルールに設定します。

これで通知が行われるようになるはずです。

より発展的なテストの課題

  • 「まず認証を行ってから、Tokenを付けてリクエストする」「リストAPIを叩いてから取れた結果要素に対して詳細取得を行う」など複数段階のAPIテストを行いたいケースでは ]Multi Step web test](https://learn.microsoft.com/ja-jp/previous-versions/azure/azure-monitor/app/availability-multistep) を用いることができました。

  • しかし2023/10現在、Multi Step web testは非推奨となっています。代替手段としては TrackAvailability() を用いて試験することが推奨されていますが、この方法ではテストを実行するサーバ（なり関数なり）を自前で建てる必要があります。

Discussion