| Current Path : /usr/local/apache22/share/doc/apache2/ |
FreeBSD hs32.drive.ne.jp 9.1-RELEASE FreeBSD 9.1-RELEASE #1: Wed Jan 14 12:18:08 JST 2015 root@hs32.drive.ne.jp:/sys/amd64/compile/hs32 amd64 |
| Current File : //usr/local/apache22/share/doc/apache2/logs.html.fr |
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr"><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type" />
<!--
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
This file is generated from xml source: DO NOT EDIT
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-->
<title>Fichiers journaux - Serveur Apache HTTP Version 2.2</title>
<link href="./style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
<link href="./style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
<link href="./style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /><link rel="stylesheet" type="text/css" href="./style/css/prettify.css" />
<script src="./style/scripts/prettify.min.js" type="text/javascript">
</script>
<link href="./images/favicon.ico" rel="shortcut icon" /><link href="http://httpd.apache.org/docs/current/logs.html" rel="canonical" /></head>
<body id="manual-page"><div id="page-header">
<p class="menu"><a href="./mod/">Modules</a> | <a href="./mod/directives.html">Directives</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="./glossary.html">Glossaire</a> | <a href="./sitemap.html">Plan du site</a></p>
<p class="apache">Serveur Apache HTTP Version 2.2</p>
<img alt="" src="./images/feather.gif" /></div>
<div class="up"><a href="./"><img title="<-" alt="<-" src="./images/left.gif" /></a></div>
<div id="path">
<a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">Serveur HTTP</a> > <a href="http://httpd.apache.org/docs/">Documentation</a> > <a href="./">Version 2.2</a></div><div id="page-content"><div class="retired"><h4>A savoir</h4>
<p>Ce document concerne une version ancienne (<strong>2.2</strong>)
du serveur HTTP Apache. La version actuelle est
documentée <a href="http://httpd.apache.org/docs/current">ici</a>. Si vous n'avez
pas encore effectué la mise è jour, veuillez suivre <a href="http://httpd.apache.org/docs/current/upgrading.html">ce
lien</a> pour plus d'informations.</p>
<p>Pour consulter la version actuelle de ce
document, vous pouvez suivre <a href="http://httpd.apache.org/docs/current/logs.html">ce lien</a>.</p></div><div id="preamble"><h1>Fichiers journaux</h1>
<div class="toplang">
<p><span>Langues Disponibles: </span><a href="./en/logs.html" hreflang="en" rel="alternate" title="English"> en </a> |
<a href="./fr/logs.html" title="Français"> fr </a> |
<a href="./ja/logs.html" hreflang="ja" rel="alternate" title="Japanese"> ja </a> |
<a href="./ko/logs.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> |
<a href="./tr/logs.html" hreflang="tr" rel="alternate" title="Türkçe"> tr </a></p>
</div>
<p>Pour véritablement gérer un serveur web,
il est nécessaire de disposer d'un
retour d'informations à propos de l'activité et des performances du
serveur, ainsi que de tout problème qui pourrait survenir. Le serveur HTTP
Apache propose des fonctionnalités de journalisation souples et très
complètes. Ce document décrit comment configurer ces fonctionnalités de
journalisation et interpréter le contenu des journaux.</p>
</div>
<div id="quickview"><ul id="toc"><li><img alt="" src="./images/down.gif" /> <a href="#security">Avertissement à propos de la sécurité</a></li>
<li><img alt="" src="./images/down.gif" /> <a href="#errorlog">Journal des erreurs</a></li>
<li><img alt="" src="./images/down.gif" /> <a href="#accesslog">Journal des accès</a></li>
<li><img alt="" src="./images/down.gif" /> <a href="#rotation">Rotation des journaux</a></li>
<li><img alt="" src="./images/down.gif" /> <a href="#piped">Journaux redirigés</a></li>
<li><img alt="" src="./images/down.gif" /> <a href="#virtualhost">Hôtes virtuels</a></li>
<li><img alt="" src="./images/down.gif" /> <a href="#other">Autres fichiers journaux</a></li>
</ul><ul class="seealso"><li><a href="#comments_section">Commentaires</a></li></ul></div>
<div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="security" id="security">Avertissement à propos de la sécurité</a></h2>
<p>Tout utilisateur qui dispose de droits en écriture sur le répertoire dans
lequel Apache écrit ses journaux pourra quasi
certainement avoir accès à l'uid sous lequel le serveur est démarré, en
l'occurrence habituellement root. N'accordez <em>PAS</em> aux utilisateurs
l'accès en écriture au répertoire dans lequel les journaux sont stockés
sans savoir exactement quelles en seraient les conséquences ; voir le
document <a href="misc/security_tips.html">conseils sur la sécurité</a>
pour plus de détails.</p>
<p>En outre, les journaux peuvent contenir des informations fournies
directement par un client, sans caractères d'échappement. Des clients mal
intentionnés peuvent donc insérer des caractères de contrôle dans les
journaux, et il convient par conséquent être très prudent lors de la
manipulation des journaux bruts.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="errorlog" id="errorlog">Journal des erreurs</a></h2>
<table class="related"><tr><th>Modules Apparentés</th><th>Directives Apparentées</th></tr><tr><td /><td><ul><li><code class="directive"><a href="./mod/core.html#errorlog">ErrorLog</a></code></li><li><code class="directive"><a href="./mod/core.html#loglevel">LogLevel</a></code></li></ul></td></tr></table>
<p>Le journal des erreurs du serveur, dont le nom et la localisation sont
définis par la directive <code class="directive"><a href="./mod/core.html#errorlog">ErrorLog</a></code>,
est le journal le plus important. C'est dans celui-ci
que le démon Apache httpd va envoyer les informations de diagnostic et
enregistrer toutes les erreurs qui surviennent lors du traitement des
requêtes. Lorsqu'un problème survient au démarrage du serveur ou pendant
son fonctionnement, la première chose à faire est de regarder dans ce
journal, car il vous renseignera souvent sur le problème rencontré et
la manière d'y remédier.</p>
<p>Le journal des erreurs est habituellement enregistré dans un fichier
(en général <code>error_log</code> sur les systèmes de type Unix et
<code>error.log</code> sur Windows et OS/2). Sur les systèmes de type Unix,
le serveur peut aussi enregistrer ses erreurs dans
<code>syslog</code> ou les
<a href="#piped">rediriger vers un programme</a> par l'intermédiaire d'un
tube de communication (pipe).</p>
<p>Le format du journal des erreurs est descriptif et de forme
relativement libre. Certaines informations apparaissent cependant dans la
plupart des entrées du journal. Voici un message typique
à titre d'exemple : </p>
<div class="example"><p><code>
[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1]
client denied by server configuration:
/export/home/live/ap/htdocs/test
</code></p></div>
<p>Le premier champ de l'entrée du journal est la date et l'heure du
message. Le second champ indique la sévérité de l'erreur rapportée. La
directive <code class="directive"><a href="./mod/core.html#loglevel">LogLevel</a></code> permet de
restreindre le type des erreurs qui doivent être enregistrées
dans le journal des erreurs en définissant leur niveau de sévérité. Le
troisième champ contient l'adresse IP du client qui a généré l'erreur.
Vient ensuite le message proprement dit, qui indique dans ce cas que le
serveur a été configuré pour interdire l'accès au client. Le serveur
indique le chemin système du document requis (et non
son chemin web).</p>
<p>Une grande variété de messages différents peuvent apparaître dans le
journal des erreurs. La plupart d'entre eux sont similaires à l'exemple
ci-dessus. Le journal des erreurs peut aussi contenir des informations de
débogage en provenance de scripts CGI. Toute information qu'un script CGI
écrit sur la sortie d'erreurs standard <code>stderr</code> sera recopiée
telle quelle dans le journal des erreurs.</p>
<p>Il n'est pas possible de personnaliser
le journal des erreurs en ajoutant ou en
supprimant des informations. Cependant, les entrées du journal des erreurs
qui concernent certaines requêtes possèdent des entrées correspondantes
dans le <a href="#accesslog">journal des accès</a>. Ainsi, l'entrée de
l'exemple ci-dessus correspond à une entrée du journal des accès avec un
code de statut 403. Etant donné qu'il est possible de personnaliser le
journal des accès, vous pouvez obtenir d'avantage d'informations sur les
circonstances d'une erreur en consultant ce journal.</p>
<p>Pendant la phase de test, il est souvent utile de visualiser en continu
le journal des erreurs afin de détecter tout problème éventuel. Sur les
systèmes de type Unix, ceci s'effectue à l'aide de la commande :</p>
<div class="example"><p><code>
tail -f error_log
</code></p></div>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="accesslog" id="accesslog">Journal des accès</a></h2>
<table class="related"><tr><th>Modules Apparentés</th><th>Directives Apparentées</th></tr><tr><td><ul><li><code class="module"><a href="./mod/mod_log_config.html">mod_log_config</a></code></li><li><code class="module"><a href="./mod/mod_setenvif.html">mod_setenvif</a></code></li></ul></td><td><ul><li><code class="directive"><a href="./mod/mod_log_config.html#customlog">CustomLog</a></code></li><li><code class="directive"><a href="./mod/mod_log_config.html#logformat">LogFormat</a></code></li><li><code class="directive"><a href="./mod/mod_setenvif.html#setenvif">SetEnvIf</a></code></li></ul></td></tr></table>
<p>Le journal des accès au serveur
enregistre toutes les requêtes que traite
ce dernier. La localisation et le contenu du journal des accès sont définis
par la directive <code class="directive"><a href="./mod/mod_log_config.html#customlog">CustomLog</a></code>.
La directive <code class="directive"><a href="./mod/mod_log_config.html#logformat">LogFormat</a></code>
permet de simplifier la sélection du contenu du journal. Cette section
décrit comment configurer le serveur pour l'enregistrement des informations
dans le journal des accès.</p>
<p>Bien évidemment, le stockage d'informations dans le journal des accès
n'est que le point de départ de la gestion de la journalisation. L'étape
suivante consiste à analyser ces informations de façon à pouvoir en
extraire des statistiques utiles. L'analyse de journaux en général est hors du
cadre de ce document et ne fait pas vraiment partie intégrante
du travail du serveur web lui-même. Pour plus d'informations à propos de ce
sujet et des applications dédiées à l'analyse de journaux, vous pouvez vous
référer à <a href="http://dmoz.org/Computers/Software/Internet/ Site_Management/Log_analysis/">Open Directory</a> ou
<a href="http://dir.yahoo.com/Computers_and_Internet/Software/ Internet/World_Wide_Web/Servers/Log_Analysis_Tools/">Yahoo</a>.</p>
<p>Différentes versions du démon Apache httpd utilisaient d'autres modules
et directives pour contrôler la journalisation des accès, à l'instar de
mod_log_referer, mod_log_agent, et de la directive
<code>TransferLog</code>. La directive
<code class="directive"><a href="./mod/mod_log_config.html#customlog">CustomLog</a></code> rassemble
désormais les fonctionnalités de toutes les anciennes directives.</p>
<p>Le format du journal des accès est hautement configurable. Il est
défini à l'aide d'une chaîne de format qui ressemble sensiblement à la
chaîne de format de style langage C de printf(1). Vous trouverez quelques
exemples dans les sections suivantes. Pour une liste exhaustive de ce que
peut contenir une chaîne de format, vous pouvez vous référer au chapitre
<a href="mod/mod_log_config.html#formats">chaînes de format</a> de la
documentation du module <code class="module"><a href="./mod/mod_log_config.html">mod_log_config</a></code>.</p>
<h3><a name="common" id="common">Format habituel du journal</a></h3>
<p>Voici une configuration typique pour le journal des accès :</p>
<div class="example"><p><code>
LogFormat "%h %l %u %t \"%r\" %>s %b" common<br />
CustomLog logs/access_log common
</code></p></div>
<p>Ici est définie l'<em>identité</em> <code>common</code> qui est
ensuite associée à une chaîne de format de journalisation particulière.
La chaîne de format est constituée de directives débutant par le
caractère %, chacune d'entre elles indiquant au serveur d'enregistrer
un élément particulier d'information. Des caractères littéraux peuvent
également être insérés dans la chaîne de format ; il seront copiés tels
quels dans le flux de sortie destiné à la journalisation.
Les guillemets (<code>"</code>) doivent être protégées en les faisant
précéder d'un anti-slash (<code>\</code>) afin qu'ils ne soient pas
interprétés comme la fin de la chaîne de format. La chaîne de format
peut aussi contenir les caractères de contrôle spéciaux
"<code>\n</code>" et "<code>\t</code>" pour insérer respectivement
un passage à la ligne et une tabulation.</p>
<p>La directive <code class="directive"><a href="./mod/mod_log_config.html#customlog">CustomLog</a></code>
définit un nouveau fichier journal en l'associant à l'identité
précédemment définie. Le chemin du nom de fichier associé au journal
des accès est relatif au chemin défini par la directive
<code class="directive"><a href="./mod/core.html#serverroot">ServerRoot</a></code>, sauf s'il
débute par un slash.</p>
<p>La configuration ci-dessus va enregistrer les entrées de
journalisation selon un format connu sous le nom de
Common Log Format (CLF) pour "Format de journalisation standard".
Ce format standard peut être produit par de nombreux serveurs web
différents et lu par de nombreux programmes d'analyse de journaux.
Les entrées de fichier journal générées selon le format CLF
ressemblent à ceci :</p>
<div class="example"><p><code>
127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
/apache_pb.gif HTTP/1.0" 200 2326
</code></p></div>
<p>Chaque partie de cette entrée de journal est décrite
dans ce qui suit.</p>
<dl>
<dt><code>127.0.0.1</code> (<code>%h</code>)</dt>
<dd>Il s'agit de l'adresse IP du client (l'hôte distant) qui a envoyé
la requête au serveur. Si la directive
<code class="directive"><a href="./mod/core.html#hostnamelookups">HostnameLookups</a></code> est positionnée à
<code>On</code>, le serveur va essayer de déterminer le nom de l'hôte
et de l'enregistrer à la place de l'adresse IP. Cette configuration
n'est cependant pas recommandée car elle peut ralentir le serveur de
manière significative. Il est par conséquent préférable d'utiliser un
processeur d'analyse de journaux a posteriori
tel que <code class="program"><a href="./programs/logresolve.html">logresolve</a></code>
pour déterminer les noms d'hôte. L'adresse IP indiquée ici n'est pas
nécessairement l'adresse IP de la machine devant laquelle se trouve
l'utilisateur. Si un serveur mandataire s'intercale entre le serveur
et l'utilisateur, l'adresse indiquée sera celle du mandataire et non
celle de la machine à l'origine de la requête.</dd>
<dt><code>-</code> (<code>%l</code>)</dt>
<dd>Le "trait d'union" indique que la portion d'information
correspondante n'est pas disponible. Dans le cas présent, l'information
non disponible est l'identité (RFC 1413) du client telle que déterminée
par <code>identd</code> sur la machine cliente. Cette information est
très peu fiable et ne devrait jamais être utilisée, sauf dans le cas
de réseaux internes étroitement contrôlés. Le démon httpd ne cherchera
d'ailleurs à obtenir cette information que si la directive
<code class="directive"><a href="./mod/mod_ident.html#identitycheck">IdentityCheck</a></code> est positionnée
à <code>On</code>.</dd>
<dt><code>frank</code> (<code>%u</code>)</dt>
<dd>Il s'agit de l'identifiant utilisateur de la personne qui a
demandé le document, issu d'une authentification HTTP.
Ce même identifiant est en général fourni aux scripts CGI par
l'intermédiaire de la valeur de la variable d'environnement
<code>REMOTE_USER</code>. Si le statut de la requête (voir plus loin)
est 401, cette identifiant n'est pas fiable car l'utilisateur n'est
pas encore authentifié. Si le document n'est pas protégé par
mot de passe, cette partie d'information sera représentée par
"<code>-</code>", comme la partie précédente.</dd>
<dt><code>[10/Oct/2000:13:55:36 -0700]</code>
(<code>%t</code>)</dt>
<dd>
L'heure à laquelle la requête a été reçue.
Le format est le suivant :
<p class="indent">
<code>[jour/mois/année:heure:minutes:secondes zone]<br />
jour = 2*chiffre<br />
mois = 3*lettre<br />
année = 4*chiffre<br />
heure = 2*chiffre<br />
minutes = 2*chiffre<br />
secondes = 2*chiffre<br />
zone = (`+' | `-') 4*chiffre</code>
</p>Il est possible de modifier le format d'affichage de l'heure
en spécifiant <code>%{format}t</code> dans la chaîne de format du
journal, où <code>format</code> est une chaîne de format de même
forme que celle de la fonction <code>strftime(3)</code> de la
bibliothèque C standard.
</dd>
<dt><code>"GET /apache_pb.gif HTTP/1.0"</code>
(<code>\"%r\"</code>)</dt>
<dd>La ligne de la requête du client est placée entre guillemets.
Elle contient de nombreuses informations utiles. Tout d'abord, la
méthode utilisée par le client est <code>GET</code>. Ensuite, le
client a demandé la ressource <code>/apache_pb.gif</code>, et enfin,
le client a utilisé le protocole <code>HTTP/1.0</code>. Il est également
possible d'enregistrer séparément une ou plusieurs parties de la
requête. Par exemple, la chaîne de format "<code>%m %U %q %H</code>"
va enregistrer la méthode, le chemin, la chaîne de la requête et le
protocole, ce qui donnera le même résultat que
"<code>%r</code>".</dd>
<dt><code>200</code> (<code>%>s</code>)</dt>
<dd>C'est le code de statut que le serveur retourne au client. Cette
information est très importante car elle indique si la requête a fait
l'objet d'une réponse positive (codes commençant par 2), une
redirection (codes commençant par 3), une erreur due au client (codes
commençant par 4), ou une erreur due au serveur (codes commençant
par 5). Vous trouverez la liste complète des codes de statut possibles
dans la <a href="http://www.w3.org/Protocols/rfc2616/ rfc2616.txt">specification HTTP</a> (RFC2616 section 10).</dd>
<dt><code>2326</code> (<code>%b</code>)</dt>
<dd>La dernière partie indique la taille de l'objet retourné au client,
en-têtes non compris. Si aucun contenu n'a été retourné au client, cette
partie contiendra "<code>-</code>". Pour indiquer l'absence de contenu
par "<code>0</code>", utilisez <code>%B</code> au lieu de
<code>%b</code>.</dd>
</dl>
<h3><a name="combined" id="combined">Combined Log Format (Format de journalisation combiné)</a></h3>
<p>Une autre chaîne de format couramment utilisée est le
"Combined Log Format" (Format de journalisation combiné). Il s'utilise
comme suit :</p>
<div class="example"><p><code>
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
\"%{User-agent}i\"" combined<br />
CustomLog log/access_log combined
</code></p></div>
<p>Ce format est identique au Common Log Format, avec deux champs
supplémentaires. Chacun de ces deux champs utilise la directive
commençant par le caractère "%" <code>%{<em>header</em>}i</code>,
où <em>header</em> peut être n'importe quel en-tête de requête HTTP.
Avec ce format, le journal des accès se présentera comme suit :</p>
<div class="example"><p><code>
127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
/apache_pb.gif HTTP/1.0" 200 2326
"http://www.example.com/start.html" "Mozilla/4.08 [en]
(Win98; I ;Nav)"
</code></p></div>
<p>Les champs supplémentaires sont :</p>
<dl>
<dt><code>"http://www.example.com/start.html"</code>
(<code>\"%{Referer}i\"</code>)</dt>
<dd>L'en-tête "Referer" (sic) de la requête HTTP. Il indique le site
depuis lequel le client prétend avoir lancé sa requête. (Ce doit être
la page qui contient un lien vers <code>/apache_pb.gif</code> ou
inclut ce dernier fichier).</dd>
<dt><code>"Mozilla/4.08 [en] (Win98; I ;Nav)"</code>
(<code>\"%{User-agent}i\"</code>)</dt>
<dd>L'en-tête User-Agent de la requête HTTP. C'est une information
d'identification que le navigateur du client envoie à propos
de lui-même.</dd>
</dl>
<h3><a name="multiple" id="multiple">Journaux d'accès multiples</a></h3>
<p>Plusieurs journaux d'accès peuvent être créés en spécifiant tout
simplement plusieurs directives
<code class="directive"><a href="./mod/mod_log_config.html#customlog">CustomLog</a></code> dans le
fichier de configuration. Par exemple, les directives suivantes vont
créer trois journaux d'accès. Le premier contiendra les informations
de base CLF, le second les informations du Referer, et le troisième
les informations sur le navigateur. Les deux dernières directives
<code class="directive"><a href="./mod/mod_log_config.html#customlog">CustomLog</a></code> montrent
comment simuler les effets des directives <code>ReferLog</code> et
<code>AgentLog</code>.</p>
<div class="example"><p><code>
LogFormat "%h %l %u %t \"%r\" %>s %b" common<br />
CustomLog logs/access_log common<br />
CustomLog logs/referer_log "%{Referer}i -> %U"<br />
CustomLog logs/agent_log "%{User-agent}i"
</code></p></div>
<p>Cet exemple montre aussi qu'il n'est pas obligatoire d'associer
une chaîne de format à un alias au moyen de la directive
<code class="directive"><a href="./mod/mod_log_config.html#logformat">LogFormat</a></code>. Elle peut
être définie directement dans la ligne de la directive
<code class="directive"><a href="./mod/mod_log_config.html#customlog">CustomLog</a></code>.</p>
<h3><a name="conditional" id="conditional">Journalisation conditionnelle</a></h3>
<p>Il est parfois souhaitable d'exclure certaines entrées des journaux
d'accès en fonction des caractéristiques de la requête du client. On
peut facilement y parvenir à l'aide des
<a href="env.html">variables d'environnement</a>. Tout d'abord, une
variable d'environnement doit être définie pour indiquer que la
requête remplit certaines conditions. Pour ceci, on utilise en général
la directive <code class="directive"><a href="./mod/mod_setenvif.html#setenvif">SetEnvIf</a></code>,
puis la clause <code>env=</code> de la directive
<code class="directive"><a href="./mod/mod_log_config.html#customlog">CustomLog</a></code> pour inclure
ou exclure les requêtes pour lesquelles
la variable d'environnement est définie.
Quelques exemples :</p>
<div class="example"><p><code>
# Marque les requêtes en provenance de l'interface loop-back<br />
SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog<br />
# Marque les requêtes pour le fichier robots.txt<br />
SetEnvIf Request_URI "^/robots\.txt$" dontlog<br />
# Journalise toutes les autres requêtes<br />
CustomLog logs/access_log common env=!dontlog
</code></p></div>
<p>Autre exemple, imaginons l'enregistrement des requêtes en provenance
d'utilisateurs de langue anglaise dans un journal, et celles des autres
utilisateurs dans un autre journal.</p>
<div class="example"><p><code>
SetEnvIf Accept-Language "en" english<br />
CustomLog logs/english_log common env=english<br />
CustomLog logs/non_english_log common env=!english
</code></p></div>
<p>Bien que nous venions de montrer que la journalisation conditionnelle
est souple et très puissante, cette méthode de contrôle du contenu des
journaux n'est pas la seule. Les fichiers journaux sont plus utiles
quand ils contiennent un enregistrement complet de l'activité du serveur,
et il est souvent plus aisé de simplement traiter a posteriori les fichiers
journaux pour supprimer les requêtes que vous ne voulez pas y voir
apparaître.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="rotation" id="rotation">Rotation des journaux</a></h2>
<p>Même dans le cas d'un serveur modérément sollicité, la quantité
d'informations stockées dans les fichiers journaux est très importante.
Le fichier journal des accès grossit en général d'1 Mo ou plus toutes
les 10000 requêtes. Il est par conséquent nécessaire d'effectuer
périodiquement la rotation des journaux en déplaçant ou supprimant les
fichiers correspondants. On ne peut pas le faire pendant que le serveur
est en cours d'exécution, car Apache va continuer à écrire dans l'ancien
fichier journal aussi longtemps qu'il le maintiendra ouvert.
C'est pourquoi le serveur doit être
<a href="stopping.html">redémarré</a> après le déplacement ou la
suppression des fichiers journaux de façon à ce qu'il en ouvre
de nouveaux.</p>
<p>Avec un redémarrage <em>graceful</em>, on peut faire en sorte que le
serveur ouvre de nouveaux fichiers journaux sans perdre de connexions
existantes ou en cours avec les clients. Cependant, pour que ceci soit
possible, le serveur doit continuer à écrire dans les anciens fichiers
journaux pendant qu'il termine le traitement des requêtes en cours.
Il est donc nécessaire d'attendre un certain temps après le rédémarrage
avant d'effectuer tout traitement sur les fichiers journaux. Voici un
scénario typique dans lequel on effectue une simple rotation des
journaux en compressant les anciens fichiers correspondants afin
de gagner de l'espace disque :</p>
<div class="example"><p><code>
mv access_log access_log.old<br />
mv error_log error_log.old<br />
apachectl graceful<br />
sleep 600<br />
gzip access_log.old error_log.old
</code></p></div>
<p>La section suivante présente une autre méthode de rotation des journaux
qui consiste à utiliser les
<a href="#piped">journaux redirigés</a>.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="piped" id="piped">Journaux redirigés</a></h2>
<p>Nous avons vu que le démon httpd écrivait les informations de
journalisation des erreurs et des accès dans un fichier journal ;
il peut également
rediriger ces informations vers un autre processus par l'intermédiaire d'un
tube de communication (pipe). Cette fonctionnalité améliore
considérablement la souplesse de la journalisation, sans ajouter de code
au serveur principal. Pour rediriger les informations de journalisation
vers un tube de communication, remplacez simplement le nom de fichier
journal par
le caractère pipe "<code>|</code>", suivi du nom de l'exécutable qui va
recueillir les entrées de journal sur son entrée standard. Apache va
lancer le processus de redirection des journaux au moment du démarrage du
serveur, et le relancera s'il cesse de fonctionner
pendant l'exécution du serveur.
(Nous dénommons cette technique "journalisation
redirigée fiable" grâce à cette dernière fonctionnalité.)</p>
<p>Les processus de journalisation redirigée sont lancés par le processus
httpd parent, et héritent de l'UID de ce dernier. Cela signifie que les
programmes de journalisation dirigée s'exécutent généralement en tant que
root. Il est donc très important que ces programmes soient simples et
sécurisés.</p>
<p>Un des grands avantages de la journalisation redirigée est la possibilité
d'effectuer la rotation des journaux sans avoir à redémarrer le serveur. Pour
accomplir cette tâche, le serveur HTTP Apache fournit un programme simple
appelé <code class="program"><a href="./programs/rotatelogs.html">rotatelogs</a></code>. Par exemple, pour une rotation des
journaux toutes les 24 heures, ajoutez ces lignes :</p>
<div class="example"><p><code>
CustomLog "|/usr/local/apache/bin/rotatelogs
/var/log/access_log 86400" common
</code></p></div>
<p>Notez que l'ensemble de la commande qui sera appelée par le tube de
communication a été placée entre guillemets. Cet exemple
concerne le journal des accès, mais la même technique peut être utilisée
pour le journal des erreurs.</p>
<p>Comme la journalisation conditionnelle, la journalisation redirigée est
un outil très puissant, mais si elle existe, il est préférable d'utiliser
une solution plus simple comme le traitement a posteriori hors ligne.</p>
<p>Par défaut, le processus de redirection du journal est
lancé en invoquant un shell(en général avec
<code>/bin/sh -c</code>). Selon
les spécificités du shell, l'invocation via un shell
peut générer un processus shell
supplémentaire pour toute la durée du programme de redirection du
journal, et induire des problèmes de gestion de signaux au cours du
redémarrage.</p>
<p>Pour lancer le programme sans invoquer un shell, utilisez
"<code>||</code>" au lieu de "<code>|</code>" :</p>
<div class="example"><p><code>
# Invocation de "rotatelogs" sans utiliser de shell<br />
CustomLog "||/usr/local/apache/bin/rotatelogs
/var/log/access_log 86400" common
</code></p></div>
<div class="note"><h3>Note à propos de la plateforme Windows</h3>
<p>Notez que sous Windows, la mémoire allouée au bureau (desktop
heap) peut devenir insuffisante si vous utilisez de nombreux
processus vers lesquels sont redirigés des journaux via un pipe, et
ceci particulièrement si httpd s'exécute en tant que service. La
quantité de mémoire du bureau allouée à chaque service est spécifiée
dans le troisième argument du paramètre <code>SharedSection</code>
de la clé de registre
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\SubSystems\Windows.
<strong>Modifiez cette valeur avec prudence</strong> ; les
précautions d'usage s'imposent lorsqu'on modifie la base de registre,
mais vous pouvez aussi saturer la mémoire du bureau si vous
spécifiez une valeur trop élevée.</p>
</div>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="virtualhost" id="virtualhost">Hôtes virtuels</a></h2>
<p>Lorsqu'un serveur possède plusieurs <a href="vhosts/">hôtes virtuels</a>, il existe de nombreuses solutions pour gérer
les fichiers journaux. Par exemple, on peut utiliser les journaux comme
s'il s'agissait d'un serveur avec un seul hôte. Il suffit pour cela de
placer les directives de journalisation en dehors des sections
<code class="directive"><a href="./mod/core.html#virtualhost"><VirtualHost></a></code> au niveau
du serveur principal, ce qui a pour effet de journaliser toutes les
requêtes dans le même journal des accès et des erreurs. Cette technique
est cependant inappropriée pour recueillir des statistiques sur chaque
hôte virtuel individuellement.</p>
<p>Si des directives <code class="directive"><a href="./mod/mod_log_config.html#customlog">CustomLog</a></code> ou
<code class="directive"><a href="./mod/core.html#errorlog">ErrorLog</a></code> sont placées dans une section
<code class="directive"><a href="./mod/core.html#virtualhost"><VirtualHost></a></code>, toutes les
requêtes ou erreurs pour cet hôte virtuel ne seront enregistrées que dans
le fichier spécifié. Tout hôte virtuel qui ne possède pas de directives de
journalisation verra ses requêtes enregistrées dans le journal du serveur
principal. Cette technique est appropriée pour un petit nombre d'hôtes
virtuels, mais si ce nombre est important, elle peut devenir compliquée à
gérer. En outre, des problèmes de <a href="vhosts/fd-limits.html">nombre de descripteurs
de fichiers insuffisant</a> peuvent rapidement apparaître.</p>
<p>Il existe un très bon compromis pour le journal des accès. En intégrant
les informations à propos de l'hôte virtuel à la chaîne de format du
journal, il est possible de journaliser tous les hôtes dans le même
journal, puis de séparer ultérieurement le journal en plusieurs journaux
individuels. Considérons par exemple les directives suivantes :</p>
<div class="example"><p><code>
LogFormat "%v %l %u %t \"%r\" %>s %b"
comonvhost<br />
CustomLog logs/access_log comonvhost
</code></p></div>
<p>Le champ <code>%v</code> sert à enregistrer le nom de l'hôte virtuel qui
traite la requête. Un programme tel que <a href="programs/other.html">split-logfile</a> peut ensuite être utilisé
pour générer "à froid" autant de journaux que d'hôtes virtuels.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="other" id="other">Autres fichiers journaux</a></h2>
<table class="related"><tr><th>Modules Apparentés</th><th>Directives Apparentées</th></tr><tr><td><ul><li><code class="module"><a href="./mod/mod_logio.html">mod_logio</a></code></li><li><code class="module"><a href="./mod/mod_log_forensic.html">mod_log_forensic</a></code></li><li><code class="module"><a href="./mod/mod_cgi.html">mod_cgi</a></code></li><li><code class="module"><a href="./mod/mod_rewrite.html">mod_rewrite</a></code></li><li><code class="module"><a href="./mod/mod_log_config.html">mod_log_config</a></code></li></ul></td><td><ul><li><code class="directive"><a href="./mod/mod_log_config.html#logformat">LogFormat</a></code></li><li><code class="directive"><a href="./mod/mod_log_config.html#bufferedlogs">BufferedLogs</a></code></li><li><code class="directive"><a href="./mod/mod_log_forensic.html#forensiclog">ForensicLog</a></code></li><li><code class="directive"><a href="./mod/mpm_common.html#pidfile">PidFile</a></code></li><li><code class="directive"><a href="./mod/mod_rewrite.html#rewritelog">RewriteLog</a></code></li><li><code class="directive"><a href="./mod/mod_rewrite.html#rewriteloglevel">RewriteLogLevel</a></code></li><li><code class="directive"><a href="./mod/mod_cgi.html#scriptlog">ScriptLog</a></code></li><li><code class="directive"><a href="./mod/mod_cgi.html#scriptlogbuffer">ScriptLogBuffer</a></code></li><li><code class="directive"><a href="./mod/mod_cgi.html#scriptloglength">ScriptLogLength</a></code></li></ul></td></tr></table>
<h3>Enregistrement du nombre réel d'octets envoyés et reçus</h3>
<p>Le module <code class="module"><a href="./mod/mod_logio.html">mod_logio</a></code> fournit deux champs
<code class="directive"><a href="./mod/mod_log_config.html#logformat">LogFormat</a></code> supplémentaires
(%I et %O) qui permettent d'enregistrer le nombre réel d'octets reçus et
envoyés sur le réseau.</p>
<h3>Journalisation de style investigation judiciaire (forensic logging)</h3>
<p>Le module <code class="module"><a href="./mod/mod_log_forensic.html">mod_log_forensic</a></code> permet la journalisation
à des fins d'investigation judiciaire des requêtes des clients. La
journalisation est effectuée avant et après le traitement de la requête,
qui fait donc l'objet de deux entrées dans le journal. Le générateur de
journaux d'investigation est très strict et ne permet aucune
personnalisation. C'est un inestimable outil de débogage et de sécurité.</p>
<h3><a name="pidfile" id="pidfile">Fichier PID</a></h3>
<p>Au démarrage, le démon httpd Apache enregistre l'identifiant du
processus httpd parent dans le fichier <code>logs/httpd.pid</code>.
Le nom de ce fichier peut être modifié à l'aide de la directive
<code class="directive"><a href="./mod/mpm_common.html#pidfile">PidFile</a></code>. Cet identifiant
permet à l'administrateur de redémarrer et arrêter le démon en
envoyant des signaux au processus parent ; sous Windows, vous devez
utiliser l'option de ligne de commande -k. Pour plus de détails,
consulter la page <a href="stopping.html">Arrêt et redémarrage</a>.</p>
<h3><a name="scriptlog" id="scriptlog">Journal des scripts</a></h3>
<p>Afin de faciliter le débogage, la directive
<code class="directive"><a href="./mod/mod_cgi.html#scriptlog">ScriptLog</a></code> vous permet
d'enregistrer les entrées et sorties des scripts CGI. Elle ne doit être
utilisée que pendant la phase de test, et en aucun cas sur un
serveur en production. Vous trouverez plus d'informations dans la
documentation du module <a href="mod/mod_cgi.html">mod_cgi</a>.</p>
<h3><a name="rewritelog" id="rewritelog">Journal de réécriture</a></h3>
<p>Lorsqu'on utilise les fonctionnalités puissantes et complexes du
module <a href="mod/mod_rewrite.html">mod_rewrite</a>, il est presque
toujours nécessaire d'utiliser la directive
<code class="directive"><a href="./mod/mod_rewrite.html#rewritelog">RewriteLog</a></code> afin de
faciliter le débogage. Ce fichier journal fournit une analyse détaillée
de la transformation des requêtes par le moteur de réécriture. Le niveau
de détail est contrôlé par la directive
<code class="directive"><a href="./mod/mod_rewrite.html#rewriteloglevel">RewriteLogLevel</a></code>.</p>
</div></div>
<div class="bottomlang">
<p><span>Langues Disponibles: </span><a href="./en/logs.html" hreflang="en" rel="alternate" title="English"> en </a> |
<a href="./fr/logs.html" title="Français"> fr </a> |
<a href="./ja/logs.html" hreflang="ja" rel="alternate" title="Japanese"> ja </a> |
<a href="./ko/logs.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> |
<a href="./tr/logs.html" hreflang="tr" rel="alternate" title="Türkçe"> tr </a></p>
</div><div class="top"><a href="#page-header"><img src="./images/up.gif" alt="top" /></a></div><div class="section"><h2><a id="comments_section" name="comments_section">Commentaires</a></h2><div class="warning"><strong>Notice:</strong><br />This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our <a href="http://httpd.apache.org/lists.html">mailing lists</a>.</div>
<script type="text/javascript"><!--//--><![CDATA[//><!--
var comments_shortname = 'httpd';
var comments_identifier = 'http://httpd.apache.org/docs/2.2/logs.html';
(function(w, d) {
if (w.location.hostname.toLowerCase() == "httpd.apache.org") {
d.write('<div id="comments_thread"><\/div>');
var s = d.createElement('script');
s.type = 'text/javascript';
s.async = true;
s.src = 'https://comments.apache.org/show_comments.lua?site=' + comments_shortname + '&page=' + comments_identifier;
(d.getElementsByTagName('head')[0] || d.getElementsByTagName('body')[0]).appendChild(s);
}
else {
d.write('<div id="comments_thread">Comments are disabled for this page at the moment.<\/div>');
}
})(window, document);
//--><!]]></script></div><div id="footer">
<p class="apache">Copyright 2017 The Apache Software Foundation.<br />Autorisé sous <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
<p class="menu"><a href="./mod/">Modules</a> | <a href="./mod/directives.html">Directives</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="./glossary.html">Glossaire</a> | <a href="./sitemap.html">Plan du site</a></p></div><script type="text/javascript"><!--//--><![CDATA[//><!--
if (typeof(prettyPrint) !== 'undefined') {
prettyPrint();
}
//--><!]]></script>
</body></html>