監視データのAzure Firewallリファレンス

この記事には、このサービスに関するすべての監視リファレンス情報が含まれています。

Azure Firewall用に収集できるデータとその使用方法の詳細については、Monitor Azure Firewallを参照してください。

Metrics

このセクションには、このサービスに関して自動的に収集されるすべてのプラットフォーム メトリックが一覧表示されています。 これらのメトリックは、 Azure Monitor でサポートされるすべてのプラットフォーム メトリックのグローバル リストの一部でもあります。

メトリックのリテンション期間については、「Azure Monitor メトリックの概要を参照してください。

Microsoft.Network/azureFirewalls でサポートされているメトリック

次の表に、Microsoft.Network/azureFirewalls リソースの種類で使用できるメトリックを示します。

• すべての列がすべてのテーブルに存在しないことがあります。
• 一部の列がページの表示領域を超えている場合があります。 [テーブルの展開] を選択すると、使用可能なすべての列が表示されます。

テーブル見出し

• カテゴリ - メトリック グループまたは分類。
• Metric - Azure ポータルに表示されるメトリックの表示名。
• REST API の名前 - REST API で参照されるメトリック名。
• 単位 - 測定単位。
• 集計 - 既定の 集計 の種類。 有効な値: 平均 (Avg)、最小 (Min)、最大 (Max)、合計 (Sum)、数。
• ディメンションメトリックで使用できるディメンション。
• 時間グレインメトリックをサンプリングする間隔。 たとえば、 は、メトリックを 1 分ごとに、は 30 分ごとに、 は 1 時間ごとにサンプリングすることを示します。
• DS Export- 診断設定を使用してメトリックを Azure Monitor ログにエクスポートできるかどうかを指定します。 メトリックのエクスポートの詳細については、「Azure Monitor で診断設定を作成するを参照してください。

監視された容量

監視容量メトリックは、実際のファイアウォールのスケーリング方法を理解するための主要なツールです。

監視された容量を使用するためのベスト プラクティス

• 事前スケーリングのセットアップを検証します。 定義した minCapacity がファイアウォールで一貫して維持されていることを確認します。
• リアルタイム スケーリングの動作を追跡します。 Avg 集計を使用して、リアルタイムの容量ユニットを確認します。
• 将来のニーズを予測する: 過去の観測容量とトラフィックの傾向 (毎月のスパイクや季節イベントなど) を組み合わせて、容量計画を調整します。
• プロアクティブ アラートの設定: 監視容量のしきい値 (たとえば、スケーリングが maxCapacity の 80% を超えたときのアラート) でAzure Monitorアラートを構成します。
• パフォーマンス メトリックと関連付ける: 監視された容量をスループット、待機時間プローブ、SNAT ポート使用率とペアにして、スケーリングが需要に合わせて維持されるかどうかを診断します。

ファイアウォールの正常性状態

前の表では、 Firewall 正常性状態 メトリックには 2 つのディメンションがあります。

• 状態: 有効な値は 、正常、 低下、 異常です。
• 理由:ファイアウォールの対応する状態の理由を示します。

SNAT ポートが 95%を超える場合は、使い果たされたと見なされ、正常性は 50% で status=Degraded and reason=SNAT port です。 ファイアウォールによってトラフィックの処理が継続され、既存の接続に影響はありません。 ただし、新しい接続が断続的に確立されない場合があります。

SNAT ポートの使用率が 95% 未満の場合、ファイアウォールは正常と見なされ、正常性は 100% として表示されます。

SNAT ポートの使用が報告されない場合、正常性は 0% として表示されます。

SNAT ポート使用率

SNAT ポート使用率メトリックでは、ファイアウォールにパブリック IP アドレスを追加すると、SNAT ポートが増え、SNAT ポートの使用率が低下します。 さらに、さまざまな理由 (CPU やスループットなど) のためにファイアウォールがスケールアウトされると、より多くの SNAT ポートも使用できるようになります。

実際には、サービスがスケールアウトされたからといって、パブリック IP アドレスを追加しなくても、SNAT ポート使用率の特定の割合が低下する可能性があります。ファイアウォールで使用可能なポートを増やすために使用できるパブリック IP アドレスの数を直接制御できます。 ただし、ファイアウォールのスケーリングを直接制御することはできません。

ファイアウォールが SNAT ポート不足に陥っている場合は、少なくとも 5 つのパブリック IP アドレスを追加する必要があります。 これにより、使用可能な SNAT ポートの数が増えます。 詳細については、「Azure Firewall機能を参照してください。

AZFW 待機時間プローブ

AZFW Latency Probe メトリックは、Azure Firewallの全体的または平均待機時間をミリ秒単位で測定します。 管理者は、次の目的でこのメトリックを使用できます。

• Azure Firewallがネットワークの待機時間を引き起こすかどうかを診断する
• 待機時間やパフォーマンスの問題を監視してアラートを生成し、IT チームが積極的に関与できるようにする
• 高い CPU 使用率、高スループット、ネットワークの問題など、Azure Firewallの待機時間が長くなる可能性があるさまざまな要因を特定する

AZFW 待機時間プローブ メトリックで測定される内容

• Measures: Azure プラットフォーム内でのAzure Firewallの待機時間
• 測定しない: ネットワーク パス全体のエンドツーエンドの待機時間。 メトリックには、ネットワークに導入される待機時間ではなく、ファイアウォール内のパフォーマンスAzure Firewall反映されます
• エラー報告: 待機時間メトリックが正しく機能していない場合は、メトリック ダッシュボードに値 0 が報告され、プローブの失敗または中断が示されます

待機時間に影響を与える要因

ファイアウォールの待機時間には、いくつかの要因が影響を与える可能性があります。

• 高い CPU 使用率
• 高スループットまたはトラフィック負荷
• Azure プラットフォーム内のネットワークの問題

待機時間プローブ: ICMP から TCP へ

待機時間プローブでは現在、ICMP (インターネット制御メッセージ プロトコル) に基づく Microsoft の Ping Mesh テクノロジが使用されています。 ICMP は ping 要求などの迅速な正常性チェックに適していますが、実際のアプリケーション トラフィック (通常は TCP に依存) を正確に表していない可能性があります。 ただし、ICMP プローブは、Azure プラットフォーム間で優先順位が異なるため、SKU 間で変動する可能性があります。 これらの不一致を減らすために、Azure Firewallは TCP ベースのプローブに移行する予定です。

重要な考慮事項:

• 待機時間の急増: ICMP プローブでは、断続的なスパイクは正常であり、ホスト ネットワークの標準動作の一部です。 これらのスパイクが解決しない限り、ファイアウォールの問題として誤って解釈しないでください。
• Average latency: ファイアウォール SKU とデプロイ サイズに応じて、平均Azure Firewall待機時間の範囲は 1 ミリ秒から 10 ミリ秒です。

待機時間を監視するためのベスト プラクティス

• ベースラインの設定: 通常またはピーク時の正確な比較のために、軽いトラフィック条件下で待機時間のベースラインを確立します。

  Note

  ベースラインを確立するときは、最近のインフラストラクチャの変更により、メトリックが急上昇することが予想されます。 これらの一時的なスパイクは正常であり、実際の問題ではなく、メトリック レポートの調整による結果です。 スパイクが時間の経過と同時に続く場合にのみ、サポートリクエストを送信してください。

• パターンを監視する: 通常の操作の一部として、待機時間が急上昇する場合があります。 これらの通常のバリエーションを超えて長い待機時間が続く場合は、調査が必要なより深い問題を示している可能性があります。

• 推奨される待機時間のしきい値: 推奨されるガイドラインは、待機時間がベースラインの 3 倍を超えないようにすることです。 このしきい値を超えた場合は、さらに調査することをお勧めします。

• ルールの制限を確認します。ネットワーク ルールが 20,000 ルールの制限内にあることを確認します。 この制限を超えると、パフォーマンスに影響する可能性があります。

• 新しいアプリケーションのオンボード: 負荷が大幅に増加したり、待機時間の問題が発生したりする可能性がある、新しくオンボードされたアプリケーションを確認します。

• サポート要求: 予想される動作と一致しない継続的な待機時間の低下が観察された場合は、サポート チケットを提出してさらにサポートを受けてください。

  Azure Firewall Latency Probe metric.

メトリック ディメンション

メトリック ディメンションについては、「多次元メトリック」を参照してください。

このサービスでは、次のディメンションがそのメトリックに関連付けられています。

• Protocol
• Reason
• Status

リソース ログ

このセクションでは、このサービス用に収集できるリソース ログの種類を一覧表示します。 このセクションは、Azure Monitor でサポートされているリソース ログ カテゴリの種類の一覧から取得します。

Microsoft.Network/azureFirewalls でサポートされているリソース ログ

DNS フロー トレース ログ

DNS フロー トレース ログは、DNS アクティビティをより詳細に把握し、管理者が解決の問題をトラブルシューティングし、トラフィックの動作を確認するのに役立ちます。

以前は、DNS プロキシのログ記録は次に制限されていました。

• AZFWDNSQuery - 初期クライアント クエリ
• AZFWInternalFqdnResolutionFailure - FQDN 解決エラー

DNS フロー トレース ログを使用すると、管理者は、クライアント クエリから DNS プロキシとしてAzure Firewall、外部 DNS サーバー、およびクライアントに戻って、完全な DNS 解決フローをトレースできます。

DNS 解決ステージ

ログには、次のステージがキャプチャされます。

1. クライアント クエリ: クライアントによって送信された初期 DNS クエリ
2. Forwarder クエリ: クエリを外部 DNS サーバーに転送Azure Firewall (キャッシュされていない場合)
3. Forwarder 応答: Azure Firewallに対する DNS サーバーの応答
4. Client response: Azure Firewallからクライアントへの最終的な解決済み応答

次の図は、DNS クエリ フローの概要を示しています。

クライアントからAzure Firewallから外部 DNS サーバーへの DNS クエリ フローと back.

これらのログは、次のような貴重な分析情報を提供します。

• クエリを実行した DNS サーバー
• 解決された IP アドレス
• Azure Firewall キャッシュが使用されたかどうか

DNS フロー トレース ログの有効化

DNS フロー トレース ログを設定する前に、まず、Azure PowerShellを使用して機能を有効にする必要があります。

ログを有効にする (前提条件)

プレースホルダーを実際の値に置き換えて、Azure PowerShellで次のコマンドを実行します。

Set-AzContext -SubscriptionName <SubscriptionName>
$firewall = Get-AzFirewall -ResourceGroupName <ResourceGroupName> -Name <FirewallName>
$firewall.EnableDnstapLogging = $true
Set-AzFirewall -AzureFirewall $firewall

ログを無効にする (省略可能)

ログを無効にするには、前と同じAzure PowerShell コマンドを使用し、値を False

Set-AzContext -SubscriptionName <SubscriptionName>
$firewall = Get-AzFirewall -ResourceGroupName <ResourceGroupName> -Name <FirewallName>
$firewall.EnableDnstapLogging = $false
Set-AzFirewall -AzureFirewall $firewall

DNS プロキシと DNS フロー トレース ログを構成する

DNS プロキシを構成し、DNS フロー トレース ログを有効にするには、次の手順を使用します。

1. DNS プロキシを有効にする:

   1. Azure Firewall DNS 設定に移動し、DNS プロキシを有効にします。
   2. カスタム DNS サーバーを構成するか、既定のAzure DNSを使用します。
   3. Virtual Network DNS 設定に移動し、ファイアウォールのプライベート IP をプライマリ DNS サーバーとして設定します。

2. DNS フロー トレース ログを有効にします。

   1. Azure ポータルでAzure Firewallに移動します。
   2. [監視] で [ 診断設定 ] を選択 します。
   3. 既存の診断設定を選択するか、新しい診断設定を作成します。
   4. [ ログ ] セクションで、[ DNS フロー トレース ログ] を選択します。
   5. 目的の宛先 (Log Analyticsまたはストレージ アカウント) を選択します。

   Note

   DNSフロートレースログは、Event Hubを宛先としてサポートしていません。

   6. 設定を保存します。

3. 構成をテストする:

   1. クライアントから DNS クエリを生成し、選択した宛先のログを確認します。

ログを理解する

各ログ エントリは、DNS 解決プロセスの特定のステージに対応します。 次の表では、ログの種類とキー フィールドについて説明します。

上記のフィールドは、各ログ エントリで使用可能なフィールドのサブセットにすぎません。

重要事項:

• DNS キャッシュが使用されている場合は、 クライアント クエリ エントリと クライアント応答 エントリのみが生成されます。
• ログには、タイムスタンプ、送信元/宛先 IP、プロトコル、DNS メッセージの内容などの標準メタデータが含まれます。
• 有効期間の短いクエリが多数ある環境で過剰なログ ボリュームを回避するには、より詳細な DNS トラブルシューティングが必要な場合にのみ、追加の DNS プロキシ ログを有効にします。

上位のフロー

トップ フロー ログは、業界では fat フロー ログ と呼ばれ、前の表では Azure Firewall Fat Flow Log として知られています。 上部のフロー ログには、ファイアウォールを介した最高のスループットに寄与する上位の接続が表示されます。

流量は、1 秒あたりのメガビット単位でのデータ伝送速度として定義されます。 これは、ファイアウォールを介して一定期間にネットワーク経由で送信できるデジタル データの量の尺度です。 上位フローのプロトコルは、3 分ごとに定期的に実行されます。 上位フローと見なされる最小しきい値は 1 Mbps です。

上位フロー ログを有効にする

トップ フロー ログを有効にするには、次のAzure PowerShellコマンドを使用します。

Set-AzContext -SubscriptionName <SubscriptionName>
$firewall = Get-AzFirewall -ResourceGroupName <ResourceGroupName> -Name <FirewallName>
$firewall.EnableFatFlowLogging = $true
Set-AzFirewall -AzureFirewall $firewall

上位フロー ログを無効にする

ログを無効にするには、同じAzure PowerShell コマンドを使用し、値を False に設定します。 例えば次が挙げられます。

Set-AzContext -SubscriptionName <SubscriptionName>
$firewall = Get-AzFirewall -ResourceGroupName <ResourceGroupName> -Name <FirewallName>
$firewall.EnableFatFlowLogging = $false
Set-AzFirewall -AzureFirewall $firewall

構成を確認する

更新が成功したことを確認するには、複数の方法があります。 ファイアウォールの [概要 ] に移動し、右上隅にある JSON ビュー を選択します。 次に例を示します。

追加のログ検証を示す JSON のスクリーンショット。

診断設定を作成し、リソース固有のテーブルを有効にするには、Azure Monitorを参照してください。

フロー トレース

ファイアウォール ログには、TCP 接続の最初の試行でファイアウォールを通過したトラフィック ( SYN パケットと呼ばれます) が表示されます。 ただし、このようなエントリでは、TCP ハンドシェイク内のパケットの完全な体験は表示されません。 その結果、パケットが破棄された場合や非対称ルーティングが発生した場合のトラブルシューティングは困難です。 Azure Firewall フロー トレース ログは、この問題に対処します。

フロー トレースのプロパティ

次のプロパティを追加できます。

• SYN-ACK: SYN パケットの受信確認を示す ACK フラグ。

• FIN: 元のパケット フローのフラグが完了しました。 TCP フローで送信されるデータはこれ以上ありません。

• FIN-ACK: FIN パケットの受信確認を示す ACK フラグ。

• RST: リセット フラグは、元の送信者がより多くのデータを受信しないことを示します。

• INVALID (フロー):パケットを識別できないか、状態がないことを示します。

  例えば次が挙げられます。

  • TCP パケットは、Virtual Machine Scale Sets インスタンスに到着します。このインスタンスには、このパケットの以前の履歴はありません。
  • 不適切なチェックサムのパケット
  • 接続の追跡テーブルのエントリがいっぱいで、新しい接続を受け入れることができない場合
  • 過度に遅延した ACK パケット

フロー トレース ログを有効にする

フロー トレース ログを有効にするには、次のAzure PowerShellコマンドを使用します。 または、ポータル内を移動し、[ TCP 接続ログの有効化] を検索します。

Connect-AzAccount 
Select-AzSubscription -Subscription <subscription_id> or <subscription_name>
Register-AzProviderFeature -FeatureName AFWEnableTcpConnectionLogging -ProviderNamespace Microsoft.Network
Register-AzResourceProvider -ProviderNamespace Microsoft.Network

この変更が有効になるまで数分かかる場合があります。 機能が登録されたら、変更をすぐに有効にするために、Azure Firewallに対して更新を実行することを検討してください。

登録の状態を確認する

AzResourceProvider 登録の状態を確認するには、次の Azure PowerShell コマンドを実行します。

Get-AzProviderFeature -FeatureName "AFWEnableTcpConnectionLogging" -ProviderNamespace "Microsoft.Network"

フロー トレース ログを無効にする

ログを無効にするには、次のAzure PowerShellコマンドを使用します。

Connect-AzAccount 
Select-AzSubscription -Subscription <subscription_id> or <subscription_name>
$firewall = Get-AzFirewall -ResourceGroupName <ResourceGroupName> -Name <FirewallName>
$firewall.EnableTcpConnectionLogging = $false
Set-AzFirewall -AzureFirewall $firewall

診断設定を作成し、リソース固有のテーブルを有効にするには、Azure Monitorを参照してください。

ログ テーブルのAzure Monitor

このセクションでは、このサービスに関連する Azure Monitor ログ テーブルの一覧を示します。このテーブルは、Kusto クエリを使用してLog Analyticsクエリに使用できます。 テーブルにはリソース ログ データが含まれており、収集されルーティングされる内容によっては、さらに多くのデータが含まれる場合があります。

Azure Firewall Microsoft.Network/azureFirewalls

• AZFWNetworkRule
• AZFWFatFlow
• AZFWFlowTrace
• AZFWApplicationRule
• AZFWThreatIntel
• AZFWNatRule
• AZFWIdpsSignature
• AZFWDnsQuery
• AZFWInternalFqdnResolutionFailure
• AZFWNetworkRuleAggregation
• AZFWApplicationRuleAggregation
• AZFWNatRuleAggregation
• AzureActivity
• AzureMetrics
• AzureDiagnostics

アクティビティ ログ

リンクされたテーブルには、このサービスのアクティビティ ログに記録できる操作が一覧表示されます。 これらの操作は、アクティビティ ログで使用可能なすべてのリソース プロバイダー操作のサブセットです。

アクティビティ ログ エントリのスキーマの詳細については、「アクティビティ ログのスキーマ」を参照してください。

• ネットワーク リソース プロバイダーの操作

関連コンテンツ

• 監視Azure Firewallの説明については、Monitor Azure Firewall を参照してください。
• ファイアウォール規則<変更を追跡するための詳細なAzure Resource Graph クエリについては<>ルール セットの変更の追跡に関する記事を参照してください。
• Azure リソースの監視の詳細については、Monitor Azure リソースと Azure Monitor を参照してください。