Les logs HTTP bruts

De nombreuses pages comportent des compteurs. L'internaute stupéfait est ainsi informé qu'il est le 18e depuis le 7 mars 1996, ou le 348 798 depuis ce matin. Soit. Quel intérêt pour l'internaute ? Aucun. Strictement aucun. L'auteur du site, en revanche y voit le même intérêt que les bistrots qui s'empressent de vous placer près de la fenêtre pour attirer les autres clients. Il est évident qu'une salle vide incite peu le consommateur à entrer. De la même façon, un site très fréquenté et un logiciel téléchargé des milliers de fois ne peuvent être que bons. Plus importante est la statistique, meilleur est le produit. Ben voyons. Ce type de statistique, facilement modifiable par le propriétaire du site, possède la même fiabilité que la publication par Apple du nombre d'appareils Apple vendus. Et exactement le même intérêt pour le visiteur.

Ces compteurs fonctionnent à partir d'un petit programme qui est exécuté sur le serveur chaque fois que quelqu'un charge la page. Le programme peut être un CGI (en Perl, Python ou autre PHP, JavaScript, etc., ou en Pascal, Delphi).

Si le but est uniquement de connaître la fréquentation, il est possible de rendre le compteur invisible : le programme exécuté sur le serveur incrémente le nombre de visiteurs dans un fichier du serveur, mais ne présente pas la valeur du compteur au visiteur.

C'est la solution que j'étais prêt à utiliser. Sauf que ce type de mécanique se met en branle systématiquement, y compris, et malheureusement pour les pages sauvegardées en local. Chaque fois que vous appelez une page stockée sur votre PC et que le dialogue de connexion Windows s'ouvre, vous avez affaire à un script placé sur la page.

Comme je souhaitais être aussi transparent dans mon analyse que possible, cette solution fut rejetée. Mon souci est de fournir l'information avec le minimum de parasitage pour l'utilisateur. Si je publie, c'est pour être lu, pas pour donner l'impression de flicage aux lecteurs.

Il existe une autre solution pour analyser son audience : les logs bruts du serveur. Tous les serveurs industriels (et à fortiori sans doute les serveurs persos) peuvent créer des journaux documentant les appels effectués. Ces logs se trouvent en fait sur tous les types de serveurs. Je me souviens d'avoir crapahuté jadis dans les logs d'Oracle, ou ceux de PerfMon sur Windows NT.

Le contenu et le format des logs varient naturellement avec le type de serveur et peuvent aussi éventuellement être désarmés ou paramétrés par l'administrateur du serveur. Trop de logs dégrade la performance du serveur, pas assez rend la détection d'anomalies difficile, voire impossible.

Il se trouve qu'en ce qui concerne les logs de serveurs HTTP, il existe une norme, qui est celle d'Apache, légèrement modifiée par IIS (Internet Information Server de Microsoft). Nous présenterons le détail du log ci-dessous, mais il contient à l'évidence des informations :

• de date et d'heure ;
• sur le serveur (son adresse) ;
• sur la requête (adresse du visiteur, type de requête, durée, page demandée).

De nombreux logiciels proposent des outils d'analyse des logs. Certains en domaine public, en source, d'autres commerciaux. Tout le spectre allant du gratuit au très cher. Et les plus chers vous expliquent naturellement pourquoi ces outils réaliseront des miracles pour analyser et régler votre site.

C'est pourquoi des personnes plus honnêtes ont écrit plusieurs articles critiquant plus ou moins vivement l'utilité des logs en tant qu'outils d'analyse de fréquentation.

Parmi les critiques, citons :

• tout d'abord, l'utilisation par le Web de caches de pages à de multiples niveaux :
• au niveau du réseau :

Les logs me semblent permettre plusieurs types d'analyses :

• les indications de « tendance » :

  • le niveau global est une première information : 100 par semaine ou 1000 par jour permettent d'évaluer l'efficacité du site,
  • même si les caches masquent une partie du trafic réel, les variations restent significatives. Une baisse sur plusieurs mois révèle une désaffection qu'il convient sans doute de corriger ;

• les statistiques par page :

  • elles peuvent indiquer un problème de navigation : une page que vous souhaitez voir utiliser (un bon de commande, par exemple) n'est pas assez visitée. Les statistiques fourniront une indication du problème, mais pas la solution : faut-il changer la page de place, ou améliorer l'attrait du chemin qui y conduit. Un peu comme un supermarché : faut-il mettre le lait à l'entrée ou obliger le chaland à parcourir le magasin en espérant qu'il achètera autre chose ;

• le cheminement dans les pages :

  • certains articles indiquent que 35 % des internautes ne dépassent pas le second clic. Il semble donc fondamental que la première page l'intéresse. Le log peut fournir ici une information précieuse,
  • le nombre de pages, le temps passé, le nombre d'octets téléchargés sont d'autres mesures de même nature. Un peu comme le remplissage moyen du caddy dans un supermarché,
  • il est même possible d'analyser des « profils types » : ceux qui se précipitent sur les téléchargements, ceux qui regardent les blagues, etc.

Notez que les caches peuvent ici aussi fausser l'information. Si le visiteur clique sur « Back », le log ne le verra pas. Le suivi rigoureux du cheminement dans le site n'est donc pas possible avec le log seul. Et certaines analyses peuvent être poussées au niveau du mouvement de la souris ; mais pas avec les logs, dont ce n'est pas du tout la vocation. Seules la Redoute ou la Fnac peuvent être intéressées par ce type d'analyse. Et lorsque les enjeux sont de cette taille, je pense qu'il est plus efficace d'entasser une vingtaine d'utilisateurs dans une pièce avec des glaces sans tain et une solide équipe de psys derrière guettant leur moindre froncement de sourcils. Technique marketing grand public de base…

Pour mon premier site sur Free, j'utilisais les statistiques fournies par Free :

• par page, le nombre de visiteurs, le volume ;
• des informations sur le type de navigateur, le type d'OS.

La principale critique de leurs statistiques concerne le nombre de visiteurs et le volume: je n'ai aucune idée de ce qui est mesuré :

• comment est mesuré le nombre de visiteurs :

  • les programmes d'analyse de logs utilisent en général une règle heuristique pour définir un visiteur. Comme les fournisseurs d'accès recyclent les URL, le compte du nombre d'URL différentes ne sert à rien: il minore le nombre réel de visiteurs. La contiguïté des URL est aussi illusoire lorsque le volume augmente, car plusieurs visiteurs font des appels entrelacés. Et la même URL peut alors provenir d'une autre personne. Des règles du style « un visiteur reste connecté 5 minutes en moyenne, donc la même URL au bout de 5 minutes correspond à un autre visiteur ». 5 minutes ? 2 peut-être ? Et pourquoi pas 30 secondes ? En fait le fournisseur souhaite le succès de votre site. Tout chiffre allant dans ce sens ne peut faire que plaisir au client. Il doit donc être examiné avec suspicion,
  • mi-octobre, j'avais demandé le référencement de mon site par Alta Vista, Google, etc. Quatre à six semaines, sans garantie. Et brusquement le 3 décembre j'ai eu 80 visiteurs en un jour. À l'évidence l'un de ceux-là était passé par là. Rien dans les statistiques Free ne me signale qu'il s'agit de référenceurs ou d'outils d'analyse automatique et non pas de visiteurs normaux ;

• le plus grave, et qui fut réellement un des éléments qui m'incita à quitter Free fut l'impossibilité de réconcilier « le jour », « les derniers 7 jours » et « le mois » :

  • comme j'avais commencé le site le 10 octobre, « le mois » ne pouvait être que le total de toutes les visites. Que nenni : 12 visiteurs le mercredi, fournissant un total de 0 pour les sept derniers jours. J'imagine qu'ils font une moyenne glissante, Pour glisser, elle glisse, mais comment, ou sur quoi glisse-t-elle : mystère,
  • si certaines pages n'étaient pas visitées dans la journée ou la semaine, la ligne disparaît complètement. Il s'agirait donc d'une espèce de loupe sur les derniers jours, sans cumul de tout ce qui s'est réellement passé. Ce qui oblige donc pour récupérer les cumuls réels à télécharger les stats quotidiennes tous les jours et réaliser ses moyennes soi-même. Naturellement il faut alors se connecter tous les jours, retrouver le mot de passe, attendre la réponse, retaper le mot de passe erroné, etc. Bref, une mécanique Minitel Rose des plus classiques.

Quant aux statistiques sur la résolution d'écran, le type de navigateur ou d'OS, je n'y attache pas grande importance :

• mes pages sont construites sans grand effort graphique actuellement. Le réglage au pixel près n'est donc pas utile. De plus je ne contrôle pas ce que le visiteur souhaite utiliser comme navigateur ou sa résolution ;
• le type d'OS me laisse froid : je travaille avec Linux, mais je navigue sous Windows 95. Pour des raisons historiques. D'autres doivent faire de même. La statistique du navigateur ne me fournit pas le type d'OS utilisé pour programmer. Peu d'espoir donc de savoir à partir de ces statistiques s'il vaut mieux écrire des articles pour Windows ou pour Linux. Et de toutes les façons les statistiques sont relativement stables : 98 % de Windows, 2 % de Linux ou autre, et pratiquement jamais de Mac. Et en gros 50 % d'Internet Explorer et 50 % de NetScape. Voilà, tout est dit. Les histogrammes sophistiqués et les camemberts coloriés n'y changeront rien. Et ceci pour les trois ans à venir.

Mentionnons que ce type d'information (résolution, navigateur, OS) n'est PAS dans les logs : il est obtenu par des scripts qui interrogent le visiteur lorsqu'il appelle une page. Une raison de plus, à mes yeux, pour ne pas récupérer ces informations.

Les logs existent sous deux formats principaux :

1. IIS ;
2. Common Log Format (Unix / Apache).

Je ne présenterai que le format IIS, mon fournisseur étant sous NT. Ce format ne diffère du format Unix que par la présence du code d'erreur NT et l'ordre des paramètres.

Voici un exemple d'une ligne du log :*

153.109.21.100, -, 09/05/2001, 17:40:33, W3SVC4, S3, 192.168.1.246, 0, 487, 3387, 404, 3, GET, /pfstats/stats.dll/add, idbase=talkMe&idSrv=12&id=125&IDelai=1&rs=1024x768&sc=16&pg=http%3A//www.talkme.net/&ref=,?

La syntaxe est une suite de paramètres séparés par des virgules. Cette ligne comporte actuellement 15 paramètres :

• l'adresse IP de celui qui a effectué la requête ;
• le nom de l'utilisateur. Ce champ n'est documenté que pour les sites exigeant que l'utilisateur s'identifie, ce qui n'est pas le cas de son site ;
• la date ;
• l'heure ;
• le service ;
• le nom du serveur (la machine de mon hébergeur) ;
• l'URL du serveur ;
• le temps écoulé ;
• les octets reçus ;
• les octets envoyés ;
• le code de statut HTTP de la requête (200= OK, pas de problème) ;
• le code de statut NT ;
• la méthode (GET par exemple) ;
• la page visée ;
• les paramètres.

Auraient pu être ajoutés :

• User Agent : permet de détecter si un Spider (programme de visite automatique) a été utilisé ;
• Cookie ;
• Referer : par quel biais la page a été atteinte (via une page « les liens de Dugenou » par exemple).

Pour avoir une idée de la différence entre les logs bruts et les logs filtrés. Voici, à titre d'exemple, quelques lignes extraites du 6 décembre 2001 (le second jour où le site était ouvert). Cette liste est sans intérêt par elle-même, mais pour évaluer ce que les logs peuvent offrir, il faut en avoir vu sur un exemple non trivial (autre qu'une seule ligne type). Voici donc le log brut :

209.73.162.171, -, 06/12/2001, 04:49:12, W3SVC37, S3, 192.168.1.230, 481, 129, 3351, 200, 0, GET, /index.html, -,
209.73.162.171, -, 06/12/2001, 04:49:13, W3SVC37, S3, 192.168.1.230, 481, 151, 4121, 200, 0, GET, /articles/articles.html, -,
209.73.162.171, -, 06/12/2001, 05:08:37, W3SVC37, S3, 192.168.1.230, 260, 138, 2796, 200, 0, GET, /menu.html, -,
213.228.29.10, -, 06/12/2001, 06:08:42, W3SVC37, S3, 192.168.1.230, 961, 288, 3355, 200, 0, GET, /index.html, -,
213.228.29.10, -, 06/12/2001, 06:08:42, W3SVC37, S3, 192.168.1.230, 0, 336, 141, 304, 0, GET, /menu.html, -,
213.228.29.10, -, 06/12/2001, 06:08:42, W3SVC37, S3, 192.168.1.230, 10, 349, 141, 304, 0, GET, /edito/edito_frame.html, -,
213.228.29.10, -, 06/12/2001, 06:08:42, W3SVC37, S3, 192.168.1.230, 0, 339, 140, 304, 0, GET, /ip4.jpeg, -,
213.228.29.10, -, 06/12/2001, 06:08:42, W3SVC37, S3, 192.168.1.230, 0, 365, 141, 304, 0, GET, /edito/edito_top.html, -,
213.228.29.10, -, 06/12/2001, 06:08:43, W3SVC37, S3, 192.168.1.230, 11, 361, 141, 304, 0, GET, /edito/edito.html, -,
66.130.158.58, -, 06/12/2001, 08:12:04, W3SVC37, S3, 192.168.1.230, 361, 370, 3351, 200, 0, GET, /index.html, -,
66.130.158.58, -, 06/12/2001, 08:12:04, W3SVC37, S3, 192.168.1.230, 160, 369, 2796, 200, 0, GET, /menu.html, -,
66.130.158.58, -, 06/12/2001, 08:12:04, W3SVC37, S3, 192.168.1.230, 160, 382, 1982, 200, 0, GET, /edito/edito_frame.html, -,
66.130.158.58, -, 06/12/2001, 08:12:04, W3SVC37, S3, 192.168.1.230, 160, 247, 3414, 200, 0, GET, /ip4.jpeg, -,
66.130.158.58, -, 06/12/2001, 08:12:04, W3SVC37, S3, 192.168.1.230, 180, 402, 1812, 200, 0, GET, /edito/edito_top.html, -,
66.130.158.58, -, 06/12/2001, 08:12:04, W3SVC37, S3, 192.168.1.230, 190, 398, 8459, 200, 0, GET, /edito/edito.html, -,
66.130.158.58, -, 06/12/2001, 08:12:21, W3SVC37, S3, 192.168.1.230, 10, 182, 0, 200, 0, GET, /404.asp, 404;http://www.jcolibri.com/favicon.ico,
66.130.158.58, -, 06/12/2001, 08:13:29, W3SVC37, S3, 192.168.1.230, 180, 456, 2022, 200, 0, GET, /entre_nous/entre_nous_frame.html, -,
66.130.158.58, -, 06/12/2001, 08:13:29, W3SVC37, S3, 192.168.1.230, 170, 477, 1832, 200, 0, GET, /entre_nous/entre_nous_top.html, -,
66.130.158.58, -, 06/12/2001, 08:13:29, W3SVC37, S3, 192.168.1.230, 451, 473, 3358, 200, 0, GET, /entre_nous/entre_nous.html, -,
66.130.158.58, -, 06/12/2001, 08:13:37, W3SVC37, S3, 192.168.1.230, 170, 452, 2006, 200, 0, GET, /articles/articles_frame.html, -,
66.130.158.58, -, 06/12/2001, 08:13:37, W3SVC37, S3, 192.168.1.230, 160, 469, 1824, 200, 0, GET, /articles/articles_top.html, -,
66.130.158.58, -, 06/12/2001, 08:13:37, W3SVC37, S3, 192.168.1.230, 360, 465, 4121, 200, 0, GET, /articles/articles.html, -,
66.130.158.58, -, 06/12/2001, 08:14:17, W3SVC37, S3, 192.168.1.230, 181, 486, 2081, 200, 0, GET, /articles/pascal_to_html/pascal_to_html_frame.html, -,
66.130.158.58, -, 06/12/2001, 08:14:17, W3SVC37, S3, 192.168.1.230, 160, 511, 1953, 200, 0, GET, /articles/pascal_to_html/pascal_to_html_top.html, -,
66.130.158.58, -, 06/12/2001, 08:14:17, W3SVC37, S3, 192.168.1.230, 360, 507, 14557, 200, 0, GET, /articles/pascal_to_html/pascal_to_html.html, -,
66.130.158.58, -, 06/12/2001, 08:15:37, W3SVC37, S3, 192.168.1.230, 170, 488, 2089, 200, 0, GET, /articles/colibri_helpers/colibri_helpers_frame.html, -,
66.130.158.58, -, 06/12/2001, 08:15:37, W3SVC37, S3, 192.168.1.230, 170, 515, 1957, 200, 0, GET, /articles/colibri_helpers/colibri_helpers_top.html, -,
66.130.158.58, -, 06/12/2001, 08:15:37, W3SVC37, S3, 192.168.1.230, 521, 511, 7282, 200, 0, GET, /articles/colibri_helpers/colibri_helpers.html, -,
66.130.158.58, -, 06/12/2001, 08:16:40, W3SVC37, S3, 192.168.1.230, 181, 462, 2046, 200, 0, GET, /presentations/presentations_frame.html, -,
66.130.158.58, -, 06/12/2001, 08:16:40, W3SVC37, S3, 192.168.1.230, 160, 489, 1843, 200, 0, GET, /presentations/presentations_top.html, -,
66.130.158.58, -, 06/12/2001, 08:16:40, W3SVC37, S3, 192.168.1.230, 511, 485, 3096, 200, 0, GET, /presentations/presentations.html, -,
66.130.158.58, -, 06/12/2001, 08:16:52, W3SVC37, S3, 192.168.1.230, 180, 515, 2151, 200, 0, GET, /presentations/soap_et_midas_colibri/soap_et_midas_colibri_frame.html, -,
66.130.158.58, -, 06/12/2001, 08:16:52, W3SVC37, S3, 192.168.1.230, 170, 549, 2001, 200, 0, GET, /presentations/soap_et_midas_colibri/soap_et_midas_colibri_top.html, -,
66.130.158.58, -, 06/12/2001, 08:16:52, W3SVC37, S3, 192.168.1.230, 190, 545, 5711, 200, 0, GET, /presentations/soap_et_midas_colibri/soap_et_midas_colibri.html, -,
66.130.158.58, -, 06/12/2001, 08:17:32, W3SVC37, S3, 192.168.1.230, 180, 460, 2038, 200, 0, GET, /pascalissime/pascalissime_frame.html, -,
66.130.158.58, -, 06/12/2001, 08:17:32, W3SVC37, S3, 192.168.1.230, 160, 485, 1840, 200, 0, GET, /pascalissime/pascalissime_top.html, -,
66.130.158.58, -, 06/12/2001, 08:17:32, W3SVC37, S3, 192.168.1.230, 180, 481, 5286, 200, 0, GET, /pascalissime/pascalissime.html, -,
66.130.158.58, -, 06/12/2001, 08:18:00, W3SVC37, S3, 192.168.1.230, 171, 448, 1990, 200, 0, GET, /livres/livres_frame.html, -,
66.130.158.58, -, 06/12/2001, 08:18:00, W3SVC37, S3, 192.168.1.230, 160, 461, 1816, 200, 0, GET, /livres/livres_top.html, -,
66.130.158.58, -, 06/12/2001, 08:18:00, W3SVC37, S3, 192.168.1.230, 500, 457, 9738, 200, 0, GET, /livres/livres.html, -,
66.130.158.58, -, 06/12/2001, 08:18:07, W3SVC37, S3, 192.168.1.230, 170, 458, 2029, 200, 0, GET, /telecharger/telecharger_frame.html, -,
66.130.158.58, -, 06/12/2001, 08:18:07, W3SVC37, S3, 192.168.1.230, 170, 481, 1835, 200, 0, GET, /telecharger/telecharger_top.html, -,
66.130.158.58, -, 06/12/2001, 08:18:07, W3SVC37, S3, 192.168.1.230, 201, 477, 8620, 200, 0, GET, /telecharger/telecharger.html, -,
66.130.158.58, -, 06/12/2001, 08:18:35, W3SVC37, S3, 192.168.1.230, 190, 486, 2059, 200, 0, GET, /stages/transparents/transparents_frame.html, -,
66.130.158.58, -, 06/12/2001, 08:18:35, W3SVC37, S3, 192.168.1.230, 170, 499, 1936, 200, 0, GET, /stages/transparents/transparents_top.html, -,
66.130.158.58, -, 06/12/2001, 08:18:35, W3SVC37, S3, 192.168.1.230, 371, 495, 5855, 200, 0, GET, /stages/transparents/transparents.html, -,

Vous constaterez que :

• certaines zones sont sans aucun intérêt :

  • le nom utilisateur est toujours « - »,
  • le service NT est W3SVC37 et ne change jamais (dans mon cas),
  • idem pour la machine qui est S3. Soit,
  • idem pour l'URL du serveur 192.168.1.230 ;
• les pages visitées, quasiment la partie la plus utile, comportent tout le chemin de la page demandée.

En débarrassant ce log d'information sans intérêt pour nous, nous obtenons :

En examinant ces lignes, vous imaginez sans aucune peine ce que nous pouvons ou non en tirer. Juste quelques commentaires :

• les nouveaux arrivants démarrent en « index.html ». Cela ne sera pas toujours le cas si les utilisateurs conservent des liens vers d'autres pages ;
• une erreur 404 est survenue. Il traîne donc encore des liens erronés. À examiner lorsque l'article sera terminé ;
• certaines pages sont sans intérêt (le jpeg du logo, les frames xxx_frame.html et xxx_top.html).

À titre d'exemple, voici un exemple simple d'analyse de pages effectué sur le même échantillon :

• il y a eu trois utilisateurs ayant passé environ trois secondes et cherché quinze pages :

• ces valeurs globales peuvent se répartir entre pages normales, frames et erreurs :

• en ce qui concerne les pages normales (ni frame, ni erreurs), voici le hit parade :

• et pour les erreurs :

Ces statistiques nous permettent de détecter plusieurs informations :

• notre site comporte des erreurs. Favicon (icône lorsque l'on clique favoris) est d'origine encore inconnue pour moi à ce jour, mais sans grande importance actuellement. On m'a dit depuis qu'ils en avaient tout plein dans la région de Toulouse, mais pas exactement du même type ;
• « 35 % des utilisateurs » à moi ne sont pas partis, eux, au bout d'un clic. Manquerait plus que cela !
• « transparents » a été cliqué sans passer par « stages ». L'examen du log séquentiel montre le saut de « télécharger » à « télécharger les transparents des stages ». Ce que nous avions prévu, et même mis en place. Mais qui est confirmé au bout de deux jours…

Etc., etc., etc. La « logologie » s'acquiert avec le temps, et n'est qu'une question de vieilles casseroles et de bonnes soupes. Allez, encore un exemple :

• j'ai été surpris du nombre de visiteurs consultant mon CV. Celui-ci avait été rédigé, car Becker Avionics (le Dassault allemand) envisageait d'utiliser nos services en programmation Delphi. À tout hasard j'ai donc inclus le CV au site, au cas où les Suédois, les Italiens…
• neuf personnes ont consulté mon CV en trois jours. À n'en pas douter, plusieurs chasseurs de têtes sortant tout droit du bureau de Lagardère ou Arnault allaient me téléphoner dans l'heure ;
• en attendant, j'ai continué à écrire le présent article. J'ai ajouté le cumul de millisecondes par page. Cette valeur devenant trop importante, je l'ai converti en secondes, et divisé par le nombre d'accès. Pour le CV, le résultat fut de 0.7 seconde. Essayez de lire un CV en 0.7 seconde. Chez Compétences, j'ai appris à évaluer professionnellement les gens rapidement. Mais en 0.7 seconde non. Adieu veau, vache, cochon, couvée…
• quoique. Quoique ! 0.7 ne veut rien dire du tout : peut-être 8 zigs sont entrés et sortis sur le champ, et UNE personne, la bonne, a lu, ou récupéré le CV sur son PC pour le lire à tête reposée. Rien n'est donc perdu : ce site s'autodétruira lorsque le téléphone sonnera. D'ici là, et en attendant, la moralité est que les statistiques sont fort utiles, mais leur interprétation exige un peu de bon sens, et encore plus, sans doute, quelques grains d'humour.

Une fois que vous avez vu les logs réels et le type de simplification puis d'analyse, il est enfantin de créer un projet Delphi qui triturera ces logs ad nauseam.

Nous allons simplement présenter ici notre mécanique, fort conscient qu'elle peut être enjolivée sans grande difficulté.

p_http_raw_logs a pour but de permettre :

• la création d'un fichier binaire de stockage de fichiers de log au format IIS ;
• l'ajout de fichiers ASCII contenant des logs IIS (ceux de décembre, de janvier, etc.) ;
• la création de statistiques telles que celles présentées ci-dessus.

Le projet fourni est compilable et fonctionne dans n'importe quel répertoire avec le jeu d'essai fourni. Compilez, exécutez et quittez.

Pour utiliser ce programme avec vos propres logs :

• placez votre fichier de log IIS dans le répertoire exe\data\ ;
• modifiez le nom du fichier dans u_http_raw_logs: k_log_file= 'mes_logs_iis.txt' ;
• compilez ;
• si le fichier binaire n'existe pas encore, cliquez « create_log_ » ;
• ajoutez votre fichier de log en cliquant « append_log_ » ;
• listez le log épuré en cliquant « list_log_ » ;
• présentez quelques statistiques en cliquant « global_stats ».

L'unité est prévue pour être placée dans :

C:
  programs
    colibri_utilities
      web
       http_raw_logs

Vous pouvez naturellement changer cette organisation par Projet | Options | Directories
Les directives de compilation sont :

• R+ (vérification des intervalles) ;
• S+ (vérification de la pile) ;
• pas d'optimisation.

Fondamentalement le programme ne fait qu'analyser un fichier ASCII dont les champs sont délimités par des virgules. Ce format a été adopté par Microsoft pour faciliter l'importation de ces logs par de nombreux outils. J'imagine que Word ou Excel savent faire cela très bien.

Personnellement Word me donne des boutons et je n'ai jamais touché à Excel. De plus Delphi fait cela encore mieux.

Notre programme analyse donc chaque ligne du log et place les informations dans des fichiers disques.

Pour les fichiers, plusieurs options s'ouvraient :

• soit des calculs statistiques directement sur les fichiers ASCII ;

• soit un stockage des données dans des fichiers binaires, avec calcul de statistiques à partir des fichiers binaires. Et pour le format binaire :

  • soit des fichiers FILE ayant le format approprié,
  • soit mécanique de base de données telle qu'Interbase.

Pour le moment et pour faciliter la mise au point, j'ai opté pour les FILE. L'organisation est la suivante :

• la classe c_string_file gère les parties variables de chaque ligne (les URL, les noms des pages…) ;
• la classe c_http_raw_logs gère les lignes du log ;
• la classe c_web_page_list calcule les statistiques ;
• le projet p_http_raw_logs est un exemple d'utilisation ;
• l'unité u_strings_html_ analyse les noms des pages et u_display affiche des chaînes dans un tMemo. Ces deux unités classiques ne seront pas détaillées ici (voyez mon site au besoin).

Cette classe place dans un fichier FILE les chaînes de notre log. La structure du fichier est la suivante :

• pour chaque chaîne :

  • un identificateur Integer permettant de retrouver au besoin le RECORD du fichier binaire de log,
  • la taille de la chaîne, sous forme d'Integer,
  • les caractères de la chaîne ;
• le début du fichier contient 4 octets permettant de gérer une FreeList. Cette partie n'est pas utilisée ici.

L'interface de cette classe est la suivante :

type c_string_file= class
                          public
                            m_file: File;
                            m_file_name: String;
                            m_first_free_position: Integer;
                            m_id: Integer;

                            Constructor create_string_file(p_name, p_file_name: String); Virtual;


                            function f_force_create: Boolean; Virtual;
                            function f_open: Boolean; Virtual;
                            function f_append_string(p_id: Integer; p_string: String): Integer;
                            function f_read_string(p_string_position: Integer): String;
                            procedure close_file;


                            Destructor Destroy; Override;
                        end;

La plupart des méthodes ont un but évident. Notons que :

• f_append_string : reçoit un identificateur (le numéro de la ligne de log dans notre cas) et la chaîne, et retourne la position du PREMIER octet où est stocké le RECORD ;
• f_read_string : reçoit la position du premier octet, et retourne la chaîne.

Cette classe gère le fichier des logs. Elle contient un enregistrement pour chaque ligne de log.

Nous avons à traiter deux types de champs :

• des champs de taille variable : les noms de serveur, les pages demandées ;
• des champs de taille fixe : les durées, les octets envoyés et reçus.

Les champs variables sont placés dans le fichier géré par c_string_file et le fichier du log contient la position de chacun de ces champs dans chacune de ses fiches. Les champs de taille fixe font directement partie du RECORD.

Certains champs pourraient être stockés soit en format variable, soit en format fixe :

• les URL n'ont pas toujours la même taille, mais ne dépassent pas 15 caractères : 123.456.789.012 ;
• les dates et heures pourraient être converties en binaire et stockées en format fixe.

L'objectif de notre programme n'étant pas l'économie de place disque, ces derniers champs ont aussi été stockés au format variable.

Dans ces conditions, la définition du RECORD est la suivante :

type t_string_position= Integer;
         t_log_record= record
                         m_client_ip: t_string_position;
                         m_user_name: t_string_position;
                         m_date, m_time: t_string_position;
                         m_service, m_computer_name: t_string_position;
                         m_server_ip: t_string_position;
                         m_elapsed_time, m_bytes_received, m_bytes_sent,
                           m_status_code, m_windows_status_code: Integer;
                         m_GET_or_POST: t_string_position;
                         m_requested_page, m_parameters: t_string_position;
                       end;

Comme indiqué plus haut, ce RECORD contient deux types de champs :

• les champs tels que m_client_ip qui est la position dans le fichier de taille variable, de la chaine contenant l'URL client ;
• les champs tels que m_elapsed_time, qui contient la valeur numérique du temps de visite.

La classe c_http_raw_logs elle-même a alors la définition suivante :

type c_http_raw_logs= class
                            public
                              // -- the variable parts of the log
                              m_c_string_file: c_string_file;

                              m_log_file_name: String;
                              m_log_file: File of t_log_record;
                              m_log_record: t_log_record;



                              constructor create_http_raw_logs(p_name, p_file_name: String); Virtual;


                              function f_force_create: Boolean; Virtual;
                              function f_open: Boolean; Virtual;
                              procedure close_file; Virtual;


                              procedure append_log(p_ascii_file_name: String);


                              function f_client_ip: String;
                              function f_date: String;
                              function f_time: String;
                              function f_GET_or_POST: String;
                              function f_requested_page: String;
                              function f_parameters: String;


                              function f_requested_page_and_parameters: String;
                              function f_date_time: tDateTime;


                              procedure display_record;


                              destructor Destroy; Override;
                          end;

Les attributs sont les suivants :

• m_c_string_file: la classe c_string_file qui gérera les chaînes de taille variable ;
• log_file_name, m_log_file et m_log_record: les attributs permettant de gérer les RECORD de taille fixe.

Quelques précisions concernant les méthodes :

• append_log: se charge de l'ajout d'un nouveau fichier de logs. Cette procédure :

  • ouvre les deux fichiers (fixe et variable),
  • ouvre et charge le fichier ASCII dans un tampon mémoire,
  • analyse toutes les lignes pour les placer dans l'enregistrement binaire,
  • referme tous les fichiers ;
• les fonctions f_client_ip, f_date, etc. ont pour seul but d'encapsuler la lecture des champs de taille variable (le programme utilisateur n'a pas besoin de manipuler c_string_file) ;
• f_requested_page_and_parameters et f_date_time: deux fonctions retournant des valeurs qui nous intéressent pour nos états ;
• display_record: la méthode qui produit le log filtré présenté ci-dessus.

Cette unité gère les statistiques par page web. Pour chaque page, elle contient le nombre de visiteurs, le temps passé à scruter la page, etc.

Pour cumuler les informations, il suffit de balayer le fichier binaire c_http_raw_logs en appelant add_or_increment.

Techniquement la mécanique de statistique est organisée sous forme d'une tStringList encapsulée :

• c_web_page_list contient une tStringList avec le nom de la page ('initiation_delphi.html' par exemple) ;
• chaque Item de la tStringList contient un pointeur vers un objet de type c_web_page qui contient les informations qui nous intéressent pour chaque page: nombre de visites, etc.

La programmation de cette unité a donc démarré par le squelette,u_c_tstringlist qui a été adapté au traitement à l'analyse du log.

IV-D-1. c_web_page▲

c_web_page= // one "web_page"
                     Class
                       public
                         m_c_parent_web_page_list: c_web_page_list;
                         m_web_page_name: String;
                         m_web_page_count: Integer;
                         m_elapsed_time: Integer;
                         m_used: Boolean;
                         m_last_date: tDateTime;

                         Constructor create_web_page(p_name, p_web_page_name: tring;
                             p_c_web_pages: c_web_page_list; p_elapsed_time: Integer; p_last_date: tDateTime); Virtual;
                         function f_display_web_page: String;
                         Destructor Destroy; Override;
                     end;

IV-D-2. c_web_page_list▲

c_web_page_list= // "web_page" list
                          Class
                            public
                              m_c_web_page_list: tStringList;
                              m_max_web_page_length: Integer;

                              Constructor create_web_page_list(p_name: String); Virtual;


                              function f_web_page_count: Integer;
                              function f_c_web_page(p_web_page: Integer): c_web_page;
                              procedure add_web_page(p_c_web_page: c_web_page);
                              procedure add_or_increment(p_web_page_name: String; p_elapsed_time: Integer;
                                p_last_date: tDateTime);


                              procedure display_web_page_list;


                              procedure display_indented_html(p_site_map_name: String);
                              procedure display_unused;


                              Destructor Destroy; Override;
                          end;

Citons en vrac :

• incorporer les informations « User-Agent » : qui permettrait de détecter les moteurs automatiques de visite de pages ;
• effectuer le même type d'analyse pour les logs FTP : pour le moment mon hébergeur ne me les fournit pas, car ils sont sur une machine séparée et qui regroupe le FTP de tous les sites. Je finirai peut-être par les obtenir un jour ;
• l'utilisation d'Interbase (ou toute autre base de données) au lieu des fichiers binaires utilisés ici.

Lorsque je me suis finalement décidé à monter un site, la première difficulté a été le choix de l'hébergeur.

• Plusieurs personnes m'avaient déjà proposé d'héberger Pascalissime, mais je ne suis pas arrivé à me décider.
• En espérant trouver une aide « personnalisée », je me suis tourné vers Lolo qui fréquentait les « Mercredis de l'Institut Pascal ». Ancien programmeur émérite, administrateur en tant qu'étudiant du site de Jussieu, il travaille actuellement chez un hébergeur professionnel. Il m'a fait comprendre qu'ils ne pouvaient pas laisser leur client gambader en CGI dans leurs systèmes, à moins d'allouer une machine dédiée à ce client chez eux. Et les machines sont des systèmes spécialisés en racks : rien à voir avec un PC de chez Carrefour ou Conforama. Je n'ai même pas demandé le prix qui n'a certainement non plus rien à voir. Alors, dégoûté, je suis retourné hiberner deux ans de plus.
• Alain Guérin m'avait présenté Free. Enfin un truc gratis à ma portée. J'ai été très satisfait de leur prestation. Le mail a fort bien marché, et fonctionne encore à ce jour. Alain avait par la suite insisté qu'il était possible, ainsi que chez d'autres hébergeurs style Club Internet, d'avoir des pages web « perso ». J'ai commencé à regarder, et suis tombé sur des tutoriels PHP. Allons donc, encore un langage de plus à la syntaxe approximative et fluctuante. J'ai plus que donné à ce niveau, et je me suis arrêté là.

• Lorsque je me suis réellement décidé à enfin faire quelque chose, j'ai commencé par analyser les pages des autres programmeurs. Pas beaucoup de PHP, JavaScript ou autre Python me semblait-il. C'est là que j'ai basculé. Le site fut monté en un mois en écrivant le texte HTML avec Notepad. Pas réellement, mais enfin, presque. À ce jour (18 décembre 2001), près de 4 Megs de pages HTML et de .ZIP téléchargeables. Et au bout de 15 jours, les limitations de Free apparurent :

  • des statistiques difficilement exploitables,
  • pas de CGI. Du Perl ou PHP si j'ai bien compris, mais cela n'est pas de mon goût,
  • un statut juridique peu clair: peut-on mentionner des prix, des bons de commande ? Sans doute compte tenu de leur volume ils ne vérifient pas tout, et peut-être même ferment-ils les yeux. Mais cette ambiguïté aurait été, pour le moins, inconfortable,

  • un service, malgré tout minimal. Gratuit certes, mais minimal :

    • pour les réponses au téléphone, 7 jours sur 7 et 24 heures sur 24, une mécanique du style « pour avoir les tarifs, tapez sur 1 », etc. Et après avoir tapé comme un malade au point d'en attraper un furoncle au doigt (j'imagine qu'ils touchent des sous des PTT comme le Minitel Rose), le message classique « tous nos techniciens sont occupés, veuillez appeler ultérieurement »,
    • patience et ténacité font plus que force et rage : au bout de plusieurs appels je tombe enfin sur quelqu'un. Très aimable et courtois, je dois dire. Mais plutôt commercial ou « grand public ». Trouver le fichier correspondant à un compteur invisible que j'avais placé sur une de mes pages n'était pas dans son domaine de compétence. Il est évident que ce n'est pas le genre de question posée par « la ménagère de plus de 50 ans ». Il m'aiguille vers un mail technique,
    • mail fut envoyé. Réponse fut obtenue : 9 jours plus tard, et « veuillez nous dire sur quelle page est le compteur ». La réponse n'est pas idiote : il allait vérifier mon bout de script, et regarder s'il trouvait le fichier .DAT quelque part, j'imagine.

    
    À ce moment j'avais tout de même un peu perdu patience, et commencé à regarder ailleurs ;

• c'est là que je suis tombé sur www.plusfacile.com. Plusieurs anciens lecteurs rencontrés lors de la conférence Borland 2000 m'avaient chaudement recommandé VienneInfo, Développez, Delphinautes, etc. Et sur ce site j'ai trouvé les coordonnées de PlusFacile. La proposition semblait alléchante: avec des CGI. Et Interbase. Et en Delphi. Oui monsieur. Quelques coups de fil. Comme je bataillais avec les stats Free, j'ai posé la question des logs bruts. Un peu d'étonnement. Apparemment j'étais le premier à avoir ce type de besoin saugrenu. Mais c'était possible: les logs étaient générés par IIS pour gérer le site, et il suffisait de créer un alias pour me permettre de récupérer « mes » logs. J'ai craqué au bout de deux jours et envoyé la commande et le chèque. À titre d'information, je paie de l'ordre de 3000 francs par an pour deux sites avec réservation du nom de domaine. Moins que ma facture de téléphone. Mais voyez le détail de l'offre par vous-mêmes : il y a des offres « personnelles », « gold », etc. Depuis, j'ai appelé PlusFacile quatre ou cinq fois. J'ai toujours eu le patron au téléphone au bout de trois ou quatre sonneries, y compris le samedi matin ou dimanche après-midi. Les mails sont répondus dans la journée. Des exemples de programmation Web en source Delphi dans le quart d'heure suivant le coup de fil…

Le plus drôle est que si cet article est convaincant, PlusFacile sera inondé de demandes d'autres clients pour obtenir leurs logs bruts. PlusFacile et surtout les autres j'espère. Lesquels n'en auront pas toujours envie. En général pas envie du tout même. Parlez-leur alors de CGI. Et en Delphi. Si, si, parfaitement : de CGI en Delphi. Et écoutez la réponse. Ensuite, il vous suffira de cliquer sur.http://www.plusfacile.com.