Supervision : Comprendre et créer ses contrôles
Sommaire
I. Présentation
Nous allons voir comment créer des contrôles dans un système de supervision open source. Je me suis basé sur la configuration de Naemon, mais c’est parfaitement applicable sur d’autres systèmes comme Nagios, Inciga ou Shinken.
Pour commencer, il nous faut des hôtes (si ce n’est pas fait, rendez-vous sur le cours précédent : Créer des objets et des hôtes ). Par défaut en créant un hôte on créer un contrôle. Il va seulement nous indiquer si l’équipement est en vie ou non. Mais nous pouvons faire bien plus que ça 😉 Je vois que vous êtes impatient, alors sans perdre de temps on passe à la 1ere étape !
II. Définir les éléments à superviser
C’est vraiment important. Avant de se lancer, faites une liste des éléments que vous souhaitez superviser. Et surtout, demandez-vous s’ils ont une utilité. On a souvent tendance à balancer des contrôles de partout, c’est vrai c’est chouette dans l’interface. Mais au final est-ce que ça nous apporte quelque chose ? Prenons l’exemple du serveur Exchange. Les serveurs exchange utilisent par défaut 100% de la RAM et c’est le fonctionnement normal du serveur. Bien que l’on soit tenté de contrôler la RAM de toutes nos machines, sur un serveur Exchange, ceci apporte peu d’intérêts.
III. Trouver ses plugins
A. Qu’est-ce que c’est un plug-in ?
Les plug-ins, ce sont des scripts exécutés par votre système pour réaliser un contrôle. Ils retournent un code qui sera interprété comme l’état du contrôle.
Vous avez plusieurs manières de trouver vos plug-ins. Vous pouvez installer le paquet nagios-plugins qui fournit des scripts pour contrôler une grande variété de services et protocoles.
apt-get install nagios-plugins
Vous devriez retrouver vos scripts dans le répertoire suivant /usr/lib/nagios/plug-ins
Si ces plug-ins ne vous suffisent pas, vous pourrez chercher sur internet un script qui correspond à votre besoin. En général vous trouverez ce que vous cherchez. Vous pouvez visiter ces sites :
Si vous ne trouvez pas votre bonheur et que vous avez l’âme d’un développeur, vous pouvez toujours vous lancer dans le développement de votre plug-in. Ou bien vous rapprocher d’une société de développement qui le fera pour vous.
B. Tester son plug-in
Étant donné que les plug-ins sont des scripts, vous pouvez directement lancer le script « à la main » sur votre système. Bien souvent vous trouverez une aide sur l’utilisation des scripts en les lançant avec l’option --help.
root@CYSA-NAEMON:~# /usr/lib/naemon/plugins/check_ssh --help check_ssh v1.4.16 (nagios-plugins 1.4.16) Copyright (c) 1999 Remi Paulmier <[email protected]> Copyright (c) 2000-2007 Nagios Plugin Development Team <[email protected]> Essaye de se connecter à un serveur SSH précisé à un port précis Utilisation: check_ssh [-46] [-t ] [-r ] [-p ] ...
De cette manière nous pourrons tester différentes façons d'utiliser notre plug-in :
root@CYSA-NAEMON:~# /usr/lib/naemon/plugins/check_ssh -p 22 127.0.0.1 SSH OK - OpenSSH_6.0p1 Debian-4+deb7u2 (protocol 2.0) | time=0,007751s;;;0,000000;10,000000
Attention : Pensez à vérifier que le compte de votre système de supervision a les droits d’exécution sur votre script. Le mieux est de tester son script directement avec le compte de supervision.
Vous pouvez voir sur la sortie de cette commande différentes informations.
- En premier lieu le résultat du contrôle interprété par le plug-in - OK.
- Ensuite vous avez la version SSH utilisée par l’hôte interrogé - OpenSSH_6.0p1 Debian-4+deb7u2 (protocol 2.0).
- Enfin juste après vous avez le temps de réponse du protocole, 0,007751s avec un timeout de 10s par défaut.
Si la réponse avait dépassé les 10 secondes, nous aurions eu le retour suivant :
CRITICAL - Le socket n'a pas répondu dans les 10 secondes
Nous avons toujours en première partie le retour du plug-in puis la sortie du plug-in, qui nous indique seulement ici qu’il n’a pas reçu de retour dans le délai du timeout.
IV. Créer une commande
Nous venons de déterminer la manière dont nous voulons utiliser notre plug-in. Nous allons pouvoir créer un objet commande qui sera utilisée par le système pour effectuer les contrôles.
define command {
command_name check_ssh
command_line /usr/lib/naemon/plugins/check_ssh -p 22 $HOSTADDRESS$
}
Ici nous avons créé un objet dont le nom est check_ssh. Chaque fois que le système appellera chech_ssh il exécutera la commande en paramètre command_line en remplaçant $HOSTADDRESS$ par l’adresse IP de la machine concernée. On appelle ceci une macro. C’est vraiment très utile et je vous ferais un détail sur comment utiliser les macros.
A. Les seuils de criticité
Suivant le type de votre contrôle, vous pouvez définir des seuils de criticité. Je vous invite à prendre le temps de réfléchir à ceci. Il est important qu’un changement d’état reflète la réalité de la situation. Dans énormément de cas, vous trouverez des configurations qui remontent des alertes critiques qui ne sont pas traitées. Simplement parce que l’alerte en réalité ne l’ai pas. Ce genre de situation pollue fortement l’efficacité de votre système, vos vraies alertes sont noyées avec les fausses.
C’est votre plug-in qui vous permettra de configurer vos seuils. Pour les modifier, nous interviendrons au niveau de l’objet command car c’est lui qui détermine les paramètres à utiliser. Petit exemple avec un contrôle d’espace disque. Avec le paramètre -w nous pouvons déterminer le seuil qui déclenchera l’état warning. Avec -c le seuil de l’état critique.
root@CYSA-NAEMON:~# /usr/lib/naemon/plugins/check_disk -w 20000 -c 10000 –u MB -p / DISK WARNING - free space: / 16926 MB (92% inode=95%);| /=1382MB;-712;4288;0;19288 root@CYSA-NAEMON:~# /usr/lib/naemon/plugins/check_disk -w 20% -c 10% -p / DISK OK - free space: / 16925 MB (92% inode=95%);| /=1383MB;15430;17359;0;19288
Je peux constater en testant mon plug-in que celui-ci me propose de définir des seuils de façons différentes. Dans mon premier test le seuil est défini par une volumétrie en MB alors que dans le second en pourcentage de la volumétrie global. J’ai choisi l’unité MB avec le paramètre -u. Vous pouvez choisir les valeurs suivantes : octets, kb, MB, GB et TB. Par défaut c’est MB.
Dans ce cas-ci, mon volume est plutôt fixe et évolue peu. J’ai décidé de fixer mon état d’avertissement à 5GB d’espace libre et mon état critique à 1GB.
define command {
command_name check_local_disk
command_line /usr/lib/naemon/plugins/check_disk -w 5000 -c 1000 -p /
}
Admettons que j’avais voulu contrôler un espace sur un serveur de fichier, j’aurais certainement pris une marge plus importante, car les volumes évoluent fortement. À vous d’adapter vos contrôles suivant vos capacités de réaction lorsqu’il s’agit de contrôles à but préventif.
En tout cas c’est super d’avoir créé une commande me direz-vous, mais comment je l’utilise pour contrôler mon serveur ? Hé bien pour cela, nous avons besoin de créer des services.
V. Créer un service
Les services vont définir les différents contrôles sur nos hôtes. Ce sont des objets, qui s’appliquent sur un ou plusieurs hôtes et qui s’appuient sur un objet command pour réaliser le contrôle. Comme pour les hôtes, nous aurons plusieurs états possibles pour nos services :
- OK : c’est OK…
- WARNING : Attention/Avertissement.
- CRITICAL : Là c’est rouge et critique, une intervention d’urgence est nécessaire.
- UNKNOWN : état inconnu/indéterminé.
Si vous avez bien suivi, c’est le script (plug-in) qui détermine l’état du service. Voici quelques paramètres à utiliser pour créer un service :
- host_name : ça sera le nom de notre hôte auquel sera attaché notre service. Concrètement c’est sur cette hôte que nous réaliserons le contrôle.
- hostgroup_name : La même chose, mais sur un groupe d’hôte.
- service_description : petite description du service.
- display_name : Le nom affiché pour votre service.
- check_command : L’objet commande utilisé pour réaliser le contrôle.
- max_check_attempts : Nombre de fois que l’hôte sera vérifié pour valider son état.
- check_interval : Temps en minute entre chaque contrôle de l’hôte.
- retry_interval : Temps en minute entre chaque contrôle dans un état non OK.
- check_period : Nom de l’objet timeperiod sur laquelle sera contrôlé l’hôte.
- notification_interval : Intervalle en minutes entre deux notifications pour l’hôte.
- notification_period : Nom de l’objet timeperiod de temps sur laquelle sera notifié un problème sur l’hôte.
contacts : Nom de l’objet contact à notifier lors d’un problème. - contact_groups : pareil, mais avec groupe de contact.
define service {
host_name SRV01
service_description État SSH
check_command check_ssh
max_check_attempts 5
check_interval 5
retry_interval 3
check_period 24x7
notification_interval 30
notification_period 24x7
notification_options w,c,r
contact_groups administrateurs
}
À ce stade vous avez configuré sur votre système un contrôle. Votre système se chargera ensuite de planifier les exécutions suivant les paramètres que vous avez configurés. Il sera surement nécessaire de configurer vos équipements/serveurs pour qu’ils répondent à vos contrôles. Ceci dépendra de la manière dont votre plug-in va les interroger.
Voici en bonus un petit schéma pour synthétiser les relations entre les objets à travers les paramètres que nous venons de voir :
Voir la partie précédente de ce cours : Supervision créer des objets et des hôtes
