Pare-feu Azure métriques et alertes
Les métriques dans Azure Monitor sont des valeurs numériques décrivant certains aspects d’un système à un moment donné. Les métriques sont collectées toutes les minutes et sont utiles pour les alertes, car elles peuvent être échantillonnées fréquemment. Une alerte peut être déclenchée rapidement avec une logique relativement simple.
Métriques de pare-feu
Les métriques suivantes sont disponibles pour le pare-feu Azure :
Nombre d’accès aux règles d’application : nombre de fois où une règle d’application a été respectée.
Nombre d’unité : nombre
Nombre d’accès aux réseau : nombre de fois où une règle réseau a été respectée.
Nombre d’unité : nombre
Données traitées : somme des données qui traversent le pare-feu dans une fenêtre temporelle donnée.
Unité : octets
Débit : nombre de données traversant le pare-feu par seconde.
Unité : bits par seconde
État d'intégrité du pare-feu : indique l'intégrité du pare-feu en fonction de la disponibilité du port SNAT.
Unité : pourcentage
Cette métrique 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 à > de 95 %, ils sont considérés comme épuisés et l’intégrité affichée est à 50 % avec : état=Détérioré et motif=port SNAT. Le pare-feu continue à traiter le trafic et les connexions existantes ne sont pas affectées. Toutefois, les 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 : pourcentage de ports SNAT qui ont été utilisés par le pare-feu.
Unité : pourcentage
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. De plus, lorsque le pare-feu est mis à l’échelle pour différentes raisons (par exemple, UC ou débit), des ports SNAT supplémentaires sont également rendus disponibles. De fait, un pourcentage donné de l’utilisation des ports SNAT peut baisser sans que vous ajoutiez d’adresses IP publiques, juste parce que le service est 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 : Estimations de la latence moyenne du Pare-feu Azure.
Unité : ms
Cette métrique mesure la latence globale ou moyenne du 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 existe plusieurs raisons pouvant augmenter la latence dans le 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.
Cette métrique ne mesure pas la latence de bout en bout d’un chemin d'accès réseau donné. En d’autres termes, cette sonde d’intégrité de latence ne mesure pas la latence induite par le Pare-feu Azure.
Quand la métrique de latence ne fonctionne pas comme prévu, la valeur 0 s’affiche dans le tableau de bord des métriques.
À titre de référence, la latence moyenne attendue d’un pare-feu est d’environ 1 ms. Cela peut varier selon la taille du déploiement et l’environnement.
La sonde de latence est basée sur la technologie Ping Mesh de Microsoft. Par conséquent, il faut s’attendre à des pics intermittents dans la métrique de latence. Ces pics sont normaux et ne signalent pas de problème avec le Pare-feu Azure. Ils font partie de la configuration réseau de l’hôte standard qui prend en charge le système.
Pour cette raison, si vous rencontrez une latence élevée constante qui dure plus longtemps que les pics classiques, envisagez de créer un ticket de support pour obtenir de l’aide.
Alerte sur les métriques du Pare-feu Azure
Les métriques fournissent des signaux critiques pour suivre l’intégrité de vos ressources. Il est donc important de surveiller les métriques de votre ressource et de détecter les anomalies. Mais que se passe-t-il si les métriques du Pare-feu Azure cessent de circuler ? Cela peut indiquer un problème de configuration potentiel ou un problème plus inquiétant tel qu’une panne. Des métriques manquantes peuvent se produire en raison de la publication d’itinéraires par défaut qui empêchent le Pare-feu Azure de charger des métriques ou si le nombre d’instances intègres atteint zéro. Dans cette section, vous allez apprendre à configurer des métriques sur un espace de travail Log Analytics et à alerter sur les métriques manquantes.
Configurer des métriques dans un espace de travail Log Analytics
La première étape consiste à configurer la disponibilité des métriques dans l’espace de travail Log Analytics à l’aide des paramètres de diagnostic dans le pare-feu.
Accédez à la page de ressources du Pare-feu Azure pour configurer les paramètres de diagnostic, comme illustré dans la capture d’écran suivante. Cette opération envoie (push) les métriques de pare-feu à l’espace de travail configuré.
Remarque
Les paramètres de diagnostic des métriques doivent être une configuration distincte des journaux. Les journaux de pare-feu peuvent être configurés pour utiliser des diagnostics Azure ou des ressources spécifiques. Toutefois, les métriques de pare-feu doivent toujours utiliser des diagnostics Azure.
Créer une alerte pour suivre la réception des métriques de pare-feu sans échec
Accédez à l’espace de travail configuré dans les paramètres de diagnostic des métriques. Vérifiez si les métriques sont disponibles à l’aide de la requête suivante :
AzureMetrics
| where MetricName contains "FirewallHealth"
| where ResourceId contains "/SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/RESOURCEGROUPS/PARALLELIPGROUPRG/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/HUBVNET-FIREWALL"
| where TimeGenerated > ago(30m)
Ensuite, créez une alerte pour les métriques manquantes sur une période de 60 minutes. Accédez à la page Alerte de l’espace de travail Log Analytics pour configurer de nouvelles alertes sur les métriques manquantes.
