BE Nagios Etude de la logique de supervision dans Nagios 3 A l attention de M T.Desprats & M E.Lavinal Aboubacar BARRY Benjamin PICARD Romain LAMOUR Vincent WATREMEZ 07/01/11 M1 STRI Bureau d étude - Nagios - 1 -
Bureau d étude - Nagios - 2 -
Sommaire I. INTRODUCTION... 5 II. ARCHITECTURE ET FONCTIONNEMENT DE NAGIOS... 6 A) L ARCHITECTURE... 6 1. Le Cœur... 6 2. Base de données... 6 3. CGI (Common Gateway Interface)... 6 4. L Interface Web... 7 5. Les Plugins... 7 B) LES MODES DE SUPERVISION... 7 1. Contrôles Actifs... 7 2. Contrôles Passifs... 8 C) OBJETS SUPERVISES... 8 1. Les hôtes... 8 2. Les Services... 9 3. Les contacts... 10 III. LOGIQUE DE SUPERVISION... 10 A) LOGIQUE DE CONNECTIVITE... 10 1. Relation à parent unique... 11 2. Relation à plusieurs parents... 11 3. Exemple de réseau... 12 B) LES DEPENDANCES... 13 1. Dépendances Réseaux... 13 2. Dépendance Applicatives... 16 C) VERIFICATION PREDICTIVE DES DEPENDANCES... 18 1. Mise en œuvre des contrôles prédictifs... 18 2. Quelles limites?... 19 D) SUPERVISION ADAPTATIVE... 20 E) GESTION DU CACHE... 21 1. Définition générale... 21 2. Intérêt du Cache dans Nagios... 21 3. Fonctionnement... 21 4. Limite... 21 IV. LA MAQUETTE DE TESTS... 22 1. Schéma physique... 22 2. Réalisation de la logique de connectivité... 23 3. Dépendances réseaux... 24 V. CONCLUSION... 25 Bureau d étude - Nagios - 3 -
VI. SOURCES... 26 F) BIBLIOGRAPHIE... 26 G) WEBOGRAPHIE... 26 VII. ANNEXES... 27 A) OPTIONS DES HOTES... 27 B) OPTIONS DES SERVICES... 29 C) OPTIONS DES CONTACTS... 32 D) ORDONNANCEUR : ETALEMENT DES VERIFICATIONS... 33 E) HOSTDEPENDENCY... 34 F) SERVICEDEPENDENCY... 35 G) SUPERVISION ADAPTATIVE... 35 H) MAQUETTE DE TEST... 37 1. Installation de Nagios... 37 2. Configuration des équipements & machines... 39 3. Fichiers de configuration de Nagios... 40 Bureau d étude - Nagios - 4 -
I. Introduction En informatique, la supervision est l un des domaines fonctionnels de l administrateur réseau. Cependant on pourrait se poser la question : Pourquoi superviser? La supervision réseau permet de prévoir et anticiper les «problèmes», ou encore trouver plus rapidement, plus facilement la cause d une anomalie. Ce rapport a pour but d effectuer une étude approfondie de la logique de supervision du logiciel Nagios 3. Celui-ci est un logiciel Open Source, créé en 1999, il permet de superviser un système complet et est conçu de façon modulaire. Dans un premier temps, nous allons analyser l architecture de Nagios, ainsi que ses principaux mécanismes de supervisions. Par la suite, nous réaliserons une étude approfondie de sa logique. Enfin, nous présenterons une maquette que nous avons réalisée dans le but de tester et vérifier cette logique. Bureau d étude - Nagios - 5 -
II. Architecture et fonctionnement de Nagios a) L architecture L architecture globale de Nagios se présente ainsi : Img 1 Architecture globale de Nagios Nous allons en détailler chaque élément dans la suite de cette partie. 1. Le Cœur Le cœur de Nagios consiste avant tout en un moteur d'ordonnancement. Cet ordonnanceur gère le séquencement des vérifications, ainsi que des événements, tels que les alertes, les escalades (notifications progressives en fonction du temps) et les actions correctives. Il est important d étaler au maximum les vérifications pour lisser la charge qui risque d être trop importante pour que les sondes aillent au bout de leurs tâches. (cf. annexe : pour plus d information sur l étalement des vérifications) 2. Base de données Permet d enregistrer des événements, les données de performances relatives aux contrôles et aux plugins. Dans le cas d instances multiples de Nagios, cette base de données permet de centraliser leurs informations. 3. CGI (Common Gateway Interface) C est une interface utilisée par un serveur http permettant d intégrer des services écrits dans différents langages de programmation. Bureau d étude - Nagios - 6 -
4. L Interface Web C est une interface graphique qui permet d avoir une visualisation complète des hôtes et ressources supervisés. De plus, il est possible de gérer une partie de la configuration via cette interface. 5. Les Plugins Les plugins sont des programmes exécutables ou des scripts qui permettent de déterminer le statut des hôtes ou services sur le réseau. Ces plugins peuvent être développés avec n importe quel langage de programmation mais doivent respecter un certains formats d affichage de retour afin de garantir leur interopérabilité. La convention à respecter est la suivante : 0 : «Tout va bien» (OK) 1 : Avertissement (WARNING) 2 : Alerte (CRITICAL) 3 : Statut inconnu (UNKNOWN) b) Les modes de supervision Nagios est capable de contrôler des hôtes et des services de deux façons : activement et passivement. 1. Contrôles Actifs Les contrôles actifs représentent la méthode la plus commune pour superviser des hôtes et services. Les principales fonctionnalités des contrôles actifs sont initiées par le processus Nagios et sont exécutées à intervalle régulier ou à la demande quand nécessaire. Lorsque Nagios a besoin de connaître l état d un hôte ou service, il exécute un plugin et lui passe en paramètre les informations sur ce qu il a besoin de contrôler. Le plugin va donc contrôler l état opérationnel de l hôte ou du service et renvoyer les résultats en retour au démon Nagios. Celui-ci va traiter les résultats et effectuer les actions appropriées (envoyer des notifications, lancer un gestionnaire d événement ). Requête Réponse Img 2 Échange en contrôle actif Bureau d étude - Nagios - 7 -
2. Contrôles Passifs La plupart du temps, on utilisera Nagios pour réaliser des contrôles actifs mais il existe aussi un autre moyen de contrôle «passif». Le contrôle passif a comme atout le fait de pouvoir être lancé et exécuté par des applications externes et ensuite les résultats sont soumis à Nagios pour le traitement. Les contrôles passifs sont utiles pour superviser des services asynchrones et ne peuvent donc pas être contrôlés activement de manière sûre (ex : on ne sait jamais à quel moment une faille de sécurité peut être franchie, il n est donc pas envisageable de contrôler leur statut toutes les deux ou trois minutes). Il peut être également utilisé pour superviser des services situé derrière un firewall car ils ne peuvent pas être contrôlés depuis l hôte supportant Nagios. Trap Img 3 Échange en contrôle passif c) Objets supervisés Nagios définit deux types d objets à superviser : Les hosts Les services 1. Les hôtes Se sont les nœuds ou ressources à surveiller tel que les serveurs, ordinateurs, routeurs, imprimantes, switchs. Un hôte est donc défini par une adresse IP ou MAC, par un ou plusieurs services et peut avoir des relations avec d autres hôtes tel que Parent/Enfant. Ces dernières sont utilisées dans la logique de supervision que nous verrons un peu plus tard dans ce rapport. Différents états sont possibles pour un hôte : o UP : Le nœud est en état de répondre. o DOWN : Le nœud est indisponible. o UNREACHABLE : L état du nœud n est pas connu car il se situe derrière un équipement qui est tombé. o FLAPPING : Un hôte passe d un état à un autre périodiquement, il fait le «yoyo». Nagios permet de définir des groupes d hôtes qui offrent une vue d état facile au niveau de l interface de Nagios. Bureau d étude - Nagios - 8 -
Les hôtes sont définis dans le fichier «hosts.cfg» et les groupes de services dans le fichier «hostsgroups.cfg». define host { host_name server-web alias Serveur Web 1 address 127.0.0.1 check_command check-host-alive check_interval 5 max_check_attempts 3 contact_groups admin-web Pour plus d information sur les variables du fichier hosts.cfg, confère la partie «Option des hôtes» dans les pages annexes. 2. Les Services Les services sont les objets les plus importants dans la logique de supervision de Nagios. Ce sont les points supervisés sur un hôte comme la charge CPU par exemple. Différents états sont possibles pour les services : o OK : Tout est bon sur l élément supervisé. o WARNING : Un problème commence à apparaître (Ex : disque presque plein). o CRITICAL : La situation est critique, il faut intervenir (Ex : disque plein). o UNKNOWN : La commande de vérification n a pas pu obtenir les informations recherchées (Ex : mauvais argument dans la commande). De la même manière que pour les hôtes, Nagios permet de définir des groupes de services. Les services sont définis dans le fichier «services.cfg» et les groupes de services dans le fichier «servicesgroups.cfg». define service { host_name server-web service_description http check_command check_tcp!80 max_check_attempts 3 contact_groups admin-web Pour plus d information sur les variables du fichier services.cfg, confère la partie «Option des services» dans les pages annexes. Bureau d étude - Nagios - 9 -
3. Les contacts Etude de la logique de supervision dans Nagios 3 A noter également que dans Nagios, il y a une notion très importante, c est la notion de contact. En effet, il est possible de définir des contacts ainsi que des groupes de contacts. Les contacts sont les objets qui vont permettre recevoir les alertes. (cf. Annexe : Définition d un contact) define contact { contact_name bpicard alias Benjamin Picard contactgroups Admin_web host_notifications_enabled 1 service_notifications_enabled 1 Pour plus d information sur les variables du fichier contacts.cfg, confère la partie «Option des contacts» dans les pages annexes. Limite : il faut savoir que cette méthode de configuration est assez fastidieuse notamment lorsque l on possède un vaste réseau, ce qui est le cas pour de nombreuses entreprises. En effet, il faut définir chaque hôte et chaque service que l on souhaite superviser et donc connaître parfaitement son réseau, ce qui est difficile sur un vaste réseau. III. Logique de supervision a) Logique de connectivité Nagios doit faire la différence entre les états DOWN et UNREACHABLE des hôtes. Ces deux états sont différents (mais en relation). Lorsqu un équipement est en état DOWN, tous les éléments situés «après» seront en état UNREACHABLE. Cela est dû au serveur Nagios ne peut pas déterminer leurs états du fait qu il faut passer par l équipement qui a un problème. On pourra donc trouver plus rapidement la cause de problèmes réseaux et éviter d être noyé de notifications, car on ne notifiera pas les états UNREACHABLE. Pour mettre en place ce dispositif, on doit préciser la façon dont ils sont connectés les uns aux autres en se plaçant du point de vue du serveur Nagios. Chaque routeur, switch, serveur que le paquet doit traverser sera considéré comme une étape et on devra définir une relation parent/enfant dans Nagios. Bureau d étude - Nagios - 10 -
L administrateur devra donc effectuer un arbre topologique dont la racine sera le serveur de supervision. Chaque hôte peut avoir un ou plusieurs parents auquel il est connecté. L hôte Nagios ne peut pas avoir de parent! 1. Relation à parent unique L image 2 présente un exemple de relation à parent unique Parents Nagios Routeur Switch Enfants Routeur Switch Serveur http Imprimante PC Img 4 Arbre Simple Exemple de configuration : define host { host_name Imprimante parents Switch define host { host_name parents Switch Routeur define host { host_name parents Routeur Serveur Nagios 2. Relation à plusieurs parents L image 3 présente un exemple de liens où un nœud a plusieurs parents. Parents Enfants Nagios Routeur 1 Routeur 1 Routeur 2 Routeur 3 Img 5 Arbre complexe Exemple de configuration : define host { host_name Serveur DNS parents Routeur 2, Routeur 3 Routeur 2 Routeur 3 define host { host_name Serveur HTTP parents Routeur 2, Routeur 3 Serveur http Serveur DNS Serveur http Serveur DNS define host { host_name Routeur 2 parents Routeur 1 Bureau d étude - Nagios - 11 -
3. Exemple de réseau Dans cet exemple, nous souhaitons superviser l ensemble des hôtes (serveurs, routeurs, switch, imprimante) figurant sur l image 4. Nagios sera installé sur le «serveur Nagios». Img 6 Architecture physique Pour définir les relations parents/enfants, nous allons effectuer un arbre topologique dont la racine sera le serveur Nagios. Maintenant que nous savons la représentation des relations parent/enfant des hôtes supervisés, nous pouvons configurer nos hôtes en fonction de cet arbre : define host { host_name define host { host_name parents define host { Serveur Nagios Switch Serveur Nagios host_name Routeur 1 parents Switch Img 7 Arbre logique (A faire pour chaque hôte) Bureau d étude - Nagios - 12 -
Cette méthode de configuration peut largement être critiquée : - L a configuration peut être fastidieuse si le réseau est grand car chaque équipement que l on souhaite superviser doit être configuré par un fichier texte. - L emplacement du serveur Nagios doit bien être choisi car si l on souhaite le déplacer, l arbre logique sera à refaire et donc tous les «parents/enfants» seront à redéfinir. - Il est préférable que le serveur Nagios ait plusieurs fils. En effet, si il en a que un, et qu il devient DOWN, alors tout le réseau supervisé sera UNREACHABLE, on aura donc aucune visibilité de notre réseau. b) Les dépendances Les systèmes d information, de nos jours, sont des systèmes vastes. Une anomalie sur un hôte peut se répercuter sur d autres éléments et ainsi de suite, ce qui peut devenir vite «cauchemardesque». Nagios permet de gérer ce genre de problème en intégrant dans sa logique de supervision le principe de dépendances. Ces relations de dépendances peuvent être physiques, ou réseaux, (par exemple : un lien entre un routeur et un serveur) ou encore virtuelles, ou applicatives, (comme par exemple : une application et sa base de données). Ce système permet de filtrer les alertes, pour avoir uniquement celles qui sont à l origine de tous ces problèmes. 1. Dépendances Réseaux L attribut parent Ces dépendances, se définissent dans le fichier «hosts.cfg», à l aide de l argument «parents», comme vous avez pu le voir précédemment. Parmi ces dépendances, deux cas se distinguent : La perte de réseau ne touche qu un équipement terminal, par exemple un serveur. L administrateur ne reçoit qu une seule alerte lui indiquant que l élément est DOWN. De plus, les alertes au niveau des services ne sont pas envoyées puisque l élément est déclaré comme DOWN. Bureau d étude - Nagios - 13 -
La perte de réseau touche un équipement réseau comme un routeur. Nagios va remarquer qu il ne peut pas contacter un nœud. Il va donc remonter l arbre de parenté en testant la disponibilité de chaque élément. Le dernier élément ne répondant pas est passé à l état DOWN, ses fils (tous les nœuds se trouvant derrière) passent à l état UNREACHABLE. Exemple 1 : L hôte «Serveur Appli» n est pas joignable. Img 8 Dépendances simples Aucune réponse Aucune réponse Routeur 1 Routeur 1 : DOWN Les enfants : UNREACHABLE Aucune réponse Routeur 2 Serveur Appli Bureau d étude - Nagios - 14 -
Exemple 2 : L hôte «Serveur HTTP» n est pas joignable. Img 9 Dépendances multiples Routeur 1 : Down Les enfants : UNREACHABLE Routeur 3 Routeur 1 Routeur 2 Serveur HTTP La notion d hostdependency Il existe aussi la notion de «hostdependency». Cette notion permet de supprimer des notifications, ainsi que des contrôles actifs d'hôtes en se basant sur l'état d'un ou de plusieurs autres hôtes. Ce type de dépendances se définit dans le fichier «nagios.cfg», comme suit : define hostdependency { dependent_host_name RouteurX dependent_hostgroup_name Routeurs host_name Serv 1 hostgroup_name Serveurs inherits_parent 0 execution_failure_criteria o, d, u notification_failure_criteria o, d, u dependency_period 24x7 Bureau d étude - Nagios - 15 -
2. Dépendance Applicatives Nagios permet également de définir des dépendances applicatives. Qu est-ce qu une dépendance applicative? C est une dépendance entre services, c est-à-dire que le bon fonctionnement d un service dépendant de l état d un autre. Cette notion permet de filtrer les alertes. En effet, prenons deux services A et B, B ayant besoin que A fonctionne correctement. Si le service A «tombe», il est intéressant de recevoir cette alerte mais pas celle du service B, il est même inutile de vérifier le bon fonctionnement du service B. Ce qu il faut retenir, c est que si un service dépend d un ou plusieurs autres, Nagios annule la supervision ou l envoi de notification si un seul des services est dans un état inquiétant tel que : WARNING ou CRITICAL. Ces dépendances se définissent dans le fichier «nagios.cfg», comme suit : define servicedependency { dependent_hostgroup_name Serveur-Web-BDD dependent_service_description Base de données host_name Serv-Web1 hostgroup_name Serv-Web service_description service_description inherits_parent 0 execution_failure_criteria w, u, c notification_failure_criteria w, u, c dependency_period 24x7 Pour plus d information sur les différents attributs, confère «Servicedependency» en annexe. Bureau d étude - Nagios - 16 -
Exemple 1 : Dépendance simple = Prenons un service «Serv-A» sur le serveur web et un service «Serv-B», une base de données sur le serveur de base de données. Dépendances Applicatives Img 10 Dépendance simple de services Le serveur Nagios reçoit une alerte sur le service B du serveur de base de données. Il va regarder ses dépendances au niveau des services, il s aperçoit que le service A dépend du service B qui vient de transmettre une alerte. Par conséquent, il annule la surveillance sur le service A, ainsi que l envoi d alerte. Exemple 2 : Multi-dépendance = Prenons le service 1 qui dépend du service 2 et 4. Dépendances Applicatives Img 11 Dépendance multiple de services Le serveur Nagios reçoit une alerte sur le service 4 du serveur B. Il va regarder ses dépendances au niveau des services, il s aperçoit que le service 1 dépend de l état des services 2 et 4. L un d entre eux étant dans un état inacceptable, il annule la surveillance et l envoi de notification concernant le service 1. Bureau d étude - Nagios - 17 -
c) Vérification prédictive des dépendances Les dépendances sont un élément clé du processus de supervision, puisque lorsqu un contrôle se déclenche, leur «fraîcheur» (entendre par là la fréquence de mise-à-jour) détermine l exactitude du contrôle. Dans des réseaux ou systèmes tant-soit-peu complexes en termes de dépendances, cette problématique devient rapidement non négligeable et un mauvais ordonnancement des contrôles entraîne des retours non représentatifs des états des services ou hôtes en question. Pour remédier à cela, Nagios dispose d une fonctionnalité de vérification prédictive des dépendances. Grâce à celle-ci, le système de supervision s assure que la logique de supervision dispose des informations les plus actuelles avant de décider d un envoi de notification ou du contrôle actif d un hôte ou service. 1. Mise en œuvre des contrôles prédictifs La Pour étudier le fonctionnement des contrôles prédictifs de dépendances, nous allons nous appuyer sur un simple cas d étude : Bureau d étude - Nagios - 18 -
Lorsque le commutateur 2 passe dans un état autre qu UP, le système de supervision a besoin de déterminer si le commutateur est DOWN ou UNREACHABLE avant de prendre une décision en conséquence. Nagios lance donc des vérifications parallèles sur les hôtes parents et enfants du commutateur, ce qui correspond à la logique classique de contrôle d accessibilité des hôtes. Or, le commutateur 2 est dépendant du serveur de fichiers Samba et du moniteur. Si les contrôles prédictifs sont activés, Nagios lance des contrôles supplémentaires au niveau de ces deux hôtes interdépendants avec le commutateur. Ce faisant, Nagios satisfait à la logique de vérification prédictive en rafraîchissant les états de ces hôtes : Le système de supervision dispose des états les plus récents possibles des hôtes dépendants du commutateur 2 (qui pourraient donc être impactés par son changement d état), et ce, juste avant d être susceptible de mener des contrôles en rapport avec ces dépendances. Notons qu il s agit d une vérification prédictive d hôtes, à laquelle les vérifications prédictives de services sont similaires. 2. Quelles limites? La mise en œuvre des vérifications prédictives ne requiert pas beaucoup de ressources. Cette charge est souvent contrebalancée par le fait d avoir les informations les plus pertinentes pour mettre en œuvre la logique de dépendance. Mais encore faut-il disposer des ressources nécessaires pour ce faire ; il faut donc correctement dimensionner son système de supervision. Cette fonctionnalité souligne aussi l importance de créer les dépendances avec pertinence et de sélectionner les valeurs des hôtes ou services qui seront les meilleurs indicateurs d échec. Bureau d étude - Nagios - 19 -
d) Supervision Adaptative Nagios permet de modifier les paramètres des commandes de vérification des hôtes ou des services, à l exécution. Pour pouvoir effectuer ce changement, il faut soumettre, au serveur Nagios, la commande externe appropriée. Il faut noter que toutes les commandes de vérification ne peuvent pas être modifiées en cours d exécution, voici un exemple d attributs que l on peut modifier en cours d exécution : Prenons le contact suivant : define contact { contact_name bpicard alias Benjamin Picard contactgroups Admins_reseau host_notifications_enabled 1 service_notifications_enabled 1 host_notification_period 24x7 service_notification_period 24x7 host_notification_options d, u, r, f, service_notification_options w, u, c, r host_notification_commands host-notify-by-email service_notification_commands notify-by-email email bpicard@iupstri.com can_submit_commands 1 retain_status_information 1 retain_nonstatus_information 1 Supposons maintenant que ce contact ne souhaite recevoir des notifications que 5 jours par semaine 24h/24h. L administrateur de Nagios devra donc utiliser la commande suivante : CHANGE_CONTACT_HOST_NOTIFICATION_TIMEPERIOD; bpicard; 24x5 Pour plus d information sur les commandes de vérification que l on peut modifier en cours d exécution, confère «Supervision Adaptative» dans les pages annexes. Bureau d étude - Nagios - 20 -
e) Gestion du Cache 1. Définition générale Le mécanisme de cache permet de mémoriser temporairement des données afin de faciliter leur réutilisation. Dans la plupart des cas, le calcul de ces données est coûteux en temps et en ressources, d où l intérêt de les mettre en cache. Voici quelques exemples de mémoire cache : Mémoire cache des microprocesseurs Mémoire cache dans le cadre de navigation internet Mémoire cache de système de stockage Mémoire cache d application tel que les SGBD, Nagios. 2. Intérêt du Cache dans Nagios Nagios est un service supplémentaire pour les administrateurs, ce service ne doit pas être une source de réduction de performances. Ainsi, il doit être optimisé au maximum. Etant donné le nombre de vérifications et l impact de celles-ci sur les performances du système d information, un système de cache est surtout mis en place dans le cadre de vérifications supplémentaires. 3. Fonctionnement Les vérifications supplémentaires sont nécessaires pour les relations de parenté réseau ainsi que pour les dépendances de services afin de déterminer l origine exact d un dysfonctionnement, afin de ne pas lever de fausses alertes : ce sont des vérifications à la demande (on demand). Si un nœud ne répond pas, Nagios vérifie ses parents en fonction de l arborescence des éléments. Nagiosstat permet d avoir une vue d ensemble des tests et de leurs valeurs. Il n est pas rare qu un test de vérification précède un autre à quelques secondes d intervalle. Dans cette configuration, l état pourra ne pas avoir changé. Il serait intéressent de récupérer cette information en mémoire sans lancer de nouveau test couteux en temps et en ressources. Ce mécanisme est utilisé dans Nagios avec le cache de test. 4. Limite Si l utilisation du cache permet de gagner en performance, la contrepartie est la perte en précision. En effet, le problème du temps de validité des informations se pose dans tout système de cache. Un nœud peut avoir un fonctionnement normal à un instant T, et tomber à l instant (T + dt) ; ainsi, à l instant (T + dt), l information dans le cache est erronée car cette information correspond à celle calculée à l instant T. Bureau d étude - Nagios - 21 -
Cet inconvénient est l une des raisons pour laquelle certains administrateurs désactivent le cache en paramétrant le temps de validité à zéro. D autres accepteront le gain de performances par rapport à quelques imprécisions. Pour trouver un compromis on définit le cache «hit ratio» : Le rapport du nombre de tests pris en mémoire sur le nombre total de demandes de re-vérifications. IV. La maquette de tests Cette maquette a été réalisée dans le but de vérifier les différents points traités dans ce rapport. Pour cela, voici la description de notre architecture de test. 1. Schéma physique Notre architecture de test se compose : D un Serveur Nagios (Linux : UBUNTU), D un Serveur Web (Linux : UBUNTU), D un Serveur DNS (Linux : DEBIAN), D une Machine Cliente (Windows Seven), De deux Switchs, D un Routeur La configuration des différents équipements et machines, ainsi que le détail de l installation et de la configuration de Nagios se trouvent en annexe. Img 12 Architecture physique de la maquette Bureau d étude - Nagios - 22 -
2. Réalisation de la logique de connectivité Pour configurer la logique de connectivité, nous effectuons tout d abord, l arbre logique de notre maquette. Celui-ci permet de définir plus facilement la relation parents/enfants. Parents Nagios Switch sw1 Routeur RTR13 Switch sw2 Enfants Switch sw1 Client Windows Routeur RTR13 Switch sw2 Serveur Web Serveur DNS Img 13 Arbre logique de la maquette Maintenant, nous pouvant effectuer la configuration «parents/enfants» pour tous nos hôtes dans les fichiers de configuration (voir la configuration en annexe). Lors de la réalisation de la maquette, la supervision du switch sw2 ne fonctionnait pas. Nous avons donc décidé de ne pas le superviser. Cependant, cet équipement fait parti de notre architecture. Suite à notre configuration, l interface graphique de Nagios trace automatiquement le schéma de notre maquette de test. On constate, alors, qu il correspond bien à notre arbre logique que nous avons décris précédemment. Img 14 Arbre logique de Nagios & Tableau des services Bureau d étude - Nagios - 23 -
3. Dépendances réseaux Pour réaliser ce test, nous avons débranché le switch1. Nous observons bien que celui-ci devient «Down» au bout de quelques minutes et que les équipements situés après ce commutateur passent à l état «Unreachable» (Voir schéma ci-dessous). Img 15 carte dépendance réseaux Nous avons souhaité ne pas recevoir les notifications de type «Unreachable». C est pourquoi, nous recevons uniquement l alerte du switch sw1 qui est à l état «Down» mais pas les autres équipements dont le serveur ne peu pas déterminer l état. Par manque de temps dans la salle de TP, nous n avons pas pu effectuer la mise en place des dépendances de services et les contrôles prédictifs. Bureau d étude - Nagios - 24 -
V. Conclusion Ce bureau d étude nous a permis, de découvrir ou d approfondir nos connaissances sur le logiciel de supervision Nagios 3. En effet, nous avons étudié son architecture, ses différents modes de supervisions, sa logique de supervision, dans le but de tester et vérifier nos «découvertes». Nous avons donc vue que ce logiciel est performant et complet : mis en place de dépendances réseaux et applicatives, supervision adaptative, gestion du cache ou encore vérification prédictive. Cependant, nous avons noté quelques limites. La principale étant la complexité de configuration de Nagios pour un réseau étendu puisqu il faut connaître l architecture de celui-ci. Nagios est un logiciel basé sur des fichiers de configurations, cela devient vite difficile de se retrouver dans ces fichiers lorsqu il y a trop de services ou d hôtes à superviser. De plus, au niveau du cache, la validité des informations peut être remise en cause. Ce bureau d étude nous a également permis de nous mettre dans la «position» de professionnels. En effet, tous les membres ayant participé à cette étude ne pouvant être disponible, à certain moment, nous avons du trouver une organisation qui nous permette de terminer cette étude dans le temps imparti. Bureau d étude - Nagios - 25 -
VI. Sources f) Bibliographie Nagios 3 pour la supervision et la métrologie : «Déploiement, configuration et optimisation», de Jean Gabès, édition Eyrolles. Nagios au cœur de la supervision Open Source : «De l installation à l optimisation», d Olivier Jan, collection Epsilon. g) Webographie http://www.nagios.org/ http://wiki.monitoring-fr.org/nagios/start Bureau d étude - Nagios - 26 -
VII. Annexes En rouge, vous trouverez les attributs obligatoires. a) Options des hôtes Variables Valeurs possibles Description host_name Nom_machine Le nom «court» de l hôte alias Serv-Web Le nom «long» de la machine address 127.0.0.1 Adresse IP généralement display_name Serv-Web test Nom affiché sur l interface Web parents Nom_machine1, nom_machine2. Liste des hôtes parents de cette machine hostsgroups Machines serveurs Nom court des groupes d hôtes auxquels cette machine appartient check_command check-host-alive Nom court de la commande utilisé pour superviser l hôte initial_state UP (par défaut) Spécifie l état souhaité de la machine max_check_attempts 3 Nombre d essai d exécution de la commande si elle ne retourne pas OK check_interval 60 (par défaut) Délai entre chaque test (par défaut en minute) retry_interval 1 Délai d attente avant d ordonnancer un nouveau contrôle active_checks_enabled 0 ou 1 Définit si les contrôles actifs sont possibles passive_checks_enabled 0 ou 1 Définit si les contrôles passifs sont possibles check_period 24x7 Nom court de la période de temps pendant laquelle peuvent se dérouler les contrôles actifs obsess_over_host 0 ou 1 Définit si les contrôles pour cet hôte seront ou non «abusif» check_freshness 0 ou 1 Définit si les contrôles de «fraicheur» sont possibles pour cet hôte freshness_threshold 0 (par défaut) Définit un seuil de fraîcheur en seconde. event_handler restart-httpd Précise le nom court d une commande à exécuter à chaque changement d état. Bureau d étude - Nagios - 27 -
Variables Valeurs possibles Description event_handler_enabled 0 ou 1 Détermine si le gestionnaire d évènement est activé ou non pour cet hôte low_flap_threshold 25.0 Définit le seuil bas de détection d oscillation pour l hôte (en pourcent) high_flap_threshold 50.0 Définit le seuil haut de détection d oscillation pour l hôte (en pourcent) flap_detection_enabled 0 ou 1 Détermine si la détection d oscillation est active ou non flap_detection_options o, d, u Détermine quels états seront utilisés pour la logique de détection d oscillation process_perf_data 0 ou 1 Détermine si le traitement des données de performance est activé ou non retain_status_information 0 ou 1 Déterminer si les informations relatives aux états de l'hôte sont conservées ou non après redémarrage du programme retain_nonstatus_information 0 ou 1 Déterminer si les informations, hormis les états de l'hôte, sont conservées après redémarrage du programme contacts bpicard Noms cours des contacts qui doivent être notifié lors d un problème contact_groups Admins_reseau Noms cours des groupes de contacts qui doivent être notifié lors d un problème notification_interval 0 Unité de temps avant de re-notifier un contact (en minutes) first_notification_delay 0 Délai d attente avant d envoyer la première notification (en minutes) notification_period 24x7 Nom court des périodes de temps pendant lesquelles les notifications d'événements sont envoyées aux contacts notification_options d, u, r, f, s Déterminer quand les notifications pour un hôte doivent être envoyées notifications_enabled 0 ou 1 Déterminer si les notifications pour cet hôte sont activées ou non talking_options o, d, u Déterminer quelle mémorisation d'états est utilisée pour l'hôte Bureau d étude - Nagios - 28 -
Variables Valeurs possibles Description Préciser une note d'information à rattacher notes Serveur de test à l'hôte, qui sera affichée sur l interface web notes_url ~/notes/serveur_test.php Définit une URL optionnelle fournissant des informations supplémentaires sur l'hôte action_url ~/notes/actions.php Définit une URL optionnelle fournissant des actions supplémentaires à appliquer à l'hôte icon_image Serveur_web.png Définit le nom d'une image au format GIF, PNG ou JPG à associer à l'hôte, utilisé à différents endroits dans l interface web vrml_image Fond_serv_web.png Définit le nom d'une image au format GIF, PNG ou JPG à associer à l'hôte, utilisé comme fond de carte pour l hôte statusmap_image map.png Définit le nom d'une image à associer à l'hôte dans le CGI «statusmap» 2d_coords (20,40) Définit les coordonnées à utiliser pour l'hôte dans le CGI «statusmap» 3d_coords (5.2, 3.6, 2.0) Définit les coordonnées de l'hôte à utiliser dans le CGI «statuswrl» b) Options des services Variables Valeurs possibles Description host_name Nom_machine Le nom «court» de l hôte sur lequel tourne le service hostgroup_name Machines serveurs Précise le nom court des groupes d'hôtes sur lequel le service tourne ou avec lequel il est associé service_description check-disk-sda1 Description du service display_name Charge disque Nom du service affiché sur l interface Web servicegroups Services_Web Noms courts des groupes de services auxquels appartient ce service is_volatile 0 ou 1 Précise si un service doit être considéré comme volatile check_command check-disk!/dev/sda1 Nom court de la commande à utiliser pour contrôler l'état du service initial_state UP (par défaut) Spécifie l état souhaité du service max_check_attempts 3 Nombre d essai d exécution de la commande si elle ne retourne pas OK check_interval 60 (par défaut) Délai à attendre avant d'ordonnancer le contrôle régulier suivant du service Bureau d étude - Nagios - 29 -
Variables Valeurs possibles Description retry_interval 1 Délai à attendre avant d'ordonnancer un nouveau contrôle du service active_checks_enabled 0 ou 1 Définit si les contrôles actifs sont possibles passive_checks_enabled 0 ou 1 Définit si les contrôles passifs sont possibles check_period 24x7 Nom court de la période de temps pendant laquelle peuvent se dérouler les contrôles actifs obsess_over_service 0 ou 1 Définit si les contrôles pour ce service seront ou non «abusif» check_freshness 0 ou 1 Définit si les contrôles de «fraicheur» sont possibles pour ce service freshness_threshold 0 (par défaut) Définit un seuil de fraîcheur en seconde. event_handler restart-httpd Précise le nom court d une commande à exécuter à chaque changement d état. event_handler_enabled 0 ou 1 Détermine si le gestionnaire d évènement est activé ou non pour ce service low_flap_threshold 25.0 Définit le seuil bas de détection d oscillation pour le service (en pourcent) high_flap_threshold 50.0 Définit le seuil haut de détection d oscillation pour le service (en pourcent) flap_detection_enabled 0 ou 1 Détermine si la détection d oscillation est active ou non flap_detection_options o, d, u Détermine quels états seront utilisés pour la logique de détection d oscillation process_perf_data 0 ou 1 Détermine si le traitement des données de performance est activé ou non retain_status_information 0 ou 1 Déterminer si les informations relatives aux états du service sont conservées ou non après redémarrage du programme retain_nonstatus_information 0 ou 1 Déterminer si les informations, hormis les états du service, sont conservées après redémarrage du programme Bureau d étude - Nagios - 30 -
Variables Valeurs possibles Description notification_interval 0 Délai à attendre avant de renotifier un contact (en minutes) first_notification_delay 0 Délai à attendre avant d'envoyer la première notification quand un service passe dans un état non-up (en minutes) notification_period 24x7 Nom court des périodes de temps pendant lesquelles les notifications d'événements sont envoyées notification_options w, u, c, r Détermine quand les notifications pour ce service doivent être envoyées notifications_enabled 0 ou 1 Détermine si les notifications pour ce service sont activées ou non contacts rlamour Noms courts des contacts qui devraient être notifiés lors d un problème contact_groups Admin_web Noms courts des groupes de contacts qui devraient être notifiés lors d un problème stalking_options o, w, u, c Détermine quelle mémorisation d'états est utilisée pour le service notes Service web Préciser une note d'information à rattacher au service, qui sera affichée sur l interface web notes_url ~/notes/serveur_test.php Définit une URL optionnelle fournissant des informations supplémentaires sur le service action_url ~/notes/actions.php Définit une URL optionnelle fournissant des actions supplémentaires à appliquer au service icon_image Serveur_web.png Définit le nom d'une image au format GIF, PNG ou JPG à associer au service, utilisé à différents endroits dans l interface web Bureau d étude - Nagios - 31 -
c) Options des contacts Variables Valeurs possibles Description contact_name bpicard Nom court pour identifier le contact alias Benjamin Picard Nom long ou description identifiant le contact contactgroups Admins_réseau Noms courts des groupes de contacts auxquels appartient ce contact host_notifications_enabled 0 ou 1 Détermine si le contact recevra ou non les notifications concernant des hôtes service_notifications_enabled 0 ou 1 Détermine si le contact recevra ou non les notifications concernant des services host_notification_period 24x7 Nom court d une période durant laquelle il peut être notifié des problèmes d hôtes service_notification_period 24x7 Nom court d une période durant laquelle il peut être notifié des problèmes de services host_notification_commands host-notify-by-email Noms courts de commandes à utiliser pour notifier le contact des problèmes d hôtes service_notification_commands notify-by-email Noms courts de commandes à utiliser pour notifier le contact des problèmes de services host_notification_options d, u, r, f, s, n Définit les états d'hôtes pour lesquels des notifications peuvent être envoyées à ce contact service_notification_options w, u, c, r, f, n Définit les états de services pour lesquels des notifications peuvent être envoyées à ce contact email pb@free.fr Définit une adresse email pour ce contact pager pagejoe@pagenet.com Définit une adresse de pager pour ce contact addressx Toto.iup@stri.com Définit une adresse supplémentaire pour ce contact (x = 1, 2, 3 ) can_submit_commands 0 ou 1 Détermine si le contact peut ou non exécuter des commandes externes à Nagios depuis les CGIs retain_status_information 0 ou 1 Détermine si les informations relatives aux états du contact sont conservées ou non après redémarrage du programme Bureau d étude - Nagios - 32 -
Variables Valeurs Possibles Description retain_nonstatus_information 0 ou 1 Détermine si les informations différentes des états du contact sont conservées ou non après redémarrage du programme d) Ordonnanceur : étalement des vérifications L étalement des vérifications sur le serveur Nagios se fait grâce à l «inter-check-delay». Cela correspond à l intervalle de temps en seconde entre deux vérifications. Il est conseillé de laisser Nagios faire le calcul par lui-même grâce à la valeur «s» (smart) - Etalement hôtes : - Etalement Services : Exemple : Un réseau comprend 1000 services à surveillés toutes les 5 minutes, on effectue donc le calcul suivant : La période moyenne de vérification est donc de 0,30 seconde. Bureau d étude - Nagios - 33 -
e) Hostdependency Variables Valeurs Possibles Description dependent_host_name RouteurX Description d un hôte dépendant dependent_hostgroup_name Routeurs Identifie le(s) nom(s) court(s) des groupes d hôtes dépendants host_name Serveur Web Identifie le nom court de l hôte dont on dépend hostgroup_name Serv-Web Identifie le(s) nom(s) court(s) des groupes d hôtes dont on dépend inherits_parent 0 ou 1 Indique si la dépendance hérite des dépendances de l'hôte dont on dépend execution_failure_criteria o, w, u, c, p, n Précise les critères qui déterminent quand l'hôte dépendant ne doit pas être contrôlé activement notification_failure_criteria o, w, u, c, p, n Définit les critères qui déterminent quand les notifications pour l'hôte dépendant ne doivent pas être envoyées dependency_period 24x7 Précise le nom court d'une période de temps pendant laquelle les dépendances sont valides Bureau d étude - Nagios - 34 -
f) Servicedependency Variables Valeurs Possibles Description dependent_host_name Serv-Web2 Identifie le(s) nom(s) court(s) d hôte(s) sur lequel tourne le service dépendant où avec lequel il est associé dependent_hostgroup_name Serv-WebX Identifie le(s) nom(s) court(s) des groupes hôtes sur lequel tourne le service dépendant où avec lequel il est associé dependent_service_description Serv-Web BDD Décrit un service dépendant host_name Serv-Web 1 Définit le(s) nom(s) court(s) d hôte(s) sur lequel tourne le service dont on dépend ou avec lequel il est associé hostgroup_name Serv-Web Définit le(s) nom(s) court(s) des groupes d hôtes sur lequel tourne le service dont on dépend ou avec lequel il est associé service_description Base de données Décrit le service dont on dépend inherits_parent 0 ou 1 Définit si la dépendance hérite des dépendances du service dont on dépend execution_failure_criteria o, w, u, c, p, n Précise les critères qui déterminent quand le service dépendant ne doit pas être contrôlé activement notification_failure_criteria o, w, u, c, p, n Définit les critères qui déterminent quand les notifications pour le service dépendant ne doivent pas être envoyées dependency_period 24x7 Préciser le nom court d'une période de temps pendant laquelle les dépendances sont valides g) Supervision Adaptative Attribut Commande Description HOST_NOTIFICATION_TIMEPERIOD CONTACT_MODATTR CONTACT_MODHATTR CHANGE_CONTACT_HOST_NOTIFICATION_ TIMEPERIOD;<contact_name>;<notification _timeperiod> CHANGE_CONTACT_MODATTR;<contact_na me>;<value> CHANGE_CONTACT_MODHATTR;<contact_ name>;<value> Modifie le nom court de la période durant laquelle le contact peut être notifié concernant un hôte Change la valeur de l attribue à modifié du contact spécifié Modifie la valeur de l attribue hôte du contact mentionné Bureau d étude - Nagios - 35 -
CONTACT_MODSATTR Attribut Commande Description SVC_NOTIFICATION_TIMEPERIOD CONTACT_VAR HOST_VAR SVC_VAR HOST_EVENT_HANDLER SVC_EVENT_HANDLER HOST_CHECK_COMMAND HOST_CHECK_TIMEPERIOD HOST_EVENT_HANDLER HOST_MODATTR HOST_CHECK_ATTEMPTS SVC_CHECK_ATTEMPTS HOST_CHECK_INTERVAL SVC_CHECK_INTERVAL HOST_CHECK_INTERVAL SVC_CHECK_INTERVAL SVC_CHECK_COMMAND SVC_CHECK_TIMEPERIOD CHANGE_CONTACT_MODSATTR;<contact_n ame>;<value> CHANGE_CONTACT_SVC_NOTIFICATION_TI MEPERIOD;<contact_name>;<notification_ti meperiod> CHANGE_CUSTOM_CONTACT_VAR;<contac t_name>;<varname>;<varvalue> CHANGE_CUSTOM_HOST_VAR;<host_name >;<varname>;<varvalue> CHANGE_CUSTOM_SVC_VAR;<host_name>; <service_description>;<varname>;<varvalue > CHANGE_GLOBAL_HOST_EVENT_HANDLER; <event_handler_command> CHANGE_GLOBAL_SVC_EVENT_HANDLER;< event_handler_command> CHANGE_HOST_CHECK_COMMAND;<host_ name>;<check_command> CHANGE_HOST_CHECK_TIMEPERIOD;<host _name>;<check_timeperod> CHANGE_HOST_EVENT_HANDLER;<host_na me>;<event_handler_command> CHANGE_HOST_MODATTR;<host_name>;<v alue> CHANGE_MAX_HOST_CHECK_ATTEMPTS;<h ost_name>;<check_attempts> CHANGE_MAX_SVC_CHECK_ATTEMPTS;<ho st_name>;<service_description>;<check_att empts> CHANGE_NORMAL_HOST_CHECK_INTERVA L;<host_name>;<check_interval> CHANGE_NORMAL_SVC_CHECK_INTERVAL; <host_name>;<service_description>;<check _interval> CHANGE_RETRY_HOST_CHECK_INTERVAL;< host_name>;<service_description>;<check_i nterval> CHANGE_RETRY_SVC_CHECK_INTERVAL;<h ost_name>;<service_description>;<check_in terval> CHANGE_SVC_CHECK_COMMAND;<host_na me>;<service_description>;<check_comma nd> CHANGE_SVC_CHECK_TIMEPERIOD;<host_n ame>;<service_description>;<check_timepe riod> Change la valeur de l attribut de service pour le contact spécifié Modifie le nom court de la période durant laquelle le contact peut être notifié concernant un service Modifie la valeur d un attribue de contact personnalisé pour le contact mentionné Modifie la valeur d un attribue hôte personnalisé l hôte spécifié Modifie la valeur d un attribue de service personnalisé pour l hôte mentionné Change la commande à exécuter à chaque changement d état d hôte Change la commande à exécuter à chaque changement d état de service Modifie la commande de contrôle pour l hôte spécifié Change la période de vérification pour l hôte spécifié Modification de la commande de gestion d évènement pour un hôte particulier Change la valeur de l attribut d hôte pour l hôte spécifié Modifie le nombre maximal de tentatives de contrôle pour un hôte donné Modifie le nombre maximal de tentatives de contrôle pour un hôte et un service donné Change l intervalle «normal» de contrôle pour l hôte spécifié Change l intervalle «normal» de contrôle pour l hôte et le service donné Modifie l intervalle de relance de contrôle pour un hôte particulier Modifie l intervalle de relance de contrôle pour un service particulier Modifie la commande de vérification pour un service spécifié Modifie la période de vérification d un service Bureau d étude - Nagios - 36 -
SVC_EVENT_HANDLER SVC_MODATTR Attribut Commande Description SVC_NOTIFICATION_TIMEPERIOD CHANGE_SVC_EVENT_HANDLER;<host_nam e>;<service_description>;<event_handler_c ommand> CHANGE_SVC_MODATTR;<host_name>;<se rvice_description>;<value> CHANGE_SVC_NOTIFICATION_TIMEPERIOD; <host_name>;<service_description>;<notifi cation_timeperiod> Modifie la commande de gestion d évènement pour un service particulier Change la valeur de l attribut pour un service donné Modifie la plage horaire de notification pour un service donné h) Maquette de Test 1. Installation de Nagios Nagios utilise une interface Web pour interagir avec les utilisateurs. Il faut donc installer un serveur Web sur notre serveur de supervision. Nous allons utiliser Apache 2. sudo apt-get install apache2 wget On vérifie si celui-ci marche on lance un navigateur web et on tape l'adresse suivante : http://localhost. Si la page affiche «It Works!» le serveur apache fonctionne. /etc/init.d/apache2 restart Pour des raisons de sécurité, le processus Nagios ne sera pas lancé en root. Nous allons donc créer un utilisateur système nagios et un groupe nagiosgrp. sudo /usr/sbin/useradd nagios sudo passwd nagios sudo /usr/sbin/groupadd nagiosgrp sudo /usr/sbin/usermod -G nagiosgrp nagios sudo /usr/sbin/usermod -G nagiosgrp www-data Il faut d'abord se rendre à la page officielle de Nagios : http://www.nagios.org/download/download.php puis noter les derniers numéros de version de Nagios et des plugins Nagios. En ce moment, c'est la version Nagios 3.0.6 et Nagios plugins 1.4.13, donc on saisie les commandes suivantes : Bureau d étude - Nagios - 37 -
sudo -s cd /usr/src wget http://surfnet.dl.sourceforge.net/sourceforge/nagios/nagios-3.2.3.tar.gz wget http://kent.dl.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.15.tar.gz On commence par décompresser la source : cd /usr/src tar xzf nagios-3.0.6.tar.gz Ensuite nous allons lancer la compilation : cd /usr/src/nagios-3.0.6./configure with-command-group=nagiosgrp make all make install make install-config make install-commandmode On installe ensuite le script de démarrage (pour que Nagios se lance automatiquement) : make install-init ln -s /etc/init.d/nagios /etc/rcs.d/s99nagios Il faut maintenant installer l interface Web : Attention : La 2eme commande permet de définir le mot de passe pour se connecter à Nagios. make install-webconf sudo htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin /etc/init.d/apache2 reload De base, Nagios est livré sans aucun plugin. Il faut donc installer les plugins standards permettant de surveiller son réseau. On commence par décompresser la source : cd /usr/src tar xzf nagios-plugins-1.4.13.tar.gz Ensuite nous allons lancer la compilation : cd /usr/src/nagios-plugins-1.4.13./configure --with-nagios-user=nagios --with-nagios-group=nagiosgrp make make install Nous allons donc tester les fichiers de configuration grâce à la commande suivante : /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg Si tout se passe bien, il devrait n y avoir aucune erreur. Enfin on lance le serveur Nagios : /etc/init.d/nagios start Bureau d étude - Nagios - 38 -
Il ne reste plus qu'à lancer un navigateur Web sur un PC de votre réseau et à saisir l'url suivante : «http://adresseipserveur/nagios/» 2. Configuration des équipements & machines Serveur Nagios > sudo -s > ifconfig eth0 10.3.2.2/23 > route add -net 10.7.10.0/23 gw 10.3.2.26 Serveur Web > su > ifconfig eth0 10.7.10.2/23 > route add -net 10.3.2.0/23 gw 10.7.10.26 Serveur DNS > su > ifconfig eth0 10.7.10.3/23 > route add -net 10.3.2.0/23 gw 10.7.10.26 Machine Cliente Windows Bureau d étude - Nagios - 39 -
Routeur RTR13 Etude de la logique de supervision dans Nagios 3 > su > telnet 10.3.2.26 Configuration des interfaces : RTR13> en RTR13> conf t RTR13> interface FastEthernet0/0 RTR13> ip address 10.3.2.26 255.255.254.0 RTR13> no shutdown RTR13> exit RTR13> interface FastEthernet0/1 RTR13> ip address 10.7.10.26 255.255.254.0 RTR13> no shutdown RTR13> exit RTR13> ip routing Configuration des routes : > route add -net 10.7.10.0/23 gw 10.3.2.26 dev eth0 > route add -net 10.3.2.0/23 gw 10.7.10.26 dev eth0 Switchs sw1 et sw2 Utilisation de la configuration de base de ces équipements. 3. Fichiers de configuration de Nagios La première étape de configuration est de définir l arborescence dans le fichier «/usr/local/nagios/etc/nagios.cfg». LOG FILE This is the main log file where service and host events are logged for historical purposes. This should be the first option specified in the config file!!! log_file=/usr/local/nagios/var/nagios.log OBJECT CONFIGURATION FILE(S) These are the object configuration files in which you define hosts, host groups, contacts, contact groups, services, etc. You can split your object definitions across several config files if you wish (as shown below), or keep them all in a single config file. Bureau d étude - Nagios - 40 -