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 : 1330883 -->
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="overview">
40 <title>Vue d'ensemble</title>
44 <module>mod_log_config</module>
45 <module>mod_log_forensic</module>
46 <module>mod_logio</module>
47 <module>mod_cgi</module>
52 Le serveur HTTP Apache fournit toute une variété de mécanismes
53 différents pour la journalisation de tout ce qui peut se passer au
54 sein de votre serveur, depuis la requête initiale, en passant par le
55 processus de mise en correspondance des URLs, et jusqu'à la fermeture
56 de la connexion, y compris toute erreur pouvant survenir au cours du
57 traitement. De plus, certains modules tiers fournissent des
58 fonctionnalités de journalisation ou insèrent des entrées dans les
59 fichiers journaux existants, et les applications comme les programmes
60 CGI, les scripts PHP ou autres gestionnaires peuvent envoyer des
61 messages vers le journal des erreurs du serveur.
65 Ce document décrit le fonctionnement des modules de journalisation
66 fournis en standard avec le serveur httpd.
71 <section id="security">
72 <title>Avertissement à propos de la sécurité</title>
74 <p>Tout utilisateur qui a les droits en écriture sur le répertoire dans
75 lequel Apache httpd écrit ses journaux pourra quasi
76 certainement avoir accès à l'uid sous lequel le serveur est démarré, en
77 l'occurrence habituellement root. N'accordez <em>PAS</em> aux utilisateurs
78 l'accès en écriture au répertoire dans lequel les journaux sont stockés
79 sans savoir exactement quelles en seraient les conséquences ; voir le
80 document <a href="misc/security_tips.html">conseils sur la sécurité</a>
81 pour plus de détails.</p>
83 <p>En outre, les journaux peuvent contenir des informations fournies
84 directement par un client, sans caractères d'échappement. Des clients mal
85 intentionnés peuvent donc insérer des caractères de contrôle dans les
86 journaux, et il convient par conséquent d'être très prudent lors de la
87 manipulation des journaux bruts.</p>
90 <section id="errorlog">
91 <title>Journal des erreurs</title>
98 <directive module="core">ErrorLog</directive>
99 <directive module="core">LogLevel</directive>
103 <p>Le journal des erreurs du serveur, dont le nom et la localisation sont
104 définis par la directive <directive module="core">ErrorLog</directive>,
105 est le journal le plus important. C'est dans celui-ci
106 que le démon Apache httpd va envoyer les informations de diagnostic et
107 enregistrer toutes les erreurs qui surviennent lors du traitement des
108 requêtes. Lorsqu'un problème survient au démarrage du serveur ou pendant
109 son fonctionnement, la première chose à faire est de regarder dans ce
110 journal, car il vous renseignera souvent sur le problème rencontré et
111 la manière d'y remédier.</p>
113 <p>Le journal des erreurs est habituellement enregistré dans un fichier
114 (en général <code>error_log</code> sur les systèmes de type Unix et
115 <code>error.log</code> sur Windows et OS/2). Sur les systèmes de type Unix,
116 le serveur peut aussi enregistrer ses erreurs dans
117 <code>syslog</code> ou les
118 <a href="#piped">rediriger vers un programme</a> par l'intermédiaire d'un
119 tube de communication (pipe).</p>
121 <p>Le format par défaut du journal des erreurs est descriptif et de forme
122 relativement libre. Certaines informations apparaissent cependant dans la
123 plupart des entrées du journal. Voici un message typique
124 à titre d'exemple : </p>
127 [Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1]
128 client denied by server configuration:
129 /export/home/live/ap/htdocs/test
132 <p>Le premier champ de l'entrée du journal est la date et l'heure du
133 message. Le second champ indique la sévérité de l'erreur rapportée. La
134 directive <directive module="core">LogLevel</directive> permet de
135 restreindre le type des erreurs qui doivent être enregistrées
136 dans le journal des erreurs en définissant leur niveau de sévérité. Le
137 troisième champ contient l'adresse IP du client qui a généré l'erreur.
138 Vient ensuite le message proprement dit, qui indique dans ce cas que le
139 serveur a été configuré pour interdire l'accès au client. Le serveur
140 indique le chemin système du document requis (et non
143 <p>Une grande variété de messages différents peuvent apparaître dans le
144 journal des erreurs. La plupart d'entre eux sont similaires à l'exemple
145 ci-dessus. Le journal des erreurs peut aussi contenir des informations de
146 débogage en provenance de scripts CGI. Toute information qu'un script CGI
147 écrit sur la sortie d'erreurs standard <code>stderr</code> sera recopiée
148 telle quelle dans le journal des erreurs.</p>
150 <p>La directive <directive module="core">ErrorLogFormat</directive>
151 vous permet de personnaliser le format du journal des erreurs, et de
152 définir les informations à journaliser. Si
153 <module>mod_unique_id</module> est présent, vous pouvez utiliser le
154 drapeau <code>%L</code> à la fois dans le journal des erreurs et
156 journal des accès, ce qui aura pour effet de générer un identifiant
157 d'entrée qui vous permettra de corréler les entrées du journal des
158 erreurs avec celles du journal des accès.</p>
160 <p>Pendant la phase de test, il est souvent utile de visualiser en continu
161 le journal des erreurs afin de détecter tout problème éventuel. Sur les
162 systèmes de type Unix, ceci s'effectue à l'aide de la commande :</p>
169 <section id="permodule">
170 <title>Journalisation par module</title>
172 <p>La directive <directive module="core">LogLevel</directive> permet
173 de spécifier un niveau de sévérité de journalisation pour chaque
174 module. Vous pouvez ainsi résoudre un problème propre à un module particulier
175 en augmentant son volume de journalisation sans augmenter ce volume
176 pour les autres modules. Ceci est particulièrement utile lorsque
177 vous voulez obtenir des détails sur le fonctionnement de modules
178 comme <module>mod_proxy</module> ou <module>mod_rewrite</module>.</p>
180 <p>Pour ce faire, vous devez spécifier le nom du module dans votre
181 directive <directive>LogLevel</directive> :</p>
183 <highlight language="config">
184 LogLevel info rewrite:trace5
187 <p>Dans cet exemple, le niveau de journalisation général est défini
188 à info, et à <code>trace5</code> pour <module>mod_rewrite</module>.</p>
190 <note>Cette directive remplace les directives de journalisation par
191 module des versions précédentes du serveur, comme
192 <code>RewriteLog</code>.</note>
196 <section id="accesslog">
197 <title>Journal des accès</title>
201 <module>mod_log_config</module>
202 <module>mod_setenvif</module>
205 <directive module="mod_log_config">CustomLog</directive>
206 <directive module="mod_log_config">LogFormat</directive>
207 <directive module="mod_setenvif">SetEnvIf</directive>
211 <p>Le journal des accès au serveur
212 enregistre toutes les requêtes que traite
213 ce dernier. La localisation et le contenu du journal des accès sont définis
214 par la directive <directive module="mod_log_config">CustomLog</directive>.
215 La directive <directive module="mod_log_config">LogFormat</directive>
216 permet de simplifier la sélection du contenu du journal. Cette section
217 décrit comment configurer le serveur pour l'enregistrement des informations
218 dans le journal des accès.</p>
220 <p>Bien évidemment, le stockage d'informations dans le journal des accès
221 n'est que le point de départ de la gestion de la journalisation. L'étape
222 suivante consiste à analyser ces informations de façon à pouvoir en
223 extraire des statistiques utiles. L'analyse de journaux en général est en
224 dehors du sujet de ce document et ne fait pas vraiment partie intégrante
225 du travail du serveur web lui-même. Pour plus d'informations à propos de ce
226 sujet et des applications dédiées à l'analyse de journaux, vous pouvez vous
227 référer à <a href="http://dmoz.org/Computers/Software/Internet/
228 Site_Management/Log_analysis/">Open Directory</a> ou
229 <a href="http://dir.yahoo.com/Computers_and_Internet/Software/
230 Internet/World_Wide_Web/Servers/Log_Analysis_Tools/">Yahoo</a>.</p>
232 <p>Différentes versions du démon Apache httpd utilisaient d'autres modules
233 et directives pour contrôler la journalisation des accès, à l'instar de
234 mod_log_referer, mod_log_agent, et de la directive
235 <code>TransferLog</code>. La directive
236 <directive module="mod_log_config">CustomLog</directive> rassemble
237 désormais les fonctionnalités de toutes les anciennes directives.</p>
239 <p>Le format du journal des accès est hautement configurable. Il est
240 défini à l'aide d'une chaîne de format qui ressemble sensiblement à la
241 chaîne de format de style langage C de printf(1). Vous trouverez quelques
242 exemples dans les sections suivantes. Pour une liste exhaustive de ce que
243 peut contenir une chaîne de format, vous pouvez vous référer au chapitre
244 <a href="mod/mod_log_config.html#formats">chaînes de format</a> de la
245 documentation du module <module>mod_log_config</module>.</p>
247 <section id="common">
248 <title>Format habituel du journal</title>
250 <p>Voici une configuration typique pour le journal des accès :</p>
252 <highlight language="config">
253 LogFormat "%h %l %u %t \"%r\" %>s %b" common
254 CustomLog logs/access_log common
257 <p>Ici est définie l'<em>identité</em> <code>common</code> qui est
258 ensuite associée à une chaîne de format de journalisation particulière.
259 La chaîne de format est constituée de directives débutant par le
260 caractère %, chacune d'entre elles indiquant au serveur d'enregistrer
261 un élément particulier d'information. Des caractères littéraux peuvent
262 aussi être insérés dans la chaîne de format ; il seront copiés tels
263 quels dans le flux de sortie destiné à la journalisation.
264 Les guillemets (<code>"</code>) doivent être échappées en les faisant
265 précéder d'un anti-slash (<code>\</code>) afin qu'elles ne soient pas
266 interprétées comme la fin de la chaîne de format. La chaîne de format
267 peut aussi contenir les caractères de contrôle spéciaux
268 "<code>\n</code>" et "<code>\t</code>" pour insérer respectivement
269 un passage à la ligne et une tabulation.</p>
271 <p>La directive <directive module="mod_log_config">CustomLog</directive>
272 définit un nouveau fichier journal en l'associant à l'identité
273 précédemment définie. Le chemin du nom de fichier associé au journal
274 des accès est relatif au chemin défini par la directive
275 <directive module="core">ServerRoot</directive>, sauf s'il
276 débute par un slash.</p>
278 <p>La configuration ci-dessus va enregistrer les entrées de
279 journalisation selon un format connu sous le nom de
280 Common Log Format (CLF) pour "Format de journalisation standard".
281 Ce format standard peut être produit par de nombreux serveurs web
282 différents et lu par de nombreux programmes d'analyse de journaux.
283 Les entrées de fichier journal générées selon le format CLF
284 ressemblent à ceci :</p>
287 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
288 /apache_pb.gif HTTP/1.0" 200 2326
291 <p>Chaque partie de cette entrée de journal est décrite
292 dans ce qui suit.</p>
295 <dt><code>127.0.0.1</code> (<code>%h</code>)</dt>
297 <dd>Il s'agit de l'adresse IP du client (l'hôte distant) qui a envoyé
298 la requête au serveur. Si la directive
299 <directive module="core">HostnameLookups</directive> est positionnée à
300 <code>On</code>, le serveur va essayer de déterminer le nom de l'hôte
301 et de l'enregistrer à la place de l'adresse IP. Cette configuration
302 n'est cependant pas recommandée car elle peut ralentir le serveur de
303 manière significative. Il est par conséquent préférable d'utiliser un
304 processeur d'analyse de journaux a posteriori
305 tel que <program>logresolve</program>
306 pour déterminer les noms d'hôte. L'adresse IP indiquée ici n'est pas
307 nécessairement l'adresse IP de la machine devant laquelle se trouve
308 l'utilisateur. Si un serveur mandataire s'intercale entre le serveur
309 et l'utilisateur, l'adresse indiquée sera celle du mandataire et non
310 celle de la machine à l'origine de la requête.</dd>
312 <dt><code>-</code> (<code>%l</code>)</dt>
314 <dd>Le "trait d'union" indique que la portion d'information
315 correspondante n'est pas disponible. Dans le cas présent, l'information
316 non disponible est l'identité (RFC 1413) du client telle que déterminée
317 par <code>identd</code> sur la machine cliente. Cette information est
318 très peu fiable et ne devrait jamais être utilisée, sauf dans le cas
319 de réseaux internes étroitement contrôlés. Le démon httpd ne cherchera
320 d'ailleurs à obtenir cette information que si la directive
321 <directive module="mod_ident">IdentityCheck</directive> est positionnée
322 à <code>On</code>.</dd>
324 <dt><code>frank</code> (<code>%u</code>)</dt>
326 <dd>Il s'agit de l'identifiant utilisateur de la personne qui a
327 demandé le document, issu d'une authentification HTTP.
328 Ce même identifiant est en général fourni aux scripts CGI par
329 l'intermédiaire de la valeur de la variable d'environnement
330 <code>REMOTE_USER</code>. Si le statut de la requête (voir plus loin)
331 est 401, cette identifiant n'est pas fiable car l'utilisateur n'est
332 pas encore authentifié. Si le document n'est pas protégé par
333 mot de passe, cette partie d'information sera représentée par
334 "<code>-</code>", comme la partie précédente.</dd>
336 <dt><code>[10/Oct/2000:13:55:36 -0700]</code>
337 (<code>%t</code>)</dt>
340 L'heure à laquelle la requête a été reçue.
341 Le format est le suivant :
344 <code>[jour/mois/année:heure:minutes:secondes zone]<br />
345 jour = 2*chiffre<br />
346 mois = 3*lettre<br />
347 année = 4*chiffre<br />
348 heure = 2*chiffre<br />
349 minutes = 2*chiffre<br />
350 secondes = 2*chiffre<br />
351 zone = (`+' | `-') 4*chiffre</code>
352 </p>Il est possible de modifier le format d'affichage de l'heure
353 en spécifiant <code>%{format}t</code> dans la chaîne de format du
354 journal, où <code>format</code> est une chaîne de format
355 de la forme de celle de la fonction <code>strftime(3)</code>
356 de la bibliothèque C standard, ou choisie parmi les
357 formats spéciaux supportés. Pour plus de détails,
358 reportez-vous aux. <a
359 href="mod/mod_log_config.html#formats">chaînes de format</a>
360 de <module>mod_log_config</module>.
363 <dt><code>"GET /apache_pb.gif HTTP/1.0"</code>
364 (<code>\"%r\"</code>)</dt>
366 <dd>La ligne de la requête du client est placée entre guillemets.
367 Elle contient de nombreuses informations utiles. Tout d'abord, la
368 méthode utilisée par le client est <code>GET</code>. Ensuite, le
369 client a demandé la ressource <code>/apache_pb.gif</code>, et enfin,
370 le client a utilisé le protocole <code>HTTP/1.0</code>. Il est aussi
371 possible d'enregistrer séparément une ou plusieurs parties de la
372 requête. Par exemple, la chaîne de format "<code>%m %U %q %H</code>"
373 va enregistrer la méthode, le chemin, la chaîne de la requête et le
374 protocole, ce qui donnera le même résultat que
375 "<code>%r</code>".</dd>
377 <dt><code>200</code> (<code>%>s</code>)</dt>
379 <dd>C'est le code de statut que le serveur retourne au client. Cette
380 information est très importante car elle indique si la requête a fait
381 l'objet d'une réponse positive (codes commençant par 2), une
382 redirection (codes commençant par 3), une erreur due au client (codes
383 commençant par 4), ou une erreur due au serveur (codes commençant
384 par 5). Vous trouverez la liste complète des codes de statut possibles
385 dans la <a href="http://www.w3.org/Protocols/rfc2616/
386 rfc2616.txt">specification HTTP</a> (RFC2616 section 10).</dd>
388 <dt><code>2326</code> (<code>%b</code>)</dt>
390 <dd>La dernière partie indique la taille de l'objet retourné au client,
391 en-têtes non compris. Si aucun contenu n'a été retourné au client, cette
392 partie contiendra "<code>-</code>". Pour indiquer l'absence de contenu
393 par "<code>0</code>", utilisez <code>%B</code> au lieu de
394 <code>%b</code>.</dd>
398 <section id="combined">
399 <title>Combined Log Format (Format de journalisation combiné)</title>
401 <p>Une autre chaîne de format couramment utilisée est le
402 "Combined Log Format" (Format de journalisation combiné). Il s'utilise
405 <highlight language="config">
406 LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
407 CustomLog log/access_log combined
410 <p>Ce format est identique au Common Log Format, avec deux champs
411 supplémentaires. Chacun de ces deux champs utilise la directive
412 commençant par le caractère "%" <code>%{<em>header</em>}i</code>,
413 où <em>header</em> peut être n'importe quel en-tête de requête HTTP.
414 Avec ce format, le journal des accès se présentera comme suit :</p>
417 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
418 /apache_pb.gif HTTP/1.0" 200 2326
419 "http://www.example.com/start.html" "Mozilla/4.08 [en]
423 <p>Les champs supplémentaires sont :</p>
426 <dt><code>"http://www.example.com/start.html"</code>
427 (<code>\"%{Referer}i\"</code>)</dt>
429 <dd>L'en-tête "Referer" (sic) de la requête HTTP. Il indique le site
430 depuis lequel le client prétend avoir lancé sa requête. (Ce doit être
431 la page qui contient un lien vers <code>/apache_pb.gif</code> ou
432 inclut ce dernier fichier).</dd>
434 <dt><code>"Mozilla/4.08 [en] (Win98; I ;Nav)"</code>
435 (<code>\"%{User-agent}i\"</code>)</dt>
437 <dd>L'en-tête User-Agent de la requête HTTP. C'est une information
438 d'identification que le navigateur du client envoie à propos
439 de lui-même.</dd>
443 <section id="multiple">
444 <title>Journaux d'accès multiples</title>
446 <p>Plusieurs journaux d'accès peuvent être créés en spécifiant tout
447 simplement plusieurs directives
448 <directive module="mod_log_config">CustomLog</directive> dans le
449 fichier de configuration. Par exemple, les directives suivantes vont
450 créer trois journaux d'accès. Le premier contiendra les informations
451 de base CLF, le second les informations du Referer, et le troisième
452 les informations sur le navigateur. Les deux dernières directives
453 <directive module="mod_log_config">CustomLog</directive> montrent
454 comment simuler les effets des directives <code>ReferLog</code> et
455 <code>AgentLog</code>.</p>
457 <highlight language="config">
458 LogFormat "%h %l %u %t \"%r\" %>s %b" common
459 CustomLog logs/access_log common
460 CustomLog logs/referer_log "%{Referer}i -> %U"
461 CustomLog logs/agent_log "%{User-agent}i"
464 <p>Cet exemple montre aussi qu'il n'est pas obligatoire d'associer
465 une chaîne de format à un alias au moyen de la directive
466 <directive module="mod_log_config">LogFormat</directive>. Elle peut
467 être définie directement dans la ligne de la directive
468 <directive module="mod_log_config">CustomLog</directive>.</p>
471 <section id="conditional">
472 <title>Journalisation conditionnelle</title>
474 <p>Il est parfois souhaitable d'exclure certaines entrées des journaux
475 d'accès en fonction des caractéristiques de la requête du client. On
476 peut aisément accomplir ceci à l'aide des
477 <a href="env.html">variables d'environnement</a>. Tout d'abord, une
478 variable d'environnement doit être définie pour indiquer que la
479 requête remplit certaines conditions. Pour ceci, on utilise en général
480 la directive <directive module="mod_setenvif">SetEnvIf</directive>,
481 puis la clause <code>env=</code> de la directive
482 <directive module="mod_log_config">CustomLog</directive> pour inclure
483 ou exclure les requêtes pour lesquelles
484 la variable d'environnement est définie.
485 Quelques exemples :</p>
487 <highlight language="config">
488 # Marque les requêtes en provenance de l'interface loop-back
489 SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog
490 # Marque les requêtes pour le fichier robots.txt
491 SetEnvIf Request_URI "^/robots\.txt$" dontlog
492 # Journalise toutes les autres requêtes
493 CustomLog logs/access_log common env=!dontlog
496 <p>Autre exemple, imaginons l'enregistrement des requêtes en provenance
497 d'utilisateurs de langue anglaise dans un journal, et celles des autres
498 utilisateurs dans un autre journal.</p>
500 <highlight language="config">
501 SetEnvIf Accept-Language "en" english<br />
502 CustomLog logs/english_log common env=english<br />
503 CustomLog logs/non_english_log common env=!english
506 <p>Dans le contexte d'une mise en cache, il peut être
507 intéressant de connaître l'efficacité du cache. Pour y parvenir,
508 on pourrait utiliser cette méthode simple :</p>
510 <highlight language="config">
512 LogFormat "%h %l %u %t "%r " %>s %b %{CACHE_MISS}e" common-cache
513 CustomLog logs/access_log common-cache
516 <p><module>mod_cache</module> va s'exécuter avant
517 <module>mod_env</module>, et si son action est couronnée de
518 succès, il délivrera le contenu sans faire appel à ce dernier. Si
519 l'URL se trouve dans le cache, la valeur journalisée sera alors
520 <code>-</code>, tandis que dans le cas contraire elle sera
523 <p>En plus de la syntaxe <code>env=</code>, la directive <directive
524 module="mod_log_config">LogFormat</directive> supporte les
525 valeurs de journalisation conditionnelles basées sur le code de la
526 réponse HTTP :</p>
528 <highlight language="config">
529 LogFormat "%400,501{User-agent}i" browserlog
530 LogFormat "%!200,304,302{Referer}i" refererlog
533 <p>Dans le premier exemple, le <code>User-agent</code> sera
534 enregistré si le code d'état HTTP est 400 ou 501. Dans le cas
535 contraire, c'est un caractère "-" qui sera enregistré à la place.
536 Dans le second exemple, le <code>Referer</code> sera enregistré si
537 le code d'état HTTP n'est <strong>pas</strong> 200, 204, ou 302
538 (remarquez le caractère "!" avant les codes d'état).</p>
540 <p>Bien que nous venions de montrer que la journalisation conditionnelle
541 est souple et très puissante, cette méthode de contrôle du contenu des
542 journaux n'est pas la seule. Les fichiers journaux sont plus utiles
543 quand ils contiennent un enregistrement complet de l'activité du serveur,
544 et il est souvent plus aisé de simplement traiter à posteriori les fichiers
545 journaux pour supprimer les requêtes que vous ne voulez pas y voir
546 apparaître.</p>
550 <section id="rotation">
551 <title>Rotation des journaux</title>
553 <p>Même dans le cas d'un serveur modérément sollicité, la quantité
554 d'informations stockées dans les fichiers journaux est très importante.
555 Le fichier journal des accès grossit en général d'1 Mo ou plus toutes
556 les 10000 requêtes. Il est par conséquent nécessaire d'effectuer
557 périodiquement la rotation des journaux en déplaçant ou supprimant les
558 fichiers correspondants. On ne peut pas le faire pendant que le serveur
559 est en cours d'exécution, car Apache httpd va continuer à écrire dans l'ancien
560 fichier journal aussi longtemps qu'il le maintiendra ouvert.
561 C'est pourquoi le serveur doit être
562 <a href="stopping.html">redémarré</a> après le déplacement ou la
563 suppression des fichiers journaux de façon à ce qu'il en ouvre
566 <p>Avec un redémarrage <em>graceful</em>, on peut faire en sorte que le
567 serveur ouvre de nouveaux fichiers journaux sans perdre de connexions
568 existantes ou en cours avec les clients. Cependant, pour que ceci soit
569 possible, le serveur doit continuer à écrire dans les anciens fichiers
570 journaux pendant qu'il termine le traitement des requêtes en cours.
571 Il est donc nécessaire d'attendre un certain temps après le rédémarrage
572 avant d'effectuer tout traitement sur les fichiers journaux. Voici un
573 scénario typique dans lequel on effectue une simple rotation des
574 journaux en compressant les anciens fichiers correspondants afin
575 de gagner de l'espace disque :</p>
578 mv access_log access_log.old<br />
579 mv error_log error_log.old<br />
580 apachectl graceful<br />
582 gzip access_log.old error_log.old
585 <p>La section suivante présente une autre méthode de rotation des journaux
586 qui consiste à utiliser les
587 <a href="#piped">journaux redirigés</a>.</p>
591 <title>Journaux redirigés</title>
593 <p>Nous avons vu que le démon httpd écrivait les informations de
594 journalisation des erreurs et des accès dans un fichier journal ;
596 rediriger ces informations vers un autre processus par l'intermédiaire d'un
597 tube de communication (pipe). Cette fonctionnalité améliore
598 considérablement la souplesse de la journalisation, sans ajouter de code
599 au serveur principal. Pour rediriger les informations de journalisation
600 vers un tube de communication, remplacez simplement le nom de fichier
602 le caractère pipe "<code>|</code>", suivi du nom de l'exécutable qui va
603 recueillir les entrées de journal sur son entrée
604 standard. Le serveur va
605 lancer le processus de redirection des journaux au moment du démarrage du
606 serveur, et le relancera s'il cesse de fonctionner
607 pendant l'exécution du serveur.
608 (Nous dénommons cette technique "journalisation
609 redirigée fiable" grâce à cette dernière fonctionnalité.)</p>
611 <p>Les processus de journalisation redirigée sont lancés par le processus
612 httpd parent, et héritent de l'UID de ce dernier. Cela signifie que les
613 programmes de journalisation dirigée s'exécutent généralement en tant que
614 root. Il est donc très important que ces programmes soient simples et
615 sécurisés.</p>
617 <p>Un des grands avantages de la journalisation redirigée est la possibilité
618 d'effectuer la rotation des journaux sans avoir à redémarrer le serveur. Pour
619 accomplir cette tâche, le serveur HTTP Apache fournit un programme simple
620 appelé <program>rotatelogs</program>. Par exemple, pour une rotation des
621 journaux toutes les 24 heures, ajoutez ces lignes :</p>
623 <highlight language="config">
624 CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" common
627 <p>Notez que l'ensemble de la commande qui sera appelée par le tube de
628 communication a été placée entre guillemets. Bien que cet exemple
629 concerne le journal des accès, la même technique peut être utilisée
630 pour le journal des erreurs.</p>
632 <p>Il existe un autre programme de rotation des journaux similaire mais
633 beaucoup plus souple : il s'agit de "cronolog", non fourni par Apache,
634 mais disponible <a href="http://www.cronolog.org/">ici</a>.</p>
636 <p>Comme la journalisation conditionnelle, la journalisation redirigée est
637 un outil très puissant, mais si elle existe, il est préférable d'utiliser
638 une solution plus simple comme le traitement à posteriori hors ligne.</p>
641 <p>Par défaut, le processus de redirection du journal est lancé sans
642 invoquer un shell. Pour invoquer un shell, utilisez "<code>|$</code>"
643 au lieu de "<code>|</code>" (en général avec <code>/bin/sh -c</code>)
646 <highlight language="config">
647 # Invocation de "rotatelogs" en utilisant un shell
648 CustomLog "|$/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" common
652 <p>Il s'agissait du comportement par défaut sous Apache 2.2. Selon
653 les spécificités du shell, ceci peut générer un processus shell
654 supplémentaire pour toute la durée du programme de redirection du
655 journal, et induire des problèmes de gestion de signaux au cours du
656 redémarrage. La notation "<code>||</code>" est aussi supportée pour
657 des raisons de compatibilité avec Apache 2.2 et est équivalente à
658 "<code>|</code>".</p>
661 <section id="virtualhost">
662 <title>Hôtes virtuels</title>
664 <p>Lorsqu'un serveur possède plusieurs <a href
665 ="vhosts/">hôtes virtuels</a>, il existe de nombreuses solutions pour gérer
666 les fichiers journaux. Par exemple, on peut utiliser les journaux comme
667 s'il s'agissait d'un serveur avec un seul hôte. Il suffit pour cela de
668 placer les directives de journalisation en dehors des sections
669 <directive module="core" type="section">VirtualHost</directive> au niveau
670 du serveur principal, ce qui a pour effet de journaliser toutes les
671 requêtes dans le même journal des accès et des erreurs. Cette technique
672 est cependant inappropriée pour recueillir des statistiques sur chaque
673 hôte virtuel individuellement.</p>
675 <p>Si des directives <directive module=
676 "mod_log_config">CustomLog</directive> ou
677 <directive module="core">ErrorLog</directive> sont placées dans une section
678 <directive module="core" type="section">VirtualHost</directive>, toutes les
679 requêtes ou erreurs pour cet hôte virtuel ne seront enregistrées que dans
680 le fichier spécifié. Tout hôte virtuel qui ne possède pas de directives de
681 journalisation verra ses requêtes enregistrées dans le journal du serveur
682 principal. Cette technique est appropriée pour un petit nombre d'hôtes
683 virtuels, mais si ce nombre est important, elle peut devenir compliquée à
684 gérer. En outre, des problèmes de <a
685 href="vhosts/fd-limits.html">nombre de descripteurs
686 de fichiers insuffisant</a> peuvent rapidement apparaître.</p>
688 <p>Il existe un très bon compromis pour le journal des accès. En intégrant
689 les informations à propos de l'hôte virtuel à la chaîne de format du
690 journal, il est possible de journaliser tous les hôtes dans le même
691 journal, puis de séparer ultérieurement le journal en plusieurs journaux
692 individuels. Considérons par exemple les directives suivantes :</p>
694 <highlight language="config">
695 LogFormat "%v %l %u %t \"%r\" %>s %b" comonvhost
696 CustomLog logs/access_log comonvhost
699 <p>Le champ <code>%v</code> sert à enregistrer le nom de l'hôte virtuel qui
700 traite la requête. Un programme tel que <a
701 href="programs/other.html">split-logfile</a> peut ensuite être utilisé
702 pour générer "à froid" autant de journaux que d'hôtes virtuels.</p>
706 <title>Autres fichiers journaux</title>
710 <module>mod_logio</module>
711 <module>mod_log_config</module>
712 <module>mod_log_forensic</module>
713 <module>mod_cgi</module>
716 <directive module="mod_log_config">LogFormat</directive>
717 <directive module="mod_log_config">BufferedLogs</directive>
718 <directive module="mod_log_forensic">ForensicLog</directive>
719 <directive module="mpm_common">PidFile</directive>
720 <directive module="mod_cgi">ScriptLog</directive>
721 <directive module="mod_cgi">ScriptLogBuffer</directive>
722 <directive module="mod_cgi">ScriptLogLength</directive>
727 <title>Enregistrement du nombre réel d'octets envoyés et reçus</title>
729 <p>Le module <module>mod_logio</module> fournit deux champs
730 <directive module="mod_log_config">LogFormat</directive> supplémentaires
731 (%I et %O) qui permettent d'enregistrer le nombre réel d'octets reçus et
732 envoyés sur le réseau.</p>
736 <title>Journalisation de style investigation judiciaire (forensic logging)</title>
738 <p>Le module <module>mod_log_forensic</module> permet la journalisation
739 à des fins d'investigation judiciaire des requêtes des clients. La
740 journalisation est effectuée avant et après le traitement de la requête,
741 qui fait donc l'objet de deux entrées dans le journal. Le générateur de
742 journaux d'investigation est très strict et ne permet aucune
743 personnalisation. C'est un inestimable outil de débogage et de sécurité.</p>
746 <section id="pidfile">
747 <title>Fichier PID</title>
749 <p>Au démarrage, le démon httpd Apache enregistre l'identifiant du
750 processus httpd parent dans le fichier <code>logs/httpd.pid</code>.
751 Le nom de ce fichier peut être modifié à l'aide de la directive
752 <directive module="mpm_common">PidFile</directive>. Cet identifiant
753 permet à l'administrateur de redémarrer et arrêter le démon en
754 envoyant des signaux au processus parent ; sous Windows, vous devez
755 utiliser l'option de ligne de commande -k. Pour plus de détails,
756 consulter la page <a href="stopping.html">Arrêt et redémarrage</a>.</p>
759 <section id="scriptlog">
760 <title>Journal des scripts</title>
762 <p>Afin de faciliter le débogage, la directive
763 <directive module="mod_cgi">ScriptLog</directive> vous permet
764 d'enregistrer les entrées et sorties des scripts CGI. Elle ne doit être
765 utilisée que pendant la phase de test, et en aucun cas sur un
766 serveur en production. Vous trouverez plus d'informations dans la
767 documentation du module <a href="mod/mod_cgi.html">mod_cgi</a>.</p>
770 <section id="rewritelog">
771 <title>Journal de réécriture</title>
773 <p>Lorsqu'on utilise les fonctionnalités puissantes et complexes du
774 module <a href="mod/mod_rewrite.html">mod_rewrite</a>, il est presque
775 toujours nécessaire d'utiliser la directive
776 <directive module="mod_rewrite">RewriteLog</directive> afin de
777 faciliter le débogage. Ce fichier journal fournit une analyse détaillée
778 de la transformation des requêtes par le moteur de réécriture. Le niveau
779 de détail est contrôlé par la directive
780 <directive module="mod_rewrite">RewriteLogLevel</directive>.</p>
projects / apache / blob