Ce guide a été réalisé en Juillet 2008 par un stagiaire CS.

Le but de ce document est de décrire comment installer les 6 premiers modules de Vigilo. C'est à dire poser les différentes commandes qui m'ont amené à l'installer et à le faire fonctionner, au moins avec une configuration basique.

L'installation est à l'origine prévue pour Debian, donc quelques modifications sont à prévoir pour Mandriva. C'est elles qui seront décrites ici.

On se base sur la configuration d'exemple de Nagios : /etc/nagios/conf.d/sample.cfg

• Dossiers pour les parties web : /usr/share/vigilo-xxx
• Dossiers pour les parties configuration : /etc/vigilo-xxx
• Dossier pour les librairies : /usr/lib

De manière général j'utiliserai presque toujours un nom du genre “vigilo-nomdumodule” pour les répertoires, ceci afin de les identifier plus facilement.

Nagios v3.0.1 marche et sera utilisé dans ce tuto, mais il n'est pas officiellement validé par CS.

# urpmi nagios

Mot de passe nagios : # vi /etc/nagios/passwd.plaintext

Apache v2.2.8 (choix 1 = stable) : # urpmi apache

RRDTool v1.2.27 : # urpmi rrdtool

Python v2.5 : # urpmi python

Port utilisé : 50001

• Décompresser l'archive

# tar -zxvf StoreMe-xx.tar.gz
# cd StoreMe-xx

• Répertoire web :

# mkdir /usr/share/vigilo-storeme
# mv StoreMe.py /usr/share/vigilo-storeme

• Script d'initialisation : storeme.sh
  • Répertoire du script de lancement :

# mv storeme.sh /etc/init.d/
# vi /etc/init.d/storeme.sh

• Éditer : variable NAME, mettre NAME=vigilo-storeme, variable PARMS, mettre PARMS=”/usr/share/vigilo-storeme/StoreMe.py”

• Répertoire des fichiers de configuration :

# mv storeme /etc/default
# mkdir /etc/vigilo-storeme
# mv /etc/vigilo-storeme/storeme.conf.py.dist /etc/vigilo-storeme/vigilo-storeme.conf.py

• Faire les réglages

• Répertoire du fichier pid : # mkdir /var/run/vigilo-storeme/. Le USER pour storeme est metro, donc :

# useradd metro
# chown -R metro:metro /var/run/vigilo-storeme/

• Modifications du script d'init pour Mandriva (dans le “case” du script d'init)

# vi /etc/init.d/storeme.sh
 
case "$1" in
        start)
                echo -n "Starting $DESC: "
                #start-stop-daemon --start --quiet --background --exec "$DAEMON" --pidfile "$PID_FILE" --chuid "$USER" --user "$USER" -- $PARMS
                #daemon --user "$USER" $DAEMON $PARMS
                nohup su -c "$DAEMON $PARMS" $USER &
                echo "$NAME."
        ;;
        stop)
                echo -n "Stopping $DESC: "
                #start-stop-daemon --stop --oknodo --quiet --exec "$DAEMON" --pidfile "$PID_FILE" --user "$USER"
                killproc -p "$PID_FILE" "$DAEMON"
                echo "$NAME."
        ;;
        restart|force-reload)
                #
                #       If the "reload" option is implemented, move the "force-reload"
                #       option to the "reload" entry above. If not, "force-reload" is
                #       just the same as "restart".
                #
                echo -n "Restarting $DESC: "
                kill -p "$PID_FILE" "$DAEMON"
                sleep 1
                daemon --pidfile "$PID_FILE" --user "$USER" $DAEMON $PARMS
                echo "$NAME."
        ;;
        *)
                N=/etc/init.d/$NAME
                echo "Usage: $N {start|stop|restart|force-reload}" >&2
                exit 1
        ;;
esac

Il y a surement une meilleure façon de faire, mais je n'ai pas trouvé. Le start/stop marche mais pas le restart.

• Lancement : # /etc/init.d/storeme.sh start

• Installation de Perl : # urpmi perl

• Décompresser l'archive

# tar -zxvf Perf2Store-xx.tar.gz
# cd Perf2Store-xx

• Activation des données de perf dans Nagios

# mv perf2store /usr/lib/nagios/plugins
# vi /etc/nagios/conf.d/sample.cfg

• Copier coller la commande de perf (cf le README). Attention de bien commenter la commande d'exemple : SAMPLE PERFORMANCE DATA COMMANDS. # mv perf2store.conf.pm /etc/vigilo-perf2store/

Ce fichier est à renommer selon le hostname de la machine. Donc ici en perf-localhost.pm

• Activer la gestion des données de performance : # vi /etc/nagios/nagios.cfg

Le fichier command.cfg contient les commandes Perf2Store avec le chemin (option -p) où se trouve les fichiers perf-host.pm.

C'est donc dans ce répertoire qu'il faut mettre les *.pm

Par rapport au sample.cfg de Nagios, on graphera donc : Load ; Users ; Web

• Apache mod python (v3.3.1) : # urpmi apache-mod_python

• Python RRDTool (v1.2.27) : # urpmi python-rrdtool

• Décompresser l'archive :

# tar -zxvf RRDGraph-xx.tar.gz
# cd RRDGraph
# mkdir /usr/share/vigilo-rrdgraph
# mv conf.py rrdgraph.py RRDGraph.py /usr/share/vigilo-rrdgraph

• Les droits sont les suivants :

# ll /etc/vigilo-rrdgraph/
total 12
-rwxr-xr-x 1 apache apache  115 2008-04-21 16:00 general.py*
-rwxr-xr-x 1 apache apache 2643 2008-01-24 17:12 graphs.py*
-rwxr-xr-x 1 apache apache 2250 2008-01-24 17:12 templates.py*

• Même user que pour storeme ici : # chown -R metro:apache /usr/share/vigilo-rrdgraph. Et le répertoire qui va contenir les rrds : # chown -R metro:apache /var/lib/rrds/.

• Configuration Apache : # mv rrdgraph.apache.conf /etc/httpd/conf.d/. Et mettre les bons droits.

• Le fichier ressemblera à ceci :

<IfModule mod_python.c>
 
    Alias /rrdgraph/cache/ /var/cache/vigilo-rrdgraph/
    Alias /rrdgraph /usr/share/vigilo-rrdgraph
 
    <Directory /usr/share/vigilo-rrdgraph>
        AddHandler mod_python .py
        Order allow,deny
        Allow from all
        PythonHandler mod_python.publisher
        PythonDebug On
        DirectoryIndex rrdgraph.py
    </Directory>
 
    <Directory /var/cache/vigilo-rrdgraph>
        Order allow,deny
        Allow from all
    </Directory>
 
</IfModule>

C'est dans /var/cache/vigilo-rrdgraph que sont générés les *.png de rrdtool Il faut donc qu'apache puisse les lire pour les afficher.

• Page web rrdgraph : http://localhost/rrdgraph/ Mais en général on passe par le SupNavigator.

NOTE : Il faut que storeme soit lancé pour ouvrir la page rrdgraph.

• Télécharger qooxdoo-xx-sdk.tar.gz, décompresser les archives :

# tar -zxvf SupNavigator-xx.tar.gz
# tar -zxvf qooxdoo-xx-sdk.tar.gz

• Déplacer qooxdoo : # mv qooxdoo SupNavigator-xx/

• Installer les dépendances :

# urpmi make
# urpmi gettext
# urpmi apache-mod_proxy

• Décompilation :

# cd SupNavigator-xx/
# make build

• Répertoire web :

# mkdir /usr/share/vigilo-supnavigator
# mv build/* /usr/share/vigilo-supnavigator
# chown -R apache:apache /usr/share/vigilo-supnavigator
# chmod 755 /usr/share/vigilo-supnavigator/
# mv SupNavigator.py /usr/share/vigilo-supnavigator
# chown -R apache:apache /usr/share/vigilo-supnavigator

• Répertoire de la configuration : # mv navconf.py.dist /etc/vigilo-supnavigator/navconf.py

• Configuration Apache : # mv apache.d/supnavigator.conf /etc/httpd/conf.d/

Qui ressemblera dans notre exemple à :

<IfModule mod_python.c>
 
Alias /supnavigator /usr/share/vigilo-supnavigator
 
<Directory /usr/share/vigilo-supnavigator>
        AddHandler mod_python .py
        PythonHandler mod_python.publisher
        PythonDebug On
 
    Options FollowSymLinks
 
    AllowOverride AuthConfig
    Order Allow,Deny
    Allow From All
</Directory>
 
</IfModule>

• le reverse-proxy

Un reverse-proxy est un serveur proxy-cache “monté à l'envers”, permettant non pas aux utilisateurs d'accéder au réseau Internet, mais aux utilisateurs d'Internet d'accéder indirectement à certains serveurs internes.

Le reverse-proxy sert ainsi de relais pour les utilisateurs d'internet souhaitant accéder à un site web interne en lui transmettant indirectement les requêtes. Grâce au reverse-proxy, le serveur web est protégé des attaques directes de l'extérieur, ce qui renforce la sécurité du réseau interne. D'autre part, la fonction de cache du reverse-proxy peut permettre de soulager la charge du serveur pour lequel il est prévu.

Enfin, grâce à des algorithmes perfectionnés, le reverse-proxy peut servir à répartir la charge en redirigeant les requêtes vers différents serveurs équivalents; on parle alors de répartition de charge (en anglais load balancing).

Dans le cas Vigilo, pourquoi le RP ?

Dans le cadre d'un supervision répartie entre plusieurs serveurs Nagios, on va utiliser un RP entre l'IHM et les serveurs Nagios. Ce dernier jouera le rôle de relais. C'est lui qui va demander aux différents serveurs Nagios les données qu'on veut récupérer pour ensuite les afficher sur une IHM unique.

Dans notre installation nous n'avons qu'un serveur qui contient tout : IHM, Nagios, Graphes, etc. Il faut donc quand on interroge ce serveur, qu'il se renvoi les données à lui même.

• Fichier du reverse proxy : # mv apache.d/supnavigator-proxy.conf /etc/httpd/conf.d/

• On le fera ressembler à ceci, sur un Vigilo mono-serveur :

<Location /localhost/>
        Order Deny,Allow
        Allow from all
        ProxyPass http://localhost/
        ProxyPassReverse http://localhost/
</Location>

• Vérifier le path root (celui où se trouve navconf.py) :

# vi /usr/share/vigilo-supnavigator/SupNavigator.py
INSTALL_ROOT = '/etc/vigilo-supnavigator'

• Changer les paths pour les pages Nagios (différence entre Debian et Mandriva) : # vi /usr/share/vigilo-supnavigator/SupNavigator.py

Il faut remplacer les chemins dans ces 2 définitions : def supPage ET def servicePage, soit : /%s/cgi-bin/nagios2/status.cgi par /%s/nagios/cgi-bin/status.cgi. Ceci afin que SupNav puisse ouvrir les pages Nagios.

• Configuration des CGI Nagios : il faut aussi que SupNav puisse voir les services.

# vi /etc/nagios/cgi.cfg

Modifier pour avoir ces valeurs :

default_user_name=*
authorized_for_all_services=*
authorized_for_all_hosts=*

• Page web SupNavigator : http://localhost/supnavigator/

• Décompresser l'archive :

# tar -zxvf DashboardInjector-xx.tar.gz
# cd DashboardInjector/

• Installer les dépendances :

# urpmi perl-Sys-Hostname-Long
# urpmi socat

• Répertoire du fichier de configuration :

# mkdir /etc/vigilo-dashboardinjector/
# mv dashboardinjector /etc/vigilo-dashboardinjector/
# chmod 755 /etc/vigilo-dashboardinjector/

• Editer : # vi /etc/vigilo-dashboardinjector/dashboardinjector

• Le début ressemblera à ceci :

PID_FILE=/var/run/vigilo-dashboardinjector/vigilo-dashboardinjector.pid
QUEUE_MAX_SZ=1024
THREAD_COUNT=1
TCP_PORT=50003
UDP_PORT=50003
DB_NAME="dbi:mysql:dashboard:127.0.0.1:3306"
DB_USER="vigilo"
DB_PASS="password"

• Ensuite sur Mandriva, il faut faire quelques modifications :
  • CAS 1 : # vi /etc/init.d/dashboardinjector
    • Remplacer : NAME=vigilo-dashboardinjector par : NAME=dashboardinjector
    • Et remplacer :

if [ -f /etc/default/$NAME ] ; then
        . /etc/default/$NAME
fi

• par

if [ -f /etc/vigilo-dashboardinjector/$NAME ] ; then
        . /etc/vigilo-dashboardinjector/$NAME
fi

• OU CAS 2 :
  • Créer un lien symbolique : # ln -s /etc/vigilo-dashboardinjector/dashboardinjector /etc/default/vigilo-dashboardinjector

• Vérification :

# ll /etc/default/
total 8
-rw-r--r-- 1 csadm csadm 696 2008-06-30 11:08 storeme
lrwxrwxrwx 1 root  root   47 2008-07-02 15:57 vigilo-dashboardinjector -> /etc/vigilo-dashboardinjector/dashboardinjector*

• Les librairies perl :

# mkdir /usr/lib/vigilo-dashboardinjector/
# mv DashboardInjector.pl /usr/lib/vigilo-dashboardinjector/
# mv PerlDaemon.pm /usr/lib/vigilo-dashboardinjector/
# chown -R netadmin:apache /usr/lib/vigilo-dashboardinjector

• Le script de démarrage : dashboardinjector.sh

• Répertoire du script de lancement :

# mv dashboardinjector.sh /etc/init.d/dashboardinjector

• Répertoire du fichier pid :

# mkdir /var/run/vigilo-dashboardinjector/

Le USER pour dashboardinjector est netadmin, donc :

# useradd netadmin
# chown -R netadmin:netadmin /var/run/vigilo-dashboardinjector

• Lancement du script d'init :

# /etc/init.d/dashboardinjector.sh start

• Le script est prévu pour Debian, il faut le modifier pour Mandriva (juste après la définition des variables) :

if [ -f /var/run/vigilo-dashboardinjector/vigilo-dashboardinjector.pid ] ; then
        DASH_PID=$(cat /var/run/vigilo-dashboardinjector/vigilo-dashboardinjector.pid)
fi
 
if [ -f /etc/default/$NAME ] ; then
        . /etc/default/$NAME
fi
 
set -e
 
export PID_FILE QUEUE_MAX_SZ THREAD_COUNT TCP_PORT UDP_PORT DB_NAME DB_USER DB_PASS
 
test -x $DAEMON || exit 0
 
set -e
 
case "$1" in
        start)
                echo -n "Starting $DESC: "
                #start-stop-daemon --start --quiet --exec "$DAEMON" --pidfile "$PID_FILE" --chuid "$USER" --user "$USER" -- $
PARMS
                nohup su -c "$DAEMON $PARMS" $USER &
                echo "$NAME."
        ;;
        stop)
                echo -n "Stopping $DESC: "
                #start-stop-daemon --stop --oknodo --quiet --exec "$DAEMON" --pidfile "$PID_FILE" --user "$USER"
                kill "$DASH_PID"
                echo "$NAME."
        ;;

Ce n'est pas parfait et le restart ne marche pas. Mais le start/stop marche.

• Décompresser l'archive :

# tar -zxvf Dashboard-xx.tar.gz
# cd Dashboard/

• Configuration Apache : # mv dashboard.httpd.conf /etc/httpd/conf.d/

Editer ce fichier selon le répertoire web voulu (ici /usr/share/vigilo-dashboard/)

• Répertoire web :

# mkdir /usr/share/vigilo-dashboard/
# mv share/* /usr/share/vigilo-dashboard/

• Même USER que pour DashboardInjector : # chown -R netadmin:apache /usr/share/vigilo-dashboard

• Répertoire du fichier de configuration :

# mkdir /etc/vigilo-dashboard/
# mv config/dashboard.cfg /etc/vigilo-dashboard/

• Editer et bien vérifier les chemins par rapport à ce tuto pour qu'ils correspondent : # vi /etc/vigilo-dashboard/dashboard.cfg, soit les parties : ”[General]”, ”[NEB]”, ”[Log]”, ”[Web]”.

• NOTE : Par exemple si les chemins Web ne sont pas bons, cela peut ne remonter aucune erreur. On obtient juste une page blanche !

• Répertoire librairie :

# mkdir /usr/lib/cgi-bin/dashboard
# mv cgi-bin/alarms-form.cgi
# chown -R netadmin:apache /usr/lib/cgi-bin/dashboard/

• Il faut installer des dépendances :

# urpmi perl-CGI
# urpmi perl-Date-Calc

• liblogfile-rotate-perl

Un paquet pour Logfile/Rotate.pm est introuvable sur Mandriva : liblogfile-rotate-perl qui fournit des méthodes pour renommer et sauvegarder plusieurs versions de vos fichiers journaux. Il n'existe que sur Debian. Il faut donc l'installer depuis les sources.

• La version Debianisée est téléchargeable ici : http://packages.debian.org/etch/liblogfile-rotate-perl (Fichier liblogfile-rotate-perl_1.04.orig.tar.gz)
• L'original ici : http://search.cpan.org/~paulg/Logfile-Rotate-1.04/Rotate.pm
• Décompression

# tar -zxvf liblogfile-rotate-perl_1.04.orig.tar.gz
# cd liblogfile-rotate-perl_1.04.orig

• Si on prend les sources Debian il faut aussi : # urpmi perl-ExtUtils-MakeMaker-Coverage

• Lancer le bin installé :

# testcover
Checking if your kit is complete...
Looks good
Writing Makefile for Logfile::Rotate
cover -delete
Deleting database /home/csadm/Téléchargement/Logfile-Rotate-1.04/cover_db
cp Rotate.pm blib/lib/Logfile/Rotate.pm
HARNESS_PERL_SWITCHES='-MDevel::Cover=-coverage,branch,-coverage,condition,-coverage,pod,-coverage,statement,-coverage,subroutine' PERL_DL_NONLAZY=1 /usr/bin/perl5.10.0 "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib','blib/arch')" t/*.t
t/01rotate..........ok
t/02signal..........Signal is a deprecated argument, see Pre/Post at t/02signal.t line 25
t/02signal..........ok
t/03compress........warning: could not load Compress::Zlib, skipping compression at t/03compress.t line 31
t/03compress........ok
t/04dir.............ok
t/05flock...........ok
t/06persist.........ok
t/07pre.............ok
t/08post............ok
t/09lib_compress....ok
All tests successful.
Files=9, Tests=115, 15 wallclock secs (14.25 cusr +  0.35 csys = 14.60 CPU)
cover
Reading database from /home/csadm/Téléchargement/Logfile-Rotate-1.04/cover_db
 
 
------------------------------------------ ------ ------ ------ ------ ------
File                                         stmt   bran   cond    sub  total
------------------------------------------ ------ ------ ------ ------ ------
blib/lib/Logfile/Rotate.pm                   87.1   57.6   81.0   93.3   76.2
Total                                        87.1   57.6   81.0   93.3   76.2
------------------------------------------ ------ ------ ------ ------ ------
 
 
Writing HTML output to /home/csadm/Téléchargement/Logfile-Rotate-1.04/cover_db/coverage.html ...
done.

• Installation :

# make
# make install

• Les tables SQL
  • Install de MySQL : # urpmi mysql
  • Création de l'utilisateur : > CREATE USER 'vigilo'@'localhost' IDENTIFIED BY '**';
  • Création de la base > CREATE DATABASE `dashboard`;
  • Don de tout les droits sur cette base à vigilo : > GRANT ALL PRIVILEGES ON `dashboard` . * TO 'vigilo'@'localhost';
  • Importation des tables : # mysql -u vigilo -pfucknt dashboard < dashboard.sql

• Déplacer le fichier perl :

# mv perl/TrpHelpers.pm /usr/lib/cgi-bin/dashboard/
# chown apache.apache /usr/lib/cgi-bin/dashboard/TrpHelpers.pm

• Droits sur les logs : # chown -R apache:apache /var/log/dashboard/
• Injection des données de Nagios

Pour que DashboardInjector puisse remonter les alertes sur le Dashboard il faut qu'il reçoive les données de Nagios. Pour celà on passe par la création d'une commande Nagios qui enverra les données au DashboardInjector.

A partir d'ici tout se fait dans le fichier /etc/nagios/conf.d/sample.cfg

• Les commandes - Elles sont à AJOUTER

define command{
        command_name    host-notify-dashinjector
        command_line    /usr/bin/printf "%b" "$HOSTNAME$|Host|$NOTIFICATIONTYPE$|$OUTPUT$|$HOSTSTATE$|" | socat -u - UDP4
:localhost:50003
}
define command{
        command_name    service-notify-dashinjector
        command_line    /usr/bin/printf "%b" "$HOSTNAME$|$SERVICEDESC$|$NOTIFICATIONTYPE$|$SERVICEOUTPUT$|$HOSTSTATE$|$SERVICESTATE$" | socat -u - UDP4:localhost:50003
}

• Syntaxe Hôte :

$HOSTNAME$|Host|$NOTIFICATIONTYPE$|$OUTPUT$|$HOSTSTATE$|
Nom_Hôte|Host|Notification_Etat|Sortie_Hôte|Etat_Hôte|Rien..

• Syntaxe Service :

$HOSTNAME$|$SERVICEDESC$|$NOTIFICATIONTYPE$|$SERVICEOUTPUT$|$HOSTSTATE$|$SERVI
CESTATE$
Nom_Hôte|Nom_Service|Notification_Etat|Sortie_du_Service|Etat_Hôte|Etat_Service

• Le contact - Il est à AJOUTER

define contact{
        contact_name                    dashinj
        alias                           DashboardInjector
        service_notification_period     24x7
        host_notification_period        24x7
        service_notification_options    w,u,c,r
        host_notification_options       d,u,r
        service_notification_commands   service-notify-dashinjector
        host_notification_commands      host-notify-dashinjector
        email                           root@localhost
}

• Le contactgroup - Il est à AJOUTER

define contactgroup{
        contactgroup_name       bots
        alias                   Nagios Notification robots
        members                 dashinj
}

Dans cet exemple, tout les autres contacts et groupes de contacts ont été commentés (#).

• Les Hosts et Services - Ils sont à MODIFIER

Les valeurs ont été choisie de manière à remonter les notifications pour voir rapidement les résultats sur le Dashboard. La détection des oscillations (flap) est désactivé, car si on veut tester les états changeront souvent. Et de nombreux changements désactivent les notifications temporairement, ce que nous ne voulons pas pour le Dahsboard.

• Le template des hôtes

define host{
        name                            generic-host
        notifications_enabled           1
        event_handler_enabled           1
        flap_detection_enabled          0
        failure_prediction_enabled      1
        process_perf_data               1
        retain_status_information       1
        retain_nonstatus_information    1
        notification_period             24x7
        register                        0
        }

• L'hôte

define host{
        name                            linux-server
        use                             generic-host
        check_period                    24x7
        check_interval                  2
        retry_interval                  1
        max_check_attempts              1
        check_command                   check-host-alive
	#notification_period             workhours (commenté, on veut du 24x7)
        notification_interval           120
        notification_options            d,u,r
        contact_groups                  bots
        register                        0
        }

IMPORTANT : le groupe de contact est “bots” et les notifications sont actives ! contact_groups = bots et notifications_enabled = 1

• Le template des services génériques

define service{
        name                            generic-service
        active_checks_enabled           1
        passive_checks_enabled          1
        parallelize_check               1
        obsess_over_service             1
        check_freshness                 0
        notifications_enabled           1
        event_handler_enabled           1
        flap_detection_enabled          0
        failure_prediction_enabled      1
        process_perf_data               1
        retain_status_information       1
        retain_nonstatus_information    1
        is_volatile                     0
        check_period                    24x7
        max_check_attempts              1
        normal_check_interval           1
        retry_check_interval            1
        contact_groups                  bots
        notification_options            w,u,c,r
        notification_interval           60
        notification_period             24x7
        register                        0
        }

• Le template des services locaux

define service{
        name                            local-service
        use                             generic-service
        max_check_attempts              1
        normal_check_interval           1
        retry_check_interval            1
        register                        0
        }

IMPORTANT : le groupe de contact est bots et les notifications sont actives ! contact_groups = bots et notifications_enabled = 1

• Si on veut générer un problème sur la charge CPU :

On peut remplacer la commande check_local_load originale par : check_local_load!0.40,0.35,0.30!0.80,0.75,0.70 Afin d'amener facilement ce service comme étant problématique. Ensuite un ping -f localhost devrait amener la charge en critical..

• Modifier le fichier de configuration de MySQL : # vi /etc/my.cnf et commenter : skip-networking

Nagios n'a pas besoin d'être lancé ici. On injecte de fausses alertes directement sans passer par lui pour voir si elles apparaissent bien dans le Dashboard.

On test directement en ligne de commande :

• On passe en problème critique, la ligne doit devenir rouge

# /usr/bin/printf "%b" "localhost|SSH|PROBLEM|CRITICAL: test|UP|CRITICAL" | socat -u - UDP4:localhost:50003

• En recovery OK, elle devient verte (sauf tout à gauche)

# /usr/bin/printf "%b" "localhost|SSH|RECOVERY|OK: test|UP|OK" | socat -u - UDP4:localhost:50003
<code>
 
  * En problème warning, elle devient orange
<code bash>
# /usr/bin/printf "%b" "localhost|SSH|PROBLEM|WARNING: test|UP|WARNING" | socat -u - UDP4:localhost:50003

• Puis de nouveau en vert

# /usr/bin/printf "%b" "localhost|SSH|RECOVERY|OK: test|UP|OK" | socat -u - UDP4:localhost:50003

• Note 1 :

Il semble y avoir un problème qui ne se manifeste pas toujours. En critique, il considère que nous sommes en warning, ça devrait être en rouge et non orange. De plus on constate que l'état le plus grave (en cliquant sur le triangle) est warning et non critical. Ou alors quand le service est OK il doit afficher le message de l'état le plus grave dans lequel il a été. Or ce n'est pas le cas.

• Note 2 (en réponse à la 1) :

Dans le Dashboard, le message de sortie persistant est le dernier état non OK dans lequel l'objet à été. Si il a été CRITICAL puis est passé directement OK après, alors le message de sortie sera celui du dernier CRITICAL. Si il a été CRITICAL, puis WARNING, puis OK alors c'est le message de sortie du WARNING qui persistera. Donc ce qui semble est un problème comme énoncé dans la Note 1, est en faite normal. (A été testé sur proto4 pour confirmation).

• Bien sur il y a les logs d'Apache :

# tail -f /var/log/httpd/error.log

• Tester la conf Nagios (Mandriva) :

# service nagios configtest

• Bien vérifier les droits sur les différents répertoire créés. En général : uid : apache ; gid : apache en 755

• Penser à relancer : apache ; nagios ; storeme quand nécessaire.