et services réseaux
1. Qu'est-ce que la supervision des applications et services réseaux ?
La supervision des services réseaux et des applications permet de contrôler la dis- ponibilité d'une application aux utilisateurs du réseau. Ce mode de supervision est habituellement réalisée sous forme active de façon à n'avoir rien de particulier à installer ou configurer sur le composant à vérifier.
C'est la méthode qui permet d'être au plus proche de ce que verra l'utilisateur. Pour être au plus près de cette réalité, il est souvent préférable d'effectuer ces mesures depuis plusieurs points du réseau. Imaginez un site comme amazon.com. La pre- mière chose qui est à prendre en compte est sa dimension mondiale nécessitant de contrôler la disponibilité de l'application (le site web dans ce cas) depuis plusieurs points de l'Internet pour contrôler à la fois la disponibilité de l'application elle-même mais surtout les routes qui y mènent. Il y aura donc tout intérêt à in- terroger le port 80 de amazon.com depuis au moins les cinq continents.
Ce chapitre va nous permettre d'amener un premier niveau de supervision sans dé- ployer quoi que soit de supplémentaire sur notre système d'informations. Ni ins- tallation ni configuration sur les composants supervisés ne sont nécessaires dans ce chapitre. Ce premier niveau nous permettra de déterminer la disponibilité de notre site de commerce en ligne ainsi que la qualité de sa réponse. Elle nous permettra d'être rapidement tenu au courant d'un problème survenant sur notre site et nous ©Edit
ionsENI-Toutereproductioninterdite
fournira les premiers éléments de diagnostic pour traiter la cause profonde et redémarrer au plus vite.
Tous les plug-ins utilisés ici possèdent l'option -H, --hostname=ADDRESS qui permet de préciser un nom d'hôte, une adresse IP ou un socket unix (préciser le chemin absolu). Ils possèdent également les options standards de seuils et de durée d'inactivité.
2. Supervision des services réseaux
C'est le contrôle le plus simple parce que le simple fait de vérifier la disponibilité d'un port sur le réseau assure du bon fonctionnement de l'ensemble de la chaîne nécessaire au fonctionnement de ce service. Par exemple, si le port 80 répond sur un hôte distant, c'est l'assurance que la machine reçoit de l'électricité, que la couche matérielle (hardware) et que le réseau fonctionnent correctement, que les systèmes de fichiers contiennent suffisamment de place et que le serveur Apache répond. Le temps de réponse retourné permet d'évaluer de son côté la qualité de l'ensemble de la transaction, réseau compris. Nous commençons par la supervision des applications et des services réseaux parce que Nagios est prévu à l'origine pour cela. Il n'y a donc rien à ajouter à notre installation actuelle et aucun logiciel n'est à installer sur les hôtes supervisés puisque la nature même des services et des ap- plications réseaux est justement d'être exposés sur le réseau. Nagios possède avec les plug-ins officiels un ensemble prêt à l'emploi pour ce type de supervision. Cet ensemble est composé d'un plug-in générique check_tcp qui permet de vérifier l'ouverture d'un port et sa disponibilité sur le réseau et de plusieurs plug-ins spécia- lisés commecheck_dnsoucheck_httpqui permettent d'aller plus loin en véri- fiant la qualité de la réponse obtenue par l'hôte supervisé. Ces plug-ins sont les mêmes quel que soit le système d'exploitation et le logiciel utilisé pour remplir le service puisque il s'intéresse à la réponse d'un protocole. Voici la liste complète de ces plug-ins spécialisés dans le test d'un type de services réseaux.
check_ftp check_time check_Idap check_real check_imap check_dns check_mysql check_ssh check_nntps check_http check_ntp_peer check_dhcp check_simap check_jabber check_spop check_rpc check_tcp check_ntp check_Idaps check_ssmtp check_ircd check_pop check_mysql_query check_nntp check_smtp check_udp check_dig check_oracle
Ces plug-ins représentent à eux seul près du tiers des plug-ins disponibles dans le paquet officiel, soulignant par là la vocation première de Nagios. Attention toute- fois, certains de ces plug-ins ne sont que des alias de check_tcp. C'est le cas de check_ftp,check_imap,check_pop,check_nntp,check_nntps.
2.1 Contrôle de la disponibilité d'un hôte
Trois façons sont proposées en standard par Nagios pour contrôler la disponibilité d'un composant sur le réseau aveccheck_ping,check_fpingetcheck_icmp.
Check_ping s'appuie sur la commande unix ping alors que check_fping s'appuie surfping. La différence notable entre ces deux utilitaires est la possibilité pour le deuxième d'interroger plusieurs hôtes dans le même appel, possibilité égale- ment retrouvée dans check_icmp. Check_icmp n'a besoin d'aucun programme externe pour fonctionner. Les trois plug-ins partagent en commun le fait de préci- ser le nombre de paquets ICMP à envoyer et le fait de mesurer à la fois le nombre de paquets perdus mais aussi le RTA (Real Time Answer), mesure du temps moyen qu'a mis l'hôte à répondre. C'est check_ping qui est utilisé dans les fichiers de configuration par défaut, c'est pourtant le moins pratique et le moins complet des trois. Il ne renvoie pas de valeurs de performance par exemple. Nous allons nous focaliser sur check_icmp qui est celui qui a le plus de possibilités ; détaillées ci-dessous. Ce plug-in nécessite d'activer le bit suid (chmod 4755) pour fonction- ner avec le compte utilisateur nagios ou tout autre réglage fait avec sudo par exemple.
-H Noms ou adresses IP du ou des hôtes à interroger. le switch-Hest option- nel, pas les noms ou adresses IP d'hôtes.
-w Seuil d'attention (par défaut 200,000ms,0% soit 200 ms de round trip time et 0% de paquets perdus.)
-c Seuil critique (par défaut 500000,000ms,80% soit 500000 ms de round trip time et 80% de paquets perdus.)
-n Nombre de paquets à envoyer (5 par défaut)
-i Intervalle maximum entre les paquets (80,000ms par défaut) -I Intervalle maximum entre les hôtes (0,000ms par défaut)
-m Nombre d'hôtes devant répondre pour que la requête soit considérée correcte.
-l TTL (Time To Live) des paquets sortants (0 par défaut) -b Taille des paquets ICMP (ignoré par défaut)
©EditionsENI-Toutereproductioninterdite
Voici un exemple simple d'appel au plug-in :
sysop@hardy:/usr/local/nagios/libexec$ ./check_icmp jeos nagios3\
olivier-desktop OK - jeos: rta 0,231ms,\
lost 0% :: nagios3: rta 0,578ms, lost 0% ::
olivier-desktop: rta 1,601ms, lost 0%|jeosrta=0,231ms;
00,000;500,000;0; jeospl=0%;40;80;; nagios3rta=0,578ms;
00,000;500,000;0; nagios3pl=0%;40;80;; olivier-desktoprta=1,601ms;
00,000;500,000;0; olivier-desktoppl=0%;40;80;;
Cet appel comporte juste les noms de domaines des trois hôtes à interroger.
L'argument -H est omis. L'exemple suivant est ce qui peut être considéré comme l'appel le plus complet possible à ce plug-in.
sysop@hardy:/usr/local/nagios/libexec$ ./check_icmp jeos nagios3\
olivier-desktop -w 200,1% -c 500000,80% -n 5 -i 80 -I 0 -m 3 -l 0 -t 10 -b 8 OK - jeos: rta 0,372ms, lost 0% :: nagios3: rta 0,399ms, lost 0% ::
olivier-desktop: rta 1,147ms, lost 0%|jeosrta=0,372ms;
00,000;255000,000;0; jeospl=0%;1;80;; nagios3rta=0,399ms;
00,000;255000,000;0; nagios3pl=0%;1;80;; olivier-desktoprta=1,147ms;
00,000;255000,000;0; olivier-desktoppl=0%;1;80;;
Ce plug-in représente le candidat idéal pour la définition de la commande Nagios check-host-alive, qui sert par défaut à valider la disponibilité d'un hôte.
define command{
command_name check-host-alive
command_line $USER1$/check_icmp -H $HOSTADDRESS$\
-w 3000.0,20% -c 500000.0,80% -n 1 -t 10 }
n
RemarqueNotez que les valeurs de seuils sont directement fixées au niveau de la commande Nagios, ces valeurs étant celles voulues pour l'ensemble des hôtes et composants à tester. Le nombre de paquets envoyés est égal à 1, ce qui fait que nous n'envoyons qu'un paquet à chaque hôte contrôlé. Pourquoi?
Il est recommandé dans la documentation officielle de minimiser le nombre de paquets dans la requête au profit d'un plus grand nombre d'essais. Plutôt que d'en- voyer 5 paquets et de retester le service toutes les deux minutes 5 fois en cas de défaillance comme c'est l'usage par défaut, il vaut mieux n'envoyer qu'un ou deux paquets et retester dix fois le service toutes les minutes. L'argument avancé est qu'il suffit le plus souvent d'envoyer un seul paquet pour juger de la disponibilité d'un hôte. Le gabarit d'hôte suivante met en place les directives pour illustrer ce propos.
define host{
name generic-host
active_checks_enabled 1
check_command check-host-alive
process_perf_data 1
check_period 24x7
check_interval 0
retry_interval 1
max_check_attempts 10
}
La valeur de check_interval est à 0 pour laisser Nagios contrôler ce service quand il le juge nécessaire, celle deretry_intervalest à 1 pour retester toutes les minutes en cas de défaillance et celle de max_check_attempts à 10 pour retester 10 fois avant de déclarer l'hôteDOWNen étatHARD. Ce type de réglage per- met de très bien s'accommoder des petites coupures qui peuvent survenir sur un réseau puisque l'hôte est testé pendant 10 minutes avant d'être déclaré indispo- nible. Il faut augmenter le nombre de paquets du test sur un réseau de mauvaise qualité. Enfin, n'oubliez pas que certains firewalls bloquent les requêtes icmp.
2.2 Contrôle de l'ouverture d'un port de service
check_tcpest le plug-in générique permettant de tester tout protocole réseau basé sur IP. check_tcp possède de nombreux alias dans le dossier des plug-ins dont voici le tableau.
check_clamd check_pop check_ftp check_simap check_imap check_spop check_jabber check_ssmtp check_nntp check_udp check_nntps
Pour pouvoir remplir le rôle que semble suggérer chacun des alias pointant sur check_tcp, celui-ci est générique et les nombreuses options disponibles ne dé- mentent pas cet état de fait.
-p, --port=INTEGER
Numéro de port à contacter. Port 21 par défaut.
-4, --use-ipv4
Utiliser une connexion IPv4.
©EditionsENI-Toutereproductioninterdite
