Referenz zu Azure Firewall-Überwachungsdaten

Dieser Artikel enthält alle Referenzinformationen zur Überwachung dieses Dienstes.

Ausführliche Informationen zu den Daten, die Sie für Azure Firewall sammeln können, und deren Verwendung finden Sie unter "Überwachen der Azure Firewall ".

Metriken

In diesem Abschnitt werden alle automatisch erfassten Plattformmetriken für diesen Dienst aufgeführt. Diese Metriken sind auch Teil der globalen Liste aller in Azure Monitor unterstützten Plattformmetriken.

Informationen zur Aufbewahrung von Metriken finden Sie unter Überblick über Metriken in Azure Monitor.

Unterstützte Metriken für Microsoft.Network/azureFirewalls

In der folgenden Tabelle sind die Metriken aufgeführt, die für den Ressourcentyp "Microsoft.Network/azureFirewalls" verfügbar sind.

• Möglicherweise sind nicht alle Spalten in jeder Tabelle vorhanden.
• Einige Spalten können über den Anzeigebereich der Seite hinausgehen. Wählen Sie Tabelle erweitern aus, um alle verfügbaren Spalten anzuzeigen.

Tabellenüberschriften

• Kategorie – Die Metrikgruppe oder -klassifizierung.
• Metrik – Der Anzeigename der Metrik, wie er im Azure-Portal angezeigt wird.
• Name in REST-API: Der Metrikname im REST-API
• Einheit – Abrechnungseinheit.
• Aggregation – Der Standard-Aggregationstyp. Gültige Werte: Mittelwert (Avg), Minimum (Min), Maximum (Max), Gesamt (Sum), Anzahl
• Dimensionen - Für die Metrik verfügbare Dimensionen.
• Aggregationsintervall - Intervalle, in denen die Metrik gesampelt wird. PT1M bedeutet zum Beispiel, dass die Metrik jede Minute abgerufen wird, PT30M alle 30 Minuten, PT1H jede Stunde usw.
• DS-Export – Gibt an, ob die Metrik über Diagnose-Einstellungen in Azure Monitor-Protokolle exportiert werden kann. Informationen zum Exportieren von Metriken finden Sie unter Diagnoseeinstellungen in Azure Monitor erstellen.

Beobachtete Kapazität

Die Metrik "Beobachtete Kapazität" ist das primäre Tool, um zu verstehen, wie Ihre Firewall in der Praxis skaliert wird.

Bewährte Methoden für die Verwendung der beobachteten Kapazität

• Überprüfen Sie Ihre Vorkalierungseinrichtung: Vergewissern Sie sich, dass Ihre Firewall die von Ihnen definierte minCapacity konsistent verwaltet.
• Nachverfolgen des Skalierungsverhaltens in Echtzeit: Verwenden Sie die Avg-Aggregation, um Echtzeitkapazitätseinheiten anzuzeigen.
• Prognose zukünftiger Bedürfnisse: Kombinieren Sie historische beobachtete Kapazität mit Verkehrstrends (z. B. monatliche Spitzen oder saisonale Ereignisse), um Ihre Kapazitätsplanung zu verfeinern.
• Proaktive Warnungen festlegen: Konfigurieren Sie Azure Monitor-Warnungen für Schwellenwerte für beobachtete Kapazität (z. B. Warnung, wenn die Skalierung 80% von maxCapacity überschreitet).
• Korrelieren mit Leistungsmetriken: Paar beobachtete Kapazität mit Durchsatz, Latenzsonde und SNAT-Portauslastung, um zu diagnostizieren, ob die Skalierung den Anforderungen entspricht.

Integritätszustand der Firewall

In der vorstehenden Tabelle weist die Metrik " Firewallintegritätsstatus " zwei Dimensionen auf:

• Status: Mögliche Werte sind Fehlerfrei, Beeinträchtigt und Fehlerhaft.
• Ursache: Gibt den Grund für den entsprechenden Status der Firewall an.

Wenn SNAT-Ports mehr als 95 % verwendet werden, werden sie als erschöpft betrachtet, und die Integrität beträgt 50 % mit status=Degraded and reason=SNAT port. Die Firewall verarbeitet weiterhin Datenverkehr, und vorhandene Verbindungen sind nicht betroffen. Neue Verbindungen können jedoch zeitweise nicht hergestellt werden.

Wenn die Auslastung von SNAT-Ports unter 95 % liegt, wird die Firewall als fehlerfrei angesehen, und für die Integrität wird „100 %“ angezeigt.

Wenn keine Auslastung von SNAT-Ports gemeldet wird, wird die Integrität als 0 % angezeigt.

SNAT-Portnutzung

Wenn Sie Ihrer Firewall weitere öffentliche IP-Adressen hinzufügen, stehen für die SNAT-Portauslastungsmetrik weitere SNAT-Ports zur Verfügung, wodurch die SNAT-Portauslastung reduziert wird. Wenn die Firewall aus unterschiedlichen Gründen (z. B. CPU oder Durchsatz) skaliert wird, sind auch weitere SNAT-Ports verfügbar.

Effektiv geht ein bestimmter Prozentsatz der SNAT-Portsauslastung möglicherweise herunter, ohne dass Sie öffentliche IP-Adressen hinzufügen, nur weil der Dienst skaliert wurde. Sie können die Anzahl der verfügbaren öffentlichen IP-Adressen direkt steuern, um die verfügbaren Ports in Ihrer Firewall zu erhöhen. Die Firewallskalierung können Sie jedoch nicht direkt steuern.

Wenn Ihre Firewall in SNAT-Portausschöpfung ausgeführt wird, sollten Sie mindestens fünf öffentliche IP-Adressen hinzufügen. Dadurch wird die Anzahl der verfügbaren SNAT-Ports erhöht. Weitere Informationen finden Sie unter Azure Firewall-Features.

AZFW-Latenzsonde

Die Metrik AZFW Latency Probe misst die gesamt- oder durchschnittliche Latenz von Azure Firewall in Millisekunden. Administrator*innen können diese Metrik für folgende Zwecke verwenden:

• Diagnostizieren, ob Azure Firewall Latenz im Netzwerk verursacht
• Überwachen und Benachrichtigen auf Latenz- oder Leistungsprobleme, sodass IT-Teams proaktiv interagieren können
• Identifizieren sie verschiedene Faktoren, die eine hohe Latenz in azure Firewall verursachen können, z. B. hohe CPU-Auslastung, hoher Durchsatz oder Netzwerkprobleme

Was die Metrik "AZFW Latency Probe" misst

• Maßnahmen: Die Latenz von Azure Firewall innerhalb der Azure-Plattform
• Misst nicht: End-to-End-Latenz für den gesamten Netzwerkpfad. Die Metrik spiegelt die Leistung innerhalb der Firewall und nicht die Latenz der Azure-Firewall wider, die in das Netzwerk eingeführt wird.
• Fehlerberichterstattung: Wenn die Latenzmetrik nicht ordnungsgemäß funktioniert, meldet sie einen Wert von 0 im Metrikdashboard, der einen Prüfpunktfehler oder eine Unterbrechung angibt.

Faktoren, die sich auf die Latenz auswirken

Mehrere Faktoren können sich auf die Firewalllatenz auswirken:

• Hohe CPU-Auslastung
• Hoher Durchsatz oder Datenverkehr
• Netzwerkprobleme innerhalb der Azure-Plattform

Latenzsonden: Von ICMP zu TCP

Die Latenzsonde verwendet derzeit die Ping Mesh-Technologie von Microsoft, die auf ICMP (Internet Control Message Protocol) basiert. ICMP eignet sich für schnelle Integritätsprüfungen, z. B. Pinganforderungen, stellt jedoch möglicherweise keinen echten Anwendungsdatenverkehr dar, der in der Regel auf TCP basiert. ICMP-Probes priorisieren jedoch auf der Azure-Plattform unterschiedlich, was zu einer Variation zwischen SKUs führen kann. Um diese Diskrepanzen zu verringern, plant Azure Firewall den Übergang zu TCP-basierten Probes.

Wichtige Überlegungen:

• Latenzspitzen: Bei ICMP-Sonden sind intermittierende Spitzen normal und Teil des Standardverhaltens des Hostnetzwerks. Interpretieren Sie diese Spitzen nicht als Firewallprobleme, es sei denn, sie bleiben erhalten.
• Durchschnittliche Latenz: Im Durchschnitt reicht die Azure Firewall-Latenz von 1 ms bis 10 ms, je nach Firewall-SKU und Bereitstellungsgröße.

Bewährte Methoden für die Überwachung der Latenz

• Legen Sie einen Basisplan fest: Richten Sie eine Latenzbasislinie unter lichtem Datenverkehr für genaue Vergleiche bei normaler oder Spitzenauslastung ein.

  Hinweis

  Wenn Sie Ihren Basisplan einrichten, erwarten Sie gelegentliche Metrikspitzen aufgrund neuer Infrastrukturänderungen. Diese temporären Spitzen sind normal und führen zu Metrikberichtsanpassungen, nicht zu tatsächlichen Problemen. Senden Sie nur eine Supportanfrage, wenn Spitzen im Laufe der Zeit beibehalten werden.

• Überwachen auf Muster: Erwarten Sie gelegentliche Latenzspitzen als Teil normaler Vorgänge. Wenn eine hohe Latenz über diese normalen Variationen hinaus besteht, kann es auf ein tieferes Problem hinweisen, das eine Untersuchung erfordert.

• Empfohlener Latenzschwellenwert: Eine empfohlene Richtlinie besteht darin, dass die Latenz 3x der Basislinie nicht überschreiten sollte. Wenn dieser Schwellenwert überschritten wird, wird eine weitere Untersuchung empfohlen.

• Überprüfen Sie den Regelgrenzwert: Stellen Sie sicher, dass sich die Netzwerkregeln innerhalb des 20K-Regellimits befinden. Das Überschreiten dieses Grenzwerts kann sich auf die Leistung auswirken.

• Neues Anwendungs-Onboarding: Überprüfen Sie alle neu integrierten Anwendungen, die erhebliche Lasten hinzufügen oder Latenzprobleme verursachen könnten.

• Supportanfrage: Wenn Sie eine kontinuierliche Latenzbeeinträchtigung beobachten, die nicht mit dem erwarteten Verhalten übereinstimmt, sollten Sie ein Supportticket für weitere Unterstützung einreichen.

  

Metrikdimensionen

Informationen darüber, was metrische Dimensionen sind, finden Sie unter Mehrdimensionale Metriken.

Bei diesem Dienst gelten die folgenden Dimensionen für die zugehörigen Metriken.

• Protokoll
• Ursache
• Der Status

Ressourcenprotokolle

In diesem Abschnitt werden die Ressourcenprotokolltypen aufgeführt, die für diesen Service erfasst werden können. Der Abschnitt wird aus der Liste aller in Azure Monitor unterstützten Kategorietypen für Ressourcenprotokolle gezogen.

Unterstützte Ressourcenprotokolle für Microsoft.Network/azureFirewalls

DNS-Ablaufverfolgungsprotokolle

Die DNS-Ablaufablaufverfolgungsprotokolle bieten tiefere Einblicke in DNS-Aktivitäten und helfen Administratoren bei der Behebung von Problemen und der Überprüfung des Datenverkehrsverhaltens.

Zuvor war die DNS-Proxyprotokollierung auf Folgendes beschränkt:

• AZFWDNSQuery – die erste Clientabfrage
• AZFWInternalFqdnResolutionFailure - FQDN-Auflösungsfehler

Mit den DNS-Ablaufablaufablaufprotokollen können Administratoren den vollständigen DNS-Auflösungsfluss von der Clientabfrage über azure Firewall als DNS-Proxy bis zum externen DNS-Server und zurück zum Client nachverfolgen.

DNS-Auflösungsstufen

Die Protokolle erfassen die folgenden Phasen:

1. Clientabfrage: Die vom Client gesendete anfängliche DNS-Abfrage
2. Weiterleitungsabfrage: Azure Firewall leitet die Abfrage an einen externen DNS-Server weiter (wenn nicht zwischengespeichert)
3. Weiterleitungsantwort: Die Antwort des DNS-Servers auf die Azure Firewall
4. Clientantwort: Die endgültige aufgelöste Antwort von Azure Firewall zurück an den Client

Das folgende Diagramm zeigt eine allgemeine visuelle Darstellung des DNS-Abfrageflusses:

Diese Protokolle bieten wertvolle Einblicke, z. B.:

• Der abgefragte DNS-Server
• Aufgelöste IP-Adressen
• Gibt an, ob der Azure Firewall-Cache verwendet wurde.

Aktivieren von DNS-Ablaufablaufablaufprotokollen

Vor dem Einrichten von DNS-Ablaufablaufablaufprotokollen müssen Sie das Feature zuerst mit Azure PowerShell aktivieren.

Aktivieren von Protokollen (Voraussetzung)

Führen Sie die folgenden Befehle in Azure PowerShell aus, und ersetzen Sie Platzhalter durch Ihre Werte:

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

Protokolle deaktivieren (optional)

Verwenden Sie zum Deaktivieren der Protokolle denselben vorherigen Azure PowerShell-Befehl, und legen Sie den Wert auf "False" fest:

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

Konfigurieren von DNS-Proxy- und DNS-Ablaufablaufprotokollen

Führen Sie die folgenden Schritte aus, um DNS-Proxy zu konfigurieren und DNS-Ablaufverfolgungsprotokolle zu aktivieren:

1. DNS-Proxy aktivieren:

   1. Navigieren Sie zu den DNS-Einstellungen der Azure Firewall, und aktivieren Sie den DNS-Proxy.
   2. Konfigurieren Sie einen benutzerdefinierten DNS-Server, oder verwenden Sie den Standardmäßigen Azure DNS.
   3. Navigieren Sie zu den DNS-Einstellungen des virtuellen Netzwerks, und legen Sie die private IP der Firewall als primären DNS-Server fest.

2. Aktivieren von DNS-Ablaufablaufüberwachungsprotokollen:

   1. Navigieren Sie im Azure-Portal zu Azure Firewall.
   2. Wählen Sie "Diagnoseeinstellungen " unter "Überwachung" aus.
   3. Wählen Sie eine vorhandene Diagnoseeinstellung aus, oder erstellen Sie eine neue.
   4. Wählen Sie im Abschnitt "Protokoll " die Option "DNS Flow Trace Logs" aus.
   5. Wählen Sie Ihr gewünschtes Ziel (Log Analytics oder Storage Account).

   Hinweis

   DNS Flow Trace Logs werden mit Event Hub als Ziel nicht unterstützt.

   6. Speichern Sie die Einstellungen.

3. Testen der Konfiguration:

   1. Generieren Sie DNS-Abfragen von Clients, und überprüfen Sie die Protokolle im ausgewählten Ziel.

Grundlegendes zu den Protokollen

Jeder Protokolleintrag entspricht einer bestimmten Phase im DNS-Auflösungsprozess. In der folgenden Tabelle werden die Protokolltypen und Schlüsselfelder beschrieben:

Die obigen Felder sind nur eine Teilmenge der verfügbaren Felder in jedem Protokolleintrag.

Wichtige Hinweise:

• Wenn der DNS-Cache verwendet wird, werden nur Clientabfrage - und Clientantworteinträge generiert.
• Protokolle umfassen Standardmetadaten wie Zeitstempel, Quell-/Ziel-IPs, Protokolle und DNS-Nachrichteninhalte.
• Um übermäßiges Protokollvolumen in Umgebungen mit vielen kurzlebigen Abfragen zu vermeiden, aktivieren Sie zusätzliche DNS-Proxyprotokolle nur, wenn eine tiefere DNS-Problembehandlung erforderlich ist.

Wichtigste Flows

Das Protokoll der obersten Flüsse ist in der Branche als Fettflussprotokoll und in der vorherigen Tabelle als Azure Firewall Fat Flow Log bekannt. Das Protokoll der obersten Flüsse zeigt die wichtigsten Verbindungen an, die zum höchsten Durchsatz über die Firewall beitragen.

Die Flussrate wird als Datenübertragungsrate in Megabits pro Sekunde definiert. Es ist ein Maß für die Menge digitaler Daten, die über ein Netzwerk in einem bestimmten Zeitraum über die Firewall übertragen werden können. Das Protokoll der wichtigsten Flows wird in regelmäßigen Abständen alle drei Minuten ausgeführt. Der Mindestschwellenwert für die Einstufung als wichtigster Flow beträgt 1 MBit/s.

Aktivieren von Protokollen mit den wichtigsten Flüssen

Verwenden Sie die folgenden Azure PowerShell-Befehle, um Top-Flows-Protokolle zu aktivieren:

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

Deaktivieren der Protokolle der häufigsten Flüsse

Um die Protokolle zu deaktivieren, verwenden Sie denselben Azure PowerShell-Befehl, und legen Sie den Wert auf "False" fest. Zum Beispiel:

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

Überprüfen der Konfiguration

Es gibt mehrere Möglichkeiten, um zu überprüfen, ob das Update erfolgreich war. Navigieren Sie zur Firewallübersicht , und wählen Sie die JSON-Ansicht in der oberen rechten Ecke aus. Ein Beispiel:

Informationen zum Erstellen einer Diagnoseeinstellung und zum Aktivieren der ressourcenspezifischen Tabelle finden Sie unter Erstellen von Diagnoseeinstellungen in Azure Monitor.

Flow-Ablaufverfolgung

Die Firewallprotokolle zeigen den Datenverkehr über die Firewall im ersten Versuch einer TCP-Verbindung an, die als SYN-Paket bezeichnet wird. Ein solcher Eintrag zeigt jedoch nicht die vollständige Reise des Pakets im TCP-Handshake an. Daher ist es schwierig, probleme zu beheben, wenn ein Paket verworfen oder asymmetrisches Routing erfolgt ist. Das Azure Firewall Flow Trace Log behandelt dieses Problem.

Ablaufablaufablaufverfolgungseigenschaften

Die folgenden Eigenschaften können hinzugefügt werden:

• SYN-ACK: ACK-Flag, das die Bestätigung des SYN-Pakets angibt.

• FIN: Die Kennzeichnung des ursprünglichen Paketflusses wurde abgeschlossen. Im TCP-Flow werden keine weiteren Daten übertragen.

• FIN-ACK: ACK-Flag, das die Bestätigung des FIN-Pakets angibt.

• RST: Das Flag "Zurücksetzen" gibt an, dass der ursprüngliche Absender keine weiteren Daten empfängt.

• INVALID (Flows): Gibt an, dass das Paket nicht identifiziert werden kann oder keinen Zustand aufweist.

  Zum Beispiel:

  • Ein TCP-Paket landet auf einer Virtual Machine Scale Sets-Instanz, die keinen vorherigen Verlauf für dieses Paket hat
  • Fehlerhafte CheckSum-Pakete
  • Der Tabelleneintrag für die Verbindungsnachverfolgung ist voll, und neue Verbindungen können nicht akzeptiert werden
  • Übermäßig verzögerte ACK-Pakete

Ablaufablaufablaufverfolgungsprotokolle aktivieren

Verwenden Sie die folgenden Azure PowerShell-Befehle, um Ablaufverfolgungsprotokolle zu aktivieren. Alternativ können Sie im Portal navigieren und nach "TCP-Verbindungsprotokollierung aktivieren" suchen:

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

Es kann mehrere Minuten dauern, bis diese Änderung wirksam wird. Nach Registrierung des Features sollten Sie eine Aktualisierung von Azure Firewall in Betracht ziehen, damit die Änderung sofort wirksam wird.

Überprüfen des Registrierungsstatus

Führen Sie den folgenden Azure PowerShell-Befehl aus, um den Status der AzResourceProvider-Registrierung zu überprüfen:

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

Ablaufablaufverfolgungsprotokolle deaktivieren

Verwenden Sie zum Deaktivieren des Protokolls die folgenden Azure PowerShell-Befehle:

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

Informationen zum Erstellen einer Diagnoseeinstellung und zum Aktivieren der ressourcenspezifischen Tabelle finden Sie unter Erstellen von Diagnoseeinstellungen in Azure Monitor.

Tabellen in Azure Monitor-Protokollen

Dieser Abschnitt bezieht sich die für diesen Service relevanten Azure-Monitor-Protokolltabellen, die für die Abfrage durch Protokollanalyse mit Kusto-Abfragen zur Verfügung stehen. Diese Tabellen enthalten Ressourcenprotokolldaten und möglicherweise mehr, je nachdem, was erfasst und an sie weitergeleitet wird.

Azure Firewall Microsoft.Network/azureFirewalls

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

Aktivitätsprotokoll

In der verknüpften Tabelle sind die Vorgänge aufgeführt, die im Aktivitätsprotokoll für diesen Dienst aufgezeichnet werden können. Diese Operationen sind eine Teilmenge aller möglichen Ressourcenanbietervorgänge im Aktivitätsprotokoll.

Weitere Informationen zum Schema von Aktivitätsprotokolleinträgen finden Sie unter Ereignisschema des Azure-Aktivitätsprotokolls.

• Netzwerkressourcenanbietervorgänge

Zugehöriger Inhalt

• Eine Beschreibung der Überwachung der Azure-Firewall finden Sie unter Überwachen der Azure-Firewall .
• Informationen zu detaillierten Azure Resource Graph-Abfragen zum Nachverfolgen von Firewallregeländerungen finden Sie unter "Nachverfolgen von Regelsatzänderungen nachverfolgen".
• Weitere Informationen zur Überwachung von Azure-Ressourcen finden Sie unter Überwachen von Azure-Ressourcen mit Azure Monitor.