この記事は更新から24ヶ月以上経過しているため、最新の情報を別途確認することを推奨いたします。

はじめに

Azureにおけるネットワークの接続状態やパフォーマンスを監視できるNetwork Performance Monitor (NPM) ソリューションというものがあります。
このソリューションはクラウドやオンプレミスの拠点、またOffice365と言ったあらゆるノードとの接続に対して「パフォーマンス」、「サービスエンドポイント」、「ExpressRouteにおける接続」の観点で監視することが可能です。
この記事ではプレビューの機能も含めてこのソリューションを用いて構築した監視システムの簡易構築手順、また、その監視システム評価をしていきたいと思います。

 

構成

今回は以下図のような構成において、下記3点に対する監視を行うシステムを構築します。
・監視サーバ自身の監視
・パブリック領域のWebサーバの監視
・プライベート領域の社内汎用サーバの監視
※ここでのパブリック/プライベートの違いは、インターネットから直接接続できるか否かで分けています。

 

構築手順

本記事ではシステム評価をメインとするため手順については簡易なものとしています。詳細な手順は公式手順（※1）や、Web上のAzureエンジニア様達の技術ブログをご参照ください。

OMSワークスペース・監視サーバ構築

(1)まずはMarketplaceからネットワークパフォーマンスモニターのワークスペースを作成します。
※2018年3月現在、NPM機能の対応リージョンは西ヨーロッパ、米国中西部、米国東部、東南アジア、オーストラリア南東部のみです。東日本リージョンを指定するとNPMが利用できませんのでご注意ください。

(2)監視サーバとする、構築した仮想マシンにMicrosoft Monitoring Agentをインストールします。
ワークスペースID、主キーが必要となります。この値はワークスペースにアクセスし、[構成]→[セットアップ]から確認可能です。

(3)OMSワークスペースと監視サーバの通信を許可します。
OMSワークスペースと監視サーバの通信は8084ポートで行われるため、基本的にはOSのファイアウォール、監視サーバのNICもしくはサブネットに紐づいているNSGで8084ポートの通信を許可するよう設定しましょう。

(4)監視サーバと通信が取れるとOMSワークスペースの[概要]に監視サーバが表示されます。

Webサーバ、社内汎用サーバの監視設定

(5)[構成]→[サービスエンドポイントモニター]→[テストの追加]をクリックし、各サーバに応じて以下赤枠のように設定します。

a.Webサーバの場合
なお、ターゲットのIPをプライベートIPで指定しているため、通信はAzureネットワーク内で完結していますが、グローバルIPを割り当てることでインターネットを経由した通信での監視も可能です。

b.社内汎用サーバの場合
基本的にはaと変わりありませんが、Webサーバでない場合HTTP/HTTPSのテストができないため、ここではICMPでのテストとします。

(6)[＋エージェントの]をクリックし、テスト通信を行うAgentをインストールした仮想マシンを選択し[追加]をクリックします。

(7)エージェントが選択されていることを確認し、以下赤枠のように設定し、[保存]をクリックします。
※赤枠部分の設定は仮の値で、実際のアラート条件は後ほど設定します。

(8)作成後、再度テストをクリックするとアラートの作成リンクが表示されているため、クリックします。

(9)アラートメールの受信先を入力し、[アラートの作成]をクリックします。

(10)作成後表示される[アラートの管理]をクリックします。

(11)アラート管理画面に遷移します。編集マークをクリックします。

(12)アラートルールを設定し、[保存]をクリックします。
ポイントとなる点を以下記載します。

・検索クエリ
アラートの判定を行う対象ログ範囲を検索、抽出するクエリとなります。
クエリの内容については公式ページ(※2)もご参照ください。

・時間枠
設定したクエリを検索するログの範囲です。5分に設定すると、直前5分間のログに対して設定したクエリを実行します。
設定としては最小5分が可能ですが、ログの取得に時間がかかり、遅延が発生する場合があります。（基本15分程度※3）
そのため間隔は30分程にすることでアラートの誤検知を防ぐことができます。

・アラートの頻度
このアラート判定を行う間隔です。

・アラートを生成する基準
クエリによって抽出された結果の判定方法を設定できます。
結果の数や、取得した数値の情報に応じてアラート発火の条件とすることが可能です。

各サーバへの検索内容サンプルを以下に記載します。

◆Webサーバの監視例
HTTP応答コードが200のログが検出されないとアラート
・検索クエリ
NetworkMonitoring | where SubType == “EndpointHealth” and ServiceResponseCode == “200” and TestName == “nw-web01”
→テスト「nw-web01」において、HTTP応答コード200のログ
・アラート生成基準：結果の数
次の値より小さい：1

◆社内汎用サーバの監視例
ネットワーク損失が100%のログを1つ以上検出したらアラート
・検索クエリ
NetworkMonitoring | where SubType == “EndpointHealth” and ServiceLossPercent == “100” and TestName == “nw-local01”
→テスト「nw-local01」において、ネットワーク損失100%のログ
・アラート生成基準：結果の数
次の値より大きい：1

 

監視サーバ自身の監視設定

(13)Azureポータルで[すべてのリソース]から、「Network Performance」で検索し、対象のソリューションをクリックします。

(14)[OMSポータル]をクリックすします。

(15)画面左側のカバンマークをクリックし、[Agent Health]をクリックします。

(16)[追加]をクリックします。

(17)アラートルールを設定し、[保存]をクリックします。
設定内容は上記(12)を参照ください。

◆監視サーバエージェントの監視例
監視サーバのハードビートログが出力されていなければアラート
・検索クエリ
Heartbeat | summarize LastCall = max(TimeGenerated) by “監視サーバ名”
→監視サーバから出力された最新のログ
・アラート生成基準：結果の数
次の値より小さい：1

 

構築作業は以上で完了です。

 

結果の確認方法

Webサーバ、社内汎用サーバの監視結果

(1)Azureポータルで[すべてのリソース]から、「Network Performance」で検索し、対象のソリューションをクリックします。

(2)[Network Performance Monitoring]の概要部分をクリックします。

(3)[サービスエンドポイントモニター]の[テスト]をクリックします。

(4)テストの結果が表示されます。

時系列でのグラフ結果も確認可能です。

監視サーバ自身の監視結果

(5)Azureポータルで[すべてのリソース]から、「Agent Health」で検索し、対象のソリューションをクリックします。

(6)「概要]部分をクリックします。

(7)Agentの監視結果が確認できます。

 

 

システム評価・まとめ

評価：簡易的な監視であれば利用可能だが、緊急性の高いシステムに対する監視としてはまだ不十分な個所も多い。

以下にNPM監視を実際に構築してのメリットデメリットを記載します。

—————–
【メリット】
・構築が非常に簡単
監視サーバに対してはAgentをインストールする必要がありますが、簡易な監視であれば、監視対象へのAgent等のインストールは不要です。
・低コストで利用可能
発生コストはエージェントをインストールする仮想マシンの稼働費用と、OMSワークスペース料金となります。
また、規模にもよりますが、Agentをインストールする仮想マシンのサイズはA1レベルから利用可能で、OMSワークスペースについてもログ保存期間7日間であれば無料で利用可能です。

【デメリット】
・現段階ではサイト監視はプレビュー
GAされていないため仕様変更や機能に不具合がある可能性があります。
・監視の間隔が長い
アラートの判定頻度は最小5分となっています。もう少し短い間隔での監視を行いたいところかと思います。
・ログ、アラートの遅延
アラート判定する対象のログの取得、集計には、公式ドキュメントにもあるように時間がかかる場合があります。
ログの集計が遅延すると、条件として「○○のログが出力されていないこと」と言ったアラート条件があるときに、
実際はログが出力されているのに、OMSでまだ取得できていないためにアラートが発火してしまうことなどが考えられます。
遅延は発生しても基本は15分とされており、誤報を防ぐためにはアラートの発生頻度を30分以上にすることで、
ログ取得遅延の影響を受けにくくなりますが、それによって監視間隔の長くなってしまいます。
弊社の運用事例の中でも、集計部分で遅延が発生し、テスト及びアラートの判定結果が遅延したケースが確認されています。
—————–

とはいえ、GAまでに機能の安定化・充足化が進めば本番システムに対しても利用できるものとなるかと思います。
今後もNPMの動向はチェックし、本ページも更新していきたいと思います。

 

※1.MS公式NPM構築手順
https://docs.microsoft.com/ja-jp/azure/log-analytics/log-analytics-agent-windows

※2.クエリ言語リファレンス
https://docs.loganalytics.io/docs/Language-Reference

※3.以下URL内「アラートが発生しない」部分参照
https://docs.microsoft.com/ja-jp/azure/log-analytics/log-analytics-alerts