Log Parser 2.2 et ASP.NET

Un petit arrière-plan du problème

Votre client rencontre un problème « Accès refusé » lorsqu’il a fait quelque chose. Vous recommandez au client d’utiliser un autre outil brillant nommé
Filemon et de reproduire le problème. S’il s’agit d’un problème avec les listes de contrôle d’accès des ressources, l’outil Filemon sera en mesure d’intercepter l’erreur. À présent, vous demandez au client de vous envoyer le fichier journal Filemon enregistré. Voici la partie malheureuse. Vous obtenez le fichier (par exemple, Filemon.log), mais vous constatez que la taille est énorme (Filemon enregistre beaucoup de données!). Le Bloc-notes semble se bloquer et sera péniblement lent pour trouver les lignes « Accès refusé » dans le fichier journal. Microsoft Office Excel refusera d’ouvrir complètement le fichier. Quoi encore?

Réponse : Ouvrez la fenêtre de commande Log Parser et utilisez la commande suivante :

LOGPARSER « Select Text from C:\Filemon.log where Text like '%Access Denied%' » -i:TEXTLINE -q:OffQu’est-ce que nous disons à l’outil Log Parser qu’il faut analyser chaque ligne (Text) à partir du fichier donné (C:\Filemon.log) où la ligne contient « Accès refusé ». Le commutateur de ligne de commande -i:TEXTLINE spécifie le format d’entrée, et le commutateur de ligne de commande -q:Off indique qu’il doit être détaillé (-q[:ON|OFF]:mode silencieux;). Si vous activez le commutateur de ligne de commande -q, les statistiques affichées et le nom du champ (Texte) dans la sortie ci-dessous seront absents.

Exemple de sortie

Texte7447 1:49:24 PM explorer.exe:1200 RÉPERTOIRE C:\ Statistiques d’accès refuséÉléments traités : 640444
Sortie des éléments : 1
Durée d’exécution : 12,75 secondes

Comment éviter d’appuyer plusieurs fois sur Entrée si le nombre d’enregistrements retournés par votre requête est supérieur à 10 ?

Réponse : Utilisez le paramètre -rtp:-1 dans vos requêtes !

Il s’agit d’un paramètre nécessaire si vous souhaitez rediriger la sortie vers un fichier. En outre, lorsque vous écrivez dans STDOUT, les enregistrements de sortie sont affichés dans des lots composés d’un nombre de lignes égal à la valeur spécifiée pour ce paramètre. Une fois qu’un lot de lignes a été affiché, il invite l’utilisateur à appuyer sur une touche pour afficher le lot de lignes suivant. La spécification de « -1 » pour ce paramètre désactive complètement le traitement par lot !

Utilisation de fichiers de requête

Une autre façon d’obtenir les mêmes résultats d’une manière plus propre consiste à créer un fichier de requête. De cette façon, vous pouvez facilement modifier votre fichier de requête et l’exécuter à partir de la ligne de commande de l’outil Log Analyseur. En dehors de cela, vous pouvez facilement créer une interface graphique graphique selon vos goûts. L’interface graphique utilisateur charge la requête SQL enregistrée et exécute la requête à l’aide de l’outil Log Parser.

Si vous souhaitez obtenir le même effet (comme dans le scénario 1) à partir des requêtes SQL, vous pouvez fournir la commande suivante :

LOGPARSER -i:TEXTLINE file:C:\LPQ\SearchAnyTextfile.sql -q:offC:\LPQ\SearchAnyTextFile.sql contient les informations suivantes :

Remarque Créer un dossier LPQ dans votre C:\ pour utiliser les exemples présentés dans cette colonne.

Select Text as LineFromFile
FROM C:\Filemon.log 
WHERE Text 
LIKE '%Access Denied%'

Si vous remarquez, la requête semble maintenant beaucoup plus propre et plus logique. De cette façon, vous pouvez également créer des requêtes plus complexes et plus volumineuses, et tout s’adaptera à votre ligne de commande, car vous utilisez . Fichier SQL au lieu de la requête entière. De toute façon, il n’est pas possible de placer plus de 260 caractères sur la ligne de commande !

En conservant les avantages de l’utilisation des fichiers de requête, j’utiliserai cette méthode dans les scénarios suivants. J’ai toutes mes requêtes enregistrées dans C:\LPQ avec une extension .sql (vous pouvez utiliser la vôtre).

Un petit arrière-plan du problème

Vous disposez d’un dossier, et il contient un certain nombre de sous-dossiers et de fichiers. Vous souhaitez connaître les 10 fichiers les plus volumineux de ce dossier, y compris ses sous-dossiers.

Je sais que, pour un dossier spécifique, vous pouvez simplement modifier l’affichage (dans le menu Affichage, cliquez sur Détails) dans Windows Explorer et trier l’affichage par taille. Mais le problème ici est que vous devez également tenir compte du contenu du sous-dossier.

Réponse : Ouvrez la fenêtre de commande de l’outil Log Parser et utilisez la commande suivante :

LOGPARSER -i:FS file:C:\LPQ\Top10Files.sql -q:off -Recurse:-1Top10Files.sql contient les éléments suivants :

SELECT TOP 10 
Path, 
Name, 
Size, 
Attributes 
FROM 'C:\Program Files\Microsoft Office\*.*' 
ORDER BY Size DESC

Ici , -i:FS signifie que nous interrogeons le système de fichiers. Vous pouvez afficher la liste complète des champs de format d’entrée FS dans la documentation et encadrer votre requête en conséquence.

-Recurse:-1 implique que nous voulons inclure tous les sous-dossiers. Si vous ne souhaitez pas tous les sous-dossiers ou que vous souhaitez limiter la récursivité, utilisez 0, 1, 2, etc. Le nombre implique la profondeur dans laquelle l’analyseur va aller. 0 signifie aucune récursivité, 2 signifie que l’analyseur revient jusqu’à la profondeur 2, etc.

Exemple de sortie

Path                                                         Name         Size     Attributes 
------------------------------------------------------------ ------------ -------- ----------
C:\Program Files\Microsoft Office\Office10\WINWORD.EXE       WINWORD.EXE  10738448 -A--R----
C:\Program Files\Microsoft Office\Office10\EXCEL.EXE         EXCEL.EXE    9358096  -A--R----
C:\Program Files\Microsoft Office\Office10\OUTLLIB.DLL       OUTLLIB.DLL  6326984  -A-------
C:\Program Files\Microsoft Office\Office10\POWERPNT.EXE      POWERPNT.EXE 6093584  -A--R----
C:\Program Files\Microsoft Office\Office10\MSOWC.DLL         MSOWC.DLL    3041880  -A-------
C:\Program Files\Microsoft Office\Office10\CLIPPIT.ACS       CLIPPIT.ACS  2904417  -A-------
C:\Program Files\Microsoft Office\Office10\GRAPH.EXE         GRAPH.EXE    2144824  -A-------
C:\Program Files\Microsoft Office\Office10\1033\OUTLLIBR.DLL OUTLLIBR.DLL 1977032  -A-------
C:\Program Files\Microsoft Office\Office10\1033\XLMAIN10.CHM XLMAIN10.CHM 1646072  -A-------
C:\Program Files\Microsoft Office\Office10\MSOWCW.DLL        MSOWCW.DLL   1200177  -A-------

StatisticsElements traités : 1000
Sortie des éléments : 10
Durée d’exécution : 0,42 seconde

Un petit arrière-plan du problème

Vous utilisez Microsoft Internet Information Services (IIS) 6, avez quelques ASP.NET sites Web et n’êtes pas vraiment satisfait des performances. Vous souhaitez ajuster le serveur et connaître les 20 premières pages qui prennent le plus de temps à traiter à partir du serveur web. Ce n’est pas comme si vous déterminiez les pages qui prennent le plus de temps, que vous les corrigez et que vos problèmes sont résolus. Malheureusement, il n’existe pas de solution miracle pour résoudre les problèmes de performances. Au moins, il devrait y avoir un moyen de commencer. Correcte?

Réponse : Ouvrez la fenêtre de commande Log Parser et utilisez la commande suivante :

LOGPARSER -i:IISW3C file:C:\LPQ\Slowest20FilesInIIS.sql -o:DataGrid -q:offSlowest20FilesInIIS.sql contient l’exemple de code suivant.

Select Top 20
LogRow as [Line Number],
date as [Date],
time as [Time],
c-ip as [Client-IP],
s-ip as [Server IP], 
s-port as [Server Port],
cs-method as [Request Verb],
cs-uri-stem as [Request URI],
sc-bytes as [Bytes sent],
sc-status as [Status],
sc-substatus as [Sub-status],
sc-win32-status as [Win 32 Status],
time-taken as [Time Taken]
From 
C:\ex060813.log
Order by time-taken desc

Ici, -i:IISW3C signifie que nous interrogeons les journaux IIS W3C. Vous pouvez afficher la liste complète des champs de format d’entrée IISW3C dans la documentation et cadrer votre requête en conséquence.

-o:DataGrid implique que la sortie doit être affichée dans une grille de données comme suit :



Remarque Pour utiliser cette requête, vous devez utiliser la journalisation IISW3C et avoir activé les propriétés de journalisation avancées. (Ouvrez les propriétés de votre site Web, cliquez sur l’onglet Site web , sélectionnez Activer la journalisation, puis définissez le format de journal actif sur W3C Extended Log File Format. Cliquez sur Propriétés, sur l’onglet
Avancé , puis cliquez sur pour sélectionner toutes les options.)

Un petit arrière-plan du problème

Vous utilisez IIS 6, disposez de quelques sites web ASP.NET et souhaitez connaître les fichiers .aspx les plus couramment utilisés afin que si vous réglez les performances de ces pages, l’ensemble du site web/serveur en bénéficie. Il est toujours préférable de passer du temps à ajuster les pages les plus utilisées plutôt que les pages qui sont utilisées avec parcimonie. (Bien qu’il puisse y avoir des exceptions à cette règle. Supposons que la page utilisée avec parcimonie est une page vraiment mauvaise qui provoque une utilisation élevée du processeur pour cela !) Maintenant, si vous constatez qu’une certaine page prend beaucoup de temps à être servie (scénario 3) et que la page est l’une des pages les plus couramment utilisées, vous devez toujours vérifier que la page se comporte bien en cas de stress.

Réponse : Ouvrez la fenêtre de commande de l’outil Log Parser et utilisez la commande suivante :

LOGPARSER -i:IISW3C file:C:\LPQ\Popular20FilesInIIS.sql -chartType:Bar3D -groupSize:640x480 -view:onPopular20FilesInIIS.sql contient l’exemple de code suivant.

Select Top 20
cs-uri-stem as [Request URI],
COUNT(*) AS Hits 
INTO MyChart.gif 
FROM C:\ex060813.log
Group by cs-uri-stem ORDER BY Hits DESC

Dans ce cas, -chartType:Bar3D indique à l’outil Log Parser le type de graphique à préparer. Le paramètre -groupSize spécifie la largeur et la hauteur de l’image cible, en pixels. L’ensemble des types de graphiques disponibles dépend de la version de Microsoft Office Web Components installée sur l’ordinateur local.

Voici à quoi ressemble la sortie :



Comme vous l’avez déjà vu, l’outil Log Parser peut s’avérer très utile de plusieurs façons pour analyser les données de différents journaux. Seule la créativité est la limite ici! Il existe des moyens presque illimités pour que les données reflètent une bien meilleure image pour vous, et il peut s’agir de quelque chose sur lequel vous pouvez agir. Ce que nous avons touché n’est que la pointe de l’iceberg! Vous pouvez également utiliser des langages de haut niveau tels que Microsoft Visual C#, Microsoft Visual Basic .NET, etc. pour créer des programmes utiles à l’aide de la puissance de l’outil Log Parser. Consultez la section « Ressources » ci-dessous.