Partager via


informations de référence sur les données de surveillance Pare-feu Azure

Cet article contient toutes les informations de référence de surveillance pour ce service.

Consultez surveiller Pare-feu Azure pour plus d’informations sur les données que vous pouvez collecter pour Pare-feu Azure et comment l’utiliser.

Metrics

Cette section répertorie toutes les métriques de plateforme collectées automatiquement pour App Service. Ces métriques font également partie de la liste globale de toutes les métriques de plateforme prises en charge dans Azure Monitor.

Pour plus d’informations sur les métriques de surveillance, consultez la section Présentation des métriques Azure Monitor.

Métriques prises en charge pour Microsoft.Network/azureFirewalls

Le tableau suivant répertorie les métriques disponibles pour le type de ressource Microsoft.Network/azureFirewalls.

  • Toutes les colonnes peuvent ne pas être présentes dans chaque table.
  • Certaines colonnes peuvent dépasser la zone d’affichage de la page. Select Expand table to view all available columns.

Table headings

  • Category - The metrics group or classification.
  • Metric - The metric display name as it appears in the Azure portal.
  • Nom dans l’API REST : le nom de la métrique comme appelé dans l’API REST.
  • Unit - Unit of measure.
  • Aggregation - The default aggregation type. Valeurs valides : Moyen (moy), Minimum (min), Maximum (max), Total (somme), Nombre.
  • Dimensions - Dimensions available for the metric.
  • Time Grains - Intervals at which the metric is sampled. Par exemple, PT1M indique que la métrique est échantillonnée toutes les minutes, PT30M toutes les 30 minutes, PT1H toutes les heures, et ainsi de suite.
  • DS Export- Whether the metric is exportable to Azure Monitor Logs via diagnostic settings. Pour plus d’informations sur l’exportation des métriques, consultez Créer des paramètres de diagnostic dans Azure Monitor.
Metric Nom dans l’API REST Unit Aggregation Dimensions Time Grains DS Export
Nombre d’accès aux règles d’application

Nombre d'accès aux règles d'application
ApplicationRuleHit Count Total (Sum) Status, , ReasonProtocol PT1M Yes
Data processed

Volume total de données traitées par ce pare-feu
DataProcessed Bytes Total (Sum) <aucune> PT1M Yes
État d’intégrité du pare-feu

Intégrité globale de ce pare-feu
FirewallHealth Percent Average Status, Reason PT1M Yes
Latency Probe

Estimation de la latence moyenne du pare-feu mesurée par la sonde de latence
FirewallLatencyPng Milliseconds Average <aucune> PT1M Yes
Nombre d’accès aux règles réseau

Nombre d’accès aux règles de réseau
NetworkRuleHit Count Total (Sum) Status, , ReasonProtocol PT1M Yes
Utilisation du port SNAT

Pourcentage de ports SNAT sortants en cours d’utilisation
SNATPortUtilization Percent Average, Maximum Protocol PT1M Yes
Throughput

Débit traité par ce pare-feu
Throughput BitsPerSecond Average <aucune> PT1M No

État d’intégrité du pare-feu

Dans le tableau précédent, la métrique d’état d’intégrité du pare-feu a deux dimensions :

  • Status: Possible values are Healthy, Degraded, Unhealthy.
  • Motif : indique la raison de l’état correspondant du pare-feu.

If SNAT ports are used more than 95%, they're considered exhausted and the health is 50% with status=Degraded and reason=SNAT port. Le pare-feu continue à traiter le trafic et les connexions existantes ne sont pas affectées. Toutefois, de nouvelles connexions peuvent ne pas être établies par intermittence.

Si les ports SNAT sont utilisés à moins de 95 %, le pare-feu est considéré comme sain et l’intégrité est affichée à 100 %.

Si aucune utilisation des ports SNAT n'est signalée, l'intégrité est affichée à 0 %.

Utilisation des ports SNAT

Pour la métrique d’utilisation du port SNAT, lorsque vous ajoutez d’autres adresses IP publiques à votre pare-feu, davantage de ports SNAT sont disponibles, ce qui réduit l’utilisation des ports SNAT. En outre, lorsque le pare-feu augmente pour différentes raisons (par exemple, le processeur ou le débit) plus de ports SNAT deviennent également disponibles.

En fait, un pourcentage donné d’utilisation des ports SNAT peut diminuer sans ajouter d’adresses IP publiques, simplement parce que le service a été mis à l’échelle. Vous pouvez contrôler directement le nombre d’adresses IP publiques disponibles pour augmenter les ports disponibles sur votre pare-feu. Toutefois, vous ne pouvez pas contrôler directement la mise à l’échelle du pare-feu.

Si votre pare-feu épuise les ports SNAT, vous devez ajouter au moins cinq adresses IP publiques. Cela augmente le nombre de ports SNAT disponibles. Pour plus d’informations, consultez Fonctionnalités du Pare-feu Azure.

Sonde de latence AZFW

La métrique de la sonde de latence AZFW mesure la latence globale ou moyenne de Pare-feu Azure en millisecondes. Les administrateurs peuvent se servir de cette métrique aux fins suivantes :

  • Diagnostiquez si le Pare-feu Azure est à l’origine de la latence dans le réseau
  • Surveillez et alertez en cas de problèmes de latence ou de niveau de performance, afin que les équipes informatiques puissent agir de manière proactive.
  • Il peut y avoir différentes raisons qui peuvent entraîner une latence élevée dans Pare-feu Azure. Par exemple, une utilisation élevée du processeur, un débit élevé ou un possible problème de mise en réseau.

Quelles sont les mesures de métriques de la sonde de latence AZFW (et non) :

  • Ce qu’il mesure : latence du Pare-feu Azure au sein de la plateforme Azure
  • Ce qu’elle ne mesure pas : la métrique ne capture pas la latence de bout en bout pour l’ensemble du chemin réseau. Au lieu de cela, elle reflète les performances au sein du pare-feu, plutôt que la latence Pare-feu Azure introduit dans le réseau.
  • Rapport d’erreurs : si la métrique de latence ne fonctionne pas correctement, elle signale une valeur de 0 dans le tableau de bord des métriques, indiquant une défaillance ou une interruption de la sonde.

Facteurs qui ont un impact sur la latence :

  • Utilisation élevée du processeur
  • Débit élevé ou charge du trafic
  • Problèmes de mise en réseau au sein de la plateforme Azure

Sondes de latence : de ICMP à TCP La sonde de latence utilise actuellement la technologie Ping Mesh de Microsoft, basée sur ICMP (Internet Control Message Protocol). ICMP convient aux contrôles d’intégrité rapides, tels que les requêtes ping, mais il peut ne pas représenter avec précision le trafic d’application réel, qui relit généralement sur TCP. Toutefois, les sondes ICMP hiérarchisent différemment sur la plateforme Azure, ce qui peut entraîner des variations entre les références SKU. Pour réduire ces différences, Pare-feu Azure prévoit de passer à des sondes TCP.

  • Pics de latence : avec les sondes ICMP, les pics intermittents sont normaux et font partie du comportement standard du réseau hôte. Ces problèmes ne doivent pas être mal interprétés comme des problèmes de pare-feu, sauf s’ils sont persistants.
  • Latence moyenne : en moyenne, la latence d’Pare-feu Azure est censée être comprise entre 1ms et 10 ms, selon la référence SKU et la taille du déploiement du pare-feu.

Meilleures pratiques pour la surveillance de la latence

  • Définir une base de référence : établissez une ligne de base de latence dans des conditions de trafic léger pour des comparaisons précises pendant une utilisation normale ou maximale.

    Note

    Lors de l’établissement de votre base de référence, attendez-vous à des pics de métriques occasionnels en raison de modifications récentes de l’infrastructure. Ces pics temporaires sont normaux et résultent des ajustements des rapports de métriques, et non des problèmes réels. Envoyez uniquement une demande de support si les pics persistent au fil du temps.

  • Surveiller les modèles : attendez des pics de latence occasionnels dans le cadre d’opérations normales. Si une latence élevée persiste au-delà de ces variations normales, cela peut indiquer un problème plus approfondi nécessitant une investigation.

  • Seuil de latence recommandé : une recommandation est que la latence ne doit pas dépasser 3x la ligne de base. Si ce seuil est franchi, une enquête supplémentaire est recommandée.

  • Vérifiez la limite de règle : vérifiez que les règles réseau se trouvent dans la limite de la règle 20K. Le dépassement de cette limite peut affecter les performances.

  • Nouvelle intégration d’applications : recherchez toutes les applications nouvellement intégrées susceptibles d’ajouter une charge importante ou de provoquer des problèmes de latence.

  • Demande de support : si vous observez une dégradation continue de la latence qui ne s’aligne pas sur le comportement attendu, envisagez de déposer un ticket de support pour obtenir une assistance supplémentaire.

    Capture d’écran montrant la métrique de la sonde de latence du pare-feu Azure.

Metric dimensions

For information about what metric dimensions are, see Multi-dimensional metrics.

Ce service a les dimensions suivantes associées à ses métriques.

  • Protocol
  • Reason
  • Status

Resource logs

Cette section répertorie les types de journaux d’activité de ressources que vous pouvez collecter pour ce service. La section extrait la liste de tous les types de catégorie de journaux d’activité de ressources pris en charge dans Azure Monitor.

Journaux de ressources pris en charge pour Microsoft.Network/azureFirewalls

Category Nom complet de la catégorie Log table Prend en charge le plan de journal de base Prend en charge la transformation de la durée d’ingestion Example queries Coûts d’exportation
AZFWApplicationRule Règle d’application de pare-feu Azure AZFWApplicationRule

Contient toutes les données du journal des règles d’application. Chaque correspondance entre le plan de données et la règle d’application crée une entrée de journal avec le paquet de plan de données et les attributs de la règle mise en correspondance.

Yes Yes Queries Yes
AZFWApplicationRuleAggregation Agrégation des règles réseau du Pare-feu Azure (analytique de la stratégie) AZFWApplicationRuleAggregation

Contient des données agrégées du journal des règles d’application pour Policy Analytics.

Yes Yes Yes
AZFWDnsQuery Pare-feu Azure - Requête DNS AZFWDnsQuery

Contient toutes les données du journal des événements du proxy DNS.

Yes Yes Queries Yes
AZFWFatFlow Pare-feu Azure - Journal FAT des flux AZFWFatFlow

Cette requête retourne les principaux flux entre les instances du Pare-feu Azure. Le journal contient des informations de flux, un taux de transmission de date (en mégabits par seconde) et la période pendant laquelle les flux ont été enregistrés. Suivez la documentation pour activer la journalisation des flux principaux et des détails sur la façon dont il est enregistré.

Yes Yes Queries Yes
AZFWFlowTrace Pare-feu Azure - Journal des traces de flux AZFWFlowTrace

Flux des journaux sur les instances de pare-feu Azure. Le journal contient des informations de flux, des indicateurs et la période pendant laquelle les flux ont été enregistrés. Suivez la documentation pour activer la journalisation des traces de flux et des détails sur son enregistrement.

Yes Yes Queries Yes
AZFWFqdnResolveFailure Pare-feu Azure - Échec de la résolution FQDN No Yes Yes
AZFWIdpsSignature Pare-feu Azure - Signature IDPS AZFWIdpsSignature

Contient tous les paquets de plan de données qui ont été mis en correspondance avec une ou plusieurs signatures IDPS.

Yes Yes Queries Yes
AZFWNatRule Pare-feu Azure - Règle NAT AZFWNatRule

Contient toutes les données du journal des événements DNAT (Traduction d’adresses réseau de destination). Chaque correspondance entre le plan de données et la règle DNAT crée une entrée de journal avec le paquet de plan de données et les attributs de la règle mise en correspondance.

Yes Yes Queries Yes
AZFWNatRuleAggregation Pare-feu Azure - Agrégation des règles NAT (analytique de la stratégie) AZFWNatRuleAggregation

Contient des données de journal de règle NAT agrégées pour Policy Analytics.

Yes Yes Yes
AZFWNetworkRule Règle de réseau de pare-feu Azure AZFWNetworkRule

Contient toutes les données du journal des règles de réseau. Chaque correspondance entre le plan de données et la règle réseau crée une entrée de journal avec le paquet de plan de données et les attributs de la règle mise en correspondance.

Yes Yes Queries Yes
AZFWNetworkRuleAggregation Pare-feu Azure - Agrégation des règles d’application (analytique de la stratégie) AZFWNetworkRuleAggregation

Contient des données de journal des règles réseau agrégées pour Policy Analytics.

Yes Yes Yes
AZFWThreatIntel Pare-feu Azure - Threat Intelligence AZFWThreatIntel

Contient tous les événements Threat Intelligence.

Yes Yes Queries Yes
AzureFirewallApplicationRule Pare-feu Azure - Règle d’application (diagnostics Azure hérités) AzureDiagnostics

Journaux d’activité de plusieurs ressources Azure.

No No Queries No
AzureFirewallDnsProxy Pare-feu Azure - Proxy DNS (diagnostics Azure hérités) AzureDiagnostics

Journaux d’activité de plusieurs ressources Azure.

No No Queries No
AzureFirewallNetworkRule Pare-feu Azure - Règle réseau (diagnostics Azure hérités) AzureDiagnostics

Journaux d’activité de plusieurs ressources Azure.

No No Queries No

Pare-feu Azure a deux nouveaux journaux de diagnostic qui peuvent aider à surveiller votre pare-feu, mais ces journaux n’affichent actuellement pas les détails de la règle d’application.

  • Top flows
  • Flow trace

Top flows

Le journal des flux principaux est connu dans le secteur comme journal des flux de graisse et dans le tableau précédent comme Pare-feu Azure journal de flux de graisse. Le journal des flux principaux affiche les connexions principales qui contribuent au débit le plus élevé via le pare-feu.

Tip

Activez les journaux top flows uniquement lors de la résolution d’un problème spécifique afin d’éviter une utilisation excessive du processeur de Pare-feu Azure.

Le débit de flux est défini comme le taux de transmission de données en mégabits par seconde unités. Il s’agit d’une mesure de la quantité de données numériques qui peuvent être transmises sur un réseau pendant une période de temps via le pare-feu. Le protocole Flux principaux s’exécute régulièrement toutes les trois minutes. Le seuil minimal à considérer comme un flux supérieur est de 1 Mbits/s.

Activez le journal des flux principaux à l’aide des commandes Azure PowerShell suivantes :

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

To disable the logs, use the same previous Azure PowerShell command and set the value to False.

For example:

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

There are a few ways to verify the update was successful, but you can navigate to firewall Overview and select JSON view on the top right corner. Voici un exemple :

Capture d’écran de JSON montrant la vérification supplémentaire du journal.

Pour créer un paramètre de diagnostic et activer une table spécifique à la ressource, consultez Créer des paramètres de diagnostic dans Azure Monitor.

Flow trace

The firewall logs show traffic through the firewall in the first attempt of a TCP connection, known as the SYN packet. Toutefois, une telle entrée n’affiche pas le parcours complet du paquet dans l’établissement d’une liaison TCP. Par conséquent, il est difficile de résoudre les problèmes si un paquet est supprimé ou si un routage asymétrique s’est produit. Le journal de trace de flux Pare-feu Azure répond à ce problème.

Tip

Pour éviter une utilisation excessive du disque causée par les journaux de suivi Flow dans Pare-feu Azure avec de nombreuses connexions de courte durée, activez les journaux uniquement lors de la résolution d’un problème spécifique à des fins de diagnostic.

Les propriétés suivantes peuvent être ajoutées :

  • SYN-ACK : indicateur ACK qui indique l’accusé de réception du paquet SYN.

  • FIN : indicateur terminé du flux de paquets d’origine. Plus aucune donnée n’est transmise dans le flux TCP.

  • FIN-ACK : indicateur ACK qui indique l’accusé de réception du paquet FIN.

  • RST : La réinitialisation de l’indicateur indique que l’expéditeur d’origine ne reçoit pas plus de données.

  • NON VALIDE (flux) : indique que le paquet ne peut pas être identifié ou n’a pas d’état.

    For example:

    • Un paquet TCP atterrit sur une instance de groupe de machines virtuelles identiques, qui n'a pas d'historique pour ce paquet
    • Paquets de somme de contrôle incorrecte
    • L’entrée de la table suivi des connexions est complète et les nouvelles connexions ne peuvent pas être acceptées
    • Paquets ACK trop retardés

Activez le journal de suivi flow à l’aide des commandes Azure PowerShell suivantes ou naviguez dans le portail et recherchez Activer la journalisation des connexions TCP :

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

Cette modification peut prendre plusieurs minutes. Une fois la fonctionnalité inscrite, envisagez d’effectuer une mise à jour sur Pare-feu Azure pour que la modification prenne effet immédiatement.

Pour vérifier l’état de l’inscription AzResourceProvider, vous pouvez exécuter la commande Azure PowerShell :

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

Pour désactiver le journal, vous pouvez le désenregistrer à l'aide de la commande suivante ou sélectionner désenregistrer dans l'exemple du portail précédent.

Unregister-AzProviderFeature -FeatureName AFWEnableTcpConnectionLogging -ProviderNamespace Microsoft.Network

Pour créer un paramètre de diagnostic et activer une table spécifique à la ressource, consultez Créer des paramètres de diagnostic dans Azure Monitor.

Tables Azure Monitor Logs

Cette section répertorie les tables de journaux Azure Monitor pertinentes pour ce service, disponibles pour une requête par l’analytique des journaux d’activité à l’aide de requêtes Kusto. Les tables contiennent les données du journal des ressources et éventuellement d’autres données en fonction de ce qui est collecté et acheminé vers elles.

Pare-feu Azure Microsoft.Network/azureFirewalls

Activity log

La table liée répertorie les opérations qui peuvent être enregistrées dans le journal d’activité de ce service. Ces opérations constituent un sous-ensemble de toutes les opérations possibles du fournisseur de ressources dans le journal d’activité.

Pour plus d’informations sur le schéma des entrées du journal d’activité, consultez Schéma du journal d’activité.