C est dans ce cadre que s inscrit mon travail, qui consiste à : 1. restaurer, mettre à niveau, améliorer, maintenir et automatiser le fonctionnement

Transcription

1 Remerciements Un tout grand merci à Madame le Professeur Marianne Baudinet, responsable du service informatique de la Faculté des Sciences Appliquées de l Université Libre de Bruxelles (ULB), pour m avoir permis de réaliser ce Travail de Fin d Études, pour sa patience et ses précieux conseils. La confiance de Monsieur le Professeur R. Poncelet et de Monsieur le Professeur J. C. Maun, responsables des échanges européens, m a permis d effectuer une dernière année d études très enrichissante à l Ecole Centrale de Paris (ECP). C est à l ECP que j ai eu la chance de rencontrer Monsieur le Professeur P. Boutin, consultant en nouvelles technologies de l information chez Publicis Technology, qui fut à la fois un professeur et un chef de projet hors-pair, malgré un emploi du temps chargé. Grâce à son aide et à celle de Monsieur D. Znaty, directeur général de Publicis Technology, j ai pu effectuer dans cette société un stage intéressant qui fut l inspiration de ce travail. Merci à toute l équipe que j y ai rencontrée, pour son soutien moral, T. Paumier, G. Besse, C. Parisi, E. Briones, A. Sfeir et R. Gbaguidi, ainsi que F. Farid pour son aide technique exceptionnelle. Je remercie également les programmeurs avec qui j ai pu collaborer activement par l intermédiaire de l internet et dont les réalisations m ont souvent été indispensables pour mener à bien mon travail. Je tiens à exprimer ma gratitude envers les responsables de la société Sun Microsystems que j ai pu rencontrer et dont l ouverture fut incomparable. Enfin, je remercie encore Madame M. Baudinet, pour avoir été mon professeur et m avoir donné le goût de l informatique ainsi que des bases solides dans ce domaine [7].

2 Résumé Ce document présente le travail réalisé lors de mon stage chez Publicis Technology. Parmi d autres activités, cette société propose l hébergement de sites web. Elle offre également la mise en ligne sécurisée d informations statistiques relatives à l audience obtenue par ces sites. C est dans ce cadre que s inscrit mon travail, qui consiste à : 1. restaurer, mettre à niveau, améliorer, maintenir et automatiser le fonctionnement d un logiciel de génération de statistiques développé précédemment en interne, lorsqu aucune solution commerciale n était encore disponible. 2. étudier la possibilité d une mise en ligne dynamique d informations, et ce sur base du langage Java [1, 2, 3, 4, 5, 16, 17, 21].

3 Avant-lecture Conventions Dans ce document, différentes conventions de langage inhabituelles seront utilisées ; abus de langage risquant certaines ambiguïtés selon les contextes, définitions controversées ou galvaudées, commodités de langage,... Voici donc quelques expressions pouvant porter à confusion et dont il peut être utile de préciser le ou les sens futurs : mise en ligne : on dira qu une information est mise en ligne lorsqu elle est consultable à partir d un navigateur web connecté à l internet. mise en ligne statique : on parlera de mise en ligne statique d informations lorsque celles-ci sont renfermées par des pages HTML 1 existant avant la requête du navigateur. mise en ligne dynamique : au contraire, on parlera de mise en ligne dynamique d informations lorsques celles-ci (pages HTML ou même images GIF/JPEG) existent avant la requête d un navigateur au serveur web mais sont mises en forme par un programme après la requête. hits : nombre de requêtes au sens large reçues par un serveur web ; cela inclut les pages HTML, les fichiers images, les fichiers binaires, documents en ligne,... pages prélevées : nombre de requêtes à des pages HTML reçues par un serveur web ; cela exclut les images et autres fichiers binaires. incrémentale : lorsqu un même traitement est appliqué de façon répétée à une quantité d informations en évolution, une méthode dite incrémentale consistera à ne tenir compte à chaque traitement que de la partie ayant été modifiée ou ajoutée par rapport au traitement précédent. 1éventuellement générées automatiquement par un programme

4 iv serveur web : toute confusion doit être évitée entre un serveur physique proposant le service HTTP et le logiciel exécuté par ladite machine réalisant ce service ; la distinction doit donc se faire entre le matériel (hardware) et le logiciel (software). site web : un site web est un ensemble de pages HTML en ligne disposées selon une arborescence ; cette arborescence correspond à celle d un répertoire sur le disque physique du serveur web. On dira qu un serveur web héberge plusieurs sites lorsque le disque contient plusieurs arborescences mises en ligne, physiquement et logiquement indépendantes. cible : dans le cadre du logiciel pywrap décrit au chapitre 2, une cible est un mot-clé identifiant un site web dont il faut générer des informations statistiques. Anglicismes Différentes locutions étrangères seront utilisées dans ce document. Voici quelques indications minimales permettant de mieux les interpréter dans les contextes où elles apparaîtront. 100% pure Java : entièrement écrit en langage Java. access log : fichier dans lequel sont notées des informations concernant les requêtes HTTP traitées par un serveur web. agent log : fichier dans lequel sont notées des informations concernant les ordinateurs et navigateurs d où émanent les requêtes HTTP adressées à un serveur web. applet : application Java s exécutant usuellement au sein d un navigateur internet et respectant une API prédéfinie. Une applet, à moins d être signée, doit également obéir à des contraintes de sécurité imposées par le navigateur. batch : différée, une application batch, au contraire d une application temps réel, s exécutera sans contrainte précise de temps. bookmark : signet, adresse web préférentielle stockée par l utilisateur d un navigateur afin de pouvoir y accéder directement. browser : navigateur internet. byte code : code Java intermédiaire extrêment compact, compilé en vue d une interprétation ou d une post-compilation à la volée. combo box : élément d interface utilisateur permettant de sélectionner une valeur parmi un choix proposé.

5 v core : noyau, coeur, classes de base du langage Java. download : téléchargement, transfert du serveur vers le client. driver : pilote. ethernet : type de réseau informatique. firewall : pare-feu, système de sécurité filtrant les accès entre deux réseaux, principalement au niveau des services TCP/IP. garbage collector : ramasse-miettes, mécanisme de récupération automatique de la mémoire. hits : nombre de requêtes au sens large reçues par un serveur web. internet : réseau informatique mondial. intranet : réseau local exploitant les standards de l internet. extranet : extension de l intranet à l extérieur. javadoc : outil du JDK permettant de générer automatiquement de la documentation structurée à partir des commentaires inclus dans un code source Java. log : trace, d une transaction HTTP par exemple. middleware : application intermédiaire faisant le lien entre un client et un serveur, jouant le rôle de serveur vis-à-vis du client extrême et le rôle de client vis-à-vis du serveur extrême. network computing : modèle informatique prônant l utilisation de postes clients légers connectés à un réseau par l intermédiaire duquel ils tirent leur puissance d un serveur. Ce type de modèle, décrit plus avant dans [12], vise à faciliter l accès au réseau, la gestion centralisée et à diminuer les coûts du matériel et de l administration. package : paquetage, ensemble de classes Java. pipe : tuyau, mécanisme de communication Unix permettant de rediriger la sortie standard ou d erreur d un programme vers l entrée standard d un autre [10, 13]. query : requête. referer log : fichier dans lequel sont notées des informations concernant l endroit, généralement une page HTML pourvues de liens hypertextes, à partir de laquelle une requête a été formulée. servlet : application Java s exécutant sur le serveur et respectant une API prédéfinie. shell : langage d interprétation de commandes Unix. standalone : autonome. string : chaîne de caractères. web : toile, service HTTP du réseau internet.

6 vi Abréviations ADT Abstract Data Type ANSI American National Standards Institute API Application Programming Interface AWT Abstract Window Toolkit CGI Common Gateway Interface CLF Common Log Format CORBA Common Object Request Broker Architecture DBMS DataBase Management System DMZ DeMilitarized Zone DNS Domain Name Server ECP Ecole Centrale Paris FTP File Transfer Protocol GIF Graphics Interchange Format GNU GNU is Not Unix GUI Graphic User Interface HTML HyperText Markup Language HTTP HyperText Transfer Protocol IHM Interface Homme-Machine IP Internet Protocol JDBC Java DataBase Connectivity JDK Java Development Kit JFC Java Foundation Classes JIT Just In Time JVM Java Virtual Machine ODBC Open DataBase Connectivity PIC Position Independent Code RGB Red Green Blue RMI Remote Method Invocation SGBD Système de Gestion de Bases de Données SGBDR Système de Gestion de Bases de Données Relationnelles SMB Service Message Broking SQL Sructured Query Language SSI Server Side Include SSJ Server Side Java PC Personal Computer TCP Transfer Control Protocol TFE Travail de Fin d Études ULB Université Libre de Bruxelles URI Uniform Resource Identifier URL Uniform Resource Locator WORA Write Once Run Anywhere WWW World Wide Web

7 Contents 1 Introduction Sujet de ce travail Le réseau informatique de Publicis Technology Les serveurs de la DMZ Description du document Mise en ligne statique Introduction Les logs des serveurs web Le transfert des logs Le traitement des logs Constatations Utilisation de Java Le langage L API JDBC Les types de drivers L API servlets Support des servlets pour Apache Mise en ligne dynamique Objectif Conception Réalisation Conclusions Conclusions 61 A Technologies auxiliaires 66 A.1 AJPv A.2 Les expressions régulières A.3 Interpolation par courbes splines B Spécifications techniques du serveur de statistiques 76

8 CONTENTS viii B.1 Description matérielle B.2 Système d exploitation B.3 Paramètres réseaux B.4 Logiciels installés B.5 Partitionnement et arborescence C Scripts associés à pywrap 80 C.1 pywrap C.2 getlog.py C.3 pystats.py C.4 access.py C.5 accesshtml.py C.6 make tables.py C.7 pycreate C.8 pydelete C.9 pyreset C.10 logzip C.11 rotate C.12 ip2fqdn.pl C.13 Extrait de stats.conf D Servlets 127 D.1 Template D.2 Campagne.java D.3 Trends.java D.4 Spline3.java D.5 Toile.java D.6 Promotion.java D.7 Couleur.java D.8 Security.java D.9 MagicDate.java D.10 ModifierCampagne.java D.11 ModificationCampagne

9 List of Figures 1.1 Requête HTTP Topologie schématique Topologie détaillée Filtrage entre l internet et la DMZ Schéma de la DMZ Schéma d évolution de la DMZ Schéma de traitement de l information Serveur web hébergeant plusieurs sites Récupération des logs par le réseau Récupération de fichiers de logs compressés Ecran d accueil Evolution de l audience au fil des mois Evolution de l audience sur un mois donné Audience en fonction des tranches horaires Navigateurs utilisés Versions de navigateur utilisées Systèmes d exploitation utilisés Schéma d exécution d un programme Java Utilisation de JDBC Trou de sécurité potentiel dans un firewall Driver natif Modèle trois-tiers Utilisation de JDBC et de drivers de type Schéma de fonctionnement de l API servlet Aiguillage des requêtes Architecture basée sur JServ Graphique superposant les promotions et l audience Inversion d une opération Codage RGB d un pixel sur 32 bits Image 4x3 constituée à partir d un tableau de 12 entiers Evolution de l audience quotidienne d un site sur 5 mois... 55

10 LIST OF FIGURES x 4.6 Evolution de l audience quotidienne d un site sur 13 mois Evolution de l audience quotidienne détaillée sur 1 mois Valeurs hebdomadaires reliées par des segments de droite Interpolation des valeurs par des courbes Architectures parallèles en place Duplication du traitement des logs A.1 Interpolation de points par courbes splines C.1 Logs des serveurs Apache C.2 Logs des serveurs Netscape C.3 Schéma de manipulation

11 Often, great technologies are born into the world without one of three essential factors for success ; a committed champion, a willing marketplace, and a workable business model. Clearly, Java had its champions, believers like James Gosling, Arthur van Hoff, Bill Joy, Patrick Naughton, and the many who fell by the wayside during Java s long, twisting history. Tweaked, renamed, and repositioned, this time the idea has found a willing marketplace ; in time, a distributed object-oriented language like Java will probably establish itself as the foundation of the Net. But whether the standard will be Java depends on whether Sun finds a business model to keep it alive. David Bank

12 Chapter 1 Introduction 1.1 Sujet de ce travail La société Publicis Technology propose différents services informatiques ; celui auquel se rapporte ce travail est l hébergement de serveurs web et plus particulièrement la mesure de l audience obtenue par ceux-ci. Le World Wide Web est devenu l un des services les plus répandus de l internet : des ordinateurs connectés au réseau mondial proposent un certain nombre de pages d information, consultables par n importe quel client 1 web appelé navigateur ou browser. La plupart des sociétés ont emboîté le pas de cette technologie, proposant des pages consultables sur internet ; celles-ci sont devenues de plus en plus une vitrine à part entière, de la société d abord, puis de ses activités et de ses produits. Certaines compagnies parviennent même à tirer profit de la récente dynamique des pages web pour proposer un réel service en ligne : vente par correspondance, consultation de bases de données,... Le site web devient dès lors à la fois un produit et un outil de communication. L analyse d audience en communication constitue depuis toujours un créneau stratégique à forte valeur ajoutée, permettant de cibler le public et d adapter le message qu on veut lui faire passer. Pour un client hébergé, évaluer l audience de son site web l aide ainsi à orienter sa démarche marketing en adaptant le contenu ou 1 l accès à une page peut bien sûr être restreint selon la zone d accès ou par un système de mots de passe

13 1.2 Le réseau informatique de Publicis Technology 2 l ergonomie des pages. Cela permet également de justifier son investissement dans cet espace publicitaire encore méconnu ou mal appréhendé. Comme l illustre la figure 1.1, lorsqu un client se connecte à un serveur de pages web à l aide de son navigateur, celui-ci envoie à travers le réseau une requête selon un protocole standardisé appelé HTTP 2. Cette requête est traitée par le serveur, qui renvoie la page demandée ou un message d erreur si celle-ci n est pas accessible. Au même moment, le serveur garde une trace (log) de la requête et du statut du résultat envoyé au client. De plus, en même temps que l objet de la requête, un navigateur web envoie quelque information sur le poste client qui l exécute. Tout cela peut être noté par le serveur. DATE ET HEURE 1. consultation externe? Serveur web externe 2. REQUETE CLIENT WEB (BROWSER) 3. PAGE (HTML) SERVEUR WEB LOGS SYSTEME D EXPLOITATION RESEAU INTERNET Figure 1.1: Requête HTTP 1.2 Le réseau informatique de Publicis Technology Les ordinateurs de la société disposent d une connexion Ethernet 10 Mbits/s au réseau local, dont la topologie globale est schématisée par la figure 1.2 et détaillée par la figure 1.3. L adressage IP est réparti sur 4 classes de type C 3 et encapsule une zone d adressage intranet de adresses. Les développements se font usuellement sur des PC connectés dans la zone intranet, principalement pour éviter certaines contraintes extrêmement com- 2 Hyper Text Transfer Protocol 3 soit au total 1024 adresses

14 1.2 Le réseau informatique de Publicis Technology 3 Applications Comptables DMZ Internet Firewall Intranet Figure 1.2: Topologie schématique T2 Tuner PABX RTC ISDN RNIS LS Applications comptables IBM Real Audio INTERNET Horus Thot Ra Renprod Rendev... Ys Intranet Figure 1.3: Topologie détaillée

15 1.3 Les serveurs de la DMZ 4 plexes imposées par un firewall aux autres zones. Nous limiterons néanmoins notre intérêt à la zone démilitarisée (DMZ), dans laquelle sont disposés l ensemble des serveurs en production, dont ceux mentionnés en section 1.3. La figure 1.4 indique les services 4 non bloqués par le firewall entre l internet et la DMZ. Il s agit bien sûr d un schéma simplifié à l extrême que nous considérerons équivalent, dans le cadre de ce travail, à la situation réelle. DMZ HTTP Tous Firewall Internet Figure 1.4: Filtrage entre l internet et la DMZ Il existe de nombreuses autres règles entre les différentes zones, que nous ne détaillerons pas ici pour des raisons de pertinence et de confidentialité. 1.3 Les serveurs de la DMZ La zone démilitarisée ou DMZ est une zone logique du réseau jouissant de propriétés particulières. La différence fondamentale par rapport aux autres zones est son niveau de sécurité défini au sens des firewalls, c est-à-dire en rapport au nombre et à l importance des services bloqués. On dira ainsi que la DMZ est moins sécurisée que l intranet et plus sécurisée que l internet, zone ayant par définition le niveau de sécurité minimal puisque tous les services possibles y sont autorisés. Comme l illustre la figure 1.5, la DMZ de Publicis Technology comprend : les services de base d un réseau local ; 3 serveurs web de production ra, thot, anubis de type PC Pentium pilotés par le système d exploitation Linux 2.0 [29], distribution Debian 2.0 [30], exécutant le logiciel serveur Apache 1.3 [19] ; ils supportent 4 l origine d une flèche indique la zone cliente

16 1.3 Les serveurs de la DMZ 5 Ra Thot Anubis Rendev Renprod Horus Stats... DMZ Firewall Figure 1.5: Schéma de la DMZ la charge manuellement répartie de la plupart des sites web hébergés, chacun disposant d une adresse IP propre 5 ; 2 serveurs web de production rendev, renprod 6 de type Sun SPARC Netra i [38] pilotés par le système d exploitation Unix Solaris 2.5 [38], exécutant le logiciel serveur Netscape Enterprise Server 2 et 3 ; ces serveurs, plus fiables et performants, sont destinés à supporter les charges nettement supérieures induites par les conséquents accès aux sites de la société Renault ; 1 serveur multi-usages horus ; les journées de la semaine, il fait office de serveur 7 de fichiers pour les ordinateurs de bureau de la zone intranet, serveur d imprimantes et serveur web de développement. Les nuits et les week-ends, lorque la charge peut s élever sans perturber la qualité des services pré-cités, il exécute en batch les programmes chargés de générer les informations statistiques relatives à l audience obtenue par les serveurs web décrits ci-dessus ; d autres serveurs sortant du cadre de ce travail. Nous examinerons au chapitre 2 les détails de cette dernière procédure. Nous expliquerons également les implications de la coexistence des différentes tâches sur ce même serveur horus et nous expliquerons pourquoi et comment transférer la génération de statistiques audimétriques sur un serveur dédié, comme le représente la figure 1.6 comparé à la figure 1.5. Ra Thot Anubis Rendev Renprod Horus Stats... DMZ Firewall Figure 1.6: Schéma d évolution de la DMZ 5 cette fonctionnalité relativement complexe est propre aux versions les plus récentes d Apache et permet de façon transparente de simuler la présence de plusieurs machines physiques 6 malgré ce que pourraient laisser penser les noms de ces 2 machines, la séparation développement / production inhérente aux normes AFNOR en vigueur dans la société est ici purement logique 7 SMB et AppleTalk

17 1.4 Description du document Description du document Les informations qui viennent d être décrites constituent une base minimale nécessaire à la compréhension de ce qui suit. Elles sont destinées à synthétiser le problème afin de permettre de mieux appréhender celui-ci, les moyens mis en œuvre pour le résoudre ainsi que la solution effective. Il est bien clair qu elles ne reflètent en rien la réalité ; cependant même si l abstraction des difficultés, qu elles soient techniques ou non, masque la pertinence de certaines décisions, elle permet néanmoins d appliquer certaines méthodes ici présentées et de les adapter à des situations radicalement différentes. Le lecteur n aura pas manqué de constater que ce travail est initialement scindé en deux parties très différentes. La première attend un simple résultat 8 tandis que la seconde exploite une partie de ce dernier afin de permettre l étude d une technologie nouvelle, l application de celle-ci à un nouveau résultat, suivi de conclusions originales et surtout de très intéressantes perspectives. Le chapitre 2 montre comment il est possible de réaliser la génération et la mise en ligne statique d informations structurées à partir de fichiers bruts générés par des serveurs web. Le chapitre 3 étudie comment et dans quelles limites le langage Java peut être utilisé pour améliorer l interactivité entre le client et le serveur web. On décrira le fonctionnement de l API JDBC [1], des servlets [17] et du moteur JServ [21] en développement permettant d exploiter ces technologies au sein d un serveur web Apache [19]. Le chapitre 4 présente un exemple concret et complet de ce qu il est possible de réaliser à l aide de servlets. Le chapitre 5 expose les conclusions de l ensemble de ce travail. 8à savoir la mise en ligne statique d informations

18 Chapter 2 Mise en ligne statique Afin de simplifier le problème, nous supposerons que le processus complet de mise en ligne d informations statistiques statiques relatives aux accès à un site web donné est assurée par un unique logiciel 1 appelé pywrap. Ce chapitre en décrit principalement les concepts et le fonctionnement. 2.1 Introduction Dans un premier temps, la section 2.2 traitera de quelques caractéristiques des logs de serveurs web, qui sont ici la source de l information à structurer et à mettre en ligne. Ensuite, nous verrons comment, pour un site donné, récupérer l information utile contenue dans les fichiers de logs, comment la stocker de façon incrémentale dans une base de données et comment, par des accès rapides à celle-ci, générer un certain nombre de pages au format HTML, que le client propriétaire du site pourra consulter afin de connaître l audience obtenue par celui-ci, éventuellement pour l adapter en conséquence. La figure 2.1 schématise ce procédé, que nous allons détailler dans les sections suivantes. 1 comme nous le verrons, il s agit en réalité d un script encapsulant un ensemble d autres programmes

19 2.2 Les logs des serveurs web 8 Visiteurs Site A LOGS BASE DE DONNEES Pages HTML Propriétaire du site A Adaptation éventuelle du site en fonction de l audience Internet Figure 2.1: Schéma de traitement de l information 2.2 Les logs des serveurs web Un serveur web stocke le plus fréquemment l historique de ses transactions (voir aussi la section 1.1) dans 4 fichiers de logs distincts et complémentaires 2 : 1. l access log : adresse du client, nom d utilisateur éventuel, date et heure de la requête, fuseau horaire, requête HTTP, code d erreur, nombre d octets transférés au navigateur, 1 ligne par requête ; 2. le referer log : fichier consulté et adresse à partir de laquelle cette requête a été envoyée ; 3. l agent log : navigateur et système d exploitation utilisés sur le poste client ; 4. l error log : les messages d erreur éventuellement générés par le serveur. Une des tendances actuelles est de regrouper l information dans un seul fichier 3, ce qui permet une meilleure corrélation de l information au détriment d une rigidité de configuration supérieure et d un espace de stockage parfois plus important. D autres formats comme l Extended Log Format ou le Custom Log Format apportent davantage de souplesse. Format d une ligne d access_log : A.B.C D - [E:F:G:H I] "J K L" M N où : 2 CLF, Common Log Format 3 Combined Log Format

20 2.2 Les logs des serveurs web 9 A = nom de la machine cliente B = domaine de la machine cliente C = pays de la machine cliente D = nom d utilisateur éventuel E = date de la requête F = heure de la requête G = minutes de l heure de la requête H = secondes de l heure de la requête I = fuseau horaire du client J = type de requête K = fichier objet de la requête L = protocole de la requête M = code de réponse N = nombre d octets utiles transférés au client Exemple : crg-018.netra.canon.fr - - [18/Aug/1998:19:39: ] "GET /icons/jhe061.gif HTTP/1.0" Format d une ligne de referer_log : O -> P où : O P adresse d où la requête a été formulée fichier objet de la requête Exemple : -> /index.html Une ligne d agent_log peut quant à elle ressembler à ceci : Mozilla/4.05 [en] (Win95; I) d où il est possible de déduire le nom du navigateur 4, son numéro de version et le système d exploitation. A chaque requête d un navigateur au serveur web, celui-ci stocke une ligne de log dans chaque fichier spécifié par son fichier de configuration httpd.conf 5. Une requête peut être adressée par exemple pour une page HTML, mais aussi pour chaque image spécifiée dans celle-ci (voir la spécification du tag HTML <IMG> [27]). 4 attention, Netscape se déclare sous l identité Mozilla et certains navigateurs comme Microsoft Internet Explorer ont une identité ambigüe 5 /etc/apache/httpd.conf

21 2.3 Le transfert des logs 10 Afin de déterminer un ordre de grandeur, supposons qu une page HTML contient en moyenne 9 images 6 ; un visiteur consultant une telle page aura provoqué après chargement complet de celle-ci 10 lignes de logs de chaque type sur le serveur. Si l on considère qu une ligne d access log compte au moins une centaine de caractères et qu il en va de même pour le referer log et l agent log réunis, l accès d un visiteur à une page chargera en moyenne le disque du serveur de 2 Ko. Prenons le cas d un site obtenant une audience moyenne de 5000 pages prélevées par jour ; la taille des logs quotidiens de ce site atteindra 10 Mo par jour, soit plus de 3 Go par an! La quantité d information est donc telle qu il faut faire le tri parmi celle-ci et ne stocker que la partie la plus utile, réalisant le meilleur compromis possible entre précision de l information, espace de stockage et durée du traitement. 2.3 Le transfert des logs Chaque serveur web, et plus précisément chaque site web, génère sur le disque local ses propres fichiers de logs. Les différents sites web sont cependant hébergés par des machines physiques différentes 7, ce qui implique que les logs de chaque site sont répartis de façon extrêmement hétérogène sur l ensemble des disques des machines. En effet, un serveur peut héberger un nombre quelconque de sites 8, pourvu que sa puissance lui permette de répondre en un temps raisonnable à l ensemble des requêtes adressées aux sites qu il héberge. Comme l illustre la figure 2.2, il y a donc un multiplexage au niveau du serveur de noms de domaine (DNS, Domain Name Server) et un démultiplexage au niveau du serveur web. Le serveur de statistiques stats chargé de la mise à ligne des informations par traitement des fichiers de logs devra donc accéder à ceux-ci à travers le réseau voir figure 2.3, par exemple en exploitant le protocole FTP 9. Le logiciel pywrap prend comme unique argument une cible, c est-à-dire un nom symbolique désignant un site dont il faut générer les informations audimétriques. Par exemple, la cible rf correspond au site de la société Radio-France. La commande pywrap rf générera donc des pages HTML 6 ce qui reste une valeur assez faible dans le contexte des sites hébergés par Publicis Technology, souvent excessivement multimédias et dont le contenu repose alors essentiellement sur des images 7 dont le détail est mentionné en section on parle aussi de virtual hosts 9 File Transfer Protocol, protocole utilisé usuellement pour le transfert de fichiers à travers un réseau

22 2.3 Le transfert des logs 11 DNS thot disque thot Visiteurs LOGS thot APACHE LOGS LOGS Internet LAN Figure 2.2: Serveur web hébergeant plusieurs sites Ra Thot Anubis Stats FTP Figure 2.3: Récupération des logs par le réseau

23 2.3 Le transfert des logs 12 décrivant l audience du site de Radio-France. Le fichier de configuration stats.conf 10 contient les informations auxiliaires relatives à chaque cible, dont par exemple le nom complet du site correspondant : Target... Site EndTarget Cela permet à pywrap de passer la main au script getlog.py, écrit en langage python [33], avec comme argument le nom de la cible courante. Ce script, détaillé en annexe C.2, se chargera en substance de lire le fichier de configuration stats.conf, d y déterminer le nom exact du site correspondant à la cible, d établir une connexion FTP avec le serveur 11 hébergeant le site et de transférer les fichiers de logs de celui-ci sur le disque local 12 du serveur de statistiques à des fins de traitement, dont nous parlerons en section 2.4. Grâce aux méthodes mises en œuvre jusqu ici, pywrap peut récupérer l ensemble des logs d un serveur web distant afin de les traiter en local par la suite. Cette façon de procéder n est pas optimale. En effet, imaginons que l on souhaite générer le 01/01/1997 les statistiques d audience du site Radio- France depuis le 01/01/1996, date d entrée en service du site. Supposons pour fixer les idées que la taille des fichiers de logs pour cette période atteint une valeur totale de 4 Go sur le serveur web. A la vitesse de 1 Mo/s, le transfert FTP engorgerait le réseau pendant environ 60 minutes. De plus, une fois les logs présents sur le serveur de statistiques, l expérience confirme que leur traitement et le stockage des informations utiles dans la base de données dure environ une dizaine d heures, pendant lesquelles la machine tourne à plein rendement. La qualité des autres services peut être dès lors affectée. Plus grave encore, 4 Go d espace disque sont monopolisés sur cette durée. Ces chiffres, basés sur une valeur de la quantité de logs relativement modeste 10 /usr/local/pystats/main/stats.conf, voir aussi l annexe C aisément identifié grâce à une requête DNS 12 dans le répertoire spécifié par la directive globale LogDir du fichier de configuration stats.conf

24 2.3 Le transfert des logs 13 par rapport à la réalité, suffisent à mettre en évidence les conséquences de deux problématiques : l espace disque et le temps de calcul. En examinant la situation, deux constatations viennent immédiatement à l esprit : 1. les fichiers de logs prennent énormément de place, temporairement sur le serveur de statistiques, mais surtout de façon permanente sur les serveurs web ; il pourrait donc être intéressant d envisager une compression de ceux-ci ; 2. à chaque génération, les logs de la période traitée ne seront plus modifiés ; l information que l on peut en extraire sera donc toujours la même. Il serait dès lors judicieux de conserver celle-ci dans la base de données et, à chaque nouvelle génération, d y rajouter de façon incrémentale les informations apparues depuis la génération précédente. Remédier à ces deux problèmes offre plusieurs perspectives intéressantes : 1. division par un facteur 15 à 25 de la taille des fichiers de logs sur les serveurs web, 2. allégement des transferts par le réseau, 3. diminution radicale du temps de traitement, 4. moindre perturbation des autres services. La solution effectivement mise en place réside initialement sur les serveurs web ; au lieu de stocker les lignes de log dans un seul fichier, par exemple ~logs/access_log 13, le serveur enverra les lignes de logs dans un pipe Unix (cf. [10], p. 67), c est-à-dire vers l entrée standard d un programme, cronolog, qui se chargera de les répartir dans un fichier différent pour chaque jour. Par exemple, les logs du 18/07/1998 seront stockés dans le fichier ~logs/1998/07/access_log-18. Dès le 19/07/1998, on est ainsi certain que ledit fichier ne sera plus modifié. La récupération et le traitement de celui-ci par pywrap ne devra donc être effectué qu une seule fois ; le script getlog se chargera de le récupérer de manière unique. Nous avons ainsi réduit considérablement la masse de traitement confiée au serveur de statistiques. Cela ne résoud pas le problème de l espace disque des serveurs web, même si la tâche en devient plus aisée. En effet, nous savons 13 les exemples mentionnés se baseront désormais sur la manipulation de l access log mais les principes exposés sont applicables similairement aux autres types de fichiers de logs

25 2.3 Le transfert des logs 14 qu un fichier de logs correspondant à un jour écoulé ne sera plus modifé. Il peut donc être compressé, sans inconvénient pour le serveur web. Tentons d apprécier le bénéfice obtenu. Admettons que chaque jour, un script automatique (cf. annexes C.10, C.11 et C.11) compresse les logs de la veille. Etant donné que les fichiers de logs contiennent des informations extrêmement répétitives, les taux γ de compression sur ceux-ci seront sans nul doute excellents. L expérience montre que les facteurs de compression GNU ZIP sur ce type de fichiers s étendent entre 10 et 50, c est-à-dire : taille taille compressée taille =: γ [90%, 98%] Cela est remarquable. Le taux γ de compression global moyen 14 des logs d un serveur web est proche de 95%, ce qui signifie qu un serveur web générant 4 Go de logs bruts par an nécessitera un espace disque annuel de 200 Mo, ce qui est tout à fait acceptable. Une dernière préoccupation apparaît cepandant : pywrap et plus particulièrement les scripts getlog et pystats -r ne sont aptes qu à respectivement récupérer par FTP et traiter des fichiers de logs entiers. Ils doivent donc être adaptés afin de pouvoir gérer le morcèlement et la compression précédemment établis. Nous verrons à la section 2.4 que le script pystats -r sera écrit de manière à manipuler des fichiers de logs décompressés tout à fait quelconques. Il procédera de manière incrémentale au niveau du stockage dans la base de données ; l entité minimale de traitement sera la ligne de log, indépendamment de la quantité de lignes fournies à l exécution et de l ordre dans lequel celles-ci se présentent. La seule restriction sera de ne jamais fournir plusieurs fois les mêmes logs au programme, ce dont on peut s assurer aisément en ne manipulant que des logs de jours entièrement écoulés et en notant la date des derniers logs traités. C est le rôle du fichier lastr dont nous reparlerons ci-dessous. Les logs à récupérer sont donc ceux compris entre la date de dernière récupération lastr et la date courante. D après les conventions adoptées pour le nommage des fichiers de logs, il est aisé de connaître les noms exacts des fichiers à récupérer sur les serveurs web, pour peu que l on connaisse sur celui-ci le répertoire de base dans lequel a lieu le stockage. Cette information se trouve dans le fichier de configuration stats.conf : Target rf 14 valeur empirique

26 2.3 Le transfert des logs RemoteLog /usr/local/www/logs/rf... EndTarget Dans cet exemple, le nom complet d un fichier du 18/09/1998 sur le serveur web sera : /usr/local/www/logs/rf/1998/09/access_log-18 S il est compressé à l aide de l algorithme GNU ZIP, il portera le suffixe.gz. C est sur base de ce principe que le script getlog détectera si un fichier à récupérer a été compressé. Il commencera par initialiser un fichier local 15 access_log vide dans lequel il ajoutera au fur et à mesure les lignes de logs transférées par FTP. Si pour une date donnée le fichier correspondant est manquant, getlog tentera de télécharger une version compressée suffixée par l extension.gz. Les lignes ne seront alors bien sûr pas ajoutées au fichier temporaire access_log mais stockées dans un fichier access_log2.gz qui, une fois entièrement transféré, sera décompressé en access_log2, lui-même concaténé au fichier access_log et effacé. La figure 2.4 résume ce procédé. Serveur web FTP access_log2.gz access_log2 access_log Figure 2.4: Récupération de fichiers de logs compressés 15 rappelons que le répertoire dans lequel ce fichier temporaire est créé est fixé par la directive globale LogDir du fichier de configuration stats.conf

27 2.4 Le traitement des logs Le traitement des logs Concentrons-nous à présent sur le serveur de statistiques, sur lequel se dérouleront l ensemble des étapes à venir, à savoir le dépouillement de l information contenue dans les fichiers de logs copiés en local par les opérations précédentes, le stockage de celle-ci dans une base de données locale, la mise en forme de pages HTML à partir de requêtes adressées au SGBD et enfin la mise en ligne de ces pages grâce à un serveur web local. Bien que la plupart des SGBD dont celui que nous allons utiliser fonctionnent selon le modèle client-serveur, le fait de travailler sur une seule et même machine ne pose pas de problème. En effet, le système d exploitation Unix, copié par quelques autres, implémente le mécanisme des Fast Unix Domain Sockets [14, 13], permettant de simuler localement la présence d un réseau en bouclant les requêtes. Le SGBD utilisé sera mysql [22], soutenu par le système d exploitation Linux 2.0, distibution Debian 2.0. MySQL est un produit ouvert et gratuit pour des fins non commerciales directes. Malgré un nombre de fonctionnalités limitées, il offre une robustesse et des performances très correctes. Il supporte une grande partie du standard SQL2, détaillé dans la référence [6] p Nous verrons aussi à la section que ce SGBD peut être accédé facilement par une application 100% pure Java. Pour la prochaine étape, pywrap passe la main à un script python détaillé en annexe C.4 : pystats -r. Ce programme est chargé de lire les logs en local, ligne par ligne, de conserver l information utile et de la stocker dans la base de données correspondante à la cible et dont le nom 16 est spécifié dans le fichier de configuration stats.conf par la directive DataBase : Target rf... DataBase rf... EndTarget Le choix de l information conservée est déterminant. Comme cela a déjà été mentionné, il s agit d un compromis entre la précision de l information d une part et la durée du traitement et de la mise en forme d autre part. Si le nombre total d accès à une page donnée par rapport à une autre a une importance capitale, il n en va certainement pas de même du nombre 16 N.B. : le nom d une base mysql ne peut contenir le caractère - depuis la version 3.21

28 2.4 Le traitement des logs 17 d accès obtenus dans une minute donnée de la journée. Par contre, il est difficile d évaluer a priori l importance du nom complet de chaque machine connectée. Seule l expérience fait apparaître ce type de besoin, à partir des appréciations des clients. Digression : il est important de noter que dans cette fin de section, les travaux sont guidés par une spécification prédéfinie, décrite ci-dessous et indispensable à suivre pour s intégrer à l existant et assurer le bon fonctionnement de celui-ci. Cette spécification n est certainement pas optimale ; la section 4.4 propose d ailleurs quelques améliorations possibles. Rappelons le format d une ligne d access log : A.B.C D - [E:F:G:H I] "J K L" M N Voici l information qui doit être conservée : A D G H I J L M nom de machine cliente nom d utilisateur éventuel minutes de l heure de la requête secondes de l heure de la requête fuseau horaire du client type de requête protocole de la requête code de réponse Les informations contenues dans des fichiers de referer et d agent sont toutes conservées. L error log n est pas pris en compte. Pour extraire l information de chaque ligne, pystats -r emploie des expressions régulières, dont le principe est expliqué en annexe A.2. Cette information devra être stockée de manière structurée dans une base de données correspondant au site en cours de traitement. Les schémas de relation d une telle base se présentent comme suit : Pour chaque mois, la table houryyyymm 17 donne le cumul des hits par heure : hits0 hits1 hits2 hits De même, les accès aux pages sont stockés tous les mois dans la table summaryyyyymm : 17 où YYYY représente l année et MM représente le mois

29 2.4 Le traitement des logs 18 url day country hits /index.html fr Pour l ensemble du site depuis sa mise en exploitation, du moins sur la période auditée, les informations récoltées sur les postes clients sont stockées dans la tables agent : name version OS hits Mozilla 4.05 win Les quantités de requêtes et d octets transférés par le réseau par jour sont stockées dans la table transfer : day hits quantity Les domaines à partir desquels les requêtes ont été envoyées sont répertoriées dans la table domain : domain hits imaginet.fr Les points d accès au site, source et destination, sont repris dans la table referer. La colonne search indique éventuellement le nom du moteur de recherche si la source d accès a été détectée comme telle 18. De plus, une ligne du referer log est ignorée si la source correspond à une expression régulière spécifiée par la directive RefererIgnore du fichier de configuration stats.conf. Cela permet de ne pas tenir compte du trafic interne et de mieux cerner les points d entrée au site. url site search hits /index.htm http ://finanza.yahoo.com/ yahoo le programme dispose d une liste de référence des principaux moteurs de recherche

30 2.4 Le traitement des logs 19 Les mots-clés de recherche utilisés dans les moteurs pour atteindre les pages sont dans la table words : Url Word Nb /index.htm renault A partir de cet ensemble de tables, le script pystats.py -g génère les pages et les graphiques à l aide de templates 19 et de librairies graphiques. Figure 2.5: Ecran d accueil Les principaux résultats proposés figure 2.5 sont les suivants : calcul du nombre de pages prélevées, de hits et d accès à la page principale ; connexions par page, pays, domaines ; évolution de l audience, globalement (figure 2.6), pour chaque mois (figure 2.7), et pour chaque page consultée ; audience en fonction des tranches horaires (figure 2.8) ; 19 fichiers modèles

31 2.4 Le traitement des logs 20 résolution du navigateur utilisé, y compris le numéro de version, et du système d exploitation (figures 2.9, 2.10 et 2.11) ; détails d accès par page ; tableaux Excel et HTML des hits par page et par jour pour un mois donné ; calcul du débit mensuel ; points et sources d entrées au site ; mots-clés utilisés dans les moteurs de recherche pour accéder au site ; possibilité d obtenir un rapport résumé personnalisé. Figure 2.6: Evolution de l audience au fil des mois Figure 2.7: Evolution de l audience sur un mois donné

32 2.4 Le traitement des logs 21 Figure 2.8: Audience en fonction des tranches horaires Figure 2.9: Navigateurs utilisés Figure 2.10: Versions de navigateur utilisées

33 2.5 Constatations 22 Figure 2.11: Systèmes d exploitation utilisés 2.5 Constatations A ce stade du travail, une procédure à la fois souple et robuste peut être mise en production. Comme nous venons de l étudier, pywrap génère pour chaque site des pages HTML consultables par le client à qui il appartient. Un serveur web Apache 1.3 est responsable de la mise en ligne de ces pages. Le nom du serveur est stats.sgip.fr et la racine de celui-ci correspond à un répertoire 20 du serveur physique. Dans ce répertoire racine, chaque cible dispose d un répertoire propre spécifié par la directive OutDir du fichier de configuration stats.conf : Target rf... OutDir /usr/local/pystats/htdocs/rf/... EndTarget Ce répertoire contient l ensemble des pages HTML décrivant l audience du site correspondant. Ces pages sont bien sûr confidentielles et doivent être protégées par un système de mots de passe. Pour ce faire, un fichier HTACCESS 21 indique quels utilisateurs ont accès à ce répertoire et à ceux qu il contient. Un fichier protégé 22 contient la liste des utilisateurs et des mots de passe correspondants. Le programme htpasswd permet de rajouter des utilisateurs à cette liste. Lorsqu un client se connecte à l URL des statistiques d audience de son site, par exemple pour la société Canon 20 /usr/local/pystats/htdocs/ 21 ce nom est standardisé sur l ensemble des serveurs web de la société 22 /etc/apache/htpasswd

34 2.5 Constatations 23 il sera demandé par le navigateur d entrer un nom d utilisateur et le mot de passe adéquat, qui auront été communiqués en privé aux responsables de la société correspondante. L utilisateur admin possède un mot de passe passe-partout réservé aux administrateurs. Une page d accueil similaire à celle de la figure 2.5 permet de naviguer à travers des pages HTML parsemées de liens hypertextes. L information renfermée par celles-ci est considérable et rigoureusement structurée. Pour un site moyennement visité, le nombre de pages HTML proposées est de l ordre de 1000 à et celles-ci sont illustrées par 100 à 1000 images au format GIF. L espace disque occupé s échelonne entre 3 Mo et 30 Mo. L ensemble des sites représente donc 200 à 400 Mo d informations en ligne, dont la génération dure environ 48 heures. Le débit moyen hebdomadaire du serveur web chargé exclusivement de la mise en ligne de celles-ci ne dépasse pourtant pas 2 Mo, ce qui signifie que plus de 99% des informations générées (et donc du temps de calcul consacré à cette tâche) ne sont pas consultées et sont donc totalement inutiles. Cependant, comme il est impossible de déterminer a priori quelles informations audimétriques seront consultées par le client, il est indispensable de tout générer à chaque exécution. De plus, il serait inacceptable de laisser en ligne des informations datant de plus d une semaine 23, ce qui impose un rafraîchissement hebdomadaire, généralement opéré pendant le week-end. La problématique est dès lors très claire ; étant donné que chaque client ne souhaite pas disposer de moins d informations 24, ni d une autre structure ou présentation de celles-ci, ce modèle de génération ne peut être modifé brutalement. L expérience, à l instar de la loi de Moore [11], indique que le monde informatique double annuellement. Ce facteur est bien sûr approximatif et ne s applique pas exactement à tous les domaines. Il reflète cependant l aspect exponentiel d une croissance de ce type et nous permettra d établir un ordre de grandeur. Le réseau internet, et donc le nombre d accès à des serveurs web, se développe actuellement selon ce modèle [13] 25. On peut donc raisonnablement estimer qu en plus ou moins trois ans, le nombre d accès, donc de logs, donc de temps de génération des informations sur le serveur de statistiques, atteindra approximativement huit fois la valeur actuelle. Dès lors, 23 certains clients exigent même des informations rafraîchies quotidiennement sur certaines périodes promotionnelles critiques! 24 certains réclament même plus de détails 25 en pariculier en France, principal pays d où proviennent les consultations aux sites web hébergés par Publicis Technology

35 2.5 Constatations 24 les 48 heures hebdomadaires actuelles de génération, toutes autres choses étant égales, s étendraient à 400 heures hebdomadaires, soit plus de deux fois la capacité de prise en charge du serveur actuel. La conclusion de ces quelques calculs et considérations est que si l on souhaite conserver ou éventuellement augmenter : le nombre de sites hébergés, les accès à ces sites, la quantité d informations générées, le taux de rafraîchissement de celles-ci, l architecture du modèle actuel, la seule solution est de suivre une course à l armement informatique, matériel et logiciel. Toutefois, si le renouvellement de l équipement matériel représente un coup relativement acceptable, il n en va certainement pas de même du logiciel et de l adaptation de celui-ci 26. Les quatre premiers points limitatifs doivent absolument être conservés voire augmentés (ce qui serait même souhaitable). Dès lors, le dernier aspect de la question mérite d être étudié avec la plus grande attention : le système de mise en ligne. La spécification en place indique qu un certain nombre d informations doivent être mises en ligne. De plus, une forte recommandation impose la conservation de leur structure actuelle. Nous avons vu que dans des conditions stables cette situation est viable pour au moins deux ans. Cela laisse le temps de migrer le système vers une mise en ligne équivalente, basée sur une architecture plus adéquate. 26 rappelons que le logiciel a été développé en interne et qu il implique donc des coûts de maintenance et de mise à jour non négligeables