Guide d’utilisation de Overmon Admin Tools

Overmon Admin Tools (OAT) est l’outil d’administration de la solution Overmon.

Il permet l’administration courante de l’OVS. En cas de besoin, sachez que le mot de passe du compte root est également « overmon ».

Il est disponible actuellement sur toute version Windows 32 & 64 bits.

Pré-requis

Avant d’utiliser ce guide, vous devez disposer d’une version à jour de l’OAT.

Par ailleurs, cette version doit s’exécuter en « full » mode, c’est-à-dire que tous les composants nécessaires au bon fonctionnement de l’OAT sont bien présent sur votre système Nagios/Centreon/Glpi, qu’il s’agisse d’un OVS ou de votre propre système.

Si ces deux conditions ne sont pas respectées, merci de bien vouloir vous référer au guide d’installation

Introduction

Ce guide est scénarisé.

Plutôt que de se contenter de vous présenter les fonctionnalités du produit, nous allons partir d’un système « vierge », et batir ensemble une gestion de parc performante, basée sur Overmon.

Le contexte est le suivant : nous disposons d’une version à jour de l’OAT, qui tourne bien en mode « full ».

Nous disposons également d’un parc de machines. Toutes sont virtuelles, et hébergées sur notre VMware workstation :

Un parc hétérogène de 11 machines, choisies pour être représentatives de la plupart des parcs d’entreprises.

Les points suivants sont à noter (car ils seront exploités ultérieurement dans ce guide) :

Le serveur Windows 2008 est controleur de domaine, serveur DNS et DHCP. En outre il héberge une base SQL Serveur 2008
Le serveur RedHat 4.6 hébèrge une base Oracle Express 10.2
Le serveur Debian 5 hébèrge une base Mysql 5

A ce stade, notre système glpi est vierge :

Aucune machine déclarée, aucun ticket d’incident.

De même, notre système Centreon est au repos :

Si vous utilisez l’OVS que nous fournissons, vous noterez qu’on y trouve déjà une machine sous surveillance : l’OVS lui même !

En effet, l’ensemble des processus nécessaires à l’OVS sont sous surveillance.

Nous allons pouvoir démarrer.

Lancons l’OAT :

Nous arrivons sur l’écran principal de l’OAT.

Premier point : notez que dans la barre de statut, vous trouverez les versions en cours chez vous, ainsi que les dernières versions en vigueur.

La syntaxe est la suivante : Commits : OVS (commit locat/commit distant) OAT (commit locat/commit distant)

Ce guide étant scénarisé, nous allons laisser tomber cet écran pour l’instant. Nous y reviendrons plus tard.

Entrons plutôt dans le vif du sujet …

A la découverte de Overmon

La première chose dont nous avons besoin, c’est d’importer notre parc dans Overmon.

Pour ce faire, cliquons sur l’onglet « Importer »

L’onglet « Importer »

Cet écran nous permet d’importer des machines, ainsi que des bases de données (nous y reviendrons plus tard)

Le système est extrêmement simple : Pour importer des machines, Overmon requiert la fourniture d’un fichier CSV, contenant les informations suivantes :

Nom de la machine
Nom de l’utilisateur (administrateur ou root de préférence)
Mot de passe
Type de machine

Important : il peut y avoir plusieurs types pour une machine.

Par exemple, notre serveur RedHat 4.6 possède deux types qui sont serveur redhat ET serveur Oracle.

Dans ce cas, les différents types doivent être séparés par une virgule.

Dans le cadre de ce guide, voici le fichier CSV que nous avons préparé :

SAMPLE-XP-01|SAMPLEPARK\administrator|Mdpplc;Administrator|Workstations-WinXP-NRPE-32
SAMPLE-AD|SAMPLEPARK\administrator|Mdpplc;Administrator|Servers-Win2K8-NSCA-64,Servers-DNS,Servers-DHCP,Servers-Mssql
SAMPLE-W2K3|SAMPLEPARK\administrator|Mdpplc;Administrator|Servers-Win2K3-WMI
SAMPLE-RHEL46|root|root|Servers-Linux-RedHat-SSH,Servers-Oracle
SAMPLE-DEBIAN5|root|root|Servers-Linux-Debian-NRPE,Servers-Mysql
SAMPLE-UBUNTU|root|root|Servers-Linux-Ubuntu-NSCA
CLX-3170|||Printers

Plusieurs points à noter à ce stade :

Les utilisateurs root (pour unix/linux) et administrator (pour windows) ne sont nécessaires QU’AU MOMENT du déploiement. Lors de l’exploitation courante de la solution, ils ne seront plus utilisés.
Pour les machines unix/linux, il est possible d’utiliser un utilisateur non root. Néanmoins, cela peut avoir des conséquences sur la qualité des informations remontées automatiquement dans l’inventaire Glpi
Les types de machines ne doivent pas être saisies au hasard. Seuls les types de machines disposant d’au moins un scénario de déploiement doivent être mentionnés.

Pour être certain de sa saisie, il suffit d’aller vérifier au niveau de l’onglet « Déployer ». Vous y trouverez une liste nommée « Types available » contenant tous les types que vous avez le droit d’utiliser. Cette liste est dynamique, car fonction de ce que vous avez déclaré dans Centreon d’une part, et des scénarios de déploiement dont vous disposez, d’autre part.

En tout état de cause, un contrôle sera fait au moment de l’importation, et les machines pour lesquelles soit le type n’existe pas, soit aucun scénario de déploiement n’est trouvé, seront exclues automatiquement.

Notez bien qu’il existe plusieurs types de sondes pour un type de machines.

Vous pouvez superviser une machine windows via NRPE (NSClient), WMI, SNMP ou NSCA

Pour les machines Linux/Unix, les méthodes proposées sont NRPE, SSH (remote), SNMP et NSCA

Avant de se lancer dans l’aventure, il est PRIMORDIAL de se poser les bonnes questions quant au type de sonde que l’on souhaite utiliser, chaque type de sonde possédant ses avantages et ses inconvénients.

Allons-y pour l’import.

Nous cliquons sur le bouton « Ouvrir CSV » du groupe « Hosts » :

Nous sélectionnons notre fichier CSV puis cliquons sur « Ouvrir » :

La liste « Equipements à importer » s’est remplie.

On ne se pose plus de questions … on sélectionne toutes ces machines et on clique sur « Importer » :

Et on valide en cliquant sur « Oui ».

Le processus d’importation démarre alors.

Chacun des hosts sera traité, et de multiples contrôles lui seront appliqué, en vue de savoir si oui ou non, ce host est apte à être géré par Overmon :

Le(s) type(s) de host définis sont ils corrects ?
Existe t-il un scénario associé ?
Le host a t-il déjà été importé ?
Le host est-il joignable via le réseau, depuis l’OAT ?
Le host est-il joignable via le réseau, depuis l’OVS ?
L’OVS est-il joignable via le réseau, depuis le host ?

Notez qu’il vous est possible de bypasser certains de ces contrôles. Pour ce faire, rendez-vous sur l’onglet « Options » et affectez la valeur « NO » à la variable ControlHostsConnectivity

Au terme du processus, un état récapitulatif vous sera proposé.

Prochaine étape : déployer les agents de supervision et d’inventaire sur nos machines fraichement importées.

L’onglet « Déployer »

Cet écran va vous permettre de déployer vos agents de supervision et d’inventaire sur vos machines. Il permettra également d’interagir avec ces agents, une fois qu’ils seront déployés.

Vous pouvez enfin créer manuellement une nouvelle machine dans Overmon. Cette méthode est néanmoins déconseillée car fastidieuse, comparée à l’import CSV.

Notez l’icone devant chaque machine : il signifie que la machine est up. Dans certains cas, si beaucoup de ces machines sont down, cela peut ralentir le lancement de l’application OAT. Si c’est votre cas, vous pouvez modifier le paramètre DisplayHostStatus dans l’onglet « Options ».

Avant d’allez plus loin, il est important de préciser les points suivants :

L’agent d’inventaire utilisé par Overmon est FusionInventory (www.fusioninventory.org), que nous avons préféré à OCS pour de multiples raisons.
L’agent de supervision utilisé par Overmon est NRPE pour les machines Linux/Unix et NSCLIENT pour les machines Windows
Il est possible de ne pas utiliser d’agent de supervision, tout en supervisant quand même les machines, que ce soit par SSH, SNMP ou WMI

Bon … trève de discours, et place à l’action …

Sélectionnons nos machines et cliquons sur « Installer agents » :

Confirmons en cliquant sur « Oui » :

La fenêtre qui apparait alors nous permet de préciser ce que nous souhaitons installer, et COMMENT nous souhaitons l’installer.

Il existe 2 modes d’installation :

Scénario+Prébuild : les agents sont installés sous forme pré-compilée et simplement déposés sur vos machines cibles
Scénario+Compilation : ce sont les sources qui sont poussés, et l’agent est compilé directement sur la machine cible, sous réserve de la présence d’un compilateur, cela va de soit …

Il vous est possible de n’installer que l’agent d’inventaire, ou que l’agent de supervision, ou les deux.

Enfin, il vous est également possible de vous restreindre à simplement générer les scripts d’installation. Ceci peut présenter un intérêt évident dans le cas où il ne vous est pas possible d’atteindre directement les machines. Dans ce cas, un répertoire portant le nom de la machine sera généré, et contiendra l’ensemble des éléments nécessaires. Il vous suffira ensuite de copier ce répertoire manuellement sur la machine distante, et de lancer l’installation localement, depuis cette machine.

Dans la très grande majorité des cas, il est conseillé d’utiliser le mode « Scénario + Prébuild », d’installer les deux agents, et de décocher le mode debug ainsi que la generation du fichier d’import centreon

Cliquons sur « Installer ». C’est maintenant que la magie opère …

Dans un premier temps, Overmon va déterminer s’il dispose en local des fichiers nécessaires à l’installation des agents. Pour ce faire, il va inspecter le contenu du répertoire <OAT_DIRECTORY>\Agents\Prebuilds\<HOST_TYPE> à la recherche des agents d’inventaire et de supervision.

Dans le cas où ces fichiers seraient absents, l’OAT va alors automatiquement les télécharger à partir des informations contenues dans les sections [FusionInventory] et [NSClient] du fichier OvermonAdminTools.ini

A noter :

Ce téléchargement n’est effectué qu’une seule fois par type d’agent
Dans le cas ou l’OAT n’aurait pas accès à Internet depuis votre lieu de travail, vous pouvez télécharger manuellement tous les agents, puis les placer dans les répertoires prévus

Ce guide d’utilisation n’est pas le lieu où détailler la somme de tâche exécutées par Overmon à ce moment.

Sachez simplement ceci :

Une barre de progression (style K2000) se met en mouvement et persistera jusqu’à la fin des opérations
Il faut compter environ 2 minutes par machine.
Au niveau des pré-requis, une simple connectivité SSH (Linux/Unix) et RPC (Windows) est nécessaire.
Vous visionnez en temps réel les actions en cours. La zone « Log locale » vous permet de suivre ce qui se passe au niveau du poste sur lequel vous travailler. La zone « Log distante », quant à elle, vous permet de visionner les tâches en cours sur la machine cible.
Toutes les opérations effectuées sur les machines cibles sont loggées (voir plus bas)
Pour les machines cibles windows, les outils de Sysinternals sont utilisés (psexec, pskill, psservice). Les copies sont effectuées via robocopy. Deux services (FusionInventory-Agent et Nsclientpp) seront créés et positionnés en démarrage automatique
Pour les machines Unix/Linux, Overmon utilise kitty (fork de putty). Les copies sont effectuées via pscp. Deux utisateurs (overmon et nagios) seront créés. Overmon sera installé dans /usr/local/overmon
Vous pouvez continuer à travailler sur votre poste de travail durant les opérations.
Il est possible de désinstaller ces agents ultérieurement.

Au bout de plusieurs minutes, le déploiement prend fin :

Jetons un oeil sur l’écran « Déployer ».

Nous remarquons l’apparition du logo de Glpi et de Centreon en face de chaque machine …

Non … c’est impossible … ce serait trop simple …. trop beau …

Allons vérifier dans Glpi tout d’abord :

Les inventaires ont été remontés automatiquement dans Glpi

Allons voir maintenant dans Centreon :

Les machines ont bien été insérées dans Centreon.

Cerise sur le gateau, certains services ont été créés automatiquement, en fonction du type de machine :

Mieux encore, deux types de liens ont été générés automatiquement, pour vous faciliter la vie.

Le premier est positionné à droite de chaque host. Si vous cliquez dessus, cela vous amène automatiquement sur la fiche Glpi correspondante. Pratique lorsqu’on cherche rapidement des informations sur une machine qu’on ne connait pas.

Le second se trouve à droite de chaque service. Si vous cliquez dessus, vous arriverez automatiquement sur une page d’un Wiki correspondant au service. :

L’idée est de vous permettre de batir de manière souple une base de connaissance liée à vos alarmes, en bénéficiant des avantages liés à un wiki.

Autre facilité qui vous est offerte. En faisant un clic-droit sur n’importe quelle machine :

vous pouvez :

vous connecter en remote sur vos machines
accéder à l’ensemble des logs liées au déploiement des agents.

Revenons à l’aspect déploiement pur.

Outre les agents déployés en un temps record, Cette fenêtre offre les possibilités suivantes :

Créer, Modifier, Supprimer : ces boutons permettent d’agir sur les machines gérées par Overmon
Raffraichir : certaines machines peuvent être assez longues à remonter leur inventaire sur l’OVS. D’ou l’intérêt de pouvoir raffraichir les informations de cette liste à la demande
Déployer clé SSH : Dans certains cas précis, on ne souhaite pas d ‘inventaire, ni de supervision sur une machine, mais simplement établir une connectivité SSH. Ce bouton est fait pour ca
Exporter : Pour le cas où vous auriez créé des milliers de machines manuellement dans Overmon, il serait dommage de tout perdre. Se créer un CSV à partir de son labeur est la moindre des choses …
Installer agents : vu plus haut
Statuer agents : Permet d’interroger les machines distantes sur l’état de leurs agents FusionInventory et Nrpe
Désinstaller agents : comme son nom l’indique …
Forcer inventaire : Les inventaires sont déclenchés selon une fréquence définie dans le plugin FusionInventory de Glpi (souvent tous les 24h). Overmon permet de forcer le déclenchement de cet inventaire à la demande.
Redémarrer agents : dans le cas où l’on a un doute sur l’état des agents.

Nos machines étant dorénavant déployées avec des services nagios de base, nous allons compléter notre dispositif.

1ère étape : superviser les bases de données de notre parc.

Retournons sur l’onglet « Importer ».

L’importation de bases de données respecte le même principe que celui de l’importation des machines, à savoir l’utilisation, en input, d’un fichier CSV.

Voici celui que nous avons préparé pour le guide :

La structure du fichier est la suivante :

Nom du host
Nom de l’instance
Port
User
Password

A noter pour chaque type de bases de données, il existe deux modes : un mode standard et un autre extended

A travers ces deux modes, nous avons souhaité nous rapprocher au plus près des réelles conditions de production de votre système d’information.

En effet, quel intérêt cela a t-il de superviser constamment 500 indicateurs spécifiques sur toutes vos bases de données. Et surtout, que faire des 500 alarmes qui se déclenchent si la base de donnée s’arrête.

C’est pour cela que nous avons mis en place ce système de double-mode :

le mode standard : à utiliser en tout temps, sur toutes vos bases de données. Dans ce cas, la supervision est concentrée sur quelques point clés, qui sont :

Oracle :

ORACLE-CONNECTED-USERS
ORACLE-CONNECTION-TIME
ORACLE-DATAFILE-IO-TRAFFIC
ORACLE-INVALID-OBJECTS
ORACLE-PROCESS-USAGE
ORACLE-RMAN-BACKUP-PROBLEMS
ORACLE-SESSION-USAGE
ORACLE-SGA-DATA-BUFFER-HIT-RATIO
ORACLE-SGA-DICTIONARY-CACHE-HIT-RATIO
ORACLE-TABLESPACE-CAN-ALLOCATE-NEXT
ORACLE-TABLESPACE-FRAGMENTATION
ORACLE-TABLESPACE-FREE
ORACLE-TNSPING

SQL Server :

MSSQL-CONNECTED-USERS
MSSQL-CONNECTION-TIME
MSSQL-CPU-BUSY
MSSQL-DATABASE-FREE
MSSQL-FULL-SCANS
MSSQL-IO-BUSY
MSSQL-LOCKS-DEADLOCKS

Mysql :

MYSQL-CONNECTION-TIME
MYSQL-OPEN-FILES
MYSQL-SLOW-QUERIES
MYSQL-UPTIME

le mode extended : à utiliser lorsque vous souhaitez une attention particulière sur une base de donnée. Outre les indicateurs du mode standard, vous y trouverez :

Oracle :

ORACLE-DATAFILES-EXISTING
ORACLE-ENQUEUE-CONTENTION
ORACLE-ENQUEUE-WAITING
ORACLE-EVENT-WAITING
ORACLE-EVENT-WAITS
ORACLE-FLASH-RECOVERY-AREA-FREE
ORACLE-FLASH-RECOVERY-AREA-USAGE
ORACLE-LATCH-CONTENTION
ORACLE-LATCH-WAITING
ORACLE-PGA-IN-MEMORY-SORT-RATIO
ORACLE-REDO-IO-TRAFFIC
ORACLE-RETRY-RATIO
ORACLE-ROLL-BLOCK-CONTENTION
ORACLE-ROLL-EXTENDS
ORACLE-ROLL-HEADER-CONTENTION
ORACLE-ROLL-HIT-RATIO
ORACLE-ROLL-WRAPS
ORACLE-SEG-TOP-10-LOGICAL-READS
ORACLE-SEG-TOP-10-PHYSICAL-READS
ORACLE-SEG-TOP-10-ROW-LOCK-WAITS
ORACLE-SGA-LATCHES-HIT-RATIO
ORACLE-SGA-LIBRARY-CACHE-GETHIT-RATIO
ORACLE-SGA-LIBRARY-CACHE-PINHIT-RATIO
ORACLE-SGA-LIBRARY-CACHE-RELOADS
ORACLE-SGA-SHARED-POOL-FREE
ORACLE-SGA-SHARED-POOL-RELOADS
ORACLE-SOFT-PARSE-RATIO
ORACLE-STALE-STATISTICS
ORACLE-SWITCH-INTERVAL
ORACLE-SYSSTAT
ORACLE-TABLESPACE-IO-BALANCE
ORACLE-TABLESPACE-REMAINING-TIME
ORACLE-TABLESPACE-USAGE

SQL Server :

MSSQL-BACKUP-AGE
MSSQL-BATCH-REQUESTS
MSSQL-FREE-LIST-STALLS
MSSQL-LATCHES-WAIT-TIME
MSSQL-LATCHES-WAITS
MSSQL-LAZY-PAGE-LIFE-EXPECTANCY
MSSQL-LAZY-WRITES
MSSQL-LOCKS-TIMEOUTS
MSSQL-LOCKS-WAITS
MSSQL-MEM-POOL-DATA-BUFFER-HIT-RATIO
MSSQL-SQL-INITCOMPILATIONS
MSSQL-SQL-RECOMPILATIONS
MSSQL-TOTAL-SERVER-MEMORY
MSSQL-TRANSACTIONS

Mysql :

MYSQL-CLUSTER-NDB-RUNNING
MYSQL-INDEX-USAGE
MYSQL-LONG-RUNNING-PROCS
MYSQL-SLAVE-IO-RUNNING
MYSQL-SLAVE-LAG
MYSQL-SLAVE-SQL-RUNNING
MYSQL-TABLE-LOCK-CONTENTION
MYSQL-TABLECACHE-HITRATE
MYSQL-THREADCACHE-HITRATE
MYSQL-THREADS-CONNECTED
MYSQL-TMP-DISK-TABLES

Evidemment, vous aurez toute latitude dans Centreon, pour affiner les services qui vous intéressent, ou pas.

Revenons à nos moutons … cliquons sur le bouton « Ouvrir CSV » du groupe « Databases »

Sélectionnons notre fichier CSV et cliquons sur « Ouvrir » :

Les trois bases de données (Oracle, Mssq, et Mysql) sont bien présentes. Il ne nous reste plus qu’à les sélectionner puis cliquer sur Importer.

A partir de ce moment, ces bases de données sont gérables dans Overmon. Pour autant, rien n’est encore visible dans Centreon.

Une étape reste à compléter : le déploiement des services associés. Rendez-vous pour ce faire sur l’onglet « Bases de données »

L’onglet « Bases de données »

Cet écran est concu pour vous permettre de déployer les services nagios de type bases de données.

Les plugins utilisés pour surveiller vos bases sont une production de Consol Labs, éditeurs des excellents plugins :

check_oracle_health
check_mssql_health
check_mysql_health

Les possibilités de ces plugins sont éprouvées. Leur mise en oeuvre, par contre, s’avère ardue. D’où l’intérêt de l’utilisation de Overmon dans ce cas.

Pour déployer les services, rien de plus simple. Sélectionnons les 3 bases de données, puis cliquons sur « Déployer dans centreon » :

A l’instar de ce qui s’est passé lors du déploiement des agents, la barre « K2000″ est de retour. Par contre, le temps nécessaire pour déployer s’avère bien plus court (quelques secondes suffisent par database).

Le résultat est immédiat :

Les bases sont maintenant sous surveillance.

Comme expliqué précédemment, les boutons « Mode Etendu » et « Mode Standard » permettent de switcher entre chacun de ces modes.

Le bouton « Supprimer de la liste » supprime les occurence de la liste, en conservant les infos dans nagios/centreon

Le bouton « Supprimer de Centreon », lui, supprimes les databases sélectionnées de la liste ET de nagios/centreon.

Nous en avons terminé avec nos bases de données. Mais notre système d’information ne se résume pas, loin s’en faut, à quelques services OS de base et une poignée de base de données.

On y trouve également des applications web.

L’onglet « Applications Web »

Cet écran a pour but de vous assister dans la mise en place d’une supervision de vos applications web, incluant authentification et parcours fonctionnel.

Une fois encore, pour ce faire, Overmon s’appuie sur une excellente production de chez Consol Labs : check_webinject

La liste « Scripts » contient l’ensemble des scripts webinjects prêts à utiliser. Dans la mesure où pour ce guide, nous utilisons l’OVS de notre cru, cette liste est déjà remplie avec deux scripts.

Sélectionnons le script « Overmon_new_version » et cliquons sur « Ouvrir script distant » :

Les deux fichiers(config et testcase) sont rapatriés sur notre poste et le fichier testcase est affiché pour édition dans la zone prévue à cet effet.

Là encore, ce guide n’est pas le lieu pour une formation exhaustive à Webinject. Pour ceux qui ne le connaissent pas, nous vous invitons à le décrouvrir ici.

Si on regarde en détail le contenu (assez simple) de ce script, il se compose de trois étapes :

Accès à la page d’accueil du site www.overmon.fr
Authentification sur le site avec le user : contact
Accès à la page des téléchargement (qui n’est disponible QUE pour les utilisateurs authentifiés) et vérification que la version en cours est la v6.46

Evidemment, il y a un piège … la dernière version en cours de Overmon est supérieure. Nous devrions donc obtenir un message d’erreur.

Voyons voir ca. Cliquons de suite sur le bouton « Lancer le test » :

Bingo ! Le script me retourne l’erreur attendue.

OK, ne touchons pas à ce script, et vérifions comment ca va se traduire au niveau de Centreon.

Pour cela, il nous faut au préalable déployer ce script dans Nagios.

Cliquons simplement sur « Ajouter dans Centreon » :

et allons ensuite vérifier le résultat :

Nickel, le service est bien créé, et genère l’alarme attendue.

De plus, ce services génère des graphes. Si l’on y regarde de plus près :

Les temps de réponse sont historisés non seulement pour le script dans son ensemble, mais également pour chacune des étapes.

Bien évidemment, si le graphes présenté ici est vide, c’est simplement parce que le service n’a pas encore eu le temps de collecter des données … étant donné qu’on vient tout juste de le créer !

A ce stade, mesurons le chemin parcouru … en moins d’une heure, nous avons :

déployé nos agents sur l’ensemble du parc
récupéré les inventaires sur toutes ces machines
déployé les services OS correspondant
implémenté une supervision de nos bases de données
placé nos sites web sous surveillance

Pas mal, non ?

C’est loin d’être terminé. Abordons maintenant un point crucial : le déploiement des sondes nagios.

L’onglet « Plugins »

Cet écran a pour objectif de vous permettre de réaliser un déploiement générique de sondes nagios

Déploiement « générique » … kézako ?

Il s’agit ni plus ni moins que de vous permettre de déployer en un temps record n’importe quelle sonde nagios sur votre parc.

Le process, que nous avons simplifié au maximum, est le suivant :

Exemple de départ : On vous demande d’implémenter de toute urgence une supervision de vos serveurs web. Dans ce scénario exemple, il s’agit de serveurs apache
A ce stade, vous ne savez pas comment procéder.
Vous vous rendez sur un market de sondes quelconque (nagios exchange, monitoring-exchange, autre), et vous tombez sur une sonde qui vous semble correspondre à votre besoin
Vous récupérez l’URL de la sonde, ainsi qu’un petit nombre d’informations qui vous permettent de créer une nouvelle entrée dans le fichier ini de l’OAT
Vous relancez l’OAT
Vous êtes prêts à déployer !

Simplissime, non ?
Entrons maintenant dans le détail des opérations.Comme je l’ai dit précédemment, tout est piloté par le fichier ini de l’OAT.Dans le cas de la sonde check_apache2 qui nous sert d’exemple, jetons un oeil sur l’entrée correspondante dans le fichier OvermonPlugins.ini :

[Plugin check_apache2]plugintype=Web Serverhosttype=Unixfilename=check_apache2.shcommandname=check_apache2servicetemplatename=APACHE-STATUSservicename=APACHE-STATUSpluginurl=http://exchange.nagios.org/components/com_mtree/attachment.php?link_id=619&cf_id=24iconurl=http://thrift.apache.org/static/images/favicon.icohelpurl=http://exchange.nagios.org/directory/Plugins/Web-Servers/Apache/check_apache2-2Esh/details--hostname=localhost--port=80--warning-req=100--critical-req=250

Analysons maintenant ce contenu :

Toute section dans le fichier ini de l’OAT commencant par « [Plugin » est considérée comme une sonde.
Toutes les entrées sont obligatoire, à l’exception de celles commencant par « –« , ou « -« , et qui sont des arguments de la sonde.
plugintype définit le type de plugin. Les types existant pour l’instant sont « Cluster », « Database », « Network », « Others », « System », et « Web Server ». Ce modèle sera enrichi ultérieurement. Une sonde ne peut être définie en dehors de ces types, sous peine de ne pas être reconue par l’OAT.
hosttype définit le type de host sur lequel peut être appliqué la sonde. Il existe deux types qui sont « Windows » et « Unix ». Là encore, il n’est pas possible de saisir un autre type. Pour les linux, utilisez « Unix ».
filename spécifie le nom du fichier. Si nécessaire, il sera automatiquement téléchargé, puis placé dans <OAT_DIR>\Plugins.
commandname est le nom de la commande qui sera éventuellement créée.
servicetemplatename est le nom du service template qui sera créé.
servicename est le nom du service qui sera créé.
pluginurl est l’URL qui sera utilisée pour télécharger la sonde, en cas de besoin.
iconurl est l’URL qui sera utilisée pour télécharger un icone associé à la sonde. Si ce champs est vide, alors c’est l’icon du plugintype qui sera utilisé
helpurl est l’URL qui sera utilisée pour proposer l’aide en ligne sur la sonde
toutes les entrées commencant par « — » ou « – » sont les arguments à passer à la sonde. Chaque sonde étant unique, il faudra donc consulter l’aide associée pour déterminer quels arguments utiliser en fonction de ses besoins

Dès lors que ces informations sont correctement saisies, il suffit de redémarrer l’OAT pour que la sonde soit prise en compte.Le déploiement est alors enfantin : il suffit de sélectionner la sonde, puis les cibles à atteindre. Cliquer sur « Ajouter dans Centreon », et le tour est joué !
Notez que vous pouvez à tout moment supprimer des services que vous auriez déployé à tort, via des menus contextuels.
Seules deux sondes sont embarquées par défaut, dans le but de vous servir de modèle (une sonde windows, l’autre unix), mais vous pouvez vous rendre dans notre « Bibliothèque de sondes », dispo ici, et qui centralise les productions de la communauté en la matière.
N’hésitez pas à y publier vos créations !

Bien …

Il nous reste le plus long, le plus complexe … traiter le spécifique.

Le « spécifique », … vous savez ? ce qui fait que votre entreprise est unique au monde ! Tous ces à-cotés, ces logiciels développés « maison », ces process dont vous seuls connaissez les méandres et qu’aucune solution de supervision du marché n’a su prendre en compte ?

Overmon ne prétend pas traiter votre spécifique d’un coup de baguette magique.

Il n’y a pas de solution miracle :

Face à un logiciel développé maison, vous devrez mettre en place un, ou plusieurs scripts de supervisions que vous aurez vous même développé.
Face à un workflow particulier, vous devrez là encore développer des scripts qui iront en contrôler l’état à chaque étape
etc …

Néanmoins, Overmon peut (sensiblement) vous aider dans le développement de ces scripts spécifiques, grâce à son « laboratoire ».

Cliquons sur « Développer » pour voir de quoi il en retourne.

L’onglet « Développer »

Cet écran a pour put de vous assister lorsque vous entreprenez d’écrire des sondes (plugins) Nagios spécifiques.

Analysons cet écran :

La liste « Plugins » contient l’ensemble des plugins qui sont déjà à votre disposition. Pour ce guide, nous utilisons l’OVS édité par Overmon. Vous vous retrouvez donc avec 173 plugins de base !
La zone « Contenu du script », comme son nom l’indique, contient le script à éditer.
La « Zone de test » contient d’une part les 10 arguments que vous pourrez passez à votre script, et deux boutons de tests d’autre part. Le bouton « Tester sur OVS » testera votre script sur votre OVS. Quant au bouton « Tester sur une machine distante », il vous permettra de pousser votre script sur la machine cible pour effectuer le test directement dessus (gain de temps appréciable, non ?).
La liste « Equipements dans Overmon » contient l’ensemble des machines que vous avez importé dans Overmon précédemment.
La zone « Log distante » affichera les résultats des éventuels tests de script que vous mènerez
Le bouton « Ouvrir script distant » permet d’ouvrir un script pré-existant sur votre OVS
Le bouton « Ouvrir script local » permet d’ouvrir un script sur votre station de travail
Le bouton « Vider » permet de vider la zone de contenu du script
Le bouton « Modèles » permet d’accèder à des modèles de scripts. Ils sont trois à ce jour : un modèle bash, un perl, et un cmd (pour les machines windows). D’autres viendront dans des versions ultérieures
Le bouton « Sauver » permet de sauvegarder le script sur l’OVS
Le bouton « Ajouter dans Centreon » permet de créer les services directement pour les machines distantes que vous aurez sélectionné

Commencons par utiliser un modèle de script Windows.

Cliquons sur « Modèles » :

Sélectionnons le modèle « check_sample_cmd_fr » et cliquons sur « Ouvrir » :

La zone de script s’est remplie à partir du modèle sélectionné. Notez qu’à ce moment précis, le bouton « Ajouter dans Centreon » se grise. Cela est dû au fait que le script n’est pas encore sauvegardé.

Notez également qu’en haut à droite de la zone de script, on trouve deux pseudo-icones de flèches montantes et descendantes, qui permettent d’agir sur la taille de la zone d’édition du script :

Ca ne vaut pas Eclipse, c’est clair, mais bon … c’est mieux que rien … ;o)

Chacun des trois modèles de scripts embarqués dans l’OAT respectent les normes de nagios. Ils sont prêts à l’emploi.

Tout ce que vous avez à faire est de compléter la partie « spécifique » du modèle (facilement localisable) en y ajoutant vos propres commandes.

Pour les besoins de ce guide, nous allons nous contenter d’utiliser les commandes par défaut.

Et part défaut, ces modèles attendent trois arguments :

arg1 : une valeur que nous fixons arbitrairement
arg2 : une valeur de seuil qui déclenche une alarme WARNING
arg3 : une valeur de seuil qui déclenche une alarme CRITICAL

Allons-y …saisissons les valeurs 10, 50 et 100, puis sélectionnons une machine distante Windows (Attention à ne pas sélectionner une machine Unix/Linux).

Enfin, cliquons sur « Tester sur une machine distante » :

Heyyyyy, pas mal !!!

Le script me retourne bien la valeur 10 qui correspond à l’arg1. Et le statut est bien OK, ce qui est normal, étant donné que 10 < 50 qui est le seuil de warning.

testons maintenant le seuil de warning, justement, en modifiant la valeur de l’arg1.

On la positionne à 60 et on relance le test :

De mieux en mieux !

Le statut est bien passé à WARNING.

Allez … je vous vois venir … vous mourrez d’envie de tester le statut CRITICAL. Rien de plus simple : passons maintenant la valeur de l’arg1 à 120, puis relancons le test :

C’est parfait.

Une fois que nous somme satisfait de notre script, nous n’avons plus qu’à le sauvegarder en cliquant sur « Sauver » :

On nous demande le nom du script à sauvegarder. ATTENTION : le nom doit respecter une certaine syntaxe :

Il doit commencer par check_
Il doit se terminer par l’extension correcte

Nommons ce script « check_test_pour_le_guide.cmd » et cliquons sur OK :

Le script a bien été sauvegardé, et ajouté dans la liste de gauche. En outre, le bouton « Ajouter dans Centreon » est dorénavant actif.

Profitons en pour appliquer maintenant ce script une de nos machines windows distantes. Pensez bien, avant, à renseigner les valeurs des trois arguments, faute de quoi, vous obtiendrez forcément une alarme.

Sélectionnons SAMPLE-XP-01, puis cliquons sur « Ajouter dans Centreon » :

La fameuse barre de progression « K2000″ se remet en branle, et au bout de quelques secondes, je suis informé que le déploiement est terminé.

Allons vérifier immédiatement dans Centreon :

C’est OK !

Les services ont bien été créés pour les machines sélectionnées.

En y regardant de plus près :

on remarque qu’Overmon utilise des macros pour implémenter ce type de plugins.

Le système est strictement identique pour les machines Unix/Linux, sauf que vous avez à votre disposition deux modèles disponibles (bash et perl) selon votre convenance.

Voilà pour le développement des sondes spécifiques.

Abordons maintenant un sujet délicat : Comment procéder si le déploiement des agents pose problème dans votre entreprise.Vous devez apporter des modifications dans certains scénarios de déploiement.

Cliquons sur « Scénarios »

L’onglet « Scénarios »

Cet écran à pour but de vous permettre d’adapter les scénarios de déploiement aux contraintes de votre entreprise :

La liste « Scénarios » contient l’ensemble des scénarios utilisable par Overmon. Notez la colonne « links ». Elle contient le nombre de modèles de host Nagios qui utilisent ce scénario. Ce nombre doit TOUJOURS être supérieur à 0, sans quoi vous avez la certitude que le scénario correspondant ne sera jamais utilisé.
La liste « Modèles de hosts », vous présente ces modèles de host, tels qu’ils sont définis dans Nagios/Centreon

Les scénarios sont de simples fichiers textes qui sont localisés dans <OATDirectory>\Scenarios

Le nom des scénarios doit respecter une syntaxe précise pour être utilisé :

Il doit commencer par « install-agents » pour être considéré comme un scénario d’installation d’agent.
Il doit commencer par « remove-agents » pour être considéré comme un scénario de désinstallation d’agent.
Le texte suivant « install-agents- » ou « remove-agents- » sera utilisé pour localiser les prébuilds dans <OATDirectory>\Agents\Prebuilds.

Par exemple, si le scénario porte le nom « install-agents-Servers-Linux-Debian.sh », alors il s’agit d’un script d’installation d’agent, et la prébuilt sera récupérée dans <OATDirectory>\Agents\Prebuilds\Servers-Linux-Debian

A chaque fois que vous sélectionnerez un scénario :

Overmon affichera la liste des Host templates liés.

Les scénarios peuvent être édités directement via l’éditeur interne proposé, ou à travers un editeur texte de votre choix.

L’onglet « Administrer »

Cet écran d’administration se compose de deux parties :

L’administration générale

Cette partie de l’écran vos donne accès à certaines informations provenant de votre OVS :

Quel est son mode réseau (ip statique ou dhcp)
Hostname et IP en vigueur
Votre OVS est-il référencé dans votre base DNS ?
Statut des principaux composants de Overmon (Mysql, Apache, Nagios, etc …)

Sous réserve que le script shell « overmon » soit présent sur votre OVS, vous pourrez ici effectuer un certain nombre d’actions simples, telles que :

Démarrer, Arrêter, Redémarrer les services de Overmon (Mysql, Apache, Nagios, Ndo2db, Centstorage, Centcore, NRPE)
Statuer sur l’état de ces services
Purger les logs

Le tuning de Overmon

Regardez en bas à droite de votre application Overmon.

La signalétique peut prendre deux formes différentes :

Dans le premier cas, les paramètres sont corrects, et vous avez accès à l’ensemble des fonctionnalités de Overmon

Dans le second, par contre, vous êtes en mode limité, du à une erreur dans le paramétrage, ou à l’absence de certains composants éxigés par Overmon.

Dans le cas où vous seriez en mode limité, vous devrez utiliser la liste nommée « Tuning ».

Cette liste présente en fait les composants nécessaires au bon fonctionnement de Overmon. Vous parviendrez au mode « full » de Overmon lorsque TOUS ces composants sont au vert.

Là encore, vous allez être accompagné. Cliquez sur un composant en rouge, et cliquez sur « Résoudre le problème ». A partir de ce moment, il peut se passer deux choses :

Overmon sait résoudre le problème automatiquement et vous propose de le faire. Par exemple, si vous utilisez votre propre installation Nagios/Centreon/Glpi, Overmon vous proposera ici de créer automatiquement la base de données « overmon » dont il a besoin pour fonctionner.
Overmon ne sait pas résoudre le problème automatiquement. Dans ce cas, il vous proposera un accès à une aide en ligne qui vous permettra de vous en sortir :

L’onglet « Options »

Cet écran vous permet de modifier les valeurs des différentes variables de l’OAT.

Une modification des valeurs présentes ici se traduira par leur répercution dans les différents fichiers .ini nécessaires au bon fonctionnement de l’OAT.Il convient donc de les manipuler avec précaution (dans la plupart des cas, il faudra redémarrer l’OAT pour que les modifications soient prises en compte)