Introduction
Cette partie de la documentation tente d'expliquer la configuration des objets par héritage et comment ils sont utiliser dans la configuration des objets basé sur des modèles.
Une de mes motivations majeures en ajoutant un support pour la configuration des objets via des modèles était de fournir l'héritage de propriétés depuis d'autres définitions d'objets. L'héritage de propriétés d'objets s'accomplit de manière récursive lors de la lecture des fichiers de configurations par Nagios.
Si vous avez encore des doutes sur les principes de récursion ou d'héritage après la lecture de ce document, regardez les exemples de configuration dans le paquetage. Si cela ne vous suffit pas, envoyer un email avec une description détaillée de votre problème sur la liste de diffusion nagios-users[NdT : liste de diffusion en anglais, pour un support en français vous pouvez aller sur http://forums.opsyx.com/].
Les concepts de base
Il y a trois variables concernant le principe de récursion et d'héritage qui sont disponibles dans toutes définitions d'objets. Elles sont indiquées en rouge dans ce qui suit...
define someobjecttype{
object-specific variables ...
name template_name
use name_of_template_to_use
register [0/1]
}
La première variable est name. C'est simplement un nom pour faire référence au "modèle" dans d'autres définitions d'objets qui, dans ce cas, héritent des propriétés/variables des objets. Le nom du modèle doit être unique dans tous les objets du même type, vous ne pouvez pas avoir deux ou plus de définitions d'hôte qui ont "hosttemplate" comme nom de modèles.
La seconde variable est use. C'est la variable qui permet de spécifier le nom du modèle duquel vous voulez hériter les propriétés/variables. Le nom que vous spécifiez pour cette variable doit être défini dans un autre modèle d'objet (en utilisant la variable name).
La troisième variable est register. Cette variable est utilisée pour indiquer si oui ou non la définition de l'objet devrait être "enregistrée" avec Nagios. Par défaut, toutes les définitions d'objet sont enregistrées. Si vous utilisez une définition partielle d'objet comme modèle, vous souhaiterz éviter l'enregistrer (un exemple est fourni par la suite). Les valeurs sont: 0 = NE PAS enregistrer la définition de l'objet, 1 = enregistrer la définition (la valeur par défaut). Cette variable n'est pas héritée; chaque définition d'objet (même partielle) utilisée comme template doit explicitement mettre la variable register à 0. Ceci permet d'éviter de spécifier la directive register à 1 pour chaque objet qui doit être enregistré [NdT : je comprends la phrase mais j'arrive pas à trouver une bonne traduction ! :(].
Variables locales versus variables héritées
Une des choses importante à comprendre avec l'héritage est que les variables locales d'un objet sont toujours prioritaires par rapport à celles définies dans le modèle. Regardez l'exemple suivant contenant deux définitions d'hôtes (l'ensemble des variables nécessaires au bon fonctionnement n'a pas été présenté).
define host{
host_name bighost1
check_command check-host-alive
notification_options d,u,r
max_check_attempts 5
name hosttemplate1
}
define host{
host_name bighost2
max_check_attempts 3
use hosttemplate1
}
Vous remarquerez que la définition de l'hôte bighost1 a été définie avec hosttemplate1 comme nom de modèle. La définition de l'hôte bighost2 utilise la définition de bighost1 comme modèle d'objet. Une fois que Nagios a analysé ces données, la définition de l'hôte bighost2 devrait être équivalente à la définition suivante :
define host{
host_name bighost2
check_command check-host-alive
notification_options d,u,r
max_check_attempts 3
}
Vous pouvez voir que les variables check_command et notification_options sont héritées depuis le modèle d'objet (où l'hôte bighost1 est défini). Cependant, les variables host_name et max_check_attempts ne sont pas héritées depuis le modèle parce qu'elles ont été définies localement. Souvenez-vous, les variables définies localement surchargent les variables qui normalement devraient être héritées depuis le modèle. Cela devrait être un concept assez simple à comprendre.
L'héritage en chaîne
Les objets peuvent hériter de propriétés/variables à travers plusieurs niveaux de modèles d'objets. Regardez l'exemple suivant :
define host{
host_name bighost1
check_command check-host-alive
notification_options d,u,r
max_check_attempts 5
name hosttemplate1
}
define host{
host_name bighost2
max_check_attempts 3
use hosttemplate1
name hosttemplate2
}
define host{
host_name bighost3
use hosttemplate2
}
Vous pouvez remarquer que la définition de l'hôte bighost3 hérite de variables depuis la définition d'hôte bighost2, laquelle hérite de variables depuis la définition d'hôte bighost1. Une fois que Nagios a analysé ces données, les défintions des hôtes devraient être équivalentes à celle-ci :
define host{
host_name bighost1
check_command check-host-alive
notification_options d,u,r
max_check_attempts 5
}
define host{
host_name bighost2
check_command check-host-alive
notification_options d,u,r
max_check_attempts 3
}
define host{
host_name bighost3
check_command check-host-alive
notification_options d,u,r
max_check_attempts 3
}
Il n'y a aucune limite d'héritage sur la "profondeur" de l'héritage, mais vous voudrez probablement vous limiter vous-même à quelques niveaux pour une gestion plus saine.
Utiliser des définitions incomplète d'hôte comme modèle
Il est possible d'utiliser des définitions incomplète d'objets comme modèle. Par "définition incomplète", j'entends que toutes les variables nécessaires à un objet n'ont pas été fournies dans la définition. Capeut sembler bizarre d'utiliser une définition incomplète comme modèle, pourtant c'est en effet ce que je vous recommande d'utiliser. Pourquoi ? Et bien, cela peut être vu comme un ensemble de valeurs par défaut utilisées par toutes les définitions d'objets. Prenez l'exemple qui suit :
define host{
check_command check-host-alive
notification_options d,u,r
max_check_attempts 5
name generichosttemplate
register 0
}
define host{
host_name bighost1
address 192.168.1.3
use generichosthosttemplate
}
define host{
host_name bighost2
address 192.168.1.4
use generichosthosttemplate
}
Remarquez que la première définition est incomplète car il manque la variable host_name nécessaire. Nous n'avons pas besoin de fournir le nom d'hôte car nous voulons simplement utiliser cette définition comme un modèle générique. Dans le but d'éviter que cette définition soit enregistrée par Nagios comme celle d'un hôte traditionnel, nous affectons 0 à la variable register.
Les définitions des hôtes bighost1 et bighost2 héritent des variables définies dans l'hôte générique. La seule variable que nous avons choisie de surcharger est la variable address afin que les deux hôtes aient exactement les mêmes propiétés en dehors de leurs variables host_name et address. Une fois que Nagios a analysé ces données, les définitions des hôtes devraient être équivalentes à ceci :
define host{
host_name bighost1
address 192.168.1.3
check_command check-host-alive
notification_options d,u,r
max_check_attempts 5
}
define host{
host_name bighost2
address 192.168.1.4
check_command check-host-alive
notification_options d,u,r
max_check_attempts 5
}
Enfin, l'utilisation de modèle pour les variables par défaut fait gagner un temps précieux. Cela vous évitera aussi de vous casse la tête si vous voulez changer des valeurs par défaut pour un grand nombre d'hôtes.