Table des matières

Configuration et lancement

Les modules disponibles

L’architecture de Shinken se veut beaucoup plus modulaire. Nombreux sont les paramètres présents dans nagios.cfg de Nagios qui sont passés sous des modules. Et tout ceci pour nous simplifier la vie!! :) La configuration sera simple pour une personne qui utilise déjà Nagios : c’est la même, mais avec quelques petits ajouts pour nos différents éléments. Un exemple de configuration est déjà disponible dans le path d’installation. Le fichier définissant les éléments de l’architecture est shinken-specific.cfg. Comme ça vous pouvez garder votre générateur de configuration de style Centreon tout en utilisant Shinken avec une architecture distribuée. Magique.

Les différents éléments sont définis suivant un modèle commun :

Certains éléments possèdent des options particulières :

Les modules ont comme propriétés :

Ci dessous une liste non exhaustive des modules, ainsi que leur paramètres.

ndodb_mysql

Chargé par le Broker. Export en base Ndo sous Mysql. Nécessite le module Python MySQLdb (apt-get install python-mysqldb).

Prends les paramètres :

ndodb_oracle

Chargé par le Broker. Export en base Ndo sous Oracle. Nécessite un client Oracle sur le serveur et que le répertoire ORACLE_HOME/lib soit dans le ld.config.cfg (ou bien alors que le daemon broker soit lancé avec LD_LIBRARY_PATH qui pointe vers ce même répertoire). Il demande également le module Python Cx_Oracle disponible sur http://cx-oracle.sourceforge.net/. Ah oui, ceci nécessite bien sûr une base Oracle avec le schémas de base déjà inséré (cf icinga pour le fichier oracle.sql).

Il prends en compte les paramètres suivants :

merlindb

Chargé par le Broker. Export en base Merlin sous Mysql ou sqlite. Nécessite le module Python MySQLdb ou Sqlite. (apt-get install python-mysqldb).

CouchDB

Chargé par le Broker. Export dans une base CouchDB (ouai, ultra utile :) )

service_perfdata

Chargé par le Broker. Export des informations de perfdata des services. Prends le paramètre :

exemple : $LASTSERVICECHECK$\t$HOSTNAME$\t$SERVICEDESC$\t$SERVICEOUTPUT$\t$SERVICEPERFDATA$\t$SERVICESTATE$\n

host_perfdata

Chargé par le Broker. Export des informations de perfdata des hôtes. Prends le paramètre :

exemple : $LASTHOSTCHECK$\t$HOSTNAME$\t$HOSTOUTPUT$\t$HOSTSTATE$\t$HOSTPERFDATA$\n

Live Status

Chargé par le Broker. Présentation des données comme le module Livestatus de Nagios

Simple-log

Chargé par le Broker. Module permettant d’avoir tout les logs dans le même fichier. (Sauf si on lance le mode debug)

Syslog

Chargé par le Broker. Envoie tout les logs logs vers le syslog. Ne peut pas être chargé en même temps que Simple-log

Status.dat

Chargé par le Broker. Module utilisée pour les vieilles interface Nagios. Utile pour le nagiostats.

NPCD

A utiliser avec l’interface PNP.

Modules de Rétention

FIXME : Detailler les différences

define module{ 

     module_name      PickleRetention
     module_type      pickle_retention_file_generic
     path             /tmp/retention.dat

}

define module{ 

     module_name      PickleRetentionBroker
     module_type      pickle_retention_file_generic
     path             /tmp/retention_broker.dat

}

define module{ 

     module_name      PickleRetentionArbiter
     module_type      pickle_retention_file_generic
     path             /tmp/retention_arbiter.dat

}

define module{ 

     module_name      NagiosRetention
     module_type      nagios_retention_file
     path             /tmp/retention-nagios.dat

}

define module{ 

     module_name      MemcacheRetention
     module_type      memcache_retention
     server           127.0.0.1
     port             11211

}

define module{ 

     module_name      RedisRetention
     module_type      redis_retention
     server           127.0.0.1

CommandFile

Exemple de configuration

Ceci donne par exemple pour une configuration simple (sans distribuée, ni hautement disponible) sur la machine qui se nomme serveur-maitre et qui a comme IP 192.168.0.1. Le Broker aura deux modules : un export vers la base Merlin, un autre pour la création d’un fichier de log unique pour toute l’architecture (équivalent de nagios.log, mais pour tous les daemons à la fois) : 

define arbiter{
       arbiter_name  arbiter-1
       host_name     serveur-maitre
       address       192.168.0.1
       port          7770
       spare         0
       }

define scheduler{
       scheduler_name	scheduler-1
       address	192.168.0.1
       port	7768
       spare	0
       }

define reactionner{
       reactionner_name	    reactionner-1
       address	192.168.0.1
       port	7769
       spare	0
       }

define poller{
       poller_name     poller-1
       address  192.168.0.1
       port     7771
       spare    0
}

define broker{
       broker_name	broker-1
       address	192.168.0.1
       port	7772
       spare	0
       modules  Export_Merlin,Simple-log
       }

define module{
       module_name      Export_Merlin
       module_type      merlindb
       backend          mysql
       database         merlin
       user             root
       password         root
       host             localhost
       character_set    utf8     ;optionnel, UTF-8 par défaut
}

define module{
       module_name      Simple-log
       module_type      simple_log
       path             /usr/local/shinken/src/var/shinken.log
}

Pour être compatible Nagios, un pack (un arbiter, un scheduler, un poller, un reactionner et un broker) est défini si l’administrateur n’en utilise pas avec toutes les valeurs par défauts.

Les daemons utilisent une configuration locale qui est présente juste pour définir les paramètres d’écoute et de définition de répertorie de travail. Il est possible de démarrer un daemon sans configuration, et dans ce cas il prendra simplement ses paramètres par défaut. Un exemple de configuration de daemon pour le scheduler : etc/schedulerd.ini 

$cat etc/schedulerd.ini

[daemon]
workdir=/usr/local/shinken/src/var
pidfile=%(workdir)s/schedulerd.pid
port=7768
host=0.0.0.0
user=shinken
group=shinken
idontcareaboutsecurity=0

Cette configuration est au format Python (RFC jenemesouviensplusdunumero). Les paramètres sont simples:

Exécution de Shinken avec les fichiers de configuration

Pour le lancement, ouvrez un shell sur la machine avec le user shinken. Dans un soucis de simplicité pour commencer, ici nous allons lancer tous les daemons sur la même machine nommée serveur-maitre. 

cd shinken
python bin/shinken-scheduler.py -d -c etc/schedulerd.ini
python bin/shinken-poller.py -d  -c etc/pollerd.ini
python bin/shinken-reactionner.py -d  -c etc/reactionnerd.ini
python bin/shinken-broker.py -d  -c etc/brokerd.ini

#on vérifie tout d'abord la conf
python bin/shinken-arbiter.py -v -c etc/nagios.cfg -c etc/shinken-specific.cfg

#si c'est bon, on lance réellement :
python bin/shinken-arbiter.py -d -c etc/nagios.cfg -c etc/shinken-specific.cfg

#Autre solution plus rapide qui lance tout les démons et vérifie la configuration
/etc/init.d/shinken start
#ou
/etc/init.d/shinken restart
Pour lancer en debug l’un des démons, il suffit d’ajouter l’option –debug [nom-de-fichier]. Par défaut c’est <nomdumodule>-debug.log

Vous pouvez alors vous ruer sur votre Ninja pour voir les informations qui vous intéresse.

Ninja ne gère qu’un ordonnanceur à la fois, c’est pourquoi Shinken envoie toutes les informatisons en base comme si elles provenaient de l’instance_id 0, mais il gère bien le multiple instance.