1 <?xml version="1.0" encoding="ISO-8859-1" ?>
2 <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
3 <?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
4 <!-- French translation : Lucien GENTIS -->
5 <!-- Reviewed by : Vincent Deffontaines -->
6 <!-- English Revision: 758929 -->
9 Licensed to the Apache Software Foundation (ASF) under one or more
10 contributor license agreements. See the NOTICE file distributed with
11 this work for additional information regarding copyright ownership.
12 The ASF licenses this file to You under the Apache License, Version 2.0
13 (the "License"); you may not use this file except in compliance with
14 the License. You may obtain a copy of the License at
16 http://www.apache.org/licenses/LICENSE-2.0
18 Unless required by applicable law or agreed to in writing, software
19 distributed under the License is distributed on an "AS IS" BASIS,
20 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
21 See the License for the specific language governing permissions and
22 limitations under the License.
25 <manualpage metafile="logs.xml.meta">
27 <title>Fichiers journaux</title>
30 <p>Pour véritablement gérer un serveur web,
31 il est nécessaire de disposer d'un
32 retour d'informations à propos de l'activité et des performances du
33 serveur, ainsi que de tout problème qui pourrait survenir. Le serveur HTTP
34 Apache propose des fonctionnalités de journalisation souples et très
35 complètes. Ce document décrit comment configurer ces fonctionnalités de
36 journalisation et interpréter le contenu des journaux.</p>
39 <section id="security">
40 <title>Avertissement à propos de la sécurité</title>
42 <p>Tout utilisateur qui a les droits en écriture sur le répertoire dans
43 lequel Apache écrit ses journaux pourra quasi
44 certainement avoir accès à l'uid sous lequel le serveur est démarré, en
45 l'occurrence habituellement root. N'accordez <em>PAS</em> aux utilisateurs
46 l'accès en écriture au répertoire dans lequel les journaux sont stockés
47 sans savoir exactement quelles en seraient les conséquences ; voir le
48 document <a href="misc/security_tips.html">conseils sur la sécurité</a>
49 pour plus de détails.</p>
51 <p>En outre, les journaux peuvent contenir des informations fournies
52 directement par un client, sans caractères d'échappement. Des clients mal
53 intentionnés peuvent donc insérer des caractères de contrôle dans les
54 journaux, et il convient par conséquent d'être très prudent lors de la
55 manipulation des journaux bruts.</p>
58 <section id="errorlog">
59 <title>Journal des erreurs</title>
63 <directive module="core">ErrorLog</directive>
64 <directive module="core">LogLevel</directive>
68 <p>Le journal des erreurs du serveur, dont le nom et la localisation sont
69 définis par la directive <directive module="core">ErrorLog</directive>,
70 est le journal le plus important. C'est dans celui-ci
71 que le démon Apache httpd va envoyer les informations de diagnostic et
72 enregistrer toutes les erreurs qui surviennent lors du traitement des
73 requêtes. Lorsqu'un problème survient au démarrage du serveur ou pendant
74 son fonctionnement, la première chose à faire est de regarder dans ce
75 journal, car il vous renseignera souvent sur le problème rencontré et
76 la manière d'y remédier.</p>
78 <p>Le journal des erreurs est habituellement enregistré dans un fichier
79 (en général <code>error_log</code> sur les systèmes de type Unix et
80 <code>error.log</code> sur Windows). Sur les systèmes de type Unix,
81 le serveur peut aussi enregistrer ses erreurs dans
82 <code>syslog</code> ou les
83 <a href="#piped">rediriger vers un programme</a> par l'intermédiaire d'un
84 tube de communication (pipe).</p>
86 <p>Le format du journal des erreurs est descriptif et de forme
87 relativement libre. Certaines informations apparaissent cependant dans la
88 plupart des entrées du journal. Voici un message typique
89 à titre d'exemple : </p>
92 [Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1]
93 client denied by server configuration:
94 /export/home/live/ap/htdocs/test
97 <p>Le premier champ de l'entrée du journal est la date et l'heure du
98 message. Le second champ indique la sévérité de l'erreur rapportée. La
99 directive <directive module="core">LogLevel</directive> permet de
100 restreindre le type des erreurs qui doivent être enregistrées
101 dans le journal des erreurs en définissant leur niveau de sévérité. Le
102 troisième champ contient l'adresse IP du client qui a généré l'erreur.
103 Vient ensuite le message proprement dit, qui indique dans ce cas que le
104 serveur a été configuré pour interdire l'accès au client. Le serveur
105 indique le chemin système du document requis (et non
108 <p>Une grande variété de messages différents peuvent apparaître dans le
109 journal des erreurs. La plupart d'entre eux sont similaires à l'exemple
110 ci-dessus. Le journal des erreurs peut aussi contenir des informations de
111 débogage en provenance de scripts CGI. Toute information qu'un script CGI
112 écrit sur la sortie d'erreurs standard <code>stderr</code> sera recopiée
113 telle quelle dans le journal des erreurs.</p>
115 <p>Il n'est pas possible de personnaliser le journal des erreurs en ajoutant ou en
116 supprimant des informations. Cependant, les entrées du journal des erreurs
117 qui concernent certaines requêtes possèdent des entrées correspondantes
118 dans le <a href="#accesslog">journal des accès</a>. Ainsi, l'entrée de
119 l'exemple ci-dessus correspond à une entrée du journal des accès avec un
120 code de statut 403. Etant donné qu'il est possible de personnaliser le
121 journal des accès, vous pouvez obtenir d'avantage d'informations sur les
122 circonstances d'une erreur en consultant ce journal.</p>
124 <p>Pendant la phase de test, il est souvent utile de visualiser en continu
125 le journal des erreurs afin de détecter tout problème éventuel. Sur les
126 systèmes de type Unix, ceci s'effectue à l'aide de la commande :</p>
133 <section id="accesslog">
134 <title>Journal des accès</title>
138 <module>mod_log_config</module>
139 <module>mod_setenvif</module>
142 <directive module="mod_log_config">CustomLog</directive>
143 <directive module="mod_log_config">LogFormat</directive>
144 <directive module="mod_setenvif">SetEnvIf</directive>
148 <p>Le journal des accès au serveur
149 enregistre toutes les requêtes que traite
150 ce dernier. La localisation et le contenu du journal des accès sont définis
151 par la directive <directive module="mod_log_config">CustomLog</directive>.
152 La directive <directive module="mod_log_config">LogFormat</directive>
153 permet de simplifier la sélection du contenu du journal. Cette section
154 décrit comment configurer le serveur pour l'enregistrement des informations
155 dans le journal des accès.</p>
157 <p>Bien évidemment, le stockage d'informations dans le journal des accès
158 n'est que le point de départ de la gestion de la journalisation. L'étape
159 suivante consiste à analyser ces informations de façon à pouvoir en
160 extraire des statistiques utiles. L'analyse de journaux en général est en
161 dehors du sujet de ce document et ne fait pas vraiment partie intégrante
162 du travail du serveur web lui-même. Pour plus d'informations à propos de ce
163 sujet et des applications dédiées à l'analyse de journaux, vous pouvez vous
164 référer à <a href="http://dmoz.org/Computers/Software/Internet/
165 Site_Management/Log_analysis/">Open Directory</a> ou
166 <a href="http://dir.yahoo.com/Computers_and_Internet/Software/
167 Internet/World_Wide_Web/Servers/Log_Analysis_Tools/">Yahoo</a>.</p>
169 <p>Différentes versions du démon Apache httpd utilisaient d'autres modules
170 et directives pour contrôler la journalisation des accès, à l'instar de
171 mod_log_referer, mod_log_agent, et de la directive
172 <code>TransferLog</code>. La directive
173 <directive module="mod_log_config">CustomLog</directive> rassemble
174 désormais les fonctionnalités de toutes les anciennes directives.</p>
176 <p>Le format du journal des accès est hautement configurable. Il est
177 défini à l'aide d'une chaîne de format qui ressemble sensiblement à la
178 chaîne de format de style langage C de printf(1). Vous trouverez quelques
179 exemples dans les sections suivantes. Pour une liste exhaustive de ce que
180 peut contenir une chaîne de format, vous pouvez vous référer au chapitre
181 <a href="mod/mod_log_config.html#formats">chaînes de format</a> de la
182 documentation du module <module>mod_log_config</module>.</p>
184 <section id="common">
185 <title>Format habituel du journal</title>
187 <p>Voici une configuration typique pour le journal des accès :</p>
190 LogFormat "%h %l %u %t \"%r\" %>s %b" common<br />
191 CustomLog logs/access_log common
194 <p>Ici est définie l'<em>identité</em> <code>common</code> qui est
195 ensuite associée à une chaîne de format de journalisation particulière.
196 La chaîne de format est constituée de directives débutant par le
197 caractère %, chacune d'entre elles indiquant au serveur d'enregistrer
198 un élément particulier d'information. Des caractères littéraux peuvent
199 aussi être insérés dans la chaîne de format ; il seront copiés tels
200 quels dans le flux de sortie destiné à la journalisation.
201 Les guillemets (<code>"</code>) doivent être échappées en les faisant
202 précéder d'un anti-slash (<code>\</code>) afin qu'elles ne soient pas
203 interprétées comme la fin de la chaîne de format. La chaîne de format
204 peut aussi contenir les caractères de contrôle spéciaux
205 "<code>\n</code>" et "<code>\t</code>" pour insérer respectivement
206 un passage à la ligne et une tabulation.</p>
208 <p>La directive <directive module="mod_log_config">CustomLog</directive>
209 définit un nouveau fichier journal en l'associant à l'identité
210 précédemment définie. Le chemin du nom de fichier associé au journal
211 des accès est relatif au chemin défini par la directive
212 <directive module="core">ServerRoot</directive>, sauf s'il
213 débute par un slash.</p>
215 <p>La configuration ci-dessus va enregistrer les entrées de
216 journalisation selon un format connu sous le nom de
217 Common Log Format (CLF) pour "Format de journalisation standard".
218 Ce format standard peut être produit par de nombreux serveurs web
219 différents et lu par de nombreux programmes d'analyse de journaux.
220 Les entrées de fichier journal générées selon le format CLF
221 ressemblent à ceci :</p>
224 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
225 /apache_pb.gif HTTP/1.0" 200 2326
228 <p>Chaque partie de cette entrée de journal est décrite
229 dans ce qui suit.</p>
232 <dt><code>127.0.0.1</code> (<code>%h</code>)</dt>
234 <dd>Il s'agit de l'adresse IP du client (l'hôte distant) qui a envoyé
235 la requête au serveur. Si la directive
236 <directive module="core">HostnameLookups</directive> est positionnée à
237 <code>On</code>, le serveur va essayer de déterminer le nom de l'hôte
238 et de l'enregistrer à la place de l'adresse IP. Cette configuration
239 n'est cependant pas recommandée car elle peut ralentir le serveur de
240 manière significative. Il est par conséquent préférable d'utiliser un
241 processeur d'analyse de journaux a posteriori
242 tel que <program>logresolve</program>
243 pour déterminer les noms d'hôte. L'adresse IP indiquée ici n'est pas
244 nécessairement l'adresse IP de la machine devant laquelle se trouve
245 l'utilisateur. Si un serveur mandataire s'intercale entre le serveur
246 et l'utilisateur, l'adresse indiquée sera celle du mandataire et non
247 celle de la machine à l'origine de la requête.</dd>
249 <dt><code>-</code> (<code>%l</code>)</dt>
251 <dd>Le "trait d'union" indique que la portion d'information
252 correspondante n'est pas disponible. Dans le cas présent, l'information
253 non disponible est l'identité (RFC 1413) du client telle que déterminée
254 par <code>identd</code> sur la machine cliente. Cette information est
255 très peu fiable et ne devrait jamais être utilisée, sauf dans le cas
256 de réseaux internes étroitement contrôlés. Le démon httpd ne cherchera
257 d'ailleurs à obtenir cette information que si la directive
258 <directive module="core">IdentityCheck</directive> est positionnée
259 à <code>On</code>.</dd>
261 <dt><code>frank</code> (<code>%u</code>)</dt>
263 <dd>Il s'agit de l'identifiant utilisateur de la personne qui a
264 demandé le document, issu d'une authentification HTTP.
265 Ce même identifiant est en général fourni aux scripts CGI par
266 l'intermédiaire de la valeur de la variable d'environnement
267 <code>REMOTE_USER</code>. Si le statut de la requête (voir plus loin)
268 est 401, cette identifiant n'est pas fiable car l'utilisateur n'est
269 pas encore authentifié. Si le document n'est pas protégé par
270 mot de passe, cette partie d'information sera représentée par
271 "<code>-</code>", comme la partie précédente.</dd>
273 <dt><code>[10/Oct/2000:13:55:36 -0700]</code>
274 (<code>%t</code>)</dt>
277 L'heure à laquelle la requête a été reçue.
278 Le format est le suivant :
281 <code>[jour/mois/année:heure:minutes:secondes zone]<br />
282 jour = 2*chiffre<br />
283 mois = 3*lettre<br />
284 année = 4*chiffre<br />
285 heure = 2*chiffre<br />
286 minutes = 2*chiffre<br />
287 secondes = 2*chiffre<br />
288 zone = (`+' | `-') 4*chiffre</code>
289 </p>Il est possible de modifier le format d'affichage de l'heure
290 en spécifiant <code>%{format}t</code> dans la chaîne de format du
291 journal, où <code>format</code> est une chaîne de format de même
292 forme que celle de la fonction <code>strftime(3)</code> de la
293 bibliothèque C standard.
296 <dt><code>"GET /apache_pb.gif HTTP/1.0"</code>
297 (<code>\"%r\"</code>)</dt>
299 <dd>La ligne de la requête du client est placée entre guillemets.
300 Elle contient de nombreuses informations utiles. Tout d'abord, la
301 méthode utilisée par le client est <code>GET</code>. Ensuite, le
302 client a demandé la ressource <code>/apache_pb.gif</code>, et enfin,
303 le client a utilisé le protocole <code>HTTP/1.0</code>. Il est aussi
304 possible d'enregistrer séparément une ou plusieurs parties de la
305 requête. Par exemple, la chaîne de format "<code>%m %U %q %H</code>"
306 va enregistrer la méthode, le chemin, la chaîne de la requête et le
307 protocole, ce qui donnera le même résultat que
308 "<code>%r</code>".</dd>
310 <dt><code>200</code> (<code>%>s</code>)</dt>
312 <dd>C'est le code de statut que le serveur retourne au client. Cette
313 information est très importante car elle indique si la requête a fait
314 l'objet d'une réponse positive (codes commençant par 2), une
315 redirection (codes commençant par 3), une erreur due au client (codes
316 commençant par 4), ou une erreur due au serveur (codes commençant
317 par 5). Vous trouverez la liste complète des codes de statut possibles
318 dans la <a href="http://www.w3.org/Protocols/rfc2616/
319 rfc2616.txt">specification HTTP</a> (RFC2616 section 10).</dd>
321 <dt><code>2326</code> (<code>%b</code>)</dt>
323 <dd>La dernière partie indique la taille de l'objet retourné au client,
324 en-têtes non compris. Si aucun contenu n'a été retourné au client, cette
325 partie contiendra "<code>-</code>". Pour indiquer l'absence de contenu
326 par "<code>0</code>", utilisez <code>%B</code> au lieu de
327 <code>%b</code>.</dd>
331 <section id="combined">
332 <title>Combined Log Format (Format de journalisation combiné)</title>
334 <p>Une autre chaîne de format couramment utilisée est le
335 "Combined Log Format" (Format de journalisation combiné). Il s'utilise
339 LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
340 \"%{User-agent}i\"" combined<br />
341 CustomLog log/access_log combined
344 <p>Ce format est identique au Common Log Format, avec deux champs
345 supplémentaires. Chacun de ces deux champs utilise la directive
346 commençant par le caractère "%" <code>%{<em>header</em>}i</code>,
347 où <em>header</em> peut être n'importe quel en-tête de requête HTTP.
348 Avec ce format, le journal des accès se présentera comme suit :</p>
351 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
352 /apache_pb.gif HTTP/1.0" 200 2326
353 "http://www.example.com/start.html" "Mozilla/4.08 [en]
357 <p>Les champs supplémentaires sont :</p>
360 <dt><code>"http://www.example.com/start.html"</code>
361 (<code>\"%{Referer}i\"</code>)</dt>
363 <dd>L'en-tête "Referer" (sic) de la requête HTTP. Il indique le site
364 depuis lequel le client prétend avoir lancé sa requête. (Ce doit être
365 la page qui contient un lien vers <code>/apache_pb.gif</code> ou
366 inclut ce dernier fichier).</dd>
368 <dt><code>"Mozilla/4.08 [en] (Win98; I ;Nav)"</code>
369 (<code>\"%{User-agent}i\"</code>)</dt>
371 <dd>L'en-tête User-Agent de la requête HTTP. C'est une information
372 d'identification que le navigateur du client envoie à propos
373 de lui-même.</dd>
377 <section id="multiple">
378 <title>Journaux d'accès multiples</title>
380 <p>Plusieurs journaux d'accès peuvent être créés en spécifiant tout
381 simplement plusieurs directives
382 <directive module="mod_log_config">CustomLog</directive> dans le
383 fichier de configuration. Par exemple, les directives suivantes vont
384 créer trois journaux d'accès. Le premier contiendra les informations
385 de base CLF, le second les informations du Referer, et le troisième
386 les informations sur le navigateur. Les deux dernières directives
387 <directive module="mod_log_config">CustomLog</directive> montrent
388 comment simuler les effets des directives <code>ReferLog</code> et
389 <code>AgentLog</code>.</p>
392 LogFormat "%h %l %u %t \"%r\" %>s %b" common<br />
393 CustomLog logs/access_log common<br />
394 CustomLog logs/referer_log "%{Referer}i -> %U"<br />
395 CustomLog logs/agent_log "%{User-agent}i"
398 <p>Cet exemple montre aussi qu'il n'est pas obligatoire d'associer
399 une chaîne de format à un alias au moyen de la directive
400 <directive module="mod_log_config">LogFormat</directive>. Elle peut
401 être définie directement dans la ligne de la directive
402 <directive module="mod_log_config">CustomLog</directive>.</p>
405 <section id="conditional">
406 <title>Journalisation conditionnelle</title>
408 <p>Il est parfois souhaitable d'exclure certaines entrées des journaux
409 d'accès en fonction des caractéristiques de la requête du client. On
410 peut aisément accomplir ceci à l'aide des
411 <a href="env.html">variables d'environnement</a>. Tout d'abord, une
412 variable d'environnement doit être définie pour indiquer que la
413 requête remplit certaines conditions. Pour ceci, on utilise en général
414 la directive <directive module="mod_setenvif">SetEnvIf</directive>,
415 puis la clause <code>env=</code> de la directive
416 <directive module="mod_log_config">CustomLog</directive> pour inclure
417 ou exclure les requêtes pour lesquelles
418 la variable d'environnement est définie.
419 Quelques exemples :</p>
422 # Marque les requêtes en provenance de l'interface loop-back<br />
423 SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog<br />
424 # Marque les requêtes pour le fichier robots.txt<br />
425 SetEnvIf Request_URI "^/robots\.txt$" dontlog<br />
426 # Journalise toutes les autres requêtes<br />
427 CustomLog logs/access_log common env=!dontlog
430 <p>Autre exemple, imaginons l'enregistrement des requêtes en provenance
431 d'utilisateurs de langue anglaise dans un journal, et celles des autres
432 utilisateurs dans un autre journal.</p>
435 SetEnvIf Accept-Language "en" english<br />
436 CustomLog logs/english_log common env=english<br />
437 CustomLog logs/non_english_log common env=!english
440 <p>Bien que nous venions de montrer que la journalisation conditionnelle
441 est souple et très puissante, cette méthode de contrôle du contenu des
442 journaux n'est pas la seule. Les fichiers journaux sont plus utiles
443 quand ils contiennent un enregistrement complet de l'activité du serveur,
444 et il est souvent plus aisé de simplement traiter à posteriori les fichiers
445 journaux pour supprimer les requêtes que vous ne voulez pas y voir
446 apparaître.</p>
450 <section id="rotation">
451 <title>Rotation des journaux</title>
453 <p>Même dans le cas d'un serveur modérément sollicité, la quantité
454 d'informations stockées dans les fichiers journaux est très importante.
455 Le fichier journal des accès grossit en général d'1 Mo ou plus toutes
456 les 10000 requêtes. Il est par conséquent nécessaire d'effectuer
457 périodiquement la rotation des journaux en déplaçant ou supprimant les
458 fichiers correspondants. On ne peut pas le faire pendant que le serveur
459 est en cours d'exécution, car Apache va continuer à écrire dans l'ancien
460 fichier journal aussi longtemps qu'il le maintiendra ouvert.
461 C'est pourquoi le serveur doit être
462 <a href="stopping.html">redémarré</a> après le déplacement ou la
463 suppression des fichiers journaux de façon à ce qu'il en ouvre
466 <p>Avec un redémarrage <em>graceful</em>, on peut faire en sorte que le
467 serveur ouvre de nouveaux fichiers journaux sans perdre de connexions
468 existantes ou en cours avec les clients. Cependant, pour que ceci soit
469 possible, le serveur doit continuer à écrire dans les anciens fichiers
470 journaux pendant qu'il termine le traitement des requêtes en cours.
471 Il est donc nécessaire d'attendre un certain temps après le rédémarrage
472 avant d'effectuer tout traitement sur les fichiers journaux. Voici un
473 scénario typique dans lequel on effectue une simple rotation des
474 journaux en compressant les anciens fichiers correspondants afin
475 de gagner de l'espace disque :</p>
478 mv access_log access_log.old<br />
479 mv error_log error_log.old<br />
480 apachectl graceful<br />
482 gzip access_log.old error_log.old
485 <p>La section suivante présente une autre méthode de rotation des journaux
486 qui consiste à utiliser les
487 <a href="#piped">journaux redirigés</a>.</p>
491 <title>Journaux redirigés</title>
493 <p>Nous avons vu que le démon httpd écrivait les informations de
494 journalisation des erreurs et des accès dans un fichier journal ;
496 rediriger ces informations vers un autre processus par l'intermédiaire d'un
497 tube de communication (pipe). Cette fonctionnalité améliore
498 considérablement la souplesse de la journalisation, sans ajouter de code
499 au serveur principal. Pour rediriger les informations de journalisation
500 vers un tube de communication, remplacez simplement le nom de fichier
502 le caractère pipe "<code>|</code>", suivi du nom de l'exécutable qui va
503 recueillir les entrées de journal sur son entrée standard. Apache va
504 lancer le processus de redirection des journaux au moment du démarrage du
505 serveur, et le relancera s'il cesse de fonctionner
506 pendant l'exécution du serveur.
507 (Nous dénommons cette technique "journalisation
508 redirigée fiable" grâce à cette dernière fonctionnalité.)</p>
510 <p>Les processus de journalisation redirigée sont lancés par le processus
511 httpd parent, et héritent de l'UID de ce dernier. Cela signifie que les
512 programmes de journalisation dirigée s'exécutent généralement en tant que
513 root. Il est donc très important que ces programmes soient simples et
514 sécurisés.</p>
516 <p>Un des grands avantages de la journalisation redirigée est la possibilité
517 d'effectuer la rotation des journaux sans avoir à redémarrer le serveur. Pour
518 accomplir cette tâche, le serveur HTTP Apache fournit un programme simple
519 appelé <program>rotatelogs</program>. Par exemple, pour une rotation des
520 journaux toutes les 24 heures, ajoutez ces lignes :</p>
523 CustomLog "|/usr/local/apache/bin/rotatelogs
524 /var/log/access_log 86400" common
527 <p>Notez que l'ensemble de la commande qui sera appelée par le tube de
528 communication a été placée entre guillemets. Bien que cet exemple
529 concerne le journal des accès, la même technique peut être utilisée
530 pour le journal des erreurs.</p>
532 <p>Il existe un autre programme de rotation des journaux similaire mais
533 beaucoup plus souple : il s'agit de "cronolog", non fourni par Apache,
534 mais disponible <a href="http://www.cronolog.org/">ici</a>.</p>
536 <p>Comme la journalisation conditionnelle, la journalisation redirigée est
537 un outil très puissant, mais si elle existe, il est préférable d'utiliser
538 une solution plus simple comme le traitement à posteriori hors ligne.</p>
541 <section id="virtualhost">
542 <title>Hôtes virtuels</title>
544 <p>Lorsqu'un serveur possède plusieurs <a href
545 ="vhosts/">hôtes virtuels</a>, il existe de nombreuses solutions pour gérer
546 les fichiers journaux. Par exemple, on peut utiliser les journaux comme
547 s'il s'agissait d'un serveur avec un seul hôte. Il suffit pour cela de
548 placer les directives de journalisation en dehors des sections
549 <directive module="core" type="section">VirtualHost</directive> au niveau
550 du serveur principal, ce qui a pour effet de journaliser toutes les
551 requêtes dans le même journal des accès et des erreurs. Cette technique
552 est cependant inappropriée pour recueillir des statistiques sur chaque
553 hôte virtuel individuellement.</p>
555 <p>Si des directives <directive module=
556 "mod_log_config">CustomLog</directive> ou
557 <directive module="core">ErrorLog</directive> sont placées dans une section
558 <directive module="core" type="section">VirtualHost</directive>, toutes les
559 requêtes ou erreurs pour cet hôte virtuel ne seront enregistrées que dans
560 le fichier spécifié. Tout hôte virtuel qui ne possède pas de directives de
561 journalisation verra ses requêtes enregistrées dans le journal du serveur
562 principal. Cette technique est appropriée pour un petit nombre d'hôtes
563 virtuels, mais si ce nombre est important, elle peut devenir compliquée à
564 gérer. En outre, des problèmes de <a
565 href="vhosts/fd-limits.html">nombre de descripteurs
566 de fichiers insuffisant</a> peuvent rapidement apparaître.</p>
568 <p>Il existe un très bon compromis pour le journal des accès. En intégrant
569 les informations à propos de l'hôte virtuel à la chaîne de format du
570 journal, il est possible de journaliser tous les hôtes dans le même
571 journal, puis de séparer ultérieurement le journal en plusieurs journaux
572 individuels. Considérons par exemple les directives suivantes :</p>
575 LogFormat "%v %l %u %t \"%r\" %>s %b"
577 CustomLog logs/access_log comonvhost
580 <p>Le champ <code>%v</code> sert à enregistrer le nom de l'hôte virtuel qui
581 traite la requête. Un programme tel que <a
582 href="programs/other.html">split-logfile</a> peut ensuite être utilisé
583 pour générer "à froid" autant de journaux que d'hôtes virtuels.</p>
587 <title>Autres fichiers journaux</title>
591 <module>mod_logio</module>
592 <module>mod_log_forensic</module>
593 <module>mod_cgi</module>
594 <module>mod_rewrite</module>
597 <directive module="mod_log_config">LogFormat</directive>
598 <directive module="mod_log_forensic">ForensicLog</directive>
599 <directive module="mpm_common">PidFile</directive>
600 <directive module="mod_rewrite">RewriteLog</directive>
601 <directive module="mod_rewrite">RewriteLogLevel</directive>
602 <directive module="mod_cgi">ScriptLog</directive>
603 <directive module="mod_cgi">ScriptLogBuffer</directive>
604 <directive module="mod_cgi">ScriptLogLength</directive>
609 <title>Enregistrement du nombre réel d'octets envoyés et reçus</title>
611 <p>Le module <module>mod_logio</module> fournit deux champs
612 <directive module="mod_log_config">LogFormat</directive> supplémentaires
613 (%I et %O) qui permettent d'enregistrer le nombre réel d'octets reçus et
614 envoyés sur le réseau.</p>
618 <title>Journalisation de style investigation judiciaire (forensic logging)</title>
620 <p>Le module <module>mod_log_forensic</module> permet la journalisation
621 à des fins d'investigation judiciaire des requêtes des clients. La
622 journalisation est effectuée avant et après le traitement de la requête,
623 qui fait donc l'objet de deux entrées dans le journal. Le générateur de
624 journaux d'investigation est très strict et ne permet aucune
625 personnalisation. C'est un inestimable outil de débogage et de sécurité.</p>
628 <section id="pidfile">
629 <title>Fichier PID</title>
631 <p>Au démarrage, le démon httpd Apache enregistre l'identifiant du
632 processus httpd parent dans le fichier <code>logs/httpd.pid</code>.
633 Le nom de ce fichier peut être modifié à l'aide de la directive
634 <directive module="mpm_common">PidFile</directive>. Cet identifiant
635 permet à l'administrateur de redémarrer et arrêter le démon en
636 envoyant des signaux au processus parent ; sous Windows, vous devez
637 utiliser l'option de ligne de commande -k. Pour plus de détails,
638 consulter la page <a href="stopping.html">Arrêt et redémarrage</a>.</p>
641 <section id="scriptlog">
642 <title>Journal des scripts</title>
644 <p>Afin de faciliter le débogage, la directive
645 <directive module="mod_cgi">ScriptLog</directive> vous permet
646 d'enregistrer les entrées et sorties des scripts CGI. Elle ne doit être
647 utilisée que pendant la phase de test, et en aucun cas sur un
648 serveur en production. Vous trouverez plus d'informations dans la
649 documentation du module <a href="mod/mod_cgi.html">mod_cgi</a>.</p>
652 <section id="rewritelog">
653 <title>Journal de réécriture</title>
655 <p>Lorsqu'on utilise les fonctionnalités puissantes et complexes du
656 module <a href="mod/mod_rewrite.html">mod_rewrite</a>, il est presque
657 toujours nécessaire d'utiliser la directive
658 <directive module="mod_rewrite">RewriteLog</directive> afin de
659 faciliter le débogage. Ce fichier journal fournit une analyse détaillée
660 de la transformation des requêtes par le moteur de réécriture. Le niveau
661 de détail est contrôlé par la directive
662 <directive module="mod_rewrite">RewriteLogLevel</directive>.</p>
projects / apache / blob