この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
いわさです。
Azure Application Insightsでは可用性機能を使って、Webアプリケーションの死活監視を行うことが出来ます。
この機能では、シンプルな監視からカスタマイズしたものまで、いくつか設定があるので確認してみました。
大きく、Classc / Standard / Custom に分類が出来るので、このブログではその3つを対象としています。
なお、検証にあたって事前にApp ServiceでパブリックなWebアプリケーションをデプロイしておき、Application Insightsリソースをひとつ作成してあります。
Classic
まずはClassicです。
公式ドキュメントではURL pingテストと記述されています。
シンプルに指定したURLに対してGETリクエストを送信し、死活状態の監視を行うことが出来ます。
Application Insightsの可用性メニューから、Add Classic testでテストを新規作成することが出来ます。
ここでは、テスト対象のURLやオプションを指定します。
Application Insightsは各種Azureリソースから自動で有効化するケースが多く、何かのリソースに加えて利用するイメージがあるかもしれませんが、Application Insightsは単体でリソースとして動作します。
なので、Azure Application Insightから別のクラウドサービスでホスティングされているWebサービスを監視することも可能です。
ここではパブリックなURLを指定します。
Azureのプライベートネットワークリソースに対して死活監視を行う方法も存在しますがこの記事では取り上げません。別で検証出来ればと思います。
いくつかオプションを見てみましょう。
「従属要求の解析」は、URLで指定したWebページのステータスを確認するだけでなく、そのページの一部である画像やスクリプトなどのリソースに対するリクエスト結果についても監視対象と出来るオプションです。
「再試行」は、テストが失敗してもすぐに結果として失敗にはならずに20秒間隔でリトライを行える機能です。3回連続で失敗すると結果として失敗として扱われます。
「テストの頻度」はそのままですが、最短で5分からとなっています。選択肢としては5分、10分、15分があります。
「テストの場所」で複数の場所を設定すると、各地域のサーバーからリクエストが送信される形となります。このオプションによって、地域に依存した問題を補足することが出来ます。
レスポンスの検証についても少しオプションがあり、タイムアウト時間や許容するステータスコード、特定コンテンツが含まれていること、などを指定することが出来ます。
なお、オプションにひとつにSKUという項目がありますが、URL pingか複数ステップかを選択することが出来ます。
複数ステップテストは、Visual StudioのWebテストファイルを使ったインテグレーションテストを可用性確認に使うことが出来るようです。
こちらは現在は推奨されておらず、互換性のために残されているようです。
本記事では扱いませんが、利用されたい場合は以下をご参照ください。
Standard
次はStandard testです。
こちらは現在パブリックプレビューとなっています。
Classicと概ね同じなのですが、追加のオプションがいくつかあります。
こちらもApplication Insightsの可用性メニューからすぐに作成することが出来ます。
主に以下2つが追加されている点です。
まず、ターゲットURLに対するSSL証明書の有効性を確認できるようになっています。
また、証明書の有効期間についての検証を行うことも出来ます。
また、Classicでは単純なGETリクエストでの検証でしたが、StandardではGET以外のメソッドを指定することが出来、カスタムヘッダーを指定することも出来ます。
さらにレスポンスに対する検証も、柔軟性が高くなっています。
Cusotom
最後に、カスタムです。
こちらは先程の2つと少しことなり、可用性メニューから作成は行いません。
カスタムコードなどから、Application Insightsに対してアプリケーションの可用性に関する情報を送信することで、Application Insightsで可用性情報として取り扱うことが出来ます。
以下のURLではAzure Functionsでタイマートリガーを使って定期的にHTTPリクエストを送信し、確認結果をMicrosoft.ApplicationInsights.TelemetryClient.TrackAvailability()を使って送信しています。
実装については上記を参照頂ければそのままベースの実装が出来ます。
Azure Functionsの場合は関数アプリ作成時の監視タブでApplication Insightsを関連付けすることでコード内から情報を参照することが出来ます。
他の可用性テストと混ざっていますが、hoge-test-3がカスタムで作成したものです。
送信するAvailabilityTelemetryのRunLocationに従って地域が設定されています。（サンプルコードでは関数アプリの実行リージョン）
停止してみる
これら3つのテストを設定した状態でWebアプリを停止してみました。
失敗が検出出来ていますね。期待どおり死活監視がされています。
なお、当然ながら検出に対してアラートアクションを設定することも出来ます。
設定方法の詳細は以下をご確認ください。
さいごに
一般的なシナリオであればカスタムコードの準備なしでポチポチだけで死活監視が導入・設定出来るのがまず良いですね。
依存リソースの検証や再試行、複数ロケーションからのリクエスト機能などオプションもいくつかありますし、パブリックなWebサイトを死活監視するのであればClassic Testでも十分な機能を備えている感じがします。
特に、従属要求の解析機能などは、単純にWebページのHTTPステータスの監視だけでなく、特定リソースのダウンロードに失敗している場合など、目視で気づきにくい点にも気付けるのでとても良いと思いました。
ただ、StandardのSSL証明書の有効性確認はかなり良いなと思ったのでClassicだとこれが使えない点はちょっと悩ましいですね。
サイトは生きていたが証明書が切れていた、あるいは期限切れの直前に気づいてしまい手配が間に合わなかった、なんてことを回避できそうです。
ClassicとStandardで対応できないシナリオの場合でもカスタムコードで対応出来ますし、SDKとApplication Insightsへの接続文字列で送信さえ出来ればオンプレミスでも別のクラウドサービスでも、どこにでも適用できそうなので汎用性も高いと思いました。
2
