Le syslog est un outil fort pratique lorsque l’on souhaite traiter différentes informations en provenance de diverses machines. Il existe un grand nombre de démon syslog.
Les plus connus sont :
- Syslog-NG (Linux)
- Syslog (Linux)
- rSyslog (Linux & BSD)
- KiwiSyslog (Windows)
- Syslogd (BSD)
Un message syslog (en) ressemble à çà :
Oct 06 00:00:01 <mon_serveur> <mon_service> service[warning] 110 <message>
Sous Windows, il n’y a pas par défaut de syslog, donc il faudra en implémenter un qui ira lire les données de l’”EventViewer”.
L’équipe de Metheris, propose un petit programme développé en C# permettant de faire la transition entre l’”EventViewer” et un serveur syslog.
Centreon E2S est disponible à l’adresse suivante : http://svn.modules.centreon.com/centreon-e2s/trunk/
Bon maintenant que l’introduction est finie, passons donc aux choses sérieuses. L’inter-action entre rSyslog et Nagios.
Dans un premier temps, il faut que le logiciel Nagios soit bien installé, configuré et que le fichier nagios.cmd soit accessible et fonctionnel.
Fichier /etc/rsyslog.conf :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
#### GLOBAL DIRECTIVES #### # include every config from /etc/rsyslog.d/ # with the extension &amp;lt;file&amp;gt;.conf $IncludeConfig /etc/rsyslog.d/*.conf # Use default timestamp format $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat #### MODULES #### $ModLoad imuxsock.so # provides support for local system logging (e.g. via logger command) $ModLoad imklog.so # provides kernel logging support (previously done by rklogd) $ModLoad immark.so # provides --MARK-- message capability $ModLoad imudp.so # Provides UDP syslog reception $ModLoad imtcp.so # Provides TCP syslog reception $UDPServerRun 514 $InputTCPServerRun 514 $ModLoad ommysql.so # MySQL Server Support #### RULES #### # Log all kernel messages to the console. # Logging much else clutters up the screen. #kern.* /dev/console # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none;cron.none /var/log/messages # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* -/var/log/maillog # Log cron stuff cron.* /var/log/cron # Everybody gets emergency messages *.emerg * # Save news errors of level crit and higher in a special file. uucp,news.crit /var/log/spooler # Save boot messages also to boot.log local7.* /var/log/boot.log |
Ensuite dans le dossier /etc/rsyslog.d/,
on y place le fichier nagios.conf contenant ceci :
1 2 3 4 |
# TEMPLATE $template tpNagios,"%HOSTNAME%|%syslogseverity%|%msg%" # ACTION *.* ^/usr/local/bin/syslog2nagios;tpNagios |
Explication:
Ici, je crée une nouveau patron dans lequel je place les informations formatées que va traiter mon binaire, une fois qu’il sera appelé par rSyslog. Le patron s’appelle ‘”tpNagios”.
Dans la documentation de rSyslog, on apprend que rSyslog peut appeller n’importe quel binaire et lui passer en 1er argument le message syslog (formaté biensur). Dans mon cas, je demande à rsyslog d’envoyer tout type de message reçu dans le script syslog2nagios.
Il faut aussi savoir que lorsque rSyslog lance un binaire/script, il le fait via l’instruction system() (en C), ce qui fait que lorsque le script est exécuté, rSyslog est bloqué tant que l’exécution de system() n’est pas arrivée à son terme. Il faut donc absolument que l’exécution du script soit la plus courte possible ou alors que le script se duplique.
Dans mon cas, je fais appel à un script en python qui va traiter les informations de façon simple:
- Ajouter le “timestamp”
- Mettre la bonne priorité (OK,WARNING ou CRITICAL)
- Formater le message pour le nagios.cmd
- Ecrire dans nagios.cmd
Et bien sur, il ne faut pas oublier que la correspondance entre le nom contenu dans /ect/hosts et le nom dans nagios soit exacte, sinon, la remonté d’informations ne se fera pas.
syslog2nagios :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
#!/usr/bin/env python # # Syslog to Nagios Alerting Script # By default : /usr/local/nagios/var/rw/nagios.cmd # This file need the correct rights import sys import os from time import gmtime, mktime fh = open ( '/usr/local/nagios/var/rw/nagios.cmd', 'a') myt = gmtime() myts = mktime(myt) MyStr = sys.argv[1] # Splitting Time MyList = MyStr.rsplit('|') Host = MyList[0] Severity = MyList[1] Sev = int(Severity) Message = MyList[2] if Sev &amp;lt;= 3: Severity = '2' elif Sev == 4: Severity = '1' else : Severity = '0' # [<timestamp>] PROCESS_SERVICE_CHECK_RESULT;<hostname>;<service>;[0-3](Nagios # Value);<message>;n str = '[%d] PROCESS_SERVICE_CHECK_RESULT;%s;Syslog;%s;%sn' % (myts,Host,Severity,Message) print str fh.write(str) fh.close() |
Maintenant, au niveau de Nagios, il suffira d’ajouter un service passif, en utilisant le script “check_snmp_dummy” ne faisant que retourner une valeur par défaut et un message par défaut (dans mon cas 0 et “OK”).
Service : Syslog
Script : check_snmp_dummy (0!OK)
Type de service : Passif
Et voila, la remontée des alertes en provenance du service Syslog se fait dans Nagios.
Allo,
si je comprends bin tu va envoyer TOUS les messages syslog dans nagios… sans aucun filtre…
J’imagine que tu ne monitor qu’un seul serveur ?
Comment ca va fonctionner avec mes 50 serveurs qui envoient leurs logs system + apache + mysql…. ? 🙂
Non,
Le filtrage je le fais au niveau de la machine centrale.
Étant donné que les utilisateurs font plein de modification, il m’était plus simple de filtrer à la réception que de devoir modifier les configurations à chaque fois.
Le script pour les alertes a été amélioré mais je n’ai pas encore mis les modifications en ligne,
filtrage sur les regex, mot clef et co.
Parcontre, le serveur mysql, c’est lui qui souffre le plus. Je pense fortement a passer à PostGreSQL mais Centreon ne le supporte pas pour le moment.
P.S. : Mon article décrivait un premier jet que j’avais écrit en 20 minutes en rentrant du travail (Oct 7, 2009 @ 11:53).
Hello,
Tout d’abord merci pour ce ptit tuto bien sympa. Il arrive pile poil à un moment où j’en avais besoin!
Par contre dans ton exemple ton serveur syslog et nagios sont sur la même machine si je comprends bien? Comment pourrais-je faire dans le cas où il s’agit de 2 machines differentes?
Autre chose, quand tu dis ” il ne faut pas oublier que la correspondance entre le nom contenu dans /ect/hosts et le nom dans nagios soit exacte”, de quel nom parles-tu?
Merci pour ces eclaircissements 😛
Snif snif personne pour m’aider? 😥
Je parle de la correspondance entre un reverse nslookup et le nom dans nagios.
soit si je fais nslookup 1.1.1.1
=> mamachine
dans nagios, l’hote mamachine doit avoir la même orthographe et doit exister.
ça va de soi, je pensais que tu parlais d’autre chose.
Mon problème c’est que le script syslog2nagios est sur le serveur syslog mais je vois que tu appelle le fichier nagios.cmd depuis cette meme machine => open ( ‘/usr/local/nagios/var/rw/nagios.cmd’, ‘a’)
Ma question est la suivante: comment puis-je faire pour ecrire dans ce fichier sachant que dans mon cas il est situé sur un autre serveur? est-ce comme pour un scp? genre: open ( ‘Machinedistante:/usr/local/nagios/var/rw/nagios.cmd’, ‘a’)?
Concernant l’inter-connexion entre les 2 serveurs, je vois ça comme ceci:
Serveur Nagios avec un petit processus XML-RPC (Serveur) qui écouterait sur un port déterminé prenons le 8080.
* XML-RPC Serveur en Python
Serveur Syslog qui lancerait le processus “syslog2nagios” qui à la place de faire un write, ferait un appel à une fonction XML-RPC (Client) pour envoyer le message.
* XML-RPC Client en Python
Avec une fonction assez simple qui recevrait de la part du client les infos que je place dans le “write”. Et ce serait le processus serveur qui écrirait dans “nagios.cmd”.
Avantage de XML-RPC, tout la partie protocole, tu l’évites et tu programmes ton syslog2nagios version XML-RPC en 10 minutes.
Bonjour,
Merci pour ce tuto qui est très intéressant et traite pile poil du sujet sur le quel je suis en train de travailler.
Dans tes commentaires tu disais que tu as amélioré le script pour les remonter d’alertes. Pourrais tu s’il te plait le mettre en ligne ?
Merci d’avance.
Dés que j’ai le temps de le refaire de manière propre oui.
Actuellement,
c’est un ensemble de morceaux de code fonctionnels mais non documentés.
Pourquoi ne pas ‘bêtement’ utiliser send_nsca côté serveur syslog et nsca côté nagios (souvent en place pour les checks passifs d’ailleurs)
C’est simple.
Un check, c’est un temps de latence entre la découverte et la mise en évidence.
Tandis que ce que je fais c’est asynchrone et me permet d’avoir le minimum de latence entre le message et la découverte. De plus, mon systeme ne dépend pas que de nagios. C’est un rien lourd de devoir passer par encore un intermédiaire pour x ou y raison.