Cette variable détermine le chemin d'accès au fichier journal principal de Nagios. Elle doit être la première variable définie dans le fichier de configuration, car Nagios essaiera d'enregistrer à cet endroit les erreurs découvertes dans le reste du fichier. Si vous avez activé la rotation des journaux ,ce fichier sera automatiquement archivé et remplacé chaque heure, jour, semaine et mois.

Cette variable détermine les fichiers de configuration des objets que Nagios doit utiliser pour la supervision. Ces fichiers contiennent les définitions pour les hôtes, groupes d'hôtes, contacts, groupes de contacts, services, commandes etc… Vous pouvez éclater votre fichier de configuration des objets en plusieurs fichiers que vous inclurez, pour leur traitement, en ajoutant un paramètre cfg_file= pour chacun d'eux.

Cette directive est utilisée pour spécifier un répertoire qui contient les fichiers de configuration d'objet que Nagios doit utiliser pour la supervision. Tous les fichiers contenus dans le répertoire avec une extension cfg sont traitées comme objet config. En outre, Nagios procède de manière récursive tous les fichiers de config dans les sous-répertoires du répertoire que vous spécifiez ici. Vous pouvez éclater votre fichier de configuration des objets dans plusieurs répertoires que vous inclurez, pour leur traitement, en ajoutant une directive cfg_dir= pour chacun d'eux.

Cette variable est utilisée pour indiquer l'emplacement d'un fichier qui contiendra une copie en cache des définitions des objets .Ce fichier cache est (re)créé à chaque (re)démarrage de Nagios et est utilisé par les CGIs. Il permet d'accélérer le cache des fichiers de configuration pour les CGIs, et vous permet de modifier les fichiers de configuration des objets, pendant que Nagios tourne, sans que l'affichage des CGIs soit modifié.

Cette variable est utilisée pour indiquer l'emplacement d'un fichier qui va contenir une copie pré-traitée, pré-cachée du fichier de configuration des objets .Ce fichier peut améliorer de façon drastique les temps de démarrage de Nagios dans des installations complexes ou de grande dimension. Lisez plus d'informations sur la façon d'améliorer les temps de démarrage ici.

Le fichier de ressources optionnel qui contient des définitions de macros du type $USERn$. Les macros $USERn$ permettent de stocker des noms d'utilisateurs, des mots de passe, et les éléments couramment utilisés dans les commandes (comme les chemins d'accès). Les CGIs ne lisent pas les fichiers de ressources, si bien que vous pouvez y mettre des droits d'accès restrictifs (600 ou 660) pour protéger les données sensibles. Vous pouvez inclure de nombreux fichiers de ressources en ajoutant des paramètres resource_file au fichier de configuration principal - Nagios les traitera tous. Référez-vous au fichier resource.cfg d'exemple situé à la racine de la distribution de Nagios, pour voir comment utiliser les macros $USERn$.

C'est un fichier que Nagios crée périodiquement durant la mise à jour des commentaires de données, des données d'état etc… Il est supprimé quand il n'est plus nécessaire.

C'est un répertoire que Nagios peut utiliser comme espace scratch pour créer des fichiers temporaires utilisés durant le processus de supervision. Vous pouvez exécuter tmpwatch, ou un outil similaire sur ce réperoire pour effacer les fichiers plus vieux de 24 heures.

C'est le fichier utilisé par Nagios, pour stocker l'état courant de tous les services supervisés. L'état de tous les hôtes et leurs services associés, est également enregistré dans ce fichier. Ce fichier est utilisé par le CGI d'état pour afficher l'état courant de la supervision dans l'interface web. Les CGIs doivent avoir le droit d'accéder en lecture à ce fichier, pour fonctionner correctement. Ce fichier est supprimé à l'arrêt de Nagios, et recréé au démarrage.

Cette variable, détermine la fréquence (en secondes), à laquelle Nagios mettra à jour les données d'état dans le la section intitulée «  status_file  » .L'intervalle minimal est de une seconde.

Ceci détermine quel utilisateur doit être le propriétaire du processus de Nagios. Après le démarrage du programme, et avant toute supervision, Nagios abandonnera ses privilèges effectifs, et se lancera sous cet utilisateur. Vous pouvez donner un nom d'utilisateur ou un UID.

Ceci détermine quel groupe doit être propriétaire du processus de Nagios. Après le démarrage du programme, et avant toute supervision, Nagios abandonnera ses privilèges effectifs et se lancera sous ce groupe. Vous pouvez donner un nom de groupe ou un GID.

Cette option détermine si Nagios envoie ou non une notification quand il (re)démarre. Si cette option est désactivée, Nagios n'enverra aucune notification, quel que soit l'hôte ou le service.

Cette option détermine, si Nagios effectuera les contrôles des services lorsqu'il (re)démarrera. Si cette option est désactivée, Nagios n'effectuera aucun contrôle de service, et restera dans un mode de sommeil (il peut quand même recevoir les contrôles passifs à moins qu'ils ne soient désactivés). Cette option est surtout utile pour définir des serveurs de supervision de secours, comme l'explique la documentation sur la redondance, ou pour mettre en place un environnement de supervision répartie. Note : si vous avez activé la mémorisation d'état, Nagios ignorera ce paramètre au (re)démarrage, et utilisera sa dernière valeur connue (telle qu'elle est stockée dans le fichier de mémorisation d'état), à moins que vous ne désactiviez l'option use_retained_program_state. Si vous voulez changer cette variable, alors que la mémorisation d'état est activée (ainsi que l'option use_retained_program_state), vous devrez passer par la commande externe appropriée, ou la changer à travers l'interface web. Les valeurs possibles de cette variable sont :

Cette option détermine si Nagios accepte les contrôles passifs de service quand il (re)démarrera. Si cette option est désactivée, Nagios n'acceptera aucun contrôle passif de service. Note : si vous avez activé la mémorisation d'état, Nagios ignorera ce paramètre au (re)démarrage et utilisera sa dernière valeur connue (telle qu'elle est stockée dans le fichier de mémorisation d'état), à moins que vous ne désactiviez l'option use_retained_program_state. Si vous voulez changer cette variable alors que la mémorisation d'état est activée (ainsi que l'option use_retained_program_state), vous devrez passer par la commande externe appropriée ou la changer à travers l'interface web. Les valeurs possibles de cette variable sont :

Cette option détermine si Nagios effectuera les contrôles des hôtes - à la demande ou de manière régulière - lorsqu'il (re)démarrera. Si cette option est désactivée, Nagios n'effectuera aucun contrôle sur les hôtes et restera dans un mode de sommeil (il peut quand même recevoir les contrôles passifs d'hôtes à moins qu'ils ne soient désactivés). Cette option est surtout utile pour définir des serveurs de supervision de secours, comme l'explique la documentation sur la redondance, ou pour mettre en place un environnement de supervision répartie. Note : si vous avez activé la mémorisation d'état, Nagios ignorera ce paramètre au (re)démarrage, et utilisera sa dernière valeur connue (telle qu'elle est stockée dans le fichier de mémorisation d'état), à moins que vous ne désactiviez l'option use_retained_program_state. Si vous voulez changer cette variable alors que la mémorisation d'état est activée (ainsi que l'option use_retained_program_state), vous devrez passer par la commande externe appropriée, ou la changer à travers l'interface web. Les valeurs possibles de cette variable sont :

Cette option détermine si Nagios accepte les contrôles passifs d'hôte quand il (re)démarrera. Si cette option est désactivée, Nagios n'acceptera aucun contrôle passif d'hôte. Note : si vous avez activé la mémorisation d'état, Nagios ignorera ce paramètre au (re)démarrage, et utilisera sa dernière valeur connue (telle qu'elle est stockée dans le fichier de mémorisation d'état), à moins que vous ne désactiviez l'option use_retained_program_state. Si vous voulez changer cette variable alors que la mémorisation d'état est activée (ainsi que l'option use_retained_program_state), vous devrez passer par la commande externe appropriée, ou la changer à travers l'interface web. Les valeurs possibles de cette variable sont :

Cette option détermine si Nagios activera les gestionnaires d'événement quand il (re)démarrera. Si cette option est désactivée, Nagios ne lancera aucun gestionnaire d'événement lié aux hôtes ou aux services. Note : si vous avez activé la mémorisation d'état, Nagios ignorera ce paramètre au (re)démarrage, et utilisera sa dernière valeur connue (telle qu'elle est stockée dans le fichier de mémorisation d'état), à moins que vous ne désactiviez l'option use_retained_program_state. Si vous voulez changer cette variable alors que la mémorisation d'état est activée (ainsi que l'option use_retained_program_state), vous devrez passer par la commande externe appropriée ou la changer à travers l'interface web. Les valeurs possibles de cette variable sont :

C'est la méthode de rotation que vous voulez que Nagios utilise pour le fichier journal. Les valeurs possibles de cette variable sont :

C'est le répertoire où Nagios doit enregistrer les fichiers journaux ayant fait l'objet d'une rotation. Cette option est ignorée si vous n'avez pas activé la rotation du journal .

Cette option détermine si Nagios va vérifier le contenu du la section intitulée «  command_file  » à la recherche de commandes à exécuter. Cette option doit être activée si vous avez prévu d'utiliser le CGI de commande pour envoyer des commandes via l'interface web. Des programmes tiers peuvent également envoyer des commandes à Nagios en écrivant dans le fichier de commande, sous réserve que les droits nécessaires à l'accès au fichier aient été donnés, comme le souligne cette FAQ. Vous trouverez plus d'informations sur les commandes externes ici.

Si vous spécifiez un nombre suivi d'un s (par exemple 30s), c'est le nombre de secondes qui séparera deux contrôles de commandes externes. Si vous ne mettez pas de s, c''est le nombre d'unités de temps à laisser entre deux contrôles de commandes externes. Si vous n'avez pas modifié la valeur de lala section intitulée «  interval_length  » qui est par défaut de 60, ce nombre représente des minutes.

C'est le fichier que Nagios lit à la recherche de commandes externes. Le CGI de commande écrit les commandes dans ce fichier. Des programmes tiers peuvent écrire dans ce fichier sous réserve qu'ils aient les droits d'accès comme il est décrit ici. Le fichier de commandes externes est implémenté sous forme d'un tube nommé [named pipe] (FIFO), qui est créé quand Nagios démarre et supprimé lorsqu'il s'arrête. Pour plus d'informations sur les commandes externes, lisez ceci.

Cette option détermine le nombre de slots tampon que Nagios va réserver pour mettre en cache les commandes externes qui ont été lues depuis le fichier de commandes externes par un processus enfant (worker thread) mais qui n'ont pas encore été traité par le processus principal (main thread) du démon Nagios. Chaque slot peut gérer une commande externe, ce qui fait que cette option détermine le nombre de commandes externes qui peuvent être mis en tampon. Pour des installations où vous avez besoin de traiter un nombre important de contrôles passifs (comme dans les environnements distribués), vous aurez peut-être besoin d'augmenter ce nombre. Vous devriez considérer l'utilisation de MRTG pour grapher l'usage que fait Nagios des tampons de commande externe. Vous pouvez en apprendre davantage sur la façon de configurer les graphes ici.

C'est l'emplacement du fichier verrou qu'utilise Nagios quand il est lancé en tant que démon (i.e. démarré avec l'argument -d ). Ce fichier contient l'identifiant du processus (PID) de Nagios.

Cette option détermine si Nagios doit mémoriser l'état des hôtes et des services entre deux démarrages. Si vous activez cette option, vous devez donnez une valeur à la variable la section intitulée «  state_retention_file  » .Une fois l'option activée, Nagios enregistrera toutes les informations concernant l'état des hôtes et des services avant de s'arrêter (ou de redémarrer) et il relira les informations d'état préalablement enregistrées quand il redémarrera.

C'est le fichier utilisé par Nagios pour mémoriser l'état des hôtes et des services entre les redémarrages. Au démarrage, Nagios positionnera l'état initial des services et des hôtes à partir des informations contenues dans ce fichier, puis commencera la supervision. Ce fichier est supprimé dès sa lecture effectuée. Pour que Nagios mémorise l'état des hôtes et des services, vous devez activer l'option de la section intitulée «  retain_state_information  » .

Cette variable détermine la fréquence (en minutes) à laquelle Nagios va automatiquement sauvegarder les données de mémorisation en situation normale. Si vous donnez une valeur de 0, Nagios ne sauvegardera pas les données mémorisées à intervalles réguliers, mais avant de s'arrêter ou de redémarrer. Si vous avez désactivé la mémorisation des états (grâce à l'option la section intitulée «  retain_state_information  » ), cette variable est sans effet.

Cette option détermine si Nagios positionnera diverses variables d'état du programme à partir des valeurs enregistrées dans le fichier de mémorisation. Parmi ces variables d'état du programme, normalement sauvegardées par delà les redémarrages du programme si la mémorisation d'état est activée, on trouve les la section intitulée «  enable_notifications  » , la la section intitulée «  enable_flap_detection  » ,la section intitulée «  enable_event_handlers  » ,la section intitulée «  execute_service_checks  » ,ou la section intitulée «  accept_passive_service_checks  » .Si vous n'avez pas activé la la section intitulée «  retain_state_information  » ,cette option est sans effet.

Cette option détermine si Nagios va garder les informations d'ordonnancement (prochain lancement de vérification pour chaque service), lorsqu'il redémarre. Si vous ajoutez un grand nombre (ou pourcentage) de services ou d'hôtes, je vous recommande de désactiver cette option lorsque vous redémarrez Nagios, car ceci peut biaiser la répartition initiale des services. Dans le cas contraire, vous voudrez probablement laisser cette option active.

Ces options détermine quels sont les attributs d'hôtes et services qui ne seront PAS conservés entre les redémarrages du programme. Les valeurs pour ces options sont au niveau du bit (bitwise) ET les valeurs spécifiées par les définitions de MODATTR_ dans le fichier du code source include/common.h. Par défaut, tous les attributs d'hôtes et services sont conservés.

Ces options déterminent quels sont les attributs de processus qui ne seront PAS conservés entre les redémarrages du programme. Il y a deux masques parce qu'il y a souvent des attributs séparés qui peuvent être changés pour les hôtes et services. Par exemple, les contrôles d'hôtes peuvent être désactivés au niveau du programme, alors que les services restent eux activés. Les valeurs pour ces options sont au niveau du bit (bitwise) ET les valeurs spécifiées par les définitions de MODATTR_ dans le fichier du code source include/common.h. Par défaut, tous les attributs de processus sont conservés.

Ces options déterminent quels sont les attributs de contact qui ne seront PAS conservés entre les redémarrages du programme. Il y a deux masques parce qu'il y a souvent des attributs séparés qui peuvent être changés pour les contacts d'hôtes et de services. Les valeurs pour ces options sont au niveau du bit (bitwise) ET les valeurs spécifiées par les définitions de MODATTR_ dans le fichier du code source include/common.h. Par défaut, tous les attributs de contact sont conservés.

Cette option détermine si les messages doivent être journalisés via l'utilitaire système Syslog. Les valeurs possibles sont :

Cette variable détermine si les messages de notification sont journalisés ou non. Si vous avez de nombreux contacts ou des problèmes fréquents sur les services, le fichier journal va rapidement grossir. Utilisez cette option pour éviter de journaliser les notifications faites aux contacts.

Cette option détermine si les tentatives répétées de contrôle d'un service sont journalisées. Ces tentatives ont lieu lorsqu'un service retourne un état différent de OK, mais que vous avez configuré Nagios pour essayer plus d'une fois avant de considérer cela comme une erreur. Les services dans cette situation sont dits en état soft. La journalisation des tentatives de contrôle permet de déboguer Nagios ou de tester les gestionnaires d'événements.

Cette option détermine si les tentatives répétées de contrôle d'un hôte sont journalisées. La journalisation des tentatives de contrôle permet de déboguer Nagios ou de tester les gestionnaires d'événements.

Cette option détermine si les gestions d'événements liés aux hôtes ou aux services sont journalisées. Les gestionnaires d'événements sont des commandes optionnelles qu'on peut lancer lors du changement d'état d'un hôte ou d'un service. La journalisation des gestions d'événements permet de déboguer Nagios ou de tester les scripts de gestion d'événements.

Cette variable détermine si Nagios forcera la journalisation de tous les états initiaux des hôtes et des services, même si leur état est OK. Les états initiaux ne sont normalement journalisés que s'il y a un problème lors du premier contrôle. Cette option peut se révéler utile si vous utilisez une application tierce qui lit le journal pour en tirer des statistiques à long terme pour les hôtes et services.

Cette variable détermine si Nagios journalisera les commandes externes reçues via le fichier des commandes externes .

Cette variable détermine si Nagios journalisera les contrôles passifs d'hôte ou de service reçus via le fichier de commandes externes .Si vous mettez en place un environnement de supervision réparti ou si vous souhaitez utiliser fréquemment un grand nombre de contrôles passifs, vous pouvez désactiver cette option pour éviter au journal de trop grossir.

Cette option détermine un gestionnaire d'événement appelé à chaque changement d'état d'un hôte. Il s'exécute juste avant le gestionnaire d'événement particulier à l'hôte que vous avez précisé de manière optionnelle dans la définition de l'hôte. L'argument commande est le nom court d'une définition de commande qui se trouve dans votre Object Configuration Overview. Le temps d'exécution maximal de cette commande est déterminé par la variable event_handler_timeout . Vous trouverez plus d'informations sur les gestionnaires d'événements ici

Cette option détermine un gestionnaire d'événement appelé à chaque changement d'état d'un service. Il s'exécute juste avant le gestionnaire d'événement particulier à l'hôte que vous avez précisé de manière optionnelle dans la définition du service. L'argument commande est le nom court d'une définition de commande qui se trouve dans votre Object Configuration Overview. Le temps d'exécution maximal de cette commande est déterminé par la variable event_handler_timeout . Vous trouverez plus d'informations sur les gestionnaires d'événements ici.

C'est le nombre de secondes pendant lequel Nagios va sommeiller avant de vérifier si le prochain contrôle de service ou d'hôte en file d'attente doit être exécuté. Notez que Nagios ne s'endormira qu'après avoir liquidé les contrôles de services en retard dans la file.

Cette option détermine comment les contrôles de service sont initialement répartis dans la file d'attente. L'option de calcul débrouillard [smart] du délai (par défaut), demande à Nagios de calculer un intervalle moyen entre les contrôles, et d'ordonnancer les contrôles initiaux de tous les services à cet intervalle, ce qui permet d'éviter les pics d'utilisation du processeur. Il n'est pas recommandé d'utiliser la méthode sans délai [no delay] à moins que vous ne vouliez tester la parallélisation des contrôles de service. En effet, cette méthode ordonnance tous les contrôles en même temps. L'exécution de tous les contrôles en parallèle va provoquer d'importants pics d'utilisation du processeur. Vous obtiendrez plus d'informations sur la façon dont cette variable affecte l'ordonnancement des contrôles de service ici. Ses valeurs possibles sont :

Cette option détermine le temps maximum (en minutes) entre le démarrage de Nagios et la vérification de tous les services qui sont ordonnancés régulièrement. Cette option va automatiquement ajuster le délai inter-contrôles de services (si nécessaire) pour s'assurer que les contrôles initiaux des services vont s'effectuer dans le temps imparti. En général, cette option n'a pas d'effet si l'option la section intitulée «  use_retained_scheduling_info  » est activée. La valeur par défaut est de 30 (minutes).

Cette variable détermine comment les contrôles de service sont entrelacés. L'entrelacement permet une distribution plus égale des contrôles de service, une charge réduite sur les hôtes distants, et une détection globalement plus rapide des problèmes liés aux hôtes. Avec l'introduction de la parallélisation des contrôles de service, les hôtes distants peuvent se retrouver bombardés de contrôles si l'entrelacement n'est pas activé. Ceci peut entrainer l'échec de contrôles ou des résultats incorrects si l'hôte distant est surchargé de requêtes. Mettre une valeur de 1 est équivalent à ne pas entrelacer les contrôles de service (c'est le mode de fonctionnement des versions de Nagios antérieures à la version 0.0.5). Mettez une valeur de s (débrouillard)[smart]) pour que le calcul du facteur d'entrelacement soit automatique, à moins que vous ayez une bonne raison de la changer. Le meilleur moyen de comprendre le fonctionnement du facteur d'entrelacement est d'observer le CGI d'état (vue détaillée) au moment où Nagios vient de démarrer. Vous verrez comment les contrôles sont faits au fur et à mesure que les résultats apparaissent. Vous trouverez plus d'informations sur l'entrelacement ici.

Cette option détermine le nombre maximal de contrôles de service pouvant tourner en parallèle à un instant donné. Une valeur de 1 empêche la parallélisation. Une valeur de 0 (par défaut) n'impose aucune restriction sur le nombre de contrôles simultanés. Vous ajusterez cette valeur en fonction des capacités de la machine sur laquelle tourne Nagios, car elle impacte directement la charge du système (processeur, mémoire, etc.). Vous trouverez plus d'informations sur le nombre de contrôles de services que vous devriez autoriser ici.

Cette option vous permet de contrôler la fréquence en secondes des événements de consolidation. Les événements de consolidation traitent les résultats des contrôles d'hôtes et de services dont l'exécution est terminée. Ces événements constituent le cœur de la logique de supervision de Nagios.

Cette option vous permet de contrôler le temps maximum en secondes que doit prendre une consolidation des résultats de contrôles d'hôte et de service. Les événements de consolidation traitent les résultats de contrôle d'hôtes et de services qui sont terminés. Si il y a une grande quantité de résultats à traiter, les événements de collecte peuvent mettre beaucoup de temps à se terminer, ce qui décale d'autant l'exécution de nouveaux contrôles d'hôtes et de services. Cette variable vous permet de limiter le temps que prend un événement de consolidation avant de rendre la main à Nagios pour d'autres traitements de la logique de supervision.

Cette option détermine quel répertoire Nagios utilisera pour stocker temporairement les résultats de contrôle. Ce répertoire ne doit pas stocker d'autres fichiers, car Nagios efface le contenu de ce répertoire de manière récurrente (voir l'option la section intitulée «  max_check_result_file_age  » pour plus d'informations).

Cette option détermine le temps maximum en seconde que Nagios peut considérer trouver des informations de résultats de contrôles dans le répertoire de stockages des résultats .Les résultats dépassant ce temps limite, ils seront effacés par Nagios et ne pourront plus être exploités. En utilisant la valeur zéro (0) pour cette option, Nagios exploitera chaque fichiers de contrôle.

Cette option détermine comment les contrôles d'hôtes (pour les hôtes qui sont régulièrement contrôlés) sont initialement répartis dans la file d'attente. L'option de calcul débrouillard [smart] du délai (par défaut) demande à Nagios de calculer un intervalle moyen entre les contrôles et d'ordonnancer les contrôles initiaux de tous les services à cet intervalle, ce qui permet d'éviter les pics d'utilisation du processeur. Il n'est pas recommandé d'utiliser la méthode sans délai [no delay]. En effet, cette méthode ordonnance tous les contrôles en même temps. Vous obtiendrez plus d'informations sur la façon dont cette variable affecte l'ordonnancement des contrôles d'hôte ici. Ses valeurs possibles sont :

Cette option détermine le temps maximum (en minutes) entre le démarrage de Nagios et la vérification de tous les hôtes qui sont contrôlés régulièrement. Cette option va automatiquement ajuster le délai inter-contrôles d'hôtes (si nécessaire) pour s'assurer que les contrôles initiaux des services vont s'effectuer dans le temps imparti. En général, cette option n'a pas d'effet si l'option d'utilisation des états mémorisés de l'ordonnanceur est activée. La valeur par défaut est de 30 (minutes).

C'est le nombre de secondes que contient une unité de temps utilisée dans la file d'ordonnancement, les re-notifications, etc. Les unités de temps sont utilisées dans le fichier de configuration des objets pour déterminer la fréquence d'exécution des contrôles de service, la fréquence de re-notification d'un contact, etc.

Cette option détermine si Nagios va essayer de ré-ordonnancer automatiquement les services de vérification actifs des hôtes et services pour les lisser dans le temps. Ceci peut aider à distribuer la charge sur le serveur de surveillance car il va essayer de conserver un delta de temps cohérent entre deux vérifications. La contrainte étant que l'ordonnancement sera plus strict.

Cette option détermine la fréquence (en secondes) de réordonnancement automatique. Cette option n'a d'effet que si l'option de réordonnancement automatique est active. La valeur par défaut est de 30 secondes.

Cette option détermine la fenêtre de temps (en seconde) sur laquelle Nagios va porter le réordonnancement automatique. Seules les vérifications d'hôtes et de services qui doivent avoir lieu durant les prochaines N secondes seront affectées par le réordonnancement. Cette option n'a d'effet que si l'la section intitulée «  auto_reschedule_checks  » est active. La valeur par défaut est de 180 secondes (3 minutes).

[NdT] : cette option comporte deux g à aggressive depuis la version 2. Elle n'en comprenait qu'un auparavant.Nagios essaye d'être plus malin dans la façon et le moment de contrôler l'état des hôtes. En général, désactiver cette option permet à Nagios d'être un peu plus malin et de faire les contrôles plus vite. Activer cette option revient à ralentir le contrôle des hôtes, mais peut améliorer la sûreté de fonctionnement. A moins que Nagios ne parvienne pas à détecter le rétablissement d'un de vos hôtes, je vous suggère de ne pas activer cette option.

Cette option détermine si Nagios peut traduire ou non l'état DOWN/UNREACHABLE d'un contrôle passif en l'état correct en considérant un point de vue d'une instance Nagios locale. Cette option peut s'avérer vraiment utile lors d'installation de type distribuée. Plus d'informations sur la traduction d'état passif peuvent être trouvés ici.

Cette option détermine si en effet Nagios traitera les contrôles d'hôte passif en états HARD ou SOFT. Par défaut, les résultats de contrôles passif sont considérés en état HARD. Vous pouvez changer ceci en activant cette option.

Cette option détermine si Nagios exécutera ou non des contrôles prédictifs sur les hôtes dépendant (comme définit dans dépendance d'hôtes) d'un hôte particulier quand celui ci change d'état. Les contrôles prédictifs permettent de s'assurer que la logique de dépendance est aussi précise que possible. Plus d'informations sur le fonctionnement des contrôles prédictifs peuvent être trouvées ici

Cette option détermine si Nagios exécutera ou non des contrôles prédictifs sur les services dépendants (comme défini dans dépendance de service) d'un service particulier quand celui ci change d'état. Les contrôles prédictifs permettent de s'assurer que la logique de dépendance est aussi précise que possible. Plus d'informations sur le fonctionnement des contrôles prédictifs peuvent être trouvées ici FIXME

Cette option détermine le temps maximum (en secondes) pour que l'état d'un précédent contrôle d'hôte soit considéré comme courant. Le cache d'état d'hôtes (du point de vue des contrôles d'hôtes qui ont été effectués plus récemment que le temps spécifié par cette valeur) peut améliorer considérablement les performances pour les contrôles d'hôtes. Une valeur trop élevée pour cette option peut se traduire par des états d'hôtes (temporairement) éronnés, alors qu'une valeur trop basse se traduira par un écroulement des performances pour les contrôles d'hôtes. Utiliser la valeur 0 pour désactiver le cache de contrôle des hôtes. Plus d'informations concernant le cache des contrôles peuvent être trouvées ici.

Cette option permet de définir le temps maximum (en secondes) pour que l'état d'un précédent contrôle de service soit considéré comme courant. Le cache d'état de service (Pour les contrôles de services qui sont effectués en avance par rapport à l'intervalle spécifié par cette valeur) peut améliorer la performance des contrôles quand un nombre important de dépendances de services est utilisé. Une valeur trop haute pour cette option se soldera par une manque de précision dans la logique de dépendance des services. Positionnez cette valeur à 0 si vous voulez désactiver le cache de contrôle de service. Plus d'informations sur le cache de contrôles peuvent être trouvées ici.

Cette option détermine si Nagios utilisera différents raccourcis pour améliorer les performances. Ces raccourcis font perdre quelques fonctionnalités, mais ils apportent de gros gains sur des périmètres importants. Plus d'informations sur ces optimisations quand vous activez cette option peuvent être trouvées ici.

Cette option permet de déterminer si Nagios libérera la mémoire utilisée par les processus enfant quand il seront arrivés en fin de traitement. Par défaut, Nagios libère la mémoire. Ce

Cette option détermine si nagios doit forker ou non en double les processus enfants quand il exécute des contrôle d'hôte et de service. Par défaut, Nagios fork en double. Cependant, si l'option use_large_installation_tweaks est activée, il ne fera qu'un fork. En déclarant cette option dans votre fichier de configuration, vous avez la possibilité de changer ce comportement.

Cette option détermine si oui ou non le démon Nagios peut considérer toutes les macros standard comme des variables d'environnements pour vos contrôles, notifications, déclencheur d'événement, etc… Dans de grands périmètres de production, ceci peut être problématique car une utilisation mémoire et CPU supplémentaire est utile pour convertir ces macros en variables d'environnements.

Cette option détermine si Nagios essaiera de détecter les hôtes et les services qui oscillent. L'oscillation apparaît lorsqu'un hôte ou un service change d'état trop fréquemment, causant l'émission d'une montagne de notifications. Quand Nagios détecte qu'un hôte ou un service oscille, il supprime temporairement les notifications pour cet hôte/service jusqu'à ce qu'il arrête d'osciller.

Cette option permet de donner le seuil inférieur pour la détection de l'oscillation d'un service. Pour plus d'informations sur la détection et la gestion des oscillations (et comment cette variable les affecte), lisez ceci.

Cette option permet de donner le seuil supérieur pour la détection de l'oscillation d'un service. Pour plus d'informations sur la détection et la gestion des oscillations (et comment cette variable les affecte), lisez ceci.

Cette option permet de donner le seuil inférieur pour la détection de l'oscillation d'un hôte. Pour plus d'informations sur la détection et la gestion des oscillations (et comment cette variable les affecte), lisez ceci.

Cette option permet de donner le seuil supérieur pour la détection de l'oscillation d'un hôte. Pour plus d'informations sur la détection et la gestion des oscillations (et comment cette variable les affecte), lisez ceci.

Cette option détermine si Nagios utilisera les informations d'état soft des services lors du contrôle des dépendances de service. En temps normal, Nagios n'utilise que le dernier état hard du service lors du contrôle des dépendances. Si vous voulez utiliser le tout dernier état (que ce soit un état de type hard ou soft), activez cette option.

C'est le nombre maximal de secondes pendant lequel Nagios laissera tourner un contrôle de service. Si le contrôle dépasse cette limite, il est tué et un état CRITICAL est retourné. Une erreur de dépassement de délai est également journalisée.

Il existe la confusion la plus totale sur ce que cette option fait vraiment. Elle est là comme dernier rempart, pour tuer les plugins qui se comportent mal, ou ne se sont pas terminés correctement. Il faut la positionner à une valeur haute (quelque chose comme 60s), de manière à ce que tout contrôle ait le temps de se terminer avant cette limite. Si le contrôle du service prend plus de temps pour s'exécuter, Nagios le tuera, pensant que c'est un processus ayant des problèmes d'exécution.

C'est le nombre maximal de secondes pendant lesquelles Nagios laissera tourner un contrôle d'hôte. Si le contrôle dépasse cette limite, il est tué et un état CRITICAL est retourné, et l'hôte sera supposé être dans l'état DOWN. Une erreur de dépassement de délai est également journalisée.

Il existe également la confusion la plus totale sur ce que cette option fait vraiment. Elle est là comme dernier rempart, pour tuer les plugin qui se comportent mal ou ne se sont pas terminés correctement. Il faut la positionner à une valeur haute (quelque chose comme 60s), de manière à ce que tout contrôle ait le temps de se terminer avant cette limite. Si le contrôle de l'hôte prend plus de temps pour s'exécuter, Nagios le tuera, pensant que c'est un processus ayant des problèmes d'exécution.

C'est le nombre maximal de secondes pendant lequel Nagios laissera tourner un gestionnaire d'événement. Si un gestionnaire d'événement dépasse cette limite il sera tué et une alerte sera journalisée.

Il existe là aussi, comme précédemment, la confusion la plus totale sur ce que cette option fait vraiment. Elle est là comme dernier rempart, pour tuer les plugins qui se comportent mal ou ne se sont pas terminés correctement. Il faut le positionner à une valeur haute (quelque chose comme 60s), de manière à ce que tout contrôle ait le temps de se terminer avant cette limite. Si le contrôle du gestionnaire d'événement prend plus de temps pour s'exécuter, Nagios le tuera, pensant que c'est un processus ayant des problèmes d'exécution.

C'est le nombre maximal de secondes pendant lequel Nagios laissera tourner une commande de notification. Si une commande de notification dépasse cette limite elle sera tuée et une alerte sera journalisée.

Il existe la confusion la plus totale (NdT: toute ressemblance avec des phrases précédentes serait purement intentionnelle :-) ) sur ce que cette option fait vraiment. Elle est là comme dernier rempart, pour tuer les plugins qui se comporte mal ou ne se sont pas terminés correctement. Il faut le positionner à une valeur haute (quelque chose comme 60s), de manière à ce que tout contrôle ait le temps de se terminer avant cette limite. Si la notification prend plus de temps pour s'exécuter, Nagios la tuera, pensant que c'est un processus ayant des problèmes d'exécution.

C'est le nombre maximal de secondes pendant lequel Nagios laissera tourner une commande de remontée de contrôle de service .Si une commande dépasse cette limite, elle sera tuée et une alerte sera journalisée.

C'est le nombre maximal de secondes pendant lequel Nagios laissera tourner une ochp_command. Si une commande dépasse cette limite, elle sera tuée et une alerte sera journalisée.

C'est le nombre maximal de secondes pendant lequel Nagios laissera tourner une commande de traitement des données liées aux performance d'un hôte ou de traitement des données liées aux performances d'un service .Si une commande dépasse cette limite, elle sera tuée et une alerte sera journalisée.

Cette variable détermine si Nagios remontera les résultats de contrôles de service et lancera la commande de remontée de contrôle de service que vous avez définie. Je sais que c'est un drôle de nom [en anglais obsessive compulsive service processor], mais c'est tout ce qui m'est venu à l'esprit. Cette option est utile dans le cadre de la supervision répartie .Si vous ne faites pas de supervision répartie, n'activez pas cette option.

Cette option définit la commande à lancer après chaque contrôle de service, ce qui peut être utile dans une supervision répartie. Elle est exécutée après les éventuelles commandes de gestion d'événement ou de notification. L'argument commande est le nom court d'une définition de commande que vous avez définie dans le fichier de configuration des hôtes. Cette option sert dans le cadre de la supervision répartie. Le temps d'exécution maximal de cette commande est déterminé par la variable la section intitulée «  ocsp_timeout  » .Vous trouverez plus d'informations sur la supervision répartie ici. Cette commande est seulement exécutée que si la variable la section intitulée «  obsess_over_services  » est entièrement activée et que si le paramètre obsess_over_service dans la définition du service l'est aussi.

Cette variable détermine si Nagios remontera les résultats de contrôles d'hôtes et lancera la commande de remontée de contrôle d'hôte que vous avez définie. Je sais que c'est un drôle de nom [en anglais obsessive compulsive host processor], mais c'est tout ce qui m'est venu à l'esprit. Cette option est utile dans le cadre de la supervision répartie. Si vous ne faites pas de supervision répartie, n'activez pas cette option.

Cette option définit la commande à lancer après chaque contrôle d'hôte, ce qui peut être utile dans une supervision répartie. Elle est exécutée après les éventuelles commandes de gestion d'événement ou de notification. L'argument commande est le nom court d'une définition de commande que vous avez définie dans le fichier de configuration des hôtes. Cette option sert dans le cadre de la supervision répartie. Le temps d'exécution maximal de cette commande est déterminé par la variable la section intitulée «  ochp_timeout  » .Vous trouverez plus d'informations sur la supervision répartie ici. Cette commande n'est exécutée que si l'option de la section intitulée «  obsess_over_hosts  » est activée et que si le paramètre obsess_over_host dans la définition de l'hôte l'est aussi.

Cette valeur détermine si Nagios traitera les données liées aux performances des contrôles d'hôtes et de services.

Cette option vous permet de spécifier une commande qui sera lancée après chaque vérification d'hôte pour traiter les données de performance qui peuvent être retournées après la vérification. L'argument commande est le nom court d'une définition de commande que vous avez définie dans le fichier de configuration des objets. Cette commande est exécutée si l'option de la section intitulée «  process_performance_data  » est activée et si le paramètre process_perf_data ([NdT] : traitement des données de performance) dans la définition de l'hôte l'est aussi.

Cette option vous permet de spécifier une commande qui sera lancée après chaque vérification de service pour traiter les données de performance qui peuvent être retournées après la vérification. L'argument commande est le nom court d'une définition de commande que vous avez définie dans le fichier de configuration des objets. Cette commande est exécutée si l'option de traitement des données de performance est activée et si le paramètre process_perf_data ([NdT] : traitement des données de performance) est activé dans la définition du service. Cette commande est seulement exécuté que si la variable la section intitulée «  obsess_over_services  » est entièrement activée et que si le paramètre process_perf_data dans la définition du service l'est aussi.

Cette option vous permet de spécifier un fichier dans lequel les données de performance vont être écrites après chaque vérification d'hôte. Les données seront écrites dans ce fichier comme spécifié dans le la section intitulée «  host_perfdata_file_template  » .Les données ne seront écrites que si l'option de la section intitulée «  process_performance_data  » est activée et si le paramètre process_perf_data ([NdT] : traitement des données de performance) est activé dans la définition de l'hôte. process_perf_data que si le paramètre dans la définition de l'hôte l'est aussi.

Cette option vous permet de spécifier un fichier dans lequel les données de performance vont être écrites après chaque vérification de service. Les données seront écrites dans ce fichier comme spécifié dans le la section intitulée «  service_perfdata_file_template  » .Les données ne seront écrites que si l'option de la section intitulée «  process_performance_data  » est activée et si le paramètre process_perf_data ([NdT] : traitement des données de performance) est activé dans la définition du service. Cette commande est seulement exécuté que si la variable la section intitulée «  obsess_over_services  » est entièrement activée et que si le paramètre process_perf_data dans la définition du service l'est aussi.

Cette option détermine ce qui va être écrit (et comment) dans le fichier de performance des hôtes .Le patron peut contenir des macros, des caractères spéciaux (\t pour une tabulation, \r un retour charriot, \n pour un retour à la ligne). Un retour à la ligne est ajouté après chaque écriture des données de performance.

Cette option détermine ce qui va être écrit (et comment) dans le fichier de performance des services .Le patron peut contenir des macros, des caractères spéciaux (\t pour une tabulation, \r un retour charriot, \n pour un retour à la ligne). Un retour à la ligne est ajouté après chaque écriture des données de performance.

Cette option détermine si le fichier de performance des hôtes est ouvert en mode écrasement ou ajout. A moins que le fichier ne soit un tube nommé [named pipe], vous voudrez certainement utiliser l'option par défaut ajout.

Cette option détermine si le fichier de performance des services est ouvert en mode écrasement ou ajout. A moins que le fichier ne soit un tube nommé [named pipe], vous voudrez certainement utiliser l'option par défaut ajout.

Cette option vous permet de spécifier l'intervalle (en secondes) entre deux traitements du fichier de performance des hôtes par la commande de performance liée aux hôtes .Une valeur de 0 signifie que le traitement n'aura pas lieu de manière régulière.

Cette option vous permet de spécifier l'intervalle (en secondes) entre deux traitements du fichier de performance des services par la commande de performance liée aux services .Une valeur de 0 signifie que le traitement n'aura pas lieu de manière régulière.

Cette option vous permet de définir la commande qui sera exécutée pour le traîtement du fichier de performance des hôtes .L'argument commande est le nom court d'une définition de commande que vous avez définie dans le fichier de configuration des objets. L'intervalle entre deux traitements est indiqué par l'intervalle de traitement du fichier de performance des hôtes .

Cette option vous permet de définir la commande qui sera exécutée pour le traîtement du fichier de performance des services .L'argument commande est le nom court d'une définition de commande que vous avez définie dans le fichier de configuration des objets. L'intervalle entre deux traitements est indiqué par la section intitulée «  service_perfdata_file_processing_interval  » .

Cette option vous permet d'activer ou désactiver la vérification des contrôles de service orphelins. Les contrôles de service orphelins sont des contrôles ayant été exécutés et supprimés de la file des événements, mais dont les résultats n'ont pas été remontés depuis longtemps.

Comme aucun résultat n'a été remontée pour ce service, il n'est pas réordonnancé dans la file d'événements. Cela peut causer l'arrêt des contrôles du service. Normalement, c'est un phénomène très rare - il peut se produire si un utilisateur ou un processus extérieur a tué le processus utilisé pour exécuter le contrôle de service.

Si cette option est activée et que Nagios s'aperçoit qu'un résultat de contrôle de service particulier ne revient pas, il journalisera un message d'erreur, et réordonnancera le contrôle de service. Si vous constatez que certains contrôles de service semblent n'être jamais réordonnancés, activez cette option et cherchez dans les journaux, des messages concernant des services orphelins.

Cette option vous permet d'activer ou désactiver la vérification des contrôles d'hôte orphelins. Les contrôles d'hôte orphelins sont des contrôles ayant été exécutés et supprimés de la file des événements, mais dont les résultats n'ont pas été remontés depuis longtemps.

Comme aucun résultat n'a été remontée pour cet hôte, il n'est pas réordonnancé dans la file d'événements. Cela peut causer l'arrêt des contrôles de l'hôte. Normalement, c'est un phénomène très rare - il peut se produire si un utilisateur ou un processus extérieur a tué le processus utilisé pour exécuter le contrôle de l'hôte.

Si cette option est activée et que Nagios s'aperçoit qu'un résultat de contrôle de l'hôte particulier ne revient pas, il journalisera un message d'erreur, et réordonnancera le contrôle de l'hôte. Si vous constatez que certains contrôles de l'hôte semblent n'être jamais réordonnancés, activez cette option et cherchez dans les journaux, des messages concernant des hôtes orphelins.

Cette option détermine si Nagios va contrôler ou non périodiquement la validité des données d'un service. L'activation de cette option aide à contrôler que les contrôles de service passifs sont reçus en temps et en heure. On peut trouver plus d'informations sur cette option ici.

Cette option détermine l'intervalle de temps (en secondes) entre deux contrôles de validité des données d'un service. Si vous avez désactivé ce service, avec l'option de contrôle de validité des données d'un service ,cette option n'a pas d'effet. Vous pouvez trouver plus d'informations sur ce service ici.

Cette option détermine si Nagios va contrôler ou non périodiquement la validité des données d'un hôte. L'activation de cette option aide à contrôler que les contrôles passifs des hôtes sont reçus en temps et en heure. On peut trouver plus d'informations sur cette option ici.

Cette option détermine l'intervalle de temps (en secondes) entre deux contrôles de validité des données d'un hôte. Si vous avez désactivé ce service, avec l'option de contrôle de validité des données d'un hôte ,cette option n'a pas d'effet. Vous pouvez trouver plus d'informations sur ce service ici.

Cette option détermine le nombres de secondes que Nagios ajoutera pour qu'un hôte ou un service se rafraichisse (Ce n'est pas déterminé nativement par l'utilisateur). Vous trouverez plus d'informations ici.

Cette option détermine ou non si l'interpréteur Perl est activé dans le cœur du programme. Nagios doit être compilé en précisant cette option pour que ce paramétrage soit opérationnel. Vous trouverez plus d'informations à ce sujet ici.

Cette option détermine si oui ou non l'interpréteur Perl sera utilisé lors d'utilisation de plugins/scripts perl. Nagios doit être compilé en précisant cette option pour que ce paramétrage soit opérationnel. Vous trouverez plus d'informations à ce sujet ici.

Cette option spécifie le format de date que Nagios utilisera dans l'interface web. Les options possibles sont :

Cette option vous autorise à définir la plage horaire par défaut à l'instance Nagios. Ceci est très utile si vous possédez plusieurs instances Nagios tournant sur le même serveur, mais avec différentes localités associées. Si vous ne spécifiez rien, Nagios prend celle du système par défaut.

<Directory "/usr/local/nagios/sbin/">
    SetEnv TZ "US/Mountain"
    ...
</Directory>
                

Cette option vous permet de spécifier quels sont les caractères illégaux dans les noms d'objets, tels qu'hôtes, services et autres. Nagios vous autorisera la plupart des caractères dans les définitions d'objets, mais je recommande de ne pas utiliser les caractères ci-dessus. Le faire vous expose à des problèmes dans l'interface web, les notifications de commandes, etc.

Cette option vous permet de spécifier les caractères illégaux qui seront filtrés dans les macros, avant qu'elles ne soient utilisées dans les notifications, les gestionnaires d'événements et autres commandes. Ceci n'affecte pas les macros utilisées dans les contrôles des services ou des hôtes. Vous pouvez choisir de ne pas filtrer les caractères donnés en exemple ci-dessus, mais je vous le le déconseille. Quelques uns d'entre eux sont interprétés par le shell ( par exemple, le ` ) et peuvent poser des problèmes de sécurité. Les macros suivantes sont débarrassées des caractères spécifiés dans l'option :

Cette option détermine si les paramètres dans vos définitions d'objet seront traités comme des expressions rationnelles. Vous pouvez trouver plus d'informations sur ce service ici.

Si vous avez activé la concordance par expression rationnelle, cette option va déterminer quand les paramètres vont être traités comme des expressions rationnelles : * Si cette option est désactivée (par défaut), les paramètres seront traités comme des expression rationnelles uniquement si elles contiennent un *, ?, +, ou un \ … * Si cette option est activée, toutes les paramètres seront traités comme des expressions rationnelles. Faîtes très attention lorsque vous activez cette option! Pour plus d'informations, lisez ceci.

C'est l'adresse mail de l'administrateur local de la machine (i.e. celle sur laquelle Nagios tourne). Cette valeur peut être utilisée dans les commandes de notification grâce à la macro $ADMINEMAIL$.

C'est le numéro du pager (ou la passerelle pager-email) de l'administrateur de la machine locale (i.e. celle sur laquelle Nagios tourne). Le numéro ou l'adresse de pager peut être utilisé dans les commandes de notification grâce à la macro $ADMINPAGER$ .

Cette option contrôle que les données (si plusieurs) seront envoyées au courtier d'événement et, ensuite, chargées dans le module du courtier d'événement. Il s'agit d'une option avancée. Dans le doute, ne transportez rien (si vous n'utilisez aucun modules) ou choisissez de tout transporter (si vous utilisez des modules). Les valeurs possibles sont les suivantes:

Ce paramètre est particulièrement utilisé pour que le module événementiel soit chargé au démarrage de Nagios. On peut utiliser plusieurs de ces mêmes paramètres si l'on veut en charger plusieurs. Les arguments passés au module seront séparés par un espace.

La manière la plus sûre de mettre à jour un module est l'une des méthodes suivantes:

Cette option détermine si oui ou non Nagios peut écrire des informations de débogage. La précision des informations que Nagios écrit dépend des options debug_level et debug_verbosity. Vous pouvez automatiquement gérer la rotation du fichier de débogage en fonction de sa taille en utilisant l'option la section intitulée «  max_debug_file_size  »

Cette option détermine quel type d'information Nagios doit écrire dans la section intitulée «  debug_file  ».Les valeurs possibles sont les suivantes:

Cette option détermine la quantité d'information de débogage que Nagios doit écrire dans le fichier de débogage .

Cette option détermine la taille maximum (en octets) du fichier de débogage .Si le fichier dépasse la taille que vous avez indiqué, il sera renommé avec une extension en .old. Si le fichier .old existe déjà, il sera automatiquement effacé. Cette option vous permet de garder un contrôle sur l'espace disque que Nagios prend quand il se trouve en mode de débogage.