La nouvelle version de Nagios (3.0.6) 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:
A vous de jouer !
Ce billet fait suite à une demande pressente de plusieurs lecteurs de ce blog qui ont en commun le besoin d’envoyer des notifications Nagios par SMS afin que leurs administrateurs/utilisateurs puissent les recevoir sur un simple téléphone portable.
… ce qui Nagios ne sait pas faire: envoyer des SMS !!!
Et oui, il n’y a pas de miracle, Nagios ne sait pas envoyer directement de SMS (il n’est pas fait pour cela…). Il va falloir donc passer par un serveur offrant les fonctions suivantes:
Pas la peine de chercher bien loin, une requête du type serveur SMS dans gOOgle devrait vous mettre sur la bonne voie. Dans l’exemple si dessous, j’ai choisi l’opérateur 123-SMS qui propose un service sans abonnement (on crédite son compte en fonction de ses besoins) et avec des interfaces diverses et variées (Mail, HTTP, Socket, Curl…).
Il faut dans un premier temps créer un compte et le créditer…
Je vous conseille de créer le compte en question en donnant l’adresse mail de l’utilisateur Unix qui lance Nagios (par exemple nagios@votredomaine.com).
Il faut créer une nouvelle commande de notification dans le fichier de configuration …:
define command{
command_name notify-service-by-sms
command_line /usr/bin/printf « %b » « ** $NOTIFICATIONTYPE$ alert – $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ ** » | /usr/bin/mail -s « MOTDEPASSE:$CONTACTPAGER$ » sms@123-sms.net
}
define command{
command_name notify-host-by-sms
command_line /usr/bin/printf « %b » « Host $HOSTSTATE$ alert for $HOSTNAME$! » | /usr/bin/mail -s « MOTDEPASSE:$CONTACTPAGER$ » sms@123-sms.net
}
avec:
Il ne reste plus qu’a ajouter cette notification aux administrateurs/utilisateurs (par exemple le pauvre gars nommé James qui a comme numéro de téléphone 06007007) que l’on souhaite prévenir:
define contact{
contact_name monadminquivapasdormirdelanuit
alias James
service_notification_period 24×7
host_notification_period 24×7
service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands notify-service-by-sms
host_notification_commands notify-host-by-sms
pager 336007007
}
Et voilà, il ne reste plus qu’a relancer Nagios et attendre les premiers SMS…
—
Mise à jour:
Une nouvelle version de ce billet est disponible ici
—
Il n’existe pas de limite pour améliorer Nagios, l’outil de supervision open-source. Au niveau des notifications (messages envoyés sur des alertes), il est possible d’utiliser les mails, les SMS, les messageries instantanées… (je vous conseille la lecture du très bon livre « Nagios au coeur de la supervision opensource » sur le sujet).
Nous allons dans ce billet apporter une pincée de Web 2.0 dans cet édifice en proposant une notification via Twitter.
Les avantages de cette solution:
Les inconveniants:
Il faut bien sûr avoir un compte Twitter dédié pour ce besoin. Vous pouvez le créer en vous rendant sur cette page.
A ce stade et avant de continuer, assurez-vous que vous avez bien noté votre login et password Twitter.
On doit éditer le fichier de commandes (/usr/local/nagios/etc/objects/commands.cfg) et y ajouter la section suivante:
define command {
command_name twit-it
command_line /usr/bin/curl –connect-timeout 30 –max-time 60 -u YOUR_TWITTER_BOT_USER:YOUR_TWITTER_BOT_PASSWORD -d status= »$SERVICEDESC$@$HOSTNAME$ is $SERVICESTATE$ ** $SERVICEOUTPUT$ ** Date: $SHORTDATETIME$ » http://twitter.com/statuses/update.xml
}
PS: notez bien qu’il y a deux – avant
Ensuite, il faut modifier un des champs suivants dans la section contact du fichier /usr/local/nagios/etc/objects/templates.cfg:
service_notification_commands twit-it
ou
host_notification_commands alarma-twitter
Il ne reste plus qu’a tester vos fichiers de configuration:
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
et à relancer Nagios:
service nagios restart
ou
/etc/init.d/nagios restart
A chaque notification, un nouveau message devrait apparaître dans votre Twitter 😉
La nouvelle version de Nagios (3.0.5) 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.4 vers 3.0.5 sans problème:
A vous de jouer !
La version 1.4.13 des plugins officiels de Nagios viennent de sortir. Pour une description précise des changements, vous pouvez consulter ce billet sur Nagios-fr.
Voici donc un procédure effectuer cette mise à jour sur un serveur existant. Cette procédure est applicable pour toutes les mises à jours des plugins.
Il faut se rendre sur le site officiel pour télécharger la dernière version des plugins.
wget http://ovh.dl.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.13.tar.gz
On lance la classique « combo » suivant:
cd nagios-plugins-1.4.13
./configure
make
make install
Puis on met à jour les droits des fichiers:
chown nagios:nagios /usr/local/nagios/libexec/*
Sous Fedora:
service nagios restart
Sous Ubuntu/Debian
/etc/init.d/ nagios restart
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.
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).
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 !
Les plugins pour surveiller son serveur SIP Asterisk à partir de Nagios sont assez nombreux. Mais aucun d’eux ne me convenait parfaitement. J’ai donc écrit un petit script nommé Nagisk (quel humour…) a exécuter localement sur le serveur Asterisk. J’utilise NRPE pour récupérer la sortie de ce script et l’intégrer à Nagios.
Nagisk permet de:
J’ai créé un nouveau projet sous GitHUB ou vous pouvez télécharger la dernière version disponible de Nagisk.
Avant d’installer Nagisk sur votre serveur Asterisk, il faut d’abord y installer NRPE (par exemple en suivant ce tuto).
On commence par décompresser l’archive préalablement récupérée:
tar zxvf nagisk-1.2.tgz
Puis on copie le script Perl dans le répertoire des plugins Nagios:
cd nagisk
cp nagisk.pl /usr/local/nagios/libexec
On lui donne les bons droits:
chown nagios:nagios /usr/local/nagios/libexec/nagisk.pl
chmod 750 /usr/local/nagios/libexec/nagisk.pl
Certaines variables sont en durs dans le code (rien de méchant, juste le path pour accèder à Asterisk). J’utilise personnellement la commande sudo pour executé les commandes sur Asterisk afin que le script soit lancé par l’utilisateur nagios. Pour celà j’ai ajouté la ligne suivante dans le fichier /etc/sudoers:
…
nagios ALL= NOPASSWD: /usr/sbin/asterisk
Il suffit d’ajouter les lignes suivantes dans le fichier de configuration de NRPE (/usr/local/nagios/etc/nrpe.conf):
…
command[check_asterisk_version]=/usr/local/nagios/libexec/nagisk.pl -c version
command[check_asterisk_peers]=/usr/local/nagios/libexec/nagisk.pl -c peers
command[check_asterisk_channels]=/usr/local/nagios/libexec/nagisk.pl -c channels
command[check_asterisk_zaptel]=/usr/local/nagios/libexec/nagisk.pl -c zaptel
command[check_asterisk_span]=/usr/local/nagios/libexec/nagisk.pl -c span -s 1
ps: il est possible de faire plus propre en utilisant les arguments NRPE mais je trouve cette solution plus lisible…
Une fois le fichier mofifié, il faut relancer NRPE:
/etc/init.d/nrpe restart
Si vous souhaitez superviser un serveur SIP Asterisk dont le host_name est sip, il suffit d’ajouter les lignes suivantes dans un de vos fichiers de configurations:
define service{
use generic-service
host_name sip
service_description Check SIP
servicegroups sip
check_command check_nrpe!check_asterisk_version
}define service{
use generic-service
host_name sip
service_description Check SIP peers
servicegroups sip
check_command check_nrpe!check_asterisk_peers
}define service{
use generic-service
host_name sip
service_description Check SIP channels
servicegroups sip
check_command check_nrpe!check_asterisk_channels
}define service{
use generic-service
host_name sip
service_description Check Zaptel card
servicegroups sip
check_command check_nrpe!check_asterisk_zaptel
}define service{
use generic-service
host_name sip
service_description Check Zaptel Span 1
servicegroups sip
check_command check_nrpe!check_asterisk_span
}
Et voilà le résultat:
Nagisk semble remplir sa fonction, le script tourne depuis quelques temps chez moi sans problème. Il est distribué sous licence libre GPL v3 et il est bien sûr possible de le modifier pour l’adapter à vos besoins.
