Partager via

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

  • Article

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.

Métriques

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. Sélectionnez Développer la table pour afficher toutes les colonnes disponibles.

Titres du tableau

  • Catégorie : le groupe de métriques ou classification.
  • Métrique : nom complet de la métrique tel qu’il apparaît dans le portail Azure.
  • Nom dans l’API REST : le nom de la métrique comme appelé dans l’API REST.
  • Unité : unité de mesure.
  • Agrégation : le type d’agrégation par défaut. Valeurs valides : Moyen (moy), Minimum (min), Maximum (max), Total (somme), Nombre.
  • Dimensions - Dimensions disponibles pour la métrique.
  • Fragments de temps - Intervalles auxquels la métrique est échantillonnée. 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.
  • Exportation DS : indique si la métrique est exportable vers les journaux Azure Monitor via les paramètres de diagnostic. Pour plus d’informations sur l’exportation des métriques, consultez Créer des paramètres de diagnostic dans Azure Monitor.
Mesure Nom dans l’API REST Unité Agrégation Dimensions Fragments de temps Exportation DS
Nombre d’accès aux règles d’application

Nombre d'accès aux règles d'application		 ApplicationRuleHit Count Total (Somme) Status, , ReasonProtocol PT1M Oui
Données traitées

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

Intégrité globale de ce pare-feu		 FirewallHealth Pourcentage Average Status, Reason PT1M Oui
Sonde de latence

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

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

Pourcentage de ports SNAT sortants en cours d’utilisation		 SNATPortUtilization Pourcentage Moyenne, maximum Protocol PT1M Oui
Débit

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

É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 :

  • État : les valeurs possibles sont Sain, Détérioré, Non sain.
  • Motif : indique la raison de l’état correspondant du pare-feu.

Si les ports SNAT sont utilisés plus de 95 %, ils sont considérés comme épuisés et l’intégrité est de 50 % avec status=Détérioré et reason=Port SNAT. 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.

  • 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écomposition de latence continue 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.

Dimensions de métrique

Pour plus d’informations sur les dimensions de métrique, consultez Métriques multidimensionnelles.

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

  • Protocol
  • Motif
  • État

Journaux d’activité de ressources

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 Table de journal Prend en charge le plan de journal de base Prend en charge la transformation de la durée d’ingestion Exemples de requêtes Coûts d’exportation
AZFWApplicationRule Règle d’application de pare-feu Azure AzureDiagnostics

Journaux d’activité de plusieurs ressources Azure.

 Non Non Requêtes Oui
AZFWApplicationRuleAggregation Agrégation des règles réseau du Pare-feu Azure (analytique de la stratégie) AzureDiagnostics

Journaux d’activité de plusieurs ressources Azure.

 Non Non Requêtes Oui
AZFWDnsQuery Pare-feu Azure - Requête DNS AzureDiagnostics

Journaux d’activité de plusieurs ressources Azure.

 Non Non Requêtes Oui
AZFWFatFlow Pare-feu Azure - Journal FAT des flux AzureDiagnostics

Journaux d’activité de plusieurs ressources Azure.

 Non Non Requêtes Oui
AZFWFlowTrace Pare-feu Azure - Journal des traces de flux AzureDiagnostics

Journaux d’activité de plusieurs ressources Azure.

 Non Non Requêtes Oui
AZFWFqdnResolveFailure Pare-feu Azure - Échec de la résolution FQDN AzureDiagnostics

Journaux d’activité de plusieurs ressources Azure.

 Non Non Requêtes Oui
AZFWIdpsSignature Pare-feu Azure - Signature IDPS AzureDiagnostics

Journaux d’activité de plusieurs ressources Azure.

 Non Non Requêtes Oui
AZFWNatRule Pare-feu Azure - Règle NAT AzureDiagnostics

Journaux d’activité de plusieurs ressources Azure.

 Non Non Requêtes Oui
AZFWNatRuleAggregation Pare-feu Azure - Agrégation des règles NAT (analytique de la stratégie) AzureDiagnostics

Journaux d’activité de plusieurs ressources Azure.

 Non Non Requêtes Oui
AZFWNetworkRule Règle de réseau de pare-feu Azure AzureDiagnostics

Journaux d’activité de plusieurs ressources Azure.

 Non Non Requêtes Oui
AZFWNetworkRuleAggregation Pare-feu Azure - Agrégation des règles d’application (analytique de la stratégie) AzureDiagnostics

Journaux d’activité de plusieurs ressources Azure.

 Non Non Requêtes Oui
AZFWThreatIntel Pare-feu Azure - Threat Intelligence AzureDiagnostics

Journaux d’activité de plusieurs ressources Azure.

 Non Non Requêtes Oui
AzureFirewallApplicationRule Pare-feu Azure - Règle d’application (diagnostics Azure hérités) AzureDiagnostics

Journaux d’activité de plusieurs ressources Azure.

 Non Non Requêtes Non
AzureFirewallDnsProxy Pare-feu Azure - Proxy DNS (diagnostics Azure hérités) AzureDiagnostics

Journaux d’activité de plusieurs ressources Azure.

 Non Non Requêtes Non
AzureFirewallNetworkRule Pare-feu Azure - Règle réseau (diagnostics Azure hérités) AzureDiagnostics

Journaux d’activité de plusieurs ressources Azure.

 Non Non Requêtes Non

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.

  • Flux principaux
  • Trace de flux

Flux principaux

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.

Conseil

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

Pour désactiver les journaux, utilisez la même commande Azure PowerShell précédente et définissez la valeur sur Faux.

Par exemple :

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

Il existe plusieurs façons de vérifier que la mise à jour a réussi. Vous pouvez notamment accéder à la section Vue d’ensemble du pare-feu et sélectionner la vue JSON dans le coin supérieur droit. 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.

Trace de flux

Les journaux de pare-feu affichent le trafic via le pare-feu lors de la première tentative d’une connexion TCP, appelée paquet SYN . 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.

Conseil

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.

    Par exemple :

    • 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

Journal d’activité

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é.

Contenu connexe