Azure Virtual WAN を監視する

[アーティクル]
09/25/2024

この記事では、次の内容について説明します。

このサービスに対して収集できる監視データの種類。
そのデータを分析する方法。

Note

このサービスや Azure Monitor を既に使い慣れていて、監視データの分析方法だけを確認したい場合は、この記事で後述する分析に関するセクションをご覧ください。

Azure リソースに依存するクリティカルなアプリケーションやビジネスプロセスがある場合は、システムを監視し、そのアラートを受け取る必要があります。 Azure Monitor サービスでは、システムのすべてのコンポーネントからメトリックとログを収集して集計します。 Azure Monitor を使用すると、可用性、パフォーマンス、回復性を視覚化し、問題に関する通知を受け取ることができます。 Azure portal、PowerShell、Azure CLI、REST API、またはクライアントライブラリは、監視データの設定および表示に使用できます。

Azure Monitor の詳細については、「Azure Monitor の概要」を参照してください。
Azure リソース全般の監視方法の詳細については、「Azure Monitor を使用した Azure リソースの監視」をご覧ください。

分析情報

Azure の一部のサービスについては、サービスを監視するための開始点となる監視ダッシュボードが Azure portal に組み込まれています。これらのダッシュボードは、"分析情報" と呼ばれており、Azure portal の Azure Monitor の [分析情報ハブ] にあります。

Virtual WAN によりネットワーク分析情報が使用されると、ユーザーやオペレーターは、自動検出されたトポロジマップを使用して仮想 WAN の状態とステータスを確認できます。リソースの状態とステータスがマップに重ねて表示され、仮想 WAN の全体的な正常性のスナップショットビューが提供されます。 Virtual WAN ポータルのリソース構成ページにワンクリックを使用してアクセスすることで、マップのリソースにナビゲーションすることができます。 Virtual WAN の詳細については、「Azure Monitor Network Insights」を参照してください。

リソースの種類

Azure では、リソースの種類と ID の概念を使用して、サブスクリプション内のすべてを識別します。リソースの種類は、Azure で実行されているすべてのリソースのリソース ID の一部でもあります。たとえば、Microsoft.Compute/virtualMachines は、仮想マシンのリソースの種類の 1 つです。サービスとそれに関連付けられるリソースの種類の一覧については、リソースプロバイダーに関するページをご覧ください。

同様に、Azure Monitor では、コア監視データがリソースの種類 (名前空間とも呼ばれます) に基づいてメトリックとログに整理されます。リソースの種類に応じてさまざまなメトリックとログが使用できます。サービスは、複数のリソースの種類に関連付けられる可能性があります。

Virtual WAN のリソースの種類の詳細については、「Azure Virtual WAN の監視 - データリファレンス」を参照してください。

データストレージ

Azure Monitor の場合:

メトリックデータは、Azure Monitor メトリックデータベースに保存されます。
ログデータは、Azure Monitor ログストアに保存されます。 Log Analytics は、Azure portal のツールの 1 つであり、このストアに対してクエリを実行することができます。
Azure アクティビティログは、Azure Portal 内の独自のインターフェイスを持つ別のストアです。

必要に応じて、メトリックおよびアクティビティログデータを Azure Monitor ログストアにルーティングできます。次に、Log Analytics を使用してデータのクエリを実行し、他のログデータと関連付けることができます。

多くのサービスで診断設定を使用して、メトリックとログデータを Azure Monitor の外部の他のストレージの場所に送信できます。たとえば、Azure Storage、ホステッドパートナーシステム、Event Hubs を使用する Azure 以外のパートナーシステムなどがあります。

Azure Monitor によるデータの保存方法の詳細については、「Azure Monitor データプラットフォーム」を参照してください。

Azure Monitor プラットフォームのメトリック

Azure Monitor により、ほとんどのサービスに関するプラットフォームメトリックが提供されます。これらのメトリックは次のとおりです。

名前空間ごとに個別に定義されます。
Azure Monitor 時系列メトリックデータベースに保存されます。
軽量であり、凖リアルタイムのアラートをサポートできます。
リソースのパフォーマンスを時間の経過と共に追跡するために使用されます。

収集: Azure Monitor では、プラットフォームメトリックを自動的に収集します。構成は必要ありません。

ルーティング: また、いくつかのプラットフォームメトリックを Azure Monitor ログまたは Log Analytics にルーティングして、他のログデータを使用してクエリを実行することもできます。各メトリックの DS エクスポート設定を確認して、診断設定を使用してメトリックを Azure Monitor ログまたは Log Analytics にルーティングできるかどうかを確認します。

詳細については、「メトリック診断設定」を参照してください。
サービスの診断設定を構成する場合は、「Azure Monitor の診断設定を作成する」を参照してください。

Azure Monitor ですべてのリソースに対して収集できるすべてのメトリックの一覧については、Azure Monitor でサポートされるメトリックに関する記事を参照してください。

Virtual WAN で使用できるメトリックの一覧については、「Azure Virtual WAN の監視 - データリファレンス」を参照してください。

Azure portal を使用して、Virtual WAN のメトリックを表示できます。次の手順に従い、メトリックを検索して表示できます。

[ゲートウェイの監視] を選択し、[メトリック] を選択します。下部にある [メトリック] を選択し、サイト間およびポイント対サイト VPN の最も重要なメトリックのダッシュボードを表示することもできます。
[メトリック] ページでメトリックを表示できます。
仮想ハブルーターのメトリックを表示するには、仮想ハブの [概要] ページから [メトリック] を選択します。

詳細については、「Azure リソースのメトリックを分析する」を参照してください。

PowerShell ステップ

PowerShell を使用して、Virtual WAN のメトリックを表示することができます。クエリを実行するには、次の PowerShell コマンドの例を使用します。

$MetricInformation = Get-AzMetric -ResourceId "/subscriptions/<SubscriptionID>/resourceGroups/<ResourceGroupName>/providers/Microsoft.Network/VirtualHubs/<VirtualHubName>" -MetricName "VirtualHubDataProcessed" -TimeGrain 00:05:00 -StartTime 2022-2-20T01:00:00Z -EndTime 2022-2-20T01:30:00Z -AggregationType Sum

$MetricInformation.Data

リソース ID。仮想ハブのリソース ID は、Azure portal で確認できます。 vWAN 内の仮想ハブページに移動し、[Essentials] の [JSON ビュー] を選択します。
メトリック名。クエリを実行するメトリックの名前を指します。この場合は VirtualHubDataProcessed という名前です。このメトリックには、ハブの選択した期間内に仮想ハブルーターで処理されたすべてのデータが表示されます。
時間グレイン。集計を表示する頻度を示します。現在のコマンドでは、5 分ごとに選択された集計ユニットが表示されます。 5M、15M、30M、1H、6H、12H、1D から選択できます。
開始時刻と終了時刻。この時刻は UTC に基づいています。これらのパラメーターを入力するときは、必ず UTC 値を入力してください。これらのパラメーターを使用しない場合、既定では過去 1 時間分のデータが表示されます。
sum 集計の種類。 sum 集計の種類には、選択した期間中に仮想ハブルーターを通過した合計バイト数が表示されます。たとえば、時間の細分性を 5 分に設定すると、各データポイントはその 5 分間隔で送信されたバイト数に対応します。この値を Gbps に変換するには、この数値を 37500000000 で除算します。仮想ハブの容量に基づいて、ハブルーターは 3 Gbps から 50 Gbps の間でサポートできます。現時点では、Max と Min 集計の種類は意味がありません。

Azure Monitor リソースログ

リソースログでは、Azure リソースによって実行された操作に関する分析情報を提供します。ログは自動的に生成されますが、保存するかクエリを実行するには、Azure Monitor ログにルーティングする必要があります。ログはカテゴリに分類されています。特定の名前空間に複数のリソースログカテゴリが含まれる場合があります。

収集: リソースログは、"診断設定" を作成してログを 1 つ以上の場所にルーティングするまでは収集および保存されません。診断設定を作成するときは、収集するログのカテゴリを指定します。診断設定を作成して管理するには、Azure portal、プログラム、Azure Policy など、複数の方法があります。

ルーティング: 既定で推奨されるのは、リソースログを Azure Monitor ログにルーティングして、他のログデータを使用してクエリを実行できるようにすることです。 Azure Storage、Azure Event Hubs、特定の Microsoft 監視パートナーなど、その他の場所も利用できます。詳細については、「Azure リソースログ」およびリソースログの送信先に関するページを参照してください。

リソースログの収集、保存、ルーティングの詳細については、「Azure Monitor の診断設定」を参照してください。

Azure Monitor で使用可能なすべてのリソースログカテゴリの一覧については、Azure Monitor でサポートされているリソースログに関するページを参照してください。

Azure Monitor 内のすべてのリソースログには、同じヘッダーフィールドの後にサービス固有のフィールドがあります。共通のスキーマの概要については、Azure Monitor リソースログのスキーマに関する記事をご覧ください。

使用可能なリソースログカテゴリ、それらに関連付けられている Log Analytics テーブル、Virtual WAN のログスキーマについては、「Azure Virtual WAN の監視 - データリファレンス」を参照してください。

スキーマ

診断ログの上位スキーマについて詳しくは、「Azure 診断ログでサポートされているサービス、スキーマ、カテゴリ」をご覧ください。

Log Analytics 経由でメトリックを確認すると、出力に次の列が含まれます。

列	タイプ	説明
TimeGrain	string	PT1M (メトリック値が 1 分ごとにプッシュされます)
Count	real	通常は 2 に等しい (各 MSEE により、1 分ごとにメトリック値が 1 つプッシュされます)
最小値	real	2 つの MSEE によってプッシュされる 2 つのメトリック値の最小値
最大値	real	2 つの MSEE によってプッシュされる 2 つのメトリック値の最大値
Average	real	(最小値 + 最大値)/2 に等しい
合計	real	両方の MSEE からの 2 つのメトリック値の合計 (クエリが実行されたメトリックの場合、メインの値に焦点が当たる)

診断設定を作成してログを表示する

次の手順を使用すると、診断設定の作成、編集、表示を行うことができます。

ポータルで、Virtual WAN リソースに移動し、 [接続] グループで [ハブ] を選択します。
左側の [接続] グループで、診断を調べるゲートウェイを選択します。
ページの右側にある [ゲートウェイの監視] をクリックし、[ログ] を選択します。
このページで新しい診断設定の作成 ([+診断設定の追加]) や既存の診断設定の編集 ([設定の編集]) を実施できます。診断ログを Log Analytics に送信するか (次の例を参照)、イベントハブにストリーミングするか、サードパーティのソリューションに送信するか、ストレージアカウントにアーカイブするかを選択できます。
[保存] をクリックすると、数時間以内にこのログ分析ワークスペースにログが表示され始めるのが確認できるはずです。
(Azure Firewall を使用して) セキュリティで保護されたハブを監視するには、次のように [診断設定] タブにアクセスして診断とログの構成を行う必要があります。

重要

これらの設定を有効にするには、追加の Azure サービス (ストレージアカウント、イベントハブ、または Log Analytics) が必要であり、コストが増加する可能性があります。推定コストを計算するには、Azure 料金計算ツールにアクセスしてください。

セキュリティ保護付きハブの監視 (Azure Firewall)

Azure Firewall を使用して仮想ハブをセキュリティで保護することを選択した場合、関連するログとメトリックは「Azure Firewall のログとメトリック」に記載されています。

Azure Firewall のログとメトリックを使用して、セキュリティ保護付きハブを監視できます。また、アクティビティログを使用して、Azure Firewall リソースに対する操作を監査することもできます。セキュリティで保護し、セキュリティ保護付きハブに変換するすべての Azure Virtual WAN に対して、明示的なファイアウォールリソースオブジェクトが Azure Firewall によって作成されます。このオブジェクトは、ハブが配置されているリソースグループ内にあります。

Azure activity log

アクティビティログには、Azure リソースごとに操作を追跡する、そのリソースの外から見たサブスクリプションレベルのイベント (新しいリソースの作成や仮想マシンの起動など) が含まれます。

収集: アクティビティログイベントは、Azure portal で表示するために、個別のストアに自動的に生成および収集されます。

ルート指定: アクティビティログデータを Azure Monitor ログに送信して、他のログデータと共に分析できます。 Azure Storage、Azure Event Hubs、特定の Microsoft 監視パートナーなど、その他の場所も利用できます。アクティビティログをルーティングする方法の詳細については、Azure アクティビティログの概要に関するページをご覧ください。

監視データを分析する

監視データを分析するためのツールは多数あります。

Azure Monitor ツール

Azure Monitor は、次の基本的なツールをサポートします。

メトリックスエクスプローラー。Azure リソースのメトリックを表示および分析できる Azure portal のツール。詳細については、「Azure Monitor メトリックスエクスプローラーを使用したメトリックの分析」を参照してください。
Log Analytics は、Kusto クエリ言語 (KQL) を使用して、ログデータのクエリと分析を可能にする Azure Portal のツールです。詳細については、「Azure Monitor でログクエリの使用を開始する」を参照してください。
アクティビティログ。表示および基本的な検索用のユーザーインターフェイスが Azure portal に用意されています。より詳細な分析を行うには、データを Azure Monitor ログにルーティングし、Log Analytics でより複雑なクエリを実行する必要があります。

より複雑な視覚化を可能にするツールは次のとおりです。

ダッシュボードを使用すると、さまざまな種類のデータを組み合わせて、Azure portal 内の 1 つのペインに表示できます。
ブック。Azure portal で作成できるカスタマイズ可能なレポート。ブックには、テキスト、メトリック、ログクエリを含めることができます。
Grafana。運用ダッシュボードに優れたオープンプラットフォームツール。 Grafana を使用して、Azure Monitor 以外の複数のソースからのデータを含むダッシュボードを作成できます。
Power BI。さまざまなデータソースにわたって対話型の視覚化を提供するビジネス分析サービス。 Azure Monitor からログデータを自動的にインポートするように Power BI を構成して、これらの視覚化を利用できます。

Azure Monitor エクスポートツール

次の方法を使用して、Azure Monitor から他のツールにデータを取得できます。

メトリック: メトリック用 REST API を使用して、Azure Monitor メトリックデータベースからメトリックデータを抽出します。この API では、取得したデータを絞り込むためのフィルター式がサポートされています。詳細については、Azure Monitor REST API のリファレンスをご覧ください。
ログ: REST API または関連するクライアントライブラリを使用します。
もう 1 つのオプションは、ワークスペースデータのエクスポートです。

Azure Monitor 用 REST API の使用を開始するには、「Azure 監視 REST API のチュートリアル」を参照してください。

Kusto クエリ

Kusto クエリ言語 (KQL) を使用して、Azure Monitor ログ/Log Analytics ストアの監視データを分析できます。

重要

ポータルでサービスのメニューから [ログ] を選択すると、クエリスコープが現在のサービスに設定された状態で Log Analytics が開きます。このスコープは、ログクエリにその種類のリソースのデータのみが含まれることを意味します。他の Azure サービスのデータを含むクエリを実行する場合は、[Azure Monitor] メニューから [ログ] を選択します。詳細については、「Azure Monitor Log Analytics のログクエリのスコープと時間範囲」を参照してください。

いずれかのサービスに関する一般的なクエリの一覧については、Log Analytics クエリインターフェイスに関するページを参照してください。

警告

Azure Monitor のアラートにより、監視データで特定の状態が見つかったときに事前に通知を受け取ります。アラートにより、ユーザーが気付く前に、管理者が問題を識別して対処できます。詳細については、Azure Monitor アラートに関するページを参照してください。

Azure リソースに関する一般的なアラートのソースは数多くあります。 Azure リソースに関する一般的なアラートの例については、ログアラートクエリのサンプルに関するページをご覧ください。 Azure Monitor ベースラインアラート (AMBA) サイトには、重要なプラットフォームメトリックアラート、ダッシュボード、ガイドラインを実装するための半自動化された方法が用意されています。このサイトは、Azure ランディングゾーン (ALZ) の一部であるすべてのサービスを含む、Azure サービスの継続的に拡張されるサブセットに適用されます。

共通アラートスキーマを使用すると、Azure Monitor のアラート通知の使用を標準化できます。詳細については、「共通アラートスキーマ」をご覧ください。

アラートの種類

Azure Monitor データプラットフォームでは、任意のメトリックまたはログデータソースに対してアラートを生成できます。監視するサービスと収集する監視データに応じて、さまざまな種類のアラートがあります。アラートの種類に応じて、さまざまな利点と欠点があります。詳細については、適切な種類の監視アラートの選択に関するページをご覧ください。

次の一覧では、作成できる Azure Monitor アラートの種類について説明します。

メトリックアラートでは、リソースメトリックを定期的に評価します。メトリックはプラットフォームメトリック、カスタムメトリック、メトリックに変換された Azure Monitor からのログまたは Application Insights メトリックにすることができます。メトリック警告では、複数の条件と動的しきい値を適用することもできます。
ログアラートでは、ユーザーは Log Analytics クエリを使用して、定義済みの頻度でリソースログを評価できます。
アクティビティログアラートは、定義された条件と一致する新しいアクティビティログイベントが発生したときにトリガーされます。 Resource Health アラートと Service Health アラートは、サービスとリソースの正常性を報告するアクティビティログアラートです。

一部の Azure サービスでは、スマート検出アラート、Prometheus アラート、推奨されるアラートルールもサポートされています。

一部のサービスでは、同じ Azure リージョン内に存在する同じ種類の複数のリソースに同じメトリック警告ルールを適用することで、大規模に監視することができます。監視対象リソースごとに個別の通知が送信されます。サポートされている Azure サービスとクラウドについては、「1 つのアラートルールで複数のリソースを監視する」をご覧ください。

Note

サービスで動作するアプリケーションを作成または実行している場合、Azure Monitor Application Insights は他の種類の警告を表示する場合があります。

Virtual WAN のアラートルール

「Azure Virtual WAN の監視 - データリファレンス」の一覧に示されている任意のメトリック、ログエントリ、またはアクティビティログエントリに対してアラートを設定できます。

Azure Virtual WAN の監視 - ベストプラクティス

この記事では、Virtual WAN を監視するための構成におけるベストプラクティスと、Virtual WAN と一緒に展開できるさまざまなコンポーネントについて説明します。この記事で紹介する推奨事項は、ほとんどが既存の Azure Monitor のメトリックと Azure Virtual WAN で生成されたログに基づいています。 Virtual WAN のために収集されるメトリックとログの一覧については、Virtual WAN 監視データのリファレンスに関するページを参照してください。

この記事の推奨事項のほとんどで、Azure Monitor アラートを作成することをお勧めしています。 Azure Monitor アラートを使用すると、監視データに重要なイベントがある場合に事前に通知を受けることができます。この情報は、根本原因に迅速に対処し、最終的にダウンタイムを短縮するのに役立ちます。メトリックアラートの作成方法については、「チュートリアル: Azure リソースのメトリックアラートを作成する」を参照してください。ログクエリアラートを作成する方法については、「チュートリアル: Azure リソースのログクエリアラートを作成する」を参照してください。

Virtual WAN ゲートウェイ

このセクションでは、Virtual WAN ゲートウェイのベストプラクティスについて説明します。

サイト間 VPN ゲートウェイ

設計チェックリスト – メトリックアラート

トンネルのエグレスパケット数またはイングレスパケット数のドロップの増加に対する警告ルールを作成します。
BGP ピア状態を監視するためのアラートルールを作成します。
アドバタイズされた BGP ルートと学習済みの BGP ルートを監視する警告ルールを作成します。
VPN ゲートウェイの過大使用に対する警告ルールを作成します。
トンネルの過大使用に対する警告ルールを作成します。

推奨	説明
トンネルのエグレスパケットまたはイングレスパケットのドロップ数の増加に対する警告ルールを作成します。	トンネルのエグレスパケットまたはイングレスパケットのドロップ数の増加は、Azure VPN ゲートウェイまたはリモート VPN デバイスの問題を示している可能性があります。アラートルールの作成時に [トンネルのエグレスパケットまたはイングレスパケットのドロップ数] メトリックを選択します。警告ロジックを構成する場合、静的しきい値は 0 より大きくして、合計の集計の種類を定義します。 [接続] を全体として監視するか、[インスタンス] と [リモート IP] によって警告ルールを分割して、個々のトンネルに関する問題に警告を発することを選択できます。 Virtual WAN における VPN 接続、リンク、トンネルの概念の間の相違については、「Virtual WAN の FAQ」を参照してください。
BGP ピア状態を監視するためのアラートルールを作成します。	サイト間接続で BGP を使用する場合、エラーが頻発して接続が中断される可能性があるため、ゲートウェイインスタンスとリモートデバイス間の BGP ピアリングの正常性を監視することが重要です。警告ルールの作成時に BGP ピア状態メトリックを選択します。静的しきい値を使用して、平均の集計の種類を選択し、値が 1 未満になるたびにアラートがトリガーされるように構成します。個々のピアリングの問題を検出するために、インスタンスと BGP ピアアドレスでアラートを分割することをお勧めします。このメトリックは、インスタンス自体 (常に 0) を含む、可能なすべての組み合わせの BGP の状態を監視するため、ゲートウェイインスタンス IP を BGP ピアアドレスとして選択することは避けてください。
アドバタイズされた BGP ルートと学習済みの BGP ルートを監視する警告ルールを作成します。	アドバタイズされた BGP ルートと学習済みの BGP ルートは、それぞれ VPN ゲートウェイがピアにアドバタイズしたルートとピアから学習を行ったルートの数を監視します。これらのメトリックが予期せずゼロになった場合は、ゲートウェイまたはオンプレミスに問題がある可能性があります。これらのメトリックの値が 0 になるたびにアラートがトリガーされるように構成することをお勧めします。合計の集計の種類を選択します。 [インスタンス] で分割して、個々のゲートウェイインスタンスを監視します。
VPN ゲートウェイの過大使用に対する警告ルールを作成します。	VPN ゲートウェイの合計スループットは、インスタンスごとのスケールユニットの数によって決まります。同じゲートウェイインスタンスで終了するすべてのトンネルで、その合計スループットは共有されます。インスタンスがその容量で長期間動作している場合、トンネルの安定性に影響する可能性があります。警告ルールの作成時に [ゲートウェイの S2S 帯域幅] を選択します。平均スループットが両方のインスタンスの最大合計スループットに近い値を上回るたびに、アラートがトリガーされるように設定します。あるいは、アラートをインスタンスごとに分割し、インスタンスごとの最大スループットを参照として使用します。適切な数のスケールユニットを選択するために、トンネルあたりのスループットのニーズを事前に決定しておくことをお勧めします。サイト間 VPN ゲートウェイでサポートされるスケールユニット値の詳細については、仮想 WAN の FAQ を参照してください。
トンネルの過大使用に対する警告ルールを作成します。	トンネルごとに許可される最大スループットは、それが終了するゲートウェイインスタンスのスケールユニットによって決まります。トンネルが最大スループットに近づく危険性があり、パフォーマンスや接続の問題につながる可能性がある場合に、アラートを受け取ることができます。トンネル使用率が増加する根本原因を調査するか、ゲートウェイのスケールユニットを増やして事前に対策を講じます。警告ルールの作成時に [トンネル帯域幅] を選択します。 [インスタンス] と [リモート IP] で分割して、個々のトンネルをすべて監視するか、特定のトンネルを選択します。平均スループットがトンネルごとに許可される最大スループットに近い値を上回るたびに、アラートがトリガーされるように設定します。トンネルの最大スループットがゲートウェイのスケールユニットによってどのような影響を受けるかについては、「Virtual WAN の FAQ」を参照してください。

設計チェックリスト - ログクエリアラート

ログベースのアラートを構成するには、まずサイト間/ポイント対サイト VPN ゲートウェイの診断設定を作成する必要があります。診断設定とは、収集するログやメトリックを定義し、後で分析するためにそのデータの保存方法を定義することです。ゲートウェイのメトリックとは異なり、診断設定が構成されていない場合、ゲートウェイログは利用できません。診断設定の作成方法については、「診断設定を作成してログを表示する」を参照してください。

トンネル切断警告ルールを作成します。
BGP 切断警告ルールを作成します。

推奨	説明
トンネル切断警告ルールを作成します。	トンネル診断ログを使用して、サイト間接続の切断イベントを追跡します。切断イベントは、SA のネゴシエートに失敗した場合や、リモート VPN デバイスが応答しなかった場合などに発生します。トンネル診断ログには、切断理由も表示されます。警告ルールの作成時に切断イベントを選択するには、この表の下の「トンネル切断警告ルールの作成 - ログクエリ」を参照してください。このクエリを実行した結果の行数が 0 より大きい場合にアラートがトリガーされるように構成します。このアラートを有効にするには、[集計の細分性] で 1 ～ 5 分を選択し、[評価の頻度] で同様に 1 ～ 5 分を選択します。この方法では、集計の細分性の間隔を経過した後、新しい間隔では行数が再び 0 になります。トンネル診断ログを分析する場合のトラブルシューティングのヒントについては、診断ログを使用した「Azure VPN ゲートウェイのトラブルシューティング」を参照してください。さらに、これらのログには IKE 固有の詳細な診断が含まれているため、IKE 診断ログを使用してトラブルシューティングを補完します。
BGP 切断警告ルールを作成します。	ルート診断ログを使用して、ルート更新と BGP セッションの問題を追跡します。 BGP 切断イベントが繰り返し発生すると、接続性に影響を与え、ダウンタイムが発生する可能性があります。警告ルールの作成時に切断イベントを選択するには、この表の下の「BGP 切断警告ルールの作成 - ログクエリ」を参照してください。このクエリを実行した結果の行数が 0 より大きい場合にアラートがトリガーされるように構成します。このアラートを有効にするには、[集計の細分性] で 1 ～ 5 分を選択し、[評価の頻度] で同様に 1 ～ 5 分を選択します。この方法では、集計の細分性の間隔を経過した後、BGP セッションが復元されている場合は、新しい間隔では行数が再び 0 になります。ルート診断ログで収集されるデータの詳細については、「診断ログを使用した Azure VPN Gateway のトラブルシューティング」を参照してください。

推奨

説明

トンネル切断警告ルールを作成します。

トンネル診断ログを使用して、サイト間接続の切断イベントを追跡します。切断イベントは、SA のネゴシエートに失敗した場合や、リモート VPN デバイスが応答しなかった場合などに発生します。トンネル診断ログには、切断理由も表示されます。警告ルールの作成時に切断イベントを選択するには、この表の下の「トンネル切断警告ルールの作成 - ログクエリ」を参照してください。

このクエリを実行した結果の行数が 0 より大きい場合にアラートがトリガーされるように構成します。このアラートを有効にするには、[集計の細分性] で 1 ～ 5 分を選択し、[評価の頻度] で同様に 1 ～ 5 分を選択します。この方法では、集計の細分性の間隔を経過した後、新しい間隔では行数が再び 0 になります。

トンネル診断ログを分析する場合のトラブルシューティングのヒントについては、診断ログを使用した「Azure VPN ゲートウェイのトラブルシューティング」を参照してください。さらに、これらのログには IKE 固有の詳細な診断が含まれているため、IKE 診断ログを使用してトラブルシューティングを補完します。

BGP 切断警告ルールを作成します。

ルート診断ログを使用して、ルート更新と BGP セッションの問題を追跡します。 BGP 切断イベントが繰り返し発生すると、接続性に影響を与え、ダウンタイムが発生する可能性があります。警告ルールの作成時に切断イベントを選択するには、この表の下の「BGP 切断警告ルールの作成 - ログクエリ」を参照してください。

このクエリを実行した結果の行数が 0 より大きい場合にアラートがトリガーされるように構成します。このアラートを有効にするには、[集計の細分性] で 1 ～ 5 分を選択し、[評価の頻度] で同様に 1 ～ 5 分を選択します。この方法では、集計の細分性の間隔を経過した後、BGP セッションが復元されている場合は、新しい間隔では行数が再び 0 になります。

ルート診断ログで収集されるデータの詳細については、「診断ログを使用した Azure VPN Gateway のトラブルシューティング」を参照してください。

ログクエリ

トンネル切断警告ルールの作成 - ログクエリ: 次のログクエリを使用することで、警告ルールの作成時にトンネル切断イベントを選択できます。
```
AzureDiagnostics
| where Category == "TunnelDiagnosticLog" 
| where OperationName == "TunnelDisconnected"
```
BGP 切断警告ルールの作成 - ログクエリ: 次のログクエリを使用することで、警告ルールの作成時に BGP 切断イベントを選択できます。
```
AzureDiagnostics 
| where Category == "RouteDiagnosticLog" 
| where OperationName == "BgpDisconnectedEvent"
```

ポイント対サイト VPN ゲートウェイ

次のセクションでは、メトリックベースのアラートの構成の詳細についてのみ説明します。ただし、Virtual WAN ポイント対サイトゲートウェイは診断ログもサポートします。ポイント対サイトゲートウェイで利用可能な診断ログの詳細については、「ポイント対サイト VPN ゲートウェイの診断」を参照してください。

設計チェックリスト – メトリックアラート

ゲートウェイの過大使用に対する警告ルールを作成します。
P2S 接続数が上限に近づいた場合にアラートを作成します。
ユーザー VPN ルート数が上限に近づいた場合にアラートを作成します。

推奨	説明
ゲートウェイの過大使用に対する警告ルールを作成します。	ポイント対サイトゲートウェイの帯域幅は、構成されているスケールユニットの数によって決まります。ポイント対サイトゲートウェイのスケールユニットに関する詳細については、ポイント対サイト (ユーザー VPN) を参照してください。ゲートウェイ P2S 帯域幅メトリックを使用してゲートウェイの使用率を監視し、ゲートウェイの帯域幅がその合計スループット付近の値を上回るたびにトリガーされるアラートルールを構成します。たとえば、ゲートウェイが 2 つのスケールユニットで構成される場合、合計スループットは 1 Gbp になります。この場合、しきい値を 950 Mbps に定義できます。このアラートを使用して、使用量が増加した根本原因を予防的に調査し、必要に応じて最終的にスケールユニットの数を増加します。警告ルールを構成する場合は、平均の集計の種類を選択します。
P2S 接続数が上限に近づいた場合にアラートを作成する	許可されるポイント対サイト接続の最大数は、ゲートウェイに構成されているスケールユニットの数によっても決まります。ポイント対サイトゲートウェイのスケールユニットに関する詳細については、ポイント対サイト (ユーザー VPN) の FAQ を参照してください。接続数を監視するには、P2S 接続数メトリックを使用します。このメトリックを選択すると、接続数が最大許容数に近づいたときにトリガーされる警告ルールが構成されます。たとえば、1 スケールのユニットゲートウェイは最大 500 のコンカレント接続をサポートします。この場合、接続数が 450 より多くなるたびにアラートがトリガーされるように構成できます。このアラートを使用して、スケールユニット数を増やす必要があるかどうかを判断します。警告ルールを構成する場合は、合計の集計の種類を選択します。
ユーザー VPN ルート数が上限に近づいた場合に警告ルールを作成します。	使用されるプロトコルによって、ユーザー VPN ルートの最大数が決まります。 IKEv2 には 255 ルートのプロトコルレベルの制限がありますが、OpenVPN には 1,000 ルートの制限があります。このことの詳細については、「VPN サーバー構成の概念」を参照してください。ユーザー VPN の最大ルート数に到達しそうになったらアラートが表示され、ダウンタイムを回避するために予防的に行動できます。ユーザー VPN ルート数を使用してこの状況を監視し、ルート数が制限値に近い値を超えるたびにトリガーされるアラートルールを構成します。たとえば、制限が 255 ルートの場合、適切なしきい値は 230 です。警告ルールを構成する場合は、合計の集計の種類を選択します。

ExpressRoute ゲートウェイ

次のセクションでは、メトリックベースのアラートについて説明します。ゲートウェイコンポーネントに焦点を当ててここで説明したアラートに加え、利用可能なメトリック、ログ、ツールを使用して ExpressRoute 回線を監視することをお勧めします。 ExpressRoute 監視の詳細については、「ExpressRoute 監視、メトリック、アラート」を参照してください。 ExpressRoute Traffic Collector ツールの使用方法については、「ExpressRoute Direct 用の ExpressRoute Traffic Collector を構成する」を参照してください。

設計チェックリスト – メトリックアラート

1 秒あたりの受信ビット数に対するアラートルールを作成します。
CPU の過大使用に対する警告ルールを作成します。
1 秒あたりのパケット数に対するアラートルールを作成します。
ピアにアドバタイズされるルート数に警告ルールを作成します。
ピアから学習を行ったルートの数の警告ルールの数。
ルート変更の頻度が高い場合の警告ルールを作成します。

推奨	説明
1 秒あたりの受信ビット数に対する警告ルールを作成します。	1 秒あたりの受信ビット数は、ゲートウェイが MSEE から受信したトラフィックの総量を監視します。ゲートウェイが受信するトラフィック量が最大スループットに達する危険性がある場合に、アラートを受け取ることができます。この状況は、パフォーマンスと接続の問題につながる可能性があります。このアプローチにより、ゲートウェイの使用率の増加の根本原因を調査したり、ゲートウェイの最大許容スループットを増加させたりして、予防的に行動できます。平均の集計の種類としきい値をゲートウェイに対してプロビジョニングされた最大スループットに近い値を警告ルールを構成する場合に選択します。さらに、ゲートウェイまたは MSEE の問題を示す可能性があるため、1 秒あたりの受信ビット数が 0 に近い場合にアラートを設定することをお勧めします。 ExpressRoute ゲートウェイの最大スループットは、プロビジョニングされたスケールユニットの数によって決まります。 ExpressRoute ゲートウェイのパフォーマンスの詳細については、「Azure Virtual WAN での ExpressRoute 接続について」を参照してください。
CPU の過大使用に対する警告ルールを作成します。	ExpressRoute ゲートウェイを使用する場合、CPU 使用率を監視することが重要です。長時間にわたって使用率が高い状態が続くと、パフォーマンスや接続性に影響を与える可能性があります。 CPU 使用率メトリックを使用して使用率を監視し、CPU 使用率が 80% を上回るたびにアラートを作成します。そのため、根本原因を調査し、必要に応じて最終的にスケールユニットの数を増やすことができます。警告ルールを構成する場合は、平均の集計の種類を選択します。 ExpressRoute ゲートウェイのパフォーマンスの詳細については、「Azure Virtual WAN での ExpressRoute 接続について」を参照してください。
1 秒あたりの受信パケット数に対する警告ルールを作成します。	1 秒あたりのパケット数は、Virtual WAN ExpressRoute ゲートウェイを通過する受信パケット数を監視します。 1 秒あたりのパケット数が、ゲートウェイに構成されているスケールユニットの数に対する許容上限に近づいている場合、アラートを出す必要がある場合があります。警告ルールを構成する場合は、平均の集計の種類を選択します。しきい値は、ゲートウェイのスケールユニット数に基づいて、1 秒あたりのパケット数の最大許容数に近い値を選択します。 ExpressRoute のパフォーマンスの詳細については、「Azure Virtual WAN での ExpressRoute 接続について」を参照してください。さらに、ゲートウェイまたは MSEE の問題を示す可能性があるため、1 秒あたりのパケット数が 0 に近い場合にアラートを設定することをお勧めします。
ピアにアドバタイズされるルート数に警告ルールを作成します。	ピアにアドバタイズされたルートの数は、ExpressRoute ゲートウェイから仮想ハブルーターと Microsoft Enterprise Edge デバイスにアドバタイズされるルート数を監視します。 ExpressRoute デバイスとして表示された 2 つの BGP ピアのみを選ぶフィルターを追加し、アドバタイズされるルートのカウントがドキュメントで規定された上限の 1,000 に近づいた場合に特定するアラートを作成することをお勧めします。たとえば、アドバタイズされるルート数がが 950 を上回る場合にアラートがトリガーされるように構成します。また、接続性の問題を事前に検出するために、Microsoft Edge デバイスにアドバタイズされるルート数がゼロになった場合にアラートを構成することをお勧めします。これらのアラートを追加するには、ピアにアドバタイズされたルートの数メトリックを選択し、[フィルターの追加] オプションと ExpressRoute デバイスを選択します。
ピアから学習を行ったルートの数の警告ルールを作成します。	ピアから学習したルートの数は、ExpressRoute ゲートウェイが仮想ハブルーターと Microsoft Enterprise Edge デバイスから学習したルート数を監視します。 ExpressRoute デバイスとして表示される 2 つの BGP ピアのみを選ぶフィルターを追加し、学習するルートのカウントがドキュメントで規定された上限 (Standard SKU 回路の場合は 4,000、Premium SKU 回路の場合は 10,000) に近づいた場合に特定するアラートを作成することをお勧めします。また、Microsoft Edge デバイスにアドバタイズされるルート数がゼロになった場合にアラートを構成することをお勧めします。このアプローチは、オンプレミスでルートのアドバタイズが停止したときを検出するのに役立ちます。
ルート変更の頻度が高い場合の警告ルールを作成します。	ルート変更の頻度は、サイト間 VPN やポイント間 VPN などの他の種類のブランチを含む、ピアとの間で学習を行い、アドバタイズされるルートの変更頻度を示します。このメトリックは、新しいブランチまたは複数の回路が接続/切断されている場合に可視性を提供します。このメトリックは、フラッピングなどの BGP 広告の問題を特定する場合に役立つツールです。環境が静的で、BGP の変更が予想されない場合にアラートを設定することをお勧めします。 BGP の挙動を一貫して監視するために、しきい値は 1 より大きく、集計の細分性は 15 分を選択します。環境が動的で BGP の変更が頻繁に予想される場合は、擬陽性を避けるためにアラートを設定しないことも選択できます。ただし、ネットワークの可観測性については、引き続きこの指標を考慮することができます。

仮想ハブ

次のセクションでは、仮想ハブのメトリックベースのアラートについて説明します。

設計チェックリスト – メトリックアラート

BGP ピアの状態のアラートルールを作成する

推奨	説明
BGP ピア状態を監視するためのアラートルールを作成します。	警告ルールの作成時に BGP ピア状態メトリックを選択します。静的しきい値を使用して、平均の集計の種類を選択し、値が 1 未満になるたびにアラートがトリガーされるように構成します。このアプローチにより、仮想ハブルーターで、ハブにデプロイされている ExpressRoute、サイト間 VPN、ポイント対サイト VPN ゲートウェイとの接続に問題が発生している場合に特定できるようになります。

推奨

説明

BGP ピア状態を監視するためのアラートルールを作成します。

警告ルールの作成時に BGP ピア状態メトリックを選択します。静的しきい値を使用して、平均の集計の種類を選択し、値が 1 未満になるたびにアラートがトリガーされるように構成します。

このアプローチにより、仮想ハブルーターで、ハブにデプロイされている ExpressRoute、サイト間 VPN、ポイント対サイト VPN ゲートウェイとの接続に問題が発生している場合に特定できるようになります。

Azure Firewall

このセクションでは、メトリックベースのアラートに焦点を当てます。 Azure Firewall は、監視目的のためにメトリックとログの包括的な一覧を提供します。次のセクションで説明するアラートの構成に加えて、Azure Firewall の監視に Azure Firewall ブックを役立てる方法を確認してください。また、Microsoft Sentinel 用 Azure Firewall コネクタを使用して Azure Firewall ログを Microsoft Sentinel に接続する利点についても確認してください。

設計チェックリスト – メトリックアラート

SNAT ポート枯渇リスクに対する警告ルールを作成します。
ファイアウォールの過大使用に対する警告ルールを作成します。

推奨	説明
SNAT ポート枯渇リスクに対する警告ルールを作成します。	Azure Firewall では、バックエンド仮想マシンスケールセットインスタンスごとに構成されたパブリック IP アドレスあたり 2,496 個の SNAT ポートが提供されます。インターネットへの送信トラフィックに関する組織の要件を満たすことができる SNAT ポート数を事前に推定することが重要です。そうしないと、Azure Firewall で利用可能な SNAT ポートの数が枯渇するリスクが高まり、送信接続に失敗する可能性があります。 SNAT ポート使用率メトリックを使用して、現在使用されている送信 SNAT ポートの割合を監視します。このメトリックのアラートルールを作成して、(予期しないトラフィックの増加などにより) この割合が 95% を超えるたびにトリガーされるようにし、Azure Firewall にその他のパブリック IP アドレスを構成するか、代わりに Azure NAT Gateway を使用することにより、それに応じて行動できるようにします。警告ルールを構成する場合は、最大の集計の種類を選択します。 SNAT ポート使用率メトリックを解釈する方法の詳細については、「Azure Firewall のログとメトリックの概要」を参照してください。 Azure Firewall で SNAT ポートをスケーリングする方法については、「Azure NAT Gateway を使用した SNAT ポートのスケーリング」を参照してください。
ファイアウォールの過大使用に対する警告ルールを作成します。	Azure Firewall の最大スループットは、SKU と有効な機能によって異なります。 Azure Firewall のパフォーマンスの詳細については、「Azure Firewall のパフォーマンス」参照してください。ファイアウォールのスループットが最大に近づいた場合に、アラートを受け取ることができます。この状況はファイアウォールのパフォーマンスに影響する可能性があるため、根本原因をトラブルシューティングできます。 [スループット] メトリックがファイアウォールの最大スループットに近い値を超えるたびにアラートルールがトリガーされるように作成します。たとえば、最大スループットが 30 Gbps の場合、[しきい値] として 25 Gbps を構成します。スループットメトリックの単位はビット/秒です。警告ルールを作成する場合は、平均の集計の種類を選択します。

推奨

説明

SNAT ポート枯渇リスクに対する警告ルールを作成します。

Azure Firewall では、バックエンド仮想マシンスケールセットインスタンスごとに構成されたパブリック IP アドレスあたり 2,496 個の SNAT ポートが提供されます。インターネットへの送信トラフィックに関する組織の要件を満たすことができる SNAT ポート数を事前に推定することが重要です。そうしないと、Azure Firewall で利用可能な SNAT ポートの数が枯渇するリスクが高まり、送信接続に失敗する可能性があります。

SNAT ポート使用率メトリックを使用して、現在使用されている送信 SNAT ポートの割合を監視します。このメトリックのアラートルールを作成して、(予期しないトラフィックの増加などにより) この割合が 95% を超えるたびにトリガーされるようにし、Azure Firewall にその他のパブリック IP アドレスを構成するか、代わりに Azure NAT Gateway を使用することにより、それに応じて行動できるようにします。警告ルールを構成する場合は、最大の集計の種類を選択します。

SNAT ポート使用率メトリックを解釈する方法の詳細については、「Azure Firewall のログとメトリックの概要」を参照してください。 Azure Firewall で SNAT ポートをスケーリングする方法については、「Azure NAT Gateway を使用した SNAT ポートのスケーリング」を参照してください。

ファイアウォールの過大使用に対する警告ルールを作成します。

Azure Firewall の最大スループットは、SKU と有効な機能によって異なります。 Azure Firewall のパフォーマンスの詳細については、「Azure Firewall のパフォーマンス」参照してください。

ファイアウォールのスループットが最大に近づいた場合に、アラートを受け取ることができます。この状況はファイアウォールのパフォーマンスに影響する可能性があるため、根本原因をトラブルシューティングできます。

[スループット] メトリックがファイアウォールの最大スループットに近い値を超えるたびにアラートルールがトリガーされるように作成します。たとえば、最大スループットが 30 Gbps の場合、[しきい値] として 25 Gbps を構成します。 スループット メトリックの単位はビット/秒です。警告ルールを作成する場合は、平均の集計の種類を選択します。

リソース正常性アラート

次のリソースに対して Service Health を介してリソース正常性アラートを構成することもできます。このアプローチにより、Virtual WAN 環境の可用性について通知を受け取ることができます。アラートを使用すると、ネットワークの問題の原因が、オンプレミス環境の問題ではなく、Azure リソースが異常な状態になったことによるものかどうかをトラブルシューティングできます。リソースの状態が機能低下または使用不能になったときにアラートを構成することをお勧めします。リソースの状態がデグレードまたは使用不能になった場合は、これらのリソースによって処理されるトラフィック量、これらのリソースにアドバタイズされたルート、または作成されたブランチまたは VNet 接続の数に最近の急増があるかどうかを分析できます。 Virtual WAN でサポートされている制限の詳細については、Azure Virtual WAN の制限に関する記事を参照してください。

Microsoft.Network/vpnGateways
Microsoft.Network/expressRouteGateways
Microsoft.Network/azureFirewalls
Microsoft.Network/virtualHubs
Microsoft.Network/p2sVpnGateways

Virtual WAN に対して作成されるメトリック、ログ、その他の重要な値のリファレンスについては、「Azure Virtual WAN の監視 - データリファレンス」を参照してください。
Azure リソースの監視に関する一般的な詳細情報については、「Azure Monitor を使用した Azure リソースの監視」を参照してください。

次の方法で共有

Azure Virtual WAN を監視する

分析情報

リソースの種類

データストレージ