docs/manual/logs.xml.fr

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<!-- English Revision: 1935747 -->

<!--
 Licensed to the Apache Software Foundation (ASF) under one or more
 contributor license agreements.  See the NOTICE file distributed with
 this work for additional information regarding copyright ownership.
 The ASF licenses this file to You under the Apache License, Version 2.0
 (the "License"); you may not use this file except in compliance with
 the License.  You may obtain a copy of the License at

     http://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an "AS IS" BASIS,
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 See the License for the specific language governing permissions and
 limitations under the License.
-->

<manualpage metafile="logs.xml.meta">

  <title>Fichiers journaux</title>

  <summary>
    <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>
  </summary>

  <section id="overview">
    <title>Vue d'ensemble</title>

  <related>
      <modulelist>
        <module>mod_log_config</module>
        <module>mod_log_forensic</module>
        <module>mod_logio</module>
        <module>mod_cgi</module>
      </modulelist>
  </related>

  <p>
  Le serveur HTTP Apache fournit toute une variété de mécanismes
  différents pour la journalisation de tout ce qui peut se passer au
  sein de votre serveur, depuis la requête initiale, en passant par le
  processus de mise en correspondance des URLs, et jusqu'à la fermeture
  de la connexion, y compris toute erreur pouvant survenir au cours du
  traitement. De plus, certains modules tiers fournissent des
  fonctionnalités de journalisation ou insèrent des entrées dans les
  fichiers journaux existants, et les applications comme les programmes
  CGI, les scripts PHP ou autres gestionnaires peuvent envoyer des
  messages vers le journal des erreurs du serveur.
  </p>

  <p>
  Ce document décrit le fonctionnement des modules de journalisation
  fournis en standard avec le serveur httpd.
  </p>

  </section>

  <section id="security">
    <title>Avertissement à propos de la sécurité</title>

    <p>Tout utilisateur qui a les droits en écriture sur le répertoire dans
    lequel Apache httpd é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 d'être très prudent lors de la
    manipulation des journaux bruts.</p>
  </section>

  <section id="errorlog">
    <title>Journal des erreurs</title>

    <related>
      <modulelist>
        <module>core</module>
      </modulelist>
      <directivelist>
        <directive module="core">ErrorLog</directive>
	<directive module="core">ErrorLogFormat</directive>
        <directive module="core">LogLevel</directive>
      </directivelist>
    </related>

    <p>Le journal des erreurs du serveur, dont le nom et la localisation sont
    définis par la directive <directive module="core">ErrorLog</directive>,
    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 défini à l'aide de la directive <directive
    module="core">ErrorLogFormat</directive> avec laquelle vous pouvez
    choisir les valeurs à journaliser. Un format par défaut sera utilisé si vous
    n'en spécifiez pas un. Un message de journalisation typique se présente
    comme suit&nbsp;:</p>

    <example>
      [Fri Sep 09 10:42:29.902022 2011] [core:error] [pid 35708:tid 4328636416]
      [client 72.15.99.187] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error
    </example>

    <p>Le premier champ de l'entrée du journal est la date et l'heure du
    message. Le second champ indique le module qui produit le message (core,
    dans ce cas) et le niveau de sévérité de ce message. Suivent l'ID du processus
    et éventuellement l'ID du thread du processus qui a été soumis à cette
    condition. Le
    troisième champ contient l'adresse IP du client qui a effectué la requête.
    Vient ensuite le message d'erreur détaillé.</p>

    <note><p>Notez que certains messages qui étaient auparavant journalisés au
    niveau <code>error</code> ont été rétrogradés au niveau <code>info</code>
    dans httpd 2.4. Par exemple, les messages "File does not exist" pour les
    réponses 404 sont journalisés au niveau <code>info</code> et n'apparaîtront
    pas dans le journal des erreurs avec la valeur par défaut <code>warn</code>
    de la directive <directive module="core">LogLevel</directive>. Pour
    restaurer le comportement précédent, spécifiez <code>LogLevel warn
    core:info</code>.</p></note>

    <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>Mettre un symbole <code>%L</code> dans le journal des erreurs et le
     journal des accès produit un ID d'entrée de journalisation grâce auquel
     vous pourrez corréler l'entrée du journal des erreurs avec celle du journal
     des accès. Si <module>mod_unique_id</module> est chargé, son ID de requête
     unique sera utilisé comme ID d'entrée de journalisation.</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>

    <example>
      tail -f error_log
    </example>
  </section>

  <section id="permodule">
    <title>Journalisation par module</title>

    <p>La directive <directive module="core">LogLevel</directive> permet
    de spécifier un niveau de sévérité de journalisation pour chaque
    module. Vous pouvez ainsi résoudre un problème propre à un module particulier
    en augmentant son volume de journalisation sans augmenter ce volume
    pour les autres modules. Ceci est particulièrement utile lorsque
    vous voulez obtenir des détails sur le fonctionnement de modules
    comme <module>mod_proxy</module> ou <module>mod_rewrite</module>.</p>

    <p>Pour ce faire, vous devez spécifier le nom du module dans votre
    directive <directive>LogLevel</directive> :</p>

<example>
<highlight language="config">
LogLevel info rewrite:trace5
</highlight>
</example>

    <p>Dans cet exemple, le niveau de journalisation général est défini
    à info, et à <code>trace5</code> pour <module>mod_rewrite</module>.</p>

    <note>Cette directive remplace les directives de journalisation par
    module des versions précédentes du serveur, comme
    <code>RewriteLog</code>.</note>
 </section>


  <section id="accesslog">
    <title>Journal des accès</title>

    <related>
      <modulelist>
        <module>mod_log_config</module>
        <module>mod_setenvif</module>
      </modulelist>
      <directivelist>
        <directive module="mod_log_config">CustomLog</directive>
        <directive module="mod_log_config">LogFormat</directive>
        <directive module="mod_setenvif">SetEnvIf</directive>
      </directivelist>
    </related>

    <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 <directive module="mod_log_config">CustomLog</directive>.
    La directive <directive module="mod_log_config">LogFormat</directive>
    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>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 en
    dehors du sujet de ce document et ne fait pas vraiment partie intégrante
    du travail du serveur web lui-même.
    </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
    <directive	module="mod_log_config">CustomLog</directive> 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 <module>mod_log_config</module>.</p>

    <section id="common">
      <title>Format habituel du journal</title>

      <p>Voici une configuration typique pour le journal des accès :</p>

<example>
<highlight language="config">
LogFormat "%h %l %u %t \"%r\" %&gt;s %b" common
CustomLog "logs/access_log" common
</highlight>
</example>

      <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
      aussi ê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 échappées en les faisant
      précéder d'un anti-slash (<code>\</code>) afin qu'elles ne soient pas
      interprétées 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 <directive module="mod_log_config">CustomLog</directive>
      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
      <directive module="core">ServerRoot</directive>, 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>

      <example>
        127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
        /apache_pb.gif HTTP/1.0" 200 2326
      </example>

      <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
	<directive module="core">HostnameLookups</directive> 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 <program>logresolve</program>
	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
	<directive module="mod_ident">IdentityCheck</directive> 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 la forme de celle de la fonction <code>strftime(3)</code>
	  de la bibliothèque C standard, ou choisie parmi les
	  formats spéciaux supportés. Pour plus de détails,
	  reportez-vous aux. <a
	  href="mod/mod_log_config.html#formats">chaînes de format</a>
	  de <module>mod_log_config</module>.
        </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 aussi
	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>%&gt;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 spécification
	HTTP (<rfc>2616</rfc>) (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>
    </section>

    <section id="combined">
      <title>Combined Log Format (Format de journalisation combiné)</title>

      <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>

<example>
<highlight language="config">
LogFormat "%h %l %u %t \"%r\" %&gt;s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
CustomLog "log/access_log" combined
</highlight>
</example>

      <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>

      <example>
        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)"
      </example>

      <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>
    </section>

    <section id="multiple">
      <title>Journaux d'accès multiples</title>

      <p>Plusieurs journaux d'accès peuvent être créés en spécifiant tout
      simplement plusieurs directives
      <directive module="mod_log_config">CustomLog</directive> 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
      <directive module="mod_log_config">CustomLog</directive> montrent
      comment simuler les effets des directives <code>ReferLog</code> et
      <code>AgentLog</code>.</p>

<example>
<highlight language="config">
LogFormat "%h %l %u %t \"%r\" %&gt;s %b" common
CustomLog "logs/access_log" common
CustomLog "logs/referer_log" "%{Referer}i -&gt; %U"
CustomLog "logs/agent_log" "%{User-agent}i"
</highlight>
</example>

      <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
      <directive module="mod_log_config">LogFormat</directive>. Elle peut
      être définie directement dans la ligne de la directive
      <directive module="mod_log_config">CustomLog</directive>.</p>
    </section>

    <section id="conditional">
      <title>Journalisation conditionnelle</title>

      <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 aisément accomplir ceci à 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 <directive module="mod_setenvif">SetEnvIf</directive>,
      puis la clause <code>env=</code> de la directive
      <directive module="mod_log_config">CustomLog</directive> pour inclure
      ou exclure les requêtes pour lesquelles
      la variable d'environnement est définie.
      Quelques exemples :</p>

<example>
<highlight language="config">
# Marque les requêtes en provenance de l'interface loop-back
SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog
# Marque les requêtes pour le fichier robots.txt
SetEnvIf Request_URI "^/robots\.txt$" dontlog
# Journalise toutes les autres requêtes
CustomLog "logs/access_log" common env=!dontlog
</highlight>
</example>

      <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>

<example>
<highlight language="config">
SetEnvIf Accept-Language "en" english
CustomLog "logs/english_log" common env=english
CustomLog "logs/non_english_log" common env=!english
</highlight>
</example>

	<p>Dans le contexte d'une mise en cache, il peut être
	intéressant de connaître l'efficacité du cache. Pour y parvenir,
	on pourrait utiliser cette méthode simple :</p>

<example>
<highlight language="config">
SetEnv CACHE_MISS 1
LogFormat "%h %l %u %t "%r " %>s %b %{CACHE_MISS}e" common-cache
CustomLog "logs/access_log" common-cache
</highlight>
</example>

      <p><module>mod_cache</module> va s'exécuter avant
      <module>mod_env</module>, et si son action est couronnée de
      succès, il délivrera le contenu sans faire appel à ce dernier. Si
      l'URL se trouve dans le cache, la valeur journalisée sera alors
      <code>-</code>, tandis que dans le cas contraire elle sera
      <code>1</code>.</p>

      <p>En plus de la syntaxe <code>env=</code>, la directive <directive
      module="mod_log_config">LogFormat</directive> supporte les
      valeurs de journalisation conditionnelles basées sur le code de la
      réponse HTTP :</p>

<example>
<highlight language="config">
LogFormat "%400,501{User-agent}i" browserlog
LogFormat "%!200,304,302{Referer}i" refererlog
</highlight>
</example>

      <p>Dans le premier exemple, le <code>User-agent</code> sera
      enregistré si le code d'état HTTP est 400 ou 501. Dans le cas
      contraire, c'est un caractère "-" qui sera enregistré à la place.
      Dans le second exemple, le <code>Referer</code> sera enregistré si
      le code d'état HTTP n'est <strong>pas</strong> 200, 304, ou 302
      (remarquez le caractère "!" avant les codes d'état).</p>

      <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 à posteriori les fichiers
      journaux pour supprimer les requêtes que vous ne voulez pas y voir
      apparaître.</p>
    </section>
  </section>

  <section id="rotation">
    <title>Rotation des journaux</title>

    <p>Même sur un serveur modérément sollicité, les fichiers journaux
    grossissent rapidement — le journal des accès croît à peu près de 1 Mo ou
    plus toutes les 10000 requêtes. Sans rotation, les journaux consomment de
    plus en plus d’espace disque et deviennent difficiles à analyser. Il est
    donc recommandé de configurer une rotation automatique des journaux dès le
    départ.</p>

    <section id="rotation-rotatelogs">
      <title>Utilisation de rotatelogs (recommandé)</title>

      <p>L’approche la plus simple consiste à utiliser le programme
      <program>rotatelogs</program> intégré à httpd en utilisant la <a
      href="#piped">redirection des journaux</a>. Ce programme permet une
      rotation des journaux sans avoir à redémarrer le serveur et sans outil
      externe. Pour une rotation des journaux toutes les 24 heures :</p>

<example>
<highlight language="config">
CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/httpd/access_log 86400" combined
ErrorLog  "|/usr/local/apache/bin/rotatelogs /var/log/httpd/error_log 86400"
</highlight>
</example>

      <p>Pour une rotation lorsque la taille du journal atteint une certaine
      valeur (par exemple 100 Mo) :</p>

<example>
<highlight language="config">
CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/httpd/access_log 100M" combined
</highlight>
</example>

      <p>Vous pouvez aussi utiliser un motif de nom de fichier avec horodatage
      sous forme d’une chaîne au format <code>strftime</code> :</p>

<example>
<highlight language="config">
CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/httpd/access_log.%Y-%m-%d 86400" combined
</highlight>
</example>

    <p>Voir <program>rotatelogs</program> pour une description complète de ses
    options, en particulier les temps de décalage, les limitations de nombre de
    fichiers et la compression.</p>
    </section>

    <section id="rotation-logrotate">
      <title>Utilisation de logrotate ou de la gestion des journaux par le
      système</title>

      <p>La plupart des distributions de Linux fournissent le programme
      <code>logrotate</code> qui effectue une rotation, une compression et une
      expiration des fichiers journaux selon une planification. Si votre
      distribution comporte déjà une configuration de logrotate pour httpd
      (examinez <code>/etc/logrotate.d/</code>), elle gère peut-être déjà la
      rotation pour vous.</p>

      <p>Lorsqu’on utilise un outil de rotation externe comme
      <code>logrotate</code>, il faut faire en sorte que httpd réouvre ses
      fichiers journaux quand les anciens ont été mis de côté. Pour ce faire,
      l’approche standard est un redémarrage <em>graceful</em> :</p>

<example>
<highlight language="sh">
/usr/sbin/apachectl graceful
</highlight>
</example>

      <p>Votre script <code>postrotate</code> dans la configuration de logrotate
      doit contenir cette dernière commande (ou la commande équivalente
      <code>systemctl reload</code>). Comme httpd continue d’écrire dans
      l’ancien fichier jusqu’à ce qu’il reçoive le signal, tout post-traitement
      des fichiers ayant subi une rotation doit prévoir un bref délai.</p>

    </section>   
  </section>

  <section id="piped">
    <title>Journaux redirigés</title>

    <p>httpd peut écrire dans les fichiers journaux des erreurs et des accès à
    travers un tube (pipe) vers un autre processus, plutôt que d’écrire
    directement dans un fichier. Pour mettre en œuvre cette redirection,
    remplacez le nom du fichier par le caractère pipe "<code>|</code>", suivi de
    la commande qui recevra les entrées du journal sur son entrée standard :</p>

<example>
<highlight language="config">
CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/httpd/access_log 86400" combined
</highlight>
</example>

    <p>httpd démarre le processus de redirection des journaux au démarrage du
    serveur et le redémarre automatiquement s’il se plante (ce comportement est
    parfois nommé « journalisation redirigée fiable »). L’ensemble de la
    commande à partir du caractère pipe doit être entourée de guillemets — cette
    syntaxe fonctionne pour les deux directives <directive
    module="mod_log_config">CustomLog</directive> et <directive
    module="core">ErrorLog</directive>.</p>

    <p>Les processus de redirection des journaux sont lancés par le processus
    httpd parent et héritent de son identifiant utilisateur. Cela signifie en
    général qu’ils s’exécutent en tant que root ; faites donc en sorte que les
    programmes de redirection des journaux restent simples et sécurisés.</p>

    <p>Par défaut, le processus de redirection des journaux est lancé
    directement, sans passer par un shell. Vous pouvez utiliser
    "<code>|$</code>" à la place de "<code>|</code>" pour effectuer ce lancement
    via un shell (en général <code>/bin/sh -c</code>) :</p>

<example>
<highlight language="config">
CustomLog "|$/usr/local/apache/bin/rotatelogs /var/log/httpd/access_log 86400" combined
</highlight>
</example>

    <p>La variante avec shell est parfois requise si votre commande redirigée
    utilise des fonctionnalités du shell comme les caractères génériques ou le
    développement de variable. Dans la plupart des cas, il est préférable
    d’utiliser l’invocation directe (sans passer par un shell).</p>

    <note><title>Note à propos de la plateforme Windows</title>
    <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>
    </note>
    </section>

  <section id="virtualhost">
    <title>Hôtes virtuels</title>

    <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
    <directive module="core" type="section">VirtualHost</directive> 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 <directive module=
    "mod_log_config">CustomLog</directive> ou
    <directive module="core">ErrorLog</directive> sont placées dans une section
    <directive module="core" type="section">VirtualHost</directive>, 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>

<example>
<highlight language="config">
LogFormat "%v %p %h %l %u %t \"%r\" %&gt;s %b" commonvhost
CustomLog "logs/access_log" commonvhost
</highlight>
</example>

    <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/split-logfile.html">split-logfile</a> peut ensuite être utilisé
    pour générer "à froid" autant de journaux que d'hôtes virtuels.</p>
  </section>

  <section id="other">
    <title>Autres fichiers journaux</title>

    <related>
      <modulelist>
        <module>mod_logio</module>
	<module>mod_log_config</module>
	<module>mod_log_debug</module>
        <module>mod_log_forensic</module>
        <module>mod_cgi</module>
      </modulelist>
      <directivelist>
	<directive module="mod_log_config">BufferedLogs</directive>
        <directive module="mod_log_forensic">ForensicLog</directive>
	<directive module="mod_log_config">LogFormat</directive>
        <directive module="mod_log_debug">LogMessage</directive>
        <directive module="mpm_common">PidFile</directive>
        <directive module="mod_cgi">ScriptLog</directive>
        <directive module="mod_cgi">ScriptLogBuffer</directive>
        <directive module="mod_cgi">ScriptLogLength</directive>
      </directivelist>
    </related>

    <section>
      <title>Enregistrement du nombre réel d'octets envoyés et reçus</title>

      <p>Le module <module>mod_logio</module> fournit deux champs
      <directive module="mod_log_config">LogFormat</directive> 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>
    </section>

    <section>
      <title>Journalisation de style investigation judiciaire (forensic logging)</title>

      <p>Le module <module>mod_log_forensic</module> 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>
    </section>

    <section id="pidfile">
      <title>Fichier PID</title>

      <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
      <directive module="mpm_common">PidFile</directive>. 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>
    </section>

    <section id="scriptlog">
      <title>Journal des scripts</title>

      <p>Afin de faciliter le débogage, la directive
      <directive module="mod_cgi">ScriptLog</directive> 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>
    </section>

    <section id="debug">
        <title>Journalisation de débogage configurable</title>

        <p>La directive <directive module="mod_log_debug">LogMessage</directive>
	vous permet de créer vos propres messages de journalisation
	personnalisés pour faciliter vos opérations de débogage.
        </p>
    </section>
    
  </section>
</manualpage>