はじめに
今回は「やってみた」の記事になります。Azureには様々なサービスがあり、数えきれない程の機能があります。私も本番ワークロードで沢山のAzureサービスを使っていますが、すべての機能を知っている訳でもなく、そのサービスを使い切れているとは到底言えません。毎月のアップデート情報のキャッチアップや実案件での調査の中で知り得た機能を使ってるのが実情です。その中で今月のアップデートを眺めていたら、本番ワークロードで使えそうな、ちょっと気になる機能が目につきましたので今回はその検証をしようと思います。
Application Insightsで外形監視
Application Insightsはログ調査でクエリ検索をよく使っていますが、その他の機能はあまり把握していませんでした。そんな中、７月のアップデートでApplication Insightsの標準テスト機能がGAしたという記事を見つけました。
内容を確認していくと、どうやらApplication Insightsには「可用性テスト」という機能があり、いわゆる外形監視してくれる機能のようです。これまで実案件でもFunctionsを使って外形監視の仕組みを作ったりしてきましたが、実はApplication Insightsで簡単に作れるのでは！？ということで詳細を確認したくなりました。
※すでにご利用の方からしたら「今更？」という話ですがご容赦ください。。
Application Insights 可用性テスト
Microsoftのドキュメントは下記になります。
可用性テストには以下の4種類があります。
- URL ping テスト
- 標準テスト（Standard test）
- 複数ステップWebテスト
- カスタムTrackAvailabilityテスト
1→4に上がるにつれて複雑なリクエストが作れるようですが、「3. 複数ステップWebテスト」はVisual Studio Enterpriseで作成する、「4. カスタムTrackAvailabilityテスト」は可用性テスト用のカスタムプログラムを作成する、というように難易度も上がってきますので今回は割愛させて頂きます。
URL ping テスト
こちら名前に"ping"とありますが、ICMPを打つことはありません。HTTPアクセスで対象システムの外形監視を行います。それでは早速作ってみます。（Application InsightsってAppService作る時に一緒に作るのが通常なので単体で作るのはちょっと新鮮です。）
①Application Insightsの管理ブレードの[可用性]に進みます。
②[+クラシックテストの追加]を選択します。
（クラシックテストって言うんですねw）
③テストの作成で項目を埋めていきます。
| 項目 | 設定内容 |
|---|---|
| SKU | "URL ping"と"複数ステップ"が選択できます |
| URL | テスト対象のURLを入力します。今回は静的WebAppでサンプルサイトを立ち上げました。パブリックアクセス しか対応していないようです。 |
| 従属要求の解析 | 対象URLに紐づくコンテンツのダウンロードも含めた時間でテストします |
| 再試行の有効 | テストが失敗した場合、20秒後に再テストしエラー試行が3回連続で失敗した場合にのみ報告されます |
| テストの頻度 | 提示実行の間隔 |
| テストの場所 | 最大16個のリージョンからURL pingを実行することができます |
| 成功の条件 | テストのタイムアウトや成功時のHTTPステータスコードを指定します |
④早速実行結果が返ってきます！
指定したリージョンからの疎通結果が表示されます。アクセス時間も表示してくれるのがいいですね。
下記は直近７日間平均の結果ですが、たまにテストが失敗していることがありました。
散布図を見てみると、ところどころ失敗していることがわかります。赤いバツマークのところです。
Application Insightsではこの一つ一つのトランザクションに対して「エンド ツー エンド トランザクションの詳細」という画面でアクセスの詳細、エラーの詳細を確認することができます。とてもわかりやすいですね。
標準テスト（Standard test）
「標準テスト」は、「URL ping テスト」より、リッチなリクエストを投げることができます。例えば、SSL証明書の有効性、プロアクティブな有効期間チェック、HTTP要求 (GET、HEAD、POST など)、カスタムヘッダー、HTTP要求に関連付けられたカスタムデータなどを含めることができます。作り方は、前章の②のところで［+標準テストの追加］を選択するだけです。
この後の設定は、「URL ping テスト」のUIと変わりません。ただ、標準テストの方が、できることが増えてますのでその分のパラメータ設定が可能になっています。アプリケーションによっては、複雑なリクエストを飛ばさないと受付できない(＝ヘルスチェックできない)ことが多々ありますので、標準テストの利用価値も高いと思います。
このあたりで細かい設定ができますね。なんだか日本語がおかしいのとフォーマットが崩れてるのはGAしたてだからでしょうが、そのうち直るでしょう。。
と言いつつ、フィードバックでさくっと指摘するとよろしいかと思います。
ちょっと脱線しますが、Auzreポータルの各サービスの画面には「フォードバック」のボタンがありますので、気軽に送信しちゃいましょう。
ちなみに英語表記にしたらキレイに収まってました。
可用性テストNGの結果をAzure Monitorに流して通知させる
可用性テストでNGが発生するということは、そのサービスが正しく使えない状態にあるため、いち早く気づき速やかな対応を行う必要があります。そのためにはNGになった時に通知する仕組みが必要です。可用性テストもAzure Monitor経由で通する仕組みを持っています。Application Insightsのメニューにある[ログの表示]に進みましょう。
LogAnalyticsみたいなログ検索画面が出てきますので、ここでエラーをひっかけるKQLを書きます。どうやら成功/失敗を示すのは"message"というカラムのようです。成功時は”Passed”、失敗時は失敗した理由が出力されています。なので、このカラムの値が”Passed”以外のログを抽出してみます。
超簡単に書くとこんな感じ
availabilityResults
| where message != "Passed"
エラーとなったリクエストが抽出されました。
ちなみに、エラーメッセージで今回見つけられたのは下記の5つです。１つ目はWebサイトを消してから出てるもので、それ以外は可用性テストでたまに失敗した時に出力されていたものです。ご参考まで。
- '404 - Not Found' does not match the expected status '200 - OK'.
- Web Test exceeded the configured timeout (00:00:30) and was aborted.
- This is usually a temporary error during hostname resolution and means that the local server did not receive a response from an authoritative server
- The remote name could not be resolved: 'icy-bush-00a592200.1.azurestaticapps.net'
- A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond [::ffff:20.99.163.40]:443
KQLが書けたら[+新しいアラート]に進みましょう。あとはAzure Monitorの設定になります。
具体的な設定方法については過去の投稿で紹介していますのでご参考ください。
可用性テストの気になったこと
可用性テストは機能的には十分使える機能と思います。その中でも調査の過程で気になったことを挙げます。
パブリックに公開されたサイトしかテストできない
やはり内部システムにも使いたくなりますね。ただ、これについては対処法（Application Insightsのサービスタグを穴あけ）もあるようですので今後の検証課題としたいと思います。
通知のリアルタイム性
これはAzure Mnonitorの話になりますが、検知から通知まで数分の間が空きます。それでも十分という気もしますが、ミッションクリティカルなコアシステムの監視となると少々苦しいかなと思います。
その他可用性テストに関する公式なトラブルシュートサイトもありますので参考にしてみてください。
おわりに
今回な長々と書いてしまいましたが、Application Insightsの可用性テストは結構使えるぞ！という話でした。エンタープライズでも十分に使えると思いますので、今後実案件の中でも可用性テストの適用を考えてきたいと思います。
それではまた次回！