Informations de référence sur les données de supervision d’Azure Application Gateway
Consultez Supervision d’Azure Application Gateway pour plus d’informations sur la collecte et l’analyse des données de surveillance d’Azure Application Gateway.
Mesures d’Application Gateway v2
Fournisseur de ressources et type : Microsoft.Network/applicationGateways
Métriques de minutage
Application Gateway fournit plusieurs métriques de minutage intégrées associées à la requête et à la réponse, qui sont toutes mesurées en millisecondes.
Remarque
Si Application Gateway comprend plus d’un écouteur, filtrez toujours par la dimension Écouteur tout en comparant différentes mesures de latence pour obtenir une inférence plus significative.
Métrique | Unité | Description |
---|---|---|
Temps de connexion au principal | Millisecondes | Temps passé à établir une connexion avec l’application principale. Cela comprend la latence du réseau ainsi que le temps pris par la pile TCP du serveur principal pour établir de nouvelles connexions. Pour TLS, il comprend également le temps consacré à l’établissement d’une liaison. |
Temps de réponse du premier octet du principal | Millisecondes | Intervalle de temps entre le début de l’établissement d’une connexion au serveur principal et la réception du premier octet de l’en-tête de la réponse. Cela correspond approximativement à la somme du temps de connexion au principal, du temps pris par la demande pour atteindre le principal depuis Application Gateway, du temps pris par l’application principale pour répondre (le temps nécessaire au serveur pour générer du contenu, extraire potentiellement des requêtes de base de données) et du temps mis par le premier octet de la réponse à atteindre Application Gateway à partir du principal. |
Temps de réponse du dernier octet du principal | Millisecondes | Intervalle de temps entre le début de l’établissement d’une connexion au serveur principal et la réception du dernier octet du corps de la réponse. Cela correspond approximativement à la somme du temps de réponse du premier octet principal et du temps de transfert des données. Ce chiffre peut varier en fonction de la taille des objets demandés et de la latence du réseau du serveur. |
Durée totale d’Application Gateway | Millisecondes | Temps moyen nécessaire pour la réception et le traitement d’une requête et l’envoi de la réponse. Il s’agit de l’intervalle entre le moment où Application Gateway reçoit le premier octet de la requête HTTP et le moment où le dernier octet de la réponse a été envoyé au client. Cela comprend le temps de traitement pris par Application Gateway, le temps de réponse du dernier octet principal, le temps pris par Application Gateway pour envoyer toutes les réponses et le RTT client. |
RTT client | Millisecondes | Durée moyenne des allers-retours entre les clients et Application Gateway. |
Ces métriques peuvent être utilisées pour déterminer si le ralentissement observé est dû au réseau client, aux performances d’Application Gateway, à la saturation de la pile TCP du réseau principal et du serveur principal, aux performances de l’application principale ou à la taille volumineuse des fichiers.
Par exemple, s’il existe un pic dans la tendance Temps de réponse du premier octet du back-end, mais que la tendance Temps de connexion au back-end est stable, on peut en déduire que la latence entre la passerelle d’application et le serveur principal et le temps nécessaire pour établir la connexion sont stables, et que le pic est dû à une augmentation du temps de réponse de l’application back-end. En revanche, si le pic dans Temps de réponse du premier octet du principal est associé à un pic correspondant dans Temps de connexion au principal, il peut être déduit que le réseau entre Application Gateway et le serveur principal ou la pile TCP du serveur principal est saturé.
Si vous remarquez un pic dans Temps de réponse du dernier octet du principal, mais que le temps de réponse du premier octet du principal est stable, il peut être déduit que le pic est dû à la demande d’un fichier plus volumineux.
De même, si la durée totale de la passerelle d’application présente un pic, mais que le temps de réponse du dernier octet du principal est stable, cela peut être le signe d’un goulot d’étranglement des performances au niveau d’Application Gateway ou d’un goulot d’étranglement dans le réseau entre le client et Application Gateway. En outre, si le client RTT présente également un pic correspondant, cela indique que la dégradation est due au réseau entre le client et le service Application Gateway.
Mesures Application Gateway
Métrique | Unité | Description |
---|---|---|
Octets reçus | Octets | Nombre d’octets reçus par Application Gateway à partir des clients. (Cette métrique compte uniquement la taille de contenu de la requête observée par Application Gateway. Il n’inclut pas les transferts de données tels que les négociations d’en-tête TLS, les en-têtes de paquets TCP/IP ou les retransmissions.) |
Octets envoyés | Octets | Nombre d’octets envoyés par Application Gateway aux clients. (Cette métrique compte uniquement la taille de contenu de réponse fournie par Application Gateway. Il n’inclut pas les transferts de données tels que les en-têtes de paquets TCP/IP ou les retransmissions.) |
Protocole TLS du client | Count | Nombre de demandes TLS et non-TLS initiées par le client qui a établi la connexion avec Application Gateway. Pour afficher la distribution du protocole TLS, filtrez par la dimension Protocole TLS. |
Unités de capacité actuelles | Count | Nombre d’unités de capacité consommées pour équilibrer la charge du trafic. Les unités de capacité incluent trois déterminants : l’unité Compute, les connexions persistantes et le débit. Chaque unité de capacité est composée au maximum de ce qui suit : une unité Compute ou 2500 connexions persistantes, ou 2,22 Mbits/s de débit. |
Unités de calcul actuelles | Count | Capacité processeur consommée. Les facteurs affectant l’unité Compute sont les connexions TLS/s, les calculs de réécriture d’URL et le traitement des règles WAF. |
Connexions en cours | Count | Nombre total de connexions simultanées actives de clients à Application Gateway. |
Unités de capacité facturées estimées | Count | Avec la référence (SKU) v2, le modèle de tarification est déterminé par la consommation. Les unités de capacité mesurent le coût basé sur la consommation qui est facturé en plus du coût fixe. *Les unités de capacité facturées estimées indiquent le nombre d’unités de capacité à l’aide desquelles la facturation est estimée. Cette valeur est calculée comme étant la plus grande valeur entre Unités de capacité actuelles (unités de capacité requises pour équilibrer la charge du trafic) et Unités de capacité facturables fixes (unités de capacité minimales approvisionnées conservées). |
Requêtes ayant échoué | Count | Nombre de requêtes traitées par Application Gateway avec des codes d'erreur serveur 5xx. Cela comprend les codes 5xx générés à partir d’Application Gateway et les codes 5xx générés à partir du serveur principal. Le nombre de demandes peut être filtré pour afficher le nombre d’affichages par combinaison de paramètres HTTP/pool principal spécifique. |
Unités de capacité facturables fixes | Count | Nombre minimal d’unités de capacité approvisionnées conservées conformément à la valeur du paramètre Unités d’échelle minimales (une instance se traduit par 10 unités de capacité) dans la configuration du service Application Gateway. |
Nouvelles connexions par seconde | Count | Nombre moyen de nouvelles connexions TCP par seconde à partir de clients au Service Application Gateway et à partir du service Application Gateway à des membres principaux. |
État de la réponse | Code d’état | État de la réponse HTTP retourné par Application Gateway. La distribution du code d’état de la réponse peut être ultérieurement classée par catégorie afin d’afficher les réponses dans les catégories 2xx, 3xx, 4xx et 5xx. |
Débit | Octets/s | Nombre d’octets par seconde servis par Application Gateway. (Cette métrique compte uniquement la taille de contenu servie par Application Gateway. Il n’inclut pas les transferts de données tels que les négociations d’en-tête TLS, les en-têtes de paquets TCP/IP ou les retransmissions.) |
Total de requêtes | Count | Nombre de requêtes réussies servies par Application Gateway. Le nombre de demandes peut être filtré pour afficher le nombre d’affichages par combinaison de paramètres HTTP/pool principal spécifique. |
Métriques du principal
Métrique | Unité | Description |
---|---|---|
État de la réponse du principal | Count | Nombre de codes d’état de réponse HTTP retournés par les principaux. Cela n’inclut pas les codes de réponse générés par Application Gateway. La distribution du code d’état de la réponse peut être ultérieurement classée par catégorie afin d’afficher les réponses dans les catégories 2xx, 3xx, 4xx et 5xx. |
Nombre d’hôtes intègres | Count | Le nombre de serveurs principaux déterminés sains par la sonde d’intégrité. Vous pouvez filtrer sur une base de pool principal pour afficher le nombre d’hôtes sains dans un pool principal spécifique. |
Nombre d’hôtes défectueux | Count | Nombre de principaux déterminés défectueux par la sonde d’intégrité. Vous pouvez filtrer sur une base de pool principal pour afficher le nombre d’hôtes non sains dans un pool principal spécifique. |
Demandes par minute par hôte sain | Count | Nombre moyen de requêtes que chaque membre sain d’un pool principal reçoit par minute. Spécifiez le pool principal à l’aide de la dimension BackendPool HttpSettings. |
API d’intégrité du back-end
Consultez Passerelles applicatives – Intégrité du back-end pour obtenir des informations sur l’appel d’API pour récupérer l’intégrité du back-end d’une passerelle applicative.
Exemple de requête : output POST https://management.azure.com/subscriptions/subid/resourceGroups/rg/providers/Microsoft.Network/ applicationGateways/appgw/backendhealth?api-version=2021-08-01 After
Après l’envoi de cette requête POST, vous devriez voir une réponse HTTP 202 accepté. Dans les en-têtes de réponse, recherchez l’en-tête Emplacement et envoyez une nouvelle requête GET en utilisant cette URL.
output GET https://management.azure.com/subscriptions/subid/providers/Microsoft.Network/locations/region-name/operationResults/GUID?api-version=2021-08-01
Monitoring de proxy TLS/TCP Application Gateway
Mesures de proxy TLS/TCP
Avec la fonctionnalité de proxy de couche 4 désormais disponible avec Application Gateway, il existe des mesures courantes (s’appliquent à la couche 7 et à la couche 4) et quelques mesures spécifiques à la couche 4. Le tableau suivant décrit toutes les mesures à l’utilisation de la couche 4.
Métrique | Description | Type | Dimension |
---|---|---|---|
Connexions courantes | Nombre de connexion actives : lecture, écriture et attente. Nombre de connexions actuelles établies avec Application Gateway. | Métriques courantes | Aucun |
Nouvelles connexions par seconde | Nombre moyen de connexions gérées par seconde pendant cette minute. | Métriques courantes | Aucun |
Débit | Taux de flux de données (octets entrants + octets sortants) pendant cette minute. | Métriques courantes | Aucun |
Nombre d’hôtes intègres | Nombre d’hôtes back-end sains. | Métriques courantes | BackendSettingsPool |
Hôtes non sains | Nombre d’hôtes back-end non sains. | Métriques courantes | BackendSettingsPool |
ClientRTT | Durée moyenne des allers-retours entre les clients et Application Gateway. | Métriques courantes | Port d'écoute |
Temps de connexion au back-end | Temps passé à établir une connexion avec un principal. | Métriques courantes | Listener, BackendServer, BackendPool, BackendSetting |
Temps de réponse du premier octet du back-end | Intervalle de temps entre le début de l’établissement d’une connexion au serveur principal et la réception du premier octet de données (ce qui correspond approximativement au temps de traitement du serveur back-end). | Métriques courantes | Listener, BackendServer, BackendPool, BackendHttpSetting* |
Durée de la session de back-end | Durée totale de la connexion back-end. Durée moyenne entre le début d’une nouvelle connexion et son arrêt. | Spécifique à L4 | Listener, BackendServer, BackendPool, BackendHttpSetting* |
Durée de vie de la connexion | Durée totale de la connexion d’un client à une passerelle applicative. Durée moyenne entre le début d’une nouvelle connexion et son arrêt en millisecondes. | Spécifique à L4 | Port d'écoute |
La dimension BackendHttpSetting *
comprend les paramètres de back-end de la couche 7 et de la couche 4.
Journaux de proxy TLS/TCP
Le proxy de couche 4 d’Application Gateway fournit les données de journal via les journaux d’accès. Ces journaux sont uniquement générés et publiés s’ils sont configurés dans les paramètres de diagnostic de votre passerelle.
Catégorie | Catégorie de journal de ressources |
---|---|
ResourceGroup | Groupe de ressources auquel appartient la ressource de passerelle applicative. |
SubscriptionId | ID d’abonnement de la ressource de passerelle applicative. |
ResourceProvider | Il s’agit de MICROSOFT.NETWORK pour une passerelle applicative. |
Ressource | Nom de la ressource de passerelle applicative. |
ResourceType | Il s’agit de APPLICATIONGATEWAYS. |
ruleName | Nom de la règle d’acheminement ayant servi la requête de connexion. |
instanceId | Instance Application Gateway ayant traité la requête. |
clientIP | Adresse IP d’origine de la requête. |
receivedBytes | Données reçues d’un client vers une passerelle, en octets. |
sentBytes | Données envoyée d’une passerelle vers un client, en octets. |
listenerName | Nom de l’écouteur ayant établi une connexion front-end avec un client. |
backendSettingName | Nom du paramètre de back-end utilisé pour la connexion back-end. |
backendPoolName | Nom du pool back-end à partir duquel un serveur cible a été sélectionné pour établir la connecter back-end. |
protocol | TCP (sans tenir compte du fait qu’il s’agisse d’un protocole TCP ou TLS, la valeur est toujours TCP). |
sessionTime | durée de session en secondes (elle concerne la session client->appgw) |
upstreamSentBytes | Données envoyées au serveur principal, en octets. |
upstreamReceivedBytes | Données reçues du serveur principal, en octets. |
upstreamSessionTime | durée de session en secondes (elle concerne la session client->appgw) |
sslCipher | Suite de chiffrement utilisée pour la communication TLS (pour des écouteurs de protocole TLS). |
sslProtocol | Protocole SSL/TLS utilisé (pour les écouteurs de protocole TLS). |
serverRouted | IP de serveur principal et numéro de port vers lequel le trafic est routé. |
serverStatus | 200 – Session correctement terminée. 400 – Impossible d’analyser les données client. 500 – Erreur interne du serveur. 502 – Passerelle incorrecte. Par exemple, lorsqu’un serveur amont est inaccessible. 503 – Service indisponible. Par exemple, si l’accès est limité par le nombre de connexions. |
ResourceId | URI de ressource Application Gateway |
Intégrité du back-end de proxy TLS/TCP
Le proxy de couche 4 d’Application Gateway permet de surveiller l’intégrité des membres individuels des pools back-end au moyen du portail et de l’API REST.
Mesures d’Application Gateway v1
Mesures Application Gateway
Métrique | Unité | Description |
---|---|---|
Utilisation du processeur | Pourcentage | Affiche l’utilisation de l’UC allouée à la passerelle applicative. Dans des conditions normales, l’utilisation du processeur ne doit pas dépasser 90 %, car cela peut entraîner une latence dans les sites Web hébergés derrière Application Gateway et perturber l’expérience du client. Vous pouvez indirectement contrôler ou améliorer l’utilisation de l’UC en modifiant la configuration de la passerelle applicative en augmentant le nombre d’instances ou en passant à une taille SKU plus grande, ou en faisant les deux. |
Connexions en cours | Count | Nombre de connexions en cours établies avec Application Gateway. |
Requêtes ayant échoué | Count | Nombre de demandes ayant échoué en raison de problèmes de connexion. Ce nombre comprend les requêtes qui ont échoué en raison du dépassement du paramètre HTTP Délai d’expiration des demandes ou de problèmes de connexion entre Application Gateway et le serveur principal. Ne sont pas comptabilisées les défaillances dues à l’absence de serveur principal sain disponible. Les réponses 4xx et 5xx du serveur principal ne sont pas non plus prises en compte dans le cadre de cette métrique. |
État de la réponse | Code d’état | État de la réponse HTTP retourné par Application Gateway. La distribution du code d’état de la réponse peut être ultérieurement classée par catégorie afin d’afficher les réponses dans les catégories 2xx, 3xx, 4xx et 5xx. |
Débit | Octets/s | Nombre d’octets par seconde servis par Application Gateway. |
Total de requêtes | Count | Nombre de requêtes réussies servies par Application Gateway. Le nombre de demandes peut être filtré pour afficher le nombre d’affichages par combinaison de paramètres HTTP/pool principal spécifique. |
Nombre de demandes bloquées par le pare-feu d’applications web | Count | Nombre de requêtes bloquées par WAF. |
Distribution des règles de demandes bloquées par le pare-feu d’applications web | Count | Nombre de requêtes bloquées par WAF et filtrées pour afficher le nombre par groupe de règles WAF ou combinaison d’ID de règle WAF spécifique. |
Distribution totale des règles du pare-feu d’applications web | Count | Nombre de requêtes reçues par groupe de règles WAF ou combinaison d’ID de règle WAF spécifique. |
Pour plus d’informations, consultez la liste de toutes les métriques de plateforme prises en charge dans Azure Monitor.
Dimensions de métriques
Pour obtenir plus d’informations sur les dimensions de mesures, consultez Métriques multidimensionnelles.
Azure Application Gateway prend en charge des dimensions pour certaines métriques dans Azure Monitor. Chaque métrique comprend une description qui explique les dimensions disponibles spécifiquement pour cette métrique.
Journaux d’activité de ressources
Cette section répertorie les types de journaux de ressources que vous pouvez collecter pour Azure Application Gateway.
Pour référence, consultez la liste de tous les types de catégories de journaux de ressources pris en charge dans Azure Monitor.
Remarque
Le journal des performances est uniquement disponible pour la référence SKU v1. Pour la référence SKU v2, utilisez les Mesures d’Application Gateway v2 pour les données de performances.
Pour obtenir plus d’informations, consultez Journaux de diagnostic et de l’intégrité du back-end pour la passerelle Application Gateway.
Application Gateway
Fournisseur de ressources et type : Microsoft.Network/applicationGateways
Catégorie | Nom d’affichage | Information |
---|---|---|
Activitylog | Journal d’activité | Les entrées du journal d’activité sont collectées par défaut. vous pouvez utiliser le Journal d’activité Azure (anciennement journaux d’activité des opérations et journaux d’audit) pour voir toutes les opérations soumises à votre abonnement Azure, ainsi que leur état. |
ApplicationGatewayAccessLog | Journal d’accès | Vous pouvez utiliser ce journal pour voir les modèles d’accès Application Gateway et analyser les informations importantes. Ceci comprend l’adresse IP de l’appelant, l’URL demandée, la latence de réponse, le code de retour et les octets d’entrée et de sortie. Un journal d’accès est collecté toutes les 60 secondes. Ce journal contient un enregistrement par instance Application Gateway. L’instance de la passerelle Application Gateway est identifiée par la propriété instanceId. |
ApplicationGatewayPerformanceLog | Journal des performances | vous pouvez utiliser ce journal pour afficher les performances des instances de la passerelle Application Gateway. Ce journal capture des informations sur les performances de chaque instance, notamment le nombre total de requêtes traitées, le débit en octets, le nombre total de requêtes présentées, le nombre de requêtes ayant échoué, le nombre d’instances du serveur principal intègres et défectueuses. Le journal des performances est collecté toutes les 60 secondes. Le journal des performances est uniquement disponible pour la référence SKU v1. Pour la référence SKU v2, utilisez les Mesures d’Application Gateway v2 pour les données de performances. |
ApplicationGatewayFirewallLog | Journal du pare-feu | vous pouvez utiliser ce journal pour afficher les requêtes consignées via le mode de détection ou de prévention d’une passerelle Application Gateway configuré avec un pare-feu d’applications web. Les journaux du pare-feu sont collectés toutes les 60 secondes. |
Tables Azure Monitor Logs
Cette section fait référence à toutes les tables Kusto de Journaux d’activité Azure Monitor qui sont pertinentes pour Azure Application Gateway et qui peuvent être interrogées par Log Analytics.
Type de ressource | Notes |
---|---|
Application Gateway | Comprend AzureActivity, AzureDiagnostics et AzureMetrics |
Pour obtenir une référence de toutes les tables Azure Monitor Logs/Log Analytics, consultez la référence relative aux tables Azure Monitor Logs.
Tables de diagnostic
Azure Application Gateway utilise la table Diagnostics Azure pour stocker les informations des journaux de ressources. Les colonnes suivantes sont pertinentes.
Diagnostics Azure
Propriété | Description |
---|---|
requestUri_s | URI de la requête du client. |
Message | Messages d’information tels que « Attaque par injection de code SQL » |
userAgent_s | Détails de l’agent utilisateur de la requête du client |
ruleName_s | Règle d’acheminement des requêtes utilisée pour traiter cette requête |
httpMethod_s | Méthode HTTP de la requête du client |
instanceId_s | Instance Appgw vers laquelle la requête du client est routée pour évaluation |
httpVersion_s | Version HTTP de la requête du client |
clientIP_s | Adresse IP à partir de laquelle la requête est effectuée |
host_s | En-tête de l’hôte de la requête du client |
requestQuery_s | Chaîne de requête dans le cadre de la requête du client |
sslEnabled_s | Si le protocole SSL est activé ou non pour la requête du client |
Voir aussi
- Consultez Surveillance Azure Application Gateway pour obtenir une description de la surveillance Azure Application Gateway.
- Pour plus d’informations sur le monitoring des ressources Azure, voir Monitoring des ressources Azure avec Azure Monitor.