Objectifs de l'activité - kevinnguyen69.files.wordpress.com · linux-ssh (appelée glpi ici). On peut utiliser n’importe quel hôte supervisable il faudra simplement adapter le

http://www.reseaucerta.org © CERTA(Roger Sanchez) - Mars 2015 – v1.0 Page 1

Objectifs de l'activité :

Théoriquement : Mettre en place des cartes de supervision (Nagvis + Shinken). Pratiquement :

Installer Nagvis

Créer une carte

Paramétrer les échanges entre Nagvis et Shinken

Installer et configurer la prise en charge de Nagvis par shinken

Tester avec une carte simple

Matériel nécessaire : une machine virtuelle avec Linux Debianwheezy 64 bits graphique installé pour avoir

le navigateur, gedit et Shinken. Il est préférable de cloner une MV existante.

Une machine virtuelle supervisée (votre machine linux avec snmp ou votre machine windows avec wmi ).Ce document a été réalisée avec un hôte linux supervisée par linux-ssh (appelée glpi ici). On peut utiliser n’importe quel hôte supervisable il faudra simplement adapter le TP.

Résultat attendu :

Interaction entre Nagvis et Shinken à travers une carte

Organisation

Travail individuel.

Travail à faire Chaque partie comporte des travaux à faire.

Auteur

Roger Sanchez pour le réseau Certa.


Partie 1 : Installation de Nagvis

Travail à faire : exécuter les différentes commandes

Installation des paquets nécessaires à Nagvis

(liste suivante établie à partir d’une commande history) apt-get install apache2 apt-get install php5 apt-get install php5-gd apt-get install php5-json apt-get install php5-sqlite apt-get install php-gettext apt-get install libapache2-mod-php5 (Remarque : contient mbstring sessions …) apt-get install php-net-socket apt-get install graphviz apt-get install rsync Téléchargement de l’archive ici http://www.nagvis.org/downloads

Installation de Nagvis

(Liste suivante établie à partir d’une commande history) cd Téléchargements/ mv nagvis-1.8.1.tar.gz /tmp cd /tmp/ tar xvzf nagvis-1.8.1.tar.gz cd /tmp/nagvis-1.8.1 chmod +x install.sh install.sh …dans le processus d’installation pour l’emplacement de nagios on donne l’emplacement de shinken soit /var/lib/shinken …on laisse l’emplacement de nagis par défaut soit /usr/local/nagvis …on répond « y » à mk_livestatus et on donne l’adresse tcp :127.0.0.1 :50000 (voir plus loin) rm -rf /tmp/nagvis-1.8.1

Répertoires et fichiers associés à nagvis

Nagvis s’installe dans /usr/local/nagvis (si on n’a pas changé le répertoire proposé par défaut à l’installation) root@debianWheezy:~# ls /usr/local/nagvis etc LICENCE README share var

Il est pris en charge par apache grâce au fichier de configuration nagvis.conf

root@debianWheezy:~# ls /etc/apache2/ apache2.conf envvars mods-available ports.conf sites-enabled


conf.d magic mods-enabled sites-available root@debianWheezy:~# ls /etc/apache2/conf.d/ charset localized-error-pages nagvis.conf other-vhosts-access-log security root@debianWheezy:~# cat /etc/apache2/conf.d/nagvis.conf … Alias /nagvis "/usr/local/nagvis/share" <Directory "/usr/local/nagvis/share"> Options FollowSymLinks AllowOverride None Order allow,deny Allow from all # To enable Nagios basic auth on NagVis use the following options # Just uncomment it. Maybe you need to adjust the path to the # Auth user file. # # If you use the NagVis internal auth mechanism based on the web # for you won't need this. # #AuthName "NagVis Access" #AuthType Basic #AuthUserFile /var/lib/shinken/etc/htpasswd.users #Require valid-user # With installed and enabled mod_rewrite there are several redirections # available to fix deprecated and/or wrong urls. None of those rules is # mandatory to get NagVis working. <IfModule mod_rewrite.c> RewriteEngine On RewriteBase /nagvis # Use mod_rewrite for old url redirection even if there are php files which # redirect the queries itselfs. In some cases the mod_rewrite redirect # is better than the php redirect. # # Using the php redirect seems to be better in some cases where https/http servers # are mixed. For example in OMD setups where using apache own mode and https in the # frontend and http in the backend apache servers. # # Disabling this redirect by default in the hope that the php direct works better. #RewriteCond %{REQUEST_URI} ^/nagvis(/config\.php|/index\.php|/|)(\?.*|)$ #RewriteRule ^(.*)$ /nagvis/frontend/nagvis-js/%1%2 [R=301,L] # Redirect old regular map links RewriteCond %{REQUEST_URI} ^/nagvis/frontend/(wui|nagvis-js) RewriteCond %{QUERY_STRING} map=(.*) RewriteRule ^(.*)$ /nagvis/frontend/nagvis-js/index.php?mod=Map&act=view&show=%1 [R=301,L] # Without map= param RewriteCond %{REQUEST_URI} ^/nagvis/frontend(/wui)?/?(index.php)?$ RewriteRule ^(.*)$ /nagvis/frontend/nagvis-js/index.php [R=301,L] # Redirect old rotation calls RewriteCond %{REQUEST_URI} ^/nagvis/frontend/nagvis-js RewriteCond %{QUERY_STRING} !mod RewriteCond %{QUERY_STRING} rotation=(.*) RewriteRule ^(.*)$ /nagvis/frontend/nagvis-js/index.php?mod=Rotation&act=view&show=%1 [R=301,L] </IfModule> </Directory>



Utilisation de nagvis

Pour que nagvis soit pris en compte par apache il faut redémarrer le service. service apache2 restart On ouvre la page web de nagvis (avec http://localhost/nagvis et « credentials » admin/admin).

Nagvis est livré avec quelques démos (pas test, test c’est ma démo ;-) ). Ces démos se trouvent dans le répertoire etc de nagvis shinken@debianWheezy:/root$ ls /usr/local/nagvis/etc/ apache2-nagvis.conf-sample geomap nagvis.ini.php~ profiles auth.db maps nagvis.ini.php-sample conf.d nagvis.ini.php perms.db-sample shinken@debianWheezy:/root$ ls /usr/local/nagvis/etc/maps/ demo-automap2.cfg demo-germany.cfg demo-muc-srv1.cfg demo-automap.cfg demo-ham-racks.cfg demo-overview.cfg demo-geomap.cfg demo-load.cfg test.cfg Encore une fois ce sont de simples fichiers texte de configuration. Si on ne veut plus voir apparaître les fichiers démos il suffira donc de renommer leur extension (en mettant bak par exemple).

Observation d’un fichier de configuration

Si on regarde le contenu du fichier test.cfg (que vous n’avez pas) on trouve ceci root@debianWheezy:~# cat /usr/local/nagvis/etc/maps/test.cfg define global { object_id=0 alias=test map_image=testCarte.png } define host { object_id=524438 host_name=glpi x=126 y=48 backend_id=live_1 gadget_type=img label_text=Serveur GLPI label_show=1 recognize_services=1 label_x=165 label_y=47 }

http://localhost/nagvis


Ouverture du fichier de configuration dans nagvis

Ce fichier correspond à ceci sur Nagvis quand on l’ouvre

Si on passe la souris on peut voir les états (la couleur jaune est du au fait que notre adressage ne nous permet pas d’accéder à un serveur ntp ce qui provoque un warning).

On s’aperçoit ici que Nagvis renvoie sur l’image du serveur de notre « petite » carte les états supervisés de notre serveur glpi. C’est cette relation entre nagvis et shinken que nous allons étudier et configurer dans la 2

ème partie.

Nous chercherons à obtenir le résultat précédent.


Partie 2 Nagvis et Shinken

Travail à faire : exécuter les différentes commandes

Livestatus

La relation entre shinken et nagvis peut se faire de différentes manières

transmission de fichiers texte à déconseiller car très lent

communication web entre processus le mieux aujourd’hui C’est cette 2

ème façon que nous allons mettre en place, elle s’appelle « livestatus » (cela a été

paramétré pour nagvis tout à l’heure lors de l’installation de nagvis mais on va revenir dessus). Qu’est ce que livestatus ? Ce module se met à l’écoute sur un port et permet d’accéder via LQL (Livestatus Query Language langage créé pour cet usage) à un ensemble d’informations de shinken (ou nagios …).

Installation de livestatus

On l’installe avec l’utilisateur shinken. shinken@debianWheezy:~# shinken install livestatus Cela a pour conséquence principalement d’installer des programmes python dans l’arborescence modules de shinken. root@debianWheezy:~# ls /var/lib/shinken/modules/livestatus/ counter.py livestatus_query_metainfo.pyc counter.pyc livestatus_query.py __init__.py livestatus_query.pyc __init__.pyc livestatus_regenerator.py livestatus_client_thread.py livestatus_regenerator.pyc livestatus_client_thread.pyc livestatus_request.py livestatus_command_query.py livestatus_request.pyc livestatus_command_query.pyc livestatus_response.py livestatus_constraints.py livestatus_response.pyc livestatus_constraints.pyc livestatus_stack.py livestatus_counters.py livestatus_stack.pyc livestatus_counters.pyc livestatus_wait_query.py livestatus_obj.py livestatus_wait_query.pyc livestatus_obj.pyc log_line.py livestatus_query_cache.py log_line.pyc livestatus_query_cache.pyc mapping.py livestatus_query_error.py mapping.pyc livestatus_query_error.pyc module.py livestatus_query_metainfo.py module.py

Port d écoute de livestatus

On trouvera bien sur aussi un fichier de configuration spécifique pour livestatus root@debianWheezy:~# ls /etc/shinken/modules/ auth_cfg_password.cfg livestatus.cfg sample.cfg webui.cfg~ glpidb.cfg livestatus.cfg~ status-dat.cfg ws_arbiter.cfg glpidb.cfg~ logstore_sqlite.bak ui-graphite.cfg ws_arbiter.cfg~ import-glpi.cfg logstore_sqlite.cfg ui-pnp.cfg


import-glpi.cfg~ mongodb.cfg webui.cfg Dont le contenu est le suivant root@debianWheezy:~# cat /etc/shinken/modules/livestatus.cfg ## Module: livestatus ## Loaded by: Broker # The LIVESTATUS API makes internal Shinken data available via the network # using an SQL-like syntax. The API supports various access methods, # authentication and sophisticated performance options. The premier interface # to Shinken internal host and service states, historical data, performance # data, configuration data, comments, maintenance periods, etc. define module { module_name livestatus module_type livestatus host * ; * = listen on all configured IP addresses port 50000 ; port to listen #socket /usr/local/shinken/var/rw/live ; If a Unix socket is required ## Available modules: # - logstore-sqlite: send historical logs to a local sqlite database # - logstore-mongodb: send historical logs to a mongodb database # - logstore-null : send historical logs to a black hole #modules logstore-null #debug /tmp/ls.debug ; Enable only for debugging this module #debug_queries 0 ; Set to 1 to dump queries/replies too (very verbose) } Le port d’écoute est donc le port 50000, important à noter car il faudra le dire à nagvis.

Prise en compte du module livestatus par le module broker

La prise en compte de ce nouveau module se fait par l’intermédiaire du module broker (qui fait déjà appel à webui). root@debianWheezy:~# cat /etc/shinken/brokers/broker-master.cfg #=============================================================================== # BROKER (S1_Broker) #=============================================================================== # Description: The broker is responsible for: # - Exporting centralized logs of all Shinken daemon processes # - Exporting status data # - Exporting performance data # - Exposing Shinken APIs: # - Status data # - Performance data # - Configuration data # - Command interface # https://shinken.readthedocs.org/en/latest/08_configobjects/broker.html #=============================================================================== define broker { broker_name broker-master address localhost port 7772 spare 0 ## Optional manage_arbiters 1 ; Take data from Arbiter. There should be only one ; broker for the arbiter.


manage_sub_realms 1 ; Does it take jobs from schedulers of sub-Realms? timeout 3 ; Ping timeout data_timeout 120 ; Data send timeout max_check_attempts 3 ; If ping fails N or more, then the node is dead check_interval 60 ; Ping node every N seconds ## Modules # Default: None # Interesting modules that can be used: # - simple-log = just all logs into one file # - livestatus = livestatus listener # - tondodb-mysql = NDO DB support # - npcdmod = Use the PNP addon # - graphite = Use a Graphite time series DB for perfdata # - webui = Shinken Web interface # - glpidb = Save data in GLPI MySQL database modules webui,livestatus # Enable https or not use_ssl 0 # enable certificate/hostname check, will avoid man in the middle attacks hard_ssl_name_check 0 ## Advanced realm All }

Fichiers logs associés à livestatus

Il faut aussi installer pour livestatus la prise en charge de fichiers logs. On a soit la possibilité de stocker les logs dans une base de données soit de les envoyer dans un fichier « poubelle » (nullog), ce que j’ai choisi ici (avec l’utilisateur shinken bien sûr). shinken install logstore-null Mais si on démarre shinken on a une erreur sur ce fichier log. En effet (bug ???) shinken continue à exiger logstore_sqlite.log. Pour contourner le problème (parce que je ne voulais pas installer sqlite en plus de mongDB), j’ai installé le log associé à sqllite shinken install logstore-sqlite Puis j’ai sauvegardé la configuration de sqllite dans un fichier .bak et enfin remplacer le contenu de sqllite par celui de nullog. root@debianWheezy:~# cat /etc/shinken/modules/logstore_sqlite.cfg ## Module: nulllogs ## Loaded by: Livestatus # Put the Livestatus logs in a black hole, so LS can not query them. # Useful if you run a livestatus backend dedicated to nagvis in addition # to your regular livestatus backend. define module { module_name nulllogs module_type logstore_null } root@debianWheezy:~# cat /etc/shinken/modules/logstore_sqlite.bak ## Module: logstore-sqlite


## Loaded by: Livestatus # Put the Livestatus logs in an sqlite database, and so LS can query them. define module { module_name logstore-sqlite module_type logstore_sqlite # Shinken 1.4 configuration # database_file /usr/local/shinken/var/livelogs.db # Shinken 2.0 configuration database_file /var/log/shinken/livelogs.db # Prefer SQL queries if available instead of internal in-memory lookups # Some corner cases may return invalid or no data. Defaults to 0 if unset. #use_aggressive_sql 1 ; Set to 1 for large installations # Only use this module to read log. Useful if you load balance # your livestatus activity over severals livestatus broker module. # Defaults to 0 if unset #read_only 1 ; Read only logstore max_logs_age 3m ; d = days, w = weeks, m = months, y = years } Le redémarrage se passe maintenant bien. On peut d’ailleurs vérifier qu’il y a un port 50000 à l’écoute. root@debianWheezy:~# netstat -tnlp Connexions Internet actives (seulement serveurs) Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name …. tcp 0 0 0.0.0.0:50000 0.0.0.0:* LISTEN 3985/python2.7 … On retourne maintenant sur nagvis.

Relation entre nagvis et le module livestatus de shinken

Il faut éditer le fichier de configuration php de nagvis /usr/local/nagvis/etc/nagvis.ini.php, et mentionner sur le « bakckend » livestatus « live_1 » le port d’écoute (avec éventuellement l’adresse IP si shinken est sur une autre machine). [backend_live_1] ; It works as follows: The assumption is that there is a "local" backend which ; monitors the host of the "remote" backend. When the remote backend host is ; reported as UP the backend is queried as normal. ; When the remote backend host is reported as "DOWN" or "UNREACHABLE" NagVis won't ; try to connect to the backend anymore until the backend host gets available again. ; ; The statushost needs to be given in the following format: ; "<backend_id>:<hostname>" -> e.g. "live_2:nagios" ;statushost="" socket="tcp:localhost:50000"

Création d’une image de fond

Tout d’abord on se crée une image « très très simple » au format png avec packet tracer, ressemblant à celle montrée au début de ce document. On va stocker cette image dans le répertoire suivant : /usr/local/nagvis/share/userfiles/images/maps/testCarte.png


root@debianWheezy:~# ls /usr/local/nagvis/share/userfiles/images/maps demo-germany.png demo-ham-racks.png demo-host.png demo-load.png demo-overview.png geomap-1_1_1_0_100_mapnik__0.25_csv_demo-locations_800_600_std_medium_0.png geomap-1_1_1_0_100_mapnik__0.25_csv_demo-locations_800_600_std_medium_1.png testCarte.png On se connecte via le navigateur (http://localhost/nagvis avec les credentials nagvis/nagvis)

On crée une carte

On édite la carte

http://localhost/nagvis


Pour lui affecter une image de fond

On choisit le backend « live_1 » pour la carte

On obtient ça

On débloque tout

On ajoute un hôte


Cet hôte doit avoir le même nom que sur shinken (dans mon cas glpi)

On bloque à nouveau et on obtient ça (après échange entre nagvis et shinken)

Si on passe la souris on peut voir les états (la couleur jaune est du au fait que notre adressage ne nous permet pas d’accéder à un serveur ntp ce qui provoque un warning).

Voilà on est capable maintenant de généraliser. Ce que nous allons faire bien sûr ;-).

Documents

Objectifs de l'activité - kevinnguyen69.files.wordpress.com · linux-ssh (appelée glpi ici). On peut utiliser n’importe quel hôte supervisable il faudra simplement adapter le