Freigeben über

Referenz zu Azure Firewall-Überwachungsdaten

  • Artikel

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.
Metrik Name in der REST-API Einheit Aggregation Dimensionen Aggregationsintervalle DS-Export
Anzahl der Anwendungsregeln

Häufigkeit, mit der Anwendungsregeln aufgerufen wurden		 ApplicationRuleHit Count Gesamt (Summe) Status, ReasonProtocol PT1M Ja
Verarbeitete Daten

Gesamtmenge der von dieser Firewall verarbeiteten Daten		 DataProcessed Byte Gesamt (Summe) <none> PT1M Ja
Integritätsstatus der Firewall

Gibt die Gesamtintegrität dieser Firewall an		 FirewallHealth Percent Average Status, Reason PT1M Ja
Latenzsonde

Schätzung der durchschnittlichen Latenz der Firewall, gemessen anhand des Latenztests		 FirewallLatencyPng Millisekunden Average <none> PT1M Ja
Anzahl der Netzwerkregeln

Häufigkeit, mit der Netzwerkregeln aufgerufen wurden		 NetworkRuleHit Count Gesamt (Summe) Status, ReasonProtocol PT1M Ja
SNAT-Portverwendung

Derzeit verwendete ausgehende SNAT-Ports in Prozent		 SNATPortUtilization Percent Mittelwert, Maximum Protocol PT1M Ja
Durchsatz

Von dieser Firewall verarbeiteter Durchsatz		 Throughput BitsPerSecond Average <none> PT1M No

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 bei der Firewall eine SNAT-Portauslastung auftritt, 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 die Ursache von Latenz im Netzwerk ist
  • Überwachen und warnen, wenn Latenz- oder Leistungsprobleme auftreten, sodass IT-Teams proaktiv interagieren können
  • Es kann verschiedene Gründe geben, die zu einer hohen Latenz in azure Firewall führen können. Beispielsweise eine hohe CPU-Auslastung, ein hoher Durchsatz oder ein mögliches Netzwerkproblem.

Was die AzFW-Latenzsonde metrisch misst (und nicht):

  • Was es misst: Die Latenz der Azure-Firewall innerhalb der Azure-Plattform
  • Was nicht gemessen wird: Die Metrik erfasst keine End-to-End-Latenz für den gesamten Netzwerkpfad. Stattdessen spiegelt sie die Leistung innerhalb der Firewall wider, anstatt wie viel Latenz die Azure Firewall in das Netzwerk einführt.
  • Fehlerberichterstattung: Wenn die Latenzmetrik nicht korrekt funktioniert, meldet sie im Metrikdashboard einen Wert von 0, der einen Prüfpunktfehler oder eine Unterbrechung angibt.

Faktoren, die sich auf die Latenz 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.

  • Latenzspitzen: Bei ICMP-Probes sind intermittierende Spitzen normal und Bestandteil des Standardverhaltens des Hostnetzwerks. Diese sollten nicht als Firewallprobleme falsch interpretiert werden, es sei denn, sie sind dauerhaft.
  • Durchschnittliche Latenz: Im Durchschnitt wird erwartet, dass die Latenz von Azure Firewall zwischen 1 ms und 10 ms liegt, 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.

  • Ü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 Verzögerung beobachten, die nicht mit dem erwarteten Verhalten übereinstimmt, sollten Sie ein Supportticket für weitere Unterstützung einreichen.

    Screenshot der Metrik „Azure Firewall Latency Probe“.

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
  • 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

Kategorie Anzeigename der Kategorie Protokolltabelle Unterstützt grundlegenden Protokollplan Unterstützt die Erfassungszeittransformation Beispielabfragen Exportkosten
AZFWApplicationRule Azure Firewall-Anwendungsregel AzureDiagnostics

Protokolle aus mehreren Azure-Ressourcen.

 No No Abfragen Ja
AZFWApplicationRuleAggregation Azure Firewall-Netzwerkregelaggregation (Richtlinienanalyse) AzureDiagnostics

Protokolle aus mehreren Azure-Ressourcen.

 No No Abfragen Ja
AZFWDnsQuery Azure Firewall-DNS-Abfrage AzureDiagnostics

Protokolle aus mehreren Azure-Ressourcen.

 No No Abfragen Ja
AZFWFatFlow Azure Firewall-FAT-Datenflussprotokoll AzureDiagnostics

Protokolle aus mehreren Azure-Ressourcen.

 No No Abfragen Ja
AZFWFlowTrace Azure Firewall-Flow-Ablaufverfolgungsprotokoll AzureDiagnostics

Protokolle aus mehreren Azure-Ressourcen.

 No No Abfragen Ja
AZFWFqdnResolveFailure Azure Firewall-FQDN-Auflösungsfehler AzureDiagnostics

Protokolle aus mehreren Azure-Ressourcen.

 No No Abfragen Ja
AZFWIdpsSignature Azure Firewall-IDPS-Signatur AzureDiagnostics

Protokolle aus mehreren Azure-Ressourcen.

 No No Abfragen Ja
AZFWNatRule Azure Firewall-NAT-Regel AzureDiagnostics

Protokolle aus mehreren Azure-Ressourcen.

 No No Abfragen Ja
AZFWNatRuleAggregation Azure Firewall-NAT-Regelaggregation (Richtlinienanalyse) AzureDiagnostics

Protokolle aus mehreren Azure-Ressourcen.

 No No Abfragen Ja
AZFWNetworkRule Azure Firewall-Netzwerkregel AzureDiagnostics

Protokolle aus mehreren Azure-Ressourcen.

 No No Abfragen Ja
AZFWNetworkRuleAggregation Azure Firewall-Anwendungsregelaggregation (Richtlinienanalyse) AzureDiagnostics

Protokolle aus mehreren Azure-Ressourcen.

 No No Abfragen Ja
AZFWThreatIntel Azure Firewall Threat Intelligence AzureDiagnostics

Protokolle aus mehreren Azure-Ressourcen.

 No No Abfragen Ja
AzureFirewallApplicationRule Azure Firewall-Anwendungsregel (Legacy-Azure-Diagnose) AzureDiagnostics

Protokolle aus mehreren Azure-Ressourcen.

 No No Abfragen No
AzureFirewallDnsProxy Azure Firewall-DNS-Proxy (Legacy-Azure-Diagnose) AzureDiagnostics

Protokolle aus mehreren Azure-Ressourcen.

 No No Abfragen No
AzureFirewallNetworkRule Azure Firewall-Netzwerkregel (Legacy-Azure-Diagnose) AzureDiagnostics

Protokolle aus mehreren Azure-Ressourcen.

 No No Abfragen No

Azure Firewall verfügt über zwei neue Diagnoseprotokolle, mit denen Ihre Firewall überwacht werden kann, aber diese Protokolle zeigen derzeit keine Anwendungsregeldetails an.

  • Wichtigste Flows
  • Flow-Ablaufverfolgung

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.

Tipp

Aktivieren Sie die Protokolle der wichtigsten Flows nur bei der Problembehandlung eines bestimmten Problems, um eine übermäßige CPU-Auslastung von Azure Firewall zu vermeiden.

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 Sie das Protokoll "Top flows" mithilfe der folgenden Azure PowerShell-Befehle:

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

Verwenden Sie zum Deaktivieren der Protokolle den gleichen vorherigen 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

Es gibt mehrere Möglichkeiten, um zu überprüfen, ob das Update erfolgreich war. Sie können jedoch zur Firewallübersicht navigieren und in der oberen rechten Ecke die JSON-Ansicht auswählen. Hier ist ein Beispiel angegeben:

Screenshot: JSON-Code mit zusätzlicher Protokollüberprüfung

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. Infolgedessen ist es schwierig, eine Fehlersuche durchzuführen, wenn ein Paket verworfen wurde oder ein asymmetrisches Routing aufgetreten ist. Das Azure Firewall Flow Trace Log behandelt dieses Problem.

Tipp

Um eine übermäßige Datenträgerauslastung durch Ablaufverfolgungsprotokolle in Azure Firewall mit vielen kurzlebigen Verbindungen zu vermeiden, aktivieren Sie die Protokolle nur zu Diagnosezwecken bei der Problembehandlung eines bestimmten Problems.

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

Aktivieren Sie das Ablaufverfolgungsprotokoll mithilfe der folgenden Azure PowerShell-Befehle, oder navigieren Sie im Portal, und suchen Sie nach "TCP-Verbindungsprotokollierung aktivieren":

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.

Um den Status der AzResourceProvider-Registrierung zu überprüfen, können Sie diesen Azure PowerShell-Befehl ausführen:

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

Um das Protokoll zu deaktivieren, können Sie die Registrierung mit dem folgenden Befehl aufheben oder im vorherigen Portalbeispiel „Registrierung aufheben“ auswählen.

Unregister-AzProviderFeature -FeatureName AFWEnableTcpConnectionLogging -ProviderNamespace Microsoft.Network

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

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.

Zugehöriger Inhalt