Ayant à récupérer les évènements d'un équipement qui ne parle que syslog et snmp, j'ai d'abord cherché à configurer un serveur syslog (sur une distribution Fedora). Et j'étais très pressé (je ne voulais pas perdre d'informations sur le boîtier déjà en production).
Bon alors, pas ça, pas ça, pas ça
La configuration de syslog n'est pas simple. Voyons syslog-ng, comme Next Generation, ça doit être de la balle, ça. Extrait du site de documentation :
The following is a very simple configuration file for syslog-ng: it collects the internal messages of syslog-ng and the messages from /dev/log into the /var/log/messages_syslog-ng.log file.
@version:3.0
source s_local { unix-stream("/dev/log"); internal(); };
destination d_file_normal {file("/var/log/messages_syslog-ng.log"); };
log { source(s_local); destination(d_file); };
Ah. Et la documentation de l'administrateur fait 241 pages.
Bon alors il paraît que Kiwi Syslog est très simple d'emploi, avec une interface graphique. Mais sur Windows. Et la version complète est payante. Laisse tomber.
Rsyslog ?
Bon, attends, il y en a un autre : rsyslog. Installé d'un coup de yum, et là c'est bien. Il remplace le syslog standard, et il est livré avec une configuration qui lui permet de stocker les messages du système local aux endroits habituels (/var/log et compagnie).
Il n'y a qu'à voir le fichier de configuration, regarde c'est à pleurer de concision. Dans le fichier de configuration par défaut (/etc/rsyslog.conf), décommenter ça pour recevoir les messages par UDP :
[...]
# Provides UDP syslog reception
$ModLoad imudp.so
$UDPServerRun 514
[...]
Ajouter une règle pour créer des fichiers biens rangés par jour et par serveur source :
[...]
$template DynFile,"/var/log/remote/%$YEAR%/%$MONTH%/%$DAY%-%HOSTNAME%.log"
#### MODULES ####
[...]
Ajouter un traitement pour nos sources syslog externes, qu'on va ranger là où on a prévu (on suppose ici que le serveur syslog s'appelle SRV_SYSLOG) :
[...]
#### RULES ####
:HOSTNAME,!isequal,"SRV_SYSLOG" ?DynFile
[...]
Et on ajoute que à partir d'ici, les autres règles (celles qui étaient déjà dans la conf par défaut) ne s'appliquent que pour lorsque le message vient du serveur syslog lui-même.
Alors, là, c'est un BSD-style block, et pour comprendre comment ça s'écrit j'ai lutté un peu. J'ai fini par trouver un article dans un forum qui m'a mis sur la piste. +toto, ça veut dire à partir d'ici, c'est tout pour toto.
[...]
#### RULES ####
:HOSTNAME,!isequal,"SRV_SYSLOG" ?DynFile
+SRV_SYSLOG
# Log all kernel messages to the console.
[...]
Redémarre rsyslogd, et ayé ça marche. Mais comment on exploite les journaux à partir de là ? Avec grep ? Arrh non.
Splunk !
Et c'est là que je me suis souvenu du vieux test que j'avais fait de Splunk, avec son interface graphique. Ca devait être l'association entre Nagios et Splunk qui m'avait mis sur la voie.
Allez, j'essaye. Installation : suivre la doc (c'est un RPM à installer, on va s'en sortir). Configuration pour faire du syslog : définir la source, en trois clics, comme ça :
Fini. Quoi ? Oui. Et je prouve que ça marche, regarde les volumes :
Splunk va reconnaître tout seul le format des messages, et en extraire des champs comme date, source, etc. La communauté a créé pas mal de filtre supplémentaires pour reconnaître de nouveaux champs, voir la splunkbase.
J'ai importé celui qui m'intéresse, ce qui m'a ajouté un champ "service", dont j'extrait ce graphe d'une simple phrase (voir dans la barre de texte en haut) :
Et pour chercher, il suffit de taper le mot dans la barre de navigation, ou mieux : de cliquer dans un évènement sur le mot ou le groupe de mot.
Bon, allez c'est décidé, c'est lui le meilleur. Jusqu'à 500 Mo par jour, après il faut payer.