Journaux de diagnostic pour Application Gateway
Les journaux Application Gateway fournissent des informations détaillées sur les événements liés à une ressource et à ses opérations. Ces journaux sont disponibles pour des événements en rapport avec l’accès, l’activité, le pare-feu et les performances (uniquement pour la V1). Les informations granulaires contenues dans les journaux sont utiles lors de la résolution d’un problème ou de la création d’un tableau de bord d’analyse qui consomme ces données brutes.
Les journaux sont disponibles pour toutes les ressources d’Application Gateway. Toutefois, pour les consommer, vous devez activer leur collection dans un emplacement de stockage de votre choix. La journalisation dans Azure Application Gateway est activée par le service Azure Monitor. Nous vous recommandons d’utiliser l’espace de travail Log Analytics, car vous pouvez facilement utiliser ses requêtes prédéfinies et définir des alertes en fonction de conditions de journal spécifiques.
Types de journaux de diagnostic
Vous pouvez utiliser différents types de journaux d’activité dans Azure pour gérer les passerelles Application Gateway et résoudre les problèmes associés. Vous pouvez en savoir plus sur ces types ci-dessous :
- Journal d’activité : vous pouvez utiliser le Journal d’activité Azure (anciennement journaux d’activité des opérations et journaux d’audit) pour afficher toutes les opérations soumises à votre abonnement Azure, ainsi que leur état. Les entrées du journal d’activité sont recueillies par défaut et vous pouvez les afficher dans le Portail Azure.
- 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.
- Journaux de 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. S’il s’agit de la référence SKU v2, utilisez les Métriques pour les données de performances.
- Journaux 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.
Remarque
Les journaux d’activité ne sont disponibles que pour les ressources déployées dans le modèle de déploiement Azure Resource Manager. Vous ne pouvez pas les utiliser pour les ressources utilisant le modèle de déploiement classique. Pour mieux comprendre ces deux modèles, consultez l’article Présentation du déploiement de Resource Manager et du déploiement classique .
Emplacements de stockage
Vous disposez des options suivantes pour stocker les journaux dans votre emplacement préféré.
- Espace de travail Log Analytic : recommandé, car il vous permet d’utiliser facilement les requêtes et visualisations prédéfinies et de définir des alertes en fonction de conditions de journal spécifiques.
- Compte de stockage Azure : les comptes de stockage conviennent parfaitement aux journaux qui sont stockés pour une durée plus longue et consultés au besoin.
- Azure Event Hubs : les hubs d’événements constituent une excellente solution pour l’intégration à d’autres outils SIEM (Security Information and Event Management) afin de recevoir des alertes sur vos ressources.
- Intégrations partenaires d’Azure Monitor
Découvrez-en plus sur les destinations des paramètres de diagnostic d’Azure Monitor.
Activation de la journalisation avec PowerShell
La journalisation d’activité est automatiquement activée pour chaque ressource Resource Manager. Vous devez activer la journalisation de l’accès et des performances pour commencer à collecter les données disponibles dans ces journaux d’activité. Pour activer la journalisation, utilisez les étapes suivantes :
Notez l’ID de ressource de votre compte de stockage, où les données de journalisation sont stockées. Cette valeur a le format suivant : /abonnements/<subscriptionId>/resourceGroups/<nom du groupe de ressources>/providers/Microsoft.Storage/storageAccounts/<nom du compte de stockage>. Vous pouvez utiliser n’importe quel compte de stockage dans votre abonnement. Vous pouvez utiliser le portail Azure pour rechercher ces informations.
Notez l’ID de ressource de votre passerelle Application Gateway pour laquelle la journalisation est activée. Cette valeur a le format suivant : /abonnements/<subscriptionId>/resourceGroups/<nom du groupe de ressources>/providers/Microsoft.Network/applicationGateways/<nom de la passerelle Application Gateway>. Vous pouvez utiliser le portail pour rechercher ces informations.
Activez la journalisation des diagnostics à l’aide de l’applet de commande PowerShell suivante :
Set-AzDiagnosticSetting -ResourceId /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name> -StorageAccountId /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Storage/storageAccounts/<storage account name> -Enabled $true
Conseil
Les journaux d’activité ne nécessitent pas de compte de stockage distinct. L’utilisation du stockage pour la journalisation de l’accès et des performances occasionne des frais de service.
Activation de la journalisation avec le portail Azure
Sur le portail Azure, recherchez votre ressource, puis sélectionnez Paramètres de diagnostic.
Pour Application Gateway, trois journaux d’activité d’audit sont disponibles :
- Journal d’accès
- Journal des performances
- Journal du pare-feu
Sélectionnez Activer les diagnostics pour démarrer la collecte de données.
La page Paramètres de diagnostic contient les paramètres des journaux de diagnostic. Dans cet exemple, Log Analytics stocke les journaux d’activité. Vous pouvez également utiliser des concentrateurs d’événements et un compte de stockage pour enregistrer les journaux de diagnostic.
Tapez un nom pour les paramètres, confirmez les paramètres, puis sélectionnez Enregistrer.
Journal d’activité
Par défaut, Azure génère le journal d’activité. Les journaux d’activité sont conservés pendant 90 jours dans la banque de journaux d’événements d’Azure. Pour en savoir plus sur ces journaux d’activité, lisez l’article Affichage des événements et du journal d’activité.
Journal d’accès
Le journal d’accès n’est généré que si vous l’avez activé sur chaque instance Application Gateway, comme détaillé dans les étapes précédentes. Les données sont stockées dans le compte de stockage spécifié lors de l’activation de la journalisation. Chaque accès à Application Gateway est journalisé au format JSON, comme indiqué ci-dessous.
Pour le niveau tarifaire Application Gateway et WAF v2
Remarque
Pour obtenir des informations sur le proxy TLS/TCP, consultez référence de données.
| Valeur | Description |
|---|---|
| instanceId | Instance Application Gateway ayant traité la requête. |
| clientIP | IP du client immédiat d’Application Gateway. Si un autre proxy fait face à votre passerelle applicative, l’IP de ce proxy faisant face s’affiche. |
| httpMethod | Méthode HTTP utilisée par la requête. |
| requestUri | URI de la requête reçue. |
| UserAgent | Agent utilisateur de l’en-tête de requête HTTP. |
| httpStatus | Code d’état HTTP renvoyé au client à partir de d’Application Gateway. |
| httpVersion | Version HTTP de la requête. |
| receivedBytes | Taille du paquet reçu, en octets. |
| sentBytes | Taille du paquet envoyé, en octets. |
| clientResponseTime | Différence de temps (en secondes) entre le premier octet et le dernier octet envoyés par Application Gateway au client. Utile pour évaluer le temps de traitement d’Application Gateway pour les réponses ou les clients lents. |
| timeTaken | Durée (en secondes) nécessaire au traitement du premier octet d’une demande cliente et à l’envoi du dernier octet dans la réponse au client. Il est important de noter que le champ Time-Taken inclut généralement l’heure à laquelle la requête et les paquets de réponse circulent sur le réseau. |
| WAFEvaluationTime | Durée (en secondes) nécessaire au traitement de la demande par le WAF. |
| WAFMode | La valeur peut être Detection ou Prevention |
| transactionId | Identificateur unique pour corréler la requête reçue du client |
| sslEnabled | Détermine si la communication avec les pools de back-ends a utilisé TLS. Les valeurs valides sont On (Activé) et Off (Désactivé). |
| sslCipher | Suite de chiffrement utilisée pour la communication TLS (si TLS est activé). |
| sslProtocol | Protocole SSL/TLS utilisé (si TLS est activé). |
| serverRouted | Serveur back-end vers lequel la passerelle d’application route les demandes. |
| serverStatus | Code d’état HTTP du serveur back-end. |
| serverResponseLatency | Latence de la réponse (en secondes) du serveur back-end. |
| host | Adresse figurant dans l’en-tête d’hôte de la demande. Si elle est réécrite en utilisant la réécriture d’en-tête, ce champ contient le nom d’hôte mis à jour. |
| originalRequestUriWithArgs | ce champ contient l’URL de demande d’origine. |
| requestUri | Ce champ contient l’URL après l’opération de réécriture sur Application Gateway. |
| upstreamSourcePort | Port source utilisé par Application Gateway lors du lancement d’une connexion à la cible back-end |
| originalHost | Ce champ contient le nom d’hôte de la requête HTTP d’origine. |
| error_info | Raison des erreurs 4xx et 5xx. Affiche un code d’erreur pour une requête ayant échoué. Pour plus d’informations, consultez Informations sur les codes d’erreur. |
| contentType | Type de contenu ou de données que la passerelle applicative traite ou remet |
{
"timeStamp": "2021-10-14T22:17:11+00:00",
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"listenerName": "HTTP-Listener",
"ruleName": "Storage-Static-Rule",
"backendPoolName": "StaticStorageAccount",
"backendSettingName": "StorageStatic-HTTPS-Setting",
"operationName": "ApplicationGatewayAccess",
"category": "ApplicationGatewayAccessLog",
"properties": {
"instanceId": "appgw_2",
"clientIP": "185.42.129.24",
"clientPort": 45057,
"httpMethod": "GET",
"originalRequestUriWithArgs": "\/",
"requestUri": "\/",
"requestQuery": "",
"userAgent": "Mozilla\/5.0 (Windows NT 6.1; WOW64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/52.0.2743.116 Safari\/537.36",
"httpStatus": 200,
"httpVersion": "HTTP\/1.1",
"receivedBytes": 184,
"sentBytes": 466,
"clientResponseTime": 0,
"timeTaken": 0.034,
"WAFEvaluationTime": "0.000",
"WAFMode": "Detection",
"transactionId": "592d1649f75a8d480a3c4dc6a975309d",
"sslEnabled": "on",
"sslCipher": "ECDHE-RSA-AES256-GCM-SHA384",
"sslProtocol": "TLSv1.2",
"sslClientVerify": "NONE",
"sslClientCertificateFingerprint": "",
"sslClientCertificateIssuerName": "",
"serverRouted": "52.239.221.65:443",
"serverStatus": "200",
"serverResponseLatency": "0.028",
"upstreamSourcePort": "21564",
"originalHost": "20.110.30.194",
"host": "20.110.30.194",
"error_info":"ERRORINFO_NO_ERROR",
"contentType":"application/json"
}
}
Remarque
Les journaux d’accès avec la valeur clientIP 127.0.0.1 proviennent d’un processus de sécurité interne s’exécutant sur les instances de passerelle d’application. Vous pouvez ignorer ces entrées de journal de manière sécurisée.
Pour le niveau tarifaire Application Gateway Standard et WAF (v1)
| Valeur | Description |
|---|---|
| instanceId | Instance Application Gateway ayant traité la requête. |
| clientIP | Adresse IP d’origine de la requête. |
| clientPort | Port d’origine de la requête. |
| httpMethod | Méthode HTTP utilisée par la requête. |
| requestUri | URI de la requête reçue. |
| RequestQuery | Server-Routed : instance de pool de back-ends à laquelle la demande a été envoyée.X-AzureApplicationGateway-LOG-ID : ID de corrélation utilisé pour la demande. Peut être utilisée pour résoudre les problèmes de trafic sur les back-ends. ÉTAT DU SERVEUR : code de réponse HTTP reçu par Application Gateway à partir du serveur principal. |
| UserAgent | Agent utilisateur de l’en-tête de requête HTTP. |
| httpStatus | Code d’état HTTP renvoyé au client à partir de d’Application Gateway. |
| httpVersion | Version HTTP de la requête. |
| receivedBytes | Taille du paquet reçu, en octets. |
| sentBytes | Taille du paquet envoyé, en octets. |
| timeTaken | Durée (en millisecondes) nécessaire pour le traitement d’une requête et l’envoi de la réponse. Elle est calculée en fonction de l’intervalle entre le moment où Application Gateway reçoit le premier octet d’une requête HTTP et le moment où l’opération d’envoi d’une réponse se termine. Il est important de noter que le champ Time-Taken inclut généralement l’heure à laquelle la requête et les paquets de réponse circulent sur le réseau. |
| sslEnabled | Détermine si la communication avec les pools de back-ends a utilisé TLS/SSL. Les valeurs valides sont On (Activé) et Off (Désactivé). |
| host | Nom de l’hôte pour lequel la requête a été envoyée au serveur back-end. Si le nom d’hôte du back-end est remplacé, ce nom reflète cette situation. |
| originalHost | Nom de l’hôte pour lequel la requête provenant du client a été reçue par Application Gateway. |
{
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/PEERINGTEST/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayAccess",
"time": "2017-04-26T19:27:38Z",
"category": "ApplicationGatewayAccessLog",
"properties": {
"instanceId": "ApplicationGatewayRole_IN_0",
"clientIP": "191.96.249.97",
"clientPort": 46886,
"httpMethod": "GET",
"requestUri": "/phpmyadmin/scripts/setup.php",
"requestQuery": "X-AzureApplicationGateway-CACHE-HIT=0&SERVER-ROUTED=10.4.0.4&X-AzureApplicationGateway-LOG-ID=874f1f0f-6807-41c9-b7bc-f3cfa74aa0b1&SERVER-STATUS=404",
"userAgent": "-",
"httpStatus": 404,
"httpVersion": "HTTP/1.0",
"receivedBytes": 65,
"sentBytes": 553,
"timeTaken": 205,
"sslEnabled": "off",
"host": "www.contoso.com",
"originalHost": "www.contoso.com"
}
}
Informations sur les codes d’erreur
Si la passerelle applicative ne peut pas terminer la requête, elle stocke l’un des codes de raison suivants dans le champ error_info du journal d’accès.
| Erreurs 4XX | (Les codes d’erreur 4xx indiquent qu’il y a eu un problème avec la requête du client et que la passerelle Application Gateway n’a pas pu traiter la requête.) |
|---|---|
| ERRORINFO_INVALID_METHOD | Le client a envoyé une requête qui n’est pas conforme à RFC. Raisons possibles : le client utilise une méthode HTTP non prise en charge par le serveur, la méthode est mal orthographiée, la version du protocole HTTP est incompatible, etc. |
| ERRORINFO_INVALID_REQUEST | Le serveur ne peut pas traiter la requête en raison d’une syntaxe incorrecte. |
| ERRORINFO_INVALID_VERSION | La passerelle applicative a reçu une requête ayant une version de protocole HTTP non valide ou non prise en charge. |
| ERRORINFO_INVALID_09_METHOD | Le client a envoyé une requête ayant le protocole HTTP version 0.9. |
| ERRORINFO_INVALID_HOST | La valeur fournie dans l’en-tête d’hôte (« Host ») est manquante, est incorrectement mise en forme ou ne correspond pas à la valeur d’hôte attendue (quand il n’y a pas d’écouteur De base, et qu’aucun des noms d’hôtes des écouteurs Multisite ne correspond à l’hôte). |
| ERRORINFO_INVALID_CONTENT_LENGTH | La longueur du contenu spécifié par le client dans l’en-tête content-Length ne correspond pas à la longueur réelle du contenu dans la requête. |
| ERRORINFO_INVALID_METHOD_TRACE | Le client a envoyé la méthode HTTP TRACE qui n’est pas prise en charge par la passerelle applicative. |
| ERRORINFO_CLIENT_CLOSED_REQUEST | Le client a fermé la connexion à la passerelle applicative avant l’expiration du délai d’inactivité. Vérifiez si le délai d’inactivité du client est supérieur au délai d’inactivité défini pour la passerelle applicative. |
| ERRORINFO_REQUEST_URI_INVALID | Indique un problème avec l’URI (Uniform Resource Identifier) fourni dans la requête du client. |
| ERRORINFO_HTTP_NO_HOST_HEADER | Le client a envoyé une requête sans en-tête d’hôte (Host). |
| ERRORINFO_HTTP_TO_HTTPS_PORT | Le client a envoyé une requête HTTP simple à un port HTTPS. |
| ERRORINFO_HTTPS_NO_CERT | Indique que le client n’envoie pas de certificat TLS valide et correctement configuré lors de l’authentification TLS mutuelle. |
| Erreurs 5XX | Description |
|---|---|
| ERRORINFO_UPSTREAM_NO_LIVE | La passerelle applicative n’a pas trouvé de serveurs back-end actifs ou accessibles pour traiter les requêtes entrantes. |
| ERRORINFO_UPSTREAM_CLOSED_CONNECTION | Le serveur back-end a fermé la connexion de manière inattendue ou avant que la requête ait été entièrement traitée. Cette erreur peut se produire quand le serveur back-end atteint ses limites, plante, etc. |
| ERRORINFO_UPSTREAM_TIMED_OUT | La connexion TCP établie avec le serveur a été fermée, car la connexion a pris plus de temps que le délai d’attente configuré. |
Journal des performances
Le journal des performances n’est généré que si vous l’avez activé sur chaque instance Application Gateway, comme détaillé dans les étapes précédentes. Les données sont stockées dans le compte de stockage spécifié lors de l’activation de la journalisation. Les données du journal des performances sont générées par intervalles d’1 minute. Il est disponible uniquement pour la référence SKU v1. S’il s’agit de la référence SKU v2, utilisez les Métriques pour les données de performances. Les données suivantes sont enregistrées :
| Valeur | Description |
|---|---|
| instanceId | Instance Application Gateway pour laquelle les données des performances sont générées. Pour une passerelle Application Gateway à plusieurs instances, il y a une ligne par instance. |
| healthyHostCount | Nombre d’hôtes intègres dans le pool de back-ends. |
| unHealthyHostCount | Nombre d’hôtes défaillants dans le pool de back-ends. |
| requestCount | Nombre de requêtes traitées. |
| latency | Latence moyenne (en millisecondes) des requêtes à partir de l’instance vers le serveur principal qui traite les requêtes. |
| failedRequestCount | Nombre d’échecs de requêtes. |
| throughput | Débit moyen depuis le dernier journal, mesuré en octets par seconde. |
{
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayPerformance",
"time": "2016-04-09T00:00:00Z",
"category": "ApplicationGatewayPerformanceLog",
"properties":
{
"instanceId":"ApplicationGatewayRole_IN_1",
"healthyHostCount":"4",
"unHealthyHostCount":"0",
"requestCount":"185",
"latency":"0",
"failedRequestCount":"0",
"throughput":"119427"
}
}
Notes
La latence est calculée à partir de l’heure de la réception du premier octet de la requête HTTP jusqu’à l’heure de l'envoi du dernier octet de la réponse HTTP. Il s’agit de la somme du temps de traitement d’Application Gateway et du coût du réseau pour le serveur principal, ainsi que le temps pris par le serveur principal pour traiter la requête.
Journal du pare-feu
Le journal du pare-feu n’est généré que si vous l’avez activé sur chaque passerelle Application Gateway, comme détaillé dans les étapes précédentes. Ce fichier journal nécessite également que ce pare-feu d’applications web soit configuré sur une passerelle Application Gateway. Les données sont stockées dans le compte de stockage spécifié lors de l’activation de la journalisation. Les données suivantes sont enregistrées :
| Valeur | Description |
|---|---|
| instanceId | Instance Application Gateway pour laquelle les données du pare-feu sont générées. Pour une passerelle Application Gateway à plusieurs instances, il y a une ligne par instance. |
| clientIp | Adresse IP d’origine de la requête. |
| clientPort | Port d’origine de la requête. |
| requestUri | URL de la requête reçue. |
| ruleSetType | Type d’ensemble de règles. La valeur disponible est OWASP. |
| ruleSetVersion | Version d’ensemble de règles utilisée. Les valeurs disponibles sont 2.2.9 et 3.0. |
| ruleId | ID de règle de l’événement de déclenchement. |
| message | Message convivial pour l’événement de déclenchement. La section Détails vous fournit plus d’informations. |
| action | Action effectuée sur la requête. Les valeurs disponibles sont Blocked (Bloqué) et Allowed (Autorisé) (pour les règles personnalisées), Matched (Mis en correspondance) (quand une règle correspond à une partie de la requête), et Detected (Détecté) et Blocked (Bloqué) (il s’agit de deux règles obligatoires, selon que le pare-feu WAF est en mode de détection ou de prévention). |
| site | Site pour lequel le journal a été généré. Actuellement, seul Global est répertorié car les règles sont globales. |
| details | Détails de l’événement de déclenchement. |
| details.message | Description de la règle. |
| details.data | Données spécifiques trouvées dans la requête correspondant à la règle. |
| details.file | Fichier de configuration qui contenait la règle. |
| details.line | Numéro de ligne dans le fichier de configuration ayant déclenché l’événement. |
| hostname | Nom d’hôte ou adresse IP de la passerelle Application Gateway. |
| transactionId | ID unique d’une transaction donnée qui permet de regrouper plusieurs violations de règle qui se sont produites au cours de la même demande. |
{
"timeStamp": "2021-10-14T22:17:11+00:00",
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayFirewall",
"category": "ApplicationGatewayFirewallLog",
"properties": {
"instanceId": "appgw_2",
"clientIp": "185.42.129.24",
"clientPort": "",
"requestUri": "\/",
"ruleSetType": "OWASP_CRS",
"ruleSetVersion": "3.0.0",
"ruleId": "920350",
"message": "Host header is a numeric IP address",
"action": "Matched",
"site": "Global",
"details": {
"message": "Warning. Pattern match \\\"^[\\\\d.:]+$\\\" at REQUEST_HEADERS:Host .... ",
"data": "20.110.30.194:80",
"file": "rules\/REQUEST-920-PROTOCOL-ENFORCEMENT.conf",
"line": "791"
},
"hostname": "20.110.30.194:80",
"transactionId": "592d1649f75a8d480a3c4dc6a975309d",
"policyId": "default",
"policyScope": "Global",
"policyScopeName": "Global"
}
}
Afficher et analyser le journal d’activité
Vous pouvez afficher et analyser les données du journal d’activité en utilisant l’une des méthodes suivantes :
- Outils Azure : récupérez les informations du journal d’activité en utilisant Azure PowerShell, Azure CLI, l’API REST Azure ou le portail Azure. Des instructions pas à pas pour chaque méthode sont détaillées dans l’article Opérations d’activité avec Resource Manager.
- Power BI : si vous n’avez pas encore de compte Power BI, vous pouvez l’essayer gratuitement. À l’aide des applications du modèle Power BI, vous pouvez analyser vos données.
Affichage et analyse des journaux d’activité d’accès, des performances et du pare-feu
Les journaux d’activité Azure Monitor peuvent collecter les fichiers du compteur et du journal d’événements à partir de votre compte de stockage d’objets Blob. Il inclut des visualisations et des fonctionnalités puissantes de recherche pour analyser vos journaux d’activité.
Vous pouvez également vous connecter à votre compte de stockage et récupérer les entrées de journal d’activité JSON pour les journaux d’activité d’accès et des performances. Après avoir téléchargé les fichiers JSON, vous pouvez les convertir en CSV et les afficher dans Excel, PowerBI ou tout autre outil de visualisation de données.
Conseil
Si vous savez utiliser Visual Studio et les concepts de base de la modification des valeurs de constantes et variables en C#, vous pouvez utiliser les outils de convertisseur de journaux disponibles dans GitHub.
Analyse des journaux d’activité d’accès via GoAccess
Nous avons publié un modèle Resource Manager qui installe et exécute le célèbre analyseur de journal d’activité GoAccess pour les journaux d’activité d’accès Application Gateway. GoAccess fournit des statistiques de trafic HTTP précieuses telles que les visiteurs uniques, les fichiers demandés, les hôtes, les systèmes d’exploitation, les navigateurs ou les codes d’état HTTP. Pour plus d’informations, consultez le fichier Lisez-moi dans le dossier de modèles Resource Manager dans GitHub.
Étapes suivantes
- Visualisez le compteur et les journaux des événements à l’aide des journaux d’activité Azure Monitor.
- Billet de blog sur la visualisation de votre journal d’activité Azure avec Power BI.
- Billet de blog sur l’affichage et l’analyse des journaux d’activité Azure dans Power BI.