"Qu'est ce que l'héritage?". Bon, ok! Je m'y colle. Nagios permet de superviser des serveurs ("host" dans la terminologie Nagios). Un host est une boîte noire avec une adresse IP. Cette boîte noire est pinguée régulièrement par Nagios pour vérifier qu'elle répond toujours. "C'est tout? Il ne peut pas faire autre chose Nagios?" Mais si, mais si ma p'tite dame. Nagios peut tester le CPU, la mémoire, les paritions, la présence d'un processus, faire une requête SQL, simuler une authentification web, ... ("service" dans la terminologie Nagios). Pour chaque service, l'administrateur doit déclarer plusieurs paramètres:

  • le nom du service
  • le host auquel il est attaché
  • le type de test avec les arguments de ce test ("check_command")
  • l'intervalle entre deux tests
  • l'intervalle entre deux notifications
  • si le service est passif
  • si le service est actif
  • le groupe devant recevoir les notifications
  • le nombre de tentatives avant d'envoyer une notification
  • une icône pour représenter le service
  • ...
"Quoi je vais devoir déclarer chacun de ces paramètres pour tous mes services? Mais c'est que j'en ai beaucoup moi des services? C'est trop long! Et je suis quelqu'un d'important moi: je n'ai pas de temps à perdre avec tout ça!". Holà ma p'tite dame! Doucement: c'est prévu. Il suffit de faire un modèle ("template") dans lequel vous pouvez définir tous les paramètres une et une seule fois. Ensuite, lors de votre définition de service, vous avez juste à indiquer le modèle utilisé et automatiquement, le service hérite des paramètres de ce modèle! Le paramètre est entré une et une seule fois, puis réutiliser grâce à la notion d'héritage. Vous gagnez un temps considérable avec ce mécanisme. Alors? Merci qui? "Merci Nagios!". Bien!

Qu'est ce qu'il y a de nouveau dans la version 3 concernant l'héritage? Dans un premier temps, les services héritent automatiquement de quelques paramètres du host auquel ils sont attachés si jamais ces paramètres n'ont pas été définis dans ces services. C'est le cas pour les groupes de contact, l'intervalle entre deux notifications et la période de notification. Un exemple: le groupe de contact ("contactgroup") d'un host est "Linux_admins_group". Si vous créez un service sans préciser de valeur pour ce paramètre, alors le paramètre de ce service a automatiquement la valeur "Linux_admins_group". Alors, c'est bien ou ce n'est pas bien? "C'est bien mais..." Mais quoi? "Mais moi je définis toujours le groupe dans mon modèle tout en haut! Je veux garder ce mécanisme car j'ai beaucoup de services avec le même contactgroup. Je ne veux pas perdre mon temps à définir mon contactgroup à chaque fois. Par contre je veux pour certains services que ce mécanisme fonctionne!"

Ha la là! On vous donne la main et vous prenez le bras! Heureusement, Nagios prévoit cela! Il suffit de déclarer la valeur null uniquement dans les quelques services qui vous intéressent. Dès lors la valeur ne sera pas reprise du template. Comme il n'y a pas de valeur pour ce paramètre, il héritera automatiquement du contactgroup du host. Facile non? "...". Je n'ai pas entendu, qu'avez vous dit? "Oui mais moi je veux ajouter des contactgroups aux contactgroups du modèle. Je veux définir dans mes modèles quelques contactgroups pour un service donné mais pour un service je veux lui ajouter des contacgroups. C'est possible cela?"

Et oui! Dans cette nouvelle version, c'est possible! Il suffit de préfixer la valeur du paramètre par un "+" et les contactgroups seront ajoutés au lieu de remplacer la valeur définie dans le template. Dans mon template, je définie le contactgroup "Linux_admins_group" et dans mon service je défini "+MySQL_admins_group". Dès lors, les deux contactgroups seront ajoutés à ce service. Alors? Quelque chose à ajouter? Oui? Bon je vous écoute! "Non je voulais juste dire... Merci Nagios!". Haaaa! Enfin!