{{tag>netadmin nagios configuration}} ====== Nagios: Configuration et définitions ====== La configuration de Nagios s'appuie sur une représentation orienté objet. Un objet de configuration Nagios décrit une unité spécifique telle qu'un service, un hote, une commande, un contact ou groupe de contacts etc. Chaque objet est décrit par un ou plusieurs couples (attribut, valeur). Nagios inclus une forme d'héritage entre objets de configuration sous la désignation de **template**. Il est également possible de déclarer des relations de dépendance entre les objets de configuration définis. La configuration repose sur un ensemble de fichiers texte. Le fichier principal est **nagios.cfg** qui fait appels aux autres fichiers *.cfg Dans une configuration standard on trouve un fichier de configuration par type d'objet: hosts.cfg, services.cfg etc Nagios n'inclus pas par défaut de mécanismes de découverte ou d' auto-configuration. Les objets de configurations doivent être définis par l'administrateur. Un hôte héberge un ou plusieurs services. Une machine (host) n'a que 3 états: UP(correpsond à Ok ou Warning), DOWN (correspond à Critical) ou UNRECHEABLE s'il ne peut être testé à cause d'une coupure réseau par exemple. Les tests des hôtes s'appuient par défaut sur ICMP (ping). Les hôtes ne sont pas testés si les services associés sont OK. Si un service déployé sur un hôte est opérationnel, alors L’hôte est considéré par Nagios opérationnel. ===== Objets contact et contactgroup ===== Permettent de définir à qui, comment, sur quelle fréquence et plages horaires doivent être envoyées les notifications. ===== Objet command ===== Définit les actions comprenant l’exécution des plugins de test et l'envoi des notifications. Les valeurs des attributs des objets de configuration Nagios peuvent être utilisées par les objets command pour le paramétrage des plugins. Les objets command sont déjà fournis pour la plupart des plugins dans la configuration par défaut. Des objets command concernant l'envoi des notifications sont présents dans le fichier misccommand.cfg. ===== Exemple ===== Configuration de Nagios pour surveiller un serveur Web: - Définir l'objet de configuration **host** - Définir l'objet de configuration **service** - Recharger la configuration ==== Objet host ==== define host{ host_name webserver alias webapp linux host address www.localdomain. check_command check-host-alive max_check_attempts 3 check_period 24x7 notification_interval 180 notification_period 24x7 notification_options d,r,f,u contact_groups administrators } Quelques remarques à propos de cette définition: * L'attribut **check_command** définit quel test sera utilisé pour l’hôte. La valeur référence un objet de type **command**. * L’attribut **max_check_attempts** définit le nombre de tests avant l'envoi de notification (passage à l’état DOWN). * L'attribut **check_period** référence un objet de configuration timeperiod pour définir une période de temps au cours de laquelle les tests peuvent avoir lieu. * L'attribut **notification_interval** permet de définir le temps minimal en minutes entre 2 notifications. * L'attribut **notification_options** permet de filtrer les notifications: down,recovery,flapping,unreachable. ==== Objet service ==== define service{ service_description http_service host_name webserver check_command check_http max_check_attempts 4 normal_check_interval 5 retry_check_interval 1 check_period 24x7 notification_interval 180 notification_period 24x7 notification_options w,c,r,f,u contact_groups administrators } Quelques remarques à propos de cette définition: * L'attribut **service_description** peut induire en erreur. C'est l'UID de l'objet service. Il pourra être référencé dans d'autres définitions. * L'attribut **host_name** définit sur quel hôte s’exécute le présent service. * L'attribut **normal_check_interval** permet de définir l'intervalle en minutes entre les tests lorsque l'état du service est OK. * L'attribut **retry_check_interval** définit l'intervalle de temps en minutes entre les tests lorsque le service est dans un état Warning ou Critical avec pour objectif de rapidement confirmer l'état du service passer de soft à hard. * L'attribut **notification_options** pour filtrer les notifications: warning, critical, recovery, flapping, unreachable. ==== Recharger la configuration ==== ToDo ===== Exemple de commandes ===== Il est intéressant d'observer la définition des objets de configuration de type command. Ici la commande check-host-alive. define command{ command_name check-host-alive command_line $USER1$/check_icmp -H $HOSTADDRESS$ } L'attribut **command_line** définit la ligne de commande d’exécution du test. Elle utilise des macros qui seront remplacés à l’exécution par les valeurs des objets de configuration ici par exemple: * $USER1$ désigne le répertoire du plugin * $HOSTADDRESS$ est la valeur de l'attribut **address** de l'objet **host**. ===== Quizz ===== * Sous Nagios les tests de l’hôte ne sont pas exécutés si les services hébergés sont fonctionnels. * L'attribut **retry_check_interval** spécifie l'intervalle en minutes entre les tests lorsque un service est dans un état soft (soft warning ou soft critical). * L'attribut **notification_period** définit la plage horaire pendant laquelle les notifications peuvent être envoyées. * L'attribut **contact_group** définit qui pourra être notifié. * L'attribut **notification_options** permet de filtrer les types de notifications à transmettre. ===== Références =====