Catégories
Open-source Planet-libre

Supervision de son PC bureautique avec Glances

D’abord orienté vers la supervision de machines distantes, Glances permet également de surveiller l’ensemble des paramètres systèmes de ses machines bureautique. De plus, depuis sa version 1.7.2 , Glances offre une interface Curses sur l’ensembles des plateformes: GNU/Linux, BSD, Mac OS et même … MS Windows.

Il est en effet fréquent d’observer un ralentissement, voir un blocage de sa machine locale. Nous allons voir comment configurer puis utiliser Glances pour en trouver les causes et ainsi prendre les actions adéquates.

Configuration de Glances

Après installation de Glances sur son système (le plus simple étant de passer par PyPI), un fichier de configuration par défaut est disponible sous /etc/glances/glances.conf sous GNU/Linux (voir ici pour les emplacements sur les autres systèmes). Je vous conseille de copier ce fichier en local dans votre répertoire de configuration standard (~/.config/glances ou $XDG_CONFIG_HOME/glances).

mkdir -p ~/.config/glances
cp /etc/glances/glances.conf ~/.config/glances/

On peut ensuite éditer son fichier selon ses besoins: ~/.config/glances/glances.conf

Voici le fichier que j’utilise sur mon PC portable:

[cpu]
# Limits values for CPU user in %
# Defaults values if not defined: 50/70/90
user_careful=50
user_warning=70
user_critical=90
# Limits values for CPU system in %
# Defaults values if not defined: 50/70/90
system_careful=50
system_warning=70
system_critical=90
# Limits values for CPU iowait in %
# Defaults values if not defined: 40/60/80
# Not easy to tweek...
# Source: http://blog.scoutapp.com/articles/2011/02/10/understanding-disk-i-o-when-should-you-be-worried
#         http://blog.logicmonitor.com/2011/04/20/troubleshooting-server-performance-and-application-monitoring-a-real-example/
#         http://blog.developpeur-neurasthenique.fr/auto-hebergement-iowait-ma-tuer-1-2-vmstat-mpstat-atop-pidstat.html (FR)
iowait_careful=40
iowait_warning=60
iowait_critical=80

[load]
# Value * Core
# Defaults values if not defined: 0.7/1.0/5.0 per Core
# Source: http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages
#         http://www.linuxjournal.com/article/9001
careful=0.7
warning=1.0
critical=5.0

[memory]
# Defaults limits for free RAM memory in %
# Defaults values if not defined: 50/70/90
careful=50
warning=70
critical=90

[swap]
# Defaults limits for free swap memory in %
# Defaults values if not defined: 50/70/90
careful=50
warning=70
critical=90

[temperature]
# Temperatures in °C for sensors
# Defaults values if not defined: 60/70/80
careful=60
warning=70
critical=80

[hddtemperature]
# Temperatures in °C for hddtemp
# Defaults values if not defined: 45/52/60
careful=45
warning=52
critical=60

[filesystem]
# Defaults limits for free filesytem space in %
# Defaults values if not defined: 50/70/90
careful=50
warning=70
critical=90

[process]
# Limits values for CPU per process in %
# Defaults values if not defined: 50/70/90
cpu_careful=50
cpu_warning=70
cpu_critical=90
# Limits values for MEM per process in %
# Defaults values if not defined: 50/70/90
mem_careful=50
mem_warning=70
mem_critical=90

[monitor]
# Define the list of processes to monitor
# *** This section is optionnal ***
# The list is composed of item (list_#nb <= 10)
# An item is defined:
# * description: Description of the processes (max 16 chars)
# * regex: regular expression of the processes to monitor
# * command: (optional) full path to shell command/script for extended stat
#            Use with caution. Should return a single line string.
# * countmin: (optional) minimal number of processes
#             A warning will be displayed if number of process < count
# * countmax: (optional) maximum number of processes
#             A warning will be displayed if number of process > count
list_1_description=Chromium browser
list_1_regex=.*chromium-browse.*
list_1_countmax=50
list_2_description=OpenVPN
list_2_regex=.*openvpn.*
list_2_countmin=1
list_3_description=Dropbox
list_3_regex=.*dropbox.*
list_3_countmin=1
list_3_command=dropbox filestatus ~/Dropbox

En plus des jeux de limites pour les alertes de CPU, de charge (LOAD) et de mémoire (MEM), je souhaiterai que l’on s’attarde un peu sur la section [monitor] qui permet de mettre en avant une liste de processus jugés importants.

[monitor]
# Define the list of processes to monitor
# *** This section is optionnal ***
# The list is composed of item (list_#nb <= 10)
# An item is defined:
# * description: Description of the processes (max 16 chars)
# * regex: regular expression of the processes to monitor
# * command: (optional) full path to shell command/script for extended stat
#            Use with caution. Should return a single line string.
# * countmin: (optional) minimal number of processes
#             A warning will be displayed if number of process < count
# * countmax: (optional) maximum number of processes
#             A warning will be displayed if number of process > count
list_1_description=Chromium browser
list_1_regex=.*chromium-browse.*
list_1_countmax=50
list_2_description=OpenVPN
list_2_regex=.*openvpn.*
list_2_min=1
list_3_description=Dropbox
list_3_regex=.*dropbox.*
list_3_countmin=1
list_3_command=dropbox filestatus ~/Dropbox

Je défini donc 3 groupes de processus qui vont donner l’affichage suivant dans l’interface de Glances:

capture_142

Supervision de Chromium

Le premier groupe (list_1) permet de surveiller les processus relatifs à mon navigateur Web (Chromium).

Pour cela je lui donne un label (list_1_description) qui est une chaîne de caractères complètement arbitraire (mais limité à 15 caractères):

list_1_description=Chromium browser

Ensuite, il faut définir l’expression régulière qui va permettre de regrouper les processus:

list_1_regex=.*chromium-browse.*

Le problème avec Chromium, c’est qu’il peut être très consommateur de ressources (notamment mémoire) si l’on ouvre un grand nombre de pages. Je configure donc une surveillance du nombre maximum de processus. Glances affichera donc la ligne en rouge si ce nombre est dépassé:

list_1_countmax=50

Je ne défini pas de commande (list_1_command) associé à ce groupe. Donc par défaut Glances va calculer la consommation CPU et la mémoire globale des processus de ce groupe.

Supervision d’OpenVPN

J’utilise souvent un service VPN pour surfer (entre autre…) sur le Web. J’ai donc ajouté une supervision du processus OpenVPN:

list_2_description=OpenVPN
list_2_regex=.*openvpn.*
list_2_min=1

Contrairement à Chromium, je pose ici une alerte si le nombre de processus est inférieur à 1 (donc si OpenVPN n’est pas lancé).

Supervision de Dropbox

Avoir ces fichiers disponibles sur toutes ses machines est devenu pour moi complètement indispensable. La supervision du service Dropbox est faite par Glances de la manière suivante:

list_3_description=Dropbox
list_3_regex=.*dropbox.*
list_3_countmin=1
list_3_command=dropbox filestatus ~/Dropbox

Rien de bien nouveau sur les 3 première lignes, la dernière nécessite cependant quelques explications. La commande (shell) passée en paramètre de (list_3_command) sera exécuté à chaque « check » de Glances (donc par défaut toutes les 3 secondes). Cette commande va demander à Dropbox l’état de synchronisation mon répertoire (voir ce billet pour apprendre à  administrer Dropbox en ligne de commande).

Utilisation de Glances

Votre Glances est maintenant prêt à être utilisé. Donc si vous rencontrez un problème sur votre machine, il faudra ouvrir un terminal et saisir la commande:

glances -ey -C ~/.config/glances/glances.conf

Glances va se lancer et afficher les informations sur votre système:

capture_143

 

En plus de la section [monitor] ou l’on retrouve la supervision de nos groupes Chromium, OpenVPN et Dropbox, on a également l’ensemble des informations systèmes.

Dans le bandeau du haut, les informations sur la CPU, la charge et la mémoire. Les codes couleurs sont standards:

GREEN stat counter is "OK"
BLUE stat counter is "CAREFUL"
MAGENTA stat counter is "WARNING"
RED stat counter is "CRITICAL"

Sur le panneau de gauche, on a les informations moins critiques comme: les débits des interfaces réseau, les capteurs de température, les IO disques et l’espace disque.

Au centre, sur la section [monitor], on retrouve la liste des processus avec, par défaut, un tri « intelligent ». Par exemple, en cas de consommation mémoire excessive, le tri sera automatiquement fait sur la consommation RAM des processus.

Enfin en bas de l’écran, un rappel des dernières alertes.

Pour une description précise des fonctions de Glances, je vous conseille la lecture de la documentation officielle (lisible ici).

Conclusion

Nous arrivons à la fin de ce billet. Je n’ai pas parlé du mode client serveur qui permet de lancer Glances en tache de fond et de l’interroger à la demande mais je pense que ce mode d’utilisation est plus utilise pour la supervision de serveurs.

Si vous avez des configurations spécifiques de Glances (et surtout du [monitor]) pour surveiller vos PC, partager cela (configuration et screenshot) avec nous !

Catégories
Open-source Planet-libre

Glances 1.7.2 et son interface pour Windows

glances-white-256

Glances est maintenant disponible dans sa version 1.7.2. Au chapitre des nouveautés, une nouvelle interface cliente pour ceux d’entre vous qui ne peuvent pas se passer, par choix ou par contrainte, du système d’exploitation Microsoft Windows.  Cette interface se base sur la librairie ColorConsole et permet dans une console de commande Windows d’avoir un « look and feel » qui se rapproche de la version GNU/Linux.

Voici le résultat dans une console standard sous Windows 7:

glances-1.7.2-windows-cmd

Je vous conseille cependant de télécharger la console Console2 qui comble en partie les manques de la console par défaut (cmd).

glances-1.7.2-windows-console2

Afin de faciliter l’installation sur Windows, Frédéric Aoustin a eu la bonne idée de créer un installeur qui installe Python, les librairies nécessaires ainsi que Glances. L’installeur est disponible ici:

downloadGlances-1.7.2-win32.msi
(32-bit, MD5: dba4f6cc9f47b6806ffaeb665c093270)

Je pense que la plupart des lecteurs de ce blog ne seront jamais arrivés jusqu’ici mais si c’est le cas, ils seront heureux d’apprendre que cette version apporte également les améliorations suivantes:

  • Mise à jour de la documentation
  • Amélioration du packaging pour BSD et OpenSuse
  • Correction de nombreux bugs

Pour les Linuxiens, une mise à jour à partir de Pip est à faire avec la ligne de commande:

sudo pip install --upgrade Glances

A vos commentaires…

Catégories
Nagios Open-source Planet-libre

Nagios 4: Résoudre l’erreur « Can’t open /etc/rc.d/init.d/functions »

La version 4 de Nagios est enfin sortie et vous avez décidé de l’installer sur votre serveur Debian/Ubuntu. Il y a de forte chance que vous tombiez sur un message d’erreur au lancement du démon Nagios. Nous allons voir dans ce billet comment résoudre ce problème.

Identification du problème

Vous avez le message suivant quand vous lancer Nagios ?

# /etc/init.d/nagios start
/etc/init.d/nagios: 20: .: Can't open /etc/rc.d/init.d/functions

alors ce billet est fait pour vous…

Explication du pourquoi…

Depuis la mise à jour de Nagios vers la version 4.0 (et la version corrective 4.0.1) un bug plutôt gênant peut impacter les machines Debian et Ubuntu. En effet le script de démarrage de Nagios qui se trouve dans le fichier /etc/init.d/nagios fait un appel à un ensemble de fonctions génériques sous /etc/rc.d/init.d/functions. Malheureusement, ce fichier n’existe pas sous ce nom sur les dernières versions de Debian/Ubuntu mais il est disponible sous  /lib/lsb/init-functions.

Comment résoudre le problème étape par étape…

On commence par installer le logiciel daemon qui est utilisé par le script d’installation nouvelle mouture:

sudo apt-get install daemon

Puis on hack le script de démarrage:

        sudo sed -i 's/^\.\ \/etc\/rc.d\/init.d\/functions$/\.\ \/lib\/lsb\/init-functions/g' /etc/init.d/nagios
        sudo sed -i 's/status\ /status_of_proc\ /g' /etc/init.d/nagios
        sudo sed -i 's/daemon\ --user=\$user\ \$exec\ -ud\ \$config/daemon\ --user=\$user\ --\ \$exec\ -d\ \$config/g' /etc/init.d/nagios
        sudo sed -i 's/\/var\/lock\/subsys\/\$prog/\/var\/lock\/\$prog/g' /etc/init.d/nagios
        sudo sed -i 's/\/sbin\/service\ nagios\ configtest/\/usr\/sbin\/service\ nagios\ configtest/g' /etc/init.d/nagios
        sudo sed -i 's/\"\ \=\=\ \"/\"\ \=\ \"/g' /etc/init.d/nagios
        sudo sed -i "s/\#\#killproc\ \-p\ \${pidfile\}\ \-d\ 10/killproc\ \-p \${pidfile\}/g" /etc/init.d/nagios
        sudo sed -i "s/runuser/su/g" /etc/init.d/nagios
        sudo sed -i "s/use_precached_objects=\"false\"/&\ndaemonpid=\$(pidof daemon)/" /etc/init.d/nagios
        sudo sed -i "s/killproc\ -p\ \${pidfile}\ -d\ 10\ \$exec/\/sbin\/start-stop-daemon\ --user=\$user\ \$exec\ --stop/g" /etc/init.d/nagios
        sudo sed -i "s/\/sbin\/start-stop-daemon\ --user=\$user\ \$exec\ --stop/&\n\tkill -9 \$daemonpid/" /etc/init.d/nagios

Il ne reste plus qu’à redémarrer Nagios:

sudo service nagios start

 …Ou utiliser un script qui fait tout pour vous

Pour les gros flemmards que vous êtes, j’ai créé un script qui va vérifier que le problème existe sur votre configuration et le corriger pour vous:

wget https://raw.github.com/nicolargo/nagiosautoinstall/master/hack4nagiosstart.sh
chmod a+x ./hack4nagiosstart.sh
./hack4nagiosstart.sh

Note: J’ai également ajouter l’appel à ce hack dans mes scripts d’installation et de mise à jour automatique de Nagios.

Catégories
Open-source Planet-libre Reseau Video

Installation d’un serveur proxy HTTP Squid sous Debian

Marre de ne pas pouvoir regarder une vidéo  basse résolution sur YouTube alors que votre FAI adoré (Free pour ne pas le citer) annonce un débit sur votre ligne de plusieurs megabits par seconde ?

Il suffit de disposer d’un simple serveur dédié ou virtuel chez un hébergeur (autre que Free bien sûr), d’y installer un proxy HTTP et à vous les vidéos en HD même en pleine soirée.

Pour illustrer ce billet, j’ai donc installé Squid (le plus connu des proxy Web) sur mon serveur OVH qui dispose d’une liaison directe, illimitée et non bridée vers Internet à 100 Mbps.

squid

Installation du serveur Squid

On commence par mettre à jour son système avec la combo:

sudo apt-get update && sudo apt-get upgrade

Ensuite on installe le logiciel Squid qui à le bon goût d’être dans les dépôts officiels de Debian:

sudo apt-get install squid

Puis on arrête le service Squid (qui doit maintenant tourner en tache de fond) en attendant sa configuration:

sudo service squid stop

On édite la configuration qui se trouve centralisée dans le fichier /etc/squid/squid.conf en éditant notamment:

  1. La gestion de l’accès au service uniquement réservé aux adresses IP clairement identifiées (par exemple remplacer AAA.BBB.CCC.DDD par l’adresse IP publique de votre domicile). Vous pouvez ajouter autant de ligne que d’adresse IP.
    acl nicolargo src AAA.BBB.CCC.DDD/32 # Home sweet home
    http_access allow nicolargo
  2. On masque notre adresse IP dans le header HTTP (X-Forwarded-For: unknown)
    forwarded_for off

Note: la liste des options disponibles est décrite sur le site officiel (la version de Squid disponible sous Wheezy est, au moment de l’écriture de ce billet, la branche 2.7) ou par la commande ‘man squid.conf’.

Une fois la configuration finalisé en fonction de vos besoins, il suffit de relancer le service:

sudo service squid start

Configuration des machines clientes

Il ne rest plus qu’à configurer son/ses clients (PC, Smarthphone ou tablette) pour utiliser le serveur proxy Squid fraîchement installé.

Avec une configuration par défaut, Squid est en écoute sur le port TCP numéro 3128. Il faut donc, pour utiliser le serveur proxy Squid configurer l’adresse IP de votre machine hébergeant Squid et le port 3128.

Si vous utilisez Chromium comme navigateur Web, je vous conseille l’installation du plugin TunnelSwitch (lien vers le store) qui va vous permettre de passer rapidement (en un seul click de souris) entre un lien direct (sans proxy) et indirect (avec proxy).

capture_133

 

capture_134

Catégories
Developpement Open-source Planet-libre

Gérer ces processus/démons Python avec Supervisor

C’est en lisant la document du projet 0Bin, une implémentation libre et auto-hébergé de PasteBin dont je reparlerai bientôt, que je suis tombé sur Supervisor. Supervisor est un système de contrôle de processus (comme launchd ou runinit) simple et orienté utilisateur (voir la documentation et les avantages ici) et donc idéal pour lancer des processus Python en mode démon (par un exemple un serveur Glances, mais ce n’est qu’un exemple…).

Installation de Supervisor

Sur un système Debian/Ubuntu, l’installation de Supervisor se résume à la saisie de la commande suivante dans un terminal:

sudo apt-get install supervisor

Une fois l’installation terminé, nous allons maintenant configurer Supervisor en utilisant le fichier /etc/supervisor/supervisord.conf (sur un système Debian).

Ajout d’un démon dans Supervisor

Nous allons donc prendre l’exemple d’un administrateur système qui souhaite que le serveur Glances soit lancé au démarrage de la machine et que celui ci soit redémarré automatiquement dans le cas ou Glances plante <mauvaisefois>ce qui n’arrive jamais</mauvaisefois>.

Pour lancer Glances en mode serveur, il faut utiliser la ligne de commande suivante:

/usr/local/bin/glances -s -C /etc/glances/glances.conf -P motdepasse

Il suffit donc d’ajouter la section suivante en fin du fichier  /etc/supervisor/supervisord.conf:

; Glances server section
[program:glances]
command=/usr/local/bin/glances -s -C /etc/glances/glances.conf -P motdepasse
user=nicolargo
autostart=true
autorestart=true

On demande a ce que le processus soit exécuté avec les droits d’un utilisateur standard (user=nicolargo dans mon exemple) et que le processus démarre automatiquement au démarrage de Supervisor (autostart=true) et qu’il soit bien redémarré si Supervisor détecte un problème sur le processus Glances.

Prendre en compte la configuration et administrer nos processus

Pour que notre configuration soit prise en compte, il faut relancer Supervisor avec les lignes de commandes:

sudo service supervisor stop
sudo service supervisor start

Normalement, à ce stade, votre processus Glances server doit être lancé. Pour le vérifier vous pouvez utiliser la commande supervisorctl qui permet d’avoir un statu des processus et un moyen simple de les arrêter / démarrer.

Vérification du statu du service Glances server:

$ sudo supervisorctl status
glances                          RUNNING    pid 5844, uptime 0:26:11

Je vous laisse regarder les autres commandes disponibles avec supervisorctl:

$ sudo supervisorctl help

default commands (type help <topic>):
=====================================
add    clear  fg        open  quit    remove  restart   start   stop  update 
avail  exit   maintail  pid   reload  reread  shutdown  status  tail  version

 

Catégories
Open-source Planet-libre Systeme

Dropbox et la ligne de commande

Je suis utilisateur du service Dropbox depuis maintenant quelques temps. Il me permet de synchroniser les fichiers entres mes différentes machines (même les serveurs). Depuis ses débuts, Dropbox propose un client pour système GNU/Linux complètement intégré dans l’environnement graphique.

Ce qui est moins connu, c’est l’utilisation de la bonne vieille ligne de commande pour profiter de ce service. C’est ce que nous allons voir ensemble dans ce billet en parcourant quelques fonctions disponibles.

Ré-initialiser du cache

Dans certains cas, il se peut que votre client Dropbox tourne dans le vide (l’icône de notification reste bloqué sur une mise à jour de fichier). Je suis bien placé pour le savoir car cela vient de m’arriver…

Pour repartir d’une configuration propre, il est nécessaire de nettoyer le cache de Dropbox. Il n’y a pas de commande à proprement parler pour faire cela mais un simple:

rm -R ~/Dropbox/.dropbox.cache/*

devrait suffire à remettre votre Dropbox dans le droit chemin de la synchronisation.

Arrêter puis relancer Dropbox en ligne de commande

Si vous avez à écrire un script shell qui va générer des fichiers non désirables (ou bien trop volumineux) dans un des répertoire de votre Dropbox, il peut être utile d’arrêter puis de relancer le service depuis le script. On évitera ainsi de saturer sa ligne internet avec des transferts inutiles.

Pour cela on utilisera les commandes:

dropbox stop
...
<votre script ici>
...
dropbox start

Obtenir des informations sur l’état de Dropbox

Pour obtenir le status du démon Dropbox (processus dropboxd), il est possible d’utiliser:

$ dropbox  status
Idle

Note: la commande ‘dropbox running’ renvoie le code retour 1 si le démon Dropbox est lancé, 0 sinon. 

Si vous souhaitez avoir l’état de synchronisation de votre répertoire ~/Dropbox:

$ dropbox filestatus ~/Dropbox/
/home/nicolargo/Dropbox/: up to date

Il est possible de passer en paramètre de cette dernière fonction un fichier (ou un répertoire):

$ dropbox filestatus ~/Dropbox/Public/ESIL2010-Cloud.pdf 
/home/nicolargo/Dropbox/Public/ESIL2010-Cloud.pdf: up to date

Obtenir l’URL publique des fichiers de votre Dropbox

Last but not least, Dropbox permet de partager vos fichiers en générant une URL publique. Celle-ci peut être obtenue en ligne de commande (ou dans vos scripts) via:

$ dropbox puburl ~/Dropbox/Public/ESIL2010-Cloud.pdf 
https://dl.dropboxusercontent.com/u/1112933/ESIL2010-Cloud.pdf

Pour aller plus loin: l’API Python

Si (comme moi), vous développez en Python, il existe une API permettant de jouer avec le service Dropbox. Je vous conseille la lecture de la page officielle sur le sujet.

Catégories
Hardware Nagios Open-source Planet-libre

Supervision d’un NAS NetApp avec Nagios ou Shinken

Dans la jungle très lucrative des « NAS appliance », c’est à dire des serveurs NAS intégré dans un hardware et un système spécifique, NetApp fait office de leader pour la qualité prix de ses produits. Nous allons voir ensemble dans ce billet comment superviser une machine NetApp FAS2200 à partir de Nagios ou de Shinken.

nas01

Note: ce billet doit également être valable pour l’ensemble des produits NetApp.

Récupération du plugin chek-netapp-ng

En cherchant un peu sur le Web, j’ai trouvé un plugin Nagios permettant de superviser finement ses machines NetApp. Bien que datant un peu, ce plugin est parfaitement fonctionnel.

Une fois connecté en SSH (en root) sur son serveur Nagios / Shinken (la procédure est la même), on commence donc par récupérer le plugin:

mkdir -p ~/tmp
cd ~/tmp
wget --no-check-certificate https://raw.githubusercontent.com/ranl/monitor-utils/master/nagios/check-netapp-ng.pl
chmod a+x check-netapp-ng.pl

Installation du plugin chek-netapp-ng

L’installation différe ici si vous utilisez Nagios ou Shinken.

Pour installer le plugin sur Nagios, il faut saisir:

cp ~/check-netapp-ng.pl /usr/local/nagios/libexec/check-netapp-ng.pl
chown nagios:nagios /usr/local/nagios/libexec/check-netapp-ng.pl

Pour Shinken:

cp ~/check-netapp-ng.pl /usr/local/shinken/libexec/check-netapp-ng.pl
chown shinken:shinken /usr/local/shinken/libexec/check-netapp-ng.pl

Configuration du plugin chek-netapp-ng

Il faut ensuite éditer le fichier (par exemple /usr/local/shinken/libexec/check-netapp-ng.pl) pour y éditer la ligne numéro 15 avec le chemin vers les librairies:

use lib "/usr/local/shinken/libexec";

 Note: Respectivement /usr/local/nagios/libexec pour Nagios.

On doit ensuite faire connaître le plugin à Shinken (ou Nagios) en ajoutant les lignes suivantes dans votre fichier commands.cfg (sous /usr/local/shinken/etc):

################################################################################
# Netapp check
#===============================================================================
# https://github.com/ranl/IT/blob/master/Nagios/check-netapp-ng.pl
################################################################################

define command {
    command_name    check_netapp_globalstatus
    command_line    $PLUGINSDIR$/check-netapp-ng.pl -H $HOSTADDRESS$ -C $SNMPCOMMUNITYREAD$ -T GLOBALSTATUS
}

define command {
    command_name    check_netapp_temp
    command_line    $PLUGINSDIR$/check-netapp-ng.pl -H $HOSTADDRESS$ -C $SNMPCOMMUNITYREAD$ -T TEMP
}

define command {
    command_name    check_netapp_fan
    command_line    $PLUGINSDIR$/check-netapp-ng.pl -H $HOSTADDRESS$ -C $SNMPCOMMUNITYREAD$ -T FAN
}

define command {
    command_name    check_netapp_ps
    command_line    $PLUGINSDIR$/check-netapp-ng.pl -H $HOSTADDRESS$ -C $SNMPCOMMUNITYREAD$ -T PS
}

define command {
    command_name    check_netapp_cpuload
    command_line    $PLUGINSDIR$/check-netapp-ng.pl -H $HOSTADDRESS$ -C $SNMPCOMMUNITYREAD$ -T CPULOAD
}

define command {
    command_name    check_netapp_nvram
    command_line    $PLUGINSDIR$/check-netapp-ng.pl -H $HOSTADDRESS$ -C $SNMPCOMMUNITYREAD$ -T NVRAM
}

define command {
    command_name    check_netapp_diskused
    command_line    $PLUGINSDIR$/check-netapp-ng.pl -H $HOSTADDRESS$ -C $SNMPCOMMUNITYREAD$ -T DISKUSED --vol $ARG1$
}

define command {
    command_name    check_netapp_faileddisk
    command_line    $PLUGINSDIR$/check-netapp-ng.pl -H $HOSTADDRESS$ -C $SNMPCOMMUNITYREAD$ -T FAILEDDISK
}

Déclaration de votre serveur NAS

Il ne reste plus qu’à définir votre serveur NAS dans la configuration de Shinken (ou de Nagios). Par exemple, j’ai un fichier nas01.cfg qui contient:

define host {
  use   ssh,generic-host
  host_name nas01
  address   192.168.1.130
}

define service {
  use generic-service
  host_name nas01
  service_description NetAPP Global status
  check_command check_netapp_globalstatus
}

define service {
  use generic-service
  host_name nas01
  service_description NetAPP Temperature
  check_command check_netapp_temp
}

define service {
  use generic-service
  host_name nas01
  service_description NetAPP FAN
  check_command check_netapp_fan
}

define service {
  use generic-service
  host_name nas01
  service_description NetAPP Power Supply
  check_command check_netapp_ps
}

define service {
  use generic-service
  host_name nas01
  service_description NetAPP CPU LOAD
  check_command check_netapp_cpuload
}

define service {
  use generic-service
  host_name nas01
  service_description NetAPP NVRAM
  check_command check_netapp_nvram
}

define service {
  use generic-service
  host_name nas01
  service_description NetAPP Disk used Home
  check_command check_netapp_diskused!/vol/vol0/
}

define service {
  use generic-service
  host_name nas01
  service_description NetAPP Disk used Archive
  check_command check_netapp_diskused!/vol/vol_ARCHIVE/
}

define service {
  use generic-service
  host_name nas01
  service_description NetAPP Disk used Install
  check_command check_netapp_diskused!/vol/vol_INSTALL/
}

define service {
  use generic-service
  host_name nas01
  service_description NetAPP Failed disk
  check_command check_netapp_faileddisk
}

Une fois Shinken (ou Nagios) redémarré et après les premiers checks, vous devriez voir la page de supervision apparaître dans l’interface Web (comme au début de ce billet).

On peut donc superviser les choses suivantes:

  • La charge CPU (ce qui peut être utile si votre serveur NAS est trop chargé, par exemple trop d’accès simultanés)
  • La taille utilisé par partitions
  • L’état des ventilateuts
  • L’état des disques (supervision du RAID)
  • Le status global

Voilà une bonne chose de faite: la supervision du serveur le plus sensible (il y a toutes vos données dessus normalement) de votre infrastructure.

Catégories
Open-source Planet-libre Reseau Systeme

Distributed Monitoring Nagios à l’aide de Mod-Gearman

Pour nous parler de Nagios et de supervision distribuée, j’ai le plaisir d’accueillir sur ce blog, en tant que rédacteur invité, Laurent Hugot. Laurent travaille actuellement pour la société Altair en Belgique et à en charge les activités de supervision.

===

Le « Distributed Monitoring » est une solution utilisée lorsque l’on veut surveiller plusieurs sites avec une seule installation de Nagios, qu’elle soit redondante ou non. La solution mise en avant dans ce billet est Mod-Gearman qui est un module Nagios abouti, performant et fiable.

Que nécessite cette solution ?

Le DistributedMonitoring de Nagios avec Mod-Gearman nécessite au minimum deux éléments :

  • Un serveur qui sera à la fois le serveur Nagios et le serveur de jobs Mod-Gearman
  • Un Worker qui peut être indépendant ou présent sur le serveur de jobs Mod-Gearman

Comment cela fonctionne-t-il ?

Mod-Gearman fonctionne de cette façon :

  • Un côté Job Server qui distribuera les jobs et rapatriera les résultats
  • Et un côté Worker qui réalisera les checks sur les hôtes de ses hostgroups

De manière plus précise le fonctionnement détaillé est le suivant:

  1. Le serveur de Jobs attend d’être contacté par des workers
  2. Lorsque les workers contactent le job server , ils s’authentifient auprès de lui, et il les répertorie
  3. Le serveur de jobs dispose d’un Event Broker que l’on insère dans Nagios
  4. Il remplacera donc la partie de Nagios qui réalise les checks, pour pouvoir les distribuer à sa guise

Un worker peut avoir plusieurs hostgroups d’assignés. Pour chaque hostgroup auquel il sera assigné, il prendra les jobs que le serveur de jobs mettra à disposition.

Côté technique

Le serveur de Jobs ne contacte pas les workers. Ce sont les workers qui contactent le serveur de jobs.

Cela implique qu’il soit joignable depuis l’extérieur, mais cela implique surtout que vos workers , à l’abris derrière des firewalls bien configurés, pourront communiquer sans le moindre souci avec votre serveur de jobs. Cela vous épargne de devoir percer le moindre trou dans les Firewalls de vos précieux clients.

Les connexions entre vos workers et votre (ou vos) job server(s) sont chiffrées, vous pouvez configurer votre structure pour désactiver ce chiffrement, si vous le souhaitez. On peut configurer la structure pour gérer les hosts et les services ou alors gérer les hostgroups. Ici j’aborderai la solution Hostgroups, pour le distributed monitoring, le mode host&services serait plutôt du failOver et loadbalancing pur.

Côté pratique

Pour faire simple (mais alors vraiment simple): on installe le serveur jobs sur le serveur de Nagios, on configure le NEB (Nagios Event Broker) dans la configuration de Nagios, et ensuite on configure un worker par site à surveiller, on le branche et c’est terminé. (Oui, aussi simple.)

Plus sérieusement : la configuration sera expliquée plus bas, mais le système est fait de telle façon à accueillir chaque worker qui se connecte au serveur de jobs, et de cette façon la distribution est totalement automatique tant que la configuration des hostgroups et du worker est faite comme il se doit.

Un peu de théorie

Avant de parler d’installation et de configuration, apprenons le concept, et le fonctionnement d’un Nagios fonctionnant avec un Mod-Gearman.

Voici un schéma illustrant mon serveur Nagios en production:

nagios-modgearman

On voit ici la façon dont j’ai architecturé mon Nagios pour gérer des clients facilement.

Chaque dossier client qui se trouve dans /etc/nagios3/conf.d/hosts/ contient un fichier de définition de hostgroup , et un fichier par machine , et un dernier fichier comprennant les personnes de contact à mailer pour les alertes, et les plages horaires.

Le reste des fichiers de configuration sont dans /etc/nagios3/conf.d/

Ici sont les templates utilisés pour tous les clients , et les templates /contacts / timeperiods utilisés pour notre infrastructure.

J’ai représenté deux workers qui contactent, à travers plusieurs Firewalls mon serveur de jobs , qui prend les checks à nagios et qui lui restitue les résultats.

Il n’y a pas de modifications à apporter à Nagios pour dire. Une mention pour chaque hôte lui spécifiant quel worker doit se charger de lui, un Event Broker dans /etc/nagios3/nagios.cfg et c’est tout. Pour le reste c’est de la config de Workers.

Préparatifs et installation étape par étape

Pour préparer un serveur de jobs et un worker, il faut suivre quelques étapes cruciales.

Nous avons besoin avant de commencer :

Un Serveur Nagios 3.4.1 sur une Debian 7 (la manœuvre ne diffère pas beaucoup selon les OS , juste la façon de compiler qui devrait être différente, mais je n’expliquerai ici que la méthode que j’ai réalisé pour Debian, travaillant exclusivement sur cet OS. Merci Antoine Habran 😀 )

Et en bonus : Un Worker Raspberry Pi mod. B. (ou sinon un autre pc.)

En bonus car on peut s’en passer, car le Job Server peut contenir un Worker. Mais l’idée c’est de mettre le Worker ailleurs sur le net et le voir contacter notre serveur, pas vrai ? 

Explications

Nous allons télécharger et installer sur notre serveur Nagios « Gearmand »  qui est le « moteur » de mod-gearman , et ensuite, mod-gearman. La seconde étape consiste à configurer Nagios en mode Broker et à configurer le job server. Ensuite, on passera à la création d’un hôte d’exemple pour expliquer comment il sera géré et que vous puissiez vous en inspirer. Pour terminer on configurera un Worker (je ferai un exemple d’un worker Raspberry Pi Mod.B et un worker sur un debian 7 normal sur VM machine physique)

Installation de Mod-Gearman

Ah ouais, là on y est ! les prochaines lignes vont décrire les étapes nécessaires a l’installation de mod-gearman , et on va procéder comme suit :

  1. Installation des packages pour l’installation
  2. Téléchargement de la source de Gearmand
  3. Décompression de la source Gearmand
  4. Compilation de Gearmand
  5. Installation de Gearmand
  6. Téléchargement de la source de mod-gearman
  7. Décompression de la source mod-gearman
  8. Compilation de mod-gearman
  9. Installation de mod-gearman
  10. Configuration du job server mod-gearman
  11. Configuration du N.E.B de Nagios
  12. Configuration du Worker mod-gearman

Là nous aurons un serveur mod-gearman complet et opérationnel.

Il ne manquera qu’un Worker pour surveiller un site distant, mais le serveur sera fonctionnel et autonome, déjà.

D’abord avant de faire quoi que ce soit, il faut installer tous les prérequis pour la compilation et l’installation de gearmand, et mod-gearman.

Donc , si vous avez bien mis à jour votre système (apt-get update , apt-get upgrade)

On lance ceci :

apt-get install libcurl4-gnutls-dev autoconf automake make gcc g++ netcat uuid-dev libltdl7 libltdl-dev libncurses5-dev libevent-dev libboost-dev libboost-graph-dev libboost-iostreams-dev libboost-program-options-dev build-essential libboost-thread-dev libcloog-ppl0

On devrait avoir à ce stade tous les éléments pour la compilation, sauf un (libgearman6) qui doit s’installer après.

On passe ensuite au téléchargement et décompression des sources de Mod-Gearman:

cd /tmp
wget https://launchpad.net/gearmand/1.2/1.1.9/+download/gearmand-1.1.9.tar.gz
tar zxvf gearmand-1.1.9.tar.gz
cd gearmand-1.1.9

Maintenant on prépare le système pour réaliser l’installation de gearmand dans le dossier /opt/ en faisant comme ça , on peut le mettre à jour très facilement et proprement , ou le supprimer. Tapons ces deux lignes :

echo «opt/lib/» /etc/ld.so.conf.d/opt_lib.conf
ldconfig

On lance l’installation:

./configure --prefix=/opt
make
make install

Et si jusqu’ici tout a bien fonctionné et que vous n’avez pas d’erreurs : Le plus dur est fait !.

Maintenant que Gearmand est installé, on peut installer Mod-Gearman.

cd /tmp
wget http://labs.consol.de/wp-content/uploads/2010/09/mod_gearman-1.4.2.tar.gz
tar zxvf mod-gearman-1.4.2.tar.gz
cd mod-gearman-1.4.2

Puis on lance l’installation:

./configure --prefix=/opt --with-gearman=/opt --with-user=nagios --with-init-dir=/etc/init.d
make
make install
make install-config

On doit maintenant copier un fichier vers /etc/init.d pour pouvoir lancer proprement gearmand.

cp ./extras/gearmand-init /etc/init.d/gearmand

ensuite il faut ajouter un shell a l’utilisateur Nagios 

chsh nagios
>> /bin/bash

chmod –R 770 /opt/var/log/mod_gearman
chown –R nagios:nagios /opt/var/log/mod_gearman

Voila qui est fait.

Note: Correction du script de démarrage de Gearmand 

Si vous subissez un plantage lorsque vous tentez de démarrer gearmand , (ce qui était systématiquement mon cas…)  il y a une modification à faire dans le script de démarrage /etc/init.d/gearmand

Démarrez gearmand :

/etc/init.d/gearmand start

Si vous avez un crash, c’est quasi obligatoirement ceci : La ligne 89 du script contient un argument de verbosité qui fait planter gearmand.

Supprimez l’argument de verbosité dans cette ligne :

CMD= »$DAEMON -p $PORT -P $PIDFILE $OPTIONS –log-file=$LOGFILE –verbose=2 –listen=$LISTEN »

Et retirez le –verbose=2

Cette option, pour une raison qui m’échappe fait planter gearmand.

Si tout fonctionne, arrêtez Gearmand (On le rallumera plus tard).

/etc/init.d/gearmand stop

Configuration du Job Server sur le serveur

Configurons le serveur de jobs pour l’intégrer à nagios et le rendre prêt à accueuillir un worker.

Éditons le fichier de config /opt/etc/mod_gearman_neb.conf:

debug=0
logfile=/opt/var/log/mod_gearman/mod_gearman_neb.log
server=127.0.0.1:4730
do_hostchecks=yes
encryption=yes
key=Superpasswordquidéchire
use_uniq_jobs=on
localhostgroups=
localservicegroups=
queue_custom_variable=WORKER
result_workers=1
perfdata=no
perfdata_mode=1
orphan_host_checks=yes
orphan_service_checks=yes
accept_clear_results=no

Ici l’important, c’est la key, elle doit être identique sur votre fichier NEB et sur vos workers.

La « queue_custom_variable » est essentielle aussi, elle définit ce qui qualifie un worker pour la configuration d’un hôte. Vous verrez pourquoi on définit cette valeur plus loin.

On va passer au worker maintenant.

Configuration du Worker sur le serveur

On va configurer notre serveur pour qu’il surveille le site dans lequel il se trouve. En faisant cela, notre serveur Nagios – mod-Gearmand va surveiller le hostgroup dans lequel vous avez mis toutes vos machines, un peu comme avant l’installation de mod-gearman.

Pour ça , on édite le fichier /opt/etc/mod_gearman_worker.conf (avec quelques informations masquées… je conserve un peu de secret concernant mon infrastructure de production :D):

debug=0
hostgroups=hostgroup1-servers,hostgroup2-servers
logfile=/opt/var/log/mod_gearman/mod_gearman_worker.log
server=127.0.0.1:4730
encryption=yes
key=Superpasswordquidéchire
job_timeout=60
min-worker=5
max-worker=50
idle-timeout=30
max-jobs=1000
spawn-rate=1
fork_on_exec=no
load_limit1=0
load_limit5=0
load_limit15=0
show_error_output=yes
enable_embedded_perl=on
use_embedded_perl_implicitly=off
use_perl_cache=on
p1_file=/opt/share/mod_gearman/mod_gearman_p1.pl
workaround_rc_25=off

Voila, c’est une configuration basique, pour le worker du serveur. Ajoutez les hostgroups que vous souhaitez checker avec CE worker , le mot de passe partagé par le serveur et les workers, et l’ip du serveur. Le reste sert à gérer le comportement du worker, ses limites, seuils.

A partir de là , le système est prêt à fonctionner, mais… pas la configuration de Nagios. On va donc s’occuper de ça !

Configuration de Nagios

Nous devons éditer Nagios pour lui dire que maintenant c’est papa qui s’occupe des checks.

ATTENTION : Ne JAMAIS inclure ou retirer de module BROKER (comme on va faire là) a chaud, ne jamais modifier quelque fichier que ce soit d’un module BROKER a chaud.

Distinction entre fichiers de module et fichier de config de mod-gearman toutefois.

Mod-gearman est indépendant du module broker et peut être redémarrer pendant que nagios tourne. Pour l’inclusion du Broker dans nagios, on arrête celui-ci.

/etc/init.d/nagios3 stop

On va éditer son fichier de configuration /etc/nagios3/nagios.cfg

Broker_module=/opt/lib/mod_gearman/mod_gearman.o config=/opt/etc/mod_gearman_neb.conf

Note: En une ligne séparé d’un espace.

Configuration des hostgroups

Il nous est nécessaire d’avoir une configuration orientée hostgroups pour mettre en place votre architecture distribuée.

Je vais illustrer cette configuration comme sur le schéma du début du document. On va donc créer deux hostgroups : hostgroup1-servers et hostgroup2-servers :

touch /etc/nagios3/conf.d/hosts/client1/hostgroup1.cfg
touch /etc/nagios3/conf.d/hosts/client2/hostgroup2.cfg

ensuite on va ajouter des machines, il nous faut au moins une machine par hostgroup.

touch /etc/nagios3/conf.d/hosts/client1/serveurnagios.cfg
touch /etc/nagios3/conf.d/hosts/client2/serveurlambda.cfg

il nous faut un worker sur le site distant, disons que le client2 est a 200Km d’où je me trouve, je me rend sur place, je déploie un worker, dont on parlera plus bas, et je ne m’en occupe plus, mais il faut le surveiller aussi le petit coquin 

touch /etc/nagios3/conf.d/hosts/client2/worker.cfg

Voici le fichier contenu de mon fichier hostgroup1.cfg:

define hostgroup{
hostgroup_name hostgroup1-servers
alias mes serveurs du hostgroup 1
members hostgroup1-serveurnagios
}

define hostextinfo{
hostgroup_name hostgroup1-servers
notes serveurs du hostgroup1
icon_image base/uneimage.png
icon_image_alt hostgroup1 logo
vrml_image base/uneimage.png
statusmap_image base/uneimage.png
}

Ici rien de spécial, comme vous le voyez. Le hostgroup est défini normalement.

Voici un fichier pour l’hôte « hostgroup1-serveurnagios » /etc/nagios3/conf.d/hosts/hostgroup1/serveurnagios.cfg

define host{
       use generic-host
       host_name hostgroup1-serveurnagios
       alias hostgroup1-serveurnagios
       address 127.0.0.1
       _WORKER hostgroup_hostgroup1-servers
       }

define service{
       use generic-service
       host_name hostgroup1-serveurnagios
       check_command check_ssh
       }

Voila un fichier d’hôte lambda, pour aller avec le fichier de hostgroup correspondant. J’ai mis un service lambda aussi, un check ssh.

Le second hostgroup sera comme suit :

define hostgroup{
hostgroup_name hostgroup2-servers
alias mes serveurs du hostgroup 2
members hostgroup2-serveurlambda,hostgroup2-worker
}

define hostextinfo{
hostgroup_name hostgroup2-servers
notes serveurs du hostgroup2
icon_image base/uneimage2.png
icon_image_alt hostgroup2 logo
vrml_image base/uneimage2.png
statusmap_image base/uneimage2.png
}

Voici le fichier hôte de la machine serveur lambda:

define host{
       use generic-host
       host_name hostgroup2-serveurlambda
       alias hostgroup2-serveurlambda
       address 192.168.1.200
       _WORKER hostgroup_hostgroup2-servers
       }

define service{
       use generic-service
       host_name hostgroup2-serveurlambda
       check_command check_ssh
       }

et le fichier de config du worker

define host{
       use generic-host
       host_name hostgroup2-worker
       alias hostgroup2-worker
       address 192.168.1.100
       _WORKER hostgroup_hostgroup2-servers
       }

define service{
       use generic-service
       host_name hostgroup2-worker
       check_command check_ssh
       }

Configuration du worker présent sur le serveur

Alez sur votre serveur éditer le fichier de config /opt/etc/mod_gearman_worker.conf et modifiez pour que la ligne:

hostgroups=

soit :

hostgroups=hostgroup1-servers

Démarrage de l’infrastructure

D’abord, on va démarrer Nagios,  gearmand, ensuite le worker mod-gearman.

/etc/init.d/nagios3 start

/etc/init.d/gearmand start

Et ensuite :

su nagios -c '/etc/init.d/mod_gearman_worker start'

Le worker doit être démarré par l’utilisateur Nagios pour fonctionner. Donc on l’éxécute avec la commande su et l’option -c .

Pour faciliter les choses, éditez /etc/rc.local et ajoutez les deux lignes :

/etc/init.d/gearmand start
su nagios -c '/etc/init.d/mod_gearman_worker start'

Note: AVANT la ligne “exit 0” (sinon ça ne fonctionnera pas)

Et comme ça à chaque reboot vos services seront exécutés comme il se doit.

Là tout devrait tourner proprement, et les checks pour votre serveur Nagios être exécutés, pas les autres.

Le worker du hostgroup2 et le serveur lambda du hostgroup2 qui n’existent d’ailleurs pas ne devraient pas rendre de critical car ils ne sont pas pris en charge.Il vous faudra ajouter un worker avec la ligne :

Hostgroups=hostgroup2-servers

On peut évidemment mettre plusieurs workers pour un seul hostgroup, il suffit de les mettre avec la même configuration.

Worker Raspberry Pi Mod. B

Ce que je trouve magique avec l’architecture distribuée Gearman , c’est qu’elle peut être utilisée avec des Raspberry… Si vous ne connaissez pas, vous devriez vraiment vous pencher sur ces machines merveilleuses !

Pour réaliser un worker sur un raspberry PI mod.B , rien de plus simple. Une fois l’installation du Raspbian faite sur votre carte SD, lancez votre raspberry, configurez le avec le raspi-config, et ensuite mettez le à jour . (apt-get update , apt-get upgrade)

Ensuite, on tape :

apt-get install mod-gearman-worker

Il va s’installer, et vous n’aurez qu’à le configurer basiquement pour qu’il soit pris en charge 

Exemple de config : /etc/mod-gearman-worker/worker.conf

server=ippublique:4730
key= Superpasswordquidéchire
hostgroup=hostgroup2-servers
encryption=yes
job_timeout=60
p1_file=/usr/share/mod-gearman/mod_gearman_p1.pl

Ouais… C’est tout!

Par défaut il va gérer le worker comme un petit chef, rien besoin de plus que ceci.

Le serveur, le password, le(s) hostgroup(s) , l’encryption, et par contre…

SURTOUT spécifier ce job_timeout=60 (60 ou ce qui conviendra à vos check, si vous avez par ex. un check qui met 2Mn à rendre son résultat, montez la valeur)

Si vous ne le faites pas et qu’un check « casse » en route, suite à un souci de connexion ou autre, votre worker attendra vita aeternam le résultat , et sera par conséquent… Planté ! ça ne vous ferait pas plaisir de faire 200Km en voiture pour débrancher et rebrancher un pc grand comme une carte de crédit, pas vrai ? (Comment ça, ça sent le vécu ? Je ne vous perm… oui c’est vrai.)

Donc , créez une machine virtuelle ou autre, sur une range inaccessible par votre serveur Nagios, avec l’ip spécifiée dans le fichier de config, (192.168.1.200) configurez la pour qu’elle réponde au ping et au ssh. Ensuite branchez un worker configuré comme expliqué sur le réseau ou elle se trouve… (en respectant la config d’ip selon le fichier de config dans nagios bien sûr)

Et comme par magie les deux machines seront prises en charge, de part leur configuration , le worker va contacter le job server, lui signaler sa présence, et là il enverra des tâches de check au worker qui les éxécutera et renverra le résultat au job server qui lui-même répondra à Nagios.

Surveillance des jobs

Je vous vois venir, vous pensez : « Mais comment est-ce que je vois ce qui se passe derrière tout ça ?

Et bien il y a une solution toute faite : gearman_top !

Il se trouve dans /opt/bin/

On peut ajouter son path dans la variable path en ajoutant :

PATH=$PATH:/opt/bin

Dans le fichier /root/.bashrc

Comme ça, vous pourrez le lancer comme n’importe quelle commande.

Lancez le , et admirez :

capture_115

Voici une petite illustration d’une infrastructure avec 8 hostgroups , et des workers.

J’ai mis un serveur qui en gère 6 à lui seul , et 2 workers qui en gèrent un chacun.

J’ai utilisé des noms de clients donc je les ai censurés pour cet exemple.

Performances

Mod-gearman améliore énormément les performances de Nagios !

Même si vous ne comptez ni utiliser le distributed monitoring, ni le load balancing, ou le fail over, le choix d’utiliser mod-gearman sur votre nagios améliorera très nettement (on parle là de la moitié de consommation processeur, mesdammes !) les performances du serveur Nagios.

Pour les cas testés, et pas uniquement par moi, les gains de performances sont de pratiquement 50%

Tests réalisés sur des serveurs qui ont une utilisation moyenne de 55-60% de processeur, le fait de juste passer sur Gearman fait chuter la consommation processeur vers les 25%.

Mod-gearman EST un must, chers amis !

Problèmes rencontrés

Voici une petite liste des problèmes que j’ai rencontré en démarrant seul sans aucune info sur mod-gearman , le jour ou j’ai décidé de me pencher sur cette technologie et d’apprendre a partir de rien à m’en servir.

Timeout sur workers :

Au début je n’avais pas défini de temps de timeout sur les workers… ça m’a vallu un déplacement aussi long qu’inutile pour aller reboot le raspberry pi, n’oubliez pas de définir le job_timeout= sur vos workers…

Compilation gearman :

En temps normal je me contente de faire apt-get install lorsque j’ai besoin de quelque chose.

Or quand j’ai commencé à me servir de mod-gearman, les packages n’étaient pas disponibles en repo pour l’apt-get install… donc j’ai du me mettre à le compiler moi-même , d’où la procédure ou on voit sa compilation alors que des versions (évidemment pas aussi à jour que celle expliquée ici, au jour ou j’écris ceci) sont disponible en repo…

Je n’ai certainement pas réalisé le sans fautes, probable que certains packages dans la phase d’installation des paquets ne sont pas essentiels, mais j’ai trié au maximum et je pense avoir fait ça proprement. Je suis preneur pour toute suggestion ou remarque 

Plantage gearmand au lancement :

Comme je le décris dans la procédure, il y a un plantage qui peut survenir au lancement de gearmand , qui se corrige par une modification du fichier dans /etc/init.d , ce problème m’a fait perdre pas loin d’une semaine, en ayant retourné le problème dans TOUS les sens , j’étais loin de suspecter qu’une option de verbosité, normalement présente pour aider a la résolution de problèmes de pantages, soit la cause du problème que je traquais… Comme quoi, il faut se méfier de tout.

Surveillance des workers

Je conclus cette rubrique par ce point, la surveillance de vos workers.

Si vous avez bien compris le fonctionnement des workers, on peut déceler une faille…

Si un worker n’est plus accessible, comment va-t-il répondre au job server pour dire qu’il n’est pas accessible ? On est d’accord c’est impossible. Alors, comment déterminer si un worker est OOR (out of range) ou non ?

J’ai pondu un petit script utilisant gearman_top qui permet ça. Le voici :

Le script:

#!/bin/bash

basevalue=`/opt/bin/gearman_top -b | grep "hostgroup_$1-servers"`

value1=`echo $basevalue | cut -d "|" -f3 | tr -d ' '`

value2=`echo $basevalue | cut -d "|" -f4 | tr -d ' '`

value3=`echo $basevalue | cut -d "|" -f2 | tr -d ' '`

critical=$2

threshold=$(($2/2))

if [[ $value1 -gt $critical ]]

then    if [[ $value2 -gt $threshold ]]

       then

               echo " Accumulation de Jobs sur le worker $1, attention!"

               echo " $value1 jobs en attente , $value2 jobs en cours "

               retval=1;

               else

               echo " Le worker $1 ne prend plus de Jobs, Critical! "

               echo " $value1 jobs en attente!"

               retval=2;

       fi

else

echo "Tout va bien. $value1 Wait $value2 run $value3 avail"

echo "$value1 jobs en attente, $value2 jobs en cours et $value3 workers dispo."

retval=0;

fi

exit $retval;

le fichier de definition de commande:

define command{

       command_name    check_workers

       command_line    /usr/lib/nagios/plugins/check_workers.sh $ARG1$ $ARG2$

       }

Et un exemple utilisé sur mon serveur :

define service{

       use                     generic-service

       host_name               ALTAIR-SRV-NAGIOS01

       service_description     Worker Altair

       check_command           check_workers!altair!15

       }

Ma société veut que les jobs en attente, en exécution et les workers prêts à traiter pour le hostgroup altair me soit rendus, et dans le script , j’éxécute gearman_top avec l’option –b qui ne rend qu’une réponse, et utilisable en script, je trie avec un grep pour obtenir le nom qui m’intéresse, et ensuite je décortique les chiffres, et définis selon le nombre de jobs waiting que je veux d’avoir une alerte s’ils atteignent ce seuil, avec une petite sécurité toutefois, s’il y a une accumulation de checks pour une raison , peu importe laquelle, mais que mon worker travaille, je ne veux pas recevoir d’alerte. Je le laisse bosser…

Catégories
Developpement Open-source Planet-libre

L’écosystème autour de Glances

Le nombre de projets gravitant autour de Glances étant devenu assez important, j’ai dessiné le schéma suivant (à partir du service en ligne Gliffy pour les plus curieux d’entre vous):

L'écosystème Glances
L’écosystème Glances

Le cœur de Glances (source disponible sur le Github officiel) est représenté en vert.

On trouve ensuite en bleu les projets composant son écosystème:

  • Glances plugin (ou CheckGlances) est un plugin pouvant de récupérer les statistiques d’un serveur Glances à partir de Nagios, Centreon ou de Shinken (ou de tout autre système compatible avec les plugins Nagios). Voir ce billet pour un exemple de mise en oeuvre.
CheckGlances
  • MetaGlances est une interface Web qui permet de centraliser les statistiques de plusieurs serveurs Glances. L’interface est « responsive » et donc compatible avec les écrans des PC, des tablettes et des smartphones (plus d’informations sur ce billet)
MetaGlances

 

  • PHPGlances est une API PHP pour s’interfacer simplement avec un serveur Glances. C’est la brique utilisé par MetaGlances. Pour un exemple de mise en oeuvre, vous pouvez lire ce billet sur le blog RootsLabs
Android Glances

 

Catégories
Developpement Open-source Planet-libre Systeme

Présentation des nouveautés de Glances 1.7

De retour de congés avec dans ma besace une nouvelle version de Glances qui sera la dernière version majeure de la série 1.x. La prochaine version sera donc une 2.x avec notamment un gros travail initial de refactoring/découpage du code en modules car le script initial atteint une taille critique (plus de 4400 lignes) qui commence à le rendre difficilement évolutif.

Mais revenons donc à nos moutons pour parler de cette version de Glances 1.7:

screenshot Glances 1.7

Un peu d’histoire

Pour ceux d’entre vous qui découvrent Glances dans ce billet, c’est un projet que j’ai lancé maintenant il y a 2 ans pour palier à un manque dans les outils de supervision système. En effet, j’utilisais tout un tas de logiciels (netstat, top, ntop, ifstat, dstat…) pour investiguer les éventuels problèmes de performance sur un système d’exploitation. Mais aucun ne permettait une visualisation simple (via un terminal par une connexion SSH) et rapide (sur un seul écran) des statistiques nécessaires. Glances était née.

Cette version apporte, en plus de son lot de corrections de bugs, d’améliorations des performances et de la documentation de nouvelles fonctionnalité que nous allons détailler ensemble

Les « Monitored Processes List »

L’objectif qui se cache derrière cette nouvelle fonction est de pouvoir, en un clin d’oeil, voir l’état d’un ensemble de processus regroupés ensemble sous une même thématique.

Par exemple, sur un machine hébergeant un serveur Web dynamique, la supervision des processus « importants » peut se découper de la manière suivante:

  • Serveur Nginx: processus NGinx
  • Serveur PHP: processus PHP-FPM
  • Serveur de caching des pages: processus Varnish
  • Serveur de base de données: processus MySQL
  • Serveur de caching des objets: processus Memcached

On a donc 5 objets à superviser. Dans Glances, la définition de ces objets est faite via le fichier de configuration glances.conf. Chaque objet est défini par:

  • description: description des processus (au maximum 16 caractères, exemple: Serveur Web Nginx)
  • regex: expression régulière permettant de regrouper les processus dans l’objet (exemple: .*nginx.*)

et optionnellement par:

  • command: chemin complet vers un script qui sera executé par Glances à chaque rafraichissement (donc toutes les 3 secondes par défaut) et qui devra retourner une chaine de caractère d’une seule et unique ligne contenant des informations utiles pour cet objet. Attention à ne pas utiliser un script trop consommateur de ressources ou bien d’augmenter le temps de rafraichissement (option -t <secondes>)
  • countmin: nombre minimal de processus attendus. Un message de warning sera affiché si le nombre de processus passe en dessous de cette valeur.
  • countmax: nombre maximal de processus attendus. Un message de warning sera affiché si le nombre de processus passe en dessus de cette valeur.

Note: par défaut, Glances par sur le principe ou le groupe ne contient qu’un seul processus (donc countmin = countmax = 1)

Ainsi, la configuration de l’objet n°1 (on peut définir jusqu’à 10 objets) correspondant au serveur Web Nginx est donc la suivante:

[monitor]
list_1_description=Serveur Web Nginx
list_1_regex=.*nginx.*
list_1_command=nginx -v
list_1_countmin=1
list_1_countmax=4

Dans Glances, l’affichage des objets se fait de la manière suivante:

monitored

La couleur détermine l’état de l’objet. Si le nombre de processus:

  • est compris entre countmin et countmax alors Glances affichera l’objet en vert (état OK)
  • est différent de 0 mais non compris entre countmin et countmax alors Glances affichera l’objet en orange (état WARNING)
  • est égal à 0 alors Glances affichera l’objet en rouge (état CRITICAL)

Comme pour toutes les autres statistiques importantes de Glances, le changement des états est logué.

En mode client/serveur la liste des items est défini au niveau serveur. Une nouvelle entrée dans l’API permet au client de récupérer la liste sur le serveur.

Supervision de la température des disques

Sur certain système, notamment les NAS, la température des disques est un critére important à surveiller. En partant de ce postulat, MendelGusmao a développé un module optionnel (activable en passant l’option -y au lancement de Glances) permettant d’aller récupérer la température des disques sur le daemon HDDTemp qui doit être lancé sur votre machine (voir ici les instructions d’installation de HDDTemp sur Debian/Ubuntu).

Sur ma machine (qui ne comporte qu’un seul disque dur), j’obtiens l’affichage suivant:

hddtemp

Il est bien sûr possible de définir les seuils d’alertes dans la section [hddtemperature] du fichier de configuration de Glances. Les valeurs par défaut sont: CAREFUL=45 / WARNING = 52 / CRITICAL = 60 (en ° celcus).

Information sur l’état de charge de la batterie

J’ai reçu plusieurs demandes d’utilisateur de Glances souhaitant superviser la capacité de la batterie (notamment dans le cas d’utilisation de nano PC autonomes). Premier problème, PsUtil ne remonte pas ce genre de statistiques (du moins dans la version actuelle 1.0). Après une rapide et non exhaustive recherche sur le net d’une bibliothéque Python permettant d’obtenir simplement les informations disponibles sur les systèmes Linux j’ai du me résoudre à coder moi même quelque chose. C’est donc ainsi que Batinfo est apparu il y a quelques semaines.

L’intégration de la librairie Batinfo a été ensuite une formalité et Glances propose donc, si une ou plusieurs batteries sont détectés, l’affichage du pourcentage de capacité restante au milieu du footer:

battery

Limitation: cette statistique est uniquement disponible sur les systèmes Linux.

Une option pour un Glances « low CPU »

Le traitement de la liste comprenant les processus est un des facteur principaux de la consommation CPU de Glances. Sur certain système (notamment les nanos PC comme les Raspberry Pi), il est conseillé de réduire le taux de rafraichissement des statistiques pour faire baisser cette consommation CPU. Cependant, si vous avez besoin d’un taux de rafraichissement important sans avoir besoin du détail des processus alors l’option -r codé par J.Renner est faite pour vous. En lançant Glances avec l’option -r, vous allez désactiver tout les traitements des processus (liste dynamique, monitored process list…) et ainsi disposer d’un Glances faiblement consommateur de CPU.

Sur ma machine de développement, l’utilisation de cette option fait passer la consommation CPU de 2.9% à 0.3%.

Détail de la CPU au lancement de Glances

Une version précédante de Glances voyait apparaître une option (activable en appuyant sur la touche ‘1’ dans Glances) permettatn d’afficher le détail de la CPU par coeur et non plus globalement. Une nouvelle option sur la ligne de commande (-1) permet de lancer par défaut ce mode d’affichage.

per-cpu

IPv6

Enfin un vrai support IPv6 pour le mode client serveur de Glances.

A tester simplement et localement avec:

glances -s -B ::0

pour lancer le serveur en mode IPv6 avec un bind sur toutes les interfaces.

Puis ensuite on lance le client sur le localhost IPv6:

glances -c ::1

Et puis…

Quelques autre petites nouveautés:

  • Platform/architecture is more specific now
  • Add support for local conf file
  • Add a uninstall script
  • Add getNetTimeSinceLastUpdate() getDiskTimeSinceLastUpdate() and getProcessDiskTimeSinceLastUpdate() in the API
  • Add more translation: Italien, Chinese

Conclusion

Tout d’abord un grand merci aux principaux contributeurs de cette nouvelle version:

Ensuite, je compte sur vous pour tester cette nouvelle version qui est dès à présent disponible sous Pypi (les packages Debian, BSD, Windows et Mac ne devrait pas trop tarder).

Installation et mise à jour de Glances 1.7

Si vous avez installé Glances via Pypi (ce que je conseille), une mise à jour peut se faire simplement via la ligne de commande:

sudo pip install --upgrade Glances

Pour une installation toute fraîche (pour les nouveaux venus ayant les droits root):

sudo pip install Glances

ou la commande équivalente pour une installation locale (pour les nouveaux venus sans les droits root):

pip install --user Glances

Si vous préférerez utiliser les packages Debian/Ubuntu, Windows et Mac OS, il va falloir attendre un peu que mes « packagers » attitrés bossent un peu.

J’attend vos retours sur les commentaires suivants ou vos retour de bug/demande d’amélioration sur le site du dépôt officiel.