====== Activité : Pourquoi et comment une machine est-elle supervisée ? ====== ===== Présentation ===== Ouvrez les différents fichiers présentés, regardez leur contenu afin de comprendre leurs relations et effectuer les actions permettant de tester **localhost**. ===== Webui===== **Webui** (l'interface utilisateur Web proposée par défaut par Shinken) montre que la supervision ne fonctionne pas. Pour Shinken l'hôte localhost est **down** ce qui **n'est pas possible** car vous avez l'interface Web. {{ :reseau:supervision:shinken_04.png?nolink |}} Les différents états gérés par Shinken sont : * Pour un hôte : * Un hôte est une machine accessible par son adresse IP pouvant prendre 4 états (**UP, DOWN,UNREACHABLE, PENDING**) : * **Up** -> 'hôte répond, * **Down** -> l'hôte ne répond pas, * **Unreachable** -> l’hôte est injoignable car il se trouve derrière un autre hôte qui ne répond pas, * **Pending** -> l’hôte n’est pas encore testé (au démarrage généralement). * Pour un service : * Un service est un élément supervisé sur un hôte (**qui doit donc être UP)** pouvant prendre 5 états (**OK, WARNING, CRITICAL, UNKNOWN, PENDING**) : * **Warning** -> des problèmes non bloquants, * **Critical** -> des problèmes bloquants, * **Unknown** -> état non testable car la commande (le plugin) a un problème, * **Pending** -> non encore testé (généralement au démarrage). L'hôte ne répond pas dans notre cas, mais pourquoi devrait-il répondre et à quoi ne répond-il pas ? ===== Les hôtes ===== **Pourquoi Shinken supervise la machine localhost ?** : * Parce que l'installation a créé un fichier **localhost.cfg** dans le répertoire **$ETC/hosts**. * Tous les hôtes présents (soit manuellement, soit dynamiquement, comme on verra dans d'autres activités) dans ce répertoire seront donc supervisés. Si on ouvre le fichier **localhost.cfg** (/etc/shinken/hosts/localhost.cfg) on y lit : define host{ use generic-host contact_groups admins host_name localhost address localhost } Le mot clé **define** permet de définir un **objet** gérable par Shinken, ici un hôte (**host**) identifié par son nom (**localhost**). Cet identifiant est important car il peut être utilisé dans d'autres fichiers de configuration. Son adresse est **localhost**, elle sera utilisée comme on le verra, par la variable **$HOSTADDRESS$** (on utilise un nom ou une adresse IP, dans notre cas **localhost** ou **127.0.0.1**, mais si on utilise un nom il faut une méthode de résolution de noms, dans ce cas le fichier **/etc/hosts**), et le groupe à contacter en cas de problème (**contact_groups**). ===== Les modèles (templates) ===== Il y a peu de choses dans le fichier précédent car la définition utilise un **modèle (template)** par l'intermédiaire de la directive **use**. Le modèle (**template**) utilisé est **generic-host**. La plupart des modèles sont décrits (définis) dans le sous-répertoire **$ETC/templates/** ou comme on le verra plus loin dans **$ETC/packs/** Dans ce répertoire on va trouver le fichier **generic-host.cfg** : # Generic host definition template - This is NOT a real host, just a template! # Most hosts should inherit from this one define host{ name generic-host # Checking part check_command check_host_alive max_check_attempts 2 check_interval 5 # Check every time active_checks_enabled 1 check_period 24x7 # Notification part # One notification each day (1440 = 60min* 24h) # every time, and for all 'errors' # notify the admins contactgroups by default contact_groups admins,users notification_interval 1440 notification_period 24x7 notification_options d,u,r,f notifications_enabled 1 # Advanced option. Look at the wiki for more informations event_handler_enabled 0 flap_detection_enabled 1 process_perf_data 1 # Maintenance period #maintenance_period workhours # Dispatching #poller_tag DMZ #realm All # For the WebUI #icon_set server ; can be database, disk, network_service, server # This said that it's a template register 0 } Ce fichier définit un modèle identifié par le nom **generic-host**, la directive **register** indique qu'il s'agit d'un modèle grâce à la valeur 0. Un modèle n'est pas instancié, il doit être appelé par un objet. Ce modèle appelle la commande **check_host_alive**. ===== Les commandes ===== La commande **check_host_alive** est définie dans **$ETC/commands/check_host_alive.cfg**. define command { command_namecheck_host_alive command_line $NAGIOSPLUGINSDIR$/check_ping -H $HOSTADDRESS$ -w 1000,100% -c 3000,100% -p 1 } Comme on peut voir la commande **check_host_alive** est une référence logique vers la commande réelle **check_ping**. Cette commande se situe dans le répertoire désignée par la variable **$NAGIOSPLUGINSDIR$**, cette variable est définie dans le fichier **$ETC/resource.d/path.cfg** . # Nagios legacy macros $USER1$=$NAGIOSPLUGINSDIR$ $NAGIOSPLUGINSDIR$=/usr/lib/nagios/plugins #-- Location of the plugins for Shinken $PLUGINSDIR$=/var/lib/shinken/libexec Cette commande est une commande faisant partie des plugins nagios. Mais si on regarde dans le répertoire **/usr/lib** on ne trouve pas de sous répertoire **nagios**. Il faut donc installer le plugin. root@ctShinken:~# apt-get install nagios-plugins Lecture des listes de paquets... Fait Construction de l'arbre des dépendances … Creating config file /etc/nagios-plugins/config/snmp.cfg with new version Paramétrage de nagios-plugins (1.4.16-1) ... Paramétrage de nagios-plugins-contrib (4.20120702) ... Traitement des actions différées (« triggers ») pour « menu » Les plugins installés sont nombreux : root@ctShinken:~# ls /usr/lib/nagios/plugins/ check_apt check_imap_receive_epncheck_rbl check_backuppc check_ipmi_sensor check_real check_breeze check_ircd check_rpc check_by_ssh check_jabber check_rta_multi check_cert_expire check_ldap check_running_kernel check_clamd check_ldaps check_sensors check_cluster check_libs check_simap check_dhcp check_lm_sensors check_smtp check_dig check_load check_smtp_send check_disk check_log check_smtp_send_epn check_disk_smb check_mailq check_snmp check_dns check_memcached check_snmp_environment check_dnssec_delegation check_mrtg check_soas check_dummy check_mrtgtraf check_spop check_email_delivery check_multipath check_ssh check_email_delivery_epn check_mysql check_ssl_cert check_entropy check_mysql_health check_ssmtp check_file_age check_mysql_query check_statusfile check_flexlm check_nagios check_swap check_fping check_nntp check_tcp check_ftp check_nntps check_time check_game check_nt check_udp check_haproxy check_ntp check_ups check_host check_ntp_peer check_users check_hpasm check_ntp_time check_wave check_hpjd check_nwstat check_webinject check_http check_oracle check_whois check_httpd_status check_overcr check_zone_auth check_icmp check_packages check_zone_rrsig_expiration check_ide_smart check_pgsql imap_ssl_cert check_ifoperstatus check_ping imap_ssl_cert_epn check_ifstatus check_pop negate check_imap check_printer urlize check_imap_quota check_procs utils.pm check_imap_quota_epn check_radius utils.sh check_imap_receive check_raid On y trouve notamment la commande **check_ping**. Cette commande est documentée ici : https://www.monitoring-plugins.org/doc/man/check_ping.html L'option * –w indique un "warning", * -c un évènement "critical", * rta signifie "round trip average travel" * et –p le nombre de paquets "icmp echo" envoyés. On peut d'ailleurs exécuter cette commande manuellement pour la tester. root@ctShinken:~# cd /usr/lib/nagios/plugins/ root@ctShinken:/usr/lib/nagios/plugins# ./check_ping -H localhost -w 1000,100% -c 3000,100% -p 1 PING OK - Paquets perdus = 0%, RTA = 0.29 ms|rta=0.291000ms;1000.000000;3000.000000;0.000000 pl=0%;100;100;0 Cela fonctionne. Que dit maintenant webui ? {{ :reseau:supervision:shinken_09.png?nolink |}} L'hôte **localhost est up !** Remarque : **$HOSTADDRESS$** a été remplacé par l'adresse trouvée dans le fichier **$ETC/hosts/localhost.cfg**, directive **address**. address localhost ==== Je reviens au menu Shinken ==== * [[reseau:supervision:shinken_00|Supervision des services avec Shinken]]