Azure Virtual WAN を監視する

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

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

Note

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

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

分析情報

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 にルーティングして、他のログ データを使用してクエリを実行することもできます。 詳細については、「メトリック診断設定」を参照してください。 サービスの診断設定を構成する方法については、「Azure Monitor で診断設定を作成する」を参照してください。

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

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

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

  1. [ゲートウェイの監視] を選択し、[メトリック] を選択します。 下部にある [メトリック] を選択し、サイト間およびポイント対サイト VPN の最も重要なメトリックのダッシュボードを表示することもできます。

    サイト間 VPN メトリック ダッシュボードを示すスクリーンショット。

  2. [メトリック] ページでメトリックを表示できます。

    カテゴリが強調表示されている [メトリック] ページを示すスクリーンショット。

  3. 仮想ハブ ルーターのメトリックを表示するには、仮想ハブの [概要] ページから [メトリック] を選択します。

    メトリック ボタンが表示された仮想ハブ ページを示すスクリーンショット。

詳細については、「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 の間でサポートできます。 現時点では、MaxMin 集計の種類は意味がありません。

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 つのメトリック値の合計 (クエリが実行されたメトリックの場合、メインの値に焦点が当たる)

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

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

  1. ポータルで、Virtual WAN リソースに移動し、 [接続] グループで [ハブ] を選択します。

    vWAN ポータルでのハブの選択を示すスクリーンショット。

  2. 左側の [接続] グループで、診断を調べるゲートウェイを選択します。

    ハブの [接続] セクションを示すスクリーンショット。

  3. ページの右側にある [ゲートウェイの監視] をクリックし、[ログ] を選択します。

    [ログ] の [Azure Monitor で表示] の選択を示すスクリーンショット。

  4. このページで新しい診断設定の作成 ([+診断設定の追加]) や既存の診断設定の編集 ([設定の編集]) を実施できます。 診断ログを Log Analytics に送信するか (次の例を参照)、イベント ハブにストリーミングするか、サード パーティのソリューションに送信するか、ストレージ アカウントにアーカイブするかを選択できます。

    [診断ログの設定] の選択を示すスクリーンショット。

  5. [保存] をクリックすると、数時間以内にこのログ分析ワークスペースにログが表示され始めるのが確認できるはずです。

  6. (Azure Firewall を使用して) セキュリティで保護されたハブを監視するには、次のように [診断設定] タブにアクセスして診断とログの構成を行う必要があります。

    スクリーンショットは、ファイアウォール診断設定を示しています。

重要

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

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

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

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

スクリーンショットは、vWAN ハブ リソース グループ内のファイアウォール リソースを示しています。

Azure activity log

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

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

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

監視データを分析する

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

Azure Monitor ツール

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

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

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

Azure Monitor エクスポート ツール

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

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 のトラブルシューティング」を参照してください。

ログ クエリ

  • トンネル切断警告ルールの作成 - ログ クエリ: 次のログ クエリを使用することで、警告ルールの作成時にトンネル切断イベントを選択できます。

    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 ゲートウェイとの接続に問題が発生している場合に特定できるようになります。

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 を構成します。 スループット メトリックの単位はビット/秒です。警告ルールを作成する場合は、平均の集計の種類を選択します。

リソース正常性アラート

次のリソースに対して 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