Nagisk, le script Perl permettant de surveiller son serveur Asterisk à partir de Nagios passe en version 1.1.
Les nouveautés sont les suivantes:
Toutes les infos (procedure d’installation/configuration) sont disponibles sur cette page.
et voilà, à quelques jours près le « Blog de Nicolargo » souffle ces deuxièmes bougies ! Après 460000 visites, 780000 pages vues et plus de 450 abonnés (cliquer ici pour les rejoindre), le blog vient de passer le cap des deux ans d’existences.
L’informatique est en pleine mutation et l’open-source prends une part de plus en plus importante dans ce petit monde. Cela me confirme dans le maintient de ma ligne éditoriale: plus de libre !
A bientôt et merci à tous.
Un petit mémo à usage interne…
Si, comme moi, vous avez besoin d’installer (ou de mettre à jours) une machine GNU/Linux en utilisant apt-get et que celle-ci se trouve sur un réseau qui force l’utilisation d’un proxy HTTP, il faut saisir la commande suivante (à adapter à votre réseau):
export http_proxy=http://login:password@adresseduproxy:portduproxy
Exemple pour un serveur proxy Squid sans authentification:
export http_proxy=http://proxy.free.fr:3128
Voili…
L’actualité open-source de la semaine…
L’actualité du libre et de l’open source en vrac:
Autres choses ?
Pour surveiller votre réseau, Nagios utilise un certain nombre d’objets (machines, services, contacts…). Par défaut, un objet hérite une grande partie de ses paramètres du template nommé « generic-* ». Nous allons dans ce billet nous focaliser sur les notions de temps et de fréquences de ces objets.
Pour rappel, à un instant t, un objet peut avoir un des les états suivants:
Un exemple: imaginons un service qui surveille la débit de votre liaison Internet…
La variable check_period permet de définir l’intervalle de temps durant lequel l’objet est actif. On définie une période de temps en utilisant la structure timeperiod.
Par exemple pour définir une période de temps correspondant aux heures ouvrées de votre entreprise vous pouvez utiliser la définition suivante:
define timeperiod {
timeperiod_name workhours
alias Heures ouvrées
monday 09:00-18:00 ; Lundi
tuesday 09:00-18:00; Mardi
wednesday 09:00-18:00; Mercredi
thursday 09:00-18:00; Jeudi
Friday 09:00-18:00; Vendredi
}
La déclaration de cette période de temps dans notre objet (par exemple un service) se fera ainsi:
define service {
…
check_period workhours
}
Quand on se trouve dans une période d’activité d’un service, plusieurs paramètres rentrent en jeu pour fixer la durée et la fréquence des vérifications (checks) du objet en question.
Quand un objet est OK, il est vérifié toutes les check_interval minutes. Si il passe WARNING, CRITICAL ou UNKNOWN, il est alors vérifié max_check_attempts fois à un intervalle de retry_interval minutes. Si l’état de l’objet n’est pas revenu à OK au bout des max_check_attempts essais, l’intervalle de vérification redevient de check_interval minutes…
Je sais ce n’est pas très simple mais ce schéma devrait vous aider à comprendre.
define service {
…
check_interval 10
retry_interval 2
max_check_attempts 3
}
Il existe des variables permettant de fixer comment les notifications sont remontés aux administrateurs.
La première variable est first_notification_delay. Elle permet de définir le temps (en secondes) que Nagios doit attendre avant d’envoyer une notification quand un objet passe d’un état OK à un état WARNING, CRITICAL ou UNKNOWN. Une valeur de 0 permet d’envoyer la notification dès ce changement d’état.
La variable notification_interval permet, en cas de problème sur un objet, de fixer l’intervalle de temps (en minutes) entre deux notifications. Pour que Nagios n’envoie qu’une seule fois une alerte, il faut fixer cette variable à 0.
Par exemple, pour que la première notification se fasse immédiatement, sans répétition, un objet doit être défini ainsi:
define service {
…
first_notification_delay 0
notification_interval 0
}
Comme on vient de le voir il est relativement facile de configurer finement les fréquences et durées de vérifications en fonction de l’importance des objets à surveiller.
Il n’y a qu’à voir les demandes des lecteurs de ce blog concernant Nagios et les outils de supervision open-source pour comprendre qu’il y a manifestement un manque de documentations en Français sur le sujet. Heureusement, quelques bons samaritains prennent les choses en main.
Ainsi, en plus de se lancer dans la traduction de la documentation officielle et de maintenir le portail Nagios-fr, Olivier va publier dans les prochains jours un livre nommé « Nagios et la supervision Open Source ».
« NAGIOS et la supervision Open Source – De l’installation à l’optimisation » (Olivier JAN)
Ce bouquin a de forte chance de devenir le livre de chevet des administrateurs réseaux. Vous pouvez dès à présent en commander un exemplaire (livraison prévue mi-novembre 2008).
A partir du moment ou votre réseau est composé de plusieurs machines, il est utile d’avoir une base de temps commune. Heureusement, il existe un protocole (NTP) permettant de fixer la même heure sur l’ensemble des machines.
Nous utiliserons le serveur de temps libre NTPd disponible sous GNU/Linux et BSD.
La configuration est centralisé dans un seul fichier /etc/ntp.conf:
server 0.fr.pool.ntp.org
server 1.fr.pool.ntp.org
server 2.fr.pool.ntp.org
server 3.fr.pool.ntp.org
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
logfile /var/log/ntp.log
driftfile /var/db/ntp.drift
On lance alors le serveur avec la commande:
ntpd -g -p /var/run/ntpd.pid -c /etc/ntp.conf
Tout comme le protocole DNS, NTP travaille avec des serveurs hiérarchisés. Les serveurs racines sont retournés par les alias x.fr.pool.ntp.org
La commande restrict permet de limité l’accès au serveur au seul réseau 192.168.1.0/24 (il est possible d’avoir plusieurs lignes restrict).
Avant de tester votre serveur de temps, il faut attendre que ce dernier se synchronise avec ses pères (au moins 30 minutes).
La plupart des OS récents inclus la prise en charge de la partie cliente NTP. Lors de la configuration, il vous siffira de saisir l’adresse IP (ou le nom DNS) du serveur sur lequel est installé NTPd.
Vous avez aussi un moyen simple de tester votre serveur en ligne de commande (par exemple sous GNU/Linux Ubuntu):
sudo ntpdate -dv -b 192.168.29.108
Si votre serveur fonctionne normalement, vous devriez avoir le message suivant:
17 Oct 16:20:21 ntpdate[6570]: step time server 192.168.29.108 offset -6.080239 sec
Si vous avez l’erreur suivante:
17 Oct 16:09:52 ntpdate[6244]: no server suitable for synchronization found
Il y a de forte chance que votre serveur ne soit pas encore prêt à répondre aux clients (attendre environ 30 minutes). Si l’erreur persiste, vous pouvez lancez la commande suivante sur votre serveur afin de voir l’état de la synchrnonisation:
# ntpq -cpe
remote refid st t when poll reach delay offset jitter
==============================================================================
+goelette.net 145.238.203.14 2 u 254 512 37 22.615 -62.193 2.902
*ntp2.cines.fr 195.83.180.3 2 u 62 64 377 12.394 -0.253 4.034
+ntp.dr-j.eu 194.2.0.28 3 u 246 512 37 23.764 1.954 3.927
+ns2.kamino.fr 193.52.184.106 2 u 59 64 377 23.397 -1.449 4.540
Il ne vous reste plus qu’a passer sur toutes vos machines pour votre « tout nouveau, tout beau » serveur NTP.
Smile est un des sponsors de votre blog préféré (comment ça lequel…). En plus de proposer des whites papers gratuitement sur son site, il vous invite à un séminaire intitulé: « l’open source et l’entreprise performante ».
Ce séminaire vous permettra de connaître les origines et la philosophie de l’open source, les licences, les business models, les principes de support et les modèles de développement.
Mais surtout, il vous permettra d’apprécier les bénéfices de solutions open source dans le contexte des entreprises, bénéfices qui vont bien au delà des économies.
Exceptionnellement, ce séminaire se tiendra en fin de journée, le jeudi 23 octobre, de 18h à 20h à Paris – Saint-Lazare.
Vous pouvez donc profiter d’une bonne journée de travail, avant d’apprendre à connaître le monde de l’open source et ses gammes de solutions, et d’apprendre à connaître Smile par la même occasion! A l’issue des présentations, un cocktail vous sera offert, et vous pourrez discuter librement avec les experts et les managers de Smile.
La nouvelle version de Nagios (3.0.4) est en ligne. La liste des changements est disponible içi. Comme toujours, il est fortement conseillé de mettre à jour vos serveurs. Pour celà vous pouvez suivre une de ces procédures:
Je viens de tester la migration d’une version 3.0.3 vers 3.0.4 sans problème:
A vous de jouer !
L’actualité open-source de la semaine…
L’actualité du libre et de l’open source en vrac:
Autres choses ?
