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
}
        

Dans certains cas, vous ne voulez pas que votre défintion d'hôte, service ou contact hérite de la valeur d'une variable du gabarit qu'il référence. Dans ce cas, vous pouvez spécifier null (sans quotes) comme valeur pour cette variable. Regardez l'exemple suivant :

define host {
    event_handler           my-event-handler-command
    name                    generichosttemplate
    register                0
}

define host {
    host_name               bighost1
    address                 192.168.1.3
    event_handler           null
    use                     generichosthosttemplate
}
        

Dans ce cas, l'hôte bighost1 n'héritera pas de la valeur de la variable event_handler qui est définie dans generichosttemplate. Le résultat effectif de la définition de bighost1 est :

define host {
    host_name               bighost1
    address                 192.168.1.3
}
        

Nagios donne la préférence aux variables locales au lieu des valeurs héritées par leurs gabarits. Dans la pluspart des cas, les valeurs locales des variables surchargent celles définies dans les gabarits. Dans certains cas, il peut être judicieux d'autoriser Nagios d'utiliser la valeur locale et héritée de la variable ensemble.

Cet héritage additif peut être réalisé en rajoutant devant la valeur de la variable local un signe plus (+). Cette fonctionnalité est uniquement accessible pour les variables standards (non-personnels) qui contiennent des valeurs sous forme de chaîne. Regardez l'exemple suivant :

define host{
    hostgroups              all-servers
    name                    generichosttemplate
    register                0
}

define host {
    host_name               linuxserver1
    hostgroups              +linux-servers,web-servers
    use                     generichosthosttemplate
}
        

Dans ce cas, l'hôte linuxserver1 va ajouter la valeur de sa variable hostgroups local, à celui du generichosttemplate. Le résultat effectif de la définition de linuxserver1 est le suivant :

define host {
    host_name       linuxserver1
    hostgroups      all-servers,linux-servers,web-servers
}
        

Normalement vous devez soit explicitement spécifier la valeur de la variable dans la définition d'un objet, ou bien l'hériter d'un gabarit. Il existe quelques exceptions à cette règle, où Nagios assumera que vous voulez utiliser une valeur qui vient en fait d'un objet lié. Par exemple, la valeur de certaines variables de service vont être copiées de l'hôte auquel le service est associé si vous ne lui spécifiez pas le contraire.

Les tableaux suivants listent les variables d'objet qui seront implicitement héritées par des objets liés, si vous spécifiez pas explicitement leurs valeurs dans votre définition d'objet ou dans son gabarit.

La superposition de défintion d'hôte et de service peuvent utiliser une règle spéciale qui combine les fonctionnalités de l'héritage implicite et explicite. Si la superposition 1) n'hérite pas la valeurs de leurs paramètres contact_groups ou contacts d'un autre gabarit et 2) leurs paramètres contact_groups ou contacts commencent avec un signe (+), alors les valeurs des paramètres contact_groups ou contacts de leurs défintions d'hôte ou service seront utilisées avec une logique d'héritage additive.

Perdu ? Voici un exemple :

define host {
    name            linux-server
    contact_groups  linux-admins
    ...
}

define hostescalation {
    host_name       linux-server
    contact_groups  +management
    ...
}
        

C'est un équivalent beaucoup plus simple que :

define hostescalation {
    host_name       linux-server
    contact_groups  linux-admins,management
    ...
}
        

Jusqu'à maintenant, tous les exemples d'héritage présentaient l'héritage de variables/valeurs à partir d'une seule source. Vous pouvez aussi hériter des variables/valeurs de sources multiples pour réaliser des configurations plus complexes, comme cela est présenté ci-dessous.

#Generic host template
define host {
    name                    generic-host
    active_checks_enabled   1
    check_interval          10
     ...
    register                0
}

# Development web server template
define host {
    name                    development-server       
    check_interval          15  
    notification_options    d,u,r
    ...
    register                0    
}

# Development web server
define host {
    use                     generic-host,development-server
    host_name               devweb1
    ...     
}
                            

Dans l'exemple ci-dessous, devweb1 hérite de variables/valeurs provenant de deux sources : generic-host et development-server. Vous noterez qu'une variable check_interval est définie dans les deux sources. Puisque generic-host était le premier gabarit spécifié dans les paramètres de devweb1, sa valeur pour la variable check_interval est héritée par l'hôte devweb1. Après l'héritage, la définition effective de devweb1 est la suivante :

# Development web server

define host {
    host_name               devweb1
    active_checks_enabled   1
    check_interval          10
    notification_options    d,u,r
    ...
}
        

Quand vous utilisez de multiples sources d'héritage, il est très important de savoir comment Nagios gère les variables qui sont définies dans ces sources multiples. Dans ces cas, Nagios utilisera les variables/valeurs de la première source qui est spécifiée dans le paramètre à utiliser. Puisque les sources d'héritage peuvent elles-même hériter de variables/valeurs provement d'une ou plusieurs sources, il peut devenir très compliqué de trouver quelle paire de variable/valeur aura la priorité.

# Development web server
define host {
    use         1, 4, 8
    host_name   devweb1
    ...
}