Centreon

Avec Centreon, les collaborateurs de cette entreprise du transport ferroviaire sont en mesure de déterminer rapidement les points de blocage dans leur SI et de gagner ainsi un temps précieux. " En dernier lieu, il ne manquait plus qu’une ... [More] assistance technique pour la gestion de certains points comme la métrologie du SAN ou l’utilisation d’un plugin plus élaboré pour les serveurs ESX. Ce fut fait, il y a quelques mois, avec la venue d’un intervenant MERETHIS. Cette aide précieuse nous permit de mieux appréhender les flux SAN lors de notre migration de sauvegarde et même de détecter des fonctionnements anormaux avec la cartographie de Centreon Map." Rattaché à une cellule informatique locale au sein d’un établissement financier d’une entreprise ferroviaire, je suis responsable de la maintenance opérationnelle d’un datacenter et de l’infrastructure réseau du bâtiment. L’exigence très forte de nos clients internes, la complexité de notre SI national et les nombreux intervenants informatiques nous ont amenés à trouver une solution de monitoring. Notre principale problématique étant de déterminer les points de blocage afin d’informer nos clients internes au plus vite. La solution Nagios/Centreon a été choisie pour sa modularité dans un environnement hétérogène, sa facilité d’installation, ses nombreux plugins. De plus, l’interface graphique de Centreon nous a permis d’accélérer le transfert de compétence de nos collaborateurs. Volumétrie et nature des systèmes concernés : Nous supervisons environ 150 hôtes associés à 760 services comprenant le Datacenter VMware, un SAN et NAS EMC, une architecture iSCSI, l’architecture LAN et plusieurs hôtes sur sites distants pour les besoins de diagnostics. L’intérêt de notre architecture distribuée nous permet de limiter le polling sur les routeurs de niveau 3 en dédiant un poller à chaque sousréseau. Nous utilisons un serveur Syslog ainsi que son module associé pour Centreon afin de centraliser tous les logs (ESX, Brocade, Linux, etc.). Nous avons rajouté les événements de nos serveurs Windows grâce à l’extension CentreonE2S. Nous avons gagné un temps précieux pour la surveillance des logs de serveurs. Quels étaient les besoins de votre organisation en matière de supervision et quels étaient les enjeux de ce projet ? Mon intérêt pour la supervision informatique est une longue histoire. Issu de la signalisation ferroviaire et connaissant déjà les problématiques de dysfonctionnements complexes ne pouvant se résoudre qu’avec des enregistreurs et des appareils de mesure, mes premiers projets informatiques se sont axés sur des solutions de monitoring du système d’information. Il n’y a rien de plus désagréable que d’être informé d’une panne informatique sur un serveur, par exemple, par vos utilisateurs. J’ai donc débuté avec Netsaint devenant Nagios. Mais sa configuration est laborieuse à mettre en place en ligne de commande. Très vite, j’ai cherché une solution d’interface graphique et tout naturellement mon choix s’est arrêté sur un projet prometteur s’appelant Oréon… Je veux parler, bien sûr, de Centreon qui deviendra mon choix de prédilection. Le challenge, dans l’équipe informatique actuelle, a été de proposer une solution de supervision la moins intrusive possible et d’améliorer les tâches de maintenance courante. Le choix s’est naturellement dirigé vers une solution libre Nagios avec Centreon. Nous avons commencé par un serveur Central puis au fur et à mesure du nombre de points de service créés, notre architecture s’est enrichie d’un satellite et d’un serveur Syslog, ainsi qu’un système « failOver » pour nous alerter en cas de défaillance du serveur Central. Actuellement, notre supervision fonctionne en architecture distribuée sous environnement VMware. Ce choix a été motivé par la souplesse, la sécurisation procurée par un Cluster d’ESX et aussi par la configuration monosite de notre organisation. Nous avons même détecté des incidents de sécurité qui nous aurait échappé auparavant. Durant la première année d’exploitation de notre supervision, nous avons amélioré nos investigations sur les dysfonctionnements rencontrés par nos utilisateurs. De nouveaux plugins maison ont vu le jour pour gérer les tâches quotidiennes telles que les Quotas sur les baies EMC. La gestion des ACL dans Centreon a permis l’accès à la supervision à toute l’équipe informatique sans risque de sécurité. Globalement, quel bilan pouvezvous faire de votre utilisation de Centreon ? Le pari était gagné, l’équipe s’est approprié l’outil et avec l’aval de mon responsable, nous avons décidé de passer à la vitesse supérieure. Dans un premier temps, la formation Méthodologie et administration d’une plateforme de supervision Centreon dispensée par la société Merethis m’a permis de rationaliser la gestion de la configuration et de consolider mes bases acquises aux cours de mes expériences précédentes. Cerise sur le gâteau, j’ai obtenu la certification 101 à la suite de cette formation. L’acquisition de Centreon Map consolide l’expérience utilisateur pour nos collaborateurs, la recherche d’équipements en défaut est beaucoup plus intuitive. Ce module, par rapport à Nagvis, est plus interactif et ne nécessite pas les nombreuses saisies de cartographies lors des modifications d’équipements. Globalement, l’outil Centreon et ses nombreuses extensions nous donnent entièrement satisfaction, il y a une bonne émulation et les développeurs sont réactifs aux questions et bugs soulevés, pour preuve les nombreuses évolutions du produit. Le support Centreon est une bonne opportunité lorsque l’on veut faire avancer un projet plus rapidement. Avezvous reçu le soutien des équipes de MERETHIS, sous quelle forme, et quel est votre sentiment ? En dernier lieu, il ne manquait plus qu’une assistance technique pour la gestion de certains points comme la métrologie du SAN ou l’utilisation d’un plugin plus élaboré pour les serveurs ESX. Ce fut fait, il y a quelques mois, avec la venue d’un intervenant MERETHIS. Cette aide précieuse nous permit de mieux appréhender les flux SAN lors de notre migration de sauvegarde et même de détecter des fonctionnements anormaux avec la cartographie de Centreon Map. Le futur sera l’intégration de CentreonBroker et certainement une solution complète Centreon avec CentreonEngine… c’est une autre histoire ! Vous pouvez télécharger l'intégralité de l'interview sur le site de Merethis. [Less]

Sortie de Centreon Engine 1.3.0Cette nouvelle version se caractérise par l'ajout des connecteurs. Le but principal de ces démons (programmes lancés une fois et tournant en tâche de fond) est de fournir un meilleur cadre d'exécution pour les plugins. ... [More] On trouvera par exemple :•    Le connecteur SSH : ce composant est un multiplexeur de connexions. Il permet à la fois de réduire de nombre de connexions ouvertes et de les rendre persistantes•    Le connecteur Perl : ce composant embarque un interpréteur Perl et permet (entre autre) d'améliorer les performances liées à l'exécution des plugins écrits en PerlLes autres évolutions notables sont les suivantes :•    Remplacement de la bibliothèque Qt par centreon-clib et libxerces (pour la partie XML)•    Quelques correctionsLe changelog détaillé (et techique) est disponible à cette adresse : http://forge.centreon.com/projects/centreon-engine/versions/133 Sortie de Centreon Broker 2.2.1Cette nouvelle version améliore les performances globales grâce à l'utilisation de transactions SQL. Le principe des transactions consiste à grouper les requêtes pour générer moins d'entrées/sorties sur le serveur. Lors de l'utilisation des transactions, les requêtes exécutées affectent une copie virtuelle de la base de données. Ce n'est qu'à la fin de l'opération que les données sont effectivement écrites sur le disque et accessibles aux autres utilisateurs. Ce mécanisme permet de réduire drastiquement les entrées/sorties sur le support de stockage.Les autres évolutions notables sont les suivantes :•    Non-traitement des statuts de hôtes/services trop anciens (next_check < now)•    Nouveau module de statistiques pour récupérer des informations telles que les modules chargés, la vitesse de traitement, l'état des connexions, etc.•    Désactivation du signal SIGCHLD (moins d'allers-retours espace noyau/espace utilisateur)•    Fichiers de log circulaires (limitation de l'utilisation disque)•    Possibilité d'écriture des logs de cbmod directement dans les logs de Engine/Nagios•    Désactivation possible de la synchronisation des logs sur le disque (appel système *sync*)•    Enregistrement décalé des callbacks avec Engine/Nagios (temps de démarrage réduit)Le changelog détaillé (et technique) est disponible à cette adresse : http://forge.centreon.com/projects/centreon-broker/versions/160 ------------------------------------------------------------------------------------------------------------ Release of Centreon Engine 1.3.0This new version implements a key feature, the use of connectors. The main purpose of these daemons (programs that are run in background) is to provide better execution context to the check plugins. For instance:•    SSH connector: this component is a connection multiplexer. It offers the reduction of open connections and it also makes them persistent•    Perl connector : this component embeds a Perl interpreter and somewhat enhances the execution performances of plugins written in PerlThe other noticeable features are the following:•    Replacement of the Qt library by centreon-clib and libxerces (for the XML part)•    A few fixesThe detailed (technical) changelog is available at this URL: http://forge.centreon.com/projects/centreon-engine/versions/133 Release of Centreon Broker 2.2.1This new version enhances overall performances thanks to the implementation of SQL transactions. Basically, the concept of these transactions is to group queries in order to generate less input/output on the server. When transactions are used, the executed queries affect a virtual copy of the database. It is only at the end of this operation that data is actually written in the disk and  made accessible to users. This mechanism highly enhances the input/output situation of the storage device.The other noticeable features are the following:•    Non-process of host/service statuses that are too old (next_check < now)•    New statistics module for retrieving information such as the list of loaded modules, processing speed, connection status, etc...•    Deactivation of the SIGCHLD signal (less back and forth signals between kernel-space and user-space)•    Rotation of log files (for limiting storage issues)•    Possibility to write cbmod logs directly in the Centreon Engine/Nagios logs•    Possibility to disable log synchronization on the disk (*sync* system calls)•    Stalled callbacks with Centreon Engine/Nagios (lesser restarting time)The detailed (technical) changelog is available at this URL: http://forge.centreon.com/projects/centreon-broker/versions/160 [Less]

La communauté Centreon a participé activement à finaliser la traduction de l’interface web pour nous fournir une version 100% complète pour les versions 2.3.x de Centreon. La traduction des bulles d’aide, dans les formulaires de configuration ... [More] , atteint elle les 60% de complétion. Un paquet RPM sera bientôt à votre disposition sur le dépôt CES afin de bénéficier de ces travaux. Il est également possible de télécharger les fichiers de traduction à partir du site Centreon Translation. Il est possible à toute personne de participer aux traductions de Centreon dans plusieurs langues tel que l’Allemand, le Chinois, l’Italien, le Portugais et bien d’autres ! Il suffit de posséder un compte sur le site d’authentification de Centreon et de proposer vos traductions via notre plate-forme de traduction Centreon. Un grand merci aux différents acteurs pour leur travail : benoitp, Hellnino18, jmathis, lpinsivy, nitroz44, Zargos, et tous les autres bien sûr ;) ------------------------------------------------------------------------------------------------------------------------- The Centreon community has been actively involved in finalizing the web interface’s translation to provide a 100% complete translation in French for v2.3x Centreon. The help bubbles in the configuration form, have reached a 60% completion rate. A RPM package will soon be available on the CES repository. You can download the translation files from Centreon Translation’s website as well. Each one of you can participate in several Centreon’s translation such as German, Chinese, Italian, Portuguese and many others! You just need to create an account on Centreon’s website and share your translations through our translation platform Centreon. A big thank you to all people who helped us: benoitp, Hellnino18, jmathis, lpinsivy, nitroz44, Zargos and of course, all of you ;) [Less]

De nombreux utilisateurs répugnent ou se décomposent à l’idée de devoir modifier les arguments des commandes de Centreon. Et on ne peut pas vraiment leur donner tort ; qui a envie de devoir retenir ce que signifient des arguments aussi abscons que ... [More] $ARG1$ , $ARG2$... Voici une méthode simple qui vous permettra, en utilisant des macros personnalisés d’écrire facilement nos commandes et surtout de retenir/comprendre les arguments utilisés. ----------------------------------------------------------------------------------------------------------------------- When you need to write or modify a command in Centreon, you sometimes come across unclear arguments such as $ARG1$ , $ARG2$... No need to say that we all hate them since there is no way we can remember them clearly. We’d like to share with you a pretty simple method to help you write commands and remember/understand the arguments by using custom macros. Quick reminder on “standard” command writing Basically, when a user defines a command in Centreon, he has to define all arguments that are linked to this command. These arguments are called “standard macro” and are shortened « $ARG1$ » for the first argument, « $ARG2$ » for the second one, etc. The user can define these macros in a service template or for a specific service. For example, you can create a command that monitor available disk space on Linux partition: What we’d like to show in the screenshot is the “line command” part that writes: $ARG1$, $ARG2$, $ARG3$, $ARG4$, $ARG5$. Here, a user defines the arguments related to the command in any order. The main issue is that these arguments are not really understandable: what does $ARG1$ mean? And $ARG2$??? In this particular case, no user can understand the meaning of these arguments if he doesn’t know the monitoring check « check_centreon_snmp_remote_storage ». Examples in a command argument With every version of Centreon, we’ve been trying to solve this problem. A first option is that the user can define an argument example. For instance, in the previous screenshot, the example is: !/!80!90!$USER2$!1 This example can be used in a service template or for specific services. The user chooses a command and defines command arguments by this syntax. The main issue is that this syntax is pretty difficult to use. The user has to write a first exclamation point, then the first argument and then, another exclamation point and a second argument, etc. To make this clear, we can explain the syntax this way: «one argument ==one exclamation point. Two arguments == two exclamation points. N arguments == N exclamation points. ». Even if it looks easy to understand the way it works, it is not that easy to understand when you have to read one, or explain a command to someone else and worse, to check if the syntax is correct! When an error is found in the configuration generation, the user has to check carefully each argument, exclamation point by exclamation point… The description in a command argument Another option is the possibility to give your argument a description when you create a command. In the first screenshot, arguments are detailed in « Argument descriptions » : ARG1 : warning ARG2 : critical ARG3 : path, partition ARG4 : community ARG5 : SNMP version When the user chooses a command, the description of argument is used to define a service or to define a service template. The good point is that Centreon automatically creates the command line based on the arguments created by a user. The weak point is that he doesn’t write the description of arguments. Moreover, if he enters only one argument, the command doesn’t work. Indeed, the user would have to enter and maintain a common macro to all host services... which is more than complex. For example, the port of a DBMS can be written only once and its value can be the same for all monitoring services in this database… The third solution allows the user to go further and to be more precise: it is the custom macros. Custom macros Custom macros are defined in the Centreon command and then, their value is put in a host or service templates, or a specific host or service. Below the example of a command written with custom macros : The most important part in this screenshot is highlighted in red: The user defines his own macros, which is made possible by: prefixing the macro by $_ (dollar sign immediately followed by underscore sign) prefixing the macro by -HOST to define a macro on host or host template -SERVICE to define a macro on service or service template Defining explicitly the macro’s name : WARNING for example Finishing the macro with $ (dollar sign). In the example above, we defined 2 custom macros of hosts (SNMPCOMMUNITY and SNMPVERSION) and 3 custom macros of services (DISK, WARNING and CRITICAL). The macros of hosts SNMPCOMMUNITY and SNMPVERSION are automatically filled by Centreon when the user defines a community SNMP and a version SNMP for a host. The macros of services have to be defined on service or a service template: To sum it up, this is why you should use custom macros: They are clearly defined with a meaningful name chosen by the user (WARNING, MYSQLPASSWORD, NRPETCPPORT...); The legacy between service template and service is more flexible : for example, a service template can define one custom macro and let service defining the others; The overwriting of one macro is possible; A custom macro which is defined on a host can be shared by several services. You can use it to define, for example, some identical arguments on host, independently of the service. The main use case is the user name and password to connect to an application when this application is monitored by several services. An example: there are 10 services which monitor MySQL. The user name MySQL, the password and the port MySQL are all in custom macros of hosts. But, the database name is in a custom macro of service. We hope all this explanation help you understand and manage custom macros! -------------------------------------------------------------------------------------------------------------------------- Rappel sur l’écriture des commandes Lorsque l'utilisateur définit une commande dans Centreon, il doit définir des arguments à cette commande. Ces arguments sont appelés « macro standards » et sont nommés « $ARG1$ » pour le premier argument, « $ARG2$ » pour le second et ainsi de suite. Ces macros sont ensuite définies dans les modèles de service ou dans un service. Exemple : l'utilisateur crée une commande supervisant l'espace disque disponible sur une partition Linux : L'important dans cette capture d'écran est à « Ligne de commande » : $ARG1$, $ARG2$, $ARG3$, $ARG4$, $ARG5$. Ces arguments sont définis par l'utilisateur, dans l'ordre qu'il souhaite. La limite est que ces éléments sont très peu lisibles : à quoi correspond $ARG1$ ? Et $ARG2$ ? Et les autres ? Sans connaître la sonde de supervision « check_centreon_snmp_remote_storage », il est impossible de le savoir. C'est la principale limite de ce mode de fonctionnement : le manque de lisibilité. Les exemples d’arguments Centreon, au fil des versions successives, a remédié à ce problème. Tout d'abord, Centreon permet de définir un exemple d'arguments. Dans la capture d'écran précédente, l'exemple est : !/!80!90!$USER2$!1 Cet exemple peut ensuite être réutilisé dans les modèles de service et les services. L'utilisateur choisi une commande et défini les arguments de la commande par cette syntaxe. Cette syntaxe très rigide est très complexe à utiliser: il faut d'abord placer un premier point d'exclamation puis le premier argument puis encore un point d'exclamation puis le second argument et ainsi de suite. Lors des formations que nous donnions, il nous arrivait d'expliquer au stagiaire : « un argument == un point d'exclamation. Deux arguments == deux points d'exclamation. N arguments == N points d'exclamation. ». Même si cela parait très simple, c’est très complexe. Tant à comprendre qu'à expliquer, mais surtout à vérifier : lorsqu'une erreur est remontée à la génération de la configuration, il faut vérifier chaque argument consciencieusement en s'assurant que tous les points d'exclamation sont présents, que les arguments sont saisis dans le bon ordre, que l'on a pas mis deux points d'exclamation au lieu d'un seul, … Les descriptifs d’arguments Une autre solution a été mise en place par Centreon : la possibilité de définir un descriptif des arguments dès la saisie de la commande. Dans la première capture d'écran, les arguments sont détaillés dans la partie « Argument descriptions » : ARG1 : warning ARG2 : critical ARG3 : path, partition ARG4 : community ARG5 : SNMP version Cette description est reprise ensuite lors de la définition du service ou du modèle de service lorsque l'utilisateur choisit la commande : Centreon construit alors automatiquement la ligne composée des arguments saisis par l'utilisateur. Lors de la création de la commande, il est possible que l'utilisateur n’ait pas saisi la description des arguments. De plus, si l'utilisateur ne saisit qu'un seul argument, cela ne fonctionne plus. Il est en effet obligatoire de saisir tous les arguments ou aucun. Enfin, il est très complexe de saisir et de maintenir une macro commune à tous les services d'un hôte. Par exemple, le port d'une base de données peut-être saisi une seule fois et sa valeur identique pour tous les services de supervision de cette base de données. Une troisième solution permet d'aller plus loin et d'être encore plus explicite : les macros personnalisées ou les custom macros. Les macros personnalisées Les macros personnalisées sont définies dans les commandes puis leur valeur est saisie dans l'hôte ou le service ou le modèle d'hôte ou le modèle de service. Exemple de définition d'une commande avec les macros personnalisées : L'important dans cette capture d'écran est surligné en rouge : L'utilisateur définit lui même ses propres macros. Ceci est rendu possible en : préfixant la macro par $_ (caractère dollar immédiatement suivi du caractère souligné/underscore) préfixant la macro par -HOST pour définir une macro qui doit être défini sur un hôte ou un modèle d'hôte -SERVICE pour définir une macro quoi doit être défini sur un service ou sur un modèle de service définissant explicitement le nom de la macro : WARNING par exemple terminant la macro par $ (le caractère dollar). Dans l'exemple ci-dessus, nous avons défini 2 macros personnalisées d'hôtes (SNMPCOMMUNITY et SNMPVERSION) et 3 macros personnalisées de service (DISK, WARNING et CRITICAL). Les macro d'hôtes SNMPCOMMUNITY et SNMPVERSION sont automatiquement remplies par Centreon lorsque l'utilisateur définit une communauté SNMP et une version SNMP pour un hôte : Les macros de service doivent être définies sur un service ou un modèle de service : En résumé, les avantages des macro personnalisées par rapport aux macros standards : 1. elles sont clairement définies, avec un nom significatif choisi par l'utilisateur (WARNING, MYSQLPASSWORD, NRPETCPPORT,...) 2. l'héritage entre modèle de service et service est beaucoup plus souple : par exemple, un modèle de service peut définir une seule macro personnalisée et laisser le service définir les autres 3. la surcharge d'une seule macro est possible 4. une macro personnalisée définie sur un hôte peut être partagée par plusieurs services. Ceci est très utilisé pour définir par exemple des arguments identiques sur un hôte, quel que soit le service. Le cas d'utilisation le plus courant étant le nom d'utilisateur et le mot de passe pour se connecter à une application lorsque celle-ci est supervisée par plusieurs services. Un exemple : il y a 10 services qui supervisent MySQL. Le nom d'utilisateur MySQL, le mot de passe et le port d'écoute de MySQL sont placés tous les trois dans des macros personnalisées d'hôte. Par contre, le nom d'une base de données sera placé dans une macro personnalisée de service. Mais espérons que cet éclairage nous permette « enfin » de vous y retrouver dans nos macros ! [Less]

Cette version apporte des améliorations sur l'ETL intégré dans la version 1.5.0 de Centreon BI ainsi que plusieurs correctifs mineurs sur l'interface et les rapports. Voici les principales anomalies qui ont été résolues : - La suppression ... [More] définitive des rapports disponibles dans l'interface Centreon BI ne fonctionnait pas ; - La sélection multiple des métriques dans le paramétrage spécifique du rapport « Hostgroup-Capacity-Planning-v2 » n'était pas pris en compte ; - La mise à jour de la configuration d'un modèle de rapport n'était pas prise en compte ; Et enfin, une meilleure gestion des erreurs a été intégrée dans l'ETL, cela concerne essentiellement la gestion du partitionnement des tables MySQL. ----------------------------------------------------------------------------------------------------------------------- This version brings several enhancements to the ETL software already in use in the version 1.5.0 of Centreon BI. Few minor fixes were made on the GUI and on the reports. You will find below the main bugs solved by this version : - Complete deletion of reports was available on the GUI but not functioning ; - Multiple select of the metrics in the configuration of the report « Hostgroup-Capacity-Planning-v2 » was not taken in account ; - The update of the report model configuration form was not taken in account. Finally, a better error management is integrated in the ETL. It mainly concerns the management of the MySQL table partitioning. [Less]

The Centreon CLAPI module (Centreon Command Line API) is a tool to manage all configuration of Centreon server objects'. Using command line from a terminal, it's possible to add/modify/delete configuration objects of the scheduler (Hosts, Services ... [More] , contacts, Groups, etc.), the access control list (ACL) of Centreon GUI or manage schedulers and brokers. Since Centreon-CLAPI version 1.3.0 which brought the complete management of the ACL of the Centreon GUI as well as Nagios© and NDOutils broker, the new version 1.4.0 completes the management of Centreon objects by bringing the support of SNMP traps as well as complete management of the Centreon-Broker. Here is the detailed list of the new features: Management of SNMP Traps List all SNMP traps Add / Delete SNMP traps definition Set parameters of a trap (name, comment, OID, status ,execution command , …) List matching rules of a trap Add / Modify / Delete a matching rule to a trap Manage Centreon-Broker List all available Centreon Broker CFG Add / Delete a Centreon Broker CFG Set parameters of a Centreon Broker CFG List Centreon Broker I/O Add / Get / Set / Delete parameters of Centreon Broker I/O The management Centreon-Broker's I/O allows you to define the storage of data (perfdata) into adatabase or RRD for graphs and configure log files and manage correlation of events for notification process. For more information about Centreon-Broker, please follow this Centreon documentation website. The wiki dedictaed Centreon-CLAPI was updated by the Centreon team. All new features are fully detailed in it. Please note that some commands have been modified so we strongly recommend that you check your commands with this new release. As usual, we invite you to report any bug that you may encounter at our forge to follow each ticket. Le module Centreon permet de manipuler la configuration des objets de votre serveur Centreon. Depuis un terminal, en ligne de commande, il est possible d’ajouter/modifier/supprimer des objets de configuration de votre ordonnanceur (Hôtes, Services, Contacts, Groupes, ...) ainsi que la gestion des listes de contrôles d’accès (LCA) à l’interface Centreon ou encore la configuration de vos ordonnanceurs et brokers. Depuis la version 1.3.0 de Centreon-CLAPI qui apportait la gestion complète des ACL de l’interface web Centreon ainsi que de la configuration de l’ordonnanceur Nagios©, de son broker NDOutils, la nouvelle version 1.4.0 complète la gestion des objets Centreon en apportant le support des traps SNMP ainsi que de la gestion complète du broker Centreon. Voici la liste détaillée des nouvelles fonctionnalités : Gestion des traps SNMP Afficher la liste des traps SNMP Ajouter / Supprimer des définitions de traps SNMP Modifier des paramètres d’un trap SNMP (nom, commentaire, OID, statut, commande à exécuter lors de la réception de l’interruption, …) Afficher la liste des règles de recherche sur les arguments de l’interruption Ajouter / Modifier / Supprimer des règles de recherche Gestion de la configuration de Centreon-Broker Afficher la liste des brokers disponibles Ajouter / Supprimer un broker Modifier les paramètres d’un broker Afficher la liste des types d’entrées sorties (I/O) d’un broker Afficher / Ajouter / Modifier / Supprimer les entrées / sorties (I/O) d’un broker La gestion des entrées / sorties (I/O) d’un broker permettent par exemple de définir la gestion du stockage des données collectées (perfdata) vers une base de données, des fichiers RRD (pour les graphiques de performance), de journaliser les évènements ou de mettre en place la corrélation d’évènements en vue d’un processus de notification. Pour plus d'information sur Centreon-Broker, rendez-vous sur le site de documentation Centreon. Le wiki du module Centreon-CLAPI a été mis à jour par l’équipe Centreon et permet d’expliquer l’ensemble des possibilités offertes par le module quant à la manipulation de la configuration de Centreon. Nous recommandons aux utilisateurs désirant de faire une mise à jour de valider le fonctionnement de leurs commandes avec cette nouvelle version. Comme d'habitude, nous vous invitons à nous remonter les bugs éventuels que vous avez pu rencontrer sur notre forge afin d'avoir un suivi de chaque ticket. [Less]

Cette version apporte des corrections majeures sur l'ETL intégré dans la version 1.5.0 de Centreon BI ainsi que quelques correctifs mineurs sur les rapports. Voici les principales anomalies qui ont été résolues : Des caractères spéciaux dans le ... [More] fichier de configuration des crons empêchaient leur exécution journalière (uniquement pour les installations RPM) ; Les tables de la base de données Centreon qui concernent le module Centreon BAM n'étaient pas importées sur le serveur MySQL de reporting par le moteur de synchronisation des données ; Le calcul des données mensuelles de capacité par métrique était incorrect ; En ce qui concerne les rapports : dans le rapport Hostgroups-Incidents-1 : le logo sur la page de garde n'était pas dynamique, dans le rapport Hostgroups-Availability-1 : le nom du groupe d'hôte n'était pas affiché dans la deuxième page de statistiques détaillées par groupe. Des améliorations ont également été apportées sur les options de reconstruction des données statistiques afin de fournir plus de flexibilité sur les actions de migration ou de reprise des données historiques. ------------------------------------------------------------------------------------------------ This version brings several major bug fixes on the ETL that is integrated in the version 1.5.0 of Centreon BI. Few minor fixes were made on the reports. You will find below the main bug fixes: The daily execution of the statistic calculation crons was corrupted by illegal characters in the cron configuration file (only for RPM installation) ; The tables concerning Centreon BAM in the database Centreon were not imported on the reporting server by the data synchronization engine ; The capacity statistics calculated by month were incorrect ; Concerning the reports : in the report Hostgroups-Incidents-1 : the logo in the front page was not dynamic ; in the report Hostgroups-Availability-1 : the name of the host group was not displayed in the second page of the detailed statistics by host group. The statistic rebuild options have been improved in order to provide more flexibility for the upgrades or the integration of Centreon historical data. [Less]

Les équipes de R&D de Centreon annoncent une nouvelle version majeure de Centreon BI. Cette version intègre de nouvelles fonctionnalités qui améliorent les performances de génération des rapports grâce à un ETL intégré. De nouveaux ... [More] rapports sont également disponibles afin de présenter une vision globale de la disponibilité de votre système d'information et de l'utilisation des ressources, aussi bien en terme de performance que de stockage. Enfin, des bibliothèques de composants (tableaux, graphiques, jeux de données) pré-configurés sont mis à disposition afin afin de faciliter le développement de vos propres rapports. Cet article décrit les principales nouvelles fonctionnalités de Centreon BI 1.5.0. -------------------------------------------------------------------------------------- The Centreon R&D team is proud to announce a new version of Centreon BI. This version comes with some new features that will enhance the report generation performances thanks to an integrated ETL. New reports will also be available to help you visualize the global availability of your equipments but also their performance and storage capacity. Furthermore, we also added new BIRT component libraries (tables, charts, data sets) in order to help you create your own reports. This article describes the main new functionnalities of Centreon BI 1.5.0. Software compatibilities Softwares Versions Centreon BI 1.3.9 1.4.0 1.5.0 Centreon >= 2.0 >= 2.3 >= 2.3 Eclipse BIRT 2.6.1 2.6.2 2.6.2 Sun Java runtime environment >= 1.5 >= 1.5 >= 1.5 ETL An ETL was integrated in Centreon BI. It stores and aggregates raw data issued from Centreon in a relationnal denormalized database optimized for reporting reading queries.This new architecture brings many advantages : The reporting platform becomes independent and doesn't additionally load the monitoring platform ; The development time of new reports is reduced thanks to the new reporting data model. This also improves the load and time of report generation ; MySQL is not needed anymore in order to synchronize the monitoring data on the reporting server. The ETL management and the aggregation rules can be defined via the Centreon BI interface. New Reports The new reports in the 1.5 version of Centreon BI was designed for the following domains : The availability management The capacity management The performance management Each report provides several axes (dimensions) of analysis based on Centreon configuration : Host groups: sort the equipments declared in the configuration by functional groups (application, clients, entities, …) or geographical groups ; Host categories: identify the type of equipment (servers, network equipments, …), the vendor and the operating system and/or its version ; Service categories: classify services based on their type (CPU load, memory, capacity, …) or their severity(minor, major, blocking). Live services: time ranges in the different days of the week (correponds to the timeperiods defined in Centreon). The content of each report was designed to provide a «top >> down» view. The first pages present an overview synthesized by functional groups, technical groups and indicator types. The following pages offer more details for each functional group with a focus on the most critical indicators and equipments. Here are a few examples on the availability report : The capacity management addresses both the storage management and the rationalization of resources. Thanks to the Centreon BI reports, you can identify the underused, overloaded or stable equipments. This reporting is made by identifying one category of indicators (CPU, memory, number of users connected to an application, …) and underuse/overload thresholds defined by the user when planning the report generation. The performanceon incidents management is identified by two indicators : MTRS : Mean Time to Repair Service MTBF : Mean Time Between Failure More examples are available on Centreon website. Report Development libraries Every visible components (tables, charts, …) in the report templates described previously are stored in BIRT libraries in order to be reused in new reports. If you want to go further in the use of Centreon BI and to create your own report with the open-source reporting tool BIRT, these components will help you greatly. Each component is configurable, which allows to extend its use to many cases. Therefore you will be capable of creating your own dashboards in a few clicks. --------------------------------------------------------------------------------------------------------------------------------------Compatibilité des logiciels Logiciels Versions Centreon BI 1.3.9 1.4.0 1.5.0 Centreon >= 2.0 >= 2.3 >= 2.3 Eclipse BIRT 2.6.1 2.6.2 2.6.2 Sun Java runtime environment >= 1.5 >= 1.5 >= 1.5 ETL Un ETL a été intégré à la solution Centreon BI, il permet d'alimenter une base de données relationnelle dé-normalisée optimisée pour les requêtes de lecture liées au reporting.L'ETL alimente ce datawarehouse avec les données brutes collectées par la supervision Centreon et les agrège en indicateurs de plus haut niveau. Cette nouvelle architecture apporte plusieurs avantages : La plate-forme de reporting devient indépendante et n'induit pas de charge supplémentaire sur la plate-forme de supervision; Les délais de développement de nouveaux rapports sont réduits grâce au nouveau modèle de données dédié au reporting. Ceci améliore également les délais et charges de génération des rapports ; Il n'est plus nécessaire de mettre en place une réplication MySQL afin de synchroniser les données de la supervision sur le serveur de reporting. L'administration de l'ETL et la définition des règles d'agrégation des données est réalisée depuis l'interface Centreon BI. Nouveaux rapports Intégrés Les nouveaux rapports de la version 1.5 de Centreon BI ont été conçus de manière à adresser les domaines suivants : La gestion de la disponibilité ; La gestion de la capacité ; La gestion de la performance. Chaque rapport fournit différents axes (dimensions) d'analyse issus de la configuration de Centreon : Les groupes d'hôtes : groupes fonctionnels (applications, clients, entités, …) ou géographiques permettant de classer les équipements déclarés dans la configuration ; Les catégories d'hôtes : groupes techniques permettant d'identifier la nature de l'équipement (serveurs, équipements réseaux), le constructeur et les systèmes d'exploitations et/ou versions ; Les catégories de services : permettent de classer les services selon leur type (Charge CPU, mémoire, stockage, …) ou leur criticité (mineur, majeur, bloquant). La plage de service : Plages horaires sur les jours de la semaine qui seront pris en compte pour le calcul de la disponibilité ou des performances (il s'agit des « timeperiods » définis dans la configuration Centreon). Le contenu de chaque rapport a été pensé de manière à fournir une vue « Top >> Down ». Les premières pages présentent des statistiques synthétisées par groupes fonctionnels, groupes techniques et types d'indicateurs. Les pages suivantes fournissent un niveau de détail par groupe fonctionnel avec également un focus sur les équipements et les indicateurs les plus critiques. Quelques exemples sur le rapport de disponibilité : La gestion de la capacité aborde aussi bien la question du stockage que la rationalisation des ressources dans un sens plus large. Grâce aux rapports Centreon BI, il est possible d'identifier les équipements sous-utilisés, surchargés ou stable. Ce reporting est réalisé selon une catégorie d'indicateurs à définir (CPU, mémoire, nombre d'utilisateurs connectés à une application, ….) et de seuils de sous-utilisation ou de surcharge définis par l'utilisateur lors de la planification du rapport. Enfin la performance sur les délais de résolution des incidents et la limitation de leur récurrence est identifié par deux indicateurs : MTRS : Mean Time to Repair Service MTBF : Mean Time Between Failure Des exemples supplémentaires sont disponibles sur le site Centreon . Composants / BIBLIOTHEQUES Tous les composants (tableaux, graphiques, etc...) visibles dans les modèles de rapports décrits précédemment sont stockés dans des bibliothèques BIRT afin qu'ils puissent être ré-utilisés dans de nouveaux rapports. Si vous souhaitez aller plus loin dans l'utilisation de Centreon BI et créer vos propres rapports à l'aide de l'outil de reporting open source BIRT, l'utilisation de ces composants vous facilitera grandement les développements. Chaque composant est également paramétrable, ce qui permet d'étendre son utilisation à de nombreux cas. Vous serez donc en mesure de créer vos propres tableaux de bords en quelques clics. [Less]

Dans notre article précédent, nous avions présenté les modèles de services et indiqué comment bien les utiliser. Les modèles d'hôtes existent et disposent des mêmes fonctionnalités que les modèles de services. Ils disposent aussi d'avantage de ... [More] fonctionnalités qu'il est important de connaître pour industrialiser votre configuration. Nous allons présenter dans cet article les fonctionnalités que vous devez connaître afin de maximiser l'utilisation de Centreon. ------------------------------------------------------ In the previous blog post, we introduce you to service templates and how you should use them. Host templates exist as well and have roughly the same features than service templates. But it's important to know how to use all features to industrialize your configuration. So, you will find in this article all features you have to manage to optimize your Centreon platform. Definition A host template is a Centreon monitoring object that has all the characteristics needed to define an host. You can use it as basis for host configuration. There is a strong link between host template and service template: they are pre-configured objects that you can use in host. You find the same characteristics: legacy/inheritance: A host can inherit from a host template and it inherits all parameters which have been set up in the “parent” host template. overload: when a host inherits from an host template, you always have the option to “force/overwrite” a parameter from the template.  In practical terms,to define an host template, go to the page "Configuration->hosts->Templates" and click on the link "add": The host template have additional features than service templates: multiple legacy/inheritance relation between service template Multiple legacy/inheritance A host template can inherit from several host templates, unlike a service that can inherit only from one service template. When you create a host, with Centreon, you can define if the host inherits from several host templates at a time. For example, below: In the above example, the host inherits from different host templates: HW-DELL, Servers-Linux, Infra-DB-MySQL and Infra-HTTP. It means that host inherits all parameters previously entered in the template. The order is important because it defines the legacy order of parameters. A specific parameter can be defined in several host templates. The order that you choose for the legacy and with which you choose a model is dominant. For example, if the test interval of the host is defined for each host template below, the inherited parameters correspond to the parameter that you define in the last chosen element (Infra-HTTP in our example). Where does the multiple legacy principle come from? You have seen that it wasn't necessary for services to have multiple legacy template, so why should it be necessary for a host to have it ? The answer is about the parameter «Create services linked to template too". This parameter allows the setting up of associative legacy, useful link. Indeed, a "host" server can receive several «under-hosts" as database and application servers for example. Relation host template with service template A host template can be linked to one or several service template. for example, the host template "HW-Dell" can be linked to these following service templates : hw-dell-cpu : monitoring of hardware functioning for each real CPU hw-dell-dimm: monitoring of hardware functioning for RAM module hw-dell-raid: monitoring of hardware functioning for RAID controller ... Considering this fact and if the option "Create services linked to template too" is configured "yes", each time a host inherit from a host template, service template of host template will be reproduced in service on the host. It means that there is not legacy but a service creation. Strategy Once again, the aim is to save your time. Using templates, we want to simplify the process by deploying services automatically. We think that is a better idea than to create service for each host. Thanks to the following configuration strategy, you can accelerate the configuration: 1. To share your IT infrastructure in several parts : -servers: hardware operating system applications -network : switch router firewall 2. To create a host template by different component, for example for the hardware : -hardware host template: HW-Dell host template: HW-IBM host template: HW-HP 3. To do the same for others components : operating system, applications, etc. 4. To create service template by monitoring applicator 5. To associate these service templates to the adequate host template 6. To create hosts based on host template So, using Centreon become easier for operating team. To create a host, the user has to wonder the following questions: 1. Is it a server? If the answer is yes, so: what is its hardware ? (example : Dell) What is its OS? (example : Linux) What are their applications which work with the server ? (example : MySQL or Apache) 2. Is it network equipment ? If the answer is yes, so: What is the type of equipement ? 3. ... Once it’s done, it’s easier to define a host in Centreon : you have to select the fitting host templates. It’s now useless to know the server list that you have to create and parameters that you have to give to these services. Configuration made easy! ----------------------------------------------------------------------------------------------------------------------------- Définition d'un modèle d'hôte Un modèle d'hôte est un objet de supervision Centreon qui possède toutes les caractéristiques définissant un hôte et pouvant être utilisé comme base pour la configuration d'un hôte. Un modèle d'hôte est à l'hôte ce qu'un modèle de service est à un service : un objet pré‑configuré pour être utilisé dans des hôtes. Les caractéristiques sont les mêmes :  héritage : un hôte peut hériter d'un modèle d'hôte et un modèle d'hôte peut hériter d'un autre modèle d'hôte parent. surcharge : un hôte héritant d'un modèle d'hôte peut modifier (« surcharger ») le paramètre hérité par le modèle. En pratique:  pour définir un modèle d'hôte, se rendre sur la page « Configuration → hôtes → Templates » puis cliquer sur le lien « add » : Les modèles d'hôte ont des fonctionnalités supplémentaires aux modèles de service : héritage multiple relation avec les modèles de services Héritage multiple Un hôte peut hériter de plusieurs modèles d'hôte, contrairement à un service qui ne peut hériter que d'un seul modèle de service. Lors de la création d'un hôte, il est possible avec Centreon de définir si cet hôte hérite de plusieurs modèles d'hôte en même temps. Exemple ci-dessous : Dans l'exemple ci‑dessus, l'hôte hérite de plusieurs modèles d'hôtes : HW-DELL, Servers-Linux, Infra-DB-MySQL et Infra-HTTP. Cela signifie que les paramètres saisis pour les modèles vont tous être hérités par l'hôte. L'ordre de l'héritage est important car il définit l'ordre d'héritage des paramètres. Un paramètre donné peut être défini dans plusieurs modèles d'hôte. L'ordre choisi durant l'héritage permettant de choisir quel modèle est prépondérant. Par exemple, si l'intervalle de test de l'hôte est défini pour chaque modèle d'hôte ci-dessus, le paramètre hérité correspondra au paramètre défini dans le dernier élément choisi (Infra-HTTP dans notre exemple). Il est légitime de se demander d'où vient ce principe d'héritage multiple : puisqu'il n'est pas nécessaire que les services disposent de l'héritage multiple, pourquoi serait-il nécessaire que les hôtes en dispose ? La réponse à la question est liée au paramètre « Create services linked to template too », qui permet la mise en place d'un héritage associatif, lien pratique. En effet, un serveur « hôte » peut lui-même recevoir plusieurs « sous-hôtes » comme une base de données et serveur d'application par exemple. Relation modèle d'hôtes et modèle de service Un modèle d'hôte peut être relié à un ou plusieurs modèles de service. Par exemple, le modèle d'hôte « HW-Dell » peut être relié aux modèles de services suivants :  hw-dell-cpu : supervision du fonctionnement matériel de chaque CPU physique hw-dell-dimm:supervision du fonctionnement matériel de chaque barrette de mémoire vive hw-dell-raid: supervision du fonctionnement matériel du contrôleur RAID controller ... Dès lors et dès que l'option « Create services linked to template too » est configurée à « Yes », lorsqu'un hôte héritera d'un modèle d'hôte, les modèles de service du modèle d'hôte seront copiés en service sur l'hôte. Cela signifie qu'il n'y a pas que de l'héritage mais aussi une création de services. Stratégie Encore une fois, le but est de gagner du temps. L'idée est de se faciliter la vie en déployant des services automatiquement, en se basant sur des modèles. Plutôt que de créer des services pour chaque hôte, en les copiant « à la main », il est préférable que ces services soient créent automatiquement. La stratégie de configuration suivante permet d'accélérer la configuration :  1. découper son système d'informations en différentes couches -serveurs: hardware système d'exploitation applications -réseau : switch routeur parefeux ... 2. créer un modèle d'hôte par composant différent. Exemple pour le hardware : -hardware modèle d'hôte: HW-Dell modèle d'hôte: HW-IBM modèle d'hôte: HW-HP 3. faire de même pour les autres composants : Système d'exploitation, applications,etc. 4. créer des modèles de service pour chaque indicateur de supervision 5. associer ces modèles de service au modèle d'hôte correspondant 6. créer des hôtes en se basant sur les modèles d'hôte Dès lors, l'utilisation de Centreon devient beaucoup plus simple pour les équipes d'exploitation. Pour créer un hôte, un utilisateur doit se poser uniquement les questions suivantes : 1. est ce un serveur ? Si oui alors : quel est son hardware ? (exemple : DELL) Quel est son OS ? (exemple : Linux) Quelles sont les applications fonctionnant sur ce serveur ? (exemple : MySQL et Apache) 2. est ce un équipement réseau ? Si oui alors : quel est le modèle de cet équipement ? 3. ... Une fois ceci fait, il devient très simple de définir cet hôte dans Centreon : il suffit à l'utilisateur de choisir les modèles d'hôtes correspondants. Il ne lui est plus nécessaire de connaître la liste des services à créer et des paramètres à passer à ces services. L'utilisation est simplifiée et accélérée. [Less]

Centreon Enterprise Server (CES) now includes an agentless-monitoring solution dedicated to Windows-based applications and environments. Based on Microsoft's Windows Management Instrumentation (WMI) API, this brand new tool will save monitoring ... [More] team time and efforts deploying performance and availability software. ------------------------------------------------------------------------------------------------------ Centreon Enterprise Server (CES) inclut une solution de monitoring sans agent dédiée aux applications et environnements Windows. Basé sur l’API Windows Management Instrumentation (WMI) de Microsoft©, ce nouvel outil fera économiser du temps et des efforts aux équipes de supervision lors du déploiement et de la supervision de leur parc. Centreon Enterprise Server: une supervision simple En 2011, Merethis dévoilait CES : une distribution GNU/Linux dédiée à la supervision, basée sur les systèmes d'exploitation CentOS ou Red Hat. CES prend en charge l'intégralité de l'installation du système, des logiciels jusqu'aux sondes, ainsi que les ordonnanceurs. Vous conservez la main sur l'administration complète du système et gérez les changements des composants officiels et communautaires à votre guise. Les plans de reprise d'activité sont également facilités et rendent les restaurations plus rapides et sûres. Vous pouvez ajouter à CES les autres produits MERETHIS (Centreon BAM, Centreon BI and Centreon Map). CES intègre aussi de nombreuses fonctionnalités avancées et de nombreux modules complémentaires exclusifs, comme les modèles et sondes préconfigurées et développés par les équipes de Merethis. Ils permettent de superviser facilement OS, hardware, middleware ou encore équipements réseaux. CES vous permet une gestion simple et efficace de votre infrastructure informatique grâce à la mise à disposition de bonnes pratiques et de modèles (templates) préconfigurés pour une mise en place rapide, efficace et performante. Les souscriptions sont disponibles auprès de la société Merethis elle-même et de ses partenaires. Pour en savoir plus sur les offres CES, rendez-vous sur le site Centreon. Centreon Entreprise Server WMI, outil de supervision pour Windows Windows Management Instrumentation (WMI) est l'implémentation, par Microsoft©, du standard Web-Based Entreprise Management (WBEM). Ce standard prend en charge le management des ressources systèmes ainsi que la surveillance de ces derniers. Grâce au composant WMIC (Windows Management Instrumentation Command-line) et au jeu de requêtes WQL (Windows management instrumentation Query Language), l'équipe R&D de Merethis a développée des outils entièrement supportés par Centreon Enterprise Server (CES), permettant ainsi de créer des plates-formes de supervision personnalisables et sans agent pour toutes les applications et environnements basés sur Microsoft© Windows ou utilisant le standard WBEM. Désormais, cet outil de supervision permet de collecter des informations applicatives et systèmes sans installation de composants supplémentaires sur les serveurs Microsoft© Windows. Cette intégration dans CES simplifie le déploiement et la gestion de la supervision dans un environnement Microsoft© Windows. Merethis a développé deux sondes de supervision (plugins) permettant :  De superviser les éléments système :  Etat des services au démarrage automatique ou fonctionnement d’un service ;  Le taux d’utilisation du CPU ;  Le taux d’utilisation des disques ;  La supervision des journaux d’événements ;  La supervision des fichiers (présence par nom, extension, age, taille, etc.) ;   Le taux d’utilisation de la bande passante d’une interface réseau ;  Le taux d’utilisation de la mémoire physique ou virtuelle (fichier de pagination) ;  La supervision des processus (nombre, consommation mémoire, arguments d’exécution, etc.) ;  De superviser les applications utilisant le standard WBEM telles que : MS Active Directory, MS Exchange, MS IIS, MS SQL Server, MS Sharepoint, MS HyperV, Citrix, etc. Le deuxième plugin est extensible et permettra à l’administrateur Microsoft© Windows de superviser l’application désirée. En effet, cette sonde de supervision utilise les informations de collecte décrites dans un fichier au format XML. Si l’administrateur possède des connaissances de l’outil perfmon (moniteur de performance) et du fonctionnement de WMI, il pourra à sa guise extraire les informations désirées et les superviser. En conclusion, les outils Centreon WMI facilitent l’automatisation des tâches de supervision des environnements Microsoft© Windows grâce à la personnalisation des règles et des options de contrôles. Par ailleurs, avec l’utilisation de WMI, plus besoin de déployer un agent sur les serveurs ou de mettre à jour ce dernier.---------------------------------------------------------------------------------------------------------- Centreon Enterprise Server: monitoring made easy In 2011 Merethis released CES (Centreon Enterprise Sever) a GNU / Linux distribution dedicated to a Centreon based monitoring platform based on CentOS and Red Hat operating systems. CES provides pre-configured out-of-the-box tools to automate the monitoring of essential system resources deploy alert management and business service management and set up your monitoring portal and console. On top of that you can subscribe to other Merethis products (Centreon BAM, Centreon BI and Centreon Map). CES integrates a few more specific extensions such as pre-configured models and plug-in developed by Merethis team. They are dedicated to OS, hardware, network components, and middleware. You can easily set up a proper monitoring platform following some good practices and using the templates that you can find within CES. Currently subscriptions are available through Merethis and its consulting partners. To know more about the CES offers, please go online on the Centreon website Centreon Entreprise Server WMI Monitoring tool Windows Management Instrumentation is the implement of Web-Based Entrerpise Management (WBEM) by Microsoft©. WBEM deals with system resources management and monitoring. Working on WMIC (Windows Management Instrumentation Command-line) and WQL (Windows management instrumentation Query Language) requests, Merethis R&D teams have developed new tools supported by Centreon Enterprise Server making it possible to build custom agentless-monitoring solutions for all Windows-based applications and environments or based on WBEM CES can collect applicative and system data without additional components to install on Microsoft© Windows servers. As a built in tool with CES, it makes the deployment and monitoring management easy for Microsoft© Windows environment. MERETHIS has worked on two types of plugins that can: :  monitor some elements of system :  service states when auto-start or service operating ;  CPU usage rate ;  disk usage rate ;  event logs monitoring ;  files monitoring (presence by name, extension, age, size, etc) ;  bandwidth usage rate in network interface ;  virtual or real memory usage rate (paging file) ;  process monitoring (number, consummation, memory, execution argument, etc) ;  monitor some applications using WBEM such as MS Active Directory, MS Exchange, MS IIS, MS SQL Server, MS Sharepoint, MS HyperV, Citrix, etc. The second plug-in is extensible and helps the Microsoft© Windows admin to monitor the application he wants. Indeed, the plug-in uses all collected information that has been described in XML files. If the admin knows perfmon (performance monitor) and how WMI works, he can extract all information he wants and monitor them. To sum it up, Centreon WMI tools make the automation of monitoring tasks in Microsoft© Windows environment easy customizing control rules and options. Using WMI tool, no more need for local deployment, or tedious configuration… [Less]