Options du fichier de configuration des hôtes

Options du fichier de configuration par défaut des objets,

(ancien format)

Important: Nagios peut être configuré avec différentes méthodes, en ce qui concerne le format des fichiers de configuration des objets, en fournissant des arguments au script configure. Cette documentation décrit comment configurer ces définitions d'objets si vous avez compilé Nagios pour supporter l'ancien format des objets. (c.a.d avec l'option --with-default-objects du script configure). Notez, svp, que ce format est fourni uniquement pour des raisons de compatibilité avec les anciennes versions. Il n'offre ni la flexibilité, ni la lisibilité des fichiers à base de modèles. Je vous suggère fortement (et amicalement) de considérer le passage à ce type de fichier, puisqu'ils seront les standards utilisés désormais et dans le futur.

Notes

Quand vous créez ou modifiez des fichiers de configuration, n'oubliez pas que :

Les lignes qui commencent avec le caractère '#' sont considérées comme des commentaires et ne sont donc pas traitées
Les noms des variables doivent commencer au début de la ligne - ne mettez pas d'espace avant le nom
Les noms des variables respectent la casse (majuscule/minuscule)

Index

Définition d'hôte
Définition de groupe d'hôtes
Définition de contact
Définition de groupe de contacts
Définition de commande
Définition de service
Définition de période
Défintion d'escalade pour un service
Définition d'escalade pour un groupe d'hôtes
Définition des dépendances du service

Définition d'hôte

Format : host[<host_name>]=<host_alias>;<address>;<parent_hosts>;<host_check_command>;<max_attempts>;<notification_interval>;<notification_period>;<notify_recovery>;<notify_down>;<notify_unreachable>;<event_handler>

Exemple : host[novell1]=Novell Server #1;192.168.0.1;;check-host-alive;3;120;24x7;1;1;1;

Une définition d'hôte permet de déclarer physiquement un serveur, une station, un périphérique, etc. qui.est connecté à votre réseau. Les arguments de cette définition sont décrits ci-dessous.

<host_name> C'est le nom court qui permet d'identifier l'hôte. Il est utilisé dans les groupes d'hôtes et les définitions de service pour faire référence à cet hôte particulier. Les hôtes peuvent être associés à de multiples services (qui sont supervisés). Si elle est utilisée dans le bon contexte, la macro $HOSTNAME$ contient ce nom court.

<host_alias> C'est un nom long ou une description de l'hôte permettant de l'identifier plus facilement. Si elle est utilisée dans le bon contexte, la macro $HOSTALIAS$ contient cet alias/description.

<address> C'est l'adresse IP de l'hôte. Vous pouvez utiliser un FQDN [Fully Qualified Domain Name, nom de domaine complet] pour identifier l'hôte, mais si le service DNS n'est pas actif, cela peut poser des problèmes. Si elle est utilisée dans le bon contexte, la macro $HOSTADDRESS$ contient cette adresse.

<parent_hosts> C'est une liste d'hôtes "parents" de cet hôte, séparés par des virgules. Les hôtes parents sont généralement des routeurs, des commutateurs, des firewalls, etc. se trouvant entre l'hôte de supervision et les hôtes distants. Le routeur, le commutateur, etc. le plus proche de l'hôte distant est considéré comme le parent de cette hôte. Pour plus d'informations, référez-vous au chapitre "Determiner l'état et l'accessibilité des hôtes du réseau" dans ce document ci. Si cet hôte est sur le même segment que l'hôte de supervision (sans routeur intermédiaire, etc.) il est considéré comme étant sur le réseau local et n'aura pas d'hôte parent. Laissez cette valeur vide si l'hôte n'a pas d'hôte parent (i.e. si il est sur le même segment que l'hôte de Nagios). L'ordre dans lequel vous déclarez les parents n'a pas d'influence sur la façon dont la supervision se déroule.

<host_check_command>
C'est le nom court de la commande à utiliser pour déterminer si l'hôte est hors service ou non. Typiquement, cette commande lance un "ping" vers l'hôte pour voir si il est "vivant". La commande doit retourner un état OK (0) sinon Nagios supposera que cet hôte est hors service. Si vous laissez cet argument vide, l'hôte ne sera pas contrôlé - Nagios supposera que l'hôte est toujours en fonctionnement. Ceci est utile pour superviser des imprimantes ou autres périphériques qui sont éteints fréquemment. Le temps d'exécution maximal de cette commande est déterminé par la variable host_check_timeout.

<max_attempts> C'est le nombre de fois que Nagios relancera la commande de contrôle de l'hôte si celle-ci retourne un état différent de OK. Positionner cette valeur à 1 fera que Nagios générera une alerte sans re-contrôler l'hôte. Note : si vous ne voulez pas contrôler l'état de l'hôte, vous devez quand même mettre une valeur supérieure ou égale à 1. Pour ne pas effectuer le contrôle de l'hôte, laissez simplement vide l'option <host_check_command>.

<notification_interval> C'est le nombre d'"unités de temps" à patienter avant de re-notifier un contact que l'hôte est toujours hors service ou inaccessible. Si vous n'avez pas modifié la valeur par défaut de la variable interval_length dans le fichier de configuration principal, qui est de 60, ce nombre exprime des minutes. Si vous mettez cette valeur à 0, Nagios ne re-notifiera pas les contacts à propos des problèmes de cet hôte - une seule notification sera émise.

<notification_period> C'est le nom court de la période durant laquelle les notifications d'événements concernant cet hôte peuvent être émises vers les contacts. Si un hôte est hors service, inaccessible, ou se rétablit en dehors de la période de notification, aucune notification ne sera envoyée. Pour plus d'informations, vous pouvez lire le chapitre sur les "Périodes de temps" dans ce document ci

<notify_recovery> Cette valeur détermine si des notifications doivent être envoyées aux contacts quand l'hôte est dans un état RECOVERY. Donnez une valeur de 1 si les notifications doivent être envoyées, 0 sinon. Note : un contact configuré pour ne pas recevoir de notifications du rétablissement des hôtes sera malgré tout notifié si ce paramètre est à 1.

<notify_down> Cette valeur détermine si des notifications doivent être envoyées aux contacts quand l'hôte est dans un état DOWN. Donnez une valeur de 1 si les notifications doivent être envoyées, 0 sinon. Note : un contact configuré pour ne pas recevoir de notifications d'hôtes hors service sera malgré tout notifié si ce paramètre est à 1.

<notify_unreachable> Cette valeur détermine si des notifications doivent être envoyées aux contacts quand l'hôte est dans un état UNREACHABLE. Donnez une valeur de 1 si les notifications doivent être envoyées, 0 sinon. Note : un contact configuré pour ne pas recevoir de notifications d'inaccessibilité des hôtes sera malgré tout notifié si ce paramètre est à 1.

<event_handler> C'est le nom court de la commande à lancer à chaque fois qu'un changement de l'état de l'hôte est détecté (i.e. chaque fois qu'il est hors service ou qu'il se rétablit). Lisez la documentation sur les gestionnaires d'événement pour des explications détaillées sur la façon d'écrire des scripts de gestion d'événements. Si vous ne souhaitez pas définir de gestionnaire d'événements pour cet hôte, laissez cette option vide (comme le montre l'exemple ci-dessus). Le temps d'exécution maximal de cette commande est déterminé par la variable event_handler_timeout.

Définition de groupe d'hôtes

Format : hostgroup[<nom_groupe>]=<alias_groupe>;<groupes_contacts>;<hôtes>

Exemple : hostgroup[nt-servers]=All NT Servers;nt-admins;nt1,nt2,nt3

Une définition de groupe d'hôtes permet de regrouper un ou plusieurs hôtes pour simplifier les notifications. Chaque hôte que vous définissez doit être membre d'au moins un groupe d'hôtes - même si c'est le seul hôte du groupe. Un hôte peut faire partie de plusieurs groupes. Quand un hôte est hors service, inaccessible, ou se rétablit, Nagios recherche les groupes dont cet hôte fait partie, en extrait chaque groupe de contacts, et notifie tous les contacts associés à ces groupes de contacts. Ceci peut sembler complexe, mais dans la plupart des cas, ce ne le sera pas. On obtient ainsi une meilleure flexibilité, nécessaire à la définition de qui re�oit la notification de quel problème. Les différents arguments d'une définition de groupe d'hôtes sont détaillés ci-dessous.

<nom_groupe> C'est le nom court qui identifie le groupe d'hôtes

<alias_groupe> C'est un nom long ou une description permettant d'identifier plus facilement le groupe d'hôtes.

<groupes_contacts> C'est une liste de noms courts de groupes de contacts à notifier en cas de problème (ou de rétablissement) concernant un hôte quelconque de ce groupe. Les groupes de contacts sont séparés par des virgules.

<hôtes> C'est une liste de noms courts d'hôtes à inclure dans ce groupe. Les noms sont séparés par des virgules.

Définition de contact

Format : contact[<contact_name>]=<alias_name>;<svc_notification_period>;<host_notification_period>;<svc_notify_recovery>;<svc_notify_critical>;<svc_notify_warning>;<host_notify_recovery>;<host_notify_down>;<host_notify_unreachable>;<service_notify_commands>;<host_notify_commands>;<email_address>;<pager>

Exemple : contact[nagiosadmin]=Nagios Administrator;24x7;24x7;1;1;1;1;1;1;notify-by-email,notify-by-epager;host-notify-by-epager;nagiosadmin@localhost.localdomain;adminpager@pagenet.com

Une définition de contact permet d'identifier quelqu'un qui doit être contacté lors de problèmes sur votre réseau. Les différents arguments d'une définition de contact sont détaillés ci-dessous.

<contact_name> C'est le nom court identifiant le contact. Il est utilisé dans les définitions de groupes de contacts. Si elle est utilisée dans le bon contexte, la macro $CONTACTNAME$ contient cette valeur.

<alias_name> C'est un nom long ou une description du contact. Si elle est utilisée dans le bon contexte, la macro $CONTACTALIAS$ contient cette valeur.

<svc_notification_period> C'est le nom court de la période durant laquelle le contact peut être notifié de problèmes ou de rétablissement de services. Pour plus d'informations, vous pouvez lire le chapitre sur les "Périodes de temps" dans le document principes de fonctionnement, qui décrit comment elles fonctionnent et quels sont les problèmes qui peuvent découler d'une utilisation incorrecte.

<host_notification_period> C'est le nom court de la période durant laquelle le contact peut être notifié de problèmes ou de rétablissement d'hôtes. Pour plus d'informations, vous pouvez lire le chapitre sur les "Périodes de temps" dans le document principes de fonctionnement, qui décrit comment elles fonctionnent et quels sont les problèmes qui peuvent découler d'une utilisation incorrecte.

<svc_notify_recovery> Cette valeur détermine si le contact doit être notifié du rétablissement d'un service. Donnez une valeur de 1 si le contact doit être notifié, 0 sinon. Note : si un service est configuré pour ne pas émettre de notification lors du rétablissement, le contact ne sera pas notifié même si ce paramétre est à 1.

<svc_notify_critical> Cette valeur détermine si le contact doit être notifié qu'un service est en état critical. Donnez une valeur de 1 si le contact doit être notifié, 0 sinon. Note : si un service est configuré pour ne pas émettre de notification au passage en état critical, le contact ne sera pas notifié même si ce paramétre est à 1.

<svc_notify_warning> Cette valeur détermine si le contact doit être notifié qu'un service est en état warning ou unknown. Donnez une valeur de 1 si le contact doit être notifié, 0 sinon. Note : si un service est configuré pour ne pas émettre de notification au passage en état warning/unknown, le contact ne sera pas notifié même si ce paramétre est à 1.

<host_notify_recovery> Cette valeur détermine si le contact doit être notifié qu'un hôte se rétablit. Donnez une valeur de 1 si le contact doit être notifié, 0 sinon. Note : si un hôte est configuré pour ne pas émettre de notification au rétablissement, le contact ne sera pas notifié même si ce paramétre est à 1.

<host_notify_down> Cette valeur détermine si le contact doit être notifié qu'un hôte passe en état down. Donnez une valeur de 1 si le contact doit être notifié, 0 sinon. Note : si un hôte est configuré pour ne pas émettre de notification au passage en état down, le contact ne sera pas notifié même si ce paramétre est à 1.

<host_notify_unreachable> Cette valeur détermine si le contact doit être notifié qu'un hôte devient inaccessible. Donnez une valeur de 1 si le contact doit être notifié, 0 sinon. Note : si un hôte est configuré pour ne pas émettre de notification lorsqu'il est inaccessible, le contact ne sera pas notifié même si ce paramétre est à 1.

<service_notify_commands> C'est une liste de noms courts de commandes à utiliser pour notifier d'un problème ou du rétablissement d'un service. Les commandes de notification multiples sont séparées par des virgules. Toutes les commandes de notification sont exécutées lorsque le contact doit être notifié. Le temps d'exécution maximal de cette commande est déterminé par la variable notification_timeout.

<host_notify_commands> C'est une liste de noms courts de commandes à utiliser pour notifier d'un problème ou du rétablissement d'un hôte. Les commandes de notification multiples sont séparées par des virgules. Toutes les commandes de notification sont exécutées lorsque le contact doit être notifié. Le temps d'exécution maximal de cette commande est déterminé par la variable notification_timeout.

<email_address> C'est l'adresse email du contact. Elle peut être utilisée dans les commandes de notification pour émettre un email, grâce à la macro $CONTACTEMAIL$ qui contient cette valeur.

<pager> C'est le numéro de pager du contact. Cela peut aussi être l'address email d'une passerelle vers un pager (i.e. pagejoe@pagenet.com). Il peut être utilisé dans les commandes de notification pour émettre un message vers un pager, grâce à la macro $CONTACTPAGER$ qui contient cette valeur.

Définition de groupe de contacts

Format : contactgroup[<group_name>]=<group_alias>;<contacts>

Exemple : contactgroup[nt-admins]=NT Administrators;bbarker,jdoe

Une définition de groupe de contacts permet de regrouper un ou plusieurs contacts pour émettre des notifications. Quand un hôte ou un service a un problème ou se rétablit, Nagios recherche les groupes de contacts à qui envoyer des notifications, et notifie tous les contacts de ces groupes. Ceci peut sembler complexe, mais dans la plupart des cas, ce ne le sera pas. On obtient ainsi une meilleure flexibilité dans la définition de qui est notifié de quel problème. Les différents arguments d'une définition de groupe de contacts sont détaillés ci-dessous.

<group_name> C'est le nom court utilisé pour identifer le groupe de contacts.

<group_alias> C'est le nom long ou la description de ce groupe de contacts.

<contacts> C'est une liste de noms courts de contacts faisant partie de ce groupe. Les noms sont séparés par des virgules.

Définition de commande

Format : command[<command_name>]=<command_line>

Exemple 1 : command[check-host-alive]=/usr/local/nagios/libexec/check_ping -H $HOSTADDRESS$ -w 1000.0,40% -c 2000.0,80%

Exemple 2 : command[check_pop]=/usr/local/nagios/libexec/check_pop -H $HOSTADDRESS$

Exemple 3 : command[check_local_disk]=/usr/local/nagios/libexec/check_disk -w 20% -c 10% -p $ARG1$

Une définition de commande, comme son nom l'indique, définit une commande. Les commandes qu'on peut définir sont les contrôles de service, les notifications de service, les gestionnaires d'événements de service, les contrôles d'hôte, les notifications d'hôte, et les gestionnaires d'événement d'hôte. Les définitions de commande peuvent contenir des macros, mais vous devez vous assurer de n'utiliser que des macros "valides" dans le contexte de la commande. Vous trouverez plus d'informations sur le domaine de validité des macros ici. Les différents arguments d'une définition de commande sont détaillés ci-dessous.

<command_name> C'est le nom court identifiant la commande. Il est utilisé dans les définitions de contact, d'hôte, et de service.

<command_line> C'est ce qu'exécute Nagios lorsque la commande est utilisée pour un contrôle de service ou d'hôte, pour une notification, ou pour un gestionnaire d'événement. Avant que la ligne de commande ne soit exécutée, toutes les macros valides sont remplacées par leur valeur. Référez-vous à la documentation sur les macros pour savoir quand elles sont valides. Notez que la ligne de commande n'est pas entourée de guillemets.

Définition de service

Format : service[<host>]=<description>;<volatile>;<check_period>;<max_attempts>;<check_interval>;<retry_interval>;<contact_groups>;<notification_interval>;<notification_period>;<notify_recovery>;<notify_critical>;<notify_warning>;<event_handler>;<check_command>

Exemple 1 : service[nt1]=FTP;0;24x7;3;5;1;nt-admins;120;24x7;1;1;1;;check_ftp

Exemple 2 : service[nt1]=HTTP;0;24x7;3;5;1;nt-admins;240;24x7;1;1;1;;check_http2!192.168.0.2!/!88

Exemple 3 : service[linux1]=Zombie Processes;0;24x7;3;5;1;linux-admins;240;24x7;1;1;1;;check_local_procs!5!10!Z

Une définition de service identifie un "service" qui tourne sur un hôte. Le terme "service" est très général. Il peut désigner réellement un service de l'hôte (POP, SMTP, HTTP, etc.) ou tout autre type de mesure de l'hôte (réponse à un ping, nombre d'utilisateurs connecté, espace disque restant, etc.). Les différents arguments d'une définition de service sont détaillés ci-dessous.

<host>

C'est le nom court de l'hôte sur lequel "tourne" le service ou avec lequel il est associé.

<description>

Une description du service qui peut contenir des espaces, tirets, et deux-points (points-virgules, apostrophes, et guillemets sont à éviter). Deux services associés au même hôte ne peuvent pas avoir la même description.

<volatile>

Cette variable détermine si le service est "volatil". Normalement, les services ne le sont pas. Vous trouverez plus d'information sur les services volatils et ce en quoi ils diffèrent des services normaux ici. Donnez une valeur de 1 pour désigner ce service comme volatil, 0 pour le désigner comme normal.

<check_period>

C'est le nom court de la période pendant laquelle le service doit être contrôlé. Les contrôles de services sont ordonnancés de façons à ce qu'ils ne soient contrôlés (ou recontrôlés) que durant cette période. Pour plus d'informations, vous pouvez lire le chapitre sur les "Périodes de temps" dans ce document ci, qui décrit comment elles fonctionnent et quels sont les problèmes qui peuvent découler d'une utilisation incorrecte.

<max_attempts>

C'est le nombre de fois que Nagios réessaiera de contrôler le service si celui-ci retourne un état différent de OK. Si vous donnez une valeur de 1 à cette variable, Nagios générera une alerte (si le contrôle de service a détecté un problème) sans nouvel essai. Pour plus d'informations sur cette valeur, voyez la documentation sur l'ordonnancement du contrôle des services.

<check_interval>

C'est le nombre d'"unités de temps" à attendre avant d'ordonnancer le prochain contrôle "regulier" du service. Les contrôles "reguliers" sont ceux qui se font lorsque le service est en état OK ou lorsque le service n'est pas en état OK, mais que le nombre de réessais défini par la variable max_attempts est atteint. Si vous n'avez pas changé la valeur de interval_length dans le fichier de configuration principal qui est par défaut de 60, ce nombre exprime des minutes. Pour plus d'informations sur cette valeur, voyez la documentation sur l'ordonnancement du contrôle des services.

<retry_interval>

C'est le nombre d'"unités de temps" à attendre avant d'ordonnancer le prochain contrôle du service. Les services sont réordonnancés à cet intervalle quand ils sont passés dans un état différent de OK. Une fois que le contrôle de service a été tenté max_attempts fois sans changement d'état, il est réordonnancé à nouveau à sa fréquence "normale" définie par la valeur de check_interval. Si vous n'avez pas changé la valeur de interval_length dans le fichier de configuration principal qui est par défaut de 60, ce nombre exprime des minutes. Pour plus d'informations sur cette valeur, voyez la documentation sur l'ordonnancement du contrôle des services.

<contact_groups>

C'est une liste de groupes de contacts, séparés par des virgules, qui doivent être notifiés des problèmes ou rétablissements de ce service. Lorsqu'un problème ou un rétablissement survient pour ce service, Nagios essaie de notifier tous les contacts de tous les groupes de contacts (en fonction des options de notifications décrites ci-dessous).

<notification_interval>

C'est le nombre d'"unités de temps" à attendre avant de renotifier un contact que ce service est toujours dans un état différent de OK. Si vous n'avez pas changé la valeur de interval_length dans le fichier de configuration principal qui est par défaut de 60, ce nombre exprime des minutes. Si vous donnez une valeur de 0, Nagios ne renotifiera pas les contacts des problèmes de ce service - une seule notification sera émise.

<notification_period>

C'est le nom court de la période qui détermine quand les notifications au sujet des problèmes ou des rétablissements de ce service peuvent être envoyées. Si un problème ou un rétablissement de ce service survient en dehors des heures comprises dans cette période, les notifications ne seront pas émises. Pour plus d'informations, vous pouvez lire le chapitre sur les "Périodes de temps" dans le document là, qui décrit comment elles fonctionnent et quels sont les problèmes qui peuvent découler d'une utilisation incorrecte.

<notify_recovery>

Cette valeur détermine si des notifications d'alerte seront émises lorsque le service se rétablit. Donnez une valeur de 1 si ce service doit générer des alertes lors du rétablissement, 0 sinon. Note : si un contact est configuré pour ne pas recevoir de notifications de rétablissement, il ne sera pas notifié des rétablissement de ce service, même si ce paramètre est à 1.

<notify_critical>

Cette valeur détermine si des notifications d'alerte seront émises lorsque le service est en état CRITICAL. Donnez une valeur de 1 si ce service doit générer des alertes lors du passage en état critical, 0 sinon. Note : si un contact est configuré pour ne pas recevoir de notifications d'état critical, il ne sera pas notifié du passage dans cet état de ce service, même si ce paramètre est à 1.

<notify_warning>

Cette valeur détermine si des notifications d'alerte seront émises lorsque le service est en état WARNING ou UNKNOWN. Donnez une valeur de 1 si ce service doit générer des alertes lors du passage en état warning/unknown, 0 sinon. Note : si un contact est configuré pour ne pas recevoir de notifications d'état warning/unknown, il ne sera pas notifié du passage dans cet état de ce service, même si ce paramètre est à 1.

<event_handler>

C'est le nom court de la commande qui doit être lancée à chaque changement d'état du service (i.e. chaque fois qu'il est hors service ou se rétablit). Lisez la documentation sur les gestionnaires d'événement pour des explications détaillées sur la façon d'écrire des scripts de gestion d'événements. Si vous ne souhaitez pas définir de gestionnaire d'événements pour cet hôte, laissez cette option vide (comme le montre l'exemple ci-dessus). Le temps d'exécution maximal de cette commande est déterminé par la variable event_handler_timeout.

<check_command>

C'est la commande que Nagios exécute pour contrôler l'état du service. Il y a trois types de commande possibles :

1. Basique [Vanilla] : Le nom de la commande est simplement le nom d'une commande définie précédemment. L'exemple 1 ci-dessus est une commande de ce type.

2. Avec arguments :
C'est une commande de type basique, mais dont les arguments sont séparés par le caractère !. L'exemple 2 ci-dessus est une commande de ce type. Les arguments sont séparés du nom de la commande (et des autres arguments) par le caractère !. La commande doit être définie de manière à utiliser les macros $ARGx$. Dans l'exemple 2, $ARG1$ vaut 192.168.0.2, $ARG2$ vaut /, et $ARG3$ vaut 88 dans le cadre de ce service. Note : Nagios ne gère que seize arguments au plus (de $ARG1$ à $ARG16$).

3. Crue [Raw] : Vous pouvez aussi donner une commande telle qu'elle doit être exécutée. Pour ce faire, toute la commande doit être entourée de guillemets. La paire de guillemets les plus englobants sera supprimée avant exécution. Il n'y a aucun remplacement de macros dans ce cas..

Le temps d'exécution maximal de cette commande est déterminé par la variable service_check_timeout.

Définition de période

Format : timeperiod[<timeperiod_name>]=<timeperiod_alias>;<sunday_ranges>;<monday_ranges>;<tuesday_ranges>;<wednesday_ranges>;<thursday_ranges>;<friday_ranges>;<saturday_ranges>;

Exemple 1 : timeperiod[24x7]=All Day, Every Day;00:00-24:00;00:00-24:00;00:00-24:00;00:00-24:00;00:00-24:00;00:00-24:00;00:00-24:00

Exemple 2 : timeperiod[workhours]="Normal" Working Hours;;09:00-17:00;09:00-17:00;09:00-17:00;09:00-17:00;09:00-17:00;

Exemple 3 : timeperiod[none]=No Time Is A Good Time;;;;;;;

Exemple 4: timeperiod[nonworkhours]=Non-Work Hours;00:00-24:00;00:00-09:00,17:00-24:00;00:00-09:00,17:00-24:00;00:00-09:00,17:00-24:00;00:00-09:00,17:00-24:00;00:00-09:00,17:00-24:00;00:00-24:00

Une période est une liste de tranches horaires pour les différents jours de la semaine, qui sont "valides" pour les notifications et les contrôles de service. Elles consistent en une ou plusieurs périodes de temps pour chaque jour de la semaine, qui "tournent" à la fin de la semaine. On ne peut pas définir d'exception à la définition hebdomadaire.

<timeperiod_name> C'est le nom court identifiant la période.

<timeperiod_alias> C'est un nom long ou une description de la période.

<xday_ranges> C'est une liste de tranches horaires séparées par des point-virgules, qui sont "valides" pour un jour donné de la semaine. Notez que vous devez définir des tranches horaires pour les sept jours de la semaine (de dimanche à samedi). Les tranches horaires sont au format HH:MM-HH:MM, où les heures sont indiquées entre 0 et 24. Par exemple, 00:15-24:00 veut dire de z�ro heure quinze ce jour jusqu'à minuit (une tranche de 23 heures et 45 minutes). Si vous laissez une tranche vide pour un jour de la semaine, cela signifie qu'aucune heure n'est valide ce jour-là.

Définition d'escalade pour un service

Format : serviceescalation[<host>;<description>]=<first_notification>-<last_notificiation>;<contact_groups>;<notification_interval>

Exemples: serviceescalation[linux1;Zombie Processes]=3-5;linux-admins,managers;0
serviceescalation[nt1;HTTP]=6-0;nt-admins,managers,everyone;30

Une définition d'escalade pour un service est complètement optionelle et est utilisée pour escalader les notifications liées à un service particulier. Vous trouverez plus d'informations sur le fonctionnement de l'escalade ici.

<host> C'est le nom court de l'hôte sur lequel le service "tourne" ou auquel il est associé.

<description> Une description du service, qui peut contenir des espaces, tirets, et deux-points (points-virgules, parenthèses, et apostrophes ne sont pas autorisés). Deux services associés au même hôte ne peuvent pas avoir la même description.

<first_notification> C'est un nombre qui désigne la première notification à partir de laquelle cette escalade est effective. Par exemple, si vous mettez cette valeur à 3, cette escalade ne sera lancée que lorsque le service sera dans un état différent de OK depuis trois notifications.

<last_notification> C'est le nombre qui désigne la dernière notification avant que cette escalade ne soit plus effective. Par exemple, si vous mettez une valeur de 5, cette escalade ne sera pas utilisée si plus de cinq notifications ont été envoyées pour le service spécifié. Donner une valeur de 0 revient à utiliser éternellement cette escalade (sans tenir compte du nombre de notifications émises).

<contact_groups> C'est une liste de noms courts de groupes de contacts à notifier quand une escalade a lieu pour ce service. Les groupes de contatcs sont séparés par des virgules.

<notification_interval> Intervalle auquel les notifications doivent être faites quand cette escalade s'applique. Si vous donnez une valeur de 0 à cet intervalle, Nagios enverra la première notification lorsque cette définition d'escalade est valide, mais arrêtera ensuite toute émission de notifications pour l'hôte. Les notifications ne sont plus envoyées jusqu'à ce que le service se rétablisse. Ceci est utile si vous ne voulez plus de notifications après un certain temps. Note : si pour un même service plusieurs définitions d'escalade ont des plages de notifications qui se chevauchent , c'est l'intervalle de notification le plus petit qui est retenu.

Définition d'escalade pour un groupe d'hôtes

Format : hostgroupescalation[<group_name>]=<first_notification>-<last_notificiation>;<contact_groups>;<notification_interval>

Exemples: hostgroupescalation[nt-servers]=3-5;nt-admins,managers;0
hostgroupescalation[nt-servers]=6-0;nt-admins,managers,everyone;60

Une définition d'escalade pour un groupe d'hôtes est complètement optionelle et est utilisée pour escalader les notifications liées aux hôtes d'un groupe d'hôtes donné. Vous trouverez plus d'informations sur le fonctionnement de l'escalade ici.

<group_name> C'est le nom court du groupe d'hôtes (tel que précédemment donné dans une définition de groupe d'hôtes) auquel s'applique l'escalade.

<first_notification> C'est un nombre qui désigne la première notification à partir de laquelle cette escalade est effective. Par exemple, si vous mettez cette valeur à 3, cette escalade ne sera lancée que lorsqu'un hôte du groupe sera dans un état différent de OK depuis trois notifications.

<last_notificiation> C'est le nombre qui désigne la dernière notification avant que cette escalade ne soit plus effective. Par exemple, si vous mettez une valeur de 5, cette escalade ne sera pas utilisée si plus de cinq notifications ont été envoyées pour un hôte du groupe spécifié. Donner une valeur de 0 revient à utiliser éternellement cette escalade (sans tenir compte du nombre de notifications émises).

<contact_groups> C'est une liste de noms courts de groupes de contacts à notifier quand une escalade a lieu pour un hôte de ce groupe. Les groupes de contacts sont séparés par des virgules.

<notification_interval> Intervalle avec lequel les notifications doivent être faites quand cette escalade s'applique. Si vous donnez une valeur de 0 à cet intervalle, Nagios enverra la première notification lorsque cette définition d'escalade est valide, mais arrêtera ensuite toute émission de notifications pour l'hôte. Les notifications ne sont plus envoyées jusqu'à ce que le service se rétablisse. Ceci est utile si vous ne voulez plus de notifications après un certain temps. Note : si pour un même groupe d'hôtes plusieurs définitions d'escalade ont des plages de notifications qui se chevauchent , c'est l'intervalle de notification le plus petit qui est retenu.

Définition des dépendances du service

Format : servicedepency[<dependent_host>;<dependent_description>]=<host>;<description>;<execution_failure_options>;<notification_failure_options>

Exemples : servicedependency[nt1;WWW1 Website]=nt1;HTTP;;wc
servicedependency[nt1;WWW2 Website]=nt1;HTTP;wcu;wcu
servicedependency[nt1;WWW2 Website]=nt2;SQL Server;c;

Les défintions de dépendances du service sont totalement facultatives. Elles sont utilisées pour contrôler à la fois l'exécution des services et les notifications des services en se basant sur l'état des autres services supervisés. Les dépendances de services sont principalement destinées aux utilisateurs avertis qui ont des configuration de supervision complexes. Pour plus d'informations sur le fonctionnement des dépendances de service (lisez le !) lisez ceci.

<dependent_host> Nom court de l'hôte sur lequel le service dépendant tourne ou qui lui est associé.

<dependent_description> Description du service dépendant.

<host> Nom court de l'hôte sur lequel le service dont nous dépendons tourne ou qui lui est associé.

<description> Description du service dont nous dépendons.

<execution_failure_options> Ces variables sont utilisées pour définir les situations dans lesquelles le service dépendant ne doit pas être en exécution. Si le service dont nous dépendons est dans un des états d'erreur spécifié, le service dépendant n'est pas en exécution. Les valeurs valides sont les combinaisons de un ou plusieurs de ces états : o = non exécuté si état OK, w = non exécuté si état WARNING , u = non exécuté si état UNKNOWN, et c = non exécuté si état CRITICAL. Par exemple, si vous spécifiez ocu dans cette variable, la dépendance est en erreur si le service dont nous dépendons est dans un des états OK, CRITICAL, ou UNKNOWN et que le service dépendant n'est pas en exécution. Vous n'avez pas à spécifier d'option d'erreur dans ce champ.

<notification_failure_options> Ces variables sont utilisées pour définir les situations dans lesquelles les notifications pour le service dépendant ne doivent pas être envoyées. Si le service dont nous dépendons est dans l'un des états d'erreur spécifiés, les notifications pour le service dépendant ne seront pas envoyées aux contacts. Les valeurs valides sont les combinaisons de un ou plusieurs de ces états : o = non exécuté si état OK, w = non exécuté si état WARNING , u = non exécuté si état UNKNOWN, et c = non exécuté si état CRITICAL. Par exemple, si vous spécifiez w dans ce champ, la dépendance est en erreur si le service dont nous dépendons est dans l'état WARNING et les notifications pour le service dépendant ne seront pas envoyées. Vous n'avez pas à spécifier d'option d'erreur dans ce champ.

Format :	host[<host_name>]=<host_alias>;<address>;<parent_hosts>;<host_check_command>;<max_attempts>;<notification_interval>;<notification_period>;<notify_recovery>;<notify_down>;<notify_unreachable>;<event_handler>
Exemple :	host[novell1]=Novell Server #1;192.168.0.1;;check-host-alive;3;120;24x7;1;1;1;

<host_name>	C'est le nom court qui permet d'identifier l'hôte. Il est utilisé dans les groupes d'hôtes et les définitions de service pour faire référence à cet hôte particulier. Les hôtes peuvent être associés à de multiples services (qui sont supervisés). Si elle est utilisée dans le bon contexte, la macro $HOSTNAME$ contient ce nom court.
<host_alias>	C'est un nom long ou une description de l'hôte permettant de l'identifier plus facilement. Si elle est utilisée dans le bon contexte, la macro $HOSTALIAS$ contient cet alias/description.
<address>	C'est l'adresse IP de l'hôte. Vous pouvez utiliser un FQDN [Fully Qualified Domain Name, nom de domaine complet] pour identifier l'hôte, mais si le service DNS n'est pas actif, cela peut poser des problèmes. Si elle est utilisée dans le bon contexte, la macro $HOSTADDRESS$ contient cette adresse.
<parent_hosts>	C'est une liste d'hôtes "parents" de cet hôte, séparés par des virgules. Les hôtes parents sont généralement des routeurs, des commutateurs, des firewalls, etc. se trouvant entre l'hôte de supervision et les hôtes distants. Le routeur, le commutateur, etc. le plus proche de l'hôte distant est considéré comme le parent de cette hôte. Pour plus d'informations, référez-vous au chapitre "Determiner l'état et l'accessibilité des hôtes du réseau" dans ce document ci. Si cet hôte est sur le même segment que l'hôte de supervision (sans routeur intermédiaire, etc.) il est considéré comme étant sur le réseau local et n'aura pas d'hôte parent. Laissez cette valeur vide si l'hôte n'a pas d'hôte parent (i.e. si il est sur le même segment que l'hôte de Nagios). L'ordre dans lequel vous déclarez les parents n'a pas d'influence sur la façon dont la supervision se déroule.
<host_check_command>	C'est le nom court de la commande à utiliser pour déterminer si l'hôte est hors service ou non. Typiquement, cette commande lance un "ping" vers l'hôte pour voir si il est "vivant". La commande doit retourner un état OK (0) sinon Nagios supposera que cet hôte est hors service. Si vous laissez cet argument vide, l'hôte ne sera pas contrôlé - Nagios supposera que l'hôte est toujours en fonctionnement. Ceci est utile pour superviser des imprimantes ou autres périphériques qui sont éteints fréquemment. Le temps d'exécution maximal de cette commande est déterminé par la variable host_check_timeout.
<max_attempts>	C'est le nombre de fois que Nagios relancera la commande de contrôle de l'hôte si celle-ci retourne un état différent de OK. Positionner cette valeur à 1 fera que Nagios générera une alerte sans re-contrôler l'hôte. Note : si vous ne voulez pas contrôler l'état de l'hôte, vous devez quand même mettre une valeur supérieure ou égale à 1. Pour ne pas effectuer le contrôle de l'hôte, laissez simplement vide l'option <host_check_command>.
<notification_interval>	C'est le nombre d'"unités de temps" à patienter avant de re-notifier un contact que l'hôte est toujours hors service ou inaccessible. Si vous n'avez pas modifié la valeur par défaut de la variable interval_length dans le fichier de configuration principal, qui est de 60, ce nombre exprime des minutes. Si vous mettez cette valeur à 0, Nagios ne re-notifiera pas les contacts à propos des problèmes de cet hôte - une seule notification sera émise.
<notification_period>	C'est le nom court de la période durant laquelle les notifications d'événements concernant cet hôte peuvent être émises vers les contacts. Si un hôte est hors service, inaccessible, ou se rétablit en dehors de la période de notification, aucune notification ne sera envoyée. Pour plus d'informations, vous pouvez lire le chapitre sur les "Périodes de temps" dans ce document ci
<notify_recovery>	Cette valeur détermine si des notifications doivent être envoyées aux contacts quand l'hôte est dans un état RECOVERY. Donnez une valeur de 1 si les notifications doivent être envoyées, 0 sinon. Note : un contact configuré pour ne pas recevoir de notifications du rétablissement des hôtes sera malgré tout notifié si ce paramètre est à 1.
<notify_down>	Cette valeur détermine si des notifications doivent être envoyées aux contacts quand l'hôte est dans un état DOWN. Donnez une valeur de 1 si les notifications doivent être envoyées, 0 sinon. Note : un contact configuré pour ne pas recevoir de notifications d'hôtes hors service sera malgré tout notifié si ce paramètre est à 1.
<notify_unreachable>	Cette valeur détermine si des notifications doivent être envoyées aux contacts quand l'hôte est dans un état UNREACHABLE. Donnez une valeur de 1 si les notifications doivent être envoyées, 0 sinon. Note : un contact configuré pour ne pas recevoir de notifications d'inaccessibilité des hôtes sera malgré tout notifié si ce paramètre est à 1.
<event_handler>	C'est le nom court de la commande à lancer à chaque fois qu'un changement de l'état de l'hôte est détecté (i.e. chaque fois qu'il est hors service ou qu'il se rétablit). Lisez la documentation sur les gestionnaires d'événement pour des explications détaillées sur la façon d'écrire des scripts de gestion d'événements. Si vous ne souhaitez pas définir de gestionnaire d'événements pour cet hôte, laissez cette option vide (comme le montre l'exemple ci-dessus). Le temps d'exécution maximal de cette commande est déterminé par la variable event_handler_timeout.

Format :	hostgroup[<nom_groupe>]=<alias_groupe>;<groupes_contacts>;<hôtes>
Exemple :	hostgroup[nt-servers]=All NT Servers;nt-admins;nt1,nt2,nt3

<nom_groupe>	C'est le nom court qui identifie le groupe d'hôtes
<alias_groupe>	C'est un nom long ou une description permettant d'identifier plus facilement le groupe d'hôtes.
<groupes_contacts>	C'est une liste de noms courts de groupes de contacts à notifier en cas de problème (ou de rétablissement) concernant un hôte quelconque de ce groupe. Les groupes de contacts sont séparés par des virgules.
<hôtes>	C'est une liste de noms courts d'hôtes à inclure dans ce groupe. Les noms sont séparés par des virgules.

Format :	contact[<contact_name>]=<alias_name>;<svc_notification_period>;<host_notification_period>;<svc_notify_recovery>;<svc_notify_critical>;<svc_notify_warning>;<host_notify_recovery>;<host_notify_down>;<host_notify_unreachable>;<service_notify_commands>;<host_notify_commands>;<email_address>;<pager>
Exemple :	contact[nagiosadmin]=Nagios Administrator;24x7;24x7;1;1;1;1;1;1;notify-by-email,notify-by-epager;host-notify-by-epager;nagiosadmin@localhost.localdomain;adminpager@pagenet.com

<contact_name>	C'est le nom court identifiant le contact. Il est utilisé dans les définitions de groupes de contacts. Si elle est utilisée dans le bon contexte, la macro $CONTACTNAME$ contient cette valeur.
<alias_name>	C'est un nom long ou une description du contact. Si elle est utilisée dans le bon contexte, la macro $CONTACTALIAS$ contient cette valeur.
<svc_notification_period>	C'est le nom court de la période durant laquelle le contact peut être notifié de problèmes ou de rétablissement de services. Pour plus d'informations, vous pouvez lire le chapitre sur les "Périodes de temps" dans le document principes de fonctionnement, qui décrit comment elles fonctionnent et quels sont les problèmes qui peuvent découler d'une utilisation incorrecte.
<host_notification_period>	C'est le nom court de la période durant laquelle le contact peut être notifié de problèmes ou de rétablissement d'hôtes. Pour plus d'informations, vous pouvez lire le chapitre sur les "Périodes de temps" dans le document principes de fonctionnement, qui décrit comment elles fonctionnent et quels sont les problèmes qui peuvent découler d'une utilisation incorrecte.
<svc_notify_recovery>	Cette valeur détermine si le contact doit être notifié du rétablissement d'un service. Donnez une valeur de 1 si le contact doit être notifié, 0 sinon. Note : si un service est configuré pour ne pas émettre de notification lors du rétablissement, le contact ne sera pas notifié même si ce paramétre est à 1.
<svc_notify_critical>	Cette valeur détermine si le contact doit être notifié qu'un service est en état critical. Donnez une valeur de 1 si le contact doit être notifié, 0 sinon. Note : si un service est configuré pour ne pas émettre de notification au passage en état critical, le contact ne sera pas notifié même si ce paramétre est à 1.
<svc_notify_warning>	Cette valeur détermine si le contact doit être notifié qu'un service est en état warning ou unknown. Donnez une valeur de 1 si le contact doit être notifié, 0 sinon. Note : si un service est configuré pour ne pas émettre de notification au passage en état warning/unknown, le contact ne sera pas notifié même si ce paramétre est à 1.
<host_notify_recovery>	Cette valeur détermine si le contact doit être notifié qu'un hôte se rétablit. Donnez une valeur de 1 si le contact doit être notifié, 0 sinon. Note : si un hôte est configuré pour ne pas émettre de notification au rétablissement, le contact ne sera pas notifié même si ce paramétre est à 1.
<host_notify_down>	Cette valeur détermine si le contact doit être notifié qu'un hôte passe en état down. Donnez une valeur de 1 si le contact doit être notifié, 0 sinon. Note : si un hôte est configuré pour ne pas émettre de notification au passage en état down, le contact ne sera pas notifié même si ce paramétre est à 1.
<host_notify_unreachable>	Cette valeur détermine si le contact doit être notifié qu'un hôte devient inaccessible. Donnez une valeur de 1 si le contact doit être notifié, 0 sinon. Note : si un hôte est configuré pour ne pas émettre de notification lorsqu'il est inaccessible, le contact ne sera pas notifié même si ce paramétre est à 1.
<service_notify_commands>	C'est une liste de noms courts de commandes à utiliser pour notifier d'un problème ou du rétablissement d'un service. Les commandes de notification multiples sont séparées par des virgules. Toutes les commandes de notification sont exécutées lorsque le contact doit être notifié. Le temps d'exécution maximal de cette commande est déterminé par la variable notification_timeout.
<host_notify_commands>	C'est une liste de noms courts de commandes à utiliser pour notifier d'un problème ou du rétablissement d'un hôte. Les commandes de notification multiples sont séparées par des virgules. Toutes les commandes de notification sont exécutées lorsque le contact doit être notifié. Le temps d'exécution maximal de cette commande est déterminé par la variable notification_timeout.
<email_address>	C'est l'adresse email du contact. Elle peut être utilisée dans les commandes de notification pour émettre un email, grâce à la macro $CONTACTEMAIL$ qui contient cette valeur.
<pager>	C'est le numéro de pager du contact. Cela peut aussi être l'address email d'une passerelle vers un pager (i.e. pagejoe@pagenet.com). Il peut être utilisé dans les commandes de notification pour émettre un message vers un pager, grâce à la macro $CONTACTPAGER$ qui contient cette valeur.

Format :	contactgroup[<group_name>]=<group_alias>;<contacts>
Exemple :	contactgroup[nt-admins]=NT Administrators;bbarker,jdoe

<group_name>	C'est le nom court utilisé pour identifer le groupe de contacts.
<group_alias>	C'est le nom long ou la description de ce groupe de contacts.
<contacts>	C'est une liste de noms courts de contacts faisant partie de ce groupe. Les noms sont séparés par des virgules.

Format :	command[<command_name>]=<command_line>
Exemple 1 :	command[check-host-alive]=/usr/local/nagios/libexec/check_ping -H $HOSTADDRESS$ -w 1000.0,40% -c 2000.0,80%
Exemple 2 :	command[check_pop]=/usr/local/nagios/libexec/check_pop -H $HOSTADDRESS$
Exemple 3 :	command[check_local_disk]=/usr/local/nagios/libexec/check_disk -w 20% -c 10% -p $ARG1$

Format :	service[<host>]=<description>;<volatile>;<check_period>;<max_attempts>;<check_interval>;<retry_interval>;<contact_groups>;<notification_interval>;<notification_period>;<notify_recovery>;<notify_critical>;<notify_warning>;<event_handler>;<check_command>
Exemple 1 :	service[nt1]=FTP;0;24x7;3;5;1;nt-admins;120;24x7;1;1;1;;check_ftp
Exemple 2 :	service[nt1]=HTTP;0;24x7;3;5;1;nt-admins;240;24x7;1;1;1;;check_http2!192.168.0.2!/!88
Exemple 3 :	service[linux1]=Zombie Processes;0;24x7;3;5;1;linux-admins;240;24x7;1;1;1;;check_local_procs!5!10!Z

Format :	timeperiod[<timeperiod_name>]=<timeperiod_alias>;<sunday_ranges>;<monday_ranges>;<tuesday_ranges>;<wednesday_ranges>;<thursday_ranges>;<friday_ranges>;<saturday_ranges>;
Exemple 1 :	timeperiod[24x7]=All Day, Every Day;00:00-24:00;00:00-24:00;00:00-24:00;00:00-24:00;00:00-24:00;00:00-24:00;00:00-24:00
Exemple 2 :	timeperiod[workhours]="Normal" Working Hours;;09:00-17:00;09:00-17:00;09:00-17:00;09:00-17:00;09:00-17:00;
Exemple 3 :	timeperiod[none]=No Time Is A Good Time;;;;;;;
Exemple 4:	timeperiod[nonworkhours]=Non-Work Hours;00:00-24:00;00:00-09:00,17:00-24:00;00:00-09:00,17:00-24:00;00:00-09:00,17:00-24:00;00:00-09:00,17:00-24:00;00:00-09:00,17:00-24:00;00:00-24:00

<timeperiod_name>	C'est le nom court identifiant la période.
<timeperiod_alias>	C'est un nom long ou une description de la période.
<xday_ranges>	C'est une liste de tranches horaires séparées par des point-virgules, qui sont "valides" pour un jour donné de la semaine. Notez que vous devez définir des tranches horaires pour les sept jours de la semaine (de dimanche à samedi). Les tranches horaires sont au format HH:MM-HH:MM, où les heures sont indiquées entre 0 et 24. Par exemple, 00:15-24:00 veut dire de z�ro heure quinze ce jour jusqu'à minuit (une tranche de 23 heures et 45 minutes). Si vous laissez une tranche vide pour un jour de la semaine, cela signifie qu'aucune heure n'est valide ce jour-là.

Format :	serviceescalation[<host>;<description>]=<first_notification>-<last_notificiation>;<contact_groups>;<notification_interval>
Exemples:	serviceescalation[linux1;Zombie Processes]=3-5;linux-admins,managers;0 serviceescalation[nt1;HTTP]=6-0;nt-admins,managers,everyone;30

Format :	hostgroupescalation[<group_name>]=<first_notification>-<last_notificiation>;<contact_groups>;<notification_interval>
Exemples:	hostgroupescalation[nt-servers]=3-5;nt-admins,managers;0 hostgroupescalation[nt-servers]=6-0;nt-admins,managers,everyone;60

<group_name>	C'est le nom court du groupe d'hôtes (tel que précédemment donné dans une définition de groupe d'hôtes) auquel s'applique l'escalade.
<first_notification>	C'est un nombre qui désigne la première notification à partir de laquelle cette escalade est effective. Par exemple, si vous mettez cette valeur à 3, cette escalade ne sera lancée que lorsqu'un hôte du groupe sera dans un état différent de OK depuis trois notifications.
<last_notificiation>	C'est le nombre qui désigne la dernière notification avant que cette escalade ne soit plus effective. Par exemple, si vous mettez une valeur de 5, cette escalade ne sera pas utilisée si plus de cinq notifications ont été envoyées pour un hôte du groupe spécifié. Donner une valeur de 0 revient à utiliser éternellement cette escalade (sans tenir compte du nombre de notifications émises).
<contact_groups>	C'est une liste de noms courts de groupes de contacts à notifier quand une escalade a lieu pour un hôte de ce groupe. Les groupes de contacts sont séparés par des virgules.
<notification_interval>	Intervalle avec lequel les notifications doivent être faites quand cette escalade s'applique. Si vous donnez une valeur de 0 à cet intervalle, Nagios enverra la première notification lorsque cette définition d'escalade est valide, mais arrêtera ensuite toute émission de notifications pour l'hôte. Les notifications ne sont plus envoyées jusqu'à ce que le service se rétablisse. Ceci est utile si vous ne voulez plus de notifications après un certain temps. Note : si pour un même groupe d'hôtes plusieurs définitions d'escalade ont des plages de notifications qui se chevauchent , c'est l'intervalle de notification le plus petit qui est retenu.

Format :	servicedepency[<dependent_host>;<dependent_description>]=<host>;<description>;<execution_failure_options>;<notification_failure_options>
Exemples :	servicedependency[nt1;WWW1 Website]=nt1;HTTP;;wc servicedependency[nt1;WWW2 Website]=nt1;HTTP;wcu;wcu servicedependency[nt1;WWW2 Website]=nt2;SQL Server;c;

<dependent_host>	Nom court de l'hôte sur lequel le service dépendant tourne ou qui lui est associé.
<dependent_description>	Description du service dépendant.
<host>	Nom court de l'hôte sur lequel le service dont nous dépendons tourne ou qui lui est associé.
<description>	Description du service dont nous dépendons.
<execution_failure_options>	Ces variables sont utilisées pour définir les situations dans lesquelles le service dépendant ne doit pas être en exécution. Si le service dont nous dépendons est dans un des états d'erreur spécifié, le service dépendant n'est pas en exécution. Les valeurs valides sont les combinaisons de un ou plusieurs de ces états : o = non exécuté si état OK, w = non exécuté si état WARNING , u = non exécuté si état UNKNOWN, et c = non exécuté si état CRITICAL. Par exemple, si vous spécifiez ocu dans cette variable, la dépendance est en erreur si le service dont nous dépendons est dans un des états OK, CRITICAL, ou UNKNOWN et que le service dépendant n'est pas en exécution. Vous n'avez pas à spécifier d'option d'erreur dans ce champ.
<notification_failure_options>	Ces variables sont utilisées pour définir les situations dans lesquelles les notifications pour le service dépendant ne doivent pas être envoyées. Si le service dont nous dépendons est dans l'un des états d'erreur spécifiés, les notifications pour le service dépendant ne seront pas envoyées aux contacts. Les valeurs valides sont les combinaisons de un ou plusieurs de ces états : o = non exécuté si état OK, w = non exécuté si état WARNING , u = non exécuté si état UNKNOWN, et c = non exécuté si état CRITICAL. Par exemple, si vous spécifiez w dans ce champ, la dépendance est en erreur si le service dont nous dépendons est dans l'état WARNING et les notifications pour le service dépendant ne seront pas envoyées. Vous n'avez pas à spécifier d'option d'erreur dans ce champ.