3 - Les dépendances
3 - Les dépendances Contact
Dans cette page :
Introduction
Comme nous l’avons vu précédemment, les dépendances permettent de limiter le nombre d’alertes reçues en cas de panne venant d’un système dont dépendent un ou plusieurs autres. Ainsi, par exemple, lors de la panne d’une switch, des alertes seront émises uniquement concernant la switch mais pas concernant tous les hôtes connectés à cette switch.
Nagios permet de mettre en place deux types de dépendances :
Les dépendances de services : un service sur un hôte dépend d’un autre service.
Les dépendances d’hôtes : un hôte dépend d’un autre hôte.
Les dépendances de service
Un service peut dépendre d’un ou plusieurs services sur le même hôte ou non.
define servicedependency{
host_name Host B
service_description Service D
dependent_host_name Host C
dependent_service_description Service F
execution_failure_criteria o
notification_failure_criteria w,u
}
define servicedependency{
host_name Host B
service_description Service E
dependent_host_name Host C
dependent_service_description Service F
execution_failure_criteria n
notification_failure_criteria w,u,c
}
define servicedependency{
host_name Host B
service_description Service C
dependent_host_name Host C
dependent_service_description Service F
execution_failure_criteria w
notification_failure_criteria c
}Description des variables
dependent_host : Cette variable est utilisée pour identifier le(s) nom(s) court(s) d’hôte sur lequel tourne le service dépendant ou avec lequel il est associé. Plusieurs hôtes peuvent être séparés par des virgules. Laissez cette variable vide peut être utilisé pour créer des dépendances sur le même hôte.
dependent_service_description : Cette variable est utilisée pour identifier la description d’un service dépendant.
host_name : Cette variable est utilisée pour identifier le(s) nom(s) court(s) d’hôte(s) sur lequel tourne le service dont on dépend (aussi appelé service maître) ou avec lequel il est associé. Plusieurs hôtes peuvent être séparés par des virgules.
service_description : Cette variable est utilisée pour identifier la description du service dont on dépend (aussi appelé service maître).
execution_failure_criteria : Cette variable est utilisée pour préciser les critères qui déterminent quand le service dépendant ne doit pas être contrôlé activement. Si le service maître est dans un état d’erreur que nous précisons, le service dépendant ne sera pas contrôlé activement. Les options valides sont une combinaison d’un ou de plusieurs des état suivants (les options multiples sont séparées par des virgules).
-
o= erreur sur état OK -
w= erreur sur état WARNING -
u= erreur sur état UNKNOWN -
c= erreur sur état CRITICAL -
p= erreur sur état d’attente (par exemple le service n’a pas encore été vérifié). -
n(none) : la dépendance d’exécution n’échouera jamais et les contrôles du service dépendant seront toujours faits activement (si d’autres conditions permettent de le faire). Si vous précisez o,c,u dans ce champ, le service dépendant ne sera pas contrôlé activement si le service maître est dans un des états OK, CRITICAL ou UNKNOWN.
notification_failure_criteria : Cette variable est utilisée pour définir les critères qui déterminent quand les notifications pour le service dépendant ne doivent pas être envoyées. Si le service maître est dans un des états d’erreur que nous précisons, les notifications pour le service dépendants ne seront pas envoyées aux contacts. Les options valides sont une combinaison d’un ou de plusieurs des état suivants :
-
o= erreur sur état OK -
w= erreur sur état WARNING -
u= erreur sur état UNKNOWN -
c= erreur sur état CRITICAL -
p= erreur sur état d’attente (par exemple le service n’a pas encore été vérifié). -
n(none) : la dépendance de notification n’échouera jamais et les notifications du service dépendant seront toujours envoyées.
Si vous précisez w dans ce champ, les notifications pour le service dépendant ne seront pas envoyées si le service maître est dans un état WARNING. dependency_period : Cette variable est utilisée pour préciser le nom court d’une période de temps pendant laquelle les dépendances sont valides. Si cette variable est vide, les dépendances seront considérées comme valides tout le temps.
Les dépendances d’hôtes
Deux solutions existent pour mettre en place les dépendances d’hôte :
Utiliser l’objet hostdependency
Utiliser la directive parents dans un objet host
L’objet hostdependency s’utilise de la même façon que les dépendances de service mais seules les notifications peuvent être supprimées, il n’y a pas d’équivalent aux vérifications d’exécution.
define hostdependency{
host_name Host A
dependent_host_name Host C
notification_failure_criteria d
}
define hostdependency{
host_name Host B
dependent_host_name Host C
notification_failure_criteria d,u
}Comme pour les services, si une des dépendances de l’hôte échoue, Icinga suspend temporairement les notifications concernant cet hôte.
La directive parent
La directive parents doit contenir le ou les hôte(s) dont dépend l’hôte configuré comme les switch, routeurs, firewall… Il s’agit d’une liste de noms courts (ils doivent avoir été définis comme hôtes dans d’autres objets).
define host{
host_name SWITCH01
alias Une switch
address 10.20.30.254
check_command check_ping
check_interval 5
retry_interval 1
max_check_attempts 5
check_period 24x7
contact_groups admin@bigshot.com
notification_interval 30
notification_period 24x7
}
define host{
host_name DNSSRV01
alias Le serveur DNS
address 10.20.30.40
check_command check_ping
parents SWITCH01
check_interval 5
retry_interval 1
max_check_attempts 5
check_period 24x7
contact_groups admin@bigshot.com
notification_interval 30
notification_period 24x7
} Lab 1
Pour configurer la dépendance des services, nous allons considérer que la console Icinga dépend du service DNS.
Vous aurez donc besoin d’une machine Linux avec Bind. La configuration par défaut sera suffisante, vous pouvez aussi utiliser une machine Windows avec le service DNS.
define host {
host_name nagios
alias L'hôte local Icinga
address 127.0.0.1
max_check_attempts 10
contacts admin
check_interval 1
notification_interval 10
notification_period 24x7
check_command check-host-alive
}
define host {
host_name DNS01
alias AD
address 192.168.230.230
max_check_attempts 10
contacts admin
check_interval 1
notification_interval 10
notification_period 24x7
check_command check-host-alive
}
define service{
host_name nagios
service_description icinga
check_command console-icinga
check_interval 1
retry_interval 1
max_check_attempts 5
check_period 24x7
contacts admin
notification_interval 1
notification_period 24x7
}
define service{
host_name ad
service_description dns
check_command requete-dns
check_interval 1
retry_interval 1
max_check_attempts 5
check_period 24x7
contacts admin
notification_interval 1
notification_period 24x7
}
define servicedependency{
host_name ad
service_description dns
dependent_host_name nagios
dependent_service_description icinga
execution_failure_criteria w,c,u
notification_failure_criteria w,c,u
} Lab 2
Pour configurer les dépendances d’hôtes :
Vous pouvez installer un routeur en utilisant une machine Windows 2008 R2 (voir procédure ci-dessous).
Créez un hôte dans Icinga pour cette machine.
Déplacez le serveur DNS sur l’autre patte du routeur (attention à changer l’adresse IP du serveur DNS dans la configuration icinga). Dans la configuration icinga du routeur, ajoutez une instruction « parents » contenant le nom de l’hôte routeur.
Configuration d’un routeur Windows 2008 R2 :
Créez une machine virtuelle avec deux cartes réseau chacune dans un réseau virtuel différent et suivez la procédure ci-dessous.
Répétez l’opération pour l’autre interface réseau.