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 (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.

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 ?

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).

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 checkhostalive.

La commande checkhostalive est définie dans $ETC/commands/checkhostalive.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 checkhostalive 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 ?

L'hôte localhost est up !

address localhost