Télécharger sous forme de PDF

1. Introduction

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

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

Un couple user/password unique a été défini sur l’ensemble des composants de Overmon Server : overmon/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 ».

2. 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 ci-dessous.

Guide d’installation

3. 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

Que la fête commence !

4. 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 »

4.1 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é :

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.

A titre d’information, les types utilisable directement aujourd’hui, si vous utilisez notre OVS sont :

• Servers-Linux-CentOS-NRPE
• Servers-Linux-CentOS-SSH
• Servers-Linux-Debian-NRPE
• Servers-Linux-Debian-SSH
• Servers-Linux-RedHat-NRPE
• Servers-Linux-RedHat-SSH
• Servers-Linux-Suse-NRPE
• Servers-Linux-Suse-SSH
• Servers-Linux-Ubuntu-NRPE
• Servers-Linux-Ubuntu-SSH
• Servers-Unix-Solaris-i386-NRPE
• Servers-Unix-Solaris-NRPE
• Servers-Unix-Solaris-Sparc-NRPE
• Servers-Unix-Solaris-SSH
• Servers-Win2K-NRPE
• Servers-Win2K-SNMP
• Servers-Win2K-WMI
• Servers-Win2K3-NRPE
• Servers-Win2K3-SNMP
• Servers-Win2K3-WMI
• Servers-Win2K8-NRPE
• Servers-Win2K8-SNMP
• Servers-Win2K8-WMI
• Workstations-Win7-NRPE
• Workstations-Win7-SNMP
• Workstations-Win7-WMI
• Workstations-WinXP-NRPE
• Workstations-WinXP-SNMP
• Workstations-WinXP-WMI

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 ». Ca y est : nos machines ont été englouties  !

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

Retournons donc maintenant sur l’onglet « Déployer »

4.2 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 11 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 4 modes d’installation :

• Scénario s’oppose à Autogeneration : Dans le premier cas (à privilégier), le déploiement s’effectuera selon un scénario « ouvert » qui se présente sous la forme d’un fichier plat. Dans le second cas, c’est  l’OAT lui même qui effectuera le déploiement de manière rigide, selon ses algorithmes propres. Ce mode « Autogeneration » n’est maintenu que pour assurer une compatibilité avec d’anciennes installations de Overmon.
• Prébuild s’oppose à Compilation : Dans le premier cas, les agents sont installés sous forme pré-compilée et simplement déposés sur vos machines cibles. Dans le second cas, 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.

Le mode debug permet d’afficher les détails de l’opération au moment du déploiement

Enfin, il est possible de générer un fichier d’import Centreon, dans le cas où on souhaiterait importer le host dans Centreon ultérieurement.

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 récupérer à la volée les prébuilds nécessaires, pour ensuite procéder au déploiement lui même.

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 … 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 :

• 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 :

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 »

4.3 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.

4.4 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 :

1. Accès à la page d’accueil du site www.overmon.fr
2. Authentification sur le site avec le user : contact
3. 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.

4.5 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 !

[Plugin check_apache2]
plugintype=Web Server
hosttype=Unix
filename=check_apache2.sh
commandname=check_apache2
servicetemplatename=APACHE-STATUS
servicename=APACHE-STATUS
pluginurl=http://exchange.nagios.org/components/com_mtree/attachment.php?link_id=619&cf_id=24
iconurl=http://thrift.apache.org/static/images/favicon.ico
helpurl=http://exchange.nagios.org/directory/Plugins/Web-Servers/Apache/check_apache2-2Esh/details
--hostname=localhost
--port=80
--warning-req=100
--critical-req=250

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.

4.6 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 sur deux 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-AD et 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 »

4.7 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.

4.8 L’onglet « Administrer »

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

4.8.1 Le tuning de Overmon

Regardez en bas à droite de votre application Overmon.

Deux cas de figures sont possibles :

• : Les paramètres sont corrects, et vous avez accès à l’ensemble des fonctionnalités de Overmon
• : 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écessaire 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 :

1. Overmon sait 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.
   
2. 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
   

4.8.2 L’administration générale

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

Depuis la version 7.6.1, vous avez également la possibilité de mettre à jour l’OVS directement depuis l’OAT.

Cliquez simplement sur le bouton « Mettre à jour ».

A ce moment là, L’OAT demandera à l’OVS de se synchroniser avec le dépôt github automatiquement :

Au terme de la mise à jour, un (long) message vous informera que dans le cas d’une montée de version GLPI ou Centreon, vous devrez compléter la mise à jour avec quelques actions manuelles fort simples :

• Se connecter sur les interfaces Centreon et/ou GLPI, pour déclencher la mise à jour de la structure de la base de donnée
• Eventuellement, réactiver les plugins GLPI

Overmon Admin Tools : git://github.com/highfeeling/OvermonAdminTools.git

Vous avez le libre choix de l’outil à utiliser pour récupérer les derniers commits de l’OAT. Tout client git fera l’affaire :

• TortoiseGit
• Github for Windows
• autres …

Ces deux dépots, pour plus de commodités, sont même accessibles directement depuis la forge Overmon

Le dépot pour Overmon Server, est accessible ici :

Le dépot pour Overmon Admin Tools, accessible ici :

 

4.9 L’onglet « Sauvegarder »

Comme son nom l’indique, cet onglet sert simplement à sauvegarder votre OVS. Il utilise pour ce faire backup-manager

Son utilisation est on ne peut plus simple, puisque trois actions figurent simplement au menu :

• Créer une nouvelle sauvegarde : outre la sauvegarde elle même, les fichiers sont rapatriés automatiquement en local sur votre poste, dans <OATDirectory>\Backups
• Restaurer un fichier de sauvegarde
• Supprimer une sauvegarde locale