Partager via

Résolution des problèmes de performances IIS ou des erreurs d’application à l’aide de LogParser

par Benjamin Perkins

Outils et connaissances utilisés dans cet utilitaire de résolution des problèmes

Vue d’ensemble

Cet utilitaire de résolution des problèmes vous aidera à analyser les fichiers journaux IIS dans le but de déterminer la cause de l’échec ou de l’échec d’une application hébergée sur IIS. Avant de commencer, il est important de noter que tous les champs que IIS peut enregistrer ne sont pas activés par défaut. Par exemple, les octets envoyés et les octets reçus ne sont pas sélectionnés, mais ils sont très utiles lors de la résolution d’un problème de performances. Par conséquent, le meilleur moment pour inclure ces champs supplémentaires est avant de rencontrer des problèmes système. Par conséquent, si vous ne l’avez pas déjà fait, sélectionnez ces champs supplémentaires, ils vous aideront à trouver des solutions lorsque des problèmes se produisent.

Le blog suivant explique comment effectuer cette opération sur IIS 7+ :

Modification des données de journal IIS 7 dans Windows 2008

Scénario

En tant qu’administrateur de systèmes, vous commencez à entendre des rapports des utilisateurs de votre système hébergé sur IIS que la réponse est lente. Il y a quelques mentions que les navigateurs web expirent ou arrêtent de répondre complètement lorsqu’ils accèdent à votre site web.

Vous passez en action et recyclez le processus de travail ; tout semble fonctionner à nouveau, comme normal.

Toutefois, vous ne pouvez pas accepter cela comme solution et avoir besoin de savoir pourquoi cela s’est produit, mais ne savez pas où commencer. Vous n’avez aucun détail des utilisateurs, tels que les codes d’erreur, les captures d’écran et pires, vous n’avez pas de données de performances pour comparer ce qui vient d’arriver à des performances normales. Dans de nombreux cas, d’autres nouveaux problèmes vous éloignent de toute analyse sérieuse de la cause racine.

LogParser de Microsoft est un bon outil rapide et facile à utiliser. Dans de nombreuses situations, l’outil vous aidera à mieux comprendre ce qui s’est passé sur le serveur et peut vous aider à identifier les problèmes. Vous pouvez prendre les informations que vous collectez avec LogParser et la transmettre à votre équipe de base de données, à votre équipe réseau ou à vos développeurs pour plus d’analyse.

Collecte de données

Par défaut, les fichiers journaux IIS se trouvent dans les répertoires suivants :

  • IIS 7 et versions ultérieures : %SystemDrive%\inetpub\logs\LogFiles
  • IIS 6 et versions antérieures : %WinDir%\System32\LogFiles

Dans cet utilitaire de résolution des problèmes, j’utilise IIS 8. Ouvrez le Gestionnaire des services Internet et sélectionnez Sites, comme illustré dans la figure 1. Cela vous indique l’ID de chaque site web hébergé sur votre serveur. Vous aurez besoin de cet ID pour déterminer le répertoire W3SVC* à analyser.

Capture d’écran de la fenêtre I S Manager montrant Sites dans le volet principal.
Figure 1 : Obtention de l’ID de votre site web

Ouvrez l’Explorateur Windows et accédez au répertoire qui contient les fichiers journaux IIS du site web qui ont rencontré le problème de performances. La figure 2 montre comment cela peut ressembler.

Capture d’écran de l’Explorateur Windows montrant les emplacements des fichiers.
Figure 2 : Emplacement du fichier journal IIS

Les fichiers journaux IIS peuvent être assez volumineux ; Par exemple, dans la figure 2, le fichier journal u_ex12101858.log est de près de 100 Mo de taille. Étant donné que ces fichiers journaux peuvent être énormes et contiennent des centaines de milliers d’entrées de fichier journal individuelles, la recherche manuelle de chacun de ces fichiers pour une erreur n’est pas une bonne approche et retourne peu de résultats pour le temps que vous investissez.

C’est là que LogParser devient un outil indispensable dans votre arsenal de résolution des problèmes.

Analyse des données

Votre première étape consiste à déterminer quels fichiers journaux peuvent contenir des erreurs. Par exemple, si les clients se plaignaient des performances le 3 juin 2012, le fichier journal peut être u_ex120603.log, où :

  • « 12 » est l’année abrégée pour 2012
  • « 06 » fait référence au sixième mois (juin)
  • « 03 » est le 3e jour du mois

Remarque : L’exemple ci-dessus suppose que la journalisation IIS est configurée pour faire pivoter les fichiers journaux quotidiennement, ce qui est la valeur par défaut. Si vous avez modifié les paramètres d’IIS pour faire pivoter les fichiers journaux selon un intervalle de temps différent, tel que hebdomadaire ou horaire, les noms des fichiers journaux seraient différents. Pour plus d’informations sur la syntaxe des noms de fichiers journaux IIS, consultez l’article IIS Log File Naming Syntax (https://support.microsoft.com/kb/242898).

Notes

Par défaut, la date et l’heure dans les journaux IIS sont stockées à l’aide de GMT ; vous devez tenir compte de cette situation lorsque vous déterminez quels journaux contiennent des erreurs. Cela étant dit, vous pouvez ajuster les dates/heures à l’aide de la TO_LOCALTIME() fonction logParser, comme illustré dans l’exemple suivant :

Notes

logparser.exe "SELECT TO_STRING(TO_LOCALTIME(TO_TIMESTAMP(date,time)),'yyyy-MM-dd hh:mm:ss') AS LocalTime,
COUNT(*) AS Hits FROM *.log WHERE date='2012-10-18'
GROUP BY LocalTime ORDER BY LocalTime" -i:w3c

Une fois que vous avez identifié les fichiers journaux IIS qui contiennent des erreurs, vous devez les copier vers un emplacement où ils peuvent être analysés. Cette étape est facultative, mais il n’est pas recommandé d’analyser vos journaux sur votre serveur IIS, car vos requêtes LogParser peuvent prendre beaucoup de temps et si vos fichiers journaux sont volumineux, l’analyseur de journaux peut concurrencer les ressources système.

Par exemple, vous pouvez copier vos journaux IIS dans un dossier sur votre ordinateur personnel où vous avez déjà copié les fichiers LogParser, c’est-à-dire comment j’analyse généralement mes fichiers journaux. La figure 3 montre un exemple d’emplacement où je les ai stockées pour créer cet article.

Capture d’écran de l’Explorateur Windows montrant l’emplacement de l’exécutable de l’analyseur de journal.Figure 3 : Fichiers journaux IIS hébergés localement pour analyse à l’aide de LogParser

Une fois que vous avez téléchargé LogParser, vous êtes prêt à commencer l’analyse. La première requête que j’exécute est illustrée à la figure 4. Les résultats vous donnent une vue d’ensemble de la façon dont IIS répond aux demandes.

logparser.exe "SELECT sc-status, sc-substatus, COUNT(*) FROM *.log GROUP BY sc-status, sc-substatus ORDER BY sc-status" -i:w3c
    
    sc-status sc-substatus COUNT(ALL *)
    --------- ------------ ------------
    200       0            3920658
    206       0            2096
    301       0            1031
    302       0            65386
    304       0            178705
    400       0            35
    401       2            692096
    404       0            2935
    404       11           7
    405       0            1
    406       0            36
    500       0            11418
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    12
    Execution time:     7.70 seconds

Figure 4 : Requête LogParser (sc-status et sc-substatus)

Les points d’intérêt dans les résultats sont les suivants :

  • Rapport entre 200 et 304 codes d’état HTTP (demandes réussies)
  • Nombre de 500 codes d’état HTTP (demandes ayant échoué)

L’importance de chacun de ces codes d’état est expliquée ci-dessous.

Rapport entre les codes d’état HTTP 200 et 304 (analyse des demandes réussies)

Le rapport entre les codes d’état HTTP 200 et 304 est important, car il indique le nombre de demandes récupérées à partir du cache des clients plutôt que directement à partir du serveur. Les résultats de la figure 4 montrent qu’il y a 3 920 658 requêtes qui ont entraîné un code d’état HTTP de 200. Cela signifie que le fichier demandé a été servi à partir du serveur chaque fois. En revanche, 178 705 requêtes ont abouti à un code d’état HTTP 304. Cela signifie que le fichier demandé a été récupéré à partir du cache local. En d’autres termes, 95,5 % des demandes sont traitées à partir du serveur.

La mise en cache peut avoir un impact très positif sur les performances de votre système ; consultez les détails de la compression statique et dynamique dans l’article Configuration de la compression HTTP dans IIS 7 .

Codes d’état HTTP 500 (analyse des demandes ayant échoué)

Les codes d’état HTTP 500 peuvent indiquer des problèmes graves sur votre système. Le niveau d’impact que la cause racine d’une erreur HTTP 500 peut avoir sur votre système peut aller de rien au blocage d’un processus worker. Par conséquent, lorsque vous les voyez, vous devez exécuter la requête affichée dans la figure 5 pour rechercher les requêtes qui ont abouti à un code d’état HTTP 500.

logparser.exe "SELECT cs-uri-stem, COUNT(*) FROM *.log WHERE sc-status=500 GROUP BY cs-uri-stem ORDER BY COUNT(*) DESC" -i:w3c
    
    cs-uri-stem                 COUNT(ALL *)
    --------------------------- ------------
    /ShoppingCart/ViewCart.aspx 1378
    /DataService.asmx           1377  
    /Start/default.aspx         949
    /GetDetailsView.aspx        753
    /Details/ImageUrls.asmx     722
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    5
    Execution time:     24.89 seconds

Figure 5 : Requête LogParser (cs-uri-stem avec 500 sc-status)

Ces résultats indiquent le chemin d’accès et le nom du fichier qui, lorsque demandé, a répondu avec un code d’état HTTP 500. Ce type d’information serait utile à l’équipe de développement. Par exemple, l’équipe de développement peut examiner ce code spécifique et rechercher du code qui s’exécute sans être contenu dans un try {...} catch {...} bloc de code, ou exécuter des requêtes de données volumineuses qui doivent être optimisées.

Prenons cet exemple pour aller plus loin et nous concentrer sur le contributeur principal pour les codes d’état HTTP 500. Il serait intéressant de savoir quand ces erreurs se sont produites, car ces informations peuvent être utilisées pour vérifier si les dépendances rencontraient des problèmes en même temps.

logparser.exe "SELECT TO_STRING(TO_TIMESTAMP(date,time),'yyyy-MM-dd hh') AS Hour,
COUNT(*) FROM *.log WHERE sc-status=500 AND cs-uri-stem='/Start/default.aspx' AND date='2012-10-18' GROUP BY Hour ORDER BY Hour" -i:w3c
    
    Hour          COUNT(ALL *)
    ------------- ------------
    2012-10-18 08 191
    2012-10-18 09 163
    2012-10-18 14 150
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    3
    Execution time:     6.36 seconds

Figure 6 : Requête LogParser (cs-uri-stem avec 500 sc-status)

Le sous-ensemble des résultats de la figure 6 limite la plage de dates du problème. Ces informations peuvent être transmises au réseau, à la base de données, aux administrateurs du système d’exploitation et aux équipes de développement pour vérifier si d’autres événements se produisaient en même temps. Par exemple : Y a-t-il des problèmes supplémentaires entre 08:00 et 09:59:59 GMT et entre 14:00:00 et 14:59:59 GMT ?

L’ensemble suivant de requêtes LogParser utilise les champs suivants, ce qui peut donner un meilleur aperçu des problèmes de performances :

Champ Description Activée par défaut
temps nécessaire Durée pendant laquelle l’action a été effectuée, en millisecondes Oui
sc-bytes Nombre d’octets envoyés par le serveur Non
cs-bytes Nombre d’octets reçus par le serveur Non

Comme mentionné précédemment, prenez le temps de demander les champs sc-bytes et cs-bytes activés ou, si possible, activez-les vous-même. Ils fournissent des informations précieuses sur votre système et son comportement. Prenez la figure 7, par exemple. Vous voyez que le temps moyen est assez bon à quelques centaines de millisecondes. Toutefois, regardez le temps maximal nécessaire, c’est trop de temps.

logparser.exe "SELECT  cs-method, COUNT(*) AS TotalCount, MAX(time-taken) AS MaximumTime, AVG(time-taken) AS AverageTime FROM *.log GROUP BY cs-method ORDER BY TotalCount DESC" -i:w3c
    
    cs-method TotalCount MaximumTime AverageTime
    --------- ---------- ----------- -----------
    GET       3172034    1366976     153
    POST      1011765    256539      359  
    HEAD      5363       26750       209  
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    3
    Execution time:     6.36 seconds

Figure 7 : Requête LogParser (MAX et AVG)

Je sais que vous vous posez déjà la prochaine question qui doit être répondue. Quelle demande prend tellement de temps ? La figure 8 montre la réponse à cette question. Comme vous le remarquerez, j’ai avancé et inclus le champ sc-octets dans la requête LogParser. N’oubliez pas que les octets sc représentent la taille du fichier envoyé du serveur au client.

logparser.exe "SELECT cs-uri-stem, time-taken, sc-bytes FROM *.log WHERE time-taken > 250000 ORDER BY time-taken DESC" -i:w3c
    
    cs-uri-stem                 time-taken sc-bytes
    --------------------------- ---------- --------
    /ShoppingCart/ViewCart.aspx 1366976    256328
    /DataService.asmx           1265383    53860
    /Start/default.aspx         262796     8077
    /GetDetailsView.aspx        261305     5038
    /Details/ImageUrls.asmx     256539     2351
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    5
    Execution time:     8.98 seconds

Figure 8 : Requête LogParser (MAX et AVG)

Nous sommes probablement tous d’accord que le temps nécessaire pour les demandes dépasse un temps de réponse « normal ». Toutefois, la taille des fichiers est quelque chose que l’administrateur ou le développeur doit analyser pour déterminer si les tailles se trouvent dans une plage acceptable.

La conclusion est que le fichier GetDetailsView.aspx a jeté un certain nombre de codes d’état HTTP 500 et qu’à un moment donné, il a fallu beaucoup de temps pour terminer, même s’il s’agissait d’un fichier relativement petit. Vous pouvez examiner la date et l’heure des problèmes qui se produisent pour ce fichier et examiner le code dans le fichier avec tous les problèmes qui se sont produits. (Par exemple, les journaux IIS contiennent une liste de variables qui ont été transmises dans la chaîne de requête; vous pouvez vérifier ces valeurs pour les données incorrectes.)

Les exemples fournis dans les chiffres 4 - 8 aident à comprendre où existe la cause racine d’un problème. Toutefois, il est probable que cette analyse n’ait rendu qu’une meilleure vue de la situation qui entraînera davantage de questions et une analyse plus approfondie. Si c’est le cas, vous pouvez créer une représentation de ces données de manière plus présentable. La section suivante décrit cela en détail.

Rapports

Captures d’écran d’une fenêtre de commande contenant des requêtes LogParser et leurs résultats peuvent être corrects pendant la phase d’analyse d’un problème de performances; toutefois, si vous devez aller devant les gestionnaires ou les administrateurs pour expliquer ce qui s’est passé, il se peut qu’il ne réponde pas à la marque.

Notes

Pour que le graphique fonctionne via LogParser, vous devez installer le Office Web Components. Les articles suivants expliquent comment procéder :

La figure 9 montre la requête LogParser pour créer un graphique en secteurs 3D contenant le nombre de requêtes et leur code d’état HTTP associé. J’ai supprimé l’état 200, car ceux-ci réussissent. Ce que je suis après voici les demandes qui sont quelque chose d’autre que OK.

logparser.exe "SELECT sc-status AS Status, COUNT(*) AS Count INTO status.gif FROM *.log WHERE sc-status > 200 GROUP BY Status ORDER BY Status" -i:w3c -o:CHART -chartType:PieExploded3D -ChartTitle:"Request Status"
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    10
    Execution time:     6.20 seconds

Figure 9 : Requête LogParser (Créer un graphique en secteurs 3D)

Le résultat de la requête est illustré dans la figure 10. Il existe plusieurs paramètres supplémentaires que vous pouvez transmettre à LogParser qui affectent l’image. Par exemple, légende, groupSize, config, etc... Pour obtenir une liste complète, entrez : LogParser -h -o:CHART pour obtenir la liste de tous les paramètres. Cette commande fournit également une liste des différents types de graphiques.

Diagramme d’un graphique en secteurs à trois dimensions montrant les allocations d’état des demandes.
Figure 10 : Graphique en secteurs LogParser 3D

Un autre graphique utile est le ratio entre les requêtes mises en cache et réelles. Rappelez-vous de la section Analyse des données où j’ai discuté qu’un code d’état HTTP de 200 signifie que les fichiers demandés sont récupérés à partir du serveur, mais qu’un 304 est récupéré à partir du client. La figure 11 montre la requête LogParser pour la création de ce graphique. Notez que j’ai utilisé le paramètre -values .

logparser.exe "SELECT sc-status AS Status, COUNT(*) AS Count INTO cache.gif FROM *.log WHERE sc-status=200 OR sc-status=304 GROUP BY Status ORDER BY Status" -i:w3c -o:CHART -chartType:PieExploded3D -ChartTitle:"Cache" -values:ON
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    2
    Execution time:     6.35 seconds

Figure 11 : Requête LogParser (Créer un graphique en secteurs 3D)

Bien que la différence entre le code d’état HTTP 200 et 304 soit clairement visible, j’ai pensé qu’il peut ajouter une valeur pour inclure le nombre d’accès pour chacun d’eux. La figure 12 illustre la sortie de la requête LogParser précédente.

Diagramme d’un graphique en secteurs à trois dimensions montrant l’allocation du cache.
Figure 12 : Graphique en secteurs LogParser 3D

Je pense que vous obtenez l’image maintenant sur la façon dont le graphique des journaux IIS à l’aide de LogParser peut aider à transmettre ce qui se passe beaucoup mieux qu’une table de données. Mais avant d’arrêter, je veux vous montrer un autre exemple à l’aide du type de graphique en colonnes. La requête LogParser affichée dans la figure 13 produit un graphique en colonnes 3D montrant le nombre de 500 codes d’état HTTPS par heure.

logparser.exe "SELECT to_string(to_timestamp(date, time), 'yyyy-MM-dd hh') AS Hour, COUNT(*) AS Count INTO 500.gif FROM *.log WHERE sc-status=500 GROUP BY Hour ORDER BY Hour" -i:w3c -o:CHART -chartType:Column3D -ChartTitle:"500 Errors by Hour"
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    13
    Execution time:     6.32 seconds

Figure 13 : Requête LogParser (Créer un graphique en colonnes 3D)

Le graphique résultant est illustré dans la figure 14.

Diagramme d’un graphique en colonnes à trois dimensions montrant le nombre de 500 erreurs par heure par date.
Figure 14 : Graphique en colonnes 3D LogParser

Création de graphiques à l’aide d’Excel et CSV

Au début de cette section, j’ai mentionné que l’installation du composant Web Office (OWC) est requise si vous souhaitez utiliser les fonctionnalités de graphique LogParser. Dans votre organisation, il peut y avoir des restrictions qui interdisent cela ou vous ne souhaiterez peut-être pas l’installer. Si l’un des deux est le cas, envisagez d’exporter le résultat de la requête LogParser vers un fichier CSV et de l’importer dans Excel.

La figure 15 montre la requête LogParser qui extrait les codes d’état HTTP pour toutes les requêtes qui ne sont pas 200 dans un fichier CSV.

logparser.exe "SELECT sc-status AS Status, COUNT(*) AS Count INTO status.csv FROM *.log WHERE sc-status > 200 GROUP BY Status ORDER BY Status" -i:w3c -o:csv
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    10
    Execution time:     6.20 seconds

Figure 15 : Requête LogParser (Créer un fichier CSV pour l’importation dans Excel)

Notez dans la figure 15 que j’ai utilisé le paramètre -o afin que LogParser crée la sortie au format CSV.

Pour importer le fichier CSV dans Excel afin qu’un graphique puisse être créé à partir de celui-ci, ouvrez Excel, accédez à l’onglet DATA et sélectionnez À partir du texte. La figure 16 montre ce que cela ressemble.

Capture d’écran montrant les options du menu onglet Données Excel.Figure 16 : Importer un fichier CSV créé par LogParser dans Excel

Sélectionnez le fichier status.csv créé par la requête LogParser et parcourez l’Assistant Importation. Importez le fichier CSV délimité par des virgules et vous allez finir par l’état dans la colonne A et le nombre d’occurrences pour chaque état de la colonne B. Cela suppose que vous avez exécuté la requête LogParser indiquée dans la figure 15. Enfin, sélectionnez toutes les données de la colonne A et B, y compris les en-têtes et choisissez le type de graphique à secteurs à créer. La figure 17 montre comment cela peut ressembler.

Capture d’écran montrant les options d’onglet Insertion Excel. Les données des colonnes A et B sont sélectionnées.Figure 17 : Créer un graphique à secteurs à l’aide d’un fichier CSV

Le résultat final est un graphique en secteurs, figure 18 similaire à celle indiquée précédemment dans la figure 10. Il existe de nombreuses options en ce qui concerne la couleur, le type de graphique, les étiquettes, etc. Avec un clic sur un bouton, vous pouvez modifier le type de graphique de secteurs en barre ou en ligne. Il existe beaucoup d’options pour créer des graphiques professionnels à l’intérieur d’Excel.

Capture d’écran d’un graphique en secteurs à trois dimensions montrant l’état de la demande.
Figure 18 : Graphique en secteurs utilisant un fichier CSV similaire à la figure 10

Il existe autant d’options et de possibilités d’analyse et de présentation des résultats de cette analyse à l’aide de LogParser. Pour obtenir des conseils et des exemples supplémentaires, consultez ces articles écrits par Robert McMurray. Il existe également un fichier d’aide très utile et de nombreux scripts préécrits fournis dans le package d’installation de LogParser. La section suivante traite de cette rubrique et d’autres rubriques plus en détail.

Aide

Lorsque vous installez LogParser 2.2 sur votre ordinateur, il s’installe par défaut dans le C:\Program Files (x86)\Log Parser 2.2 répertoire. Accédez à cet emplacement et passez en revue les répertoires Samples\Requêtes et Samples\Scripts pour obtenir une offre abondante de code préécrit qui vous permettra de passer rapidement.

Vous réaliserez également un grand avantage en lisant le contenu dans le fichier LogParser.chm.

Réduction de la taille ou du fractionnement des fichiers journaux IIS

Vous pouvez rencontrer une situation où le fichier journal IIS est trop volumineux pour que LogParser interroge. Il s’agit probablement d’un ordinateur 32 bits, mais peut se produire sur un ordinateur 64 bits également. Néanmoins, si vous rencontrez des erreurs « hors mémoire » lors de l’exécution d’une requête LogParser, envisagez d’exécuter la commande indiquée dans la figure 19. La requête extrait certains champs essentiels d’un fichier journal IIS volumineux et les place dans un autre, ce qui entraîne un fichier journal plus petit.

logparser.exe "SELECT date, time, c-ip, cs-uri-stem, cs-uri-query, sc-status, sc-substatus, sc-win32-status, sc-bytes, cs-bytes, time-taken INTO u_exJUSTRIGHT.log FROM u_exTOOBIG.log" -i:w3c -o:w3c
    
    Statistics:
    -----------
    Elements processed: 19712301
    Elements output:    19712301
    Execution time:     3.07 seconds

Figure 19 : Réduction de la taille d’un fichier journal IIS (en supprimant les champs)

Dans cet exemple, j’ai réalisé une réduction de taille de fichier d’environ 45 %. Dans de nombreux cas, cela peut être suffisant, dans d’autres peut-être pas. Cela dépend de la taille du fichier journal d’origine. Si vous constatez que vous devez toujours réduire la taille du fichier journal IIS, envisagez d’ajouter une contrainte d’heure de date à la requête LogParser, comme illustré dans la figure 20.

logparser.exe "SELECT date, time, c-ip, cs-uri-stem, cs-uri-query, sc-status, sc-substatus, sc-win32-status, sc-bytes, cs-bytes, time-taken INTO u_exJUSTRIGHT.log FROM u_exTOOBIG.log WHERE to_timestamp(date, time) >= timestamp('2012-11-09 00:00:00', 'yyyy-MM-dd hh:mm:ss')" -i:w3c -o:w3c
    
    Statistics:
    -----------
    Elements processed: 240123
    Elements output:    240123
    Execution time:     0.45 seconds

Figure 20 : Réduire davantage la taille d’un fichier journal IIS en ajoutant une clause WHERE

Il s’agit d’une technique précieuse pour réduire la taille du fichier, mais il est également utile de supprimer les entrées indésirables du journal IIS. Par exemple, quand vous commencez à résoudre un problème, vous réalisez que les octets de temps, les octets sc et cs-bytes n’étaient pas enregistrés. Vous les avez activés dans IIS et souhaitez que la requête analyse uniquement ces entrées avec les champs récemment activés. Utilisez l’instruction where pour extraire les données du fichier journal IIS à partir de l’heure dans laquelle ces champs ont été activés. Cela est important lorsque vous utilisez les agrégats AVG, MIN et MAX.

Conclusion

LogParser est un outil petit mais puissant pour analyser un certain nombre de types de journaux système différents. Cet article s’est concentré sur les requêtes applicables aux journaux IIS. Lorsque des problèmes de performances ou des erreurs sont rencontrés dans votre environnement IIS, il est parfois difficile de savoir où démarrer.

LogParser peut être utilisé comme point de départ, car un administrateur système disposant de certaines compétences SQL peut rapidement créer des requêtes LogParser très sophistiquées. Ces requêtes peuvent être utilisées pour approfondir l’analyse de la cause racine du problème.

Voici les liens qui sont mentionnés dans cet article, ainsi que quelques liens avec des informations supplémentaires.