Apache2 est l'un des serveurs HTTP les plus populaires et couramment utilisé. Bien que ce dernier sache utiliser le protocole SYSLOG pour les messages d'erreurs (via la directive « ErrorLog syslog »), il n'en est rien pour ceux liés à l'application, définis par la directive CustomLog. Pourquoi transmettre ces journaux de manière continue vers un serveur SYSLOG central ? Quelques raisons :
- analyser les journaux à des fins statistiques sans exécuter les processus nécessaires sur les serveurs de production ;
- analyser les journaux à la volée pour dépister failles de sécurité et attaques éventuelles.
Sous Linux, l'offre en matière de services syslog s'est bien étoffée depuis quelques années car en plus du vieux sysklogd, un héritier direct des syslogd qu'on trouve encore sous Unix, il y a à présent syslog-ng et rsyslog. Ce dernier a d'ailleurs remplacé sysklogd sur les distributions comme Debian ou Fedora.
Ces alternatives proposent de nouveaux protocoles comme REPL ainsi que de nombreuses fonctionnalités. Grâce à celles-ci, il est possible d'enregistrer les messages SYSLOG transmis par des systèmes tiers dans des fichiers dédiés à chaque système ou d'alimenter directement une base de données SQL.
La directive ErrorLog permet donc assez facilement de rediriger les messages d'erreurs générés par Apache2 vers SYSLOG. Exemple :
ErrorLog syslog:local7
La facilité par défaut est local7. Quant à la sévérité, elle dépend de la valeur attribuée à la directive LogLevel. En effet, la sévérité minimale est fixée par celle-ci. Tous les messages de sévérité équivalente ou inférieure à sa valeur sont ainsi transmises via SYSLOG. Il est ensuite possible de séparer les messages par sévérité à partir du service syslog :
local7.info /var/log/apache2.info
local7.warn /var/log/apache2.warn
local7.err /var/log/apache2.err
Cependant, il n'existe donc pas de fonction syslog pour la directive CustomLog. Cette dernière accepte toutefois l'appel d'une commande via un pipe au lieu du fichier de journalisation usuel.
Plusieurs solutions logicielles existent, dont l'une est écrite en Perl mais logger demeure sans doute la plus appropriée. En effet, cette dernière est fournie par défaut avec la plupart des systèmes Unix.
Il suffit alors de définir de façon globale la directive CustomLog comme suit :
LogFormat "[%P]: %v:%p %h %l %u \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" syslog
CustomLog "|logger -p local7.info -t apache2" syslog
Le format « syslog » est recommandé car il fournit une information essentielle : le nom du site virtuel à l'origine du message. De plus, il supprime l'horodatage fourni par Apache2, devenu inutile.
Évidemment, il convient de supprimer les directives équivalentes des configurations virtuelles pour que cela fonctionne correctement car ces dernières surchargent les directives globales.
Avec l'option -i, le PID de la commande logger est journalisé. La directive LogFormat permet d'ajouter le PID du processus fils servant la requête. Cependant, le format de SYSLOG n'est alors plus respecté.
Exemples :
May 26 00:40:47 mabelrode apache2: [19011]: debianfr.net:443 62.212.121.156 - - "GET /modules/views/css/views.css?S HTTP/1.1" 304 154 "http://www.debianfr.net/content/centralisation-des-journaux-apache2-syslog" "Mozilla/5.0 (X11; U; Linux i686; fr-fr) AppleWebKit/531.2+ (KHTML, like Gecko) Version/5.0 Safari/531.2+ Ubuntu/10.10 () Epiphany/2.30.2"
Voici le fichier permettant d'intégrer tout cela sous Debian, /etc/apache2/conf.d/syslog.conf :
# Logger to syslog
LogFormat "[%P]: %v:%p %h %l %u \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" syslog
CustomLog "|logger -p local7.info -t apache2" syslog
ErrorLog syslog:local7
Références :
- Vous devez vous identifier ou créer un compte pour écrire des commentaires
