次の方法で共有

Azure Firewall の監視

  • [アーティクル]

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

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

Note

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

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

Azure Firewall のログとメトリックを使用して、ファイアウォール内のトラフィックと操作を監視できます。 これらのログとメトリックは、次のようないくつかの重要な目的に役立ちます。

  • トラフィック分析: ログを使用して、ファイアウォールを通過するトラフィックを調べて分析します。 この分析には、許可および拒否されたトラフィックの調査、ソースと宛先の IP アドレス、URL、ポート番号、プロトコルなどの検査が含まれます。 これらの分析情報は、トラフィック パターンの理解、潜在的なセキュリティの脅威の特定、接続の問題のトラブルシューティングに不可欠です。

  • パフォーマンスと正常性のメトリック: Azure Firewall のメトリックは、処理されたデータ、スループット、規則ヒット カウント、待機時間などのパフォーマンスと正常性のメトリックを提供します。 これらのメトリックを監視して、ファイアウォールの全体的な正常性を評価し、パフォーマンスのボトルネックを特定し、異常を検出します。

  • 監査証跡: アクティビティ ログを使用すると、ファイアウォール リソースに関連する操作の監査、ファイアウォール規則とポリシーの作成、更新、削除などのアクションをキャプチャできます。 アクティビティ ログを確認すると、構成の変更履歴レコードを保持し、セキュリティと監査の要件に確実に準拠できるようになります。

リソースの種類

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

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

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

データ ストレージ

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 Firewall で利用可能なメトリックの一覧については、「Azure Firewall の監視データのリファレンス」を参照してください。

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 テーブル、Azure Firewall のログ スキーマについては、「Azure Firewall の監視データのリファレンス」を参照してください。

Azure Firewall ブックにより、Azure Firewall のデータ分析のための柔軟なキャンバスが提供されます。 これを使用して、Azure portal 内で高度な視覚的レポートを作成できます。 Azure 全体でデプロイされる複数のファイアウォールを活用し、それらを結合して、統合された対話型エクスペリエンスにすることができます。

自身のストレージ アカウントに接続して、アクセス ログとパフォーマンス ログの JSON ログ エントリを取得することもできます。 JSON ファイルをダウンロードした後、そのファイルを CSV に変換し、Excel、Power BI などのデータ視覚化ツールで表示できます。

ヒント

Visual Studio を使い慣れていて、C# の定数と変数の値を変更する基本的な概念を理解している場合は、GitHub から入手できるログ変換ツールを使用できます。

Azure activity log

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

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

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

構造化された Azure Firewall ログ

構造化ログは、特定の形式で構成されたログ データの一種です。 定義済みのスキーマを使用して、ログ データを簡単に検索、フィルター処理、分析できるように構造化します。 自由形式のテキストで構成される非構造化ログとは異なり、構造化ログには、マシンが解析および分析できる一貫した形式があります。

Azure Firewall の構造化ログでは、ファイアウォール イベントのより詳細なビューが提供されます。 これには、送信元と宛先の IP アドレス、プロトコル、ポート番号、ファイアウォールによって実行されたアクションなどの情報が含まれます。 また、イベントの時刻や Azure Firewall インスタンスの名前など、さらに多くのメタデータも含まれます。

現在、Azure Firewall では、次の診断ログ カテゴリを利用できます。

  • アプリケーション ルール ログ
  • ネットワーク ルール ログ
  • DNS プロキシ ログ

これらのログ カテゴリでは、Azure 診断モードが使用されます。 このモードでは、任意の診断設定に基づくすべてのデータが、AzureDiagnostics テーブルに収集されます。

構造化されたログを使用すると、既存の AzureDiagnostics テーブルではなく、リソース固有テーブルの使用を選択できます。 両方のログ セットが必要な場合は、ファイアウォールごとに少なくとも 2 つの診断設定を作成する必要があります。

リソース固有モード

[リソース固有] モードでは、診断設定で選択されたカテゴリごとに個別のテーブルが、選択されたワークスペース内に作成されます。 次の理由により、この方法をお勧めします。

  • 全体的なログのコストを最大 80% 削減できる。
  • ログ クエリ内のデータの操作をはるかに容易にする。
  • スキーマとその構造の検出を容易にする。
  • インジェストの待ち時間とクエリ時間の両方でパフォーマンスを向上させる。
  • 特定のテーブルに対する Azure RBAC 権限の付与を可能にする。

診断設定で新しいリソース固有テーブルを使用できるようになりました。これにより、次のカテゴリを利用できます。

  • ネットワーク規則のログ - ネットワーク規則のログ データがすべて含まれます。 データ プレーンとネットワーク規則の一致ごとに、データ プレーン パケットおよび一致した規則の属性を含むログ エントリが作成されます。
  • NAT 規則のログ - DNAT (宛先ネットワーク アドレス変換) イベントのログ データがすべて含まれます。 データ プレーンと DNAT 規則の一致ごとに、データ プレーン パケットおよび一致した規則の属性を含むログ エントリが作成されます。
  • アプリケーション規則のログ - アプリケーション規則のログ データがすべて含まれます。 データ プレーンとアプリケーション規則の一致ごとに、データ プレーン パケットおよび一致した規則の属性を含むログ エントリが作成されます。
  • 脅威インテリジェンスのログ - すべての脅威インテリジェンス イベントが含まれます。
  • IDPS のログ - 1 つ以上の IDPS シグネチャと一致したすべてのデータ プレーン パケットが含まれます。
  • DNS プロキシのログ - DNS プロキシ イベントのログ データがすべて含まれます。
  • 内部 FQDN の解決失敗のログ - 失敗の原因になったすべての内部ファイアウォール FQDN 解決要求が含まれます。
  • アプリケーション規則の集計ログ - ポリシー分析用に集計された、アプリケーション規則のログ データが含まれます。
  • ネットワーク規則の集計ログ - ポリシー分析用に集計された、ネットワーク規則のログ データが含まれます。
  • NAT 規則の集計ログ - ポリシー分析用に集計された、NAT 規則のログ データが含まれます。
  • トップ フロー ログ - トップ フロー (ファット フロー) ログには、ファイアウォールを通過するスループットへの寄与の度合が上位である接続が表示されます。
  • フロー トレース - フロー情報、フラグ、フローが記録された期間が含まれます。 SYN、SYN-ACK、FIN、FIN-ACK、RST、INVALID (フロー) などの完全なフロー情報を確認できます。

構造化ログを有効にする

Azure Firewall 構造化ログを有効にするには、まず Azure サブスクリプションで Log Analytics ワークスペースを構成する必要があります。 このワークスペースは、Azure Firewall によって生成された構造化ログを格納するために使用されます。

Log Analytics ワークスペースを構成したら、Azure portal のファイアウォールの [診断設定] ページに移動して、Azure Firewall の構造化ログを有効にすることができます。 そこから、リソース固有のターゲット テーブルを選択し、ログに記録するイベントの種類を選択する必要があります。

Note

機能フラグまたは Azure PowerShell コマンドを使用してこの機能を有効にする要件はありません。

診断設定ページのスクリーンショット。

構造化ログ クエリ

定義済みのクエリの一覧は、Azure portal で入手できます。 この一覧には、カテゴリごとに定義済みの KQL (Kusto 照会言語) ログ クエリと、Azure ファイアウォール ログ イベント全体を 1 つのビューで示す結合クエリがあります。

Azure Firewall クエリを示すスクリーンショット。

Azure Firewall ブック

Azure Firewall ブックにより、Azure Firewall のデータ分析のための柔軟なキャンバスが提供されます。 これを使用して、Azure portal 内で高度な視覚的レポートを作成できます。 Azure 全体でデプロイされる複数のファイアウォールを活用し、それらを結合して、統合された対話型エクスペリエンスにすることができます。

Azure Firewall 構造化ログを使用する新しいブックをデプロイするには、「Azure Firewall 用 Azure Monitor ブック」を参照してください。

従来の Azure Diagnostics ログ

従来の Azure Diagnostics ログは、非構造化または自由形式のテキストの形式でログ データを出力する元の Azure Firewall ログ クエリです。 従来の Azure Firewall のログ カテゴリでは、Azure 診断モードを使用して、AzureDiagnostics テーブル内のデータ全体を収集します。 構造化されたログと診断ログの両方が必要な場合は、ファイアウォールごとに少なくとも 2 つの診断設定を作成する必要があります。

診断ログでは、次のログ カテゴリがサポートされています。

  • Azure Firewall アプリケーション ルール
  • Azure Firewall ネットワーク ルール
  • Azure Firewall DNS プロキシ

Azure portal を使用して診断ログを有効にする方法については、「構造化されたログの有効化」を参照してください。

アプリケーション ルール ログ

アプリケーション ルール ログは、これを各 Azure Firewall で有効にしている場合にのみ、ストレージ アカウントへの保存、Event Hubs へのストリーミング、Azure Monitor ログへの送信が行われます。 構成されているアプリケーション ルールのいずれかと一致する新しい接続ごとに、許可/拒否された接続のログが生成されます。 次の例に示すように、データは JSON 形式でログに記録されます。

Category: application rule logs.
Time: log timestamp.
Properties: currently contains the full message.
note: this field will be parsed to specific fields in the future, while maintaining backward compatibility with the existing properties field.

{
 "category": "AzureFirewallApplicationRule",
 "time": "2018-04-16T23:45:04.8295030Z",
 "resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/{resourceName}",
 "operationName": "AzureFirewallApplicationRuleLog",
 "properties": {
     "msg": "HTTPS request from 10.1.0.5:55640 to mydestination.com:443. Action: Allow. Rule Collection: collection1000. Rule: rule1002"
 }
}

{
  "category": "AzureFirewallApplicationRule",
  "time": "2018-04-16T23:45:04.8295030Z",
  "resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/{resourceName}",
  "operationName": "AzureFirewallApplicationRuleLog",
  "properties": {
      "msg": "HTTPS request from 10.11.2.4:53344 to www.bing.com:443. Action: Allow. Rule Collection: ExampleRuleCollection. Rule: ExampleRule. Web Category: SearchEnginesAndPortals"
  }
}

ネットワーク ルール ログ

ネットワーク ルール ログは、これを各 Azure Firewall で有効にしている場合にのみ、ストレージ アカウントへの保存、Event Hubs へのストリーミング、Azure Monitor ログへの送信が行われます。 構成されているネットワーク ルールのいずれかと一致する新しい接続ごとに、許可/拒否された接続のログが生成されます。 次の例に示すように、データは JSON 形式でログに記録されます。

Category: network rule logs.
Time: log timestamp.
Properties: currently contains the full message.
note: this field will be parsed to specific fields in the future, while maintaining backward compatibility with the existing properties field.

{
 "category": "AzureFirewallNetworkRule",
 "time": "2018-06-14T23:44:11.0590400Z",
 "resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/{resourceName}",
 "operationName": "AzureFirewallNetworkRuleLog",
 "properties": {
     "msg": "TCP request from 111.35.136.173:12518 to 13.78.143.217:2323. Action: Deny"
 }
}

DNS プロキシ ログ

DNS プロキシ ログは、これを各 Azure Firewall で有効にしている場合にのみ、ストレージ アカウントへの保存、Event Hubs へのストリーミング、Azure Monitor ログへの送信が行われます。 このログは、DNS プロキシを使用して構成された DNS サーバーへの DNS メッセージを追跡します。 次の例に示すように、データは JSON 形式でログに記録されます。

Category: DNS proxy logs.
Time: log timestamp.
Properties: currently contains the full message.
note: this field will be parsed to specific fields in the future, while maintaining backward compatibility with the existing properties field.

成功:

{
  "category": "AzureFirewallDnsProxy",
  "time": "2020-09-02T19:12:33.751Z",
  "resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/{resourceName}",
  "operationName": "AzureFirewallDnsProxyLog",
  "properties": {
      "msg": "DNS Request: 11.5.0.7:48197 – 15676 AAA IN md-l1l1pg5lcmkq.blob.core.windows.net. udp 55 false 512 NOERROR - 0 2.000301956s"
  }
}

［失敗］:

{
  "category": "AzureFirewallDnsProxy",
  "time": "2020-09-02T19:12:33.751Z",
  "resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/{resourceName}",
  "operationName": "AzureFirewallDnsProxyLog",
  "properties": {
      "msg": " Error: 2 time.windows.com.reddog.microsoft.com. A: read udp 10.0.1.5:49126->168.63.129.160:53: i/o timeout”
  }
}

メッセージ形式:

[client’s IP address]:[client’s port] – [query ID] [type of the request] [class of the request] [name of the request] [protocol used] [request size in bytes] [EDNS0 DO (DNSSEC OK) bit set in the query] [EDNS0 buffer size advertised in the query] [response CODE] [response flags] [response size] [response duration]

監視データを分析する

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

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 つのアラート ルールで複数のリソースを監視する」をご覧ください。

Azure Firewall メトリックに関するアラート

メトリックは、リソースの正常性を追跡するための重要なシグナルを提供します。 そのため、リソースのメトリックを監視し、異常がないか注意することが重要です。 しかし、Azure Firewall メトリックのフローが停止した場合はどうすればよいですか? これは、潜在的な構成の問題や、障害のようなもっと険悪なものを示している可能性があります。 メトリックが見つからない原因は、Azure Firewall によるメトリックのアップロードをブロックする既定のルートの発行や、正常なインスタンスの数が 0 に減ったことである可能性があります。 このセクションでは、Log Analytics ワークスペースへのメトリックを構成し、メトリックの欠落に対する警告を行う方法を学習します。

Log Analytics ワークスペースに対してメトリックを構成する

最初の手順では、ファイアウォールの診断設定を使用して、Log Analytics ワークスペースに対するメトリックの可用性を構成します。

次のスクリーンショットに示すような診断設定を構成するために、Azure Firewall リソース ページに移動します。 これにより、構成されたワークスペースにファイアウォール メトリックがプッシュされます。

Note

メトリックの診断設定は、ログとは別の構成である必要があります。 ファイアウォール ログは、Azure Diagnostics またはリソース固有を使用するように構成できます。 ただし、ファイアウォール メトリックでは常に Azure Diagnostics を使用する必要があります。

Azure Firewall 診断設定のスクリーンショット。

アラートを作成して、エラーなしでファイアウォール メトリックの受信を追跡する

メトリック診断設定で構成されているワークスペースを参照します。 次のクエリを使用して、メトリックが使用可能かどうかを確認します。

AzureMetrics
| where MetricName contains "FirewallHealth"
| where ResourceId contains "/SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/RESOURCEGROUPS/PARALLELIPGROUPRG/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/HUBVNET-FIREWALL"
| where TimeGenerated > ago(30m)

次に、60 分間を超えるメトリックの欠落に対するアラートを作成します。 メトリックの欠落に対する新しいアラートを設定するために、Log Analytics ワークスペースの [アラート] ページに移動します。

[アラート ルールの編集] ページを示すスクリーンショット。

Azure Firewall アラート ルール

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

Advisor の推奨事項

一部のサービスでは、リソースの操作中にクリティカルな条件や差し迫った変更が発生した場合は、ポータルのサービス [概要] ページにアラートが表示されます。 アラートの詳細と推奨される修正は、左側のメニューの [監視] の下の [アドバイザーのレコメンデーション] に表示されます。 通常の操作中、アドバイザーのレコメンデーションは表示されません。

Azure Advisor の詳細については、Azure Advisor の概要に関するページをご覧ください。

関連するコンテンツ