Affichage des articles dont le libellé est shinken. Afficher tous les articles
Affichage des articles dont le libellé est shinken. Afficher tous les articles

mercredi 31 octobre 2012

Thruk une alternative à l'interface Web de Nagios

Il était une fois un moteur nagios ...

Si comme moi vous avez été amené a mettre en oeuvre plusieurs nagios, vous avez sûrement dû vous frotter a son interface Web a base de cgi et de fichier plat exporter toutes les 10 secondes.

Ne crachons pas dans la soupe, cette interface reste très bien pour une petite installation.

Malheureusement, avec l'évolution des besoins en supervision, il devient de plus en plus difficile de se contenter de cette interface. En vrac, on va donner les éléments suivants :
  • Interface vieillissante qui (en dehors des nouveaux CSS des dernières version de nagios) n'a plus évolué depuis de nombreuses années ;
  • Nécessité d'héberger les CGI sur la même machine que le moteur nagios ;
  • Overhead d'écriture du fichier status.dat ;
  • Désynchronisation de l'interface avec le moteur nagios (pour lancer un test immédiat - même dans le cas d'un test très court - l'interface vous rend la main tout de suite et vous devez attendre le lancement du test + le temps de rafraîchissement du fichier status.dat) ;
  • Explosion des temps de réponse dans le cas d'une grosse installation ;
  • Dans le cas où vous auriez plusieurs nœuds nagios, vous devez vous connecter sur la bonne interface pour consulter votre serveur.

Origine de Thruk

Thruk est donc un projet qui a démarré sur ce constat afin d'offrir une alternative sans pour autant dérouté complètement les utilisateurs en reprenant - dans les grandes lignes - l'aspect de l'ancienne interface. En réalité, cette interface apporte des améliorations très intéressantes par rapport à l'ancienne interface avec notamment les points suivants :
  • Possibilité de déporter l'interface de consultation sur un serveur distant ;
  • Possibilité de fédérer plusieurs noeuds nagios dans la même interface ;
  • Compatibilité avec n'importe quel moteur du moment que ce dernier supporte Livestatus (Shinken, Icinga, centreon engine, check_mk).

Quelques pré-requis de fonctionnement

L'installation de Livestatus se fait en rajoutant un broker à votre moteur nagios. Pour plus de détail, vous pouvez vous reporter à l'article suivant : setting up and using Livestatus. A noter que check_mk et Shinken viennent nativement avec ce support.

Autre point, dans le cas d'un accès déporter, il sera peut-être nécessaire de mettre en place un outil vous permettant d'exposer votre socket Unix sur le réseau. La documentation officiel fait appel à l'outil Unixcat (qui vient avec nagios). Pour ma part, j'ai préféré utiliser l'outil socat qui m'a donné des connexions plus stable et plus rapide. Ci-dessous un exemple de commande pour lancer socat :

socat TCP-LISTEN:1958,interface=lo,reuseaddr,keepalive,nodelay,fork,crnl \
      UNIX-CLIENT:/var/lib/nagios3/rw/live,keepalive

Installation de Thruk

Le gros défaut de Thruk est tout de même la ribambelle de plugin perl CPAN qu'il a comme dépendance. Heureusement, l'auteur du plugin propose un package tout prêt pour la plupart des plateformes disponibles (Debian, RedHat, Ubuntu, etc.). Pour se faire, il faut se rendre sur la page de téléchargement du projet, choisir le package qui vous convient et procéder à l'installation du package.

A noter que le produit a tout de même besoin de quelques dépendances au niveau système (plugin fastcgi pour apache notamment). Il faudra donc bien penser à installer ces dernières sous peine d'avoir des erreurs au moment de l'installation du package.

Une fois l'installation terminée, Thruk va créer un fichier htpasswd avec comme administrateur par défaut thrukadmin (mdp thrukadmin). Dans le cas où vous auriez déjà un fichier de mot de passe, bien penser à modifier le fichier /etc/apache2/conf.d/thruk.conf afin de pointer sur le bon. Bien penser également à modifier le fichier /etc/thruk/cgi.cfg dans ce cas là afin de définir les droits adéquates.

Enfin, il vous faudra  modifier le fichier /etc/thruk/thruk_local.conf afin de pointer sur votre noeud de supervision. Ci-dessous un exemple d'interfaçage avec un moteur Shinken :
######################################
# Backend Configuration, enter your backends here
<Component Thruk::Backend>
  <peer>
      name   = Shinken
      type   = livestatus
      <options>
          peer    = 127.0.0.1:50000
     </options>
  </peer>
</Component>
Un petit arrêt/relance du serveur apache et nous devrions être en mesure d'utiliser Thruk.

Tour du propriétaire

Connectez-vous sur l'interface Thruk (http://MONSERVEUR/thruk/). On devrait vous demander un mot de passe (thrukadmin/thrukadmin par défaut).

Au premier lancement, vous devriez avoir à attendre quelques secondes (ce comportement est normal puisque apache va devoir instancier les process fastcgi de Thruk à ce moment là). Ce délais d'attente passé, vous devriez arriver sur l'interface de Thruk. Par la suite, les process étant déjà là, vous n'aurez pas ce temps d'attente.

Comme indiqué un peu plus haut, l'interface est quasi la même que celle des CGIs si on exclue la map graphique (mais elle est avantageusement remplacé par une grille qui est plus fonctionnelle).

Du côté des améliorations, on peut noter les points suivants :
  • Champ de recherche plus efficace (utilisation d'ajax pour vous proposer des solutions lors de le champ de recherche avec proposition de choix de hostgroup, nom des services et bien sûr machine) ;
  • Lors du lancement d'un test, l'interface se bloque tant que le moteur nagios n'a pas récupéré le résultat du test (plus besoin de faire de rafraîchissement) ;
  • Intégration des graphiques de PNP ;
  • Présence de lien permettant des exports au format Excel (je sais, je suis pas forcément fan mais c'est quand même pratique).
Globalement, l'interface est plus jolie, plus réactive et vous avez également d'autres raffinements auxquels je ne pense pas forcément (générateur de rapport, gestion de la conf etc.).

Bref, comme dirait l'autre, l'essayer c'est l'adopter !

mercredi 3 octobre 2012

Mise en place selenium

Ces derniers temps, on m'a demandé de mettre en place de scénario de surveillance sur une application typiquement horrible : code HTML horrible, Internet Explorer only etc.

Bref, j'ai donc commencé à vouloir faire ça en cucumber mais je me suis rapidement frotté à des problèmes mon cher concombre masqué refusant catégoriquement mes noms de formulaires fantaisiste (il faut dire qu'on trouve des dollars ('$') dedans ...).

Bien triste, j'ai commencé à chercher quelque chose d'autre qui pourrait répondre à mon besoin et je suis tombé sur selenium (http://seleniumhq.org/) et son IDE (qui est une simple extension à installer dans firefox).

J'ai commencé à faire joujou avec l'IDE et - malgré un rendu HTML catastrophique - j'ai réussi à faire un scénario de test avec Firefox.

En trifouillant un peu, j'ai vu qu'il existait un serveur selenium (un process java) et qu'il pouvait tourner dans un serveur X virtuel. Devant tant de beauté, j'ai donc commencé à mettre ça en place :D.

Pré-requis python

Comme par la suite je vais générer des scripts au format python, nous allons devoir installer la librairie python permettant de communiquer avec selenium. Ici, rien de bien compliqué, un coup de apt-get pour installer le nécessaire :

apt-get install python-pip python-dev build-essential

Maintenant que nous avons pip, nous pouvons procéder à l'installation de la librairie selenium :

pip install -U selenium

Passons maintenant à la suite (et y'a du monde !)

X11 Virtual frame buffer (miam !)

Ce cher Xvfb ! Toujours un petit moment émouvant quand je le croise ! Pour le lancer, il faut simplement utiliser la ligne de commande suivante :

DISPLAY=:1 Xvfb :1 -screen 0 1024x768x24

Bien penser à le rendre utilisable depuis n'importe où avec la commande xhost :

DISPLAY=:1 xhost +

ATTENTION : L'utilisation de xhost + va rendre le serveur X visible depuis l'extérieur !!! Il est conseillé de mettre en place un parefeu pour bloquer les accès externes.

L'installation se fait avec un apt-get install xvfb (et x11-server-utils pour disposer de l'utilitaire xhost)

Installation de Firefox

Par la suite, nous utiliserons firefox pour faire nos tests. Donc rien de bien fameux si ce n'est un apt-get install firefox (à remplacer par iceweasel si vous êtes sur Debian).

Mise en place de Selenium

On arrive enfin au coeur du sujet. Selenium est un serveur qui s'appuie sur un jar java pour se lancer. Donc de manière logique, il va vous falloir un java fonctionnel. Je vous passe les détails, vous faîtes comme vous voulez.

Récupérer ensuite la dernière version de selenium serveur sous la forme d'un JAR. Vous pouvez ensuite le lancer avec la ligne de commande suivante :

export DISPLAY=:1
java -Djava.security.egd=file:/dev/./urandom \
     -jar /path/to/jar/selenium-server-standalone-2.25.0.jar \
     -browserSessionReuse

A noter la présence de l'option -browserSessionReuse qui permet d'éviter de relancer le navigateur à chaque lancement de scénario et l'option biscornu java.security.egd qui permet de passer du device aléatoire /dev/random (qui est lent) à /dev/urandom qui lui n'utilise pas l'entropie du système pour fonctionner mais un générateur de nombre aléatoire.

Test de notre premier scénario

À l'aide de l'IDE selenium, nous avons enregistré notre scénario. Nous allons maintenant exporter ce dernier au format Python 2 / unittest / Remote Control. Voici ce à quoi ça devrait ressembler :

from selenium import selenium
import unittest, time, re

class sites(unittest.TestCase):
    def setUp(self):
        self.verificationErrors = []
        self.selenium = selenium("localhost", 4444, "*chrome", "http://monsite/")
        self.selenium.start()
    
    def test_sites(self):
        sel = self.selenium
        sel.open("/ma_page")
        sel.type("id=un_champ", "une_valeur")
        sel.type("id=un_autre_champ", "une_autre_valeur")
        sel.click("id=id_d_un_lien")
        sel.wait_for_page_to_load("30000")
    
    def tearDown(self):
        self.selenium.stop()
        self.assertEqual([], self.verificationErrors)

if __name__ == "__main__":
    unittest.main()
Lançons maintenant ce beau script depuis la machine faisant tourner selenium :

python mon_scenario.py
.
----------------------------------------------------------------------
Ran 1 test in 4.051s
OK

Magnifique non ? Tout à fait mais ça ne vous dit pas ce que vous allez en faire dans votre nagios.

(Des)intégrations dans nagios/Shinken

Comment ça, vous voulez le script qui analyse la sortie de tout ça et l'insert directement dans nagios ? Je vous trouve un peu exigeant quand même !

Bon, si vous insistez ... Il faut récupérer le script check_selenium.pl et lancer ensuite la sonde de la manière suivante :

/emplacement/scripts/check_selenium.pl --script \
      /emplacement/de/mon/scenario.py  \
      --label "Le test de ma super application"

De là, vous devriez obtenir la sortie suivante :

Selenium test OK (Le test de ma super application)|time=3.180s test_count=1

Elle est pas belle la vie ?

mardi 2 octobre 2012

Suivi des interfaces d'un switch CISCO sous Nagios/Shinken

Depuis quelques jours, je travaille sur la mise en place d'un Shinken chez un client. A cette occasion, on m'a demandé de faire un suivi des switchs de la boîte et notamment le débit de chaque port.

Comme je suis quelqu'un de relativement paresseux (je n'avais pas trop envie de me déclarer les 48 ports des 200 switchs à la main). J'ai donc rapidement pensé à un script qui me permettrait de déclarer automatiquement ces surveillances. Et comme je suis un mec super sympas qui adore raconter sa vie, je vais vous en faire profiter bande de veinards !

Pour se faire, nous allons utiliser les MIBs SNMP des switchs CISCO qui ont la bonne idée de proposer tout un tas de chose vachement intéressante (oui, enfin ... pour un administrateur d'outils de surveillance). Nous allons voir notamment l'OID 1.3.6.1.2.1.2.2.1.2 qui va nous renvoyer la liste des interfaces du switch :

$ snmpwalk -c ecalyptus -v 2c 10.1.1.1 1.3.6.1.2.1.2.2.1.2
iso.3.6.1.2.1.2.2.1.2.1 = STRING: "FastEthernet1"
iso.3.6.1.2.1.2.2.1.2.2 = STRING: "TenGigabitEthernet1/1"
iso.3.6.1.2.1.2.2.1.2.3 = STRING: "TenGigabitEthernet1/2"
iso.3.6.1.2.1.2.2.1.2.4 = STRING: "TenGigabitEthernet1/3"
iso.3.6.1.2.1.2.2.1.2.5 = STRING: "TenGigabitEthernet1/4"
iso.3.6.1.2.1.2.2.1.2.6 = STRING: "GigabitEthernet3/1"
iso.3.6.1.2.1.2.2.1.2.7 = STRING: "GigabitEthernet3/2"
iso.3.6.1.2.1.2.2.1.2.8 = STRING: "GigabitEthernet3/3"
iso.3.6.1.2.1.2.2.1.2.9 = STRING: "GigabitEthernet3/4"
iso.3.6.1.2.1.2.2.1.2.10 = STRING: "GigabitEthernet3/5"
iso.3.6.1.2.1.2.2.1.2.11 = STRING: "GigabitEthernet3/6"
iso.3.6.1.2.1.2.2.1.2.12 = STRING: "GigabitEthernet3/7"
iso.3.6.1.2.1.2.2.1.2.13 = STRING: "GigabitEthernet3/8"
iso.3.6.1.2.1.2.2.1.2.14 = STRING: "GigabitEthernet3/9"
iso.3.6.1.2.1.2.2.1.2.15 = STRING: "GigabitEthernet3/10"
[...]

Nous allons nous servir de cette sortie pour générer notre surveillance. Pour cela, nous allons utiliser le script perl suivant :
#!/usr/bin/perl
use strict;

open(MODEL, "modele.txt");
mkdir("modeles") if(!-d("modeles"));
while() {
  chomp();
  my($modele, $ip) = split(/;/);
  my @interfaces = `snmpwalk -c ecalyptus -v 2c $ip 1.3.6.1.2.1.2.2.1.2`;
  open(MODEL_CFG, ">modeles/switch-$modele.cfg");
  foreach(@interfaces) {
    if(/iso.3.6.1.2.1.2.2.1.2.(\d+) = STRING: "(.*Ethernet.*)"/) {
      my ($id, $interface) = ($1, $2);
      print MODEL_CFG "define service {
  hostgroup_name       $modele
  use                  generic-service
  service_description  $interface
  check_command        check_port_usage!$id!6000!8000
}
\n";
    }
  }
  close(MODEL_CFG);
}
close(MODEL);
Ce script attend en entrée un fichier de paramètre (modele.txt) et nous donne en sortie des fichiers de configuration au format nagios dans le sous-répertoire modeles. Il nous reste maintenant à prendre ces fichiers et les intégrer dans la configuration de notre nagios/Shinken.

Ci-dessous un exemple de surveillance sur un switch CISCO (du type WS-C2960-24PC-L) :
define service {
  hostgroup_name       WS-C2960-24PC-L
  use                  generic-service
  service_description  FastEthernet0/1
  check_command        check_port_usage!10001!6000!8000
}
[...]
define service {
  hostgroup_name       WS-C2960-24PC-L
  use                  generic-service
  service_description  GigabitEthernet0/2
  check_command        check_port_usage!10102!6000!8000
}
Il reste ensuite à déclarer un hostgroup ad-hoc avec un template de serveur comme suit :

define hostgroup{
  hostgroup_name  WS-C2960-24PC-L
  alias           Switchs Cisco WS-C2960-24PC-L
}

define host {
  name            switch-WS-C2960-24PC-L
  use             generic-switch
  alias           Ensemble des switchs Cisco WS-C2960-24PC-L
  hostgroups      Switch,WS-C2960-24PC-L
  icon_image      vendors/cisco.png
  register        0
}
Et nous pouvons déclarer maintenant des switchs utilisant le template switch-WS-C2960-24PC-L. Ces derniers viendront directement avec la surveillance automatique de tous leurs ports.

dimanche 26 février 2012

Gestion des mots de passe de l'interface web de shinken

Shinken est sortie il y a peu de temps en version 1.0rc1. J'ai voulu l'installer et utiliser la nouvelle interface web. Comme j'ai eu quelques difficultés et qu'il semblerait que d'autre ai eu le même problème que moi (merci à David pour ton aide !), je me permets de déposer quelques éléments sur le sujet.
Pour l'installation, il faut tout d'abord télécharger l'archive à l'adresse suivante :https://github.com/naparuba/shinken/tarball/1.0rc1
Vous obtiendrez alors l'archive naparuba-shinken-1.0rc1-0-g5a2075e.tar.gz. Une fois l'archive décompressé, vous pourrez lancer l'installation à l'aide de la commande suivante :
sudo python setup.py install --install-scripts=/usr/bin/
De là, lancez shinken avec la commande /etc/init.d/shinken start
Si vous jetez un oeil au process shinken de votre machine, vous devriez obtenir les choses suivantes :
root@robert:/home/drayan/dev/naparuba-shinken-5a2075e# ps -fu shinken
UID        PID  PPID  C STIME TTY          TIME CMD
shinken  15495 30036  0 00:15 ?        00:00:00 /usr/bin/python /usr/bin//shinken-reactionner -d -c /etc/shinken/reactionnerd.ini
shinken  30009     1  0 Feb25 ?        00:00:56 /usr/bin/python /usr/bin//shinken-scheduler -d -c /etc/shinken/schedulerd.ini
shinken  30019 30009  0 Feb25 ?        00:00:00 /usr/bin/python /usr/bin//shinken-scheduler -d -c /etc/shinken/schedulerd.ini
shinken  30021     1  0 Feb25 ?        00:00:51 /usr/bin/python /usr/bin//shinken-poller -d -c /etc/shinken/pollerd.ini
shinken  30031 30021  0 Feb25 ?        00:00:21 /usr/bin/python /usr/bin//shinken-poller -d -c /etc/shinken/pollerd.ini
shinken  30036     1  0 Feb25 ?        00:00:40 /usr/bin/python /usr/bin//shinken-reactionner -d -c /etc/shinken/reactionnerd.ini
shinken  30046 30036  0 Feb25 ?        00:00:07 /usr/bin/python /usr/bin//shinken-reactionner -d -c /etc/shinken/reactionnerd.ini
shinken  30051     1  0 Feb25 ?        00:00:54 /usr/bin/python /usr/bin//shinken-broker -d -c /etc/shinken/brokerd.ini
shinken  30061 30051  2 Feb25 ?        00:05:53 /usr/bin/python /usr/bin//shinken-broker -d -c /etc/shinken/brokerd.ini
shinken  30063     1  0 Feb25 ?        00:00:22 /usr/bin/python /usr/bin//shinken-receiver -d -c /etc/shinken/receiverd.ini
shinken  30073 30063  0 Feb25 ?        00:00:00 /usr/bin/python /usr/bin//shinken-receiver -d -c /etc/shinken/receiverd.ini
shinken  30079     1  0 Feb25 ?        00:01:11 /usr/bin/python /usr/bin//shinken-arbiter -d -c /etc/shinken/nagios.cfg -c /etc/shinken/shinken-specific.cfg
shinken  30080 30079  0 Feb25 ?        00:00:03 /usr/bin/python /usr/bin//shinken-arbiter -d -c /etc/shinken/nagios.cfg -c /etc/shinken/shinken-specific.cfg
shinken  30087 30079  0 Feb25 ?        00:00:00 /usr/bin/python /usr/bin//shinken-arbiter -d -c /etc/shinken/nagios.cfg -c /etc/shinken/shinken-specific.cfg
shinken  30109 30021  0 Feb25 ?        00:00:04 /usr/bin/python /usr/bin//shinken-poller -d -c /etc/shinken/pollerd.ini
shinken  30116 30021  0 Feb25 ?        00:00:04 /usr/bin/python /usr/bin//shinken-poller -d -c /etc/shinken/pollerd.ini
shinken  30124 30021  0 Feb25 ?        00:00:04 /usr/bin/python /usr/bin//shinken-poller -d -c /etc/shinken/pollerd.ini
shinken  30140 30051  1 Feb25 ?        00:03:26 /usr/bin/python /usr/bin//shinken-broker -d -c /etc/shinken/brokerd.ini
shinken  30149 30051  0 Feb25 ?        00:00:14 /usr/bin/python /usr/bin//shinken-broker -d -c /etc/shinken/brokerd.ini
shinken  30170 30021  0 Feb25 ?        00:00:04 /usr/bin/python /usr/bin//shinken-poller -d -c /etc/shinken/pollerd.ini
Vous pouvez maintenant vous rendre sur l'interface web de shinken sur l'url suivante : http://localhost:7767/
Un utilisateur vous sera demandé. Il s'agira par défaut de admin/admin.
A ce sujet, il faut savoir que le système d'authentification s'appuie sur la configuration contenu dans le fichier shinken-specific.cfg (dans le répertoire /etc/shinken) et notamment sur le passage suivant :

# The WebUI broker module
define module{
       module_name      WebUI
       module_type      webui
       
       host             0.0.0.0       ; mean all interfaces
       port             7767

[...]
       modules          Apache_passwd,ActiveDir_UI,Cfg_password
[...]
}
Comme indiqué, l'interface essaye d'authentifier l'utilisateur avec 3 modules différents. Le premier qui y arrive arrête le mécanisme.
Dans le cas présent, nous allons tout d'abord essayer de nous authentifier avec un fichier htpasswd apache (toujours dans shinken-specific.cfg) :
define module{
       module_name      Apache_passwd
       module_type      passwd_webui

       #  WARNING : put the full PATH for this value!
       passwd           /etc/shinken/htpasswd.users

}
Vient ensuite le module active directory :
# Check authentification for WebUI using a Active Directory
define module{
       module_name      ActiveDir_UI
       module_type      ad_webui

#   UNCOMMENT this line to really enable this module and allow it to
#   connect!
#        ldap_uri         ldaps://myserver
       username         user
       password         password
       basedn           DC=google,DC=com

}
Enfin, dans le cas de l'interface web de shinken (avec sa conf par défaut), ce dernier va s'appuyer sur ces fichiers de configuration. Dans le cas de l'utilisateur admin, il s'agit d'un contact (au sens nagios) définie dans les fichiers de configuration (par défaut, fichier contacts.cfg). Le mot de passe est par ailleurs définie de la manière suivante :
define contact{
        use                                     generic-contact
        contact_name                            admin
        email                                   shinken@localhost
        pager                                   0600000000   ; contact phone number
        password                                admin
        is_admin                                1
}
De là, vous pouvez changer le mot de passe et le faire prendre en compte par shinken. Il ne reste plus maintenant qu'à configurer vos services !

jeudi 23 décembre 2010

Installation de shinken et configuration de l'interface Thruk

J'utilise beaucoup nagios pour mon travail de tous les jours mais c'est un outil qui n'est pas parfait (loin de là! ). J'ai donc lu avec beaucoup d'intérêt le démarrage du projet shinken qui a comme gros avantage d'être beaucoup plus performant et d'être beaucoup plus modulable que son ainé.

Voulant m'en faire une idée pour de vrai, j'ai donc procédé à une installation from scratch. Comme la documentation ne parle pas du tout de l'ajout de l'interface, je laisse donc ici quelques mots à ce sujet.

Installation de shinken



Tout d'abord créer un utilisateur shinken. Très important, il faut un home qui soit valide (sinon, l'arbitrer ne démarre pas !).

Reste ensuite à procéder à l'installation. Ici, rien de plus simple, il faut simplement récupérer le package shinken-0.4.tar.gz puis de le décompresser. Se rendre dans le répertoire shinken-0.4 puis lancer la commande suivante :

sudo python setup.py install --install-scripts=/usr/bin


De là, shinken va créer pas mal de répertoire (notamment /var/lib/shinken et /etc/shinken). Par convenance, j'ai créé un fichier shinken.sh qui me lance tous les éléments dans le bon ordre :


patrice@Enclume:~/tmp/shinken-0.4$ cat /etc/init.d/shinken.sh
#!/bin/bash

cd /etc/init.d

for script in shinken-scheduler shinken-poller shinken-reactionner shinken-broker shinken-arbiter
do
./$script $1
done


De là, il suffit de faire un /etc/init.d/shinken.sh start et c'est parti ! Pour vérifier que tout va bien, il faut s'assurer que les process suivants sont bien présents :


patrice@Enclume:~/tmp/shinken-0.4$ ps -u shinken
PID TTY TIME CMD
4358 ? 00:00:09 shinken-schedul
4367 ? 00:00:10 shinken-poller
4372 ? 00:00:00 shinken-poller
4380 ? 00:00:09 shinken-reactio
4385 ? 00:00:00 shinken-reactio
4949 ? 00:00:13 shinken-broker
4989 ? 00:00:00 shinken-poller
4990 ? 00:00:00 shinken-poller
4993 ? 00:00:00 shinken-poller
4996 ? 00:00:18 shinken-broker
4997 ? 00:00:00 shinken-broker
5001 ? 00:00:00 shinken-reactio
5004 ? 00:00:00 shinken-poller
5018 ? 00:00:10 shinken-arbiter


Configuration de l'interface Thruk



Ici, il faut récupérer l'interface Thruk à l'emplacement suivant. On la décompresse puis nous nous rendons dedans afin d'y créer un fichier thruk_local.conf. En voici le contenu :


~/tmp/Thruk-0.74$ cat thruk_local.conf
######################################
# Backend Configuration, enter your backends here
<component Thruk::Backend>
<peer>
name = Shinken
type = livestatus
hidden = 0 # make this backend hidden by default
groups = admins # make this backend only visible to the admin group
<options>
peer = 127.0.0.1:50000
verbose = 0
</options>
</peer>
</component>


De là, il ne nous reste plus qu'à lancer le démon Thruk :


~/tmp/Thruk-0.74/script$ ./thruk_server.pl
You can connect to your server at http://enclume:3000


NB : Attention, il s'agit d'un test. Il est possible de lancer l'interface Thruk en utilisant un serveur apache mais ce n'est pas l'objet de cet article.

De là, il ne nous reste plus qu'à accéder à l'interface http://localhost:3000 au travers un navigateur :



Bon, il va maintenant falloir que je configure correctement ma map :D Mais bon, ça c'est une autre histoire ;).