Cette documentation essaye d'expliquer l'héritage d'objet et comment il peut être utilisé dans vos définitions d'objet.

Si vous êtes perdu dans le fonctionnent des récurrences et des héritages après avoir lu cela, allez voir le ficher de configuration d'un objet simple proposé par la distribution Nagios. Si cela ne vous aide toujours pas, laissez un message mail à la liste de diffusion nagios-users avec une description détaillée de votre problème.

Il y a trois variables qui affectent la récursion et l'héritage qui sont présentes dans toutes les définitions d'objet. Elles sont indiquées en rouge ci-dessous

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 le nom du gabarit qui peut être référencé dans d'autre définition d'objet, de manière à ce qu'ils héritent des propriétés/variables de cet objet.

La deuxième variable est use. C'est ici que vous spécifiez le nom des objets gabarit dont vous voulez hériter les propriétés/variables. Le nom que vous spécifiez dans cette variable doit être défini dans un autre gabarit d'objet nommé. (En utilisant la variable nom)

La troisième variable est register. Cette variable est utilisée pour indiquer si la définition de l'objet doit être prise en compte par Nagios ou non. Par défaut, toutes les défintions d'objet sont prise en compte. Si vous utilisez une définition d'objet partiel comme gabarit, vous voulez éviter qu'il soit prise en compte (Un exemple de ce mécanisme sera présentez plus loin). Les valeurs acceptées sont les suivantes : 0 = ne PAS prendre en compte la définition de l'objet, 1 = prendre en compte la définition de l'objet (Comportement par défaut). Cette variable n'est pas héritée, toutes définitions d'objet (partiel) utilisées comme gabarits doivent explicitement avoir le paramètre register à 0. Celà évite d'avoir à surcharger une directive register héritée avec la valeur 1 pour tous les objets qui doivent être pris en compte.

Une chose importante à comprendre avec l'héritage c'est que les variables locales ont toujours autorité sur les variables définies dans un gabarit d'objet. Regardez l'exemple suivant avec deux définitions d'hotes (toutes les variables nécessaires n'ont pas été indiquées)

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 comme ayant hosttemplate1 comme nom de gabarit. La définition de l'hôte bighost2 utilise la définition de bighost1 comme gabarit. Une fois que Nagios traite les données, le résultat de la définition de l'hôte bighost2 sera équivalent à cette définition :

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 du gabarit.( où l'hôte bighost1 a été défini). Cependant, les variables host_name et max_check_attempts n'ont pas été héritées du gabarit car elles sont définies localement. N'oubliez pas que les variables définies localement surchargent les variables qui devraient normalement être héritées du gabarit. C'est un concept assez facile à comprendre.

Les objets peuvent hériter des propriétés/variables de multiples niveaux des gabarits 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 remarquerez que la définition de l'hôte bighost3 hérite des variables de la définition de l'hôte bighost2, qui lui-même hérite des variables de la définition de l'hôte bighost1. Une fois que Nagios a traité ces données de configuration, le résultat de la définition de ces hôtes est équivalent à :

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 pas de limite de profondeur d'héritage, mais vous voudrez probablement vous limitez à tout au plus quelques niveaux, de façon à garder votre santé mentale.

Il est possible d'utiliser une définition incomplète d'object comme gabarit afin de les utiliser dans d'autres définitions d'objets. Par définition incomplète, je veux dire que toutes les variables requises pour l'objet n'ont pas été mises dans la définition de l'objet. Celà peut paraître bizarre d'utiliser des définitions incomplètes comme gabarit, mais c'est en fait recommandé de les utiliser. Pourquoi? Et bien, ils servent d'ensemble par défaut afin d'être utilisés dans d'autres définitions d'objets. Regardez l'exemple suivant :

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
}
       

Notez que la 1er définition d'hotes est incomplète car il manque la variable requise host_name. Nous n'avons pas besoin de définir un nom d'hôte car nous voulons juste utiliser cette définition comme un gabarit d'hôte générique. Afin de prévenir cette defintion d'être registered par nagios comme un hôte normal, nous devons définir la variable register à 0.

La définition des hôtes bighost1 et bighost2 héritent leurs valeurs de la définition d'hôte générique. La seule variable que nous avons choisi de surcharger est la variable address. Celà veut dire que les deux hôtes auront exactement les mêmes propriétés, à l'exeption de leurs variables host_name et address. Une fois que Nagios aura traité les données de configuration de l'exemple, les définitions d'hôtes résultants seront la même chose que si nous spécifions :

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, utiliser une définition de gabarit pour les variables par défaut vous fera gagner beaucoup de temps. Cela vous évitera aussi beaucoup de maux de tête ultérieurs si vous voulez changer la valeur par défaut d'une variable pour un grand nombre d'hôtes.

Toutes les variables personnalisées d'objet que vous définisez dans vos définitions de gabarit d'hôtes, de services ou de contacts seront héritées comme n'importe quelle autre variable standard. Regardez l'exemple suivant :

define host {
    _customvar1         somevalue  ; <-- Custom host variable
    _snmp_community     public  ; <-- Custom host variable
    name                generichosttemplate
    register            0
}

define host {
    host_name           bighost1
    address             192.168.1.3
    use                 generichosthosttemplate
}
       

L'hôte bighost1 va hériter de la variable personnalisée de l'hôte _customvar1 et _snmp_community, aussi bien que de leur valeurs respectives de la définition du generichosttemplate. Le résultat effectif est une définition pourbighost1 qui ressemble à ça :

define host {
    host_name               bighost1
    address                 192.168.1.3
    _customvar1             somevalue
    _snmp_community         public
}