Catégorie : Nagios

Nagios et supervision réseau

Catégories
Nagios Open-source Planet-libre Reseau

Nagios 3.3.1: mise à jour des scripts d’auto installation

Le coeur de Nagios (aka « Nagios Core ») vient de sortir dans sa version 3.3.1 et apporte son lot d’améliorations et de corrections d’erreurs (voir la liste ici). Dans la foulé, je viens de mettre à jour les scripts d’installation et de mise à jour automatique de Nagios pour Ubuntu et Debian.

Vous les trouverez sur le GitHub suivant: https://github.com/nicolargo/nagiosautoinstall

Pour une nouvelle installation

Il suffit de saisir les lignes de commande suivante dans un terminal (en mode root ou avec sudo):

cd /tmp

wget –no-check-certificate https://raw.github.com/nicolargo/nagiosautoinstall/master/nagiosautoinstall-ubuntu.sh

chmod a+x nagiosautoinstall-ubuntu.sh

./nagiosautoinstall-ubuntu.sh

Pour une mise à jour d’un serveur existant

Mise à jour de ce billet: je viens de publier une nouvelle version du script de mise à jour (version 0.9) développé en langage Python qui fait grosso modo la même chose que la version Shell Script (version 0.83) mais avec un affichage et un log beaucoup plus verbeux… 

J’ai fait le test sur un serveur en version 3.2.3 que j’ai migré en 3.3.1. Il suffit de saisir les lignes de commande suivante dans un terminal (en mode root ou avec sudo):

cd /tmp

wget –no-check-certificate https://raw.github.com/nicolargo/nagiosautoinstall/master/nagiosautoupdate.py

chmod a+x nagiosautoupdate.py

./nagiosautoupdate.py

Et voilà le travail.

Catégories
Nagios Open-source Planet-libre Reseau

Installation pas à pas d’un serveur de supervision Icinga

Icinga est un des nombreux forks libres de Nagios qui font pas mal parler d’eux en ce moment. Il apporte son lot d’amélioration par rapport « à son père » comme une architecture distribuée, une utilisation possible des bases de données MySQL/PgSQL/Oracle ou encore une interface Web tirant partie des dernières technologies dans le domaine (cliquez ici pour tester la démonstration de l’interface Web Icinga). Pour voir une comparaison pas forcément impartiale entre Icinga et Nagios, vous pouvez consulter ce tableau.

Dans ce billet, nous allons installer et configurer un serveur de supervision Icinga sur un serveur Debian (version Lenny ou supérieure mais la procédure doit être facilement adaptable à Ubuntu Server).

Les caractéristiques du serveur Icinga seront les suivantes:

  • Icinga dernière version disponible
  • Données de surperision stockées dans une base de donnée MySQL
  • Interface Web basée sur Apache
  • Plugins Nagios 1.4.15

Cette procédure a été testé sur une machine virtuelle (VM) sous Debian 6.0 Squeeze fraichement installée.

Préparation de l’installation

Nous allons installer Icinga depuis les sources se trouvant dans le dépôt Git officiel. Nous aurons ainsi la dernière version disponible. Pour cela, il est nécessaire d’installer certaines librairies et outils sur votre système.

Note: Les commandes de ce billet ont été saisies dans un terminal administrateur. Il est également possible d’utiliser la commande sudo <cmd> pour executer certaines taches en tant qu’administrateur ou su – -c « <cmd> ».

On installe les pré-requis (à adapter si vous utilisez Ubuntu Server en lieu et place de Debian):

ETAPE 1

apt-get install apache2 build-essential libgd2-xpm-dev libjpeg62 libjpeg62-dev libpng12-0 libpng12-dev mysql-server mysql-client libdbi0 libdbi0-dev libdbd-mysql snmp libsnmp-dev git

En cas d’erreur (par exemple paquet introuvable), il faudra faire une recherche dans les dépots et remplacer la librairie manquante par la nouvelle version.

On passe ensuite à la création du compte utilisateur et du groupe avec lesquels Icinga sera exécuté.  Je préfère personnellement utiliser le compte nagios (et le groupe nagios) plutôt que icinga comme on le trouve sur la documentation officielle. En effet, cela permet de simplifier une migration éventuelle d’un serveur Nagios vers Icinga.

ETAPE 2

groupadd nagios

useradd -g nagios -c « Nagios User » -s /bin/noshellneeded nagios

passwd nagios

usermod -a -G nagios www-data

Installation depuis les sources (Git)

On passe ensuite à la récupération de la dernière version de Icinga sur le gestionnaire de version Git officiel.

ETAPE 3

cd /usr/src

git clone git://git.icinga.org/icinga-core.git

cd /usr/src/icinga-core/

git submodule init

git submodule update

Puis on compile « la bête » avec les commandes suivantes:

ETAPE 4

./configure –with-icinga-user=nagios –with-icinga-group=nagios –with-nagios-user=nagios –with-nagios-group=nagios –with-command-user=nagios –with-command-group=nagios –prefix=/usr/local/icinga –enable-idoutils –enable-ssl

make all

make fullinstall

Si vous souhaitez protéger l’accès à l’interface Web d’Icinga avec un login/password, il faut également saisir la commande suivante. Par exemple pour définir un compte icingaadmin:

htpasswd -c /usr/local/icinga/etc/htpasswd.users icingaadmin

Installation des plugins Nagios

Comme Icinga est un fork de Nagios, il est possible d’utiliser directement les plugins de Nagios en version 1.4.15 au moment de la rédaction de ce billet.

Pour les installer on saisi:

ETAPE 5

cd /usr/src

wget http://downloads.sourceforge.net/project/nagiosplug/nagiosplug/1.4.15/nagios-plugins-1.4.15.tar.gz

tar zxvf nagios-plugins-1.4.15.tar.gz

cd nagios-plugins-1.4.15

./configure –prefix=/usr/local/icinga –with-cgiurl=/icinga/cgi-bin –with-htmurl=/icinga –with-nagios-user=nagios –with-nagios-group=nagios

make

make install

make install-root

Configuration de IDO

Arrivé à ce point de l’installation, vous devriez avoir un Icinga fonctionnel avec une base de donnée locale sous la forme de fichier texte (c’est le mode par défaut de Nagios). Pour avoir une installation évolutive et permettant d’exploiter les données issues de Nagios sur d’autres applications, il est nécessaire de configurer Icinga pour utiliser une base de donnée (MySQL dans notre exemple) en lieu et place de ces fichiers textes.

Pour cela, nous allons utiliser le module IDO qui fait l’interface entre Icinga et MySQL (ou PgSQL…). Ce module est l’équivalent du module NDO dans l’écosystème Nagios.

Le module IDO est installé par défaut suite à l’utilisation de l’option –enable-idoutils lors de la configuration de la compilation de Icinga. Il suffit donc de le configurer en suivant les indications suivantes:

ETAPE 6

cp /usr/local/icinga/etc/idomod.cfg-sample /usr/local/icinga/etc/idomod.cfg

sed -i -e « s/^use_ssl=0/use_ssl=1/g » /usr/local/icinga/etc/idomod.cfg

sed -i -e « s/^output_type=unixsocket/output_type=tcpsocket/g » /usr/local/icinga/etc/idomod.cfg

sed -i -e « s/^output=\/usr\/local\/icinga\/var\/ido.sock/output=127\.0\.0\.1/g » /usr/local/icinga/etc/idomod.cfg

cp /usr/local/icinga/etc/ido2db.cfg-sample /usr/local/icinga/etc/ido2db.cfg

sed -i -e « s/^use_ssl=0/use_ssl=1/g » /usr/local/icinga/etc/ido2db.cfg

sed -i -e « s/^socket_type=unix/socket_type=tcp/g » /usr/local/icinga/etc/ido2db.cfg

sed -i -e « s/^#broker_module=\/usr\/local\/icinga\/bin\/idomod.o\ config_file=\/usr\/local\/icinga\/etc\/idomod.cfg/broker_module=\/usr\/local\/icinga\/bin\/idomod.o\ config_file=\/usr\/local\/icinga\/etc\/idomod.cfg/g » /usr/local/icinga/etc/icinga.cfg

cat >> /usr/local/icinga/etc/modules/idoutils.cfg < EOF
define module{
module_name ido_mod
path /usr/local/icinga/bin/idomod.o
module_type neb
args config_file=/usr/local/icinga/etc/idomod.cfg
}
EOF

On doit enfin créer la base de donnée MySQL qui va stocker les données d’Icinga.

ETAPE 7

mysql -u root -p

mysql> CREATE DATABASE icinga; GRANT USAGE ON *.* TO ‘icinga’@’localhost’ IDENTIFIED BY ‘icinga’; GRANT SELECT , INSERT , UPDATE , DELETE ON icinga.* TO ‘icinga’@’localhost’;

mysql> FLUSH PRIVILEGES;

mysql> quit

mysql -u root -p icinga < /usr/src/icinga-core/module/idoutils/db/mysql/mysql.sql

Par défault, la base de donnée s’appelle icinga et elle sera accessible seulement en local (localhost) par l’utilisateur MySQL icinga avec le mot de passe icinga. (vous pouvez bien sur changer ces paramètres dans la base de donnée mais il faudra alors veiller à également les modifier dans le fichier ido2db.cfg).

Test de l’installation d’Icinga

On relance les processus pour prendre en compte notre configuration:

ETAPE 8

/etc/init.d/ido2db start

/etc/init.d/icinga start

/etc/init.d/apache2 restart

Puis on automatise le démarrage d’Icinga au prochain boot du serveur:

ETAPE 9

update-rc.d ido2db defaults

update-rc.d icinga defaults

Vous devriez avoir un Icinga fonctionnel ! Pour vérifier ceci, il suffit de pointer un navigateur Web vers l’URL suivante: http://<adresse ip serveur icinga>/icinga (ou http://localhost/icinga)

Migration de votre configuration Nagios (optionnel)

Comme nous l’avons vu au début de ce billet, Icinga est un fork de Nagios. C’est à dire qu’il est tout à fait possible d’utiliser les plugins et les configurations d’un serveur Nagios existant directement dans votre nouveau serveur Icinga.

Je vous conseille dans un premier temps d’archiver la configuration initiale de Icinga pour pouvoir revenir en arrière en cas de problème:

cp -R /usr/local/icinga/etc /usr/local/icinga/etc.default

Ensuite on copie la configuration depuis le répertoire de Nagios. Je pars sur l’hypothèse ou le serveur Nagios est installé sur la même machine que votre serveur Icinga. Si ce n’est pas le cas, il faudra transférer les fichiers depuis votre serveur Nagios.

cp -R /usr/local/nagios/etc/* /usr/local/icinga/etc/

On transforme ensuite la configuration pour l’adapter à Icinga:

mv /usr/local/icinga/etc/nagios.cfg /usr/local/icinga/etc/icinga.cfg

sed -i ‘s/nagios/icinga/g’ /usr/local/icinga/etc/icinga.cfg

sed -i ‘s/nagios/icinga/g’ /usr/local/icinga/etc/cgi.cfg

sed -i ‘s/nagios/icinga/g’ /usr/local/icinga/etc/resource.cfg

cp /usr/local/icinga/etc.default/htpasswd.users /usr/local/icinga/etc/

On devrait ainsi avoir une configuration mélangeant celle faite pour Icinga (notamment en ce qui concerne IDO) et votre ancienne configuration de Nagios.

On vérifie que la configuration ne comporte pas d’erreur:

/usr/local/icinga/bin/icinga -v /usr/local/icinga/etc/icinga.cfg

Si c’est le cas, il suffit de relancer Icinga pour prendre en compte cette configuration:

/etc/init.d/ido2db restart

/etc/init.d/icinga restart

/etc/init.d/apache2 restart

Vous pouvez faire fonctionner les deux services (Nagios & Icinga) en parallèle sans aucun problème. Cela peut être utile pour une phase de migration. Par contre il faut garder à l’esprit que vous aurez deux fois plus de requêtes vers vos serveurs…

Sources:

Catégories
Nagios Open-source Planet-libre Reseau Systeme

Shinken découvre votre réseau pour vous

Si vous avez mis en place un serveur de supervision sur votre réseau, vous devez savoir que cette phase est souvent longue, fastidieuse et source d’erreur de configuration. Heureusement, la dernière version (0.6) de Shinken (le fork compatible Nagios développé de main de maitre par Jean Gabes) intègre un mesure de découverte de votre réseau.

Nous allons dans ce billet détailler les étapes pour utiliser ce module. Nous partons sur l’hypothèse ou vous avez un serveur Shinken/Thruk opérationnel. Si ce n’est pas le cas, j’ai développé un petit script shell permettant de faire cette installation pour vous.

C’est quoi donc ce module ?

Shinken-discovery est un programme qui va scanner les machines de votre réseau puis en déduire les services à superviser pour ensuite générer les fichiers de configurations pour Shinken.

Installation

Le scan de votre réseau se base sur le bien connu programme nmap qui doit donc être présent sur votre système.

Sur Debian / Ubuntu:

sudo aptitude install nmap

Sur Fedora:

yum install nmap

Le reste des programmes est inclue dans la version 0.6 (et supérieure) de Shinken.

Configuration

Si vous avez bien suivi, il faut maintenant dire à Shinken quel est le ou les réseaux à scanner. Cette configuration permet non seulement de découvrir des machines sur votre réseau local mais également (sous réserve de règles de filtrages compatible dans vos firewalls/routeurs) sur des réseaux distants.

La liste des réseaux à scanner est à configurer dans le fichier /etc/shinken/resource.cfg dans la variable $NMAPTARGETS$ (en fin de fichier):

# sudo vi /etc/shinken/resource.cfg

$NMAPTARGETS$=192.168.0.0/24 blog.nicolargo.com

Dans l’exemple ci-dessus je vais donc scanner:

  • 192.168.0.0/24: les 254 adresses de mon réseau local
  • blog.nicolargo.com: un serveur sur Internet que je surveille de près

Lancement de la découverte

Il suffit de saisir la commande suivante:

sudo shinken-discovery -o /etc/shinken/objects/discovery -r nmap

Selon la taille de votre réseau, cette opération peut prendre plus ou moins de temps (« I’m launching nmap »).

Comme on peut s’en douter, la configuration sera générée dans le répertoire /etc/shinken/objects/discovery. Le principal avantage est que l’on ne pert pas la configuration existante.

Note

Pour partir sur une nouvelle configuration basée uniquement sur le module de découverte (c’est à dire juste après une installation propre de Shinken), vous pouvez suivre la procédure suivante (au cas ou la configuration initiale est archivé dans /tmp/shinken-backup.tgz):

tar zcvf /tmp/shinken-backup.tgz /etc/shinken

sudo rm -f /etc/shinken/objects/hosts/*

sudo rm -f /etc/shinken/objects/services/*

sudo rm -f /etc/shinken/hostgroups.cfg

sudo touch /etc/shinken/hostgroups.cfg

sudo rm -f /etc/shinken/servicegroups.cfg

sudo touch /etc/shinken/servicegroups.cfg

/Note

On doit ensuite fixer les droits des fichiers générés:

sudo chown -R shinken:shinken /etc/shinken/objects/discovery

Prise en compte de la nouvelle configuration

Il suffit ensuite de redémarrer Shinken pour voir votre réseau:

sudo /etc/init.d/shinken restart

Si vous aviez déjà une configuration existante, il y a de forte chance pour que Shinken vous affiche un message d’erreur lors de la vérification de vos fichiers. Le résultat de la commande de check se trouve dans le fichier /tmp/shinken_checkconfig_result.

Par exemple, le module de découverte peut générer une entrée pour un host existant. Il faut alors éditer et ou supprimer le host en question pour que la configuration soit valide.

Conclusion

Ce billet n’est qu’une courte introduction à ce module qui peut être paramétré de manière beaucoup plus fine lors de la transformation du scan vers une configuration Shinken. J’aurai l’occasion de revenir prochainement sur ce vaste sujet.

Catégories
Nagios Open-source Planet-libre Reseau Systeme

Mise à jour 0.4 du script d’installation de Shinken/Thruk

Aussi bien pour Shinken que pour les Thruk, les mises à jour s’enchaînent avec une fréquence importante ces derniers temps. Cela démontre un grand dynamisme sur ce projet !

J’ai donc adapté le script d’installation automatique du couple Shinken/Thruk en ajoutant pas mal de contrôle sur le bon déroulement des téléchargement ainsi qu’une adaptation pour aller chercher Thruk dans les archives si la version du script n’est plus téléchargeable dans le répertoire officiel.

La version 0.4 du script va installer:

  • Shinken 0.6
  • Thruk 1.0.2

La procédure pour installer ou mettre à jour votre serveur de supervision Shinken est toujours la même:

cd ~

rm -f shinkenautoinstall-debian.sh

wget http://svn.nicolargo.com/shinkenautoinstall/trunk/shinkenautoinstall-debian.sh

chmod a+x shinkenautoinstall-debian.sh

sudo ./shinkenautoinstall-debian.sh

Si tout se passe comme prévu, le script devrait afficher:

—————————————————-

Installation is finished

—————————————————-

Backup configuration file : /tmp/shinken-backup-20110513073545.tgz

Configuration file folder : /etc/shinken

Log file : /var/lib/shinken/nagios.log

Shinken startup script : /etc/init.d/shinken

Thruk startup script : /etc/init.d/thruk

Thruk web interface URL : http://sam:3000

Dans certain cas, notamment lors d’une mise à jour, il faut ensuite relancer Shinken:

sudo /etc/init.d/shinken restart

Pour remonter les éventuels bugs / nouvelles fonctions, merci d’utiliser le site officiel du script qui se trouve sur GitHub à l’adresse suivante: https://github.com/nicolargo/shinkenautoinstall.

Catégories
Nagios Open-source Planet-libre Reseau Systeme

Mise à jour du script d’installation de Shinken/Thruk

Shinken, le système libre de supervision système et réseau compatible avec les fichiers de configurations et les plugins Nagios vient de sortir en version 0.6.

Cette nouvelle version apporte un lot impressionnant de nouveautés. Celle qui me semble la plus notable et sur laquelle je reviendrai dans un prochain billet est la découverte automatique de votre réseau. Plus besoin de faire toutes sa configuration à la main ! En effet, le « discovery module » permet d’automatiser cette tache fastidieuse.

Dès sa sortie, j’ai modifié le script d’installation automatique pour qu’il prenne en compte cette nouvelle version 0.6 de Shinken. J’en ai également profité pour modifier la version de Thruk (l’interface Web) pour utiliser la version 0.94.4. Je rappelle que le script a été développé et testé sur un système Debian mais il doit également fonctionner sous Ubuntu moyennant quelques modifications (lignes arch_version et perl_version).

Récupération du script d’auto installation de Shinken/Thruk

Il suffit d’ouvrir un terminal puis de saisir les commandes suivantes:

cd ~

rm -f shinkenautoinstall-debian.sh

wget https://raw.github.com/nicolargo/shinkenautoinstall/master/shinkenautoinstall-debian.sh

chmod a+x shinkenautoinstall-debian.sh

Lancement du script d’auto installation de Shinken/Thruk

Là encore rien de compliqué:

sudo ./shinkenautoinstall-debian.sh

Le script devrait se dérouler tout seul. Il vous demandera juste à un moment donnée de saisir le mot de passe que vous voulez affecter à l’utilisateur Unix shinken.

A la fin de l’installation, le serveur Shinken et l’interface Web Thruk seront lancées automatiquement.

—————————————————-

Installation terminée

—————————————————-

Fichiers de configuration : /etc/shinken

Fichiers de logs : /var/lib/shinken/nagios.log

Script de lancement de Shinken : /etc/init.d/shinken

Script de lancement de Thruk : /etc/init.d/thruk

Interface d’administration : http://@IP:3000

Arrivé à ce stade, vous pouvez éditer la configuration de Shinken (contenue dans le répertoire /etc/shinken) et vous connecter à l’interface Web d’administration (http://@IP:3000 ou @IP est à remplacer par l’adresse IP de votre serveur de supervision).

En bonus

Vous pouvez également utiliser le script pour mettre à jour un système Shiken existant (si il a été installé depuis les sources ou avec mon script). Dans ce cas, le script va sauvegarder votre configuration existante (le contenu du dossier /etc/shinken) dans un fichier .tgz (le nom et l’emplacement du fichier sont données à la fin de la mise à jour).

Il sera ensuite possible de restaurer cette configuration à la main.

Encore plus de Shinken ?

Jean Gabes, le papa de Shinken donnera une conférence sur son fils jeudi 12 mai au salon Solution Linux (à 15h30). Venez nombreux, il annonce une « conf de fou » 🙂 (il va avoir une belle pression…)

Catégories
Nagios Open-source Planet-libre Reseau

Script d’installation automatique de Shinken/Thruk

Dans le petit monde des systèmes de supervision système et réseau, un nouveau venu pointe le bout de sa… lame: Shinken.

Développé de main de maître par Jean Gabes (un des spécialiste Français de Nagios), il en reprend la structure au niveau des fichiers de configuration tout en apportant de plus grandes des performances, le tout distribué sous une licence libre AGPL v3. Basée sur le langage Python, il offre une liste pour le moins  impressionnante de fonctions que vous pouvez consultez sur cette page.

Nous allons dans ce premier billet sur le sujet, détailler un script d’installation automatique du couple Shinken + Thruk (interface Web) sur une distribution GNU/Linux Debian (le script doit également fonctionner sur une distribution Ubuntu moyennant, peut être, quelques modifications, notamment l’édition des lignes arch_version et perl_version).

La version actuelle du script, va installer Shinken version 1.0 (à noter que cette version inclue une UI maison) et Thruk 1.1.7. Pour information, ces deux versions peuvent être utilisées dans un environnement de production.

Récupération du script d’auto installation de Shinken/Thruk

Il suffit d’ouvrir un terminal puis de saisir les commandes suivantes:

cd ~

rm -f shinkenautoinstall-debian.sh

wget –no-check-certificate https://raw.github.com/nicolargo/shinkenautoinstall/master/shinkenautoinstall-debian.sh

chmod a+x shinkenautoinstall-debian.sh

Vous pouvez également récupérer le script / remonter des demandes de nouvelles fonctions ou des bugs sur GitHub.

Lancement du script d’auto installation de Shinken/Thruk

Là encore rien de compliqué:

sudo ./shinkenautoinstall-debian.sh

Le script devrait se dérouler tout seul. Il vous demandera juste à un moment donnée de saisir le mot de passe que vous voulez affecter à l’utilisateur Unix shinken.

A la fin de l’installation, le serveur Shinken et l’interface Web Thruk seront lancées automatiquement.

—————————————————-

Installation terminée

—————————————————-

Fichiers de configuration : /etc/shinken

Fichiers de logs : /var/lib/shinken/nagios.log

Script de lancement de Shinken : /etc/init.d/shinken

Script de lancement de Thruk : /etc/init.d/thruk

Interface d’administration : http://@IP:3000

Arrivé à ce stade, vous pouvez éditer la configuration de Shinken (contenue dans le répertoire /etc/shinken) et vous connecter à l’interface Web d’administration (http://@IP:3000 ou @IP est à remplacer par l’adresse IP de votre serveur de supervision).

Petite astuce complémentaire pour les utilisateurs voulant faire transiter les connections vers l’interface d’administration Web par un serveur Web Nginx. Il suffit d’ajouter la configuration suivante dans un fichier de conf Nginx:

server {

listen 80;

server_name nagios.mondomaine.com;

location / {

proxy_pass http://127.0.0.1:3000;

proxy_redirect off;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

}

}

Toute les requêtes entrantes sur le port TCP 80 et le nom de machine  nagios.mondomaine.com (à adapter à votre serveur) seront redirigées vers Nagios (http://127.0.0.1:3000). Cela permet d’éviter d’avoir à ouvrir un port supplémentaire (le 3000) sur votre serveur…

Que fait exactement le script d’auto installation de Shinken/Thruk ?

Pas grand chose, mis à part:

  • installation des pré-requis système
  • création de l’utilisateur shinken et du groupe associé
  • téléchargement des sources de Shinken et de Thruk
  • mise en place des scripts de démarrage de Shinken et Thruk (init.d)
  • vérification de la configuration de Shinken (l’équivalent de l’option -v de Nagios)
  • premier lancement de Shinken
  • premier lancement de Thruk

Si vous testez ce script sur Debian ou sur une autre distribution, je suis preneur de vos retours.

Sources:

Catégories
Nagios Open-source Planet-libre Reseau Systeme

Et un eBook gratuit sur Nagios, un…

On m’a plusieurs fois proposé d’écrire un livre sur Nagios et la supervision système et réseau. J’ai, pour l’instant, refusé ces offres par manque de temps et de motivation. Le Blog de Nicolargo m’occupe déjà  beaucoup et je trouve cette formule plus « interactive » que le support papier.

Cependant, je sais par expérience qu’il est parfois utile d’avoir une documentation papier ou sous la forme d’un simple fichier sur une clés USB. C’est donc pour cette raison que j’ai compilé l’ensemble des billets de ce blog abordant Nagios dans un eBook au format PDF sous licence Creative Common BY NC.

Pour télécharger gratuitement cet eBook, il suffit de cliquer sur l’image suivante:

Je vous rappelle, que l’ensemble des billets sur Nagios est regroupé également sur cette page (vous trouverez encore plus d’informations que dans l’eBook). Si vous voulez être tenu au courant des nouveaux articles, je vous conseille de vous abonner au flux RSS du blog, à mon compte Twitter ou à partir de Facebook.

Bonne lecture !

Catégories
Nagios Open-source Planet-libre Reseau

Le script de supervision d’Asterisk par Nagios évolue

Grâce à la contribution de Fréderic Jean, le script Perl Nagisk que j’avais développé il y a quelques temps passe en version 1.2. Cette nouvelle mouture apporte les nouveautés suivantes:

  • adaptation du script pour Asterisk version 1.6.13.2
  • modification de la commande pour avoir les informations sur les channels (« core show channels »)
  • ajout de l’option -p pour spécifier un peer

Pour rappel, Nagisk est un plugin pour Nagios permettant de récupérer, via NRPE, des informations sur votre serveur Asterisk (serveur PABX software).

La syntaxe est la suivante:

Syntax: ./nagisk.pl [-hv] [-c OPT] [-s NB|-p NAME]

-c version: Display the Asterisk version

-c peers: Display the SIP peers status

-c peer: Display the status of a particular peer

-c channels: Display the SIP channels status

-c zaptel: Display the status of the zaptel card

-c span: Display the status of a specific span (set with -s option)

-s <span number>: Set the span number (default is 1)

-p <peer name>

-h: Display the help and exit

-v: Display version and exit

Toutes les informations pour télécharger et installer ce script dans Nagios se trouve dans ce billet (mis à jour pour cette version).

Catégories
Blog Nagios Open-source Planet-libre Reseau Systeme Web

Superviser son blog avec Nagios

Pour moi, la vraie révolution Internet de ces dernières années est l’apparition de blogs ayant petit à petit pris le relais des sites institutionnels pour diffuser de l’information. Souvent tenu à bout de bras par des particuliers, ils ne disposent pas d’une infrastructure informatique professionnelle.

Ainsi en cas de problème technique, l’administrateur est souvent prévenu par ses lecteurs…

Nous allons donc voir dans ce billet comment utiliser le logiciel libre de supervision Nagios pour surveiller automatiquement son blog.

Voilà ce que donnera le résultat dans l’interface Web de Nagios:

Contexte

Afin d’illustrer ce billet, nous allons partir sur l’hypothèse ou vous disposer d’un blog hébergé sur un serveur dédié ou virtuel sous Ubuntu Server 10.04 avec un accès SSH et un compte utilisateur avec les droits d’administration (sudo>r00t).

Aller on se connecte en SSH sur son serveur et on suit le guide.

Installation de Nagios

Nous allons utiliser le script d’installation automatique de Nagios (développé par votre serviteur).

On commence par le télécharger le script nagiosautoinstall-ubuntu.sh:

mkdir ~/monitoring/

cd ~/monitoring

wget https://raw.github.com/nicolargo/nagiosautoinstall/master/nagiosautoinstall-ubuntu.sh

chmod a+x nagiosautoinstall-ubuntu.sh

Puis on lance l’installation (il y a quelques questions auxquelles il faudra répondre) :

sudo ./nagiosautoinstall-ubuntu.sh

On devrait ensuite pourvoir accéder à l’interface Web de Nagios à partir de l’URL suivant: http://@IP/nagios/

Ou @IP est l’adresse IP de votre serveur.

Configuration de Nagios

Comme Nagios tourne sur la même machine que le serveur à superviser, toutes la configuration se fera dans le fichier de configuration localhost.cfg.

J’utilise deux plugins non inclus dans les plugins de bases de Nagios (mais installé automatiquement par le script nagiosautoinstall-ubuntu.sh):

On édite le fichier /usr/local/nagios/etc/objects/localhost.cfg (à adapter à votre configuration…):

#######################################################################

#

# Supervision du blog blog.nicolargo.com

#

#######################################################################

 

#######################################################################

#######################################################################

#

# HOST DEFINITION

#

#######################################################################

#######################################################################

 

# Define a host for the local machine

 

define host{

use linux-server

host_name blog

alias blog.nicolargo.com

address 127.0.0.1

}

 

#######################################################################

#######################################################################

#

# SERVICE DEFINITIONS

#

#######################################################################

#######################################################################

 

 

# Define a service to « ping » the local machine

 

define service{

use local-service

host_name blog

service_description PING

check_command check_ping!100.0,20%!500.0,60%

}

 

 

# Define a service to check the disk space of the root partition

# on the local machine. Warning if < 20% free, critical if

# < 10% free space on partition.

 

define service{

use local-service

host_name blog

service_description Root Partition

check_command check_local_disk!10%!5%!/

}

 

 

 

# Define a service to check the number of currently logged in

# users on the local machine. Warning if > 2 users, critical

# if > 3 users.

 

define service{

use local-service

host_name blog

service_description Current Users

check_command check_local_users!2!3

}

 

 

# Define a service to check the number of currently running procs

# on the local machine. Warning if > 250 processes, critical if

# > 400 processes.

 

define service{

use local-service

host_name blog

service_description Total Processes

check_command check_local_procs!250!400!RSZDT

}

 

# Check memoire avec script check_memory

# http://blog.nicolargo.com/2008/07/surveiller-la-memoire-de-vos-serveurs-avec-nagios.html

# -w 800000000 -c 900000000

 

define service{

use local-service

host_name blog

service_description Memory

check_command check_memory!800000000!900000000

}

 

# Define a service to check the load on the local machine.

 

define service{

use local-service

host_name blog

service_description Current Load

check_command check_local_load!5.0,4.0,3.0!10.0,6.0,4.0

}

 

# Define a service to check the swap usage the local machine.

# Critical if less than 10% of swap is free, warning if less than 20% is free

 

define service{

use local-service

host_name blog

service_description Swap Usage

check_command check_local_swap!20!10

}

 

# Define a service to check SSH on the local machine.

# Disable notifications for this service by default, as not all users may have SSH enabled.

 

define service{

use local-service

host_name blog

service_description SSH

check_command check_ssh

#notifications_enabled 0

}

 

 

 

# Define a service to check HTTP on the local machine.

# Disable notifications for this service by default, as not all users may have HTTP enabled.

 

define service{

use local-service

host_name blog

service_description HTTP

check_command check_http

#notifications_enabled 0

}

 

# Define a service to check URL

# http://blog.nicolargo.com/google89d0cf0b89815a2a.html

 

define service{

use local-service

host_name blog

service_description URL Google check file

check_command check_url!http://blog.nicolargo.com/googl

e89d0cf0b89815a2a.html

}

 

# Define a service to check URL

# http://blog.nicolargo.com/sitemap.xml.gz

 

define service{

use local-service

host_name blog

service_description URL Sitemap

check_command check_url!http://blog.nicolargo.com/sitem

ap.xml.gz

}

 

# Define a DDOS detection service

# http://blog.nicolargo.com/?p=4100

# Warning: >50 SYN_RECV

# Critical: >70 SYN_RECV

 

define service{

use local-service

host_name blog

service_description DDOS detect

check_command check_ddos!50!70

}

Ce fichier de configuration va permettre de superviser les choses suivantes:

  • état du serveur (réponse au ping en moins de 500ms et 60% de paquets perdus)
  • espace disque disponible > 5% de la taille totale (10% pour un warning)
  • pas plus de 3 personnes connectés en même temps sur le serveur (2 pour un warning)
  • pas plus de 400 processus lancés en parallèle (250 pour un warning)
  • mémoire disponible (basée sur RAM 1 Go) > 10% de la mémoire totale (20% pour un warning)
  • charge (CPU) moyenne sur 5 minutes < 10% (5% pour un warning)
  • espace de swap disponible > 10% de la taille totale du swap (20% pur warning)
  • Port SSH en écoute
  • Port HTTP en écoute
  • Vérification de l’existence du fichier de check de Google
  • Vérification de l’existence du fichier sitemap.xml (référencement dans moteur de recherche)

Il y a surement plein d’autres choses à vérifier…

A vos claviers pour nous dire cela dans les commentaire.

Catégories
Nagios Open-source Planet-libre Reseau Systeme Web

La supervision chez Web4All, hébergeur associatif

Ce billet a été rédigé par Jonathan Gaulupeau et à pour double objectif de mettre en avant Web4all, un hébergeur alternatif à but non lucratif et de montrer comment des outils open-source sont utilisés pour assurer une supervision professionnelle de ce type de réseau.


Web4All, qui sommes-nous ?

Web4All est une association à but non lucratif qui a pour but de fournir un hébergement mutualisé de qualité professionnelle au plus grand nombre. Nos offres, plus orientées vers l’utile que vers le tape-à-l’œil, sont parmi les moins chères du marché.

Notre gestion est totalement désintéressée. Tous les acteurs de Web4All sont des bénévoles animés par l’envie de rendre un service de qualité à plus de 2000 clients.

Nous sommes constamment à la recherche du meilleur rapport qualité / prix. Nous étudions pour cela aussi bien des solutions libres que propriétaires. Dans les faits, la quasi-totalité de nous outils est issue de la communauté open-source. Cependant, nos besoins étant parfois très spécifiques, nous développons également nos propres outils.

Pourquoi la supervision ?

Toute entité possédant un ou plusieurs serveurs (quels que soient les systèmes d’exploitation utilisés) se doit de contrôler en permanence leur état. D’autant plus lorsqu’il s’agit, comme nous, de serveurs dont dépend le maintien en conditions opérationnelles des services que nous proposons.

En réalité, ce n’est pas tout à fait le cas, notre infrastructure étant redondée afin de fournir des services à haut taux de disponibilité.

La supervision sous quelle forme, quels outils ?

Je n’ai parlé, jusqu’à présent, que de la supervision en temps réel. Celle qui nous remonte une alarme si un service ne respecte pas des paramètres que nous avons définis. Un technicien peut alors prendre en compte l’alarme, en chercher la cause et, de préférence, la régler. Si, malgré nos précautions, un service est impacté, le technicien en informe les clients par une interface dédiée.

Chez nous, cette supervision est assurée par Nagios.

Quelques services surveillés par Nagios sur un frontal Apache

Toutefois, un autre aspect est important dans la supervision : suivre l’évolution de divers indicateurs sur une période plus ou moins longue. En clair, nous avons besoin, par exemple, pour anticiper l’évolution de nos besoins en terme de stockage, de regarder l’évolution sur l’espace disque que nous avons eu par le passé. Ces indicateurs peuvent nous fournir des informations remontant à des mois, voire des années. Ils nous permettent également de prévoir les pics de charge que subira notre infrastructure. Très pratique pour savoir quand ne pas programmer des tâches d’archivage par exemple. Enfin, cela peut s’avérer très utile lorsqu’il s’agit de réaliser un état de santé général. Nous savons à quoi doivent ressembler nos graphiques, nous pouvons donc voir d’un coup d’œil si tout semble correct.

Cette partie est réalisée par un autre outil : Cacti.

Graphique de trafic réseau réalisé par Cacti

Tous ces indicateurs combinés nous permettent d’évaluer notre qualité, point très important pour la personne chargée de la QoS (Quality of Service). Ils nous permettent également de prévoir nos futurs achats et évolutions de l’infrastructure. Nous pouvons ainsi réaliser tous les tests nécessaires aux évolutions dans un environnement de pré-production, sans travailler dans l’urgence et la panique que pourrait constituer une dégradation de la qualité des services rendus aux clients.

Enfin, nous avons également une carte d’état en temps réel du réseau client de Web4All qui est accessible à tous les clients.

Cette carte se base sur les informations récupérées par Cacti.

Carte d’état en temps réel du réseau client de Web4All

Ce que nous supervisons

Tous ces tests sont réalisés dans Nagios ainsi que dans Cacti.

Les basiques

Les incontournables de la supervision que sont :

  • Le ping -> Un ping est réalisé sur le serveur, nous indiquant s’il est joignable ou non sur le réseau. C’est l’information la plus élémentaire dont nous avons besoin.
  • Le load average -> Le load est récupéré par SNMP. Il nous indique la charge système. Des seuils de criticité sont définis en fonction des habitudes de chaque serveur.
  • La mémoire -> Le taux de mémoire utilisée est récupéré par SNMP. Il nous permet de savoir si une application souffre d’une fuite mémoire par exemple.
  • L’espace disque -> Le taux d’espace libre sur les partitions des serveurs est récupéré par SNMP. Il nous permet d’être alertés avant qu’une partition ne soit pleine.

Le réseau

C’est le cœur de notre activité. Il fait donc l’objet de toutes les attentions.

Nous surveillons le taux de transfert de toutes les interfaces des serveurs. Nous pouvons alors être alertés en cas de pic anormal ainsi qu’étudier l’évolution de la charge réseau afin d’anticiper les besoins en terme de bande passante.

Les services

Chaque service est testé par Nagios grâce à des plug-ins.

Ces plugins sont soit récupérés sur la plateforme d’échange Nagios Exchange soit écrits spécifiquement pour Web4All.

Voici quelques exemples :

  • Serveur DNS -> Test de résolution de nom
  • Serveur Mail -> Test des protocoles POP, IMAP, SMTP, état de la queue des mails, etc.
  • Frontaux Apache -> Test des Apache Server Status
  • Load Balancers -> Vérification du nombre de serveurs dans le pool
  • Serveurs SQL -> Test de connexion à une base de données

Les aide-mémoires

Certains tests n’ont pour but que de nous rappeler de réaliser une action bien précise.

Par exemple, tous nos certificats SSL sont testés afin de nous remonter une alerte plusieurs semaines avant leur date d’expiration.

Conclusion

La supervision est un point essentiel chez Web4All. Elle nous permet d’avoir une meilleure réactivité grâce aux alertes remontées par Nagios, mais elle nous permet également de mieux préparer l’avenir grâce aux graphiques réalisés par Cacti.

Enfin, grâce à la supervision, nous pouvons également fournir à nos clients le taux de disponibilité réel de nos services.

 

A propos de l’auteur: Jonathan est expert sur le logiciel de conception mécanique CATIA V5, la « crise » du secteur automobile l’a poussé à s’orienter vers l’administration des systèmes Unix. Il est aujourd’hui Ingénieur Systèmes & Réseaux. Depuis 2009 il s’est engagé dans l’association Web4All ou il fait partie du Conseil d’Administration et ou il s’occupe de l’administration des serveurs ainsi que de leur supervision.

A propos de Web4All: Web4all est un hébergeur associatif qui propose des hébergements de site web à faible coût ainsi que la vente de nom de domaine et un service emails.

J’espère que comme moi cet article vous a intéressé. N’hésitez pas à poser des questions à Jonathan dans les commentaires de ce billet, je suis sur qu’il se fera un plaisir de vous répondre.